RPAでエラー処理するべき2つの理由

RPAでエラー処理しないといけない理由ってなに?必要性がよくわからないから教えて。

という疑問に答えます。

本記事のテーマ

RPAでエラー処理するべき2つの理由

記事の内容
  • エラー処理を行う前提の話
  •  RPAは本番環境で運用することが基本
  •  本番環境ではエラーが分かりにくい
  • [1]エラー発生後の処理を行いたいから
  •  ①リカバリーのための詳細情報を得る
  •  ②自分以外のユーザーへの情報を伝える
  •  ③正しい終了処理を行う
  • [2]シナリオ実行を続けたいから
記事の信頼性

記事を書いている僕は、RPA関連の書籍を5冊出版しているRPAの専門家です。7年以上、複数の会社でRPAの導入・開発・運用に携わっています。

読者さんへの前書き

本記事は、僕が関わってきたRPAツール(UiPath、WinActor、Power Automate for desktopなど)をイメージして解説しています。

RPA全般について解説していますが、個別のRPAツールに応用してくださいね。

それでは、どうぞ!

この記事を書いた人
この記事を書いた人
こさい
こさい

(株)完全自動化研究所代表のこさいです。

1) エンジニア歴25年超。開発から業務改善まで幅広く経験してきました
2) 複数の企業においてRPAのコンサルティングを行っています
3) RPA関連の書籍を5冊出版しています

  1. オープンソースで作る!RPAシステム開発入門
  2. 実務者のための失敗しないRPAシナリオ設計入門
  3. UiPath業務自動化最強レシピ
  4. WinActor業務自動化最強レシピ
  5. Power Automate for desktop業務自動化最強レシピ

現在はChatGPTとPower Automate for desktopの書籍を執筆中!

エラー処理を行う前提の話

エラー処理を行う前提をお話します。

RPAは本番環境で運用することが基本

まず、これをお伝えしておきます↓↓

RPAは本番環境で運用することが基本です。

開発し終えたシナリオは、開発環境ではなく、実行端末(実行用パソコン)の本番環境で実行します。

シナリオ

RPAツールで開発したオートメーションのことを、僕は「シナリオ」と呼んでいます。UiPathで「ワークフロー」、Power Automate for desktopで「フロー」と呼ばれているものです。

本番環境

UiPathではUiPath Robot(UiPath Assistant)もしくはオーケストレータ―から実行します。Power Automate for desktopでコンソール、またはPower Automate(クラウドフロー)から実行します。

よく目にするのは、開発環境のまま運用している人。
これは「デバッグ環境で実行」している状態です。

今後は、「開発環境のまま運用している」ことを「デバッグ環境で実行している」と表記します。

これは、正しい運用ではありません。
「料理しながら、フライパンにのったままの料理を食べている」感じです。
(それでも、いいという人もいるでしょうけど……。)

ちゃんと、お皿に盛りつけて、テーブルでいただきましょう。
それが、「本番環境で運用する」ということです。

本番環境ではエラーが分かりにくい

デバッグ環境では、エラー発生すると、開発画面内にエラー情報が表示されます。

たとえば、Power Automate for desktopなら、このようにエラーが発生したアクションが赤枠で囲まれます。エラーパネルにも、エラー内容が表示されます。

Power Automate for desktopにおけるエラー発生時の画面

うん、エラーの発生場所も、原因もわかりやすい!すぐにシナリオを直して、再実行することも容易です。多くの人が、デバッグ環境のまま運用している理由の1つは、コレでしょうね。

一方、本番環境でエラーが発生したときは、

エラー情報が少なく、エラーの原因がわかりにくい。その場で、シナリオを直すこともできません。

だからこそ、エラー処理を行う必要があるんです!
逆に、デバッグ環境で運用しているかぎり、エラー処理の重要性はわからないんじゃないかな。

というわけで、ここまではエラー処理を行う理由の前置きでした。
ここから、エラー処理を行う理由の深掘りになります。

[1]エラー発生後の処理を行いたいから

「RPAでエラー処理するべき理由」の1つ目は、「エラー発生後の処理を行いたいから」です。

エラー処理を行わないと、このようにエラーが発生したときのアクションを実行できません。

エラー発生時の処理を行えない

エラー発生後の処理として、よく行うことを3つ解説します。

エラー処理の目的
  • ①リカバリーのための詳細情報を得る
  • ②自分以外のユーザーへの情報を伝える
  • ③正しい終了処理を行う

それでは、1つずつ、詳しく解説していきます。

①リカバリーのための詳細情報を得る

エラー処理の目的の1つ目は「リカバリーのための詳細情報を得る」ことです。

本番環境でエラーが発生したときに、適切にリカバリーするには、

  • どこでエラーが発生したのか
  • どんな原因でエラーが発生したのか

を知りたい、ですね。

RPAツール自体の仕組みで、エラー内容を表示してくれるケースもあります。
しかし、このエラー情報が足りないなら、エラー情報を詳しく得るための処理を行います。

具体的には、

  • ポップアップメッセージで、詳しいエラー情報を表示する
  • ログに詳しいエラー情報を書き出す

といった方法です。

②自分以外のユーザーへの情報を伝える

エラー処理の目的の2つ目は「自分以外のユーザーへの情報を伝える」ことです。

RPAは「自分で作って、自分で使う」というケースだけではありません。

「RPAを作れる人がシナリオを作って、RPAにあまり詳しくないユーザーが使う」というケースはよくありますよね。このケースを考えてみましょう。

↓↓

ユーザー
ユーザー

エラーが発生したら、なんか不親切なエラーメッセージが表示される

これでは、ユーザーは困惑してしまいます。
シナリオを作った開発者に、すぐ問い合わせするでしょう。

シナリオを作った人も、何回も問い合わせを受けて、疲弊します。

RPA開発者
RPA開発者

問い合わせ対応ばかりで、開発が進まないよ……

こういうケースを防ぐために、エラー発生時には、

  • わかりやすいエラーメッセージに変えて、表示する
  • このあと、どうすればいいのかを教える

といった処理を加えるのが、いい方法です。

③正しい終了処理を行う

エラー処理の目的の最後は「正しい終了処理を行う」ことです。

本番環境でエラーが発生したら、そこでシナリオの実行は終了します。

もし、RPAツールがExcelの操作途中だったら、途中で終了、というわけ。

このとき、Excelを非表示で操作していたら?
Excelのインスタンス(実体)は残ったままになってしまいますね。
(「裏で生きている」と言ったりします)

このまま、再度シナリオを実行したら、別のエラーが発生するかも!

ユーザー
ユーザー

「Excelは既に開いている」って言われた……

エラー発生時には、エラー処理を行い、Excelを適切に終了させることが重要なことがわかりますね。

Excelだけではなく、アプリケーションやWebサイトの操作でも同じ。
正しい方法でログアウトして、ウィンドウを閉じましょう。

[2]シナリオ実行を続けたいから

エラー処理を行う理由の2つ目は「シナリオ実行を続けたいから」です。

エラー発生時も自動的にリカバリーできるケースもあります。そのリカバリーアクションを設定していなかったら、このようにフローはそこで終了します。

フローを続けられない

せっかく、リカバリー方法があるのに、、
エラー発生のたびに手動でリカバリーしないといけなかったら、大変だし、ムダ!!

自動リカバリー可能なケースだったら、その処理を組み込みましょう。リカバリーして、また正常なシナリオに復帰できれば、運用の工数が減りますね。

まとめ

この記事では、『RPAでエラー処理が必要な理由』を解説してきました。

  • エラー処理を行う前提の話

「RPAでエラー処理って必要か?」と疑問に思う人は、「エラー処理を行う前提の話」で書いたように、デバッグ環境で運用しているから、かも。

で、RPAでエラー処理が必要な理由は、大きく分けると次の2つ。

  • [1]エラー発生後の処理を行いたいから
  • [2]シナリオ実行を続けたいから

です。

本番環境で運用して、かつ、エラー処理を行うことで、RPAをMAXで活用できるようになりますよ!

それでは、また♪

タイトルとURLをコピーしました