巷では「RPAの導入によって低コストで大きなコスト削減を実現」なんて文字が躍っていたりしますが、
至極もっともな話として導入すればうまく行くものなんて実際にはありはしません。
私の会社でも会社内の業務の自動化をRPAで進めてコスト削減なんてことを考えた人がいたようで
すったもんだの挙句、BizroboというRPAソフトを導入しました。
導入してみて初めて分かった諸々について以下に書き連ねていこうと思います。
RPAは万能ではありません。
割と普通に色々な所で言われているにもかかわらず、
上の方々はどうもなんでもうまく行くような幻想を抱いているようです。
RPAのソフトウエアには有名処だけでも数種類あり、それらの実装に関してもそれぞれ特徴があります。
実装方法によっては向いていない業務もありますし、逆に得意な業務もあります。
得意な業務に適応する場合、導入にかかる工数も小さく、効果も出やすい事になります。
逆に不得意な業務に適応してしまうと導入にかかる工数が膨れ上がり、最悪効果は雀の涙なんてことも。
導入時に自分の所の業務内容と導入するソフトの相性をきちんと把握しておかないとひどい目に合います。
（私のように）
Bizroboの実装内容
Bizroboは、元々ソフト内にWebブラウザと独自のExcelエンジンを持っています。
ホームページから情報を引き出してExcelに転記するような業務をターゲットにしていたようです。
その後、時代の要求にこたえる形でDesktop Automationという機能で他のソフトを画面上で操作する手段を追加しています。
このDesktop Automationという機能は画面に表示されているオブジェクトを解析してそのオブジェクトを操作するという方法で実現しています。
但し、この操作を言うのはマウスとキーボードを使用して操作する方法のみでオブジェクトをソフトウエア的に操作する方法が用意されていません。
また、Desktop Automation機能を使用する為にはその為のPCを別に用意する必要があり、外部のアプリケーションを操作する為には一つのロボットで二台のPCが必要になります。
で、二台のPCに分かれている以上、ロボット自体が動くPCと画面操作を行うPCの間はネットワーク接続されている必要があり、画面の解析結果や操作情報がネットワーク上でやり取りできる事が前提になります。
Bizroboの限界
ソフトの成り立ちからも想像が出来ますが、内臓のWebブラウザとExcelエンジンを使用して動かす分にはかなり使いやすいと言ってよいと思います。画面を操作するコマンドも豊富ですし、ソフトウエア開発に関する知識がなくてもロボットを組めると思います。
そこだけ見ると結構優秀に見えるのですが、いろいろやってみると問題が出てきます。
内蔵ブラウザはChromiumベースの物が標準で入っています。但し、EdgeともChromeとも実装が微妙に違う為、いろいろやり出すと表示がうまく行かないとか、EdgeやChromeではうまく行くのに内蔵だとうまく行かないとかそういう事が出てきます。
設定の変更等である程度は対応できますが、RPAテクノロジー自身が「同じものではないので」うまく行かないケースがあると言っていますので回避策がないケースはあると考えるべきです。
代替え手段はDesktop Automationを使ったEdgeやChromeを使っての操作になります。
内蔵WebブラウザがEdgeやChromeとの実装の違いを抱えているように内蔵の独自実装のExcelエンジンも同じ問題を抱えています。
Microsoftがバージョンアップする度に追加する機能に独自エンジンの実装が遅れる事になるのでうまく読み込めない、書き込めないというケースが出てきます。
読み込めない方も十分問題ですが、書き込めない方は最悪ファイルを壊してしまう危険性をはらんでいるので問題が大きいと言えます。
組み込みエンジンを持っているが故の優位性もあると思いますが、MicrosoftのExcelは相手にするには巨大すぎるというのが個人的な見解です。
切り札的に登場するDesktop Automationですが、こちらも実装に起因する問題を抱えています。
まず、ネットワークの影響を受けてしまうという部分です。
実際の作業自体はローカルで済むような場合でもロボットで画面を操作する為にネットワークが不可欠になります。
あと、これは特殊なケースになりますが、使用するアプリケーションが一度に表示する内容があまりに多い場合、画面の解析に時間が掛かり操作時の動きが非常に遅くなります。また、膨大な解析結果をロボットに送信する必要がある為、画面更新時の通信によるタイムラグは無視できないほど大きくなってきます。
これらの問題点はBizroboの実装に起因する問題なので簡単に解決できるものではありません。
ところが、一旦導入してしまうとおいそれとはやめる事が出来ない為、「何とかしろ」と言う事になって苦労する事になるわけです。
（実際にそうなっているわけですが）
画面が複雑になると使いにくいDesktop Automation
Desktop Automationは、マウスとキーボードを使用して操作する方法のみサポートしています。
ファイル周りの機能も入っていますが、その部分はアプリケーションの操作に直接関係ないのでこっちに置いておきます。
マウスとキーボードを使用して操作する方法のみと言う事が何を意味しているのかというと画面上に表示されていない物は操作できないと言う事です。
例えば、Edgeでホームページを表示して押したいボタンが画面の外にある場合、まずEdgeの画面をスクロールさせてボタンを画面上に入れる必要があります。
しかし、画面をスクロールさせるというコマンドは用意されていないのでスクロールバーを操作するか、キーボートを使ってスクロールさせる必要があります。これを実際に実装してみるとわかるのですが、とても遅いです。
それに一体何回操作すればよいのかもわかりません。毎回同じ回数で良ければともかく表示内容によって変わる場合は簡単にいきません。
ページの最後と分かっていれば余分に操作すれば済みますが、ページの途中にある場合はもはやお手上げです。
（実際には実装方法が全くないわけではないのですが、複雑な方法になると後々のメンテナンス性が悪くなります）
Desktop Automationを使ってExcelを操作すれば、内臓のExcelエンジンを使った時のような問題はないのですが、
ここでも「マウスとキーボードを使用して操作する方法のみ」という点が色々と影響してきます。
Excel上での実際の操作をよく考えてみると実は単純な操作ではうまく行かないケースがあちこちに出てきます。
例えば、セルからはみ出すような文字列が設定されているとします。
この状態でそのセルを選択して何らかの編集を行った後、そのセルのすぐ左にあるセルを直接選択する事は出来ません。
選択中のセルの文字列が上に被っているからです。この場合、一度セルの選択を解除する必要があります。
人間が使う場合は半分無意識に行っている操作を全て再現しないとExcelを確実に操作する事は出来ません。
操作対象のアプリケーションが複雑になってくると「マウスとキーボードを使用して操作する方法のみ」では対応が難しくなってきます。
RPAソフトを導入する時は向き不向きをよく検討してから
ここまでBizroboの実装に起因する愚痴をつらつらと書いてきましたが、
Bizroboの実装が私の会社の作業に不適合だったと言うだけでいかなる場合でも問題が起こるというわけではありません。
開発者ががっつり作成しないと自動化できないような物に関してはBizroboは向かないと思います。
現場の担当者が簡単に作れて単純作業を任せてしまえるというような業務であれば向いています。
あまり複雑な事をさせようとせずに単純作業だけど回数がものすごく多いというような業務に小規模なロボットを適応するのがBizroboの本来の使い方ではないかと思います。