はじめに

RPAの利用で困ったとき、どこに問い合わせをしているでしょうか？自社にRPAの保守運用チームがある場合、トラブル時の即時対応がしやすく頼りにしていると思います。問い合わせをして問題解決まで数十分ということもあれば、2日、3日かかることもあるかもしれません。今回はRPAの運用担当者が問題解決までどのように行動し、どんなことを考えるのか舞台裏を少し紹介いたします。

エラー解決の鍵はロボットのログ

ユーザーから「ロボットがエラーになった」との連絡を受けたとき、まず運用担当者は事件現場の証拠集めから始めます。例えば次のような証拠です。

・ロボットのログ
・エラー時のスクリーンショット
・インプットデータ
・中間データ

特に解決に欠かせないのがロボットのログです。いわばロボットのダイイングメッセージにあたります。実際にログの内容を見ただけで解決するという場合も多くあります。丁寧に作られたロボットであれば、直接的な犯人（原因）を教えてくれます。「インプットファイルのフォーマットが間違っている」「システムのパスワードの有効期限が切れている」などです。しかし、このような理想的なログを出すロボットは実際には極めて稀です。ログの内容次第では、10分で問題解決することもあれば、10時間かかることもあります。

追加調査に必要不可欠なものとは？

多くの場合は、さらに調査が必要だという判断になります。例えば「〇〇システムの××画面のUIの操作に失敗しました。」というログです。システムの画面が急に変更になったのか、システム側のエラーでロボットが操作できない状態になったのか、あるいは単にロボットが不安定だっただけなのか、この時点では判断できません。

次に確認するのがエラー時のスクリーンショットです。どの画面でエラーになっているのかを業務手順書やRPA仕様書など、ロボットが操作する画面がわかる資料とスクリーンショットを見比べます。ところが、スクリーンショットもない、ロボットが操作する画面を説明する資料もないという現場も存在します。RPAの開発にスピード感は大事ですが、必要最低限の資料は作っていてほしいと願う瞬間です。

エラーの再現には時間がかかる

次はエラーを再現してみるという段階に入ります。犯人（原因）を現行犯で取り押さえようというわけです。同じPCでできれば一番理想的ですが、他のロボットのスケジュールとの兼ね合いで、同じPCで検証できないというケースがほとんどです。
まず手動でロボットがやっていることを再現してみます。それでも原因が特定できない場合は開発用PCで再現します。実はこの作業がある程度時間を要します。

開発から数年たったロボットだと開発用PCの環境構築から始めなくてはなりません。本番環境と同じ環境にするためにソフトをインストールしたり、同じフォルダ構成を再現したり、ロボットの内部設定をテスト用に変更したりします。ようやく環境が整って、いよいよエラー再現という段階ですが、実行してもエラーが再現できないとますます頭を抱えてしまいます。

原因特定には部署間同士の体制作りも重要

原因特定に時間がかかった例を紹介します。そのロボットは夜間を利用して業務システムからデータをダウンロードする処理をしていました。ところがある晩から前半は順調だったにもかかわらず、後半から業務システムが操作できないというエラーを出し始めてしまいました。途中からエラーになるという事象だったため、ロボット側のバグなのか原因を特定することができませんでした。

開発用PCの他、本番用PCでもエラー再現に挑戦しましたが、再現できませんでした。運用担当者たちであれでもない、これでもないと議論をし、改めてロボットのログに注目してみました。すると毎晩深夜2時ちょうどからエラーを出し始めていたのです。

業務システムの担当部門に問い合わせた結果、エラー発生日から業務システム自体が深夜2時よりメンテナンスで利用ができなくなるという運用変更があったことがわかりました。さらに、23時以降この業務システムの利用は制限しているとの返事も。ユーザー部門も利用制限時間を知らなかったため、ロボットの稼働時間を要件に含められなかったようです。このような場合には、システムを管理する部門と密に連携をとり、原因特定を進める必要があります。また、RPAの運用マニュアルを作成し、予期せぬトラブルにも迅速な対応ができるよう、部署間同士でフォローする体制を構築することも大切です。

おわりに

最近では市民開発によるRPA導入を推進している企業も増えてきています。もし市民開発者としてRPA開発をする機会がありましたら、本コラムを思いだし、運用コストがかからないような工夫に役立てていただければ幸いです。