不具合管理と再発防止——同じ問題を二度起こさないプロセス設計

「同じバグが別の画面でも出ていた」「先月と同じ原因でリリースが遅れた」——こうしたデジャヴュを感じたことのあるPMは多いはずだ。不具合はゼロにできない。しかし、同じ不具合を二度繰り返すことは、プロセスの失敗だ。本記事では、不具合を「その場で潰す」対症療法から脱し、再発を構造的に防ぐプロセス設計の実践手法を具体的に解説する。

＜目次＞

なぜ不具合は繰り返されるのか——「解決」と「解消」の違い
1. 「直した」と「潰した」は別物だ
2. 不具合の「表層」と「根層」を分けて記録する
不具合を「分類・集約」することで見えてくるパターン
1. 不具合はカテゴリで語れ
2. 「検出フェーズ」の記録が予防設計のカギになる
再発防止策を「組織に埋め込む」設計
1. 再発防止策の「実効性チェック」を設計に組み込む
2. ナレッジを「次のプロジェクト」に渡す仕組み
まとめ——再発防止を「習慣」ではなく「構造」にする
よくある質問

なぜ不具合は繰り返されるのか——「解決」と「解消」の違い

「直した」と「潰した」は別物だ

現場でよく見る光景がある。テスト工程でバグが検出される。担当者が修正する。テストをパスする。チケットをクローズする。——これで「解決」と思っていないだろうか。

実際、あるWebシステムの開発プロジェクトで、同一カテゴリの入力値検証バグが3つの画面で同時期に報告されたケースがあった。それぞれが個別チケットで管理され、それぞれが「修正済み」になった。しかし翌スプリントで、別の4つの画面に同様の不具合が発見された。原因は共通コンポーネントの設計ミスだったが、最初の3件を「個別事象」として処理したため、横断的な原因追及が行われなかったのだ。

これが「直した（Fix）」と「潰した（Resolve）」の違いだ。Fixは症状への対処、Resolveは原因の除去を意味する。不具合管理が「チケットのクローズ」をゴールにしている限り、再発は必然的に起きる。

不具合の「表層」と「根層」を分けて記録する

再発防止の第一歩は、不具合を記録する粒度を変えることだ。多くのプロジェクトでは「何が起きたか（症状）」しか記録しない。再発防止には「なぜ起きたか（原因層）」と「なぜ検出できなかったか（検出失敗層）」の2軸が必要になる。

PMBOKでも品質管理プロセスにおいて「欠陥修復」と「品質管理測定値」を明確に区別しているが、現場では往々にして両者が混在する。具体的には、不具合チケットに以下の3フィールドを追加するだけで記録の質が変わる。

直接原因：何がトリガーになったか（例：バリデーション関数の条件分岐漏れ）
根本原因：なぜその直接原因が生まれたか（例：コーディング規約にバリデーション要件が明記されていなかった）
検出失敗原因：なぜレビューやテストで見逃したか（例：境界値テストケースが設計されていなかった）

この3層記録を習慣化するだけで、後述する再発防止策の精度が劇的に向上する。

不具合を「分類・集約」することで見えてくるパターン

不具合はカテゴリで語れ

個々の不具合を個別に対処していると、プロジェクト全体のトレンドが見えない。重要なのは不具合を分類し、集約してパターンを読むことだ。

ある業務システム開発（6ヶ月・チーム15名）では、スプリント4終了時点で累計76件の不具合が発生していた。PMが集計したところ、以下の分布が明らかになった。

入力値検証の漏れ：28件（37%）
画面遷移・状態管理の不整合：19件（25%）
外部API連携エラーハンドリング：14件（18%）
その他：15件（20%）

この分析から、上位2カテゴリで全体の62%を占めることが判明した。PMはスプリント5の開始前に「入力値検証チェックリスト」と「画面遷移仕様テンプレート」を整備し、コードレビューの必須確認項目に追加した。結果、スプリント5・6の不具合数は合計で31件に抑えられ、単純計算で約40%削減できた。

不具合のカテゴリ分類は最初から完璧でなくていい。「機能バグ」「UI/UXバグ」「パフォーマンス」「セキュリティ」「データ整合性」という5分類から始め、プロジェクトの特性に合わせて細分化していくのが現実的だ。

「検出フェーズ」の記録が予防設計のカギになる

不具合の分類において、どのフェーズで検出されたかを記録することも重要だ。単体テストで見つかったバグと、ユーザー受入テスト（UAT）で見つかったバグでは、その意味合いがまったく異なる。後工程で検出されるほど、手戻りコストは指数関数的に増大する。IBM研究所の古典的なデータでは、要件定義フェーズで見つけた欠陥を100とすると、システムテスト段階では1,500、運用後では6,400以上のコストがかかるとされている。

検出フェーズの記録を積み上げることで、「なぜこのバグは単体テストで捕まえられなかったのか」という問いが立てられる。この問いこそが、テスト設計の見直しやレビュープロセスの改善につながる入口になる。

関連して、「テスト計画は作った」で止まっていないか——形骸化の構造を解剖し、現場で”機能する”テスト計画に再設計する実践技法でも述べているように、テスト計画は作成時点ではなく「運用時点」でその価値が問われる。不具合の検出フェーズデータは、テスト計画を動的に改善する燃料になる。

再発防止策を「組織に埋め込む」設計

再発防止策の「実効性チェック」を設計に組み込む

再発防止の最大の落とし穴は、「対策を決めた」で終わることだ。多くのプロジェクトで、不具合発生後に「チェックリストを追加する」「レビュー強化」「意識を高める」といった対策が検討される。しかし、これらが実際に機能しているかを確認する仕組みがなければ、対策は宣言で終わる。

実効性の高い再発防止策には、次の3要件が必要だ。

具体性：「レビュー強化」ではなく「入力値検証チェックリスト全12項目をレビュー時に確認し、確認済みのサインをPRに添付する」
オーナー：誰が維持・運用するかを明記する（「チーム全員」は誰でもない）
検証タイミング：次のスプリントレビューで「同カテゴリの不具合が出なかったか」を確認する

これを実現するために有効なのが「再発防止策台帳」だ。不具合チケットに紐づく形で、対策内容・オーナー・検証日・検証結果を記録する。この台帳をスプリントレビューやフェーズゲートレビューの定常確認項目に組み込むことで、対策が形骸化せず生き続ける。

ナレッジを「次のプロジェクト」に渡す仕組み

再発防止をプロジェクト内で完結させることの限界も意識したい。同じ組織の別プロジェクトで、まったく同じ種類の不具合が再発するケースは珍しくない。これは「組織の学習が設計されていない」ことの証左だ。

具体的には、プロジェクト完了時のレトロスペクティブで、再発防止策として効果が実証されたものを「品質ナレッジベース」として整理し、組織の標準プロセスやテンプレートに反映する工程を設ける。形式は問わない。Confluenceのページでも、社内WikiでもExcelでも、「誰でもアクセスでき、次のPMが参照できる」状態を作ることが重要だ。

また、レビューを機能させる設計——形骸化しないレビュープロセスの作り方でも指摘しているように、ナレッジが「見える場所にある」だけでは使われない。レビューチェックリストや設計テンプレートに直接組み込む形で「使わざるを得ない状態」を作ることで、初めてナレッジは組織に血肉化する。

さらに、受入基準と不具合管理は切り離せない関係にある。受入基準の合意形成——「完了の定義」をステークホルダーと握る実践法で述べているように、「完了の定義」が曖昧なまま不具合管理を行うと、何をもって「再発なし」と判断するかの基準も揺れる。再発防止策の検証は、受入基準と同じ精度で設計されなければならない。