「テスト計画は作った」で止まっていないか——形骸化の構造を解剖し、現場で”機能する”テスト計画に再設計する実践技法

＜目次＞

テスト計画が「飾り物」になる瞬間

プロジェクトの終盤、こんな光景を見たことはないだろうか。

「テスト計画書はあります。でも、今やっていることとは少し違いますね……」

誰もがそれを把握しながら、誰も修正しない。テスト計画書はフォルダの奥に眠り、現場は「感覚」と「経験」でテストを進める。そして終盤に大量のバグが発見され、「なぜこんなことが起きたのか」という後悔が繰り返される。

テスト計画の形骸化は、多くのプロジェクトで起きている構造的な問題だ。PMPの知識体系においても、品質管理は「品質計画→品質保証→品質コントロール」の三段階で設計されるが、テスト計画はその実行の核心を担うはずの文書である。にもかかわらず、現場では驚くほど機能していない。

なぜか。そして、どう変えるか。今回はその構造を解剖する。

多くの現場では、要件定義が完了してからテスト計画を作り始める。一見、順序として正しく見えるが、これが最初の罠だ。

テストは「要件を満たしているかを確認する行為」である以上、要件の解釈と同時進行で設計されるべきだ。後から書かれたテスト計画は、要件の「表面」だけをなぞりがちになり、設計段階での暗黙の前提や例外条件をカバーできない。

ある製造業のシステム導入プロジェクトでは、要件定義完了から2週間後にテスト計画を作成したが、その間に複数の仕様変更が発生していた。テスト計画はすでに「古い要件」に基づくものになっており、品質保証の実態がなかった。

テスト計画書の表紙には「QA担当者」の名前だけが並んでいないだろうか。PMや開発者、ビジネスオーナーが関与しないまま作られた計画は、プロジェクト全体の品質観とズレが生じやすい。

テスト計画が問うべき最も重要な問いは、「何をもって”完了”とするか」である。これはビジネス側の価値判断であり、開発側の技術的制約であり、PMの資源配分の問題でもある。テスターだけで答えが出る問いではない。

プロジェクトは変化する。スコープが変わり、スケジュールが圧縮され、前提条件が崩れる。しかしテスト計画だけは最初に作ったまま更新されないことが多い。

これはスケジュール管理の形骸化と同じ構造だ。作成した瞬間から現実と乖離し始め、誰も「使えるもの」として参照しなくなる。

実践的な改善策として最も効果的なのは、テスト計画の「骨格」を要件定義の段階から書き始めることだ。

具体的には、要件定義の各項目に対して「この要件はどのようにテストするか」という「テスト可能性の問い」をセットで立てる。要件が定義される瞬間に、そのテスト観点が議論の俎上に乗ることで、曖昧な要件が早期に発見される。

あるERPの導入プロジェクトでは、要件定義のワークショップにQAリードを参加させ、「この要件、どうテストしますか？」を議論の締めくくりに置くルールを作った。結果として、テスト計画の完成度が上がっただけでなく、要件の品質そのものが上がったという報告がある。

テスト計画が形骸化する理由の一つは、「何もかも一枚の文書に詰め込もうとする」ことにある。戦略レベルから個別テストケースまでが混在すると、誰も全体を把握できなくなる。

現場で機能するテスト計画は、次の3層に分けて管理するとよい。

第1層：テスト戦略（プロジェクト全体の品質方針）
何を優先的にテストするか、どのリスクを重点的に管理するか、品質基準は何か。PMとビジネスオーナーが承認する。
第2層：テスト計画（フェーズ・機能単位の計画）
スコープ、スケジュール、担当者、環境、入出力の定義。QAリードと開発リードが共同で作成・管理する。
第3層：テストケース（実行レベルの詳細）
具体的な手順と期待値。テスターが担当するが、第1・2層と整合していることを定期的に確認する。

この分離により、「計画が変わった」場合に更新が必要な層が明確になり、変更コストが下がる。