ピタゴラスイッチ目線で考えるRPA開発

前回は、RPAが自動化対象アプリケーションをどのように操作しているのかについて説明しました。自動化の方式によって、開発生産性、処理スピード、同一マシン上での人間の操作可否などがどのように変わるのかを確認しました。

3回目となる今回は、RPAの開発／運用の効率性を高めるためのアプローチにフォーカスしようと思います。

ロボットの動きを何かにたとえるなら……

想定どおりにRPAが動いてくれるのは気持ちがいいものです。それはドミノ倒しが成功した時の感覚、あるいはNHKの幼児向けTV番組「ピタゴラスイッチ」を見ているときの感覚に似ています。

ドミノ倒しやピタゴラ装置（番組に登場するからくり装置）はいずれも、最初のきっかけを人間の力が与え、後の動きは全て連鎖的に引き起こされます。特にピタゴラ装置の場合、紙コップ、割り箸、クリップなど、身の回りの物で組み立てられていることが、RPAにおける「簡単な部品」の組み合わせで処理を定義していく様子に似ています。

ドミノ倒しやピタゴラ装置には、「始まり」と「終わり」があります。RPAにも、処理の「開始」と「終了」があります。このエンドツーエンドの動きを作成するには、どのようなアプローチが考えられるでしょうか。

RPAの作成単位は?

ドミノ倒しやピタゴラ装置では、最終的には1つの”一連の動作”が完成します。しかし、その作成過程は、必ずしも始まりから終わりまでの順番どおりである必要はありません。

大規模なドミノ倒しでは、「ストッパー」と呼ばれる器具を使って作成単位を分けます。これによって、1つのドミノを複数人で並べたり、並べている途中でのミスの影響範囲を限定したりすることが可能となります。つまり、独立した部品をそれぞれに定義していくイメージです。

RPAの開発においても、これと同様の手法を取ることができます。例えば、ロボットの処理内容を複数に分割して部品化することで、作業効率を向上させられます。また、部品間の依存関係をなくすことで、エラーの影響範囲を最小限に留められるのです。

RPA自体の巨大化は是か、非か

では、RPAそのものの巨大化は、果たして許容されるべきでしょうか。

この問いは、「業務プロセスの途中で、超巨大なドミノ倒しやピタゴラ装置を挟むべきか」という問いとほぼ同等であると筆者は考えます。

言うまでもないことですが、ドミノ倒しやピタゴラ装置は、そのプロセスが長くなればなるほど、途中で止まるリスクが増大します。現実世界のドミノやピタゴラ装置の周囲では、空気の流れがあったり、わずかな振動があったりして、条件が常に一定ではないためです。また、ドミノ牌やピタゴラ装置を置くのは人間ですから、初期条件は毎回異なります。

ドミノ倒しやピタゴラ装置のような力学的な作用を、デジタルな世界のRPAに押し広げる発想はナンセンスだと思う方もいらっしゃるかもしれません。しかしデジタルな世界でも、突然ウイルススキャンソフトが動き出してアプリケーションの応答が遅くなったり、複数プログラムがOS上で実行される際の内部コールの実行順は常に一定とは限らなかったり、OS起動直後と、しばらく経ってからの状態とでは、起動したアプリケーションの状態が異なったり……と、力学的な世界と同じようにさまざまな現象が発生します。そのため、RPAのプロセスに関しても、長くなればなるほど、停止リスクが増大すると言えるのです。

ドミノ倒しやピタゴラ装置であれば、失敗した箇所やその原因は見ればすぐにわかります。一方、デジタルな世界にあるRPAでは、エラーで停止した箇所やその原因を知るには調査が必要です。

さらに、巨大なRPAでは、定義内容が知らず知らずのうちに「ブラックボックス化」してしまい、問題の解析をさらに困難にします。

こうしたことから、「個々のRPAのサイズは可能な限り小さくしておくべき」だと言えます。

RPAが業務全体のハブになるのはNG!

開発／運用効率の観点から、RPAの部品化が必要であり、さらに個々のRPAのサイズは小さいほうが良いことがわかりました。

それでは、この(多数の小さな)RPAを使ってエンドツーエンドのプロセスを実現するには、どのようなアプローチを取るべきでしょうか。

最も有効な方法として、ワークフローエンジンなどの「外部の仕組み」からRPAを呼び出すことが考えられます。この「外部の仕組み」に対して、各RPAが実行結果を報告したり、途中でエラーが発生した場合にはその旨を通知したりします。データの集計や突合処理、例外処理などは、RPA自身ではなく外部の仕組みで巻き取ることも検討できます。

また、RPA単体では、何がどこまで進み、どういう処理変遷をたどったのかがわかりづらいというデメリットがあります。ステータス管理や監査証跡取得などは、外部の仕組みに頼るのが得策です。

ロボットが単独で動作するのではなく、わざわざ「外部の仕組み」に状況を通知するというのは、一見非効率にも見えます。しかし、実際のプロジェクトでは、ロボットそのもののロジックが肥大化して運用やトラブルシュートが困難になってしまう事態が数多く発生しています。「外部の仕組み」を有効活用し、開発／運用コストを下げ、軽やかにRPAを導入したいものです。

全てをRPA化する必要はない

RPAのことだけを考えていると忘れがちですが、RPAは、費用対効果を考えると、(バリエーションが少なく実行頻度が高い)正常系処理を中心に作り、(バリエーションが多く実行頻度が低い)異例パターンやエラー処理は、RPAで100%実装するのではなく、人でカバーすれば十分である、という考え方もあります。このとき、RPAと人の処理を繋ぐための「オーケストレーター」的な役回りは、ワークフローなどのRPA以外の仕組みに頼ることができます。

*　*　*

RPAの「部品化」と「最小化」、そして「外部の仕組み(ワークフローなど)の導入」は、システム設計の根幹に関わる部分です。これらを開発着手後に変更することは極めて困難と言えるでしょう。開発着手前の段階で、関係者の合意を得ておくことが、プロジェクトを成功に導くカギとなります。RPAの巨大化が原因で、本来は避けることができたはずの無用なトラブルがプロジェクトに降りかかることのないよう注意すべきです。