Dog:RPAでロボットを作る時、100%を目指さない方がいいって聞いたんだけど、本当?

Robo:えっ、誰に聞きました? まあ、本当かどうかと言われれば、本当です。

Dog:そうなの!? 理由はどうしてなの?

Robo:ちょっと語弊がありますが、正しくは「最初から100%を目指さない方がよい」です。

Dog:うーん、完璧主義の僕としてはさぁ…。

Robo:これはRPAだけでなく、プログラム全般に言われることなんですけど、いきなりユーザーにとって完璧なものを作ろうとすると、凄く非効率なんですよ。

Dog:そうなの?

Robo:はい、まず最低限の機能を付けて、そこに追加、もしくは例外処理を盛り込んでいくのが王道なのです。

 

■完璧(完全)であることを要求されるもの

RPAに限らず、IT業界において、完璧というはありえません。

エンジニアは完璧を目指して設計・運用を行っていますが、どんなシステムも結果として完璧はあり得ないのです。

つい最近では、Amazonのクラウドサービスが数時間停止しました。(原因はコンピュータの冷却装置故障とのこと)

世界トップレベルの専門家が集まって構築したシステムですが、それでも日中止まり、日本の有名企業のサービスもそれに伴い止まり、大騒ぎになりました。

こういった「インフラ」関係は、その利用目的上、限りなく完璧であることを要求されます。

 

機械は壊れるものである。

このことを想定しながら、大事な個所は常に二重化、場合によっては三重化して、迂回ルートを物理的に作っていきます。

データセンターなどの建物も、震度7程度は想定して、免震構造はもちろん、引き込む回線も2経路から入れたりと故障確率を限りなくゼロに近づける努力がされているのです。

それでも、Amazonのように想定外の個所が故障することにより、結果としてサービスが停止することがあります。

我々は普段何気なく使っているサービスも、裏ではエンジニア達が綱渡りのように運用していることは少なくないのです。

いまやインターネット回線やサーバなどは、水道や電気と同じであり、企業にとっては死活問題ですから、仕方がないとも言えます。

 

 

■完璧であることを求めない方がよいもの

はい、こちらが本題です。

これに「RPA」が該当します。

誤解の無いように申し上げますと、「最初から完璧を求めてロボットを作成を検討しない方が良い」という意味です。

そもそもRPAは、今までプログラミング言語で書いていたものを、GUI(Graphic User Interface)と呼ばれるアイコンに置き換え、使いやすくしたものです。

なので、その工程はプログラミングとほぼ同じと言えます。

プログラミングを始める前には、「何を」「どうしたいか」ということをハッキリさせておく必要があります。

つまり、「スタート」と「ゴール」ですね。

それも曖昧な表現ではなく、誰が読んでも間違って理解されない表現で、細部まで行うことが大切です。

ここを明文化できなければ、ロボットを作成することはできません。

明文化できれば、「段取り8割」完了ですね。

 

あとはロボット作成の流れに落とし込んでいけば、「(とりあえず動く)ロボットは完成!」です。

「えっ!?動けばそれでいいのでは?」

と思われた方もいらっしゃると思います。

はい、動けばそれはそれで良いのですが、より精度の高いロボット、分かりやすくいえば、「100人が100人、100回動かしてもちゃんと動くロボットであるのか?」ということです。

そのロボットの作業に精通している人が動かせば、恐らく大丈夫でしょう。

しかし、パソコンに疎い人や新入社員のような人が操作した場合、思いもよらない操作を行うことがあります。

例えば、ロボットが作業の過程で、「該当のエクセルファイルを選んでください」と表示しているのに、なぜか間違って関係のない「ワードファイル」を選んでしまった!

こんなことが普通に起こります(苦笑)

 

そういった場合には、ロボットにどういった反応を起こさせるか?

上記は一例ですが、プログラムorロボット作成は、ただ動けばよいのではなく、例外発生の可能性と処理を潰していく作業も行わないといけません。

エクセルファイル以外は、選択フォルダに表示させない仕組み「*.xlsx」にするとか。

そうやって完成度100%に近づけていきます。

ただ。。。

場合によっては、現実問題としてロボットの精度を100%に出来ないものもあります。

入金チェックの消込などであれば、お客様が間違って振り込んでくるケースがあるでしょう。

ちょっと考えるだけでも、

①振り込手数料を引いた金額で振り込んできた

②振込人名義を法人ではなく、個人名で振り込んできた

③振込期限を過ぎて振り込んできた

④他サービスと合算で振り込んできた

といった具合に、全ての例外を挙げていくのは、大変です。

でも、100%にして、完全自動化を目指すのであれば、起こりえる全部のケースをプログラムに反映させる必要が出てきます。

それを追求しはじめると、ある意味終わりがなく、自己満足な仕事となってしまいますね。

では、どうすれば良いのでしょうか?

 

結論を言えば、「適当なところ落としどころを決めて処理する」ということなります。

上記の消込作業であれば、正規の振込手順・表示であるものだけ、ロボットやプログラムで自動処理する。

それ以外のものに関しては、「当日未確認振込」などとして、特定のエクセルシートに転記するようにし、後からスタッフが目視と手作業で消込を行うといった具合です。

残念ながら、今はまだそれが現実的な解になりますね。

という訳で、ロボット作成は下手に完成度を上げるよりは、業務フローで対応するのが現実的であることが少なくありません。

その分、こういった考え方を許容することで、より広い業務にRPAを導入することが可能になるはずです。