お役立ち情報
テスト計画書の不備を防ぐには？発注企業が確認したいポイントと書き方を解説

システム開発お役立ち情報

公開日:2026.08.04　更新日:2026.08.04

テスト計画書の不備を防ぐには？発注企業が確認したいポイントと書き方を解説

監修者

取締役斎藤裕一

システム開発を進めるなかで、テストの範囲や判断基準が曖昧なまま「開発会社に任せてよいのか？」と不安を感じる担当者も少なくありません。テスト計画書に必要な項目が不足していると、確認漏れや手戻りが発生し、リリース後の障害につながる可能性があります。

そこで本記事では、テスト計画書の目的や書き方、よくある失敗など「発注側の確認ポイント」を解説します。システムの導入や刷新を担当する前に、テスト計画書を確認するポイントとして参考にしてみてください。

ITコンサルティングやシステム開発を一気通貫してご相談・ご依頼したい人はこちらのバナー

テスト計画書とは

テスト計画書とは、システム開発で実施するテストの方針をまとめた文書です。テストの目的や対象範囲だけでなく、実施体制・スケジュール・品質の判断基準なども記載します。

また、発注側にとっても、予定しているテストで十分な品質を確保できるかどうかを確認する重要な資料です。テストの終了や本番リリースの可否を判断する際にも使用されています。

作成する目的

テスト計画書を作成する主な目的は、テストの進め方と品質の判断基準を関係者間で共有するためです。計画が曖昧なままテストを開始すると、担当者によって確認範囲や合否の判断が変わる可能性があります。

テストには実施担当者だけでなく、業務部門による確認やテスト用の環境・データなどが必要です。計画書に準備事項と期限を記載しておけば、テスト開始後に人員やデータが不足する事態を避けやすくなります。

また、テストケースの消化率や未解決の不具合数などを設定すると、感覚ではなく数値をもとにした状況把握が可能です。リリース可否を判断する担当者としても、判断の根拠を社内へ説明しやすくなります。

テスト計画書の種類

テスト計画書は、主に以下の2種類に分けられます。

種類	主な役割	主な内容
全体テスト計画書	プロジェクト全体の方針を定める	テストレベル、体制、全体スケジュールなど
個別テスト計画書	各テスト工程の進め方を定める	対象機能、テスト観点、開始・終了条件など

小規模な改修では、2種類の計画書を1つにまとめるケースもあります。ただし、複数のシステムや開発会社がかかわるプロジェクトでは、全体計画と個別計画を分けたほうが効率的です。

テスト仕様書・テスト設計書との違い

名称が似ている以下の文書は、それぞれ使用する目的や役割が異なります。

文書	主な役割	主な記載内容
テスト計画書	テスト全体の進め方を定める	テストの目的、範囲、体制、スケジュールなど
テスト設計書	テストの観点や条件を整理する	確認する機能、条件、組み合わせなど
テスト仕様書	実行するテスト内容を具体化する	入力値、操作手順、期待結果など

テスト計画書は「テストをどのように進め、管理するのか」を定める文書です。テスト対象や担当者など、プロジェクト全体を管理するための情報をまとめましょう。

テスト計画書に必要な項目と書き方

テスト計画書には、テストを実行・管理・評価するための項目を記載します。ただし、テンプレートの項目を埋めるだけでは、実務で使える計画書にはなりません。

関係者が計画書を読んだ際に「何を準備し、どの基準で判断するのか」がわかる状態を目指します。プロジェクトの規模やシステムの特性に応じて、必要な項目や記載する内容を調整してみましょう。

プロジェクトの背景とテストの目的

まずはシステム開発や改修を行う背景と、テストで確認したい内容を記載しましょう。背景と目的を明確にすると、テストの優先順位を決めやすくなります。

たとえば「手作業で管理している受注情報をシステム化する」「古い販売管理システムを新しい環境へ移行する」といった背景を記載すれば、プロジェクトの位置づけが新規開発・既存システムの改修・リプレイスのどれに当たるのかを明確化できます。

また、要件定義書や設計書など、テストの前提となる資料を明記しておくのも効果的です。仕様変更が発生した場合に、どの資料を基準として期待結果を判断するのかが把握しやすくなります。

テストの粒度と種類

テストの粒度とは、システムを「どの単位に分けて確認するのか」を示す考え方です。機能・画面・処理など、目的に応じて以下のような種類に分けて確認します。

テストの種類	主な確認内容
単体テスト	個別のプログラムや機能が正しく動作するか
結合テスト	複数の機能やプログラムを組み合わせて正しく動作するか
システムテスト	要件や仕様に沿ってシステム全体が正しく動作するか
運用テスト	本番に近い環境や業務手順で運用できるか

テスト計画書には、各テストの目的や対象、担当者を記載します。どの工程で何を保証するのかを明記することは、後工程で同じ内容を繰り返したり、確認が漏れてしまう機能が残ったりするミスの対策としても効果的です。

テストの対象範囲

テストの対象範囲には、対象となるシステムや機能・画面などを具体的に記載します。また、対象外とする範囲も明確化しておくのも有効です。

たとえば、販売管理システムを改修する場合は、受注データが在庫管理や請求管理へ正しく連携されるか、帳票に反映されるかなども検討します。改修箇所だけでなく、既存機能へ与える影響もテストの確認対象です。

さらに、外部サービスや他システムとの連携部分も整理します。決済サービスや会計システムなど、社外の環境を使う場合は、確認できる範囲や接続できる期間も記載しておきましょう。

テスト環境とテストデータ

テスト計画書には、テストで使用する以下の環境やデータも記載します。

テスト環境	サーバーネットワークOSブラウザ使用端末
テストデータ	データの種類件数準備方法管理担当者

また、本番環境とテスト環境の相違点を明確にしておきます。たとえば、本番環境とテスト環境では、使用できるサーバー台数が異なるケースも少なくありません。環境に差がある場合は、確認できない内容や代わりの検証方法を検討しておくと安全です。

正常なデータだけを用意するとエラー処理を十分に確認できないため、境界値や異常値、大量データなども準備しておきましょう。

テストの体制・スケジュール

作業の重複や確認漏れを防ぐため、テストの体制に「誰が何を担当するか」を定義しておきましょう。開発会社だけでなく、発注側や業務部門の役割も整理しておくのが効果的です。

スケジュールには、テストの実行期間だけでなく以下の作業も含めます。

計画書や仕様書の作成・レビュー
テスト環境とデータの準備
テストの実行
不具合の修正・再テスト
全体への影響を確認する回帰テスト
テスト完了の報告と承認

不具合の修正や再テストを考慮し、一定の予備日を設けておくとリリース後のリスクを軽減できます。また、特殊な製品知識や操作研修が必要な場合は、トレーニング計画も含めて記載しておきましょう。

テスト開始～終了の判断条件

テスト計画書には、テストを開始・中断・再開・終了する条件も記載します。判断条件をあらかじめ定めておくことで、担当者の感覚だけで工程を進める事態を防げます。

以下は、各条件の記載例です。

条件	記載例
開始	対象プログラムの開発が完了している設計書のレビューが完了しているテスト環境が利用できる
中断	テストを継続できない環境障害が発生している重大な不具合が頻発している
再開	環境障害の復旧が確認できた修正版のプログラムが反映された
終了	テストケースの消化率が100%に達している不具合の解決が0件になるまで完了している

無効なテスト結果や再テストを防ぐためにも、判断基準として具体的な数値や条件を定めておきましょう。

合否判定基準とリリース判断基準

テストケースの合否と本番リリースの可否は、分けて判断します。システム全体に重大なリスクが残っていれば、個別のテストに合格していてもリリースを延期する判断が必要です。

合否判定基準には、各操作の期待結果を具体的に記載します。「登録した顧客名と契約金額が一覧画面へ表示される」のように、正誤を確認できる項目や状態を示しておきましょう。

リリース判断基準には、テスト全体の結果を用います。テストケースの消化率・合格率・未解決の不具合数などを組み合わせ、発注側と開発側で想定リスクを共有しながら進めましょう。

テストの進捗・不具合・品質管理

テストの進捗と品質は、下表のような指標を使って管理します。テストケースの消化率だけを見ても、システムの品質を正しく判断できるとは限りません。

管理項目	記載する内容
進捗管理	テスト件数実施数合格数不合格数未実施数
不具合管理	対象の機能や画面再現するための操作手順期待結果と実際の結果不具合の重大度と優先度修正担当者と対応期限再テストの結果対応状況

品質を評価する際は、不具合の件数だけでなく、重大度や発生傾向も確認しましょう。簡易的な表記ミスとデータ消失につながるバグでは、同じ1件の不具合でも業務にかかわるリスクが異なります。

テストの成果物

テストの成果物には、テスト工程で作成・提出する文書や記録を記載します。主な成果物は、以下のとおりです。

テスト計画書
テスト設計書
テスト仕様書
テストデータ
テスト実施結果
不具合管理表
進捗・品質報告書
テスト完了報告書
リリース判定資料

テスト結果には、合格・不合格だけでなく、確認に使用したデータや実施日時も記録します。スクリーンショットやログなどの証跡があれば、結果の再確認や不具合の原因調査に役立ちます。

想定されるリスクと対応策

テスト計画書には、テスト工程で起こり得るリスクと対応策も記載します。問題が発生してから対応を考えるよりも、事前に判断基準や代替案を用意したほうが影響を抑えやすくなるためです。

たとえば、テスト工程では以下のようなリスクが想定されます。

開発の遅延によってテスト期間が短くなる
テスト環境やデータの準備が遅れる
業務担当者を確保できない
不具合で外部システムに接続できない
仕様変更によってテストケースの修正が発生する
修正によって別機能への影響が出る

想定されるリスクに応じて、発生する可能性や影響範囲を評価しておくと安心です。まずは業務への影響が大きいリスクから対策を検討しておきましょう。

テスト計画書のよくある失敗と対策

テスト計画書に不備があると、テスト漏れや手戻りが発生しやすくなります。文書の形式が整っていても、範囲や基準が曖昧では実際の判断に使えません。

そこで、よくある失敗を把握し、計画書のレビュー時に確認しておきましょう。発注側と開発側の双方が参加すれば、技術面と業務面から不足箇所を見つけられます。

テストの目的や範囲が曖昧になっている

テストの目的や範囲が曖昧な計画書では、確認漏れや認識の違いが発生します。たとえば、受注画面を改修した場合、画面への入力だけを確認しても不十分です。登録したデータが在庫や帳票へ反映されるように、変更していない既存機能にも改修の影響が及ぶ可能性はあります。

対策として、テストの対象範囲を業務上の目的と結びつけて定義するのが効果的です。発注側の業務担当者が対象範囲をレビューすると、開発側だけでは気づきにくい業務パターンを補えます。

正常系のテストに偏っている

正常な操作だけに偏ったテストでは、実際の運用で起こる入力ミスや通信障害を見落とす可能性があります。システムは、利用者が想定どおりに操作した場合だけ動作すれば良いわけではありません。

異常系のテストでは、不正な値や想定外の操作に対してシステムが安全に処理できるかどうかを確認します。たとえば、以下のようなパターンです。

必須項目を空欄にする
文字数の上限を超える
数値の欄へ全角文字を入力する
同じボタンを連続して押す
処理中に通信が切れる
権限のない利用者が画面へアクセスする

各テスト項目に正常系・異常系・例外処理の観点を定義しておくのも対策として効果的です。過去に発生した障害や問い合わせも参考にしながら、異常系の確認も実施しておきましょう。

性能・セキュリティなどの非機能テストが不足している

画面や機能の動作だけを確認すると、処理速度やセキュリティなどの問題を見落とす可能性があります。機能が正常に動作しても、画面表示に数分かかるシステムでは業務に支障が出るかもしれません。

非機能テストでは、主に以下の項目を確認します。

画面表示や処理にかかる時間
同時に利用できる人数
大量データを処理したときの動作
利用者の権限に応じたアクセス制御
バックアップとデータの復元
長時間連続して稼働したときの安定性

非機能要件をテスト段階で決めると、基準に根拠がなくなるリスクもあります。そのため、要件定義の段階で、必要な処理速度や同時利用者数などを関係者間で共有しておきましょう。

修正・再テストの期間が確保されていない

テストの実行期間だけを設定すると、不具合の修正と再テストに必要な日数が不足するケースも少なくありません。不具合は見つけて終わりではなく、修正内容を確認し、他機能への影響を検証する時間も必要です。

さらに、修正によって別機能に新たな不具合が発生する可能性もあります。対策として、スケジュールを以下の単位に分けて設定してみましょう。

テストの実行
不具合の調査・修正
修正内容のレビュー
再テスト
回帰テスト

不具合の件数を正確に予測するのは困難なため、一定の予備日を設けておきましょう。開発が遅れた場合でも、修正や再テストの期間を機械的に削らない判断が必要です。

終了条件が曖昧でリリースを判断できない

終了条件が曖昧な状態では、テストを完了すべきタイミングが判断できません。とくに納期を優先するような状況では、品質上のリスクを十分に評価せずリリースする可能性もあります。

そこで終了条件には、以下のような基準を設定しておくのが有効です。

テストケースの実施数
未実施のテスト数
未解決の不具合数
重大度別の不具合数
修正後の再テスト完了率
性能やセキュリティの達成状況

基準を満たさない状態でリリースする場合は、例外として承認する手順を定めます。持ち越すリスクや修正予定日を記録し、発注側の責任者が対応方針を判断しましょう。

発注側が確認しておきたいテスト計画書のポイント

テスト計画書の確認を開発会社に任せきりにせず、発注側もチェックしておきましょう。開発会社は技術的な品質を確認できますが、自社の業務や利用者の実態を理解しているのは発注側です。

ただし、技術的な用語をすべて理解する必要はありません。これから解説するポイントを参考に、システム導入の目的や重要な業務、社内で必要となる準備などを中心に確認してみてください。

システム導入の目的に沿った計画になっているか

発注側の観点として、システムを導入・改修する目的がテスト計画へ反映されているかどうかの確認が重要です。機能一覧を順番に確認するだけでは、業務上の目的を達成できるかどうかを判断できません。

たとえば、受注処理の入力ミスを減らす目的で改修する場合は、入力チェックや確認画面を重点的にテストします。作業時間の短縮が目的であれば、操作の流れや処理速度も確認対象です。

また、利用者が実際に行う業務フローを想定しているかどうかも確認しておきましょう。個別の画面が正常に動作しても、一連の処理がつながらなければ現場で利用できません。

重要な業務・機能がテスト対象に含まれているか

自社の事業や日常業務に欠かせない機能がテスト対象に含まれているかどうかも重要な確認項目です。開発会社だけでは、各機能が業務へ与える影響を正確に判断できない可能性もあります。

まずは受注や決済、在庫管理など、停止による影響度の高い機能を洗い出しましょう。利用頻度だけで判断せず、不具合による影響の大きさによって優先度を設定するのが効果的です。

また、外部システム連携やデータ移行も見落としやすいポイントです。新システムの動作が正常であっても、旧システムから移行したデータが正しく引き継がれていることを確認しておきましょう。

発注側が準備する人員・環境・データが明確か

発注側が担当する作業は、テスト開始前に確認しておきましょう。準備内容が曖昧では、業務担当者を確保できず、テストの進捗が遅れる可能性もあります。

発注側が参加する主な作業は、受入テストです。受入テストでは、納品されたシステムが業務要件を満たしているかどうかを発注側が確認します。テスト計画書をレビューする段階で、以下の項目を整理しておきましょう。

参加する部署と担当者
各担当者が行う作業
必要な作業時間
テストを実施する日時
承認者と承認期限
必要な端末やネットワーク
テスト用の利用者アカウント
発注側が提供するデータ

顧客情報や商品情報などを発注側が用意する場合は、抽出方法と提出期限を定めておきます。また、個人情報を含む場合は、内容を架空データに置き換える対策も必要です。

現実的な体制とスケジュールが設定されているか

発注側は、テストの規模に対して十分な人数と期間が設定されているかどうかも確認します。日程が記載されているだけでは、実行可能な計画かどうかを判断できません。

レビューやデータ準備など、テスト期間には実行以外の作業も含まれます。月末や決算期などの繁忙期と重なると十分な確認時間を確保できないため、業務担当者の予定を踏まえて調整しましょう。

外部システムとの接続や別部署からのデータ提供が必要な場合は、調整期間も見込んでおくと安心です。

不具合の報告・修正・再テスト方法が決まっているか

不具合を発見したあとの流れは、テスト開始前に決めておきましょう。報告方法が統一されていないと、同じ不具合が重複して登録されたり、修正状況を追跡できなくなったりするからです。

テスト計画書では、報告に使用する管理表やツールを確認しておきます。不具合ごとに発生した画面や操作手順、入力データなどを記録し、スクリーンショットやログを添付するルールも決めておくのが効果的です。

事前に報告先と連絡期限を定めておけば、判断の遅れを防ぎやすくなります。不具合の修正後には、問題が解消したか、他機能に影響が出ていないかを再テストしましょう。

まとめ：テスト計画書の定義と役割について

テスト計画書は、システム開発で行うテストの目的・対象・管理体制などを整理する文書です。テスト漏れや役割の曖昧さを防ぎ、開発側と発注側の認識をそろえる役割があります。

目的や対象範囲が曖昧な計画では、業務に必要な機能や処理を十分に確認できません。自社の重要な業務や機能がテスト対象に含まれているかどうか、発注側で準備する人員やデータが明確かどうかも重要な確認項目です。

計画内容に不足や曖昧な要素がある場合は、テスト開始前に開発会社と調整しておきましょう。発注側と開発側が計画に合意し、共通の基準でテストを進めることで、品質を確保しながら円滑なリリースにつなげられます。

監修者

斎藤裕一
取締役

＜略歴＞
大阪大学工学部、大阪大学大学院情報科学研究科修了。
国内最大手IT企業の株式会社NTTデータで大手金融機関向けに債権書類電子化システム、金融規制・法規制対応システムの要件定義・インフラ設計・開発・構築・複数金融サービスのAPI連携等を手がける。その後、株式会社GeNEEの取締役に就任。

＜資格＞
基本情報技術者試験、応用情報技術者試験、Oracle Master Platinum等多数

この記事をいいねと思ったら！