欠陥管理とは？バグの検出から解決までを体系的に管理する実践手法
欠陥管理はソフトウェアの欠陥（バグ）を検出・記録・分類・追跡・解決する体系的なプロセスです。欠陥ライフサイクル、重大度分類、メトリクス活用法を解説します。
欠陥管理とは
欠陥管理（Defect Management）とは、ソフトウェアの欠陥（バグ）を体系的に検出・記録・分類・追跡・解決するプロセスです。単にバグを修正するだけでなく、欠陥の傾向を分析して根本原因を特定し、同種の欠陥の再発を防止することまでを含みます。
ISTQBでは欠陥を「コンポーネントまたはシステムにおいて、要求された機能を実行する能力の欠如を引き起こす可能性のある不完全さまたは不備」と定義しています。欠陥は開発のあらゆる段階（要件定義、設計、実装、テスト）で混入し、検出が遅れるほど修正コストが増大します。
欠陥管理が適切に機能しているプロジェクトでは、欠陥の状態が常に可視化され、修正の優先順位が合理的に判断され、品質の改善傾向がデータで確認できます。逆に欠陥管理が不十分なプロジェクトでは、同じバグが繰り返し報告されたり、重大な欠陥が放置されたりする問題が発生します。
:::box-point ISTQBでは欠陥を「要求された機能を実行する能力の欠如を引き起こす可能性のある不完全さまたは不備」と定義しています。欠陥管理は単なるバグ修正ではなく、傾向分析による根本原因の特定と再発防止までを含む体系的なプロセスです。 :::
構成要素
欠陥のライフサイクル
| ステータス | 説明 |
|---|---|
| 新規（New） | 欠陥が報告された初期状態 |
| オープン（Open） | 欠陥として認定され、修正対応が開始された状態 |
| 修正中（In Progress） | 開発者が修正作業に着手した状態 |
| 修正済み（Fixed） | 修正が完了し、再テスト待ちの状態 |
| 再テスト（Retest） | テスターが修正の正当性を確認中の状態 |
| クローズ（Closed） | 修正が確認され、欠陥が解決済みの状態 |
| リオープン（Reopened） | 再テストで修正が不十分と判断され、再度対応が必要な状態 |
| 却下（Rejected） | 欠陥ではないと判断された状態（仕様通り、重複など） |
欠陥の分類基準
- 重大度（Severity）: 欠陥がシステムに与える技術的影響の大きさ。致命的/重大/中程度/軽微の4段階が一般的
- 優先度（Priority）: 修正の緊急性。即時/高/中/低の4段階。重大度と優先度は必ずしも一致しない
- 検出工程: 欠陥が検出された工程（設計レビュー、単体テスト、結合テスト、受入テストなど）
- 混入工程: 欠陥が作り込まれた工程（要件定義、設計、実装など）
実践的な使い方
ステップ1: 欠陥報告の標準化
欠陥を正確に記録するための報告フォーマットを標準化します。
- 欠陥ID: 自動採番による一意の識別子
- タイトル: 欠陥の内容を端的に表す1行の要約
- 再現手順: 欠陥を再現するための具体的な操作手順
- 期待結果と実際の結果: 何が起きるべきで、何が起きたかの明確な記述
- 環境情報: OS、ブラウザ、バージョンなどの実行環境
- スクリーンショットやログ: 欠陥の証拠となる補助情報
- 重大度と優先度: 報告者が初期判定し、トリアージで確定する
ステップ2: トリアージプロセスを運用する
報告された欠陥を評価し、対応方針を決定するトリアージを定期的に実施します。
- トリアージ会議を日次または隔日で開催し、新規欠陥の評価を行う
- 重大度と優先度を確定し、修正担当者を割り当てる
- 修正のスケジュール（次のスプリント、次のリリース、将来のリリース）を決定する
- 「修正しない」（仕様通り、回避策あり、修正コストが効果に見合わない）という判断も適切に行う
- 欠陥の重複を確認し、既存の欠陥との統合を行う
ステップ3: 欠陥メトリクスを活用する
欠陥データを分析し、品質の状態と傾向を把握します。
- 欠陥検出率: テスト工程ごとの欠陥検出数の推移
- 欠陥修正率: 報告された欠陥のうち修正完了した割合
- 欠陥密度: 成果物の規模（LOC、機能ポイントなど）あたりの欠陥数
- 平均修正時間: 欠陥の報告から修正完了までの平均期間
- 欠陥の残存曲線: 未解決欠陥数の時系列推移。収束傾向の確認に使用
- リオープン率: 修正後に再発する欠陥の割合。修正の品質を反映する
ステップ4: 根本原因分析と再発防止
欠陥データの傾向分析から根本原因を特定し、再発防止策を講じます。
- 混入工程の分析: 欠陥が多く作り込まれている工程を特定し、その工程のプロセスを改善する
- 欠陥パターンの分析: 繰り返し発生する欠陥のパターン（入力バリデーション不足、エラーハンドリング漏れなど）を特定する
- コードレビューやテストの改善: 頻出する欠陥パターンをレビュー観点やテストケースに反映する
活用場面
- ソフトウェア開発プロジェクト: JiraやAzure DevOpsなどのツールで欠陥を一元管理し、開発チームとテストチームの連携を効率化します
- システムテストフェーズ: 大量の欠陥が検出されるフェーズで、トリアージと優先度管理により限られた修正リソースを最適配分します
- 運用保守: 本番環境で発生するインシデントを欠陥管理プロセスに取り込み、恒久的な修正を追跡します
注意点
:::box-warning 欠陥管理では、重大度と優先度の混同やツールへの過信が典型的な落とし穴です。分類基準を明確に定義し、ツール外で報告された欠陥も漏れなく登録する運用を徹底してください。 :::
重大度と優先度の混同
重大度はシステムへの技術的影響、優先度はビジネス上の修正緊急性です。軽微な表示不具合でも、主要顧客に影響する場合は優先度が高くなります。この2つの軸を独立して評価することが重要です。
欠陥管理ツールの過信
ツールに登録されていない欠陥は「存在しない」ことになります。チャットや口頭で報告された欠陥も必ずツールに登録する運用を徹底しないと、欠陥の漏れが発生します。
欠陥数をKPIにすることの弊害
「検出された欠陥数が少ない=品質が高い」とは限りません。テストが不十分な場合も欠陥数は少なくなります。欠陥数だけでなく、テストカバレッジや欠陥密度と合わせて品質を評価することが必要です。
まとめ
欠陥管理は、欠陥のライフサイクルに沿った体系的な追跡と、メトリクスに基づく品質分析を組み合わせた管理手法です。報告の標準化、トリアージプロセスの運用、欠陥メトリクスの活用、根本原因分析と再発防止の4ステップを回すことで、プロジェクトの品質を継続的に改善できます。