【第4回】"怠け心"こそ進歩の源泉?【第6回】RPAの「先」にあるもの一覧はこちら前回は、RPAを適用すべき業務エリアの正しい選び方について説明しました。RPAプロジェクト成功には、「業務分析の実施」「業務プロセスの見直し」「プロジェクトのガバナンス確保」の3つの要素が必要であることをお伝えしました。5回目となる今回は、RPAの業務継続性に対する考え方について解説します。RPAのSPOFを回避せよ映画「インデペンデンス・デイ:リサージェンス」をご覧になった方はどのくらいいらっしゃるでしょうか。単一障害点)と言えるような状況が発生しています。この手の設定はSF映画で使われることが多いと思います。一般に、SPOFは多重化/冗長化で回避するのが定石です。映画のなかで親玉は唯一無二の存在として出てくるため、「親玉を多重化すればいいのに......」という発想にはなかなか至りません。RPAの世界でも、映画と同じように、親玉(コントローラ)に相当するサーバが、各RPAに指示を出しているケースがあります。そのような場合に可用性を確保したいのであれば、迷わずコントローラを多重化すべきでしょう。それでは、RPAにおける業務継続性は、一般にどのように整理したらいいのでしょうか。RPAが止まる原因の大半は、システム障害ではないシステム障害によって、RPA関連プロセスが落ちることはまれです。何が原因になるかと言うと、その大半はアプリケーションエラーです。アプリケーションエラーには次のようなものがあります。待機時間を超えてもアプリ画面が遷移し終わらなかった読み込んだファイルに不備があった人が割り込んで誤操作したパスワードが変わったのでログインに失敗した対象アプリのUIが変わったデータパターンが想定外で処理を継続できなくなった想定外のエラーポップアップが出て処理を継続できなくなったアプリケーションエラーは、システムの可用性を高めても解決しません。エラーが発生した後の運用ルールを事前に策定した上で対応する必要があります。アプリケーションエラーに対する具体的な対応方法としては、次のものが挙げられるでしょう。Eがそれほど大きな負荷にならないのであれば、アプリケーションエラーへの対応をことさらにRPAに頼る必要も無いかもしれません。アプリケーションエラーの発生に気づいたり、エラー発生後の指示を出したりする部分は、RPA外部の仕組み(ワークフローなど)に頼ることで、システム全体の見通しを良くすることもできます。システム障害観点での業務継続性いわゆるアプリケーション・サーバやデータベース・サーバであれば、わずかなダウンタイムも許されないミッションクリティカルなシステムが多いかもしれません。RPAでは通常、数分程度のダウンタイムが許容されないような状況はほとんど発生しません。その理由は、業務そのものは重要であっても、ロボットの処理は通常非同期で実行されるため、数分程度のダウンタイムは問題にならない場合がほとんどだからです。その意味で、RPAにおける業務継続性確保では、待機用のマシンを1つ確保しておき、適切に切り替えが行えるようにしておけば十分であると言えます。待機用のマシンを用意しておくことをここでは「多重化」と呼ぶことにします。それでは、この「多重化」の対象にはどのようなものがあるでしょうか。一口に「RPA」と言っても、世の中にはいろいろな種類のRPAが存在します。スレーブ型)」と「各ロボットが自立して動作するもの(以降、自立型)」を取り上げます。RPA稼働マシンのみなお、自立型のなかには、RDA(ロボティック・デスクトップ・オートメーション)と呼ばれる、1つのマシン上で人間とロボットが協業するタイプのものも含まれます。この構成で業務継続性を確保するには、コントローラとスレーブの双方を多重化する必要があります。多重化すべきポイントが多い点がデメリットに見える一方、この構成は、コントローラさえ堅牢であれば、スレーブが落ちても業務が継続しやすく、優れているという捉え方もできます。自立型RPAの場合には、単にRPAがセットアップされたマシンを複数台用意すれば業務継続性を確保できます。RDAの場合には、ユーザーが利用するPC上でロボットが稼働しているだけなので、代替マシン上にロボットをセットアップして業務を継続すれば十分でしょう。管理ツールの業務継続性ロボットの導入が進んでくると、数百のロボットにタスクを割り振ったり、数百のロボットの進捗管理をしたり、数百のマシンにロボットの定義を配布したり......といったことが必要になります。これを可能とするために、多くのRPAベンダーがRPAの管理ツールを提供しています。上述のコントローラが、この管理ツールの機能を兼ねている場合もありますが、自立型RPAでは、管理ツールが必要になります。この管理ツールについても、業務継続性の検討が必要です。ここでは、管理ツールのシステムアーキテクチャに応じて、必要な箇所を多重化することになります。*ここまでRPAの業務継続性について説明してきましたが、いずれにせよ重要なのは「RPAが停止することを前提に業務を設計する」という点です。RPAは、対象アプリの例外的な挙動や、想定していなかったエラーの発生などによって、停止することがあります。筆者は、RPAはある一定頻度で停止することを前提に利用すべきであると考えています。各RPAの「状態管理」には、停止しないことを前提とできる外部ワークフローなどの仕組みの利用が有効です。例外処理についても、RPA内部ではなく、そうした外部の仕組みから起動するかたちが理想的かもしれません。ワークフローなど外部の仕組みを導入することの利点については本連載でも何度かお伝えしていますが、業務継続性の観点からも有効なアプローチになることがおわかりいただけたのではないでしょうか。Kanai)2012年11月より現職。ペガジャパンの親会社である米ペガシステムズ社が2016年4月にオープンスパン社を買収したことに伴い、同年6月よりRPAのプリセールス活動を開始。これまでの提案企業は50社を超え、導入検証、実プロジェクトでの実装経験もある。小さい頃から大きな車を運転することが夢だったため、学生時代に大型免許を取得。現在に至るまで活用シーンはなし。趣味はビール、ラーメン(主に二郎系)、映画鑑賞。(2000年4月~2012年11月)。本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。Ops』を意味します。人気記事をお届けしますダウンロードBOXに入れる記事をダウンロードBOXに追加します。よろしいですか?ブックマーク記事をブックマークに追加します。Corporation。