RPAに何をやらせるのか？ | ユーザー目線で見るRPA（２）

前回のおさらい

前回は「RPAって何ができるの？」と題して、RPAとは何か、得意領域／不得意領域、RPAを動かすために必要な指示＝処理フローの難易度等の話をしてきました。要約すると以下のような感じです。

上記に「指示は必ず正しく行うけど、指示が正しくないとおかしな動きをするので、『指示の正しさを確認する』ための社員が定期的に面倒を見てあげる必要がある」を付け加えておきたいと思います。

RPAのポテンシャルがわかったところで、今回はRPAに何をやらせるのかを考えていきましょう。使いようによっては非常に優秀なデジタルレイバーですが、理解せずに使えばポンコツロボットに成り下がってしまいます。
重要なのは「特性に合った業務をやらせる」という、人間と同じ発想を持つことです。

RPAに何をやらせるのか？

活用事例から考える

RPAの活用事例として見たことがあるものとして、以下のようなものがあります。

これらに共通して言えることは、「Input／Outputの形状が同じ、もしくはパターン化可能」ということです。システムから送られてくるメールは必ず同じ行数に同じ内容が記載され、その行のテキストをWebサイトの特定のエリアに転記することになります。Webサイトからファイルをダウンロードするためのボタンは同じ位置にあれば定期的にボタンを押すだけになります。

どちらも件数が多ければ多いほどRPAの効果を得やすいものですが、事例があまりにも限定的で汎用的にどこの企業でも使えるかというと、全く当てはまらなかったり、わざわざRPAを導入してまでやるほどの件数がなかったりするかもしれません。

RPAの真価

実は「わざわざやるほどの件数がない」業務こそが、RPAの真価を発揮するポイントです。

RPAの機能を総合的に見ると、「言語・動作環境に依存しないシステムをユーザー独自で構築できる」ツールなのです。RPAそのものがシステム開発環境兼動作環境であり、他システムや人間が作ったデータをInputに別のOutputを作り出すための連携システムを対象業務専用のソフトではなく汎用的な環境として提供してくれます。

システムAのファイルを出力する仕組みや、WebサイトBにデータを入力する仕組みを作ろうと思うと、それぞれの提供元にカスタマイズを依頼したり、専用のツールを導入する必要がありますが、RPAはそれらに依存しない形でユーザー独自で仕組みを構築することができるのです。

個々にシステムを導入しようとすると投資対効果が見込めないような業務でも、RPAであれば取り込むことが可能になります。多少設定が難しいとはいえ、一からプログラムを習得して構築するのと比較すれば簡単です。しかもInput／Outputとなるもののアーキテクチャ毎に異なる言語を習得する必要が無く、RPAさえ使いこなせれば良いのです。

シナリオは複数作成した上で時間をずらして実行することができます。
システムA～Dを対象としたシナリオ、WebサイトE～Hを対象としたシナリオ、といったようにいくつものシナリオを作成することで、ひとつひとつの効果が小さかったとしても合計するとある程度の効果を産むことができます。

それこそがRPAの真価であり、これまでシステム化が及ばなかった領域をシステム化できる＝生産性向上＝働き方改革という流れに到達することになります。

「RPAエンジニア」が登場する？

以前「非機能要件で見るGSuite」の中でもお話しした「ITのユーザーシフト」ですが、RPAはまさにその文脈に該当するシステムと言えます。
しかし導入・活用は１シナリオ毎にミニシステムを導入するようなものですから、徒手空拳で取っ組み合うにはかなりハードルが高いです。

他のシステムと同様に導入支援や開発をベンダーに依頼する、としてしまうとRPAの持つメリットの多くの部分を捨てることになりかねません。作成されたシナリオが業務を自動化することによる効率化の恩恵は受けられますが、先ほども述べたように、既存のシステムでは投資対効果が得られなかったような業務を対象とできることがメリットなわけですから、そこに通常のシステムと同様に導入支援を受けるとなると掛かる費用のほうが高くなるし、その後の保守・メンテナンスのノウハウを蓄積することができずさらに費用がかかることになりかねません。

しかし現在RPAの導入は加速度的に進んでおり、近い将来RPAを専業とするようなSE、「RPAエンジニア」が登場する可能性は無くはありません。
RPAの適用に適した業務を分析し、適切な導入をサポートするようなサービスがあれば需要はあるかもしれません。社内のRPA担当者の育成もサポートできればなおよいかもしれませんが、そこまでいくと「エンジニア」ではなく「コンサルタント」というのが適切かもしれません。

どちらにしても、RPAの導入＝システムを内製する、であるということを理解したうえで、そのための体制を整備することが重要ということができるでしょう。

「間の業務」を探し出す

RPAの真価を理解したうえで、もう一度本題である「RPAに何をやらせるのか」に立ち返ってみます。
具体例ではありませんが、システムや人が作っているOutputを元に別のOutputを作るための「間の業務」が適していると言えるかもしれません。RPA=連携／変換システムと捉えて、データとして取り込める定型的なInputがあり、それを基にしたOutputを作り出すような業務を探し出すのです。
１つ１つの業務は大きな手間がかかるものでなくても良いです。むしろ小さいほうがシナリオ作成もメンテナンスも楽になります。それらをいくつも束ねて自動化することで効果を産みだしていくのです。

中締め・その２

繰り返しになりますが、RPAのシナリオ作成はプチシステム導入です。どんなに手軽に入れられるツールであったとしても、それによって運用手順が変わる可能性がありますし、RPAはInputの条件がシビアですからきちんとしたルールを作って運用する必要があります。
次回はRPAでシナリオを作成するための手順をお話ししていきたいと思います。