【台帳項目・重要度基準付】プロジェクト欠陥管理（バグ管理）の鉄則｜修正漏れを防ぐ4ステップ
「テストでバグが見つかったけど、とりあえずチャットで報告しておけばいいよね？」
「バグが多すぎて、どれから直せばいいのか、何が未完了なのか分からなくなってきた……」
システム開発のテスト工程に入ると、避けて通れないのが「欠陥（不具合・バグ）」の発生です。 欠陥が見つかること自体は、システムをより良くするための健全なプロセスです。しかし、その管理がずさんだと「直したはずのバグが再発する」「修正漏れがあるままリリースしてしまう」といった致命的な問題に繋がります。
この記事では、欠陥管理を単なる「バグ直し」で終わらせず、システムの信頼性を証明する「品質の履歴書」へと昇華させるための実践的なポイントと、そのまま現場で使える管理台帳の項目を解説します。
なぜバグは再発するのか？欠陥管理を「品質の履歴書」にすべき3つの理由
プロジェクトにおける「欠陥管理」とは、発見された不具合を記録し、修正から再テスト完了までの状態（ステータス）を正確に追跡するプロセスのことです。
なぜ、メールやチャットのやり取りだけでは不十分なのでしょうか。欠陥管理には以下の3つの重要な役割があります。
- 修正漏れと「二次バグ（デグレード）」を防ぐため： 見つかった不具合をすべてリスト化し、一つひとつ「完了」になるまで追いかけることで、対応漏れを防ぎます。また、修正によって他の箇所が壊れる「デグレード（先祖返り）」の検知にも役立ちます。
- 品質を「見える化」してリリース判定を行うため： バグの発生件数や推移（バグ曲線）を分析することで、「品質が安定してきたか」「まだテストが足りないか」を客観的に判断できます。これはリリース可否を決める重要な指標になります。
- 責任の所在と品質保証の「証跡」を残すため： 「誰が修正し、誰が再テストしてOKを出したか」を記録します。これは将来のトラブル時の原因究明や、お客様へ「これだけテストをやり切りました」と証明するための強力な証拠（履歴書）となります。
【失敗事例】メールと口頭でのバグ報告が招く「炎上」の始まり
注文管理機能のテストをしている、担当の佐々木さんと開発者のやり取りを見てみましょう。
注文管理担当
佐々木さん
ボタンを押しても出荷区分が更新されないバグがあります。昨日メールで言った分と合わせて、今日中に直してください！
出荷管理
開発者
分かりました、やっておきます。
翌日……
注文管理担当
佐々木さん
先週頼んだバグ、まだ直ってませんけど……
出荷管理
開発者
え？ メールで報告された検索バグの方は直しましたよ。もう一つは在庫チェックの件ですよね？
注文管理担当
佐々木さん
いえ、在庫じゃなくて商品チェックの方です！ あと、出荷区分の件もどうなりました？
出荷管理
開発者
出荷区分？ それは初耳ですが……
数日後の定例会議で、テスト進捗の遅れを報告した佐々木さんは、リーダーから厳しい追及を受けます。
連鎖する問題と「炎上」の始まり
数日後のチーム定例会議で、テスト進捗の遅れを報告した佐々木さんは、リーダーから厳しい追及を受けます。
注文管理リーダー
佐藤さん
現時点でのバグの件数は？残りは何件あって、いつ完了する予定なの？
注文管理担当
佐々木さん
えーっと……メールや口頭でやり取りしているだけで、正確な件数は把握していません……
注文管理リーダー
佐藤さん
はぁ！？じゃあ、いつテストが終わるか全く分からないってこと？ちなみに、見つかった『出荷区分のバグ』って、他の機能への影響は調べた？
注文管理担当
佐々木さん
あっ！出荷区分は先日の仕様変更で追加された項目なので……もしかしたら、他の関連画面も同じように対応が漏れてバグになっているかも……
一つの小さなバグ管理を怠った結果、「全体の進捗が見えない」「他の機能への影響調査（二次被害）が漏れる」という連鎖的な問題を引き起こし、プロジェクト全体を巻き込む炎上へと発展してしまいました。 「記録なき修正」は、プロジェクトを崩壊させる第一歩なのです。
迷走を断ち切る「欠陥管理プロセス」4つのステップ
欠陥を効率的かつ確実に処理するために、以下の4つのフローを徹底しましょう。
- ステップ1：欠陥の起票（報告）
- テスト実施者が不具合を見つけたら、速やかに管理表に登録します。「再現手順」「スクリーンショット」「発生環境」を詳しく記載し、開発者が迷わず調査できる状態にします。
- ステップ2：重要度の判定と割り振り
- PMやリーダーが内容を確認し、修正の優先順位を決めます。「業務が止まる致命的なもの」から「文言の微修正」まで、限られたリソースをどこに投下すべきか判断します。
- ステップ3：修正と「再テスト」
- 開発者が修正したら終わりではありません。必ずテスト実施者が「本当に直っているか」「他が壊れていないか」を改めて確認（再テスト）します。
- ステップ4：完了確認とクローズ
- 再テストで合格したものだけを「完了（クローズ）」とします。原因が「設計ミス」か「コーディングミス」かを分類しておくと、将来の工程改善に役立ちます。
【保存版】現場ですぐ使える！バグの「重要度ランク（A〜D）」判定基準
「どれから直せばいいか分からない」を防ぐため、運用ルールとしてそのまま使える判定基準を整理しました。
| ランク | 判定基準（テスト・受入時共通） | 役割・対応方針 |
|---|---|---|
| A：致命的 | ・システム全体が機能しない ・回避策がなくテストを中断せざるを得ない ・リリースに直結する致命的な遅延要因 | 最優先で修正が必要。全リソースを投入して解決を図る。 |
| B：重要 | ・主要機能が動作しない ・回避策はあるが業務運用に支障が出る ・スケジュールへの影響がある | Aの次に優先順位が高い。マイルストーンまでに必ず解消する。 |
| C：普通 | ・一部機能が動作しないが、テスト自体は継続可能 ・運用でカバー可能な範囲の不具合 | 計画的に修正を進める。運用回避でリリースするかの判断対象。 |
| D：軽微 | ・画面のレイアウト崩れ、誤字脱字 ・操作性に影響しない軽微な不備 | 他の修正のついで、または余裕があるタイミングで対応する。 |
【図解】欠陥管理フローと品質を承認する「ステークホルダーの役割」
体制図に基づき、誰が「起票」し、誰が「クローズ」の責任を持つかを明確にします。
誰が品質を承認するか（役割）
| 職務名称 | 欠陥管理における役割 | 目的 |
|---|---|---|
| 統括責任者 / PM | ・未解決バグ状況の把握 ・品質分析結果に基づくリリース可否の最終判断 | プロジェクト全体の品質に責任を持ち、「Go/No Go」の決断を下す。 |
| PL / リーダー | ・欠陥管理台帳のメンテナンス ・重要度の一次判定 ・仕様かバグかの切り分け | 現場の判断を統括し、開発とテストの交通整理を行う。 |
| ユニットリーダー | ・修正作業の割り振り ・修正内容のレビュー ・内部再テストの指揮 | 実際の修正品質を担保し、二次バグ（デグレード）を防ぐ。 |
| 品質保証（QA） | ・バグ曲線の分析と警鐘 ・欠陥管理プロセスの遵守状況の監査 | 第三者の視点で品質を客観視し、リスクを早期にアラートする。 |
欠陥管理フロー（お客様とシステム会社の対応手順）
| 手順（図の番号） | 担当 | 実施内容 |
|---|---|---|
| 1. 発見・連絡（①②） | 両者 | 欠陥が発見されたら、プロジェクト担当者へ連絡する。 |
| 2. 起票・記録（③） | 開発側 | 欠陥内容をヒアリングし、管理台帳へ記録する。 |
| 3. 判定（仕様orバグ）（④⑤） | 開発側 | 欠陥か仕様かを判定。「仕様」の場合は却下し、変更管理へ回す。 |
| 4. 原因調査（⑥⑦） | 開発側 | 「バグ」と判定された場合、原因を調査し対策を検討する。 |
| 5. 対策の合意（⑧⑨⑩） | 両者 | 対策内容をお客様と合意。影響が大きい場合は責任者の承認を得る。 |
| 6. 修正の実施（⑪⑫） | 開発側 | 開発者へ対策を指示し、設計書やプログラムへ反映する。 |
スプレッドシートでそのまま使える！「欠陥管理台帳」必須項目
そのままExcelやスプレッドシートの列名として使えるよう、記録すべき項目を整理しました。
| 分類 | 記録項目 | 項目内容 |
| 欠陥内容 | 発見日 | 欠陥の報告を受け付けた日 |
| 欠陥内容 | 欠陥の内容 | |
| 対応希望日 | 欠陥の対応を希望する日 | |
| 欠陥発見者 | 欠陥を発見した担当者 | |
| 状況 | 「受付」「原因調査中」「対策検討中」「承認済」「対策実施中」「却下」「完了」などの状態 | |
| 調査結果 | 欠陥原因 | 欠陥の原因（要件不備・未決定、仕様認識の齟齬、設計不備・漏れ、プログラム間違い、テストデータ不備、インフラ不備など） ※欠陥原因や発生工程は品質分析で活用するもの |
| 発生工程 | 欠陥が見つかった工程（要件定義、概要設計、詳細設計、開発、結合テスト、システムテスト、ユーザー受入テスト、移行など） ※欠陥原因や発生工程は品質分析で活用するもの |
|
| 重要度 | 欠陥が業務やプロジェクトに与える影響をランクで振り分け（上述の重要度ランク定義表を参照） | |
| 対策内容 | 欠陥の対策内容（対応内容やポイント、注意事項など） | |
| 調査担当者 | 調査をした担当者 | |
| 対策判定 | 採否判定 | 変更を承認するか、却下とするか |
| 採否確定日 | 採否が決定した日 | |
| 承認者（お客様） | お客様側の責任者 | |
| 承認者（システム会社） | システム会社側の責任者 | |
| 対応完了 | 対応担当者 | 対応した担当者 |
| 対応完了日 | 対応が完了した日 |
【プロの視点】自信を持ってリリースするための3つの運用術
最後に、欠陥管理を形骸化させず、プロジェクトを無事に着地させるための極意をお伝えします。
① 「却下」を恐れず、変更管理へ繋ぐ
現場で揉めやすいのが「これはバグか、仕様（変更）か」という議論です。欠陥管理で「仕様通り（バグではない）」と判定された場合は、毅然として「却下」ステータスにしましょう。 そして、必要であれば前回の記事で解説した「変更管理プロセス」へ回すことが重要です。ここを曖昧にして「ついでに直します」を繰り返すと、現場の工数が無限に削られます。
② 「クローズ」の権限はテスト側に持たせる
開発者が「直しました」と言っただけでは、そのバグは終わっていません。「完了（クローズ）」ステータスに変更できるのは、修正後に再テストを行ったテスト実施者（またはお客様）だけというルールを徹底してください。この「検収」のプロセスこそが、品質を守る最後の砦です。
③ Excelから脱却し、管理ツールを活用する
Excelでのバグ管理は、100件を超えると「同時編集ができない」「最新版が分からない」と限界が来ます。Redmine、Jira、Backlogといった課題管理ツールを活用すれば、履歴の検索性も上がり、バグ曲線のグラフ化も自動で行えます。
Excelでの管理に限界を感じているものの、上司へのツール導入の説得に悩んでいる方は、こちらの『脱Excelガイド（稟議の通し方とツール比較）』もあわせてご覧ください。Excelでのタスク管理、もう限界？脱Excelガイド｜ツール比較と稟議の通し方【PM向け】
まとめ：欠陥管理はシステムの信頼性を証明する「履歴書」である
欠陥管理は、単なるバグ直しの記録ではありません。そのシステムがいかに真摯にテストされ、磨き上げられてきたかを示す「履歴書」です。
- どんな小さな不具合も必ず可視化し、放置しない。
- 重要度（A〜D）とステータスを明確にし、現在地を常に把握する。
- 修正後の「再テスト」まで完了して、初めて解決とする。
適切な欠陥管理を行うことで、自信を持ってシステムをリリースできる体制を整えましょう。
本記事のバグ管理手法を実践しても、根本的な要件崩壊により「直しても直してもデグレが起きる」という終わりの見えない現場にいるなら、それは環境自体が限界を迎えているサインかもしれません。そんな過酷な炎上現場を生き抜いたあなたのスキルは、実は『社内SE』として非常に高く評価されます。心身が疲弊しきる前に、こちらの記事もあわせてご覧ください。【PM・リーダー向け】UATでデグレ連発は撤退のサイン？炎上現場を生き抜いたあなたが社内SEで無双できる理由
次回は、プロジェクト中に発生する様々な問題を管理する「課題管理」について解説します。ぜひ併せてお読みください。
