テストを増やしても品質は上がらない——PMが知るべき品質管理の本質と実践

「テストを増やせば品質が上がる」という誤解

リリース直前になって大量のバグが発覚し、テスト担当者が夜中まで残業している——そんな光景に覚えがある方は多いのではないでしょうか。このとき多くの現場では「テストが足りなかった」という反省が生まれ、次のプロジェクトではテスト工程を厚くしようという判断が下されます。しかし、そうして生まれた「テスト強化策」が根本的な改善をもたらすことは、残念ながらほとんどありません。

品質問題の根本原因の多くは、テスト工程にあるのではなく、要件定義や設計の段階にあります。欠陥は後工程で発見するほど修正コストが指数関数的に増大する——これをソフトウェア工学では「欠陥の早期発見の原則」と呼びます。PMBOKが定義する品質管理の思想もまさに同じです。本記事では、品質管理の全体像を整理したうえで、現場で機能する品質の「作り込み方」を具体的に解説します。

品質管理の3つのプロセス

PMBOKにおける品質管理は、以下の3プロセスで構成されています。

この3つの中で「品質コントロール（テストや検査）」だけに注目されがちですが、上流に位置する「品質計画」と「品質保証」の充実度が、最終的な成果物の品質を最も大きく左右します。品質はプロセスの中で作り込まれるものであり、テストで発見するものではないという認識の転換が、品質管理を根本から変えます。

品質計画：「何をもって品質とするか」を定義する

品質基準が曖昧だと何も守れない

品質計画において最初にすべきことは、品質基準（Quality Criteria）の定義です。「高品質なシステムを作る」という言葉は聞こえがよいですが、測定可能な基準がなければ達成の判断ができません。

具体的な品質基準の例として、レスポンスタイムの上限（たとえば「通常操作時の画面遷移は2秒以内」）、バグ密度の目標値（「リリース前の重大バグ件数ゼロ、軽微バグは1KLOCあたり0.5件以下」）、コードカバレッジの目標（「単体テストのラインカバレッジ80%以上」）などが挙げられます。こうした数値基準を持つことで、プロジェクト内での品質の達成度が客観的に評価できるようになります。

COQ（品質コスト）の概念を持つ

品質計画のもう一つの重要な概念が、COQ（Cost of Quality：品質コスト）です。品質に関するコストは「適合コスト」と「不適合コスト」の二種類に分けられます。

適合コストとは、品質基準を達成するために投資するコストです。要件レビューの時間、設計書のウォークスルー、テストの実施、CI/CDパイプラインの整備などが含まれます。一方、不適合コストとは品質基準を達成できなかったために発生するコストです。バグ修正コスト、再テストコスト、顧客対応コスト、そして信頼の毀損による機会損失がこれにあたります。

多くの現場では不適合コストを「避けられないもの」として受け入れていますが、実際には適合コストへの投資を増やすことで不適合コストを大幅に減らせます。上流工程でのレビュー1時間が、下流工程での10時間の修正作業を防ぐ——こういう認識を数字で示せるPMは、品質への投資を組織として正当化できます。

品質保証：プロセスそのものを評価する

QAはテストではなくプロセス監査

「QA（品質保証）」という言葉をテストと同義で使っている現場は多いですが、PMBOKにおけるQAはそれとは異なります。品質保証とは、プロジェクトのプロセスが品質計画で定義した基準・手順に沿って実行されているかを継続的に確認する活動です。

たとえば「要件定義書は必ずレビューを経て承認されているか」「コードレビューは定義されたチェックリストを使って実施されているか」「テストケースは要件にトレースされているか」——こうしたプロセスの遵守状況を監査し、逸脱があれば是正することがQAの本質です。

品質保証が機能しているプロジェクトでは、成果物の品質が工程をまたがって安定しやすくなります。なぜなら、欠陥を生みやすいプロセスの問題が早期に発見・修正されるからです。問題のある成果物を量産してからテストで発見するのではなく、問題が生まれる原因をプロセスレベルで取り除くのがQAの役割です。

レビューを「文化」として定着させる

現場レベルでQAを機能させるための最も有効な手段の一つが、コードレビューと設計レビューの文化づくりです。レビューは単なる「チェック作業」ではなく、欠陥が成果物に埋め込まれる前に取り除く「予防活動」です。

効果的なレビューには、チェックすべき観点を明示したチェックリストが欠かせません。「変数名は意図が伝わるか」「エラーハンドリングは適切か」「セキュリティ上の考慮漏れはないか」など、観点を構造化しておくことで、レビューの質が個人の経験に依存しにくくなります。また、レビューで指摘された内容を記録しておくことで、プロジェクト全体を通じた「よくある欠陥パターン」を把握でき、チーム全体の品質意識の向上にも繋げられます。

品質コントロール：成果物を検証する

テストは「発見の場」であって「作り直しの場」ではない

品質コントロール（QC）の代表的な活動がテストです。ただし、テストの目的は「品質の向上」ではなく「品質の確認」です。テストで欠陥が多数発見されること自体が、上流工程の品質作り込みが不十分だったことを示しています。

IT現場でのQCにおいて特に重要なのが、テストの設計と実施の分離です。テストケースを書く人と実施する人が同じだと、設計者の思い込みが検証の抜け漏れを生みます。また、要件から直接トレースされたテストケースであることの確認（トレーサビリティマトリクス）は、「一通りテストした」ではなく「すべての要件がテストされた」ことを証明するために必要です。

受入テストをゴールにしない

品質コントロールの最終局面である受入テスト（UAT）は、顧客が成果物を承認するための重要なマイルストーンです。しかしここで大量の課題が噴出するプロジェクトは、UATが「品質の網」として機能している状態であり、それは上流工程での品質作り込みが不十分なことを意味します。

理想的なUATは「最終確認の場」であり、致命的な問題が発見されることなく滞りなく完了するものです。そのためにはUAT開始前に、開発側で定義した品質基準がすべて達成されていることを内部で確認し、顧客に対して品質の状態を透明に報告できる状態にしておくことが必要です。「テストが始まってから心配する」ではなく「テストが始まるときには問題がほぼない状態を作る」——この発想の転換が品質管理の成熟を示します。

PMとして品質に向き合う姿勢

品質はPMが一人で作るものではありません。しかし品質に対する姿勢や文化を作るのはPMの責任です。「品質よりスケジュール」という圧力はプロジェクトの至るところから生まれます。そのとき、品質を守ることの経済的根拠（COQの考え方）を数字で示せること、品質基準を明文化して全員が参照できる状態にしておくこと、品質に関する懸念を早期にエスカレーションできる心理的安全性をチームに作ることが、PMとしての具体的な役割です。

品質のコストを「削れるもの」と見なす判断が、プロジェクトの後半を最も消耗させます。品質に投資することは、プロジェクト全体のコストと信頼を守ることだという視点を、チーム全体に浸透させることがPMの重要な使命の一つです。

まとめ：品質は検査で生まれず、設計で生まれる

テストを増やしてもプロジェクトの品質が根本的に改善されないのは、問題の発生源に手を入れていないからです。品質計画で基準を明確にし、品質保証でプロセスを監視し、品質コントロールで成果物を確認する——この三層構造を意識することで、品質は「運」ではなく「設計」の結果になります。

「品質は後から検査するもの」という思い込みを手放したとき、PMとしての視野は一段広がります。それは技術だけでなく、チームの働き方そのものを変える視点です。