RPAは止まるのが前提!?

前回は、RPAを適用すべき業務エリアの正しい選び方について説明しました。RPAプロジェクト成功には、「業務分析の実施」「業務プロセスの見直し」「プロジェクトのガバナンス確保」の3つの要素が必要であることをお伝えしました。

5回目となる今回は、RPAの業務継続性に対する考え方について解説します。

RPAのSPOFを回避せよ

映画「インデペンデンス・デイ：リサージェンス」をご覧になった方はどのくらいいらっしゃるでしょうか。この映画では、女王エイリアンが倒されると、他のエイリアンたちも次々に墜落していくという、まさにSPOF(Single Point of Failure, 単一障害点)と言えるような状況が発生しています。この手の設定はSF映画で使われることが多いと思います。

一般に、SPOFは多重化／冗長化で回避するのが定石です。しかし、映画のなかで親玉は唯一無二の存在として出てくるため、「親玉を多重化すればいいのに……」という発想にはなかなか至りません。

RPAの世界でも、映画と同じように、親玉(コントローラ)に相当するサーバが、各RPAに指示を出しているケースがあります。そのような場合に可用性を確保したいのであれば、迷わずコントローラを多重化すべきでしょう。

それでは、RPAにおける業務継続性は、一般にどのように整理したらいいのでしょうか。

RPAが止まる原因の大半は、システム障害ではない

システム障害によって、RPA関連プロセスが落ちることはまれです。では何が原因になるかと言うと、その大半はアプリケーションエラーです。

アプリケーションエラーには次のようなものがあります。

• 待機時間を超えてもアプリ画面が遷移し終わらなかった
• 読み込んだファイルに不備があった
• 人が割り込んで誤操作した
• パスワードが変わったのでログインに失敗した
• 対象アプリのUIが変わった
• データパターンが想定外で処理を継続できなくなった
• 想定外のエラーポップアップが出て処理を継続できなくなった

アプリケーションエラーは、システムの可用性を高めても解決しません。エラーが発生した後の運用ルールを事前に策定した上で対応する必要があります。

アプリケーションエラーに対する具体的な対応方法としては、次のものが挙げられるでしょう。

A. 処理をRPAがロールバックする(→この処理にも失敗した場合には人間が対応)
B. 処理をRPAが再実行する(→この処理にも失敗した場合には人間が対応)
C. 処理を人間がロールバックする
D. 処理を人間が再実行する
E. エラーの状況を人間が確認し、人間が必要な対処方法をその都度考える

エラーが発生した場合の影響範囲(対象アプリケーション／対象データの範囲)を事前に洗い出しておき、上記AやBに収束できることが望ましいところですが、運用上C, D, Eがそれほど大きな負荷にならないのであれば、アプリケーションエラーへの対応をことさらにRPAに頼る必要も無いかもしれません。

アプリケーションエラーの発生に気づいたり、エラー発生後の指示を出したりする部分は、RPA外部の仕組み(ワークフローなど)に頼ることで、システム全体の見通しを良くすることもできます。

システム障害観点での業務継続性

いわゆるアプリケーション・サーバやデータベース・サーバであれば、わずかなダウンタイムも許されないミッションクリティカルなシステムが多いかもしれません。

しかし、RPAでは通常、数分程度のダウンタイムが許容されないような状況はほとんど発生しません。その理由は、業務そのものは重要であっても、ロボットの処理は通常非同期で実行されるため、数分程度のダウンタイムは問題にならない場合がほとんどだからです。

その意味で、RPAにおける業務継続性確保では、待機用のマシンを1つ確保しておき、適切に切り替えが行えるようにしておけば十分であると言えます。待機用のマシンを用意しておくことをここでは「多重化」と呼ぶことにします。

それでは、この「多重化」の対象にはどのようなものがあるでしょうか。

業務継続性観点でのRPAの分類

一口に「RPA」と言っても、世の中にはいろいろな種類のRPAが存在します。

RPAの分類方法は数々ありますが、業務継続性を考えるにあたって、ここでは2種類のRPA、「コントローラとスレーブに分かれた構成となっているもの(以降、コントローラ - スレーブ型)」と「各ロボットが自立して動作するもの(以降、自立型)」を取り上げます。

なお、自立型のなかには、RDA(ロボティック・デスクトップ・オートメーション)と呼ばれる、1つのマシン上で人間とロボットが協業するタイプのものも含まれます。

コントローラ - スレーブ型RPAの業務継続性

冒頭で触れたSF映画の例が、まさにこのコントローラ - スレーブ型です。

この構成で業務継続性を確保するには、コントローラとスレーブの双方を多重化する必要があります。

多重化すべきポイントが多い点がデメリットに見える一方、この構成は、コントローラさえ堅牢であれば、スレーブが落ちても業務が継続しやすく、優れているという捉え方もできます。

自立型RPAの業務継続性

自立型RPAの場合には、単にRPAがセットアップされたマシンを複数台用意すれば業務継続性を確保できます。

なお、RDAの場合には、ユーザーが利用するPC上でロボットが稼働しているだけなので、代替マシン上にロボットをセットアップして業務を継続すれば十分でしょう。

管理ツールの業務継続性

ロボットの導入が進んでくると、数百のロボットにタスクを割り振ったり、数百のロボットの進捗管理をしたり、数百のマシンにロボットの定義を配布したり……といったことが必要になります。これを可能とするために、多くのRPAベンダーがRPAの管理ツールを提供しています。

上述のコントローラが、この管理ツールの機能を兼ねている場合もありますが、自立型RPAでは、管理ツールが必要になります。

この管理ツールについても、業務継続性の検討が必要です。ここでは、管理ツールのシステムアーキテクチャに応じて、必要な箇所を多重化することになります。

*　*　*

ここまでRPAの業務継続性について説明してきましたが、いずれにせよ重要なのは「RPAが停止することを前提に業務を設計する」という点です。RPAは、対象アプリの例外的な挙動や、想定していなかったエラーの発生などによって、停止することがあります。筆者は、RPAはある一定頻度で停止することを前提に利用すべきであると考えています。

各RPAの「状態管理」には、停止しないことを前提とできる外部ワークフローなどの仕組みの利用が有効です。例外処理についても、RPA内部ではなく、そうした外部の仕組みから起動するかたちが理想的かもしれません。

ワークフローなど外部の仕組みを導入することの利点については本連載でも何度かお伝えしていますが、業務継続性の観点からも有効なアプローチになることがおわかりいただけたのではないでしょうか。