こんにちは!
ご無沙汰しております。AIRCのたかはしです。
今回は、RPAにおけるエラーメッセージについてお話をしようかなと考えています。

 

さて、皆様はRPAを動かしている最中に、以下のようなエラーメッセージを見たことないでしょうか。

さあ大変!と実行ログを確認し、どこで止まったか、その時のインプットデータは何か……と、調査をすること数十分。結果、プログラムのミスなどではなく、指定のフォルダに必要なファイルが格納されていないだけだった。

そして、思うのです。もっとわかりやすいエラーメッセージだったらなあ、と。

ですが、具体的にわかりやすいエラーとは何?と聞かれても困ってしまう。
そこで今回は、そんな方のために、どんなエラーメッセージがわかりやすいか、そもそもエラーメッセージはなぜ必要なのかというお話をしていきたいなと思います。

エラーメッセージの役割

エラーが起こると悲しいし、それを知らせるメッセージなんて不吉……と考えてしまう方がいらっしゃるかもしれませんが、実はエラーメッセージはとても重要な役割を担っているのです。
それは、「エラーが発生した際に、業務担当者または開発者に対してエラーが生じたことを知らせ、さらにエラーが発生した時の状況を伝えることで業務担当者または開発者に対して何をすればよいかを伝える」ことです。

業務中、エラーが生じた際に一番困ることって何でしょう。私は、エラーがエラーとして認識されず、そのまま誤った情報で業務を進めてしまうことだと考えています。それが金額を扱う業務なら一大事!それ以外の業務であっても、生じたエラーに対してのリカバリ作業は、気付くのが遅ければ遅いほど膨大になっていくものです。

そのため、RPAに限らず、あらゆるシステムではエラーが起こった場合にエラーメッセージをユーザーに知らせ、エラーによる被害を最小限に抑えようとしているのです。
もちろんエラーが起こらないシステムが一番よいのは確かですが、どんなシステムであってもエラーは生じるものですし、特にRPAについては開発コストが制限されていることが多いため、エラーが起こらないような作りにするのは難しいのが現状です。

さて、上記を踏まえてもう一度最初のエラーメッセージを見てみましょう。

……どうでしょうか? エラーが生じたことはわかりますが、どうしてエラーが起こったのかの状況がわからず、業務担当者も開発者も何をすればよいか分かりませんね。これではエラーメッセージとして十全とは言えません。

エラーメッセージが状況を正しく伝えるためには、以下の要素をエラーメッセージの中に含めるとよいでしょう。

  • いつ
  • どの処理で
  • なにが
  • どうした

これに加えて、最後に以下の情報もあるとより親切ですね。

  • どうすればいいか

では、どのようにこれらの情報を入れればよいか、実際の例を挙げながら見ていきましょう。

業務担当者が対応可能なエラー

数あるエラーの中でも、業務担当者側の対応で収まるものは多いです。例えば、インプットファイルに不備があったり、業務で扱うデータに例外的なものがあったり、といったものですね。まずはそちらのエラーについて、見ていきたいと思います。

業務担当者側で対応可能なエラーについては、業務担当者がわかるように記載する必要があります。そのうえで、ロボット側で業務担当者に何をすればよいかを伝えてあげるとよりよいでしょう。

例として、従業員の情報を取得しようとした際に従業員情報が記載されたファイルが存在しなかった場合のエラーメッセージを考えてみましょう。

まずは基本的な情報として、発生日時や処理機能名を記載します。これによって業務担当者は、処理がどこまで進んで、どこでエラーになったかを判断することが出来るようになります。
加えて、業務担当者に対応してほしいこと……「従業員情報ファイルが存在することを確認してから再実行」のために必要な情報を記載していきます。

……こんな感じでしょうか。

発生日時:
2020/02/14 10:12:00

処理機能名:
従業員情報照会機能

エラー内容:
従業員情報ファイルが見つかりません。
従業員情報ファイルが指定のフォルダに存在することを確認してプロセスを再実行してください。
フォルダ名:C:\Users\UserName\Documents\
ファイル名:従業員情報20200101.xlsx

いかがでしょうか?
最初の「エラーが発生しました」だけのメッセージと比較すると、エラーが発生しただけではなく、業務担当者が何をすればよいのかが明確になったのではないでしょうか。

さらに、同じく従業員情報を照会する機能の中で、ファイルは存在しているものの、中に目当ての従業員情報が存在しなかった場合を考えてみましょう。

この時、従業員が新入社員か、はたまた退職者なのか、考えられるケースは複数あると思います。ただし、これらを細かい部分まで詰めていくと通常の開発と変わらなくなり、RPAのうまみでもある「少ない開発コスト」による業務効率化の効果が薄くなってしまいます。

この場合は「従業員情報が存在しない場合は業務担当者に通知し、その従業員については手動で実施する」とするのがよいでしょう。
そうなると、「手動での対応が必要な従業員は誰か」を伝える必要がありますね。ここでは従業員番号を伝えることにします。

発生日時:
2020/02/14 10:12:00

処理機能名:
従業員情報照会機能

エラー内容:
従業員情報ファイルに従業員情報が見つかりませんでした。
該当の従業員については手動での対応をお願いします。
従業員番号:012345

このように、業務担当者側で対応が可能なエラーについては、業務担当者が何をすればいいか迷わないようなエラーメッセージを心掛けるとよいかと思います。

業務担当者が対応不可能なエラー

RPAでは業務担当者が対応できないエラーももちろん存在します。システムの画面構成が変わって要素が取得できなかった場合や、ネットワーク障害などの外部要因によるエラーの場合ですね。
これらの場合に出力するエラーメッセージは開発者向けに送るものとなるため業務担当者にはわからないメッセージでも問題ないのでは……と考えるかもしれませんが、最初にそのエラーメッセージを確認するのは業務担当者です。

ですので、業務担当者が対応を迷わないように、エラーメッセージで「開発者に対応を依頼しなければいけないエラー」であることを伝える必要があります。

基本的に、こういったエラーはロボット側で制御しない・できないエラーです。
外部要因によって生じたエラーの場合は英語で書かれていることも多く、ユーザーが一目見てもわかるものではありません。
ただ、ユーザーから見たらわからない情報であっても、開発者視点では別です。エラーメッセージの内容でどのあたりがおかしいか、何が原因かの当たりを付けることが可能です。ですので、別のエラーメッセージで上書きしたりして情報を出さない、といったこともしないほうがよいでしょう。

つまり、業務担当者でも対応できないエラーが発生した場合、業務担当者向けのエラーメッセージに加え、開発者向けの元のエラーメッセージを添えて出力するのがよいですね。

発生日時:
2020/02/14 10:12:00

処理機能名:
従業員情報照会機能

エラー内容:
予期せぬエラーが発生しました。RPA開発担当者に以下のエラー情報と実行ログを連携してください。
例外の種類: UiPath.Core.SelectorNotFoundException
メッセージ: このセレクターに対応する UI 要素が見つかりません:

開発者は、ユーザーからの情報を得れば円滑にエラーの調査ができそうです。
加えて、例えばUiPathであれば「ログフィールドを追加(Add Log Fields)」アクティビティなどで引数情報をログに出力できていれば、エラー調査に必要な時間がぐっと下がる予感がします!

おわりに

工夫次第で運用のコストがぐっと下がるエラーメッセージについて書いてみましたが、いかがだったでしょうか。
適切なエラーメッセージを出して、ぜひ快適なRPAライフを送ってくださいね!