テスト計画書の読み方【発注者向け】承認前に確認すべき5つのポイントとチェックリスト

開発会社からテスト計画書が届いたとき、「何を確認すればいいのか分からない」「とりあえず承認したけど、これで良かったのか不安」という経験はないでしょうか。

テスト計画書は、システム開発の品質を保証するための重要なドキュメントです。しかし、ITエンジニアではない発注者の方が読むと、専門用語が並んでいてどこに注目すればよいか分からないことも少なくありません。

この記事では、テスト計画書の各項目の意味から発注者が承認前に確認すべき5つのポイント、そしてそのまま使える承認チェックシートまで解説します。「とりあえず承認」から「根拠を持った承認」へ。この記事を読み終えれば、自信を持ってテスト計画書を確認できるようになります。

テスト計画書とは何か（発注者が知っておくべき基本）

テスト計画書の目的

テスト計画書とは、「何をテストするか」「どのような基準で合格・不合格を判定するか」を開発会社と発注者が事前に合意するためのドキュメントです。

重要なのは、テスト計画書は開発者だけが読むものではないという点です。発注者がテスト計画書を確認・承認することで、はじめて「このテストで品質が保証された」という認識を双方で共有できます。

システム開発における品質トラブルの多くは、テストが終わった後に「こんなはずじゃなかった」という認識のずれから発生します。テスト計画書の段階で「何をどこまでテストするか」を合意しておくことが、後のトラブルを防ぐ最大の予防策になります。

テスト計画書・テスト仕様書・テスト結果報告書の違い

テスト関連のドキュメントには複数の種類があります。発注者として受け取る可能性があるのは主に次の3つです。

ドキュメント	タイミング	内容
テスト計画書	テスト開始前	何をテストするか（範囲・方針・基準）
テスト仕様書	テスト実施中	どのようにテストするか（具体的なケース）
テスト結果報告書	テスト完了後	テストの結果（バグ件数・合否・未解決事項）

SCROLL→

このうち発注者が最も重要に確認すべきタイミングは、テスト計画書（テスト前） と テスト結果報告書（テスト後） の2回です。テスト計画書で「何をテストするか」を確認し、テスト結果報告書で「計画通りに実施されたか」を確認します。

テストの種類や各工程の詳細については、ソフトウェアテストの種類と工程についての解説記事も参考にしてください。

発注者がテスト計画書を確認する理由

「開発のプロに任せているんだから、計画書の内容は開発会社に判断してもらえばいい」と思われる方もいるかもしれません。しかし、発注者が確認・承認することには明確な理由があります。

理由1: 要件との突合せは発注者にしかできない テスト範囲が要件定義書の全機能をカバーしているかの確認は、要件を最もよく理解している発注者が行う必要があります。

理由2: 合否基準の合意がトラブル防止につながる 「どの程度の不具合があればリリースを延期するか」という基準を事前に合意しておくことで、テスト完了後の認識ずれを防ぎます。

理由3: 承認に根拠を持てる いざ問題が起きたときに「この計画書で確認しました」という根拠を持つことは、発注者としての責任を果たすことにもなります。

テスト計画書に書かれている項目の意味

テスト計画書には多くの項目が含まれていますが、発注者として理解しておきたい主要な項目を解説します。

テスト範囲（スコープ）

テスト範囲は「何をテストするか」だけでなく、「何をテストしないか」も明記されているはずです。

発注者として確認すべきことは、要件定義書（または仕様書）で定義した全機能がテスト範囲に含まれているかどうかです。「テスト対象外」の項目がある場合は、その理由が合理的かどうかを確認してください。

よくある「対象外」の理由には、以下のようなものがあります。

• 外部サービスとの連携部分（外部サービス側の問題のため）
• ブラウザ・端末の対応範囲に含めていないもの（例：Internet Explorer は対象外）
• 移行前の既存データ（移行前データの品質は別途確認する）

これらの理由が説明されている場合は問題ありません。しかし「特に理由の記載なく対象外」となっている機能があれば、必ず開発会社に理由を確認してください。

テストケース数・テストレベル

テストには複数のレベルがあります。

テストレベル	実施者	内容
単体テスト	開発者	個々の機能・部品単位の動作確認
結合テスト	開発者	複数の機能を組み合わせた動作確認
システムテスト	開発者・QA	システム全体の動作確認
受入テスト（UAT）	発注者	発注者が実際の業務シナリオで最終確認

SCROLL→

発注者として特に重要なのは受入テスト（UAT: User Acceptance Testing）です。受入テストは発注者が主体となって実施するテストで、「実際の業務で使えるか」を確認します。

テスト計画書に受入テストの内容が記載されている場合、「誰が」「何を」「いつまでに」確認するかが明確になっているかを確認してください。

テスト環境

テスト環境とは、テストを実施するシステム構成のことです。理想は本番環境と同等の構成ですが、コストや準備時間の関係で完全に同一にできないこともあります。

発注者として確認すべきポイントは次の通りです。

• サーバー構成: 本番と同じクラウド環境・スペックで実施されているか
• データ量: 本番で想定されるデータ量（件数）と同程度のテストデータがあるか
• 外部連携: 外部サービスとの連携部分はどのように扱われているか（モック・実環境など）

本番と大きく異なる環境でテストしている場合、本番環境特有の問題（パフォーマンス問題など）がテストで見つからない可能性があります。

合否判定基準（終了基準）

テスト計画書の中で発注者が最も重視すべき項目が合否判定基準（終了基準）です。

「テストが完了した」「テストに合格した」といったとき、その基準が曖昧なままだと、後から認識ずれが生じます。具体的には次のような基準が明記されているべきです。

良い例:

テスト終了基準: 計画したテストケースの100%を実施し、重大度「致命的（S）」「重大（A）」のバグが0件であること。中程度（B）のバグは3件以内、軽微（C）のバグは修正計画が合意されていること。

悪い例:

テスト終了基準: すべてのバグが修正されていること。

後者は「どのバグが対象か」「どの程度の修正状態か」が不明で、判断基準になりません。

スケジュールとリスク対応

テスト期間と本番リリース日の関係も確認が必要です。

• テスト完了日から本番リリース日まで十分なバッファがあるか
• 重大なバグが見つかった場合の対応フロー（リリース延期の判断基準）が明記されているか
• テストが遅延した場合の対応方針（リソース追加か、スコープ縮小か）が示されているか

「テスト完了日 = リリース日」というスケジュールは、重大バグが見つかった際に非常にリスクが高くなります。

発注者が特に注目すべき5つのポイント

テスト計画書全体を隅から隅まで読むのは現実的ではありません。発注者として、特に次の5つのポイントに集中して確認することをお勧めします。

ポイント1: テスト範囲に「要件定義の全機能」が含まれているか

最初の確認は、要件定義書（または仕様書）で定義した全機能がテスト範囲に含まれているかの突合せです。

確認方法:

1. 要件定義書の機能一覧を手元に用意する
2. テスト計画書のテスト範囲と照合する
3. 「テスト対象外」となっている機能があれば理由を確認する

特に注意が必要なのは、要件定義後に追加・変更された機能がテスト範囲に反映されているかどうかです。途中で仕様変更があった場合、テスト計画書が古いバージョンのままになっていることがあります。

発注者が言うべき確認の言葉: 「第3回仕様変更（〇月〇日）で追加した〇〇機能は、このテスト計画書に含まれていますか？」

ポイント2: 合否判定基準が数値で明記されているか

先ほど触れた通り、合否判定基準は定量的な数値で記載されているかを確認します。

確認すべき内容：

• バグの重大度分類（S/A/B/C など）が定義されているか
• 重大度別の許容件数が明記されているか
• 「合格」「不合格」の境界が明確か

もし「バグ0件」という基準だけが書かれている場合は要注意です。現実的には軽微なバグが残った状態でリリースすることはよくあります。重要なのは「どの重大度のバグがいくつ残っていればリリースしてよいか」を合意することです。

曖昧だった場合の交渉ポイント: 「重大度の定義と、重大度ごとの許容件数を明記していただけますか？これが合否判断の基準になるため、双方で認識を合わせたいです」

ポイント3: 受入テストでの発注者の役割が明記されているか

テスト計画書に発注者が何をするかが書かれているかを確認します。受入テストは発注者が主体となって実施するものです。

確認内容：

• 受入テストの期間・スケジュールが明記されているか
• 発注者側が実施するテストシナリオの用意について言及があるか
• 承認者（最終的にサインオフする人）が決まっているか
• 不具合報告の方法・窓口が決まっているか

「受入テストは発注者の方でお願いします」とだけ書かれていて、具体的な進め方や支援体制が示されていない場合は開発会社に確認が必要です。

受入テストの具体的な進め方については、事前に社内で実施手順を整理しておくことをお勧めします。

ポイント4: テスト環境が本番環境に近いか

テスト環境と本番環境の差異が大きいほど、「テストでは問題なかったのに、本番でトラブルが起きた」というリスクが高まります。

発注者が質問すべきポイント:

• 「テストサーバーのスペックは本番と同じですか？」
• 「テストデータの件数は本番で想定される件数に近いですか？」
• 「外部サービス（決済システム・メール配信など）との連携は本番と同じ環境でテストしますか？」

特に、ユーザー数が多くなる本番環境では負荷テストが重要です。テスト計画書に負荷テストの記載がない場合は確認を求めましょう。

ポイント5: リスクと対応策が具体的か

テスト計画書には「リスクと対策」のセクションが含まれていることが多いです。ここが「リスクあり → 注意します」のような抽象的な記述になっていないかを確認します。

良いリスク記述の例:

リスク: テスト環境の構築遅延
影響: テスト開始日が3日遅延する可能性
対策: 環境構築完了の確認チェックリストを事前に準備し、〇月〇日までに確認する
コンティンジェンシー: 遅延した場合は週次定例で発注者に報告し、スケジュール調整を協議する

悪いリスク記述の例:

リスク: テスト環境の問題
対策: 注意して進める

発注者への影響が大きいリスク（スケジュール遅延、スコープ縮小）については、特に具体的な対応策が示されているかを確認してください。

「ここが抜けていたら危険」チェックリスト

以下は、発注者が承認前に確認するためのチェックリストです。NGの項目がある場合は開発会社に確認・修正を依頼してください。

テスト範囲チェック

#	確認項目	OK	NG	確認方法
1	要件定義書（最新版）の全機能がテスト対象に含まれているか			機能一覧と突合せ
2	テスト対象外の項目がある場合、その理由が明記されているか			対象外リストの確認
3	直近の仕様変更が反映されているか			変更履歴との照合
4	受入テスト（UAT）が計画に含まれているか			UATセクションの有無

SCROLL→

合否基準チェック

#	確認項目	OK	NG	確認方法
5	バグの重大度分類が定義されているか			用語定義・分類表の確認
6	重大度別の許容バグ件数（終了基準）が定量的に明記されているか			終了基準セクションの確認
7	「致命的」バグの具体的な定義が明示されているか			バグ分類の定義確認
8	テスト合格の最終承認者が決まっているか			役割・責任の確認

SCROLL→

スケジュール・体制チェック

#	確認項目	OK	NG	確認方法
9	テスト完了日からリリース日まで十分な期間があるか（最低1週間以上推奨）			スケジュール表の確認
10	重大バグ発生時のリリース延期基準が明記されているか			リスク管理セクションの確認
11	テスト担当者（人数・役割）が明記されているか			体制図・担当表の確認
12	不具合報告の方法・窓口が決まっているか			コミュニケーション計画の確認

SCROLL→

受入テスト準備チェック

#	確認項目	OK	NG	確認方法
13	受入テストの期間・スケジュールが発注者側と合意されているか			受入テスト計画の確認
14	発注者が準備すべきもの（テストシナリオ・テスト用アカウント等）が明示されているか			発注者タスクリストの確認
15	受入テスト中の問い合わせ対応体制（開発会社側）が決まっているか			サポート体制の確認
16	受入テスト合格の判断基準・最終承認フローが決まっているか			承認フローの確認

SCROLL→

テスト結果報告書の読み方

テストが完了すると、開発会社からテスト結果報告書が提出されます。ここでも発注者としての確認ポイントを押さえておきましょう。

テスト結果報告書に含まれる情報

テスト結果報告書には、一般的に以下の情報が含まれます。

• テスト実施概要（実施期間・実施件数・担当者）
• バグ件数の集計（重大度別・発見日別）
• バグの修正状況（修正済み・修正中・対応保留）
• テスト計画書で定めた終了基準の充足状況
• 残存リスク（未修正バグの内容と影響範囲）

発注者が確認すべきポイント

1. 終了基準を満たしているか

テスト計画書で合意した終了基準（重大度別の許容バグ件数）を、テスト結果が満たしているかを確認します。終了基準の充足状況が明記されていない場合は、個別に確認を求めましょう。

2. 未修正バグの内容と影響範囲

「修正保留」「対応保留」のバグがある場合は、以下を確認します。

• どの機能に影響するか
• いつ修正するか（次バージョン？）
• 業務に支障はないか

3. テストカバレッジ（テストした範囲の割合）

テストケース数が計画より大幅に少ない場合は注意が必要です。「〇〇の理由により一部テストを省略しました」という記載がある場合、省略した内容と影響を必ず確認してください。

「問題なし」報告をそのまま信じない視点

「全テスト合格しました」という報告を受けたとき、念のため確認しておきたいことがあります。

• テストケース数は十分か: テスト計画書で想定していた件数と実際の実施件数が大きく異なる場合は理由を確認する
• テスト期間は十分だったか: 予定より短縮されていた場合は何をスキップしたかを確認する
• 「このテストでは検出できない可能性があるもの」への言及があるか: 誠実な開発会社はテストの限界も正直に記載します

受入テストで発注者がやるべきこと

テスト計画書を確認したら、次は受入テストの準備です。受入テストは発注者が品質を最終確認する「最後の砦」です。

受入テストの位置づけと発注者の役割

受入テストは、開発側のテストが完了した後に、発注者（ユーザー）が「実際の業務で使えるか」を最終確認するテストです。

重要なのは、開発側のテスト結果を鵜呑みにしないという姿勢です。開発側は技術的な動作確認（バグがないか）を行いますが、発注者は「業務上の正しさ」（業務フローと合致しているか、エンドユーザーが使いやすいか）を確認する必要があります。

受入テストの詳しい進め方については、開発会社と事前にしっかり打ち合わせておきましょう。

受入テストシナリオの準備

発注者が受入テストに備えて準備すべきことは、実際の業務フローをテストシナリオとして整理することです。

例えば、受注管理システムであれば：

1. 新規注文を受け付ける
2. 在庫を確認して受注確定する
3. 発送手続きを行う
4. 請求書を発行する
5. 入金確認をする

このような実際の業務フロー（エンドツーエンドのシナリオ）を複数用意して、順番に確認します。

全ての機能を確認する必要はありません。業務上のリスクが高い順（金銭が絡む処理、データが削除される処理など）から優先して確認しましょう。

バグ報告の方法と判定

受入テスト中に不具合を発見した場合は、開発会社と合意した方法で報告します。よくある方法は次の通りです。

• 専用のバグ管理ツール（Jira、Backlog など）への登録
• Excelのバグ票への記録とメール送付
• チャットツールでの都度報告

バグ報告時に必要な情報：

• 何をしたら: 操作手順
• 何が起きたか: 実際の動作
• 何が期待されたか: 期待される動作
• 再現性: 毎回起きるか、特定の条件下でのみ起きるか

また、「バグ」と「仕様変更の要望」を区別することも重要です。「こうなってほしかった」という要望は追加の開発費・期間が発生する可能性があります。合意済みの仕様と比較して判断してください。

最終承認判断のフレームワーク

受入テストが終わったら、最終的に「承認する・しない」を判断します。

承認してよい条件の目安:

• テスト計画書で合意した終了基準を満たしている
• 致命的・重大なバグが残っていない
• 業務を開始するうえで支障のない状態である
• 残存する軽微なバグについて修正計画と期限が合意されている

「条件付き承認」という選択肢

すべてが完璧でなくても、条件付きで承認するという判断もあります。例えば「〇〇機能のバグは翌月の修正版で対応することを確認し、本番リリースを承認する」という形です。

テスト工程の外注を検討している方は、QAアウトソーシングガイドも参考にしてください。

発注者が使える「テスト計画書 承認チェックシート」

最後に、発注者が承認前に活用できるチェックシートをまとめます。このまま印刷・コピーしてご利用ください。

テスト計画書 承認チェックシート

プロジェクト名: ＿＿＿＿＿＿＿＿＿＿
テスト計画書バージョン: ＿＿＿
確認日: ＿＿＿年＿＿月＿＿日
確認者: ＿＿＿＿＿＿＿＿＿＿

カテゴリ	#	確認項目	OK	NG	要確認	備考
テスト範囲	1	要件定義書（最新版）の全機能がテスト対象に含まれているか
テスト範囲	2	テスト対象外の項目がある場合、その理由が明記されているか
テスト範囲	3	直近の仕様変更が反映されているか
テスト範囲	4	受入テスト（UAT）が計画に含まれているか
合否基準	5	バグの重大度分類が定義されているか
合否基準	6	重大度別の許容バグ件数が定量的に明記されているか
合否基準	7	「致命的」バグの具体的な定義が明示されているか
合否基準	8	テスト合格の最終承認者が決まっているか
スケジュール	9	テスト完了日からリリース日まで十分な期間があるか
スケジュール	10	重大バグ発生時のリリース延期基準が明記されているか
スケジュール	11	テスト担当者（人数・役割）が明記されているか
スケジュール	12	不具合報告の方法・窓口が決まっているか
受入テスト	13	受入テストの期間・スケジュールが合意されているか
受入テスト	14	発注者が準備すべきものが明示されているか
受入テスト	15	受入テスト中のサポート体制が決まっているか
受入テスト	16	受入テスト合格の判断基準・承認フローが決まっているか

SCROLL→

チェック結果の見方

• NG が1つでもある場合: 開発会社に修正・補足を依頼し、解消されるまで承認を保留してください
• 要確認が複数ある場合: 確認事項を整理して開発会社に一括質問することをお勧めします
• 全てOKの場合: 上記を確認したうえで、最終的なビジネス判断（承認・条件付き承認・保留）を行ってください

テスト計画書を「ちゃんと説明してくれる」開発会社を選ぶ重要性

この記事を読んで、テスト計画書の確認が発注者にとって重要であることはご理解いただけたと思います。しかし、もう一つ大切なことがあります。それは、テスト計画書をわかりやすく説明してくれる開発会社を選ぶことです。

テスト計画書を提出するだけで「ご確認ください」と言う開発会社と、「このチェックポイントを一緒に確認しましょう」と丁寧に説明してくれる開発会社では、発注者の安心感が全く異なります。

特に、ITに詳しくない発注者の方にとって、専門用語が並んだ文書をひとりで読み解くのは大変です。開発会社がその負担を軽減するために、どれだけ発注者に寄り添えるかは、開発の品質だけでなく、プロジェクト全体の成功に影響します。

秋霜堂株式会社では、テスト計画書の内容を発注者の方にわかりやすく説明し、一緒に確認することを大切にしています。「技術的なことはよくわからないけど、ちゃんとした開発会社に任せたい」という方は、お気軽にご相談ください。

要件定義とテスト計画の関係については、要件定義の完全ガイドも参考にしてください。

まとめ

テスト計画書の読み方について解説しました。発注者として特に重要な5つのポイントをおさらいします。

1. テスト範囲に要件定義の全機能が含まれているか を確認する
2. 合否判定基準が数値で定量的に明記されているか を確認する
3. 受入テストでの発注者の役割が明記されているか を確認する
4. テスト環境が本番環境に近いか を質問する
5. リスクと対応策が具体的に記載されているか を確認する

テスト計画書は、「承認のための形式的なドキュメント」ではなく、「開発の品質を双方で守るための合意書」です。この記事で紹介したチェックシートを活用して、自信を持った承認判断をしていただければ幸いです。