「素人が作るRPAロボット」と「プロが作るRPAロボット」の違いとは？

まず最初に定義を確認したいと思います。

RPAというのは、本来、「ロボットを使ったホワイトカラー業務の自動化」という概念の話です。

しかし、一般的にはRPA＝RPAツールといった捉え方をされる場合がとても多いです。

そして、RPAツールから生み出されるものが「ロボット」です。

この「ロボット」は、RPAツールによって呼び名がそれぞれです。

あるツールでは「シナリオ」と呼ばれ、またあるツールでは「プロセス」と呼ばれたりもします。

私が勤めていた会社では、「RPAロボ」という名前で統一されていましたね。

さて、ここでは「ロボット」ということで進めていきたいと思います。

独学でRPAのロボットを作ることは無理なのか？

ロボットに対しての私の主張は、「RPAツールを販売・開発している会社は、ロボット作成が簡単で、ノンプログラマーでもすぐ使えると言いますが、それは嘘です。」といったものです。

とはいえ、独学で使えるようにはならないのか？と言われれば、そうでもありません。

実際、私もかなり時間が掛かりましたが、当初は独学である程度のところまで使えるようになりました。

センスのある人であれば、もっと早く使えるようになるでしょう。

しかし、プロとして現場に入り、熟練の人から学ぶようになると、独学の限界をすぐに知るようにもなりました。

では、どういった点が「独学の限界」なのでしょうか？

・ロボットが止まりやすい

・引継ぎが困難である

・トラブル発生時の対応が上手くできない

・トラブル発生時の原因把握に時間が掛かる

・他ロボットへの転用がしづらい

「とりあえず動けばよい！」というロボットであれば、時間を掛けながら、なんとか出来ることも少なくありません。

分岐や繰り返しが少なく、全体の行数もさほどではないシンプルなものなら、勘の良い人ならマニュアル片手に出来るでしょう。

しかし、RPAで作るロボットは、ちょっとした外的環境ですぐエラーを起こして止まるという性質があります。

「それは仕方ないじゃん！」という面もあるのですが、一方、プロが作るロボットには、現場の知恵といいますが、細かな配慮がされており、極力止まりづらいテクニックが盛り込まれています。

エラー発生時、つまりトラブル発生時の対応をマニュアル化することは必須です。

会社の中でのロボット作成は、個人が趣味で作成するのとは訳が違います。

特定の作業が１日行われないだけで、損失に繋がるというケースは少なくありません。

ロボットも、コンピュータ上で動くものですから、一定の確率で故障すると考えて間違いありません。

ロボットの修正で簡単に復旧できるものもあれば、コンピュータが物理的に壊れることもあるでしょう。

場合によっては、ネットワークが不通になり、作業が行えないという自体になるかもしれません。

そんな時には、急ぎの案件は手作業で行わなければなりません。

しかし、現在行われている手作業を自動化することにより、その手作業がブラックボックスに放り込まれてしまい、数年後、数十年後には社内の誰もやり方が分かる人がいないという状態になることが往々にしてあり得ます。

こういった運用システムを構築せずに、RPAツールを使おうとすると、「野良ロボット」を含め、大きなトラブルの種になりえるという訳です。

かといって、最初にRPAツールを導入した素人の人を責めるというのは、可哀そうです。

システム構築の経験がない人に、メンテナンスを含めた社内システムを構築するのは、極めて難しいと言わざるを得ないからです。

あと独学で作成すると、どうしても「非効率なロボット作成」になってしまいがちです。

RPAでは、通常のプログラミングと違って、簡単・短時間にロボットが作れるとは言うものの、それなりに時間が掛かります。

その時間短縮の為に、一度作ったロボットから、共有パーツを使いまわすという工夫/発想が大事になってきます。

これは大規模なロボットになるほど、重要度が上がってきます。

また、時間の経過とともに、その共有パーツは洗練されてきますから、最新版のひな型としてバージョンアップし、全員が用いるような社内システムも必要とされます。

一人でやっているうちは良いのですが、複数の人でロボット作成を行うようになると、ファイル管理がとても重要な仕事となってきます。

一度作成し、本稼働させたRPAロボットは、その会社にとっての大事な『資産』となります。

決して紛失しないようにしなくてはいけません。

天変地異の可能性も考慮して、クラウドサービスとの併用なども考え、BCP（Business Continuity Planning)対策として対応しておきたいところですね。