はじめに
「品質管理計画」と言われると、多くの発注側担当者は「テスト計画のことだろう」と考えます。もちろんテストは品質を確認する重要な手段ですが、テストだけに頼った品質管理計画は、プロジェクトの後半で必ず手戻りを生みます。
テスト計画の立て方｜品質を担保する3つの観点で解説したテストは、あくまで「品質を検証する」工程です。品質管理計画は、それよりも前の段階——どういう品質を目指し、どのように作り込み、どう検証するか——を定義するものです。今回は、テスト計画だけでは不十分な理由と、発注側が主導すべき品質管理計画の作り方を整理します。
「検証」だけでは品質は作れない
品質管理には「作り込み」と「検証」という2つの側面があります。
- 作り込み：設計・開発の段階で、品質を高めるために行う活動（レビュー、コーディング規約の順守、設計書のダブルチェックなど）
- 検証：作られたものが要求を満たしているかを確認する活動（単体テスト、結合テスト、受け入れテストなど）
テスト計画は「検証」のみをカバーします。しかし、作り込みが不十分なまま検証工程に入ると、テストで見つかった不具合の修正が後工程に集中し、「不具合疑い」と「不具合確定」を同じ表で管理してはいけない理由で触れたような不具合管理の混乱を招きます。品質管理計画では、作り込みの活動も明文化しておく必要があります。
品質管理計画に含めるべき要素
発注側として、品質管理計画に最低限含めるべき要素は以下の5つです。
1. 品質目標：バグ密度、性能基準など、何をもって「品質が十分」と判断するかの数値・基準
2. 作り込み活動：設計レビューの実施タイミング・参加者・観点、コーディング規約の有無
3. 検証活動：単体・結合・受け入れテストの範囲と責任分担（テスト計画の立て方と連動）
4. 品質メトリクスの収集・報告方法：不具合件数、レビュー指摘件数などを、どの頻度で・誰に報告するか
5. 品質が基準を下回った場合の対応ルール：追加レビュー、リリース延期の判断基準など
これらは、プロジェクト計画書（プロジェクト計画書は「誰のための文書」なのか参照）の一部として、あるいは独立した品質管理計画書として、プロジェクト初期に合意しておくべき内容です。
ベンダー任せにすると起きること
品質管理計画の作成をベンダーに一任すると、以下のような問題が起きやすくなります。
- 品質目標が「業界標準」程度の一般論で済まされ、このプロジェクト固有のリスクを反映していない
- レビュー活動が形式的になり、「実施した」という記録だけが残る
- 品質メトリクスが報告されず、品質状況がプロジェクト終盤まで可視化されない
発注側は、品質管理計画を「ベンダーの内部プロセス」として丸投げせず、少なくとも品質目標とメトリクスの報告方法については、自ら確認・合意するプロセスを持つべきです。これはリスク管理表の作り方と運用で触れた「ベンダー任せにしない管理」と同じ考え方です。
進捗報告に品質メトリクスを組み込む
品質管理計画を作っても、その後の運用でメトリクスが報告されなければ意味がありません。実務上は、週次・月次の進捗報告のフォーマットに、品質メトリクス（レビュー指摘件数、バグ件数の推移など）を組み込んでおくことをお勧めします。
進捗報告の「大丈夫です」を鵜呑みにしないための4つのチェック方法でも触れた通り、「進捗は順調です」という言葉だけでは、品質の実態は分かりません。数値として品質状況が見えていれば、終盤に差し迫った品質問題を早期に察知できます。
まとめ
品質管理計画は、テスト計画だけでは代替できません。設計・開発段階の「作り込み」活動を含めて計画し、品質目標とメトリクスをプロジェクト初期に合意し、進捗報告の中で継続的に可視化する——この3つを押さえることで、プロジェクト終盤での品質問題の発覚を防ぐことができます。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント