テスト計画の立て方｜計画と計画書の違いから解説

2026 7/25

2026年7月25日 2026年7月25日

案件が大型化・複雑化してくると、「テストは現場任せでなんとかなる」というやり方が急に通用しなくなります。テスト計画の立て方を体系的に学んだことがないまま、テンプレートを前に手が止まってしまう。これは多くのPMが最初にぶつかる壁です。

この記事では、テスト計画を「計画書のテンプレを埋める作業」としてではなく、「何をどう確かめるかを構想する行為」として捉え直します。計画と計画書の違いから入り、決めるべき要素の全体像、標準の位置づけ、そして計画が破綻する落とし穴までを俯瞰します。

手順やテンプレの詳細は別記事に譲り、本記事は「考え方の土台」に集中します。

テスト計画を立てずに走り出すと、なぜ現場は破綻するのか

少人数の受託開発では、テストを開発エンジニアが兼任するのが当たり前です。目の前の実装に追われ、計画を立てないまま「動いたら確認する」で走り出してしまう。

その結果、リリース直前に炎上する。これは特別に運の悪い現場の話ではなく、計画を持たずに走ったチームに共通して起きる典型です。

兼任テストで起きる「なんとなく終わり」の正体

計画がないテストは、範囲も終わりも曖昧なまま進みます。テストケースをその場で思いつき、実装しながら手当たり次第に確認していく。

一見それらしく動いているように見えても、「どこまで確認すれば完了なのか」を誰も決めていません。結果として、次のような破綻パターンが繰り返されます。

スコープ膨張: 範囲を決めていないため、テスト対象がずるずる広がり工数が読めない
完了条件の欠如: 「なんとなく大丈夫そう」で終わり、品質の担保がない
見積り根拠の不在: 工数やスケジュールの根拠を顧客・上長に説明できない
担当交代でのブレ: 属人的なため、担当者が変わると観点も品質も変わる

たとえば、ある改修案件で範囲を決めずに走った結果、結合段階で「ついでにここも」と検証対象が周辺機能まで膨張し、同じ画面を担当者ごとに重複して確認して工数が想定を超えた、というのはよくある場面です。範囲の一線を引いていれば防げた種類のロスです。

弊社が支援したテスト代行の案件でも、テスト開始時に全体像を把握しきれていないと、後戻りや重複が生じて無駄が積み上がる場面がありました。急がば回れで、全体像の把握に先行投資したほうが、結果的にトータルの時間は短くなります。

「計画を立てる」と「計画書を書く」を混同していないか

破綻の根っこには、ある混同があります。それは「計画を立てること」と「計画書を書くこと」を同じものだと思ってしまうことです。

テンプレートを埋めれば計画したことになる、と考えてしまうと、書式は整っているのに中身のない計画書ができあがります。埋まった欄の数と、構想の深さは比例しません。

計画を立てることと計画書を書くことは、同じではありません。

この違いを解きほぐすことが、本記事全体の出発点です。まずは「そもそもテスト計画とは何か」から整理していきます。

テスト計画の立て方の第一歩｜「テスト計画」とは何かとその目的

テスト計画の立て方を身につける第一歩は、テンプレートの入手ではありません。「テスト計画とは何をすることなのか」を、自分の言葉で説明できるようになることです。

計画とは「次に何をするかを構想すること」

計画という言葉を、テストの文脈で捉え直してみます。テストの世界では、計画を「次に何をするかを構想すること」と捉えます。

計画とは「次に何をするかを構想すること」であり、書類を作る作業そのものを指すのではありません。何をどの順番で、どこまで確かめるのかを頭のなかで組み立てる。その思考のプロセスこそが計画の本体です。

テストにおける「計画」や「テストプロセス」の標準的な定義は、公的なシラバスでも確認できます。用語の共通理解を持っておくと、チーム内の認識のズレを防げます。

JSTQBのシラバスでテストプロセスの定義を確認する

なぜテスト計画が必要か

では、なぜ構想する行為としての計画が必要なのでしょうか。受託開発のPMにとって、テスト計画は主に3つの役割を果たします。

目的	計画がないと起きること
説明責任	工数・スケジュール・範囲の根拠を顧客・上長に示せない
チーム標準化	担当者ごとに品質がばらつき、交代でブレる
抜け漏れ防止	兼任による確認漏れが、リリース直前に露見する

テスト計画は、自分のためだけの備忘録ではありません。顧客や上長に「なぜこのテストで十分と言えるのか」を説明し、チームの誰が担当しても一定の品質を出すための土台です。

つまり計画は、対内的には「迷わないための地図」、対外的には「合意と説明のための根拠」という二重の役割を担います。この二面性を意識しておくと、次に見る「行為」と「成果物」の違いも腹落ちしやすくなります。

計画の土台となる、良い要求仕様の特性

もう一つ、計画を立てる前に押さえておきたい前提があります。それは、テスト対象となる要求そのものが「テスト可能」でなければ、計画も成り立たないという点です。

高橋寿一『知識ゼロから学ぶソフトウェアテスト』によれば、テストの土台となる良い要求仕様には、次のような特性が求められます。

完全である
正当（妥当）である
実現可能である
必要である
優先順位がついている
曖昧さがない
一貫している（矛盾がない）
テスト可能である

この8つのうち最後の「テスト可能である」が、まさに計画の前提です。要求が曖昧なまま、あるいは互いに矛盾したまま計画を立てようとすると、「何を確認すればよいか」が定まらず、計画は空中分解します。計画の前段として、要求の曖昧さと矛盾を潰しておくことが欠かせません。

「テスト計画（行為）」と「テスト計画書（成果物）」はどう違うのか

ここが本記事の核心です。テスト計画とテスト計画書は、言葉は似ていますが役割がまったく異なります。この違いを腹落ちさせることが、計画の空洞化を防ぐ最大のポイントです。

テスト計画＝「何をどう確かめるか」を構想する行為

テスト計画は「行為」です。どの範囲を、どんな観点で、どこまで確かめれば十分と言えるのか。リスクの高い箇所はどこで、限られた時間をどこに配分するのか。

こうした問いに頭を使って答えを出していく、戦略的な思考そのものがテスト計画です。成果物の有無とは関係なく、考えなければ計画は存在しません。

テスト計画書＝構想を伝達・合意・再現するための道具

一方、テスト計画書は「成果物」です。頭のなかで構想した戦略を、他者に伝え、合意を取り、後から再現できるように書き残すための道具です。

計画書は計画の結果を映す鏡であって、計画そのものではありません。両者の違いを整理すると、次のようになります。

観点	テスト計画（行為）	テスト計画書（成果物）
目的	何をどう確かめるかを構想する	構想を伝達・合意・再現する
アウトプット	判断・戦略・優先順位	文書・ドキュメント
評価軸	妥当か・抜けがないか	伝わるか・合意できるか
欠けたときの症状	現場が迷走し破綻する	属人化し、引き継げない

「テンプレを埋める＝計画した」ではない

この対比からわかるのは、テンプレートを埋める作業だけでは計画にならないということです。

テンプレートを埋めただけでは、計画したことにはなりません。欄が埋まっていても、そこに構想の裏づけがなければ、それは形式だけの計画書です。

弊社が支援したテスト代行の案件でも、テスト項目をただ列挙するだけでは設計として不十分でした。列挙した項目を重要度・リスク・確認容易性の観点で順位づけし、限られた時間をどこに割くかを判断する。そこまでやって初めて「計画した」と言えます。

テンプレートは構想を書き留める器にすぎません。器を先に埋めようとするのではなく、まず構想を作る。この順序を間違えないことが大切です。

テスト計画で決めるべき要素の全体像｜代表的な7つを”地図”で把握する

構想と言われても、いったい何を構想すればよいのか。計画づくりでつまずくのは、たいていこの「決めるべきことの全体像が見えない」段階です。

そこで、計画で決めるべき代表的な要素を7つの領域に分け、”地図”として一覧化します。

代表的な7つの要素の地図

まず全体像を俯瞰しましょう。次の7要素が、テスト計画で構想すべき代表的な骨格です。

要素	決めること	曖昧なままだと起きる症状
範囲	テストする／しない対象を線引きする	スコープが膨張し工数が読めない
観点	どんな視点で欠陥を探すか	重要な確認が抜け落ちる
完了条件	どうなったら終わりか	「なんとなく終わり」になる
工数	どれだけ時間をかけるか	見積り根拠を説明できない
リスク	どこを重点的に確かめるか	重要箇所に時間を割けない
体制	誰が何を担当するか	兼任で抜け漏れが生じる
スケジュール	いつまでに何を終えるか	リリース直前に間に合わない

なお、この7つは計画の全項目を網羅したものではなく、あくまで代表的な骨格です。案件に応じて、このほかにテスト環境・テストデータ・テストレベル（単体／結合／システムなど）・成果物・承認プロセスなども計画に含めます。まずは代表的な7要素で骨格をつかみ、必要に応じて項目を足していくのが現実的です。

決めるべき要素を”地図”として先に把握することが、遠回りに見えて最短です。

仮の小規模案件で7要素を埋めてみる

抽象的な地図も、具体的な案件に当てはめると一気に手触りが出ます。ここでは「会員登録機能の改修」という仮の小規模案件を置いて、7要素を1行ずつ埋めた見本を示します。

要素	「会員登録機能の改修」での記入例
範囲	会員登録・ログイン画面のみ。決済連携は今回の対象外とする
観点	入力値の境界・異常系、および既存のログイン機能への影響
完了条件	重要度「高」のケース消化率100％＋未解決の重大バグ0件
工数	設計・実施・報告を分けて見積もり、リスクの高い箇所に厚く配分
リスク	既存会員データへの影響と、登録失敗時のエラー処理
体制	実装者以外がレビュー観点で確認し、単独判断を避ける
スケジュール	実装完了後に着手し、リリース前日を報告の締切とする

このように1行ずつでも埋めてみると、「自分の案件では範囲をどこで切るか」「何をもって完了とするか」が具体的な言葉になります。完璧な記述より、まず言語化して抜けを見つけることが目的です。

「完了条件」は定量と定性で書き分ける

7要素のなかでも、現場が最も曖昧にしがちなのが「完了条件」です。ここが決まっていないと、テストはいつまでも終わらず、逆にいつでも終われてしまいます。

完了条件は、定量と定性の両面で書き分けると、上長にも示せる形になります。

定量的な完了条件: 「重要度『高』のテストケース消化率100％」「未解決の重大バグ0件」「主要導線の自動テストが全件パス」など、数で判定できるもの
定性的な完了条件: 「主要な業務シナリオが一通り通ること」「既知の重大な不具合が残っていないこと」など、状態で判定するもの

定量だけだと「数字は満たしたが不安が残る」状態を見逃し、定性だけだと判断が属人化します。両方を併記しておくと、「なぜ終わってよいのか」を筋道立てて説明できます。

顧客・上長への説明は「型」で組み立てる

計画の妥当性は、顧客や上長に説明できて初めて力を持ちます。説明が苦手なら、次の型に沿って一文で組み立てると通りやすくなります。

根拠→配分→完了条件→工数、の順で説明すると計画の筋が伝わります。たとえば次のような一言です。

> 範囲はA・B機能に限定し、リスクの高い決済連携に工数の4割を配分します。完了条件は重要度「高」のケース100％消化＋重大バグ0件。ゆえに◯人日と見積もりました。

ここでの工数（◯人日）はあくまで型を示すための例で、実際の数字は案件ごとに算出します。大切なのは、範囲・リスク配分・完了条件という判断の根拠がそろっていれば、工数の数字も「説明できる数字」になるという点です。

「計画できるところまで計画する」＝どこまで決めるかの原則

7要素すべてを、案件の初日に完璧に決められるわけではありません。むしろ、決められないことまで無理に決めようとすると計画は破綻します。

大切なのは「今の知識で計画できるところまで計画し、それ以上は決め打ちしない」という原則です。この考え方は後半の適応型計画で詳しく触れます。ここでは「全体像は地図として持ちつつ、確定は段階的でよい」と押さえてください。

詳細な項目の埋め方・作成手順はどこで学ぶか

本記事はあくまで全体像を俯瞰するハブです。個々の要素をどう深掘りするかは、目的別に次の記事へ進んでください。

観点の具体的な洗い出し方はテスト観点の洗い出し方を具体例で確認する
リスクで優先順位をつける進め方はリスクベースで優先順位をつける手順を学ぶ
計画書を実際に組み立てる順序はテスト計画書の作成手順を順を追って確認する

全体像を地図として押さえたら、次は「その地図を書き残す枠組み」を見ていきます。

IEEE 829 という枠組みの立ち位置｜計画書は「説明責任」の道具

構想した計画を、どんな枠組みで書き残せばよいのか。ここで参考になるのが、かつて広く使われたテストドキュメントの枠組みであるIEEE 829です。

IEEE 829は、歴史的に広く使われたテストドキュメントの枠組みで、2008年版（IEEE 829-2008）を最後に廃止され、現在は後継のISO/IEC/IEEE 29119-3に引き継がれています。ただし、計画書の項目立ての雛形としては今も実務の参考になります。

IEEE 829が定める8つのテストドキュメント

Copeland『はじめて学ぶソフトウェアのテスト技法』によれば、IEEE 829（同書はIEEE 829-1988を参照）はテストに関わる文書として次の8種類を挙げています。

テスト計画書
テスト設計仕様書
テストケース仕様書
テスト手順書
テスト項目移管レポート
テストログ
テスト不具合レポート
テストサマリーレポート

重要なのは、この枠組みの立場です。同書によれば、どのドキュメントを作るかの選択は組織の自由であり、すべてを揃える必要はありません。ただし「作る」と決めたなら、その文書は枠組みに従って書くべきだとされます。

テスト計画書に書く主要セクション

8ドキュメントのうち、計画書に相当するのがテスト計画書です。IEEE 829では、テスト計画書に次のようなセクションを設けます。

領域	主なセクション
識別・概要	計画書識別番号／概要
対象	対象項目／テストすべき特性／テストしない特性
進め方	アプローチ／合否基準／中断・再開基準
成果物・作業	成果物／テストタスク
体制・環境	環境条件／責任／要員計画
管理	スケジュール／リスクと対応策／承認

ここで用語を1つ整理しておきます。合否基準は個々のテスト項目に対する1件ごとの判定、完了条件（終了基準）はテスト活動全体を終えてよいかの判断で、両者は別物です。中断・再開基準は、そのテストを一時停止・再開してよい条件を指します。7要素の「完了条件」は、このうちテスト全体の終了判断にあたります。

これらは、先ほどの7要素の地図を、文書として具体化したものと考えると理解しやすいでしょう。各セクションの具体的な記入例やテンプレートの埋め方は、次の記事で確認できます。

テスト計画書の各項目の記入例とテンプレートを見る

まずは3行の最小骨子から始めてよい

とはいえ、いきなり全セクションを埋める必要はありません。小さな案件なら、次のような3行の最小骨子から始めれば十分です。

範囲: 会員登録・ログイン画面のみ（決済連携は対象外）
観点: 入力値の境界・異常系＋既存機能への影響
完了条件: 重要度「高」100％消化＋重大バグ0件

この3行があるだけで、「どこまでを・どんな視点で・どうなったら終わるか」がチームで共有できます。案件が大きくなるにつれて、環境条件や体制、スケジュールを足していけばよいのです。

枠組みに沿うと何が良いか

枠組みに沿って計画書を作る最大の利点は、説明責任と再現性です。

計画書は顧客・上長への説明責任を果たす道具でもあります。標準化された枠組みで書かれていれば、「なぜこの範囲・この工数なのか」を筋道立てて説明できます。

さらに、書式が揃うことで担当者ごとのブレも抑えられます。属人化を防ぎ、誰が担当しても一定品質にするための取り組みは、次の記事も参考にしてください。

属人化を防ぎチーム標準にする方法を確認する

計画は一度で完成しない｜適応型計画と「計画の5つの落とし穴」

ここまでで「計画とは何か」「何を決め、どう書き残すか」を見てきました。最後に、本記事がハブとして最も伝えたい視点を扱います。それは「計画は一度で完成しない」という思想です。

古典的計画 vs 適応型計画

Copeland『はじめて学ぶソフトウェアのテスト技法』では、計画の立て方を大きく2つに分けています。

種類	いつ計画するか	特徴
古典的計画	要件からコーディングの過程で	現時点の知識に基づき先に立てる
適応型計画	各機能がテスト可能になる前・テスト途中	予期せぬ現象を観察した時点で立て直す

適応型計画は、動的な・柔軟な・ジャストインタイムな・反応的な・前進的な計画とも表現されます。要は、走りながら情報を得て計画を更新していく進め方です。

同書は、優れた計画の原則として次の点を挙げます。知識に基づき計画できるところまで計画し、計画が可能になる前にはそれを行わない、というものです。先ほどの「計画できるところまで計画する」は、この原則を指しています。

適応型計画を実務でどう回すか

「走りながら更新する」と言われても、無秩序に変えてよいわけではありません。受託開発の現場では、次の4ステップに落とすと運用しやすくなります。

① 初日は骨格だけ確定する: 範囲・完了条件・体制など、初日でも決められる要素を先に固める
② テスト可能になった時点で観点を足す: 各機能が実装され触れるようになったら、その機能の観点を計画に追加する
③ 重大バグ検出時に再見積りする: 想定外の重大バグが出たら、工数・スケジュールをその場で立て直す
④ 週次で計画を更新する: 進捗と新情報を反映し、計画を最新の状態に保つ

計画は「初日に完成させるもの」ではなく「更新し続けるもの」です。この回し方なら、決め打ちの弊害と行き当たりばったりの両方を避けられます。

計画は学習プロセス｜新情報で見直す前提

適応型計画の背景には、計画そのものへの捉え方の転換があります。

同書がアメリカ海兵隊の『Planning』から引くように、計画は学習プロセスであり、計画書は暫定的な産物です。新しい情報が得られたら、見直しの対象になります。

同書がモルトケの言葉として引く「いったん敵に遭遇すれば、計画書は用をなさない」という一節も、同じ含意です。現場に出れば前提は必ず変わる。だからこそ計画書に固執せず、更新し続ける姿勢が要ります。

同書はさらに、「仕事を計画し、計画に従って仕事する」だけでは足りず、常に「仕事を計画し、計画に従って仕事し、仕事を見直し、計画を見直す」ようにすべきだと述べています。

計画の5つの落とし穴

とはいえ、計画への向き合い方を誤ると、かえって現場を縛ります。同書がアメリカ海兵隊の『Planning』から引く「計画の5つの落とし穴」は、受託開発の現場にもそのまま当てはまります。

落とし穴	受託開発での現れ方	回避の指針
遠い将来まで予想しすぎる	リリース後まで細かく決め、前提崩れで無駄になる	見通せる範囲までにとどめる
詳細まで計画しすぎる	初日に全ケースを固め、変更のたびに作り直す	粒度は段階的に上げる
手法を制度化し硬直化させる	過去の手順を思考停止で踏襲する	案件ごとに手法を選び直す
計画を唯一の解と思い込む	計画外の事象を無視してしまう	別解の余地を残す
フィードバック機構を無視する	途中の気づきを計画に反映しない	見直しの機会を組み込む