最近 RPA（Robotic Process Automation）が流行っている。「ルーチンワークは RPA で自動化！」と言うと聞こえはいいが、本当に効果はあるのだろうか？
自社で RPA を導入した際に触れる機会があったのだが、巷で謳われているようなメリット溢れる RPA と現実の実物にあまりにも乖離があったので、実際に導入した時感じた RPA の問題点を考えてみたい。
…というのは建前で、導入した RPA があまりに思ってたのと違ったので、ここで鬱憤を吐き出す。
おことわり
- この記事はとある RPA ソフトに触れてみた感想からできています。
- その為、RPA の悪い点としている部分がその”特定のソフト”に偏向していると思います。
- 完全にプログラマ視点です。
強い制約
RPA を使うにあたり、業務に応じて柔軟に利用…とは言えない、非常に厳しい制約がいくつかある。
デジタル化済みが前提
当たり前と言っては当たり前なんだけど、パソコンのソフトウェアなのでパソコン内で完結する作業しか自動化できない。インプットが紙な業務は RPA 化できないので、業務のペーパーレス化が進んでいることが前提条件になる。アウトプットが紙というのであれば、プリンタ出力するだけなので出来ないことはない。
インプットが紙の場合 OCR という手もある。下記のようなユースケースだ。
OCR 自体は割と昔からあるが、まず印字か手書きかで認識率は大きく異なる。RPA 導入時のベンダーに聞いたところ、手書きの OCR はハッキリ言って無謀だが印字ならまあ大丈夫だろうというレベルらしい。
しかし印字した紙を受け取ってスキャンして OCR するくらいなら、印字する為の元のデータがあるはずなのでそれを貰えないかと思ってしまう。もちろん相手方の都合があるので「絶対貰えるハズだ！」とは言えないけど、スキャンして OCR すること自体も結構手間なので、できればそこも含めての自動化にしたいと考えてしまう。
人との同居はできない
業務の自動化と言うのだから、自分は PC を使って仕事をしている裏で RPA がガリガリ仕事を進めてくれるのを想像していたが、そうではないらしい。
実際は RPA のシナリオが起動したタイミングで PC の操作ハンドルは奪われる。（厳密には奪われないが、RPA 処理中に何か操作をすると一発でエラー停止する）つまり人が普段使用している PC に RPA は入れることができず、RPA 専用 PC を用意して動かすことを余儀なくされる。
並列実行もできない
RPA の処理は「シナリオに沿ってキーボード・マウスの入力をエミュレートする」という形で動作するので、ブラウザを操作する場合はブラウザが立ち上がるし、マウスカーソルも指定された処理通りに動く。上記で書いた通り PC の操作を占有するので、複数のシナリオを並列実行はできないのだ。
並列実行できないので自ずと順次実行する形になる。基本的に手動でシナリオ開始を叩くということはしたくないので、Windows タスクマネージャで指定時間になったら目的のシナリオを起動させるという方法を取る。（他にも起動方法あるけど、あまり実用的ではなかった）
順次実行の問題点は、A というシナリオが終わらないうちに B というシナリオが起動する時間になってしまった場合、シナリオ B は単純に開始しないという挙動を取る点だ。エラーを吐く訳でも無いので実行されなかったという事実は画面を見ていないと分からない。シナリオ A の終了時間にバラつきがあり予測できない場合、どうしたらいいのだろう？
アップデートもできない
RPA では操作対象の状態を識別する手段として「画像マッチング」という方法がある。操作対象の処理結果だったり、画面遷移の有無だったりを「画像」として判別する方法だが、基本的に用意した画像と完全一致しなければならない。なのでアップデート等で操作対象の GUI が変わってはいけないし、セキュリティソフトの通知が入ってもダメだし、OS のアップグレードでスタートメニューやタスクバーの表示が変わってもダメだ。
また、新たにシナリオを作成する場合、アップデートが止まっている環境で作成しなければならない。新しいシナリオがより新しいバージョンを要求する場合はアウトだ。追加するには既存のシナリオを新しいバージョンで作り直さなければならない。
難しいシナリオ作成
説明が前後してしまうが、RPA で一つの業務を担う場合、その業務をフローチャート化して実行する。この単位をシナリオという。
このシナリオに関しても作成するのには一筋縄ではいかない。
非常に不安定な判定
前述の「画像マッチング」だが、非常に繊細ですぐにマッチングエラーとなる。
理屈としては手動で実行した際の画面を画像として保存しておき、次に自動実行した際は必ず同じ座標で同じ画像になるというものだが、実際はシナリオ作成中に何度もエラーになる。マッチング率を下げれば解消するのかもしれないが、そもそも何処がアンマッチでエラーになっているかもわからないので、安易にマッチング率を下げて対応して良いのかも不明だ。
開発時には通ったが、本番運用時はアンマッチエラーを吐くなんてことも頻発する。ロボットに任せっきりにしたいはずなのに、ちょくちょく止まっていないか確認しなければならない。
私のイメージでは「画像マッチング」は割と最後の手段的なイメージがあったのだが、かなりの頻度で利用しないとシナリオ作成が成り立たないような状態になっている。
複雑なエラーハンドリング
RPA はシナリオ実行中に予期しないエラー（指定のファイルが存在しない等）が発生するとそこで処理を終了してしまう。
「だったらそのシナリオ再実行すればいいじゃん」というレベルの業務であればそれでもいいんだけど、中にはリトライが許されないクリティカルな業務や、シナリオの実行時間自体が無視できないほど長かったりするものもある。そもそもエラーが発生していないかどうかを人がちょくちょく確認しなければならないこと自体がイケてないので、原則として予期しないエラーは起きてはならないということを前提とする。
モダンなプログラミング言語であれば例外機構を備えているのでそれで対応できるが、RPA の場合そのような機構は存在しないので、一つ一つフローチャートにエラーの分岐を記述していかなければならない。少し想像して貰いたいのだが、正常系のフローと異常系のフローが入り乱れたうえに凄まじく長大なフローができあがる。
実際のところそこまでやるのは不可能だ。
結局 VBS かよ
RPA には色々な処理が用意されているが、それでも対応できない場合は VBS を書くことで対応することができる。逆に言うと VBS で書かないと対応できない処理が多数あるということだ。
例えば「昨日の日付を取得する」という処理も VBS が必要になる。これくらいできないの？とも思うが、このレベルで VBS のお世話になるということは利用頻度は押して図るべしということか…
ていうか VBS 一択なの？辛すぎ…
これ直せるの？
シナリオはフローチャート形式で進んでいくが、ユーザーの一動作が一つのブロックとして記述されるので、わりと簡単な業務でも結構な長さになる。さらに処理の抽象化ができないので、パターンでの条件分岐があると似たような後続処理を何度も記述しなければならない。更にはエラーハンドリングも必要だし、画像マッチング判定や VBS も不可避であれば……これメンテできるの？
学習コスト
ノンコーディングと言われるけど
RPA はノンコーディングと言われているけど、ツールとして操作を習得するのは決して簡単ではなく学習コストは高いと感じる。少なくとも業務をフローチャートに起こす程度のスキルは必要だし、RPA が用意している処理コンポーネントもそれなりの数があるし、独自のルールを覚えたり、画像マッチングの勘所を抑えたり、もしかしたら VBA も覚えなければならないかもしれない。
プログラミング未経験者からすれば異論はあると思うが、少なくとも私の感覚から言うと RPA の使い方を習得するコストを考えれば、Python を覚えたほうがよっぽど早いのではないかと思った。
プログラミング未経験から Python を覚えるというのは言うほど簡単ではないと思うが、それでも RPA の方が簡単とは言い切れない。それほどRPA でのシナリオ作りは大変だ。ましてや Python であれば前述の問題点はほとんどクリアできる。
※別にPythonじゃなくてもいいんだけど、一番覚えるのが簡単そうだからPythonにした。JavaでもC#でもJavaScriptでもRubyでもなんでもいいんじゃない？ただVBSは将来性ないと思うよ…
誰がやるべきか
そもそもルーチン業務の自動化（シナリオの作成）って誰がやるべきなの？
ユーザー部門がやるべきか
ユーザー部門がやる場合、業務担当者が自分の業務に対して自力で自動化をすることになると思う。
では作られたシナリオの妥当性は誰が検証するのだろうか？担当者の上司だろうか？…恐らく作成されたシナリオの検証などされないのではないだろうか。
この記事にあるように、担当者自身が業務改善をできることが RPA の大きなメリットだと謳っている。半面、自分の業務範囲であれば自分でやってしまおうという内容だ。少なくとも、担当者が中心となって RPA シナリオを作り、ユーザー部門で共有し管理するという内容ではないはずだ。
担当者がルーチンワークとなる業務を自分でピックアップし、”自分流”のシナリオを作成して自動化する。確かに短期的には効果があるかもしれないが、そのようなシナリオが数多く作られた時、それらを管理しきれるだろうか？引き継ぎできるだろうか？メンテナンスできるだろうか？シナリオ作成者が最後まで面倒見てくれるだろうか…？
ユーザー部門が独自に RPA を使う場合、いわゆる”野良ロボット”を多く生んでしまうだろう、Excel マクロの乱立と同じ道を辿り、大きな技術的負債を抱えることは想像に難くないはずだ。
システム部門がやるべきか
ではシステム部門がやるべきなのだろうか？心情的には”Yes”なのだが、RPA はユーザー部門でも作れるという点が大きなメリットとして存在している。システム部門とのコミュニケーションコストを削ることで、短期でシナリオを作成したり PDCA を回して業務改善を小まめに行えるという点だ。逆にシステム部門が間に入るのであれば通常のシステム開発となんら変わりが無い時間や工数が発生してしまい、前述のメリットが得られないという事になってしまう。
また、シナリオがブラックボックス化してしまうのも問題だ。業務担当者から見たら「正常に動いて正しい結果は出しているように見えるけど、どうやっているかは分からない」ということになる。ある意味担当者が手を出せない領域になってしまうのだ。ここでエラーが発生したり業務の変更が発生したりすると、システム部門に問い合わせして改修してもらう必要がある為、前述のコミュニケーションコストが重く圧し掛かってくる。
それでもユーザー部門に好き勝手にシナリオを作らせるよりは、システム部門でシナリオの作成・管理はしたほうがいいと思う。だが、そこまでして RPA 化するメリットは本当に残っているのだろうか？
理想は Github？
もしかしたらユーザー部門がシナリオを作り、システム部門がレビューするという方式なら上手くいくかもしれない。Github のプルリクエストのようなイメージだ。
シナリオを変更する際もプルリクエストを送り、レビューし、承認されてマージされる。リポジトリでバージョン管理がされるので、わけのわからない野良ロボットも出ないということだ。
これ、イケるんじゃないか？
まあ、RPA のシナリオがバイナリで保存されるのであればダメだけどね。
自社システムならシステム改修を検討しよう
もし自社のシステムに対し RPA で自動化を図ろうとしているなら、それは本来自動であって然るべきということに気付くべきだ。
「RPA を導入したことで効率化が果たされた」のではなく、本来自社システムが効率的にやるべき部分を効率化しきれていなかったので「RPA がそのツケを払っている」のだ。
システム改修で自動化が果たされるのであれば一番真っ当な解決方法だと思う。確かにコスト（お金）は掛かるだろう、しかし永続的に安定的な自動化が実現できるなら決して高くはないはずだ。RPA なら安価で安易に解決できるよう見えがちだが、根本から正していくほうが結果的に近道なのだ。
ユーザー部門はやるなってこと？
私自身、ユーザー部門の担当者が自身の業務改善をするという点については肯定的だ。
担当者は様々なツールを使いこなさなければならないし、それらで業務を行ううえで改善点やムダな点を敏感に察知し、適切なアクションをとっていくことは非常に大事だ。ただそこで”場当たり的な自動化”を進めてしまうのは筋が悪いように思えるし、そのコストが安価でないのであれば尚更だ。
例えば、ある担当者が自身の業務フローを見直した時、冗長な作業が含まれていることに気付いたとする。ここで「RPA で自動化しました」だと「それって将来的に大丈夫なの？」と思ってしまうが、「業務フロー自体を組み替えて冗長な作業を不要にしました」であれば非常に素晴らしいと思う。
“非効率な業務を変えないまま自動化“ではなく”効率的な業務に変えてしまう“ことのほうが遥かに価値があるはずだ。
さいごに
改めて言うけど、ある製品を使っての感想なので、世の中の RPA 全部が全部ここまで酷いとは思っていない。
だからこれらの問題がそもそも無い RPA を使ったり、もしくは問題を認識したうえで回避できるのであれば上手く活用できればいいと思う。自社で導入した RPA も大きな技術的負債になったとは思っているが、今時点で全く効果が出ていない訳では無い。
しかし RPA はライセンス形態にもよるが最低でも 100 万は超えると思って間違いはないので、決して安い買い物ではない。導入を検討する場合、是非試用版なりで実際使ってみることをオススメしたい。その上で思ってたのと違うとならないように、よくよく検討して貰えればいいと思う。
そう、効果が無いわけではないんだ。ただこの改善をするのに本当にウン 100 万の投資が妥当だったのか？や、システム化したほうがシンプルかつ保守性も高くできたんじゃない？とか、1 年後、2 年後もちゃんと動くのだろうか？とか、モヤモヤが尽きないわけです。