障害管理表は毎日更新されている。件数も分類も入っている。それなのに、そこから何も出てこない。
品質会議で「今週は15件でした」と報告して終わる。傾向を聞かれても答えられない。テストの終盤になって、同じような不具合が繰り返し出ていたことに気づく——。
原因は、記録していないことではありません。溜めた記録を分析する工程が、誰の仕事にもなっていないことです。この工程は手間がかかるわりに、やらなくても表面上は困りません。だから真っ先に省かれます。
ここは生成AIで大きく変わる領域です。分類と傾向出しはAIに任せ、人は打ち手を決めることに集中できます。
なぜ原因分類は形骸化するのか
形骸化には、はっきりした理由が3つあります。
1. 分類を決めるのが早すぎる プロジェクト開始時に「こんな分類が必要だろう」と机上で決めます。実際に障害が出始めると当てはまらず、判断に迷ったものが全部「その他」に流れます。気づくと半分が「その他」になっています。
2. 登録する人によって基準が違う 同じ「画面に想定外の値が出る」でも、ある人は「表示不具合」、別の人は「計算誤り」と入れます。集計しても実態を表さないので、誰も見なくなります。
3. 分析する時間が確保されていない 分類はされていても、集計して傾向を読む人がいません。テスト工程は常に逼迫しているため、この作業は必ず後回しになります。
AIで解けるのは主に1と2です。3は、1と2の手間が減った結果として時間が生まれます。
用意するもの
| 入力 | 具体例 |
|---|---|
| 溜まった障害の記録 | 障害管理表の現物。事象・原因・対応内容の記述があるもの |
| 分類の定義 | 現在使っている選択リスト値の一覧。無ければ手順①で作る |
| 工程の情報 | 検出工程と、本来検出すべき工程 |
| 参考の観点 | 設計・開発・テストのレビュー観点 |
重要なのは、事象と原因が文章で書かれていることです。分類コードだけが入っていて記述が空欄の表は、AIに渡しても何も出てきません。逆に、記述さえあれば分類が雑でも整理できます。
手順
① 分類の定義を、実際の障害から作り直す
机上で決めた分類を捨て、実際に起きた障害から帰納して作り直します。
溜まった障害の事象と原因の記述をまとめて渡し、「この障害群を、原因の性質で5〜8種類に分類する定義を作って」と依頼します。件数が偏らないように、と添えると実用的な粒度になります。
出てきた定義を人が確認し、現場の言葉に直します。AIは一般的な用語を使いたがりますが、分類はチーム内で通じることが最優先です。
このとき、障害管理表の設計そのもので解説しているとおり、障害分類（起きた事象の種別）と根本原因（なぜ作り込まれたか）は別の列として分けておきます。混ぜると、この後の分析が成立しません。
② 溜まった障害を一括で分類させる
定義が固まったら、既存の全件を分類し直します。ここは完全に機械的な作業で、AIに任せて問題ありません。
数十件から数百件を一度に渡すと精度が落ちるので、30〜50件ずつに区切って処理します。出力には分類の根拠を1行で添えさせると、後の確認が一気に楽になります。
判断に迷ったものには印を付けさせます。印が付いたものは、たいてい記述が曖昧な障害です。分類の問題ではなく、記録の問題として起票者に確認します。
③ 分類の揺れを検出させる
分類が終わったら、AI自身に揺れを探させます。
「同じような事象なのに違う分類になっているものを挙げて」と依頼するだけです。人が目視で探すのは非現実的ですが、機械的な突き合わせなら確実に見つかります。
揺れが多い分類は、定義そのものが曖昧というシグナルです。分類名を変えるか、2つに割るかを検討します。
④ 傾向を出させ、打ち手の候補まで書かせる
ここが本来やりたかった工程です。
分類済みのデータを渡し、次を出させます。
- 分類ごとの件数と、その推移
- 検出工程と、本来検出すべき工程のずれが大きい分類
- 特定の機能・担当・工程に偏っているもの
- それぞれに対して考えられる打ち手の候補
2つ目が特に効きます。「単体テストで見つけるべきだったものが、結合テストで大量に出ている」という状態が見えれば、打ち手はテストの強化ではなく、単体テストの観点や完了基準の見直しになります。
テストの消化状況とあわせて見るならテスト進捗管理表、単体テストの中身は単体テスト仕様書兼結果報告書を突き合わせます。
AIに任せてはいけないこと
1. 打ち手を決めること
AIは打ち手の候補を出せますが、どれを実行するかは決められません。残っている期間、体制、顧客との関係、他機能への影響——これらを踏まえた判断は、プロジェクトの文脈を持っている人にしかできません。
「テストケースを増やす」は正しく見えますが、期間が残っていなければ実行不能です。実行できない打ち手を掲げるくらいなら、スコープを削る相談を先にするほうが誠実です。
2. 個人の評価に使うこと
「この分類の障害は、特定の担当に偏っている」という分析結果は簡単に出ます。これを人の評価に使った瞬間に、障害の報告が止まります。
障害が報告されなくなったプロジェクトは、品質が良くなったのではなく、見えなくなっただけです。分析結果は仕組みの問題として扱うと決めておきます。偏りが出たなら、レビュー体制か引き継ぎの問題として読みます。
3. 事実の確認を省くこと
分類結果は必ずサンプリングして確認します。AIは、記述が曖昧な障害を、それらしい分類に入れてしまいます。全件は無理でも、分類ごとに数件ずつ見れば、大きな誤りは検出できます。
分析結果を打ち手に変える
傾向が出たら、打ち手は3種類に整理すると実行に移しやすくなります。
| 種類 | 内容 | 例 |
|---|---|---|
| 今すぐ効くもの | 現在のテスト工程で対応できる | 特定の観点でテストケースを追加する |
| 横展開するもの | 同種の障害が潜んでいる箇所を先回りで点検 | 同じ設計パターンの機能をまとめて再レビュー |
| 次から効くもの | 工程・基準の見直し | 単体テストの完了基準に観点を追加する |
2つ目の横展開が、いちばん費用対効果が高いです。1件の障害から、まだ表面化していない同種の障害を先に潰せます。テストの終盤で同じ不具合が繰り返し出るのは、これをやっていないからです。
打ち手をどう合意し、どう報告するかはテスト計画書・テスト方針書の書き方にまとめています。レビュー段階で検出した指摘はレビュー指摘表で管理し、実装後に顕在化したものを障害管理表へ引き継ぐと、工程ごとの検出状況が正しく集計できます。
うまくいかないときの原因
| 症状 | 原因 | 対処 |
|---|---|---|
| 分類しても傾向が見えない | 障害分類と根本原因を1列で扱っている | 事象の種別と、なぜ作り込まれたかを分けて持つ |
| 「その他」が大量に出る | 机上で決めた分類のまま | 実際の障害から帰納して定義し直す（手順①） |
| 分類結果が信用できない | 記述が空欄の障害が多い | 分類の前に、記述を埋める運用を直す |
| 打ち手が実行されない | 実行可能性を検討せずに掲げている | 期間と体制を踏まえて3種類に整理する |
| 報告が上がらなくなった | 分析結果を個人の評価に使った | 仕組みの問題として扱うと明示し、運用を戻す |
まとめ
- 原因分類が形骸化するのは、分類を決めるのが早すぎることと、分析する時間が誰の仕事でもないこと
- 分類の定義は、机上で決めず、実際に起きた障害から帰納して作り直す
- 分類・揺れの検出・傾向出しはAIに任せられる。数十件ずつ区切り、根拠を1行添えさせる
- 打ち手を決めること・個人の評価に使うこと・事実確認を省くことは渡さない
- 打ち手は「今すぐ効く／横展開する／次から効く」の3種類に整理する。横展開が最も費用対効果が高い
分類と集計が自動化されると、品質会議の中身が「件数の報告」から「打ち手の相談」に変わります。もともとそこが目的だったはずです。
実際の進め方を手を動かしながら身につけたい方は、AI開発トレーニングで個別にお伝えしています。
