V字モデルとは？設計とテストの対応関係を4つの工程で解説

V字モデルとは、ソフトウェア開発の設計工程と、それを確かめるテスト工程を左右対称に対応づける開発の考え方です。要件定義には受入テスト、基本設計にはシステムテストというように、設計書ごとに「何をもって正しいとするか」を設計の段階で決めておく点が特徴です。

この記事では、設計工程4つとテスト工程4段階の対応を表で整理したうえで、現場での進め方5ステップと、フリーランスのPM・PMOが参画初日に確認したい3点までまとめます。読み終えたときに、設計書とテストの対応を自分の言葉で説明できる状態を目指します。なお、工程名や対応の組み方は会社やプロジェクトによって異なるため、本記事は2026年10月時点で一般的とされる整理に基づいています。

V字モデルとは？開発工程とテストを対応づける考え方

V字モデルは、開発工程をアルファベットのVの形に並べ、左側の設計工程と右側のテスト工程を横線で結んで対応づけるモデルです。左側を上から下へ設計して実装まで進み、右側を下から上へテストして完成に近づけます。

V字モデルが生まれた背景と目的

V字モデルの目的は、設計書ごとに対応するテストを前もって決め、検証の漏れを防ぐことです。テストを開発の最後にまとめて行うと、不具合の原因が要件や設計にあっても発見が遅れ、修正の範囲が大きくなりがちです。そこで、設計書を書く時点で「この設計書の内容は、このテストで確かめる」と対にしておきます。

ソフトウェアテストの国際資格を運営するISTQBの日本支部であるJSTQBのFoundation Levelシラバス（Version 2023V4.0.J02）でも、V字モデルはウォーターフォールモデルと並ぶシーケンシャル開発モデル（工程を順番に進める開発モデル）の例として挙げられています。

ウォーターフォールとの関係

V字モデルは、ウォーターフォール型の開発にテストの対応関係を加えて整理したものと捉えると理解しやすくなります。上流から下流へ工程を順に進める点は、どちらも同じです。

違いは、テスト工程の位置づけにあります。ウォーターフォールの説明では「設計、実装、テスト」と一列に並べて語られることが多い一方、V字モデルでは各テストが「どの設計書の内容を確かめるのか」を明示します。そのため、プロジェクトの進捗を報告する場面でも、設計書の完成度とテストの準備状況を並べて説明できます。

V字モデルの左側で押さえる設計工程4つ

左側の設計工程は、要件定義、基本設計、詳細設計、プログラミングの4つで、上から下へ向かうほど決める内容が細かくなります。プログラミングはV字の底にあたり、ここで設計がコードに変わります。

要件定義と基本設計の違い

要件定義は「業務として何を実現したいか」を決める工程で、基本設計は「システムとしてどう実現するか」を決める工程です。前者は発注側の業務の言葉で書かれ、後者はシステムの画面や機能の言葉で書かれます。

架空の受発注システムで考えてみます。要件定義書には「受注内容を当日中に出荷指示へ反映したい」と書かれます。これを受けて基本設計書では、「受注登録画面で商品コードと数量を入力し、登録時に在庫システムへ引当を依頼する」といった画面と連携の仕様に落とし込みます。要件定義が「目的」、基本設計が「その目的を満たす仕様」という関係です。

詳細設計とプログラミングの位置づけ

詳細設計は、基本設計書の仕様をプログラムが実装できる粒度まで分解する工程で、プログラミングはその設計書をコードに変える工程です。詳細設計書には、処理の分岐条件、入力チェックの内容、データベースの項目といった、開発者が迷わず実装できる情報を書きます。

受発注システムなら、「数量は1以上999以下の整数のみ受け付ける」「範囲外ならエラーメッセージを表示する」といった記述が詳細設計書に入ります。なお、基本設計を外部設計、詳細設計を内部設計と呼ぶ会社もあります。名称が違っても、粗い設計から細かい設計へ進む流れは変わりません。

V字モデルの右側で行うテスト工程4段階

右側のテスト工程は、単体テスト、結合テスト、システムテスト、受入テストの4段階で、下から上へ向かうほど確認する範囲が広がります。小さい単位で不具合を取り除いてから、より大きな単位の確認へ進む順序です。

単体・結合・システム・受入テストの目的

各テストは、確認する範囲と、確認する主体が異なります。次の表に、4段階の目的を整理します。

JSTQBのシラバスでは、単体テストに相当するものを「コンポーネントテスト（ユニットテストとも呼ばれる）」、結合テストに相当するものを「コンポーネント統合テスト」と呼んでいます。同シラバスは、テストレベルとして、これらにシステムテスト、システム統合テスト（他システムや外部サービスとのインターフェースの確認）、受け入れテストを加えた5つを説明しています。国内の現場では、システム統合テストをシステムテストや結合テストに含めて4段階で呼ぶ場合があり、実施者も会社ごとに異なります。

各テストが設計書のどれと対応するか

各テストは、対応する設計書の記述を「正解」として、合格か不合格かを判断します。一般的な対応は次の4組です。

• 要件定義書と受入テスト：業務の要求が満たされているかを確かめます。
• 基本設計書とシステムテスト：画面や連携を含むシステム全体の振る舞いを確かめます。
• 詳細設計書と結合テスト：プログラム間の受け渡しが設計どおりかを確かめます。
• プログラムと単体テスト：1つひとつのプログラムが詳細設計書どおりに動くかを確かめます。

設計書に判断の基準が書かれていなければ、対応するテストは合否を決められません。そのため、設計書のレビューでは「この記述はテストで確認できる形になっているか」という視点が役立ちます。

設計工程とテスト工程の対応を表で確認する

対応表とは、設計書、対応するテスト、確認する観点、具体例を1つの表に並べたものです。架空の受発注システムを題材に、左から右へ読める形にしました。

対応表の読み方と見落としやすい点

対応表は、設計書の名前から右へ読み、「この設計書の内容は、どのテストで、何を基準に確かめるのか」を確認するために使います。表の空白は、検証されないまま残る設計の記述があるというサインです。

見落としやすい点は、主に3つあります。

1. 設計書に合否の基準が書かれていない場合、テストの期待値を決められません。数量の範囲や表示される文言など、確認できる形で書かれているかを見ます。
2. 性能やセキュリティといった非機能要件は、どの設計書からどのテストへ対応するのかが空白になりやすい項目です。
3. 対応の組み方は会社ごとに異なります。たとえば、基本設計書を結合テストに、詳細設計書を単体テストに対応づける組織もあります。自分が参画する現場の定義を確かめてから使います。

V字モデルを現場で使うときの進め方5ステップ

現場でV字モデルを使うときは、受入条件の確定から対応表の更新までを、次の5ステップで進めます。各ステップで、何を見て、何が出来上がるのかを明確にします。

1. STEP1：要件から受入条件を先に決めます。入力は要件定義書、出力は要件ごとの受入条件の一覧です。
2. STEP2：設計書ごとにテスト観点を紐づけます。入力は基本設計書と詳細設計書、出力は設計書、テスト、観点を並べた対応表です。
3. STEP3：対応表をテスト計画に落とし込みます。入力は対応表と体制・スケジュール（スケジュールはWBSの作成手順に沿って作業単位に分けます）、出力は実施者、環境、期間、開始基準と終了基準を記したテスト計画書です。
4. STEP4：終了基準を満たしてから次のテストへ進みます。入力はテスト結果と不具合一覧、出力は工程ごとの完了判定の記録です。
5. STEP5：設計変更が出たら対応表を更新します。入力は変更要求、出力は更新後の対応表と、再テストが必要な範囲の一覧です。

STEP4について、JSTQBのシラバスは、シーケンシャルな開発モデルでは、あるテストレベルの終了基準が次のレベルの開始基準の一部になるよう定義されることが多いと説明しています。終了基準を決めずに次へ進むと、前の工程の不具合が後ろへ持ち越されます。

STEP1 要件から受入条件を先に決める

受入条件は、要件定義の段階で「どうなれば要件を満たしたと言えるか」を、数や時刻で確認できる形に書いたものです。右側の最後にあたる受入テストの基準を、左側の最初で決めるところに、V字モデルの考え方が最もよく表れます。

受発注システムの例では、要件定義書の「受注内容を当日中に出荷指示へ反映したい」を次のように書き換えます。「午後5時までに登録した受注10件が、同日中に出荷指示一覧に表示される」。件数と時刻が入ることで、受入テストの担当者が同じ手順で確認でき、合否の判断が人によってぶれません。

STEP2 設計書ごとにテスト観点を紐づける

設計書の1つの記述に対して、確認するテスト観点を1つ以上ひも付け、設計書の項番とテストケースのIDで対応を追えるようにします。観点とは、「何に注目してテストするか」のことです。

たとえば、詳細設計書の項番3.2に「数量は1以上999以下の整数のみ受け付ける」とあれば、単体テストの観点は境界値（0、1、999、1000）の入力です。結合テストでは、入力した数量が在庫引当のプログラムへ正しく渡るかを観点にします。項番とテストケースIDを対応表に残しておくと、設計変更の際にどのテストを見直すのかがすぐに分かります。

V字モデルの弱点とアジャイル開発での扱い方

V字モデルの弱点は、要件や設計の誤りが右側のテストまで見つからず、見つかったときの手戻りが大きくなる点です。とくに受入テストで要件の解釈違いが分かると（開発全体のリスク管理でも代表的な懸念です）、V字の一番上まで戻って修正することになります。

手戻りが大きくなる場面と回避策

手戻りが大きくなるのは、受入テストの段階で要件の解釈違いが見つかる場面で、回避策は受入条件と設計をテストより前にレビューすることです。次の3つが実務でよく使われます。

• 受入条件を要件定義の段階で数や時刻の形に書き、発注側と合意します。
• 設計書をシステム開発のレビューにかけ、コードを動かす前に誤りを見つけます。JSTQBのシラバスでも、シーケンシャル開発モデルの初期段階では、テスト担当者が要件レビューやテスト設計に関わると説明されています。
• 画面や操作の流れなど誤解が生じやすい部分は、早い段階で試作品を見せて確認します。

アジャイル開発では、イテレーション（短い開発期間）ごとに設計、実装、テストを繰り返します。JSTQBのシラバスによれば、反復型や増分型の開発では、各イテレーションで静的テストと動的テストの両方が、すべてのテストレベルで実行される可能性があります。V字を1回だけ大きく回すのではなく、小さな単位で何度も回すイメージです。そのため、アジャイルの案件であっても、設計とテストの対応という発想は役立ちます。ただし、設計書を軽くする代わりに、受入条件を細かく共有する運用になる点は、V字モデルの現場と異なります。

フリーランスのPM・PMOがV字モデルで確認すべき3点

参画初日に確認すべき3点は、工程定義書の有無、受入条件の確定時期、テスト責任者の3つです。この3点が分かると、プロジェクトがV字モデルのどこまで運用できているかを短時間でつかめます。

1. 工程定義書（標準プロセスの文書）の有無です。確認の入力は、プロジェクト計画書や標準プロセスの資料です。出力は、その現場での工程名と、設計書とテストの対応の定義です。
2. 受入条件の確定時期です。確認の入力は、要件定義書とスケジュールです。出力は、受入条件の確定予定日と、確定していない要件の一覧です。
3. テスト工程ごとの責任者です。確認の入力は、体制図とテスト計画書です。出力は、単体、結合、システム、受入の各テストの責任者と、終了基準を承認する人の名前です。

参画初日に工程の対応関係を見る方法

初日は、WBSや進捗表を見る前に、設計書の一覧とテスト計画書を並べて見て、STEP2で作る対応表の空白を探します。設計書は存在するのに対応するテストの記載がない行、またはその逆の行があれば、そこが優先して確認すべき箇所です。

質問は、次のように具体的にすると答えを得やすくなります。「基本設計書は、どのテストで確認する計画ですか」「受入テストの合格基準は、いつ誰が決めますか」。プロジェクトの初期に確認できていれば、後半に手戻りが発生する兆候を早めにつかめます。

参画前の段階でも、確認できることがあります。大手企業の案件では、与信や機密の都合から、法人を挟む3者間契約になるケースが多いとされています。そのため、現場の工程定義やテスト体制の質問は、エージェントの担当者を通じて事前に尋ねる形が一般的です。面談の際に「テスト工程の責任者は誰か」を聞いておくと、参画初日の確認がスムーズに進みます。

出典・参考情報

1. JSTQB「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02」（2.1節、2.2節。2026-10-19参照）

対応表の例は、架空の受発注システムを題材に編集部が作成したものです。工程名・対応関係・実施者は会社やプロジェクトによって異なるため、参画する現場の定義を確認してください。最終更新日：2026年10月19日。