こんにちは。
mediba Advent Calendar 2023 4日目を担当させていただきます、伊礼と申します。
今年の 1月から、主に RPA を用いて社内の業務改善を進める部署 BPM UNIT の配属となり、この年末で 1年が経過しました。今でも必死に勉強中です。

BPM UNIT では、mediba で働く皆さんの業務を少しでも楽にするべく、沢山のロボットを生み出し、現在は 20台以上のロボットたちが昼夜問わず働いてくれています。
しかし、そんなロボットたちは、ときたまエラーを起こしてしまうことがありまして、都度都度直してまた働いてもらっているのですが、この度、エラーの傾向として多いものだったり、どのロボットが問題児なのかなどを把握すべく、エラー分析なるものを行うことになりました。

今回は、そのロボットたちが起こしてしまったエラーを集計して、分析した結果をお話しさせていただければと思います。

分析前の準備 (分析目的の明確化, データの収集)

まずは、どのような分析を行い、どのような結果を得たいかを整理します。
今回、ひとまず得たい結果としては、以下の 3点を置きました。

ロボット全体を見て、どのような種類のエラーが現れやすいのか
極端にエラーを起こしてしまう特定のロボットは存在するのか
ロボットの品質を図る指標として有効な数値の算出方法

これら 3点は、ロボットの開発者やエラー対応をされている方はなんとなーく把握されているのですが、今後新しく入ってきた方や、BPM UNIT としての品質目標として分かりやすく掲げられるように、しっかりと明文化していきます。

これら 3点の結果を得るためには、以下の種類のデータが必要だと考えました。

エラー内容 (ロボット名、日時、エラーメッセージなど)
それぞれのロボットの実行件数

早速、集計してみたところ、Slack チャンネル内に投稿されたエラーは 2022年4月から 2023年6月までのもので 8209件ありました。

……多くね？

15ヶ月間で 8209件ということは、1ヶ月で約550件、1日約18件エラーを起こしていることになります。そんなバカな……
そこでエラーの内容を確認してみると、1つのエラー内容が異常に多く投稿されていることが分かりました。
そのエラーは、2つのデータを照らし合わせ、存在しなかった場合スキップするというものでした。処理としては正常なのですが、Slack チャンネルにスキップした分が全て投稿されていたというわけです。

こちらはエラーではありません。その他にも、エラーではないのにチャンネルに投稿されてしまっているものを除外したところ、エラーの総数は 755件になりました。一安心。ちなみに、先ほど例に出したあのエラー文言は 5000件以上ありました。本当に骨が折れました。早くロボット開発の勉強をして自動化してやります。

どんなエラーが多かったのか

残ったエラーを分類すると、84種類のエラーであることが分かり、それらを更に大まかな要因で分類していくと、以下の 4つに分けられることが分かりました。

エラー要因	エラー概要	件数
バグ起因	ロボットのプログラム起因のエラー例 : ロジックの誤りでロボットが停止した	360件
ユーザー起因	誤ったユーザー操作によって発生するエラー例 : 指定のフォーマットでないファイルを投入した。	154件
インフラ起因	ネットワーク・クラウド起因により発生するエラー例 : AWSのサーバがダウンした	74件
対向システム起因	ロボットが操作するシステムの変更により発生するエラー例 : 管理画面の UI が変更された	33件

※エラー文言から要因が判断できないものなど、「その他」に分類されているエラーが 134件

ユーザー, インフラ, 対向システム起因のものに関しては、ロボット自体が原因ではありませんが、バグ起因のものはロボット自体に問題があり発生したエラーになります。
つまり、BPM UNIT の方で改善が可能なエラーになります。こちら件数も多いことから、全体のエラーの割合のとは別に、バグ起因の割合も算出した方が良さそうだということが分かりました。

問題児のロボットは誰だ

それぞれのロボットの実行件数も収集し、まずはロボット毎の全てのエラー割合を算出しました。すると、以下のような結果になりました。

黒塗り部分が多くて申し訳ありません……この黒塗り作業も、いつか自動化してやる。
こちらエラー割合が高い順でソートすると、1割を超えてしまっているロボットたちには、それぞれ 3種類の特徴があることが分かりました。

赤字のロボットは、仕様上エラーの投稿が多く出てしまっているもので、青字のロボットは、実行する上で、ある程度のエラーが許容されているものでした。
つまり、赤字と青字のロボットは、一癖あるものの、運用上問題ないものでした。問題は緑字のロボットです。

これらはエラーの発生率が 1割を超えてしまっていますが、特に癖のあるロボットというわけではありません。共通する特徴として持っているものは、運用歴の浅さです。
当然と言えば当然なのですが、ロボットを運用する中で、リリース直後が最もエラーが起きやすく、それを毎回改修することで、エラーの数が少なくなっていきます。

つまり、ロボットの運用歴が浅いものは、まだ安定した運用がされていない、もしくは、安定してから日が経っていないことから、エラー率が高いままになってしまっているというわけです。

ロボットエラー率の仮説

そこで、以下のような仮説を立ててみました。

ロボットのエラー率はリリース直後に高く出るが、ある一定の期間を経過すると低下し収束していく

そして、その仮説が正しいものなのかを確かめるために、ロボットの実行件数とエラー数を、各月毎に集計し直すことにしました。
改めて集計したデータで、ロボットの各月毎のエラー率を算出し、リリース直後を起点としたグラフを作成すると、以下のようなものが出来上がりました。

リリースから経過月毎の各ロボットのエラー率の推移

このグラフを見ると、ほとんどのロボットで 7ヶ月目以降からエラー率が 20% を超えなくなっています。
また半数以上のロボットが、1ヶ月目, 2ヶ月目の高いエラー率に対して 3ヶ月目で一気に下がっている傾向が読み取れました。

つまり、リリースから 2ヶ月目までは高いエラー率が出やすく、運用上 3ヶ月目以降にエラー率が落ち着いてくることが分かったことから、リリースから 3ヶ月目以降のデータは、ロボットの安定性を図る指標にすることができることが分かりました。やったー！！

まとめ

今回のエラー分析で得たかった結果は以下の 3点でした。

ロボット全体を見て、どのような種類のエラーが現れやすいのか
極端にエラーを起こしてしまう特定のロボットは存在するのか
ロボットの品質を図る指標として有効な数値の算出方法

現れやすいエラーの種類は、4つに分類でき、その中でもロボットのバグ起因のものが多いことを把握することができました。
問題児のロボットについては、それぞれ特定することができ、その特徴も確認することができました。
そして、3つ目に関しても、ロボットをリリースしてから改修を繰り返し、3ヶ月目以降のエラー率を確認することで、ロボットの品質を図れることが分かりました。

今回のエラー分析は、過去のデータを一気に収集して、手探りで計算して……という流れだったのですが (非常に大変だった)、現在は 1ヶ月毎に収集, 算出し、ロボットの品質改善に繋がるよう継続して行なっています (あまり大変じゃない)。

来年は、ロボットのエラー割合のモニタリングだけでなく、エラー分析を組み込んだ品質改善プロセスを新たに策定や、エラー分析の新たな観点や指標を見つけたいと考えています。
これから開発するロボットの起こりがちなエラーなどが把握できるようにして、開発時点から考慮したり、より品質の高いレビューができるようになったりなど、今後のロボット開発の品質がより向上するよう動いていきます。

改めまして、BPM UNIT では mediba で働く皆さんの業務を少しでも楽にするべく、沢山のロボットを生み出し、そのロボットも日々、品質改善を行なっています。
この記事が皆様のお役に立てれば幸いです。

最後まで読んでいただき、ありがとうございました。