Vモデル（V字モデル）とは？システム開発工程とテストの対応関係を早見表で解説

2025 7/22

2025年7月22日 2026年8月7日

ソフトウェア開発において、品質の高いシステムを効率的に構築するためには、適切な開発プロセスの選択が欠かせません。その中でも「Vモデル」は、開発工程とテスト工程の対応関係を明確に示した手法として、システム開発の現場で最も広く使われている考え方です。

この記事では、Vモデル（V字モデル）の基本構造と対応関係の早見表、メリット・デメリット、向いているプロジェクトの判断基準、W字モデル・アジャイル開発との関係、そして実務で機能させるための5つのポイントまでを、テスト代行の現場視点でまとめて解説します。

Vモデル（V字モデル）とは？開発工程とテスト工程を対にした開発モデル

Vモデルとは、システム開発の工程とテストの工程を1対1で対応させて、アルファベットの「V」の字に並べた開発モデルのことです。左側の下り坂が開発工程（要件定義→基本設計→詳細設計→実装）、右側の上り坂がテスト工程（単体テスト→結合テスト→システムテスト→受入テスト）を表しています。

ポイントは、右辺のテストは「対応する左辺の工程で決めたこと」を検証するために存在するという点です。単体テストはプログラム設計どおりに動くかを、受入テストは要件定義で約束した業務要求を満たすかを確認します。テストが「なんとなく最後にまとめてやるもの」ではなく、上流の成果物と紐づいた検証活動になる。これがVモデルの核心です。

「Vモデル」「V字モデル」「V字開発」は同じものを指す

調べ始めた方がまず戸惑うのが呼び方の多さです。結論から言うと、以下はすべて同じ開発モデルを指しており、内容に違いはありません。

呼び方	使われやすい場面・ニュアンス
Vモデル	ソフトウェアテストや品質保証の文脈での標準的な呼称。V-Modelの直訳
V字モデル	日本語の記事・書籍で最も一般的。図の形状をそのまま名前にしたもの
V字開発	「V字モデルに沿った開発の進め方」を指す言い方。SIerの提案書などで使われる
システム開発のV字モデル	Web／業務システム開発の工程管理という文脈を明示した言い方
V字型開発モデル／V-Model	書籍や英語文献での表記

本記事でも「Vモデル」と「V字モデル」を文脈に応じて使い分けますが、どちらも同じものを指しています。社内やベンダーとの会話で呼び方が食い違っていても、指しているのは「開発工程とテスト工程の対応関係を定めた同じ枠組み」だと理解しておけば問題ありません。

Vモデルの歴史と背景｜1980年代の標準化から現在まで

V字モデルは1980年代に、複数の系譜で並行して提唱されました。よく知られているのが、ドイツ連邦政府が公共システム調達の標準プロセスとして整備した「V-Modell」です。1992年に公的な標準として公表され、その後も改訂を重ねながら、防衛・行政システムの開発標準として使われてきました。

同時期に、英国でもソフトウェア開発とテストの対応関係を示すモデルとして同様の考え方が提唱され、航空宇宙・医療機器・自動車といったミッションクリティカルな領域を中心に普及しました。日本では、IPA（情報処理推進機構）が整備した共通フレームの工程定義とも親和性が高く、SIerの標準開発プロセスとして定着しています。

現在では、それぞれの企業が自社の開発環境に合わせてカスタマイズしたV字モデルを採用しており、「唯一の正しいV字モデル」が存在するわけではない点も押さえておきましょう。

ウォーターフォールモデルとV字モデルの関係

「V字モデルとウォーターフォールモデルは何が違うのか」は非常によくある疑問です。両者は対立する概念ではなく、V字モデルはウォーターフォールモデルを「テストの視点」で描き直したものと理解するのが正確です。

観点	ウォーターフォールモデル	V字モデル（V字開発）
図の形	左上から右下への一直線の階段	V字（開発工程で下り、テスト工程で上る）
工程の進め方	前工程が完了してから次工程へ	同じ（ウォーターフォールがベース）
テストの位置づけ	最終工程にまとめて置かれることが多い	各開発工程と1対1で対応づけられる
強調している点	工程の順序と後戻りしないこと	「どの成果物を、どのテストで検証するか」

つまり、システム開発工程をV字で描くメリットは、テスト計画を上流工程の段階で立てられるようになることにあります。ウォーターフォール型で進めているプロジェクトであれば、V字モデルの考え方はそのまま適用できます。

V字モデルの対応関係一覧｜システム開発工程とテスト工程の早見表

V字モデルを理解するうえで最も重要なのが、左辺（開発工程）と右辺（テスト工程）の対応関係です。まずは全体像を表で押さえてください。

左辺：開発工程	主な成果物	右辺：対応するテスト工程	検証する内容	主な実施者
要件定義	要件定義書、業務フロー、受入基準	受入テスト（UAT）	発注者の業務要求どおりに使えるか（妥当性確認）	発注者・ユーザー部門
基本設計（外部設計・システム設計）	基本設計書、画面・帳票仕様、外部インターフェース仕様	システムテスト（総合テスト）	システム全体が仕様どおりに動くか（機能・性能・セキュリティ）	テストチーム・第三者検証
詳細設計（内部設計・サブシステム設計）	詳細設計書、モジュール構成図、内部インターフェース仕様	結合テスト（統合テスト）	モジュール間の連携やデータの受け渡しが設計どおりか	開発チーム・テストチーム
プログラム設計（モジュール設計）	クラス図、関数仕様、処理ロジック	単体テスト（コンポーネントテスト）	個々のモジュールが仕様どおりに動くか	プログラマー
実装（コーディング）	ソースコード	―（V字の底で折り返す）	ここから右辺のテスト工程へ進む	プログラマー

対応関係を読み解く3つのルール

テストケースは、対応する左辺の成果物から導出する：結合テストのテストケースは詳細設計書から、システムテストのテストケースは基本設計書から作ります。「実装されたコードを見てテストを作る」のはV字モデルの考え方から外れます。
V字の高さは「抽象度」を表す：上に行くほど業務・ユーザーに近い視点、下に行くほど技術・実装に近い視点になります。受入テストで技術的な内部処理を確認しようとすると、テストの粒度がずれます。
右辺のテストは「検証」と「妥当性確認」に分かれる：単体〜システムテストは「設計どおりに作れているか」を見る検証（Verification）、受入テストは「そもそも正しいものを作ったか」を見る妥当性確認（Validation）です。この2つは目的が異なるため、片方だけでは品質を保証できません。

「基本設計＝結合テスト」説と「基本設計＝システムテスト」説はどちらが正しい？

V字モデルを調べていると、対応関係が資料によって食い違っていることに気づくはずです。これは多くの人がつまずくポイントなので、整理しておきます。

	4層版（本記事の表）	3層版
要件定義	受入テスト	受入テスト／システムテスト
基本設計	システムテスト	結合テスト
詳細設計	結合テスト	単体テスト
プログラム設計	単体テスト	（詳細設計に含める）

どちらも間違いではありません。違いは「設計工程を何段階に分けるか」だけです。設計をプログラム設計まで4段階に分ければ4層版に、詳細設計までの3段階にまとめれば3層版になります。テスト工程の数と設計工程の数を合わせているだけなので、層の数が変われば対応相手も1段ずれます。

実務で重要なのは、どちらの流派が正しいかではなく、プロジェクトの開始時に「自社ではどの設計書を、どのテストで検証するのか」を関係者で合意しておくことです。ここが曖昧なまま進むと、「その観点は結合テストでやると思っていた」「いやシステムテストの範囲だ」というテスト漏れが必ず発生します。

システム開発のV字モデル｜左辺（開発工程）の役割と成果物

ここからは、V字モデルの左辺にあたる各開発工程を、「何を決める工程か」と「どのテストの基準になるか」の2点に絞って見ていきます。

要件定義｜何を作るのかを決める

開発プロセスの最初のステップとして、ユーザーや顧客のニーズを明確にし、システムが実現すべき機能や性能を定義します。この段階では「何を作るのか（What）」に答えることが目的で、「どう作るか（How）」にはまだ踏み込みません。

主な成果物は要件定義書、業務フロー図、非機能要件一覧などです。これらは受入テストの基準になるため、「何をもって完成とみなすか」という受入基準まで書き切れているかが、後工程の混乱を防ぐ分かれ目になります。

基本設計（外部設計・システム設計）｜ユーザーから見える仕様を決める

要件定義をもとに、システム全体の構造と、ユーザーや外部システムから見える振る舞いを設計します。画面レイアウト、帳票、データベースの論理設計、外部システムとの連携インターフェース、システムアーキテクチャなどがここで決まります。

成果物である基本設計書は、システムテストのテストケースを作る際の一次資料になります。上流工程と下流工程の境目にあたる工程で、ここでの曖昧さは下流のすべてに波及します。

詳細設計（内部設計・サブシステム設計）｜内部構造とモジュール分割を決める

基本設計で定義した機能を、実装可能な単位まで分解する工程です。モジュール構成、モジュール間の呼び出し関係、データの受け渡し形式、エラー処理方針などを具体化します。

詳細設計書やモジュール仕様書が成果物となり、これらが結合テストの基準になります。モジュール間のインターフェース定義が甘いと、結合テストで大量の不具合が噴き出すことになります。

プログラム設計（モジュール設計）｜クラス・関数レベルの仕様を決める

個々のモジュールやクラスの内部を設計する工程です。プログラミング言語の特性を踏まえて、データ構造、アルゴリズム、メソッドの入出力仕様を定義します。

クラス図やシーケンス図、関数仕様書が成果物となり、これらが単体テストの基準になります。なお、この工程を詳細設計に含めて扱う企業も多く、その場合は前述の3層版の対応関係になります。

実装（コーディング）｜V字の底で折り返す

設計に基づいて実際にプログラムを作成する段階です。ソースコードが主な成果物となり、ここがV字の底、つまり折り返し地点になります。実装工程には対応するテスト工程がありません。実装の正しさは、直上の単体テストから順に上へ検証していく形で確認されます。

V字モデルの右辺（テスト工程）｜何をどこまで検証するか

右辺のテスト工程は、下から上へと進みます。各テスト工程は、左側の対応する開発工程で作成された成果物を検証するために設計されている点を意識してください。

単体テスト（コンポーネントテスト）｜モジュール単位の正しさを検証する

個々のモジュールやクラスが正しく実装されているかを検証するテストです。プログラム設計で定義された仕様に基づいて、各モジュールが期待通りの動作をするかをテストします。分岐や境界値を網羅する必要があるため、テストケース数は右辺の中で最も多くなります。

主にプログラマーが実施し、テスティングフレームワークによる自動化が最も進めやすい層です。CI（継続的インテグレーション）に組み込んで、コミットのたびに自動実行する体制を作れると効果が大きくなります。

結合テスト（統合テスト）｜モジュール間の連携を検証する

複数のモジュールを組み合わせた際の動作を検証するテストです。詳細設計で定義されたインターフェースやデータの受け渡しが正しく機能するかを確認します。単体では正常でも、組み合わせた瞬間に破綻するケースを洗い出す工程です。

テストケースは詳細設計書から導出し、モジュール間の依存関係、異常系のエラー伝播、外部システムとの連携に焦点を当てます。

システムテスト（総合テスト）｜システム全体を通しで検証する

システム全体としての機能や性能を検証するテストです。基本設計で定義された仕様に基づいて、本番に近い環境でシステム全体が期待通りに動作するかを確認します。

テストケースは基本設計書から導出し、以下のような複数の観点でテストを実施します（各テストの進め方は「システム開発テストの基本と実践｜品質確保の完全ガイド」でも解説しています）。

機能テスト：業務シナリオに沿って一連の操作が通るか
性能テスト・負荷テスト：想定ユーザー数・データ量で応答時間の要件を満たすか
セキュリティテスト：認証・認可・入力値検証が適切か
互換性テスト：対象ブラウザ・OS・端末で正しく動作するか
運用テスト：バックアップ、障害復旧、バッチ実行などの運用手順が回るか

受入テスト（UAT）｜発注者の業務要求を満たすかを検証する

最終的なユーザーや顧客の視点からシステムを検証するテストです。要件定義で定められた要件を満たしているか、実際の業務がこのシステムで回るかを確認します。

テストケースは要件定義書から導出し、ユーザー部門の代表者が参加して実施されるのが一般的です。ここで初めて「仕様どおりだが業務では使えない」という妥当性の問題が見つかることがあり、それを避けるためにも要件定義の段階で受入基準を明文化しておくことが重要になります。

V字モデル（V字開発）を活用するメリット

テスト内容を上流工程で確定できる

V字モデルの最大の特徴は、開発の初期段階からテストを計画できる点です。要件定義の段階で受入テストの計画を、基本設計の段階でシステムテストの計画を立てられます。テスト工程に入ってから「何をテストすればいいのか」を考え始める状況を避けられるため、テスト準備の遅れによるスケジュール逼迫が起きにくくなります。

各工程の責任者と完了基準が明確になる

「どの成果物を、誰が、どのテストで検証するか」が対応関係として定義されるため、責任の所在が明確になります。不具合が出たときに「どの工程の抜けが原因か」をたどりやすく、原因工程にフィードバックして再発防止につなげられます。

進捗を定量的に管理できる

各工程の成果物と完了基準が定義されているため、プロジェクトの進捗管理が容易になります。テスト工程では「テストケース消化率」「不具合検出数と収束傾向」といった指標で進捗と品質を数値で追えるため、プロジェクトマネージャーが状況を正確に把握し、必要に応じて対策を打てます。

手戻りリスクと修正コストを削減できる

ソフトウェア開発では、不具合の修正コストは発見が遅れるほど跳ね上がることが経験則として知られています。要件定義の誤りを要件定義の段階で直せば書き直すだけで済みますが、リリース後に発覚すれば、設計・実装・テスト・リリース手順のすべてをやり直すことになります。

不具合を検出した工程	必要になる作業	修正コストの傾向
要件定義・設計のレビュー	ドキュメントの修正	小
単体テスト・結合テスト	コード修正＋再テスト	中
システムテスト・受入テスト	設計見直し＋広範囲の再テスト	大
リリース後（本番障害）	緊急対応＋業務影響の補償＋信頼低下	極大

V字モデルは、各開発工程の成果物に検証の相手を割り当てることで、この「発見の遅れ」を構造的に減らす仕組みだと言えます。

V字モデルのデメリットと対応策

V字モデルには多くのメリットがある一方で、構造上避けられない弱点もあります。デメリットを把握したうえで対応策とセットで導入することが、V字開発を機能させるカギです。

デメリット	現場で起きること	対応策
仕様変更・要件変更に弱い	実装後の変更で、設計書・コード・テストケースを全部直すことになる	変更管理プロセスを定め、影響範囲を対応表でたどれるようにする。大きな機能単位でミニV字を回す
不具合の発見が後工程に偏る	システムテストで設計の根本的な不備が見つかり、日程が崩れる	左辺の各工程にレビュー・ウォークスルーを必須で挟む（W字モデル化）
ドキュメント作成の負荷が大きい	設計書の作成に時間を取られ、開発着手が遅れる	テストケース導出に必要な粒度を先に定義し、それ以上は書かないと決める
開発チームとテストチームが分断されやすい	テスト担当が仕様を理解しておらず、的外れな不具合報告が増える	テストエンジニアを要件定義・設計のレビューに参加させる
立ち上げに時間がかかる	小規模案件ではプロセスのオーバーヘッドが目立つ	工程を3層に圧縮する、単体テストと結合テストを統合するなど、規模に合わせて簡略化する

対応策の要は「左辺での早期検証」

デメリットの多くは「検証が右辺に偏る」ことに起因します。そこで、左辺の開発工程中にも検証活動を組み込むことが有効です。具体的には次のような活動が挙げられます。

要件定義のレビューとウォークスルー（テスト可能な書き方になっているかを確認する）
設計段階でのプロトタイピングや机上検証
設計レビューへのテストエンジニアの参加
静的コード解析ツールの活用
継続的インテグレーション（CI）による自動ビルド・自動テストの実行

これらを通じて、右辺のテスト工程に入る前に多くの問題を発見・修正できます。この考え方を体系化したものが、後述するW字モデルです。

V字モデルが向いているプロジェクト・向かないプロジェクト

V字モデルはあらゆるプロジェクトに適しているわけではありません。プロジェクトの特性や制約を踏まえて、適切な開発モデルを選択することが重要です。

V字モデルに向いているプロジェクト

要件が明確で安定しているプロジェクトには、V字モデルが適しています。

既存システムのリプレース・再構築プロジェクト
法令や業界規制など、明確な要件に基づくシステム開発
標準化された業務プロセスを自動化する基幹システム

また、信頼性や安全性が特に重要なシステムの開発には、体系的な検証アプローチを持つV字モデルが適しています。

医療機器や自動車の制御システム
金融システムや決済システム
航空宇宙・社会インフラ関連のシステム
監査や第三者への品質証明が求められるシステム

加えて、多数のベンダーや協力会社が関わる大規模プロジェクトとも相性が良いモデルです。工程と成果物が定義されているため、分業と進捗管理がしやすくなります。

V字モデルに向かないプロジェクト

要件が流動的なプロジェクトでは、V字モデルよりもアジャイル開発などの反復的なアプローチが適しています。

新規事業向けの、仮説検証を繰り返すサービス開発
ユーザー体験の改善を継続的に行うWebアプリケーション
市場や競合の変化に迅速に対応する必要があるプロダクト

また、開発期間が短く早期リリースが求められるプロジェクトでは、V字モデルの体系的なアプローチよりも、機能を絞ったMVP（Minimum Viable Product）を先に出す進め方が適しています。

判断チェックリスト｜4つ以上当てはまればV字モデル向き

リリース時点で満たすべき要件を、着手前に文書で確定できる
開発期間中の仕様変更が限定的で、変更管理プロセスがある
障害が発生したときの業務影響・金銭影響が大きい
発注者・監査部門に対して、テストの網羅性を証明する必要がある
複数チーム・複数ベンダーで分担して開発する
設計ドキュメントを作成・維持する体制と工数を確保できる

V字モデルと他の開発モデルの違い

開発モデル	進め方	テスト設計の開始時期	仕様変更への強さ	向いているプロジェクト
ウォーターフォールモデル	工程を順に一度だけ通す	実装完了前後	弱い	要件が固まった大規模開発
V字モデル（V字開発）	ウォーターフォールを開発とテストの対で描く	対応する開発工程の完了後	弱い	高信頼性が求められる開発
W字モデル	開発とテスト設計を並走させる	対応する開発工程と同時	やや強い	大規模かつ品質要求が高い開発
アジャイル開発	短い反復で開発とリリースを繰り返す	各反復の中で都度	強い	要件が流動的なサービス開発
プロトタイプ開発	試作品でユーザー確認してから本開発	本開発の工程に準じる	中程度	要件が固まっていないUI中心の開発

W字モデルとの違い｜テスト設計を並走させる進化形

W字モデル（Wモデル）は、V字モデルの各開発工程に、対応するテストの設計・準備工程を並走させた考え方です。開発のV字とテスト設計のV字が重なって「W」の形に見えることから、この名前で呼ばれます。

たとえば要件定義を行っている間に、テストエンジニアが並行して受入テストの設計を進め、その過程で「この要件はテストできない書き方になっている」と指摘する。テストを作ろうとすることで、設計段階の曖昧さや矛盾があぶり出されるのがW字モデルの本質的な価値です。

比較軸	V字モデル	W字モデル
テスト設計の開始	対応する開発工程が終わってから	対応する開発工程と同時に並走
テスト担当者の参画時期	実装完了後が中心	要件定義の段階から参画
不具合が見つかる場所	右辺のテスト実行時	左辺の設計レビュー時にも見つかる
手戻りコスト	大きくなりやすい	抑えやすい
必要な体制	開発チーム主体でも回せる	テストエンジニアの上流参画が前提
向いているケース	要件が安定した中規模までの開発	大規模・高信頼性・要件に不確実性がある開発

W字モデルを実践するポイントは次の5つです。

開発とテストの協業体制の構築：開発の初期段階からテストエンジニアを参加させ、両チームの密接な連携を促進します。
レビューと検証の文化醸成：各工程の成果物に対して、多角的な視点からのレビューを行う文化をつくります。
テスト駆動開発の要素の取り入れ：テストケースを先に設計し、それに基づいて開発を進めることで、テスト可能性の高い設計を促します。
継続的インテグレーションの活用：自動ビルドと自動テストを頻繁に実行し、問題を早期に検出します。
段階的なリリース計画：大きな機能を小さな単位に分割し、段階的に開発・テスト・リリースしてリスクを分散します。

U字モデルとの違い

U字モデルは、V字の底にあたる実装工程を1点ではなく「幅のある区間」として捉え、実装と単体テストを一体の反復として扱う考え方です。図の形がVではなくUに近くなることから、こう呼ばれます。テスト自動化やCIが前提の開発では、実装と単体テストが分離できないため、この描き方のほうが実態に近い場合があります。

アジャイル開発ではV字モデルは使えないのか

「アジャイル開発を採用しているからV字モデルは関係ない」と考えるのは早計です。V字モデルが定義しているのは工程の順序ではなく、「決めたこと」と「検証すること」の対応関係です。この対応関係は、開発の進め方が反復型であっても成り立ちます。

実際、アジャイル開発でも次のような形でV字の考え方が活きています。

1つのスプリントの中で、ユーザーストーリー（＝要件）に対する受入基準を先に定義し、それを受入テストで確認する
テストピラミッド（単体テスト＞結合テスト＞E2Eテスト）の階層は、V字の右辺のテストレベルと対応している
リリース判定の段階で、システム全体を通した回帰テストを実施する

つまりアジャイル開発は、小さなV字をスプリントごとに何度も回していると捉えられます。V字モデルとアジャイル開発は排他的な選択肢ではありません。

「V字モデルは古い」と言われるのは本当か

V字モデルが1980年代に生まれたモデルであることから、「古い」「時代遅れ」という評価を目にすることがあります。しかし批判の対象になっているのは、多くの場合V字モデルそのものではなく、「大量のドキュメントを作り、テストを最後にまとめて実施する」という運用の仕方です。

「決めたことは、対応するテストで検証する」という原則自体は、開発手法が変わっても有効です。実際、JSTQBのテストレベル（コンポーネントテスト／統合テスト／システムテスト／受入テスト）の定義はV字の右辺そのものであり、現在のソフトウェアテストの共通言語として使われ続けています。古いのはモデルではなく運用、と理解するのが実態に即しています。

V字モデルを実務で機能させる5つのポイント

V字モデルは「図を知っている」だけでは効果が出ません。実践で成果につなげるために、最低限押さえておきたい5点を挙げます。

①要件定義と同時に受入テストの合格条件を書く

要件定義書に「〜できること」と書くだけでは、受入テストの合格条件になりません。「どの操作を、どのデータで行い、どうなれば合格か」まで書けて初めてテスト可能な要件です。要件定義のレビューに、テスト設計を担当する人を必ず同席させましょう。

②要件とテストケースをトレーサビリティマトリクスで紐づける

要件番号とテストケース番号の対応表を作り、すべての要件が最低1つのテストケースでカバーされている状態を維持します。これにより、テスト漏れの検出と、仕様変更時の影響範囲の特定が一気に楽になります。V字モデルの対応関係を、実際に運用可能な形に落とし込む作業がこれにあたります。

③各テスト工程の入口条件・出口条件を先に決める

「単体テストが終わっていないコードは結合テストに入れない」「システムテストは未解決の重大不具合ゼロで完了とする」といった条件を、テスト計画の段階で明文化します。条件を決めていないと、下流工程が前工程の未完了分を吸収して破綻します。

④設計工程ごとにテスト観点レビューを挟む

基本設計・詳細設計の完了時に、「この設計書からテストケースが書けるか」という観点でレビューします。書けないなら設計に曖昧さが残っている証拠です。これは前述のW字モデルの考え方を、既存のV字プロセスに部分的に取り込む方法でもあります。

⑤テスト工程に第三者検証（テスト分離）を組み込む

V字モデルの右辺、特にシステムテストと受入テストは、作った本人以外が検証したほうが不具合の検出率が上がります。開発担当者は「こう動くはず」という前提を持っているため、その前提自体が誤っているケースを見つけにくいからです。

開発とテストの担当を分ける「テスト分離」や、外部のテスト専門チームに委託する「第三者検証」を組み込むことで、V字モデルが本来持つ検証力を引き出せます。リリース直前にテスト要員が不足しがちなプロジェクトでは、この部分を外部に切り出すことでスケジュールの平準化にもつながります。

V字モデル（V字開発）に関するよくある質問

Q. VモデルとV字モデル、V字開発は違うものですか？

すべて同じものを指します。「Vモデル」は英語のV-Modelの直訳、「V字モデル」は日本語で最も一般的な呼び方、「V字開発」はV字モデルに沿った開発の進め方を指す言い方です。「システム開発のV字モデル」も同義で、システム開発工程をV字で表現したものを意味します。

Q. V字モデルとウォーターフォールモデルの違いは何ですか？

対立する概念ではありません。V字モデルはウォーターフォールモデルをベースに、各開発工程と対応するテスト工程を明示した描き方です。ウォーターフォール型で進めているプロジェクトには、そのままV字モデルの考え方を適用できます。

Q. 基本設計に対応するのは結合テストですか、システムテストですか？

設計工程を何段階に分けるかによって変わります。プログラム設計まで4段階に分ける流派では「基本設計＝システムテスト」、詳細設計までの3段階にまとめる流派では「基本設計＝結合テスト」になります。どちらも間違いではないので、プロジェクト開始時に社内で定義を統一してください。

Q. 実装工程に対応するテスト工程がないのはなぜですか？

実装はV字の底、つまり折り返し地点だからです。実装の成果物であるソースコードは、直上の単体テストから順に検証されていきます。実装工程だけを単独で検証する層は存在しません。

Q. アジャイル開発を採用している場合、V字モデルは不要ですか？

不要ではありません。V字モデルが定義しているのは「決めたことと検証することの対応関係」であり、これは反復型開発でも成り立ちます。アジャイル開発は小さなV字をスプリントごとに繰り返していると捉えられます。

Q. 小規模なプロジェクトでもV字モデルを使うべきですか？

工程を簡略化したうえで適用するのが現実的です。たとえば設計を基本設計・詳細設計の2層に圧縮し、単体テストと結合テストを1工程にまとめる方法があります。重要なのは工程の数ではなく、「この成果物は、どのテストで確認するのか」がすべて埋まっていることです。

まとめ｜V字モデルは「決めたことを検証する」ための設計図

Vモデル（V字モデル、V字開発）は、システム開発工程とテスト工程を1対1で対応させることで、テストを上流から計画可能にする開発モデルです。要点を整理します。

「Vモデル」「V字モデル」「V字開発」「システム開発のV字モデル」はすべて同じものを指す
左辺（要件定義→基本設計→詳細設計→実装）と右辺（単体テスト→結合テスト→システムテスト→受入テスト）が対応する
テストケースは、対応する左辺の成果物から導出するのが原則
対応関係には3層版と4層版があり、どちらも正しい。プロジェクト内で定義を統一することが重要
弱点は仕様変更への対応力。左辺での早期検証（W字モデル化）で補える
アジャイル開発とも両立する。「古い」と言われるのはモデルではなく運用の問題

そして、V字モデルを図として理解していても、右辺のテスト工程を回しきる体制がなければ品質は上がりません。テスト設計・テスト実行の工数が確保できない、テスト観点の網羅性に不安がある、リリース直前に人手が足りなくなる。こうした課題は、右辺の一部を第三者検証として切り出すことで解消できるケースが少なくありません。

ソフトウェアテスト代行サービス「テスター10」では、システムテスト・受入テストを中心に、テスト計画の策定からテストケース作成、テスト実行、不具合報告までをご支援しています。V字開発の進め方やテスト体制でお悩みの際は、お気軽にご相談ください。