品質は検査で担保するな——上流工程での「作り込み」と品質計画の立て方

「テストで品質を確保しよう」——この言葉を疑ったことがあるだろうか。多くのプロジェクトで品質管理はテストフェーズの話として扱われ、上流工程での品質設計はおざなりになる。しかし、下流で見つかる不具合の大半は、上流での設計判断や要件定義の曖昧さに起因している。本記事では、検査依存から脱却し、品質を「作り込む」ための計画立案と実践技法を具体的に解説する。

＜目次＞

「検査で品質を担保する」という思想が招く構造的失敗
1. 「品質＝テスト」という認知バイアスの正体
2. 「後で直せばいい」が積み重なる技術的負債の構造
上流工程での「品質の作り込み」——具体的な実践アプローチ
品質計画書を「実効性のあるドキュメント」として設計する
まとめ——品質を「作り込む」PMの思考と行動の転換点
よくある質問

「検査で品質を担保する」という思想が招く構造的失敗

あるERPシステム導入プロジェクトでの話だ。予算4億円、期間18ヶ月の案件だったが、テストフェーズに入って初めて「要件定義書に記載された業務フローと実際の現場フローが大きく乖離している」という致命的な問題が発覚した。修正コストは当初見積の2.3倍。リリースは4ヶ月延期された。このプロジェクトで上流工程のレビューに割かれた時間は、全体の7%に過ぎなかった。

これは特殊なケースではない。IBMの研究やNISTの報告でも繰り返し示されている通り、要件定義フェーズで見つかった欠陥の修正コストを1とすると、テストフェーズでは10〜15倍、リリース後では30〜100倍に膨れ上がる。それでも多くのPMが上流工程での品質活動を軽視するのはなぜか。

「品質＝テスト」という認知バイアスの正体

原因は構造的な誤解にある。テストは成果物が「目に見える」段階の活動だ。バグ票が出る、修正が走る、再テストが走る——これらは「品質管理をやっている感」を強く与える。一方、要件定義書のレビューや設計段階での品質チェックリストは、地味で可視化しにくい。スケジュールプレッシャーのある現場では真っ先に削られる。

PMBOKでは品質マネジメントを「品質計画（Plan Quality Management）」「品質保証（Manage Quality）」「品質コントロール（Control Quality）」の3プロセスで構成している。しかし実態として、多くのプロジェクトで機能しているのは最後の「品質コントロール（検査）」だけだ。前段の計画と保証が空洞化しているため、問題が下流に集中する。

「後で直せばいい」が積み重なる技術的負債の構造

上流での品質活動を省略すると、短期的にはスケジュールが進んでいるように見える。だが実際には「品質の負債」が静かに蓄積している。設計の曖昧さはコードに転写され、コードの複雑さはテストの困難さに転写される。あるシステム開発PMは「テストフェーズが始まった途端、バグ票が雪崩のように来た。毎日200件以上。何を直すと何が壊れるかわからない状態になった」と振り返る。これは品質の崩壊ではなく、上流で積み上げた負債の一括請求だった。

上流工程での「品質の作り込み」——具体的な実践アプローチ

品質を作り込むとは、問題が発生しにくい構造を設計段階から意図的に埋め込むことだ。これはQCD（品質・コスト・納期）のトレードオフではなく、むしろQCDを同時に改善する根本戦略である。

品質基準を「プロジェクト開始前」に合意する

最も効果的かつ最も省略されがちな活動が、品質基準の事前合意だ。「高品質なものを作る」という言葉は品質基準ではない。具体的に何をもって品質とするかを定義しなければ、チームも顧客も品質が達成されたかどうかを判断できない。

実践的な手順としては、まず品質属性（Quality Attributes）を列挙することから始める。機能要件の充足率、性能（レスポンスタイム）、可用性、セキュリティ、保守性、ユーザビリティ——これらのうち、このプロジェクトで最も重視するものは何かをステークホルダーと議論する。次に、各品質属性に計測可能な指標を紐づける。たとえば「性能」なら「ピーク時に100ユーザーが同時接続した状態でトップページの表示速度が2秒以内」といった形だ。

この合意形成プロセスは、後続の設計判断・開発方針・テスト範囲のすべての判断基準になる。品質基準が曖昧なまま進むプロジェクトでは、「これで十分か」の判断が担当者の主観に委ねられ、チーム内で認識が分断される。受入基準の合意形成については、受入基準の合意形成——「完了の定義」をステークホルダーと握る実践法も合わせて参照してほしい。

設計レビューを「通過儀礼」から「品質ゲート」に変える

多くのプロジェクトにはレビュープロセスが存在するが、形骸化していることが多い。「とりあえず資料を共有してコメントを募る」「会議に出席者がいるかどうかが主な関心事」という状態では、設計上の品質問題を上流で捕捉できない。

品質ゲートとしてのレビューは、明確な「通過条件」を持つ。たとえば要件定義レビューの通過条件として「全ユースケースに正常系・異常系の両方が記述されている」「非機能要件に数値目標が設定されている」「業務部門の代表者が内容を確認し、署名している」といった具体的なチェック項目を事前に定義する。これらの条件を満たさなければ、次フェーズには進めない。形骸化しないレビュー設計の詳細については、レビューを機能させる設計——形骸化しないレビュープロセスの作り方も参考になる。

コードレビューとペアワーク——開発段階の品質作り込み

設計フェーズを超えて開発フェーズでも、品質の作り込みは続く。コードレビューは多くの組織で行われているが、「レビューアが忙しくて2週間後にまとめてフィードバック」という状況では機能しない。効果的なコードレビューは小さく・速く・頻度高く行われる。プルリクエストのサイズを1機能・200行以内に絞り込み、24時間以内にレビューが完了する運用を設計したあるチームでは、テストフェーズでのバグ検出数が以前比で約40%減少した。

品質計画書を「実効性のあるドキュメント」として設計する

PMBOKが定義する品質マネジメント計画書は、多くのプロジェクトで「あることになっているドキュメント」として存在する。棚に眠り、プロジェクト終了後に「そういえばあったね」と思い出される。これを実際に機能させるためには、計画書の設計思想から見直す必要がある。

品質計画書に盛り込むべき5つの要素

実効性のある品質計画書には以下の5要素が必要だ。

品質目標と計測指標：前述の通り、具体的な数値目標と計測方法をセットで記述する。
品質活動のスケジュール：どのフェーズで、どのような品質活動（レビュー、テスト、監査など）を実施するかをWBSと紐づけて定義する。
役割と責任：誰が品質の判断権限を持ち、誰がゲートキーパーとして機能するかを明確化する。「全員が品質に責任を持つ」は実質的に「誰も責任を持たない」と同義だ。
不具合の分類と対応フロー：発見された不具合をどう分類し、誰が判断し、いつまでに対応するかのプロセスを事前定義する。これにより、テストフェーズでのバグ対応がパニックにならない。
品質の振り返りサイクル：計画した品質活動が実際に機能しているかを定期的に評価するプロセス。週次の品質メトリクスレビューや、フェーズ終了時の品質レトロスペクティブがこれに当たる。

品質計画を「生きた計画」にするための運用設計

品質計画書の最大の問題は「一度作ったら更新されない」ことだ。プロジェクトが進むにつれてリスクの性質は変化し、チームの習熟度も変わり、顧客の優先順位も動く。品質計画はこれらの変化に追従しなければ実態と乖離する。

あるプロジェクトでは、品質計画の主要指標（テストカバレッジ、コードレビュー実施率、重大バグ発生数）を週次の進捗報告に組み込んだ。数字が可視化されたことで、PMだけでなくチームメンバー全員が品質の状態をリアルタイムで把握できるようになった。「バグが多い週」の翌週には自然とコードレビューの頻度が上がるという文化的変容も生まれた。計画を「報告の材料」ではなく「チームの羅針盤」として機能させることが、品質計画を生きたものにする鍵だ。

後工程に「品質の借り」を持ち越さない判断設計

スケジュールプレッシャーの下では、「ここは後でちゃんとやる」という先送り判断が積み重なりやすい。この判断の積み重ねが、テストフェーズの地獄を生む。品質計画に「先送り判断のログ」を組み込むことを提案したい。品質基準を満たさないまま次フェーズに進む場合、その判断をログとして記録し、対応時期を明記する。これにより「なんとなく後回し」が可視化され、後工程での対応コストの予測精度が上がる。また不具合の再発防止についても、不具合管理と再発防止——同じ問題を二度起こさないプロセス設計を参考にしてほしい。