第1回の再掲となるが、ロボは外部環境と連動を図り、データをやりとりしながら作業を進める（図1）。従って外部環境との連動を考慮しきれないままロボを開発した場合、ロボの停止や誤作動などのトラブルが発生し、ロボが関わる業務自体が滞ってしまう可能性がある。

図1　ロボと外部環境との連動

　これらの“ロボトラブル”は、大きく以下の4つに分けることができる。回避するためには、ロボの開発段階で打っておくべき対策がある。具体例を交えて説明しよう。

表1　4つのロボトラブルに対する原因

1.「ロボが止まる」その原因と対策

　「ロボが止まる」とは、動作中のロボが停止してしまう事象のことだ。ロボが停止すると、そのロボが担っていた業務自体が滞る。場合によっては顧客にも影響が及ぶかもしれない。このようなトラブルが頻出すると、重要な業務をロボに任せられず、ヒトはいつまでも業務から離れられない。

図2　月次の給与振込事務のロボが止まる例

　例えば、月次の給与振込作業をロボ化した図2のフローでは、2の行程で振込先情報を取得するロボが停止すると、その後の作業にも影響が及び、振込が滞ってしまう。根本的な原因は、多くの場合、そもそもロボ開発の担当者に「止まりにくいロボ」を作るという発想が抜け落ちていることにある。

　「止まりにくいロボ」を作るポイントの一つは、ロボに操作する対象、すなわちオブジェクトを認識させる方法だ。例えば、図2の「2.振込先情報取得」では、ロボが振込先情報画面の「ダウンロードボタン」を押すことで振込先情報を取得している。図3ではその工程を分解し、抜き出した。このロボの開発の時点では、ロボが押す「ダウンロードボタン」というオブジェクトをどう認識させ、操作させるかが重要だ。

図3　振込先情報取得の操作方法

　この場合では、一般的に表2に挙げるa～eの5通りの方法が考えられる。どれが好ましいか分かるだろうか。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

表2　オブジェクトコントロールの指定パターン

　これらの方法はそれぞれ特性が異なる。a、b、cの方法はPC画面など、変化が起きやすい外部的なオブジェクトをコントロールする手法であるため画面の解像度やUIの変化、ロボが参照するPCにウイルスソフトなど外部プログラムの割り込みがあるだけでロボが停止してしまう可能性がある。対してd、eの方法は、システム内部からオブジェクトをコントロールする手法であるため、ロボはより精度の高いシステム操作が可能となる。つまり、この場合選択すべきオブジェクトコントロールの指定方法はd、eだ。このように、ロボの操作対象となるシステムの種類によって内部コントロールができない場合などを除いては、オブジェクトを内部システムからコントロールするようロボを開発すると良い。

　以上はあくまで一つの例であり、「止まりにくいロボ」を作るためには、ロボが動作する環境やユーザーの業務の進め方、扱うデータパターンなどに従って、幾つかのポイントを抑えなければならない。以下は具体例だ。

• ロボの開発環境と本番環境の処理スピードの差を考慮し、影響を受けないような作りにすること
• ロボが動作する環境の設定情報を管理しておくこと
• 一連の業務の中でロボが同じ作業を複数回行う場合は、全ての作業を同じ作りにしておくこと

　どのような現場でも、ロボの開発時にはそれぞれのロボの特性を理解し、「止まりにくいロボ」を作るためのルールや開発指針など、共通認識となる規約を用意しておくと良い。ロボ開発の過程の中で「ロボが止まる」事象と原因、回避策などを取りまとめて蓄積することも忘れてはならない。

2.「ロボが誤動作する」その原因と対策

　「ロボが誤動作する」とは、本来想定しているものとは異なる動作で、ロボが業務を遂行しまう事象である。ロボの誤動作の内容によっては、業務が間違った方法で進んでしまい、後でヒトがその間違いを修正せざるを得ない状況に陥ることもある。このロボトラブルもやはり、業務自体が滞るだけでなく顧客への影響を与える可能性が大きい。

　経費精算の例に沿って説明しよう。ロボは提出された経費情報をもとに振込情報一覧を作成するよう作られている。しかし、ロボが処理をすべきデータに通常とは異なる例外的な経費精算書類が混ざっており、これにロボが気付けない（例外的なデータであるということを検知しなかった）場合、ロボは誤った動作をしてしまう可能性がある（図4）。

　仮に、ロボが誤動作によって振込先や振込金額を間違えた場合、企業の信用問題や、金額的な損失を与える大きな事故につながることは容易に想像がつく。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図4　誤った振込情報が混入

　このような事例は、「例外的な業務パターンの考慮漏れ」が根本的な原因である場合が多い。ロボを作る際に通常業務の流れにとらわれ、例外業務をどのように対処するかを事前に設計しきれていないのである。ロボを開発する際には、通常のフローとは異なる例外が発生した場合に、ロボが取る対応を事前に決めておくことが重要だ。SHIFTで活用している、例外的な業務パターンの一覧を例として提示する。以下の一覧では、操作やシステムに関する大、中、小の分類ごとに、異常または例外的な観点が細かく抽出されている。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

表3　異常系・例外系の観点一覧

　一覧の作成方法を、より具体的に解説しよう。はじめに、ロボの要件を決めるために、ロボにとって例外的な処理となるケースを漏れなく洗い出す。ロボが業務を行う最小単位ごとに、想定される例外ケースを書き出すと良いだろう。前述した経費精算処理の例では、異常系の観点として「振込情報一覧のファイル名がヒトの手によって変わってしまっている」「振込情報一覧と既に同様のファイルが開かれている」「振込情報一覧のファイルが存在しない」などが挙げられる。初めから全てを列挙することは難しくても、メンバーが直面したエラーを集約していけば非常に有効な資産となる。さらに、表を作成する際には、観点ごとに影響の大きさに応じて、優先度も記載しておくと良い。

　また、ロボの誤作動を避けるためには、ロボの業務結果がリリースされる前に、ヒトの目で最終チェックをすることも有効だ。ロボの開発規模、要件の複雑度にもよるが、ヒトによる最終チェックだけでなく、ロボのイテレーション開発（反復開発）を行うことでフォローできる場合も多い。このようにロボが誤動作する原因を理解し、事前の対策を打つことが重要だ。

3.「ロボ停止に気付けない」その原因と対策

　「ロボ停止に気付けない」とは、ロボが停止した際に、ユーザー側でそれを検知する仕組みがなく、業務が止まってしまう事象である。ロボはヒトが使う端末とは別の、ロボ専用端末で動くように設定されている場合が多い。ヒトはロボ専用端末の画面や動きを都度確認しているわけではないため、あるロボが停止したことに気付かなければ、次のロボが作業を行ってしまう。これによって、処理が正しく完了しないといったエラーが発生する。また、ロボの停止に気が付いたとしても、そのタイミングが遅れれば、予定のスケジュールから遅延が発生することになる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図5　ロボ業務の現場

　ロボを開発する際には、ロボが停止したことを検知し、ヒトにアラートを鳴らす仕掛けも併せて用意する必要がある。処理するデータや、関連する操作に例外があった場合、ロボは大きく以下の二つの理由で止まってしまう。

1. 例外に対応できず、処理を停止する
2. 正しいデータを取得するまで、待ち続けてしまう

　（1）はロボ自身が停止することを認識できるため、エラー時にメールを通知するようにロボを設定すればよい。一方、（2）は、厳密にはロボは停止しているわけではない。そのため、ロボ自身がエラーを認識することが難しく、ロボを監視する仕掛けが必要となる。一般的に、ロボの監視には「ロボ管理ツール」「ログ監視ツール」「BPM」などを活用する。これらの中から適切なものを選んで、ロボが正常に動作しているかのプロセス監視を行い、一定時間待機した後にタイムアウトをした際にはアラートを鳴らす仕組みなどを構築したい。

4.「ロボを再実行できない」その原因と対策

　「ロボを再実行できない」とは、ロボが停止した際、ロボの再実行をユーザーの手で行うことが難しく、システム担当者の対応が必要になってしまうような事象を指す。現場でロボを活用するのはユーザーであるため、本来はユーザー自身が停止の原因を取り除き、再実行できるような状態にしておきたい。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図6　ロボの再実行をする際に問題が発生する例

　まずは、望ましくない例から説明する。図6では1台のロボが1～4の一連の作業を自動化している。「4.振込一覧送付」時にロボが停止した場合、再稼働の際には、「1.給与情報取得」から再び業務をスタートしなくてはいけない。ロボは一連のフローの途中から作業をスタートできないためだ。そうなると振込情報一覧が二重に作成され、再稼働したことでまたロボが停止あるいは誤動作を起こす可能性がある。

　スムーズに再稼働させるためには、ロボを開発する前段階で、できる限り小さな作業単位で分割して設計することが重要だ。具体例も交えながら解説しよう。まず、図7のフローに対して、業務単位ごとにロボを分業化してみる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

図7　ロボ業務を再実行しやすい小さな作業単位に分割した例

　この場合、「4.振込一覧送付」の時点でロボが停止をしても、4の工程内で作業のやり直しが可能だ。このように、作業単位、言い換えると機能単位でロボを開発することで、再稼働が容易になる。ロボの分業をイメージしながら1ロボの作業範囲を決めていくことが重要だ。

　ロボの分業化は、「ロボの再利用性」という観点でも生きる。業務をRPA化する際には同様の作業を行うロボットを何度も必要とする場合が多い。RPAツールの種類によっても、多少方法は異なるが、ロボを可能な限り小さな作業単位に分割しておけばロボの再利用性が高まる。さらに、運用保守時にも第三者がメンテナンスしやすい。

　また、ユーザー自身がロボを再実行するには、運用の設計も肝となる。基本ではあるが、実際の現場では見落とすことが多い。本稿では詳述しないが、ロボの再実行手順、問い合わせフローの整備も検討が必要だ。

ロボに影響を与える外部環境の変化

　以上では、ロボの設計・開発の工程で抑えるべきポイントを、代表的な4つのロボトラブルに沿って解説した。最後になるが、ロボトラブルの中でも「ロボが止まる」「ロボが誤作動をする」という事象は、今回説明した理由だけで起こるわけではない。例えば、ロボが操作する対象のシステム自体に変更が起こる場合など、取り巻く外部環境の変化によって、ロボが止まってしまうことも多々ある。

　表4では、外部環境の変化として代表的なものを記した。少々専門的な内容になるが、この例を見れば、一般的なシステムの際の保守・運用の内容と近しいことを検討する必要があると分かるだろう。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

表4 ロボに影響を与える外部環境の要素

　ロボは一般的なシステムより外部環境との連動が多いため、変化にはことさら影響を受けやすい。外部環境の変化に強いロボを作るために、RPAツールやRPAが動作する実行基盤、またRPAが操作する対象のシステムなどを変更する場合にはロボに影響が無いか見極めが必要だ。それだけでなく、表4の要素に関わる運用プロセスを、ロボのリリース前に整備しておきたい。この詳しい内容については、また改めて解説の機会を持ちたい。

　今回は、RPAを活用した業務自体の停滞につながる、ロボのトラブル回避策について開発のポイントを絞って解説した。次回は、これらのポイントと開発の効率性向上という観点も交えて、ロボ開発の望ましいプロセスを紹介する。