【初心者必見】プロジェクトマネジメントの欠陥管理とは？欠陥管理の目的と手順を解説

システム開発のプロジェクトマネージャーを任命されたけど、欠陥管理はどうすればいいの？
そもそも欠陥管理ってなに？
欠陥管理のやり方がわからない？

システム開発のプロジェクトでは必ず欠陥（バグ）が埋め込まれます。そのため、欠陥が発見された時の管理方法や運用フローをプロジェクト計画書に記載することが重要です。

今回は、プロジェクトにおける欠陥管理とは何か？プロジェクト計画に記載すべき欠陥管理のポイントをわかりやすく解説します。

前回のおさらい（プロジェクト計画の書き方）
プロジェクトにおける欠陥管理とは？
- お客様とシステム担当者の欠陥対応事例
- 場当たり的に欠陥を対応すると大変なことに
欠陥管理のやり方
- 欠陥管理のフロー図
欠陥管理で記録すべき項目
欠陥を適切に管理してプロジェクトを成功に導こう

前回のおさらい（プロジェクト計画の書き方）

これまで、プロジェクトを成功させるためにプロジェクト計画を立てること、そしてプロジェクト計画の最初は「プロジェクト概要」をまとめることを解説しました。

プロジェクト概要がまとまったら、次はプロジェクト計画を詳細に落とし込んでいきます。プロジェクト計画でやるべきことは、そのプロジェクト概要を含めて11項目あります。

これらはプロジェクトを円滑に運営するための重要なガイドと言えるものです。この11項目をプロジェクト計画書にまとめ上げ、ゴールに向かってプロジェクトをスタートしましょう。

今回は、欠陥管理を解説します。

プロジェクトにおける欠陥管理とは？

欠陥とは、プロジェクトの全工程で発見される機能要件やシステム仕様の不備や障害を指します。これら欠陥を漏れることなく対処することで品質向上を図ることが欠陥管理の目的です。

欠陥は、プログラム開発後のテストで発見されたバグだけではなく、上流工程の要件定義や設計で埋め込まれる欠陥もあります。設計段階の考慮不足、仕様通りにプログラミングされずにテストで発見されたバグ、お客様が受入れテストで動作確認時に発見した業務と異なる動作も全て管理対象の欠陥になります。

これら欠陥を管理しないとどうなるでしょうか？

お客様とシステム担当者の欠陥対応事例

とあるシステム開発で、開発完了後のテストを進めているプロジェクト。
※登場人物はこちらの「システム開発の体制図サンプル」に合わせています。

ある時、注文管理機能の注文登録画面のテストをしていると

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

またバグが見つかりました。
注文登録画面で登録ボタンをクリックしても
出荷区分が更新されないから修正してください。

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

分かりました。
昨日聞いたバグと合わせて
今日中に修正しておきます。

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

先週連絡した２つのバグは修正完了していますか？
まだ連絡がありませんが・・・

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

え？先週中に１つは修正完了したと
メールしましたが見てませんか？
検索処理のバグの方を修正しています。

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

わかりました、確認します。
でも、先に修正してほしかったのは
もう１つの方だったんだけど・・・

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

そうなんですか？
ではもう１つもすぐに修正します。
バグは在庫チェックの処理でしたよね？

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

いや、在庫チェックじゃなくて、
商品チェックの処理です。（大丈夫かなあ・・・）

場当たり的に欠陥を対応すると大変なことに

この事例のように、欠陥を発見しても場当たり的な対応では欠陥が再発したり、欠陥を漏れなく対応することは難しくなります。欠陥内容や優先順を口頭ベースで伝えるだけでは伝達ミスが発生してさらに問題を引き起こすことにつながります。

その後、システム開発会社の注文管理チームのミーティングで、欠陥の対応遅れで進捗が遅延していることを報告すると

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

現時点の欠陥の状況を教えてください。
何件発見されて、何件解消しているの？
残りは何件で、いつ完了する予定ですか？

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

えーっと・・・
欠陥はメールや口頭でやりとりしているだけで、
件数を把握していません。

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

では残りの欠陥がいつ完了するかを確認してください。
それと見つかった欠陥は他の機能に影響するものはないですか？

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

あ！出荷区分が更新されないバグが見つかったのですが、
出荷区分は先日の変更要求で追加された項目なので、
もしかしたら他の画面も同じように対応できていないかも・・・

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

他の画面の概要設計に出荷区分が追加されているか
確認してください。
念のため、出荷管理リーダーの小林さんにも共有して
再発防止を検討しないと！

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

わかりました。
（欠陥をしっかり記録しておけばよかったなあ）

このように、欠陥を発見したら速やかに記録し、優先順を決めて漏れなく対応する必要があります。欠陥の対応内容によって仕様変更やスケジュール遅延がある場合は、お客様と協議が必要になることもあります。

そのため、プロジェクトの全工程で発見した欠陥は必ず文書化し、プロジェクトに参画するすべての方（ステークホルダー）で共有して、お互いの責任者の承認をもって反映する仕組みをプロジェクト計画段階で合意しておく必要があるわけです。

お客様と欠陥を管理する方法を決めてプロジェクト計画に明記しましょう。
プロジェクト内で欠陥を共有し、関連する部分の影響確認を行いましょう。
同じような欠陥が潜んでいないか調査して漏れなく対応しましょう。
欠陥内容をプロジェクト内で周知することで再発防止を実施しましょう。
欠陥に伴う変更は、お互いの責任者の承認後に反映しましょう。

欠陥管理のやり方

欠陥管理の流れはどのようになるでしょうか。
以下に欠陥管理のフロー図とポイントをまとめます。

欠陥管理のフロー図

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

欠陥管理で記録すべき項目

欠陥管理として記録すべき項目を下記にまとめます。これらを横に並べて一覧表形式で利用してもよいでしょう。

分類	記録項目	項目内容
欠陥内容	発見日	欠陥の報告を受け付けた日
	欠陥内容	欠陥の内容
	対応希望日	欠陥の対応を希望する日
	欠陥発見者	欠陥を発見した担当者
	状況	「受付」「原因調査中」「対策検討中」「承認済」「対策実施中」「却下」「完了」などの状態
調査結果	欠陥原因	欠陥の原因（要件不備・未決定、仕様認識の齟齬、設計不備・漏れ、プログラム間違い、テストデータ不備、インフラ不備など） ※欠陥原因や発生工程は品質分析で活用するもの
	発生工程	欠陥が見つかった工程（要件定義、概要設計、詳細設計、開発、結合テスト、システムテスト、ユーザー受入テスト、移行など） ※欠陥原因や発生工程は品質分析で活用するもの
	重要度	欠陥が業務やプロジェクトに与える影響を下記のようなランクで振り分け（Ａが最高ランク、Ｄが最低ランク）テスト時を例に記載Ａ：システム全体が機能しない欠陥で、その欠陥を回避する対策も無くてテストが続行できない場合Ｂ：システム全体が機能しない欠陥だが、その欠陥を回避する対策がありテストを続行できる場合Ｃ：システムの一部が機能しない欠陥だが、引き続きテストが続行できる場合Ｄ：見つかった欠陥部分だけが機能せず、引き続きテストが続行できる場合お客様の受入テスト時の例を記載Ａ：欠陥が見つかったテストケースは中断し、その欠陥が解消されなければテストが続行できない、もしくはスケジュール遅延する場合Ｂ：欠陥が見つかったテストケースは中断するが、引き続きテストを続行できる（スケジュールも遅延しない）場合Ｃ：欠陥が見つかったが、テストケースを中断せずにテストを続行できる（スケジュールも遅延しない）場合
	対策内容	欠陥の対策内容（対応内容やポイント、注意事項など）
	調査担当者	調査をした担当者
対策判定	採否判定	変更を承認するか、却下とするか
	採否確定日	採否が決定した日
	承認者（お客様）	お客様側の責任者
	承認者（システム会社）	システム会社側の責任者
対応完了	対応担当者	対応した担当者
対応完了	対応完了日	対応が完了した日