検証計画書の書き方と必須項目——発注者・PM向け実務ガイド

なぜ今、検証計画書の質が問われているのか

システム開発プロジェクトにおける品質トラブルの多くは、開発フェーズではなく検証フェーズの設計不足に起因しています。「何をどの順番で、誰が、どの基準で確認するか」が曖昧なまま検証が始まり、リリース直前になって重大な欠陥が発覚するケースは少なくありません。

こうした事態を防ぐための中核ドキュメントが、検証計画書です。しかし実務では、検証計画書がベンダー側の形式的な提出物として扱われ、発注側が内容を十分に精査しないまま承認されているケースが多く見られます。

検証計画書は単なる作業手順書ではありません。「何をもってシステムの品質合格とするか」を発注側とベンダー側が合意するための意思決定ドキュメントです。この認識が欠けていると、以下のような問題が連鎖的に発生します。

• 検証範囲の認識齟齬により、重要機能がテスト対象から漏れる
• 合格基準が曖昧なため、リリース判断を誰も主体的に下せなくなる
• 不具合発生時の責任の所在が不明確になり、対応が遅延する

情報システム担当者やPMクラスの方々にとって、検証計画書の書き方と必須項目を理解することは、ベンダーから提出された計画書の妥当性を見極めるためにも、自社でレビュー基準を設けるためにも不可欠なスキルになっています。

本記事では、検証計画書の基本的な定義からテスト計画書との違い、標準的な構成と各セクションの記載ポイント、発注側が見落としやすい落とし穴、承認前に使えるチェックリスト、そしてすぐに活用できるテンプレートまでを順に解説します。

検証計画書とは何か——テスト計画書との違いを整理する

「検証計画書とテスト計画書、どちらかあれば十分では？」——そう考える発注者やPMは少なくありません。しかし両者は目的も対象も判断基準の粒度も異なります。混同したまま承認プロセスを進めると、後フェーズで品質上の重大な抜け漏れが発覚するリスクがあります。

検証（Verification）と妥当性確認（Validation）の違い

まず用語を整理します。英語圏では「V&V」と略されるほど、この2つはセットで語られます。

• Verification（検証）：「正しくシステムを作っているか」を確認するプロセスです。設計書・仕様書どおりに実装されているかを問います。
• Validation（妥当性確認）：「正しいシステムを作っているか」を確認するプロセスです。業務要件・ビジネス目的を本当に満たしているかを問います。

たとえば「注文確定ボタンを押したらメールが送信される」という仕様どおりに動くことを確かめるのがVerification、「その仕様自体が購買フローの業務要件を正しく反映しているか」を問うのがValidationです。検証計画書はこの両方をカバーする文書として機能します。

テスト計画書との役割分担——何が違い、何が重なるか

下表に2つの文書の主な違いを整理します。

• 目的／検証計画書：要件・設計の適合性と業務目的への妥当性を確認する　／　テスト計画書：実装済みの機能が仕様どおりに動作するかを確認する
• 対象フェーズ／検証計画書：要件定義〜設計フェーズから策定を開始する　／　テスト計画書：開発完了後〜テスト実施フェーズが中心になる
• 判断基準の粒度／検証計画書：ビジネス要件・受入基準レベルで定義する　／　テスト計画書：テストケース・期待値レベルで定義する
• 主な作成者／検証計画書：発注者側PM・品質責任者が主導する　／　テスト計画書：ベンダーのテストリードが主導する

重なる部分もあります。受入テスト（UAT）の範囲や合否判定基準は、両文書に記載されることがあります。この重複箇所の整合が取れていないと、ベンダーと発注者の間で「合格の定義」がずれたまま検収を迎えるケースがあります。

誰が作るべきか——ベンダー任せにするリスク

検証計画書の策定をベンダーに一任しているプロジェクトは少なくありません。しかしこの文書が本来担う役割は、「発注者が何をもって完成と見なすか」の合意形成です。ベンダーが作成した場合、判断基準がベンダーの実装都合に寄りやすくなる傾向があります。

発注者・PMが両文書を混同したまま承認すると、次のような問題が起きます。

• テストがパスしても業務要件が満たされていない状態で検収が完了してしまう
• 受入基準が曖昧なため、追加改修の責任範囲でベンダーと認識が食い違う
• 稼働後に「想定していた使われ方と違う」という問題が顕在化する

検証計画書は発注者側が主体的に関与すべき文書です。ベンダーに作成を依頼する場合でも、受入基準・判断軸の定義は発注者が責任を持って確認・承認するプロセスを設けることが重要です。

検証計画書の全体構成——標準的な8つのセクション

検証計画書に何をどの順で書くべきか、迷う担当者は少なくありません。セクション構成が不明瞭なまま作成を進めると、レビュー時に「何が書かれていないか」を発見しにくくなります。まず全体像を把握してから個々の項目に入ることで、抜け漏れを防ぎやすくなります。

標準的な検証計画書は、以下の8つのセクションで構成されます。各セクションの目的と、主に誰が責任を持つべきかを整理しました。

責任者の欄に「発注側」とある項目は、ベンダー任せにすると後のトラブルにつながりやすい箇所です。特に合格基準（Exit Criteria）は、発注側が主体的に定めなければ、ベンダー都合の緩い基準が通ってしまうリスクがあります。

次のセクションでは、この8項目それぞれについて、具体的な記載内容と注意点を順に解説します。

各セクションの書き方——項目別の記載ポイントと注意点

検証計画書の構成が整っていても、各セクションの記載内容が薄ければ、意思決定には使えません。ここでは標準的な8つのセクションごとに、何を書くべきか・よくある不備・発注側が確認すべき視点を整理します。

①目的とスコープ——何を検証し、何を検証しないかを明示する

このセクションでは、「なぜこの検証を行うのか」という目的と、「どこまでが今回の対象か」というスコープを明記します。目的は「品質確認のため」のような抽象表現ではなく、「本番リリース可否を判定するための受け入れ検証」など、判断の根拠になる形で書きます。

よくある不備は、目的が書かれていてもスコープが曖昧なケースです。発注側は「今回の検証で何が保証されるのか」を読み取れるか確認してください。

②検証対象と対象外の定義——境界線を引くことで手戻りを防ぐ

機能・画面・データ・連携先ごとに、対象と対象外を一覧形式で示します。対象外の理由も併記することで、後から「なぜここは検証していないのか」という認識のズレが防げます。

発注側は、対象外とされた項目が本当に除外してよいものかを確認する必要があります。ベンダー都合で対象外になっているケースが少なくないため、除外理由の論拠を必ず確認してください。

③検証観点と判定基準——「合格」の定義が曖昧だと判定できない

検証観点は「何を確かめるか」の軸であり、判定基準は「どうなれば合格か」の定義です。たとえば性能検証であれば「同時アクセス100件で応答時間が3秒以内」のように、数値で表現できる形が理想です。

「問題がないこと」「正常に動作すること」という記述は判定基準として機能しません。発注側はすべての観点に対して定量・定性の合格条件が明記されているかを確認してください。

④検証方法と環境——本番相当の環境が確保されているか

手動テスト・自動テスト・負荷ツールの使用など、実施方法を具体的に記載します。あわせて、検証環境が本番構成とどの程度一致しているかを明記することが重要です。

本番と大きく異なる環境で行われた検証は、リリース後の障害を防ぐ効果が限定的になります。環境の差異がある場合は、その影響範囲をベンダーに説明させるのが適切です。

⑤スケジュールと工程——マイルストーンと前提条件を明記する

開始日・終了日・各フェーズの期間だけでなく、「何が揃っていれば開始できるか」という前提条件を明記します。たとえば「テストデータの準備完了」「環境構築の完了」などです。

前提条件が未記載の計画書は、遅延が発生したときに責任の所在が曖昧になります。発注側の作業が前提になっている項目は特に注意して確認してください。

⑥体制と役割分担——発注側の関与範囲をここで決める

ベンダー側の担当者だけでなく、発注側が誰をアサインし、どの工程で何を判断するかを明記します。受け入れ検証の最終承認者・エスカレーション先・問い合わせ窓口なども含めます。

発注側の役割が「確認」とだけ書かれているケースでは、実際にどれだけの工数が必要かを見積もれません。承認の権限者を具体的に記載するよう求めることが重要です。

⑦リスクと前提条件——計画通りに進まない場合の判断軸

想定されるリスク（環境トラブル・データ不備・人員変更など）と、それぞれの対応策・判断基準を記載します。「リスク：なし」と記載された計画書は、実態の考慮が不十分なことが多いため注意が必要です。

発注側は、リスクが顕在化したときに誰がどう判断するかのエスカレーションフローが書かれているかを確認してください。

⑧成果物と報告ルール——何をもって検証完了とするか

検証終了時に提出される成果物（検証結果報告書・エビデンス一覧・不具合管理表など）のリストと、報告の頻度・形式・宛先を明記します。「完了をもって報告」では、途中の状況が発注側に伝わりません。

検証完了の定義——たとえば「判定基準をすべて満たし、残存する不具合が軽微なものに限られること」——が明文化されているかどうかが、最終的なリリース判断を下すうえで重要なポイントになります。

発注者・PMが見落としやすい3つの落とし穴

検証計画書の形式が整っていても、実際の検証フェーズで「合否が判断できない」「本番稼働後に不具合が発覚した」といった問題が起きるケースは少なくありません。原因の多くは、ベンダー側の技術的なミスではなく、発注者・PMによる計画書レビュー時の見落としにあります。特に注意が必要な落とし穴を3点、整理します。

落とし穴①：判定基準が定性的で合否を判断できない

「正常に動作すること」「画面表示が適切であること」といった記述は、一見もっともらしく見えますが、合否を客観的に判断する根拠になりません。検証担当者によって判断が変わるため、実質的に機能しない基準です。

承認前に確認すべきポイントは、判定基準が数値や具体的な状態で定義されているかどうかです。たとえば「検索結果が3秒以内に表示されること」「エラー発生時に指定のメッセージが表示され、処理が中断されること」のように、誰が見ても同じ結論に至る記述になっているかを確認してください。

落とし穴②：非機能要件が検証スコープから抜け落ちる

機能要件（画面・帳票・データ連携など）の検証に集中するあまり、性能・セキュリティ・可用性といった非機能要件が検証スコープに含まれていないケースがあります。これらは本番稼働後に問題が顕在化しやすく、かつ対処コストが高くなりやすい領域です。

検証計画書を確認する際は、スコープ一覧に非機能要件の項目が明示されているかを必ずチェックしてください。「同時接続100件時のレスポンスタイム」「個人情報項目の暗号化状態の確認」「障害発生時のフェイルオーバー動作」など、具体的な検証項目として計画書に落とし込まれているかどうかが判断の基準になります。

落とし穴③：検証環境の本番乖離を見逃したまま承認する

検証環境が本番環境と大きく異なる構成のまま検証を進め、「検証はパスしたが本番では動かない」という事態が起きることがあります。サーバースペック・ミドルウェアのバージョン・外部連携先の向き先（本番API vs スタブ）などが代表的な乖離ポイントです。

検証計画書には、検証環境の構成概要と、本番環境との差異が明記されている必要があります。差異が存在する場合は「その差異が検証結果に影響を与えるリスクをどう評価しているか」まで確認することで、承認後のリスクを大幅に低減できます。

検証計画書レビュー用チェックリスト——承認前に確認すべき15項目

検証計画書を受け取った際、「記載がある」という事実だけを確認しても承認判断としては不十分です。重要なのは、記載内容がプロジェクトの実態に即しているかどうかです。以下の15項目は、記載の有無だけでなく「内容の質」を評価するための観点として活用してください。

目的・スコープの妥当性（項目1〜3）

1. 検証目的が要件定義と対応しているか
   単に「品質確認のため」といった抽象的な記述ではなく、要件定義書や仕様書のどの項目を検証するのかが明示されているかを確認します。対応関係が示されていない場合、何を保証する計画なのかが曖昧なままになります。
2. 検証スコープの境界が明記されているか
   「何を検証するか」と同時に「何を検証しないか」が記載されているかを確認します。除外項目の理由も添えられていると、後工程でのスコープ外争いを防ぎやすくなります。
3. スコープが実際のシステム構成と一致しているか
   外部連携システムやクラウド環境など、アーキテクチャに照らして漏れがないかを確認します。記載と実態のズレは、後から発覚した際の手戻りコストが大きくなります。

体制・役割分担の明確さ（項目4〜6）

4. 検証実施者と承認者が具体的に記載されているか
   「ベンダー側」「発注者側」といった括り方ではなく、担当者名または役割名が明示されているかを確認します。曖昧な場合、問題発生時の責任の所在が不明確になります。
5. 発注者側の関与範囲が定義されているか
   受入検証（UAT）における発注者の作業量・期間・判断基準が記載されているかを確認します。関与範囲が不明だと、工数の見積もりが社内で立てられません。
6. 不具合発生時のエスカレーションルートが明示されているか
   誰が判断し、誰に報告し、どのタイミングで承認判断が必要かのフローが書かれているかを確認します。記載がない場合、重大な不具合が見落とされるリスクがあります。

テスト設計の妥当性（項目7〜10）

7. テスト種別ごとの実施タイミングが整理されているか
   単体・結合・システム・受入の各フェーズが、スケジュールとともに明示されているかを確認します。種別の記載があっても時系列が不明な計画は実行可能性を判断できません。
8. テストケースの設計根拠が示されているか
   「網羅的にテストする」といった記述にとどまらず、同値分割や境界値分析など、どのような設計手法を用いるかが記載されているかを確認します。
9. 非機能要件（性能・セキュリティ等）の検証方針が含まれているか
   機能検証のみで非機能要件への言及がない計画書は、本番稼働後のトラブル要因になりやすいです。性能目標値とその測定方法が具体的に記載されているかを確認します。
10. テストデータの準備方針が明記されているか
    本番データの利用可否、マスキング処理の有無、データ量の規模感が記載されているかを確認します。テストデータの準備不足は、検証の実効性を大きく損なう要因です。

合否判定基準の具体性（項目11〜13）

11. 合否判定の基準が数値で示されているか
    「不具合が解消されること」といった定性的な基準ではなく、重大度別の残存不具合数や応答時間の閾値など、数値で判断できる基準が設定されているかを確認します。
12. 不具合の重要度分類と対応方針が定義されているか
    致命的・重大・軽微といった分類基準と、それぞれの対処期限・判断者が記載されているかを確認します。分類が曖昧な場合、本番リリース判断がブレやすくなります。
13. 検証完了の定義が明確か
    「何をもって検証完了とするか」が記載されているかを確認します。完了定義のない計画書では、いつでも「まだ終わっていない」という状況が起きえます。

スケジュール・リスクの現実性（項目14〜15）

14. 検証期間が開発スケジュールと整合しているか
    開発の完了予定日と検証開始日の間に十分なバッファがあるかを確認します。開発遅延が発生した場合の検証期間の圧縮リスクについての記載があるかも確認ポイントです。
15. リスクと対応策がセットで記載されているか
    「テスト環境の準備遅延」「外部APIの仕様変更」など、プロジェクト固有のリスクが列挙され、それぞれの対応策または代替手段が示されているかを確認します。リスクの列挙だけで対応策がない計画書は、形式的な記載にとどまっていることが多いです。

この15項目をチェックした結果、複数の項目で「記載なし」または「内容が抽象的」と判断された場合は、承認を保留してベンダーに差し戻すことを検討してください。特に項目11〜13（合否判定基準）と項目4〜6（体制・役割）に不備がある計画書は、検証フェーズに入ってから判断が止まるケースが少なくありません。

検証計画書テンプレート——コピーして使えるセクション構成サンプル

以下は、Word・Excelどちらでも転用できる検証計画書のセクション構成サンプルです。各セクションには記載例を添えていますので、文体や粒度のイメージをつかむ参考としてご活用ください。

テンプレートの使い方と注意点——そのままコピーする前に確認すること

このテンプレートはあくまで構成の「型」です。プロジェクトの規模・業種・契約形態によって、省略できるセクションと絶対に外せないセクションが異なります。コピーする前に、以下の3点を確認してください。

• スコープの確認：検証対象がシステム全体なのか、特定機能に限定されるのかを先に定義する
• 責任分界点の確認：発注者とベンダーのどちらが各セクションを記載・承認するかを合意する
• 改訂ルールの確認：計画変更が生じた場合の版管理ルールを文書化する

セクション別サンプル記載例

以下の構成をそのまま見出しとして使用できます。記載例は実際の文体・粒度をイメージするための参考文です。

1. 文書管理情報
   記載例：「文書番号：TEST-2025-001 ／ 版数：1.0 ／ 作成日：2025年○月○日 ／ 作成者：○○株式会社 ××部 ○○氏 ／ 承認者：△△」
2. 検証の目的と対象範囲
   記載例：「本検証は、受発注管理システムの新規注文登録機能が要件定義書（Rev2.1）の仕様を満たすことを確認することを目的とする。対象は注文登録画面および在庫連携APIとし、帳票出力機能は対象外とする。」
3. 検証環境・前提条件
   記載例：「検証はステージング環境（本番相当のデータ量・設定）で実施する。本番データの使用は不可とし、マスキング処理済みのサンプルデータを用いる。」
4. 検証項目一覧と合否判定基準
   記載例：「各テストケースにはID・検証内容・期待結果・判定基準を記載する。合否は『期待結果と一致する場合をPASS』と定義し、目視確認が必要な項目は検証担当者2名による確認を必須とする。」
5. スケジュールと体制
   記載例：「検証期間は○月○日〜○月○日（10営業日）。検証リーダー：○○、検証担当：△△・□□。発注者側の立会確認日は○月○日を予定する。」
6. 不具合管理ルール
   記載例：「発見された不具合はBTSに登録し、重大度（Critical／High／Medium／Low）で分類する。Criticalは発見当日中にPMへ報告し、対応方針を翌営業日までに確定する。」
7. 完了基準と成果物一覧
   記載例：「全テストケースの実施完了、かつCritical・High不具合の残件ゼロを完了条件とする。成果物は検証結果報告書・不具合一覧・エビデンス一式とする。」
8. リスクと対応策
   記載例：「外部APIの接続障害により検証が中断するリスクがある。発生時はモックを使用して継続し、本接続での再確認を別途実施する。」

上記の8セクションは、前のセクションで解説した標準構成と対応しています。各セクションの記載粒度がこのサンプルと大きく乖離している場合は、情報の過不足がないかをレビュー時に確認してください。

まとめ——検証計画書は「品質の合意書」として機能させる

検証計画書は、テストの手順を記録するための行政的な書類ではありません。発注側とベンダーが「何をもって品質合格とみなすか」を事前に合意するための、意思決定ドキュメントです。この認識の違いが、プロジェクト後半における手戻りや品質トラブルの発生率に直結します。

本記事では、以下のポイントを中心に解説してきました。

• 検証計画書とテスト計画書の違い：テスト計画書が実施手順に焦点を当てるのに対し、検証計画書は「何を根拠に合格と判断するか」という合意基準の策定に重点を置きます。
• 標準的な8つのセクション構成：目的・スコープ・合格基準・役割分担・スケジュール・環境条件・リスク・承認プロセスを網羅することで、双方の認識ズレを防ぎます。
• 発注側が見落としやすい落とし穴：合格基準の曖昧な定義、非機能要件の検証漏れ、承認権限の未明確化は、後工程で深刻な問題を引き起こしやすい箇所です。
• 15項目のチェックリストと活用可能なテンプレート：ベンダー提出物のレビューと自社作成の両面で、抜け漏れを構造的に防ぐ手段として活用できます。

実務への次のアクションとして、まず既存プロジェクトの検証計画書に「合格基準が数値で記載されているか」を確認することをお勧めします。「問題がないこと」「正常に動作すること」といった定性的な表現が残っている場合は、ベンダーと協議のうえ、測定可能な基準へ書き直すことが優先事項になります。

検証計画書の書き方・作り方を整備することは、単なる書類管理の改善ではありません。発注側がプロジェクトの品質水準をコントロールするための、最も実効性の高い手段のひとつです。