こんにちは。
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 で働く皆さんの業務を少しでも楽にするべく、沢山のロボットを生み出し、そのロボットも日々、品質改善を行なっています。
この記事が皆様のお役に立てれば幸いです。
最後まで読んでいただき、ありがとうございました。