プロジェクト欠陥管理の鉄則｜「品質の履歴書」で修正漏れと再発を防ぐ極意

「テストでバグが見つかったけど、メールや口頭で報告するだけでいいの？」
「バグが多すぎて、どれから直せばいいのか、何が未完了なのか分からなくなってきた……」

システム開発のテスト工程に入ると、避けて通れないのが「欠陥（不具合・バグ）」の発生です。

欠陥が見つかること自体は、システムをより良くするための健全なプロセスです。しかし、その管理がずさんだと「直したはずのバグが再発する」「修正漏れがあるままリリースしてしまう」といった致命的な問題に繋がります。

今回は、30年の現場経験を持つ筆者が、欠陥管理を単なる「バグ直し」で終わらせず、システムの信頼性を証明する「品質の履歴書」へと昇華させるためのポイントを解説します。

欠陥管理の本質：なぜ「品質の履歴書」が必要なのか
【失敗事例】メールと口頭が招く「バグ対応の迷走」
- 連鎖する問題と「炎上」の始まり
迷走を断つ「欠陥管理プロセス」4ステップ
【プロの判定基準】重要度ランク（A〜D）の定義表
職務と役割：誰が品質を承認するか
【サンプル】欠陥管理のフロー図
現場を動かす「欠陥管理台帳」の必須項目
【プロの視点】自信を持ってリリースするための運用術
まとめ：欠陥管理は「品質の履歴書」である

欠陥管理の本質：なぜ「品質の履歴書」が必要なのか

プロジェクトにおける「欠陥管理」とは、発見された不具合を記録し、修正から再テスト完了までの状態（ステータス）を正確に追跡するプロセスのことです。

なぜ、メールやチャットのやり取りだけでは不十分なのでしょうか。

修正漏れと「デグレード」を防ぐため 見つかった不具合をすべてリスト化し、一つひとつ「完了」になるまで追いかけることで、対応漏れを防ぎます。また、修正によって他の箇所が壊れる「デグレード（先祖返り）」の検知にも役立ちます。
品質を「見える化」するため（バグ曲線） バグの発生件数や推移（バグ曲線）を分析することで、「品質が安定してきたか」「まだテストが足りないか」を客観的に判断できます。これはリリース可否を決める重要な指標になります。
責任の所在と「証跡」を明確にするため 「誰が修正し、誰が再テストしてOKを出したか」を記録します。これは将来のトラブル時の原因究明や、お客様への品質保証の強力な証拠となります。

【失敗事例】メールと口頭が招く「バグ対応の迷走」

注文管理機能のテストをしている、担当の佐々木さんと開発者のやり取りを見てみましょう。

システム会社
注文管理担当
佐々木さん

ボタンを押しても出荷区分が更新されないバグがあります。昨日言った分と合わせて今日中に直してください！

システム会社
出荷管理
開発者

分かりました、やっておきます。

翌日……

システム会社
注文管理担当
佐々木さん

先週頼んだバグ、まだ直ってませんけど……

システム会社
出荷管理
開発者

え？メールで報告した検索バグの方は直しましたよ。もう一つは在庫チェックの件ですよね？

システム会社
注文管理担当
佐々木さん

いえ、在庫じゃなくて商品チェックの方です！あと出荷区分の件もどうなりました？

システム会社
出荷管理
開発者

出荷区分？それは初耳です……（大丈夫かな、このプロジェクト）

このように場当たり的な報告では、伝達ミスや優先順位の取り違えが発生します。しかし、本当の恐怖はこの後にやってきます。

連鎖する問題と「炎上」の始まり

数日後のチーム定例会議で、テスト進捗の遅れを報告した佐々木さんは、リーダーから厳しい追及を受けます。

システム会社
注文管理リーダー
佐藤さん

現時点でのバグの件数は？残りは何件あって、いつ完了する予定なの？

システム会社
注文管理担当
佐々木さん

えーっと……メールや口頭でやり取りしているだけで、正確な件数は把握していません……

システム会社
注文管理リーダー
佐藤さん

はぁ！？じゃあ、いつテストが終わるか全く分からないってこと？ちなみに、見つかった『出荷区分のバグ』って、他の機能への影響は調べた？

アイコンシステム会社
注文管理担当
佐々木さん

あっ！出荷区分は先日の仕様変更で追加された項目なので……もしかしたら、他の関連画面も同じように対応が漏れてバグになっているかも……

システム会社
注文管理リーダー
佐藤さん

今すぐ他の画面の設計書も確認して！関連チームのリーダーにも共有して、至急再発防止策を考えないとリリースに間に合わないぞ！！

システム会社
注文管理担当
佐々木さん

（こんな大ごとになるなんて……最初から一覧表に記録して、影響範囲を調べておけばよかった……）

一つの小さなバグ管理を怠った結果、「全体の進捗が見えない」「他の機能への影響調査（二次被害）が漏れる」という連鎖的な問題を引き起こし、プロジェクト全体を巻き込む炎上へと発展してしまいました。

「記録なき修正」は、プロジェクトを崩壊させる第一歩なのです。

迷走を断つ「欠陥管理プロセス」4ステップ

欠陥を効率的に処理するために、以下のフローを徹底しましょう。

ステップ1：欠陥の起票（報告）

テスト実施者が不具合を見つけたら、速やかに管理表に登録します。「再現手順」「スクリーンショット」「発生環境」を詳しく記載し、開発者が迷わず調査できる状態にします。

ステップ2：重要度の判定と割り振り

PMやリーダーが内容を確認し、修正の優先順位を決めます。「業務が止まる致命的なもの」から「文言の微修正」まで、限られたリソースをどこに投下すべきか判断します。

ステップ3：修正と「再テスト」

開発者が修正したら、必ずテスト実施者が「本当に直っているか」「他が壊れていないか」を改めて確認（再テスト）します。

ステップ4：完了確認とクローズ（完了）

再テストで合格したものだけを「完了」とします。原因が「設計ミス」か「コーディングミス」かを分類しておくと、将来の工程改善に役立ちます。

【プロの判定基準】重要度ランク（A〜D）の定義表

「運用ルール」としてそのまま使えるよう、判定基準を整理しました。

ランク	判定基準（テスト・受入時共通）	役割・目的
A：致命的	・システム全体が機能しない・回避策がなくテストを中断せざるを得ない・リリースに直結する致命的な遅延要因	最優先で修正が必要。全リソースを投入して解決を図る。
B：重要	・主要機能が動作しない・回避策はあるが業務運用に支障が出る・スケジュールへの影響がある	Aの次に優先順位が高い。マイルストーンまでに必ず解消する。
C：普通	・一部機能が動作しないが、テスト自体は継続可能・運用でカバー可能な範囲の不具合	計画的に修正を進める。運用回避でリリースするかの判断対象。
D：軽微	・画面のレイアウト崩れ、誤字脱字・操作性に影響しない軽微な不備	他の修正のついで、または余裕があるタイミングで対応する。

職務と役割：誰が品質を承認するか

体制図に基づき、誰が「起票」し、誰が「クローズ」の責任を持つかを明確にします。

職務名称	欠陥管理における役割	役割・目的
統括責任者 / PM	・未解決バグ状況の把握・品質分析結果に基づくリリース可否の最終判断	プロジェクト全体の品質に責任を持ち、「Go/No Go」の決断を下す。
PL / リーダー	・欠陥管理台帳のメンテナンス・重要度の一次判定・仕様かバグか（却下判断）の切り分け	現場の判断を統括し、開発とテストの交通整理を行う。
ユニットリーダー	・修正作業の割り振り・修正内容のレビュー・内部再テストの指揮	実際の修正品質を担保し、二次バグ（デグレード）を防ぐ。
品質保証（QA）	・バグ曲線の分析と警鐘・欠陥管理プロセスの遵守状況の監査	第三者の視点で品質を客観視し、リスクを早期にアラートする。

【サンプル】欠陥管理のフロー図

番号	実施担当	実施内容
1～2	両者	欠陥が発見されたら、プロジェクト担当者へ連絡します。
3	システム会社	プロジェクトメンバー間で欠陥内容を説明し、欠陥内容を記録します。
4	システム会社	欠陥内容を確認し、欠陥が仕様通りか判定します。欠陥ではない場合は却下とし、却下通知を行います。欠陥と思われる場合は欠陥原因の調査を開始します。
5	お客様	却下理由を確認します。もし欠陥内容が解消されないことで業務に影響が出る場合は仕様変更するか検討します。（仕様変更時は変更管理に記録）
6	システム会社	欠陥原因を調査します。
7	システム会社	欠陥に対する対策を検討します。
8	システム会社	欠陥の原因と対策内容を確認し、問題なければお客様のプロジェクトメンバーへ連絡します。
9	お客様	欠陥の原因と対策内容を確認します。
10	両者	仕様変更が必要になったり、納期が遅延するなど、プロジェクト全体に影響する場合はプロジェクトメンバー同士で対策内容を整合します。問題なければ両者の責任者の承認を得ます。
11	システム会社	責任者の承認により、対策が確定したことをプロジェクトメンバーで共有し、開発者へ対策を指示します。
12	システム会社	対策内容を設計書やプログラムへ反映します。

現場を動かす「欠陥管理台帳」の必須項目

そのままエクセルやスプレッドシートに転用できるよう、記録すべき項目を整理しました。これらを横に並べて一覧表形式で利用してもよいでしょう。

分類	記録項目	項目内容
欠陥内容	発見日	欠陥の報告を受け付けた日
	欠陥内容	欠陥の内容
	対応希望日	欠陥の対応を希望する日
	欠陥発見者	欠陥を発見した担当者
	状況	「受付」「原因調査中」「対策検討中」「承認済」「対策実施中」「却下」「完了」などの状態
調査結果	欠陥原因	欠陥の原因（要件不備・未決定、仕様認識の齟齬、設計不備・漏れ、プログラム間違い、テストデータ不備、インフラ不備など） ※欠陥原因や発生工程は品質分析で活用するもの
	発生工程	欠陥が見つかった工程（要件定義、概要設計、詳細設計、開発、結合テスト、システムテスト、ユーザー受入テスト、移行など） ※欠陥原因や発生工程は品質分析で活用するもの
	重要度	欠陥が業務やプロジェクトに与える影響をランクで振り分け（上述の重要度ランク定義表を参照）
	対策内容	欠陥の対策内容（対応内容やポイント、注意事項など）
	調査担当者	調査をした担当者
対策判定	採否判定	変更を承認するか、却下とするか
	採否確定日	採否が決定した日
	承認者（お客様）	お客様側の責任者
	承認者（システム会社）	システム会社側の責任者
対応完了	対応担当者	対応した担当者
対応完了	対応完了日	対応が完了した日