RPAは止まるのが前提!?

【連載】

はじめてのRPA導入 - 真の有効活用の指針とは?

【第5回】RPAは止まるのが前提!?

[2018/10/30 08:00]金井盛隆 ブックマーク ブックマーク

  • ソリューション
  • ● 関連キーワード
  • 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、「コントローラとスレーブに分かれた構成となっているもの(以降、コントローラ - スレーブ型)」と「各ロボットが自立して動作するもの(以降、自立型)」を取り上げます。

  コントローラ - スレーブ型 自立型
定義 RPA稼働マシン内にはRPAの定義情報を持たず、各RPAはコントローラに依存して動作 RPA稼働マシン内にRPAの定義情報を持ち、各RPAは自立して動作
ロボット配布 コントローラ側でRPAの定義情報を集中管理するため、RPA稼働マシンに定義情報を配布する必要がない RPA稼働マシン内にRPAの定義情報を配布する必要がある (自動配布も可能)
処理スピード コントローラとスレーブ(RPA稼働マシン)の間で常にやり取りが発生するため、処理スピードは相対的に遅い RPA稼働マシン内のロボットが自立して動作するため、処理スピードは相対的に速い
SPOF候補となるレイヤー コントローラとスレーブ(RPA稼働マシン) RPA稼働マシンのみ

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

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

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

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

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

自立型RPAの業務継続性

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

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

管理ツールの業務継続性

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

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

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

* * *

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

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

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

著者紹介


ペガジャパン株式会社
シニア ソリューション コンサルタント
金井 盛隆 (Moritaka Kanai)

2012年11月より現職。ペガジャパンの親会社である米ペガシステムズ社が2016年4月にオープンスパン社を買収したことに伴い、同年6月よりRPAのプリセールス活動を開始。これまでの提案企業は50社を超え、導入検証、実プロジェクトでの実装経験もある。
小さい頃から大きな車を運転することが夢だったため、学生時代に大型免許を取得。しかし、現在に至るまで活用シーンはなし。趣味はビール、ラーメン(主に二郎系)、映画鑑賞。
前職は日本オラクル (2000年4月~2012年11月)。2児の父。

連載目次

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

関連リンク

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします
4123
2
【連載】はじめてのRPA導入 - 真の有効活用の指針とは? [5] RPAは止まるのが前提!?
前回は、RPAを適用すべき業務エリアの正しい選び方について説明しました。RPAプロジェクト成功には、「業務分析の実施」「業務プロセスの見直し」「プロジェクトのガバナンス確保」の3つの要素が必要であることをお伝えしました。5回目となる今回は、RPAの業務継続性に対する考え方について解説します。
https://news.mynavi.jp/itsearch/2018/10/29/RPA_300_250.jpg
前回は、RPAを適用すべき業務エリアの正しい選び方について説明しました。RPAプロジェクト成功には、「業務分析の実施」「業務プロセスの見直し」「プロジェクトのガバナンス確保」の3つの要素が必要であることをお伝えしました。5回目となる今回は、RPAの業務継続性に対する考え方について解説します。

会員登録(無料)

注目の特集/連載
AI人材に必要なもの
DMM.make AKIBAから生まれたスタートアップたち
はじめてのRPA導入
教えてカナコさん! これならわかるAI入門
RPA入門
PowerShell Core入門
Swagger 3.0 入門
徹底研究! ハイブリッドクラウド
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

ページの先頭に戻る