V字モデルとは 開発とテスト工程の対応・メリットと限界・W字モデルとの違い

「テスト工程に入ったら不具合が大量に出た」「見つかった不具合が、どの設計の誤りに起因するのか分からない」。システム開発でテストがうまく進まないとき、原因は工程の組み立て方にあることが少なくありません。

V字モデルは、開発工程とテスト工程をそれぞれ対にして配置した開発の進め方です。実装を底として工程の流れを折り曲げると、左側に設計、右側にテストが並ぶV字の形になります。

この対応関係があることで、何をもってその工程が正しかったと判断するかが、設計の時点で決まります。テストの抜けが減り、不具合の起因工程も特定しやすくなります。

この記事では、工程の対応関係を整理したうえで、メリットと限界、向くプロジェクトの判断、W字モデルとの違い、そしてアジャイル開発での活用までを順に扱います。

確認したいポイント	結論	詳細
V字モデルとは？	開発とテストを対にしたモデル	各設計工程に対応するテスト工程を配置し、V字の形で表した開発の進め方です。
何が良いのか？	テストの抜けと原因特定が改善	設計書を根拠にテストを作れるため網羅性が上がり、不具合の起因工程も分かります。
限界はどこか？	テストが後半に集中する	上流の誤りが後工程で見つかると手戻りが大きくなります。仕様変更にも弱いです。
W字モデルとは？	テスト設計を設計と並行する型	V字の左側でテスト設計まで行い、上流での欠陥検出を早めた発展形です。

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

目次

この記事でわかること

• V字モデルの構造と、なぜV字の形で表現されるのか
• 要件定義から実装までの各工程と、対応するテスト工程の関係
• テストの抜けが減るという利点と、後半に集中するという限界
• V字モデルが向くプロジェクトと向かないプロジェクトの判断基準
• W字モデルとの違いと、アジャイル開発でV字を活かす考え方

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や試験の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら※オンライン完結／しつこい営業は一切いたしません

V字モデルとは

V字モデルは、システム開発の工程を、開発側とテスト側で対応づけて表したモデルです。左側に要件定義から実装までの工程、右側に単体テストから受入テストまでの工程を配置します。

重要なのは、単に工程を並べているのではなく、対になっているという点です。要件定義には受入テスト、基本設計にはシステムテストが対応します。それぞれのテストが、対応する設計工程の成果を検証します。

なぜV字の形になるのか

一般的なシステム開発の工程は、要件定義、基本設計、詳細設計、実装、単体テスト、結合テスト、システムテスト、受入テストという順に進みます。

この一直線の流れを、実装の工程を中心にして折り曲げると、左右が向かい合う形になります。これがV字と呼ばれる理由です。

折り曲げたときに向かい合う工程どうしが、対応関係にあります。上流の設計は上流のテストと、下流の設計は下流のテストと対になるという構造です。

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

V字モデルは、ウォーターフォールモデルに対応関係の考え方を加えたものと位置づけられます。工程を順に進め、原則として後戻りしないという性質は共通です。

ウォーターフォールでは、設計工程とテスト工程が独立して並んでいます。そのため、テストで見つかった不具合がどの設計段階に起因するのか分かりにくいという課題がありました。

V字モデルはこの点を改善しています。対応関係が明示されているため、不具合が出たときに、どの工程の成果物を見直すべきかが判断できます。

国内での位置づけ

IPA（情報処理推進機構）が公開するソフトウェア開発分析データ集では、累計5,546プロジェクトの定量データが分析されています。

この資料の2022年版によると、開発ライフサイクルはウォーターフォール型が97.2%を占め、反復型とその他の合計は約2.8%という結果になっています。

受託開発を中心とした国内の案件では、V字モデルが依然として主流であることを示す数値です。金融や公共分野など、品質の証跡が求められる領域では特にそうなります。

工程の対応関係

どの工程がどのテストと対応するのかを、具体的に整理します。ここが理解の中心になります。

全体の対応を確認する

まず全体像です。左側の設計工程と、右側のテスト工程が向かい合います。

要件定義　─────────────────　受入テスト

　└ 基本設計　──────────　システムテスト

　　　└ 詳細設計　────　結合テスト

　　　　　└ 実装　─　単体テスト

上に位置する工程ほど、確認する範囲が広くなります。実装と単体テストは個々の部品、要件定義と受入テストはシステム全体という関係です。

要件定義と受入テスト

要件定義は、システムに求めることを明確にする工程です。発注側の業務目線で、何を実現すべきかを定めます。

これに対応する受入テストでは、その要件が満たされているかを発注側が検証します。仕様どおりに動くかではなく、業務で使えるかという観点で確認します。

要件定義書がテストの根拠になります。要件が曖昧なままだと、受入テストの合否基準も定まりません。要件の書き方については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

基本設計とシステムテスト

基本設計（外部設計）は、利用者から見える部分を設計する工程です。画面、帳票、外部システムとの連携方式を決めます。

対応するシステムテストでは、システム全体が設計どおりに動作するかを検証します。業務の流れを通した動作、性能、セキュリティといった観点が含まれます。

受入テストとの違いは主体です。システムテストは開発側、受入テストは発注側が実施します。同じ範囲を見ても、観点が異なります。

詳細設計と結合テスト

詳細設計（内部設計）は、プログラムの内部構造を設計する工程です。モジュールの分割、処理のロジック、データの受け渡し方を決めます。

対応する結合テストでは、複数のモジュールを組み合わせた動作を検証します。部品どうしのデータの受け渡しが正しく行われるかを確認します。

結合テストは2段階に分けられることがあります。同一システム内を内部結合テスト、他システムとの連携を外部結合テストと呼び分ける運用です。

工程の呼び方は組織で異なる

注意しておきたい点です。同じ工程が、組織によって別の名前で呼ばれています。

基本設計を外部設計、詳細設計を内部設計と呼ぶ組織があります。単体テストをコンポーネントテスト、受入テストをユーザー受入テストやUATと呼ぶこともあります。結合テストを内部結合と外部結合の2段階に分ける場合もあります。

呼び方の正解を探すより、プロジェクト内で定義を揃えるほうが実務的です。工程名、その工程で行うこと、成果物、完了条件を一覧にして関係者で合意します。

複数社が関わる案件では特に重要です。「結合テストは誰がどこまでやるのか」という認識のずれが、そのまま検証の抜けにつながります。

実装と単体テスト

実装は、詳細設計にもとづいてプログラムを作る工程です。V字の底にあたります。

対応する単体テストでは、個々のモジュールや関数が正しく動くかを検証します。コンポーネントテストとも呼ばれます。

実施するのは開発者自身であることが一般的です。自分が書いたコードを、書いた直後に確認するという形になります。

V字モデルのメリット

対応関係があることで得られる効果を整理します。

テストの抜けが減る

最大の利点です。設計書を根拠にテストケースを作れるため、確認すべき項目を機械的に洗い出せます。

対応関係がないと、テストの内容は担当者の経験に依存します。何を確認すべきかを毎回考えることになり、経験の差が網羅性の差として現れます。

設計書に書かれている項目を1つずつテストに落とすという進め方ができれば、抜けは構造的に減ります。逆に言えば、設計書の記述が不十分なら、この利点は得られません。

不具合の原因を特定しやすい

どのテストで落ちたかが、どの工程に問題があるかを示します。これが対応関係のもう1つの効果です。

単体テストで落ちれば実装の誤り、結合テストで落ちれば詳細設計の誤り、システムテストで落ちれば基本設計の誤りという切り分けができます。

この情報は次のプロジェクトの改善にもつながります。「システムテストでの不具合が多い」という傾向が見えれば、基本設計のレビューを強化するという手が打てます。

役割分担と進捗把握がしやすい

対応する開発段階に沿った内容にテストを絞り込めるため、分担が明確になります。各工程の責任者もはっきりします。

単体テストは開発者、結合テストは開発チーム、システムテストは品質保証の担当、受入テストは発注側。こうした役割の割り当てが自然に決まります。

プロジェクトの進行段階も把握しやすくなります。「いま結合テストの段階」と言えば、関係者がどこまで進んでいるかを共通に理解できます。

テストの計画を早く立てられる

見落とされやすい利点です。設計工程の時点で、対応するテストの計画に着手できます。

要件定義が終われば受入テストの計画を、基本設計が終わればシステムテストの計画を作り始められます。実装の完了を待つ必要がありません。

この前倒しができると、テスト期間の圧縮を防げます。開発の遅れがテスト期間にしわ寄せされるという事態を、計画の面から緩和できます。

工程設計やテスト計画からご相談いただけます 考え方は分かっても、自社の案件にどう当てはめるかは別の問題です。工程の設計からご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

デメリットと限界

構造そのものに由来する弱点があります。理解しておかないと、対策を打てません。

テストが後半に集中する

最も本質的な限界です。実際にテストを実行できるのは、実装が終わってからです。V字の右側はすべて後半に位置します。

その結果、プロジェクトの後半に不具合が集中して発見されます。すでに残り期間が少ない段階で大量の修正が必要になるという展開です。

開発が遅れると、テスト期間が削られます。リリース日を動かせない場合、しわ寄せは必ずテストに来ます。この構造が、品質低下の最大の要因になります。

上流の欠陥が後で見つかると手戻りが大きい

要件定義の誤りは、受入テストまで発見されません。その時点で修正すると、設計、実装、テストのすべてをやり直すことになります。

一般に、欠陥の修正コストは後工程で発見されるほど大きくなるとされています。要件段階なら文書の修正で済むものが、受入テスト段階では全工程の手戻りになります。

対策は上流のレビューを厚くすることです。設計書のレビューに時間をかけるほど、後工程での手戻りは減ります。次章で扱うW字モデルは、この考え方をさらに進めたものです。

仕様変更に弱い

原則として後戻りしない構造であるため、開発中の変更を吸収しにくいという性質があります。

要件が変わると、対応する設計とテストの両方を修正する必要があります。対応関係が明示されている分だけ、修正すべき箇所も多くなります。

変更が前提の案件には向きません。市場の反応を見ながら作る、要件が固まっていないという条件では、別の進め方を検討します。

形式だけが残りやすい

運用面での問題です。工程の名前と成果物の形式は守られているが、対応関係が実質的に機能していないという状態が起こります。

システムテストと称して、実際には単体テストの延長のような確認しかしていない。受入テストと称して、画面を数枚開いただけで承認している。こうした状況は実際に見られます。

原因は、各テストで何を確認するのかが定義されていないことです。工程の名前だけを借りても、観点が定まっていなければ検証にはなりません。

対策は、各テスト工程の目的と観点を計画書に明記することです。「このテストでは何を保証するのか」を一文で書けるかが、機能しているかどうかの目安になります。

設計書の品質に依存する

設計書がテストの根拠になるという構造は、裏返せば設計書が不十分ならテストも不十分になるということです。

設計書に例外処理が書かれていなければ、テストにも含まれません。非機能要件が記載されていなければ、性能の検証も漏れます。

「設計書に書かれていないことは、テストされない」という前提を関係者で共有しておく必要があります。文書化の水準が、そのまま品質の上限になります。

向くプロジェクトと向かないプロジェクト

判断は要件の性質で決まります。

向くケース

次の条件に当てはまるなら、V字モデルが適しています。

• 要件が最初から明確で、開発中の変更がほとんど発生しない
• 品質と安全性の確保が最優先される
• 設計とテストの対応を文書で示す必要がある（監査や第三者認証）
• 複数社が関わり、工程の区切りを契約に落とし込む必要がある

具体例としては、既存システムのリプレース、法制度にもとづくシステム構築、金融や医療、公共インフラの領域が挙げられます。

これらの分野では、要件が外部の規則で定まっていることが多く、変更も頻繁には起きません。対応関係を文書で示せることが、そのまま要件になる場合もあります。

向かないケース

反対に、次の条件では機能しません。無理に適用すると、形だけの工程管理になります。

開発途中での仕様変更や要件の追加が頻発する、何を作るべきかを探りながら進める必要がある、市場の反応を見て方向を変えたい。こうした案件では、後戻りしない前提が成立しません。

短期間で試作を出したい場合も向きません。全工程を通さないとリリースできない構造のため、最初の成果物が出るまでに時間がかかります。

判断の基準

機能の一覧を書き出せるかどうかが実務的な判断軸になります。

現時点で8割以上の機能を書き出せるなら、V字モデルで進められます。半分も書けないなら、反復型を検討する段階です。

上流はV字、実装以降は反復という折衷案も実務では取られます。全体の枠と予算を確定しつつ、細部の調整には柔軟に対応できる構成です。委託時の進め方はシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方でも整理しています。

W字モデルとの違い

V字モデルの限界を補うために考えられた発展形です。

W字モデルとは

V字の左側で、設計と並行してテストの設計も行うという進め方です。2つのV字が重なった形になるため、Wと呼ばれます。

従来のV字モデルでは、テストの設計は右側の工程で行われます。W字モデルでは、要件定義の段階で受入テストの設計を、基本設計の段階でシステムテストの設計を並行して進めます。

テストの実行は右側のままです。変わるのは、テストケースを作る時期です。実装を待たずに、対応する設計が終わった時点で着手します。

何が変わるのか

効果は2つあります。上流での欠陥の発見と、テスト期間の確保です。

テストケースを作る作業は、設計書を精読する作業です。その過程で、設計の曖昧さや矛盾が見つかります。「この条件のときにどう動くのか書かれていない」という指摘が、設計段階で出てきます。

これがW字モデルの本質的な価値です。欠陥を、それが作られた工程で見つけるという発想です。後工程で発見するより、はるかに安く直せます。

加えて、テストの準備が前倒しになるため、実装完了後すぐにテストを開始できます。テスト期間が圧縮される問題も緩和されます。

導入のハードル

必要な体制が重くなるという難点があります。設計とテスト設計を並行させるには、それぞれの担当者が同時に動く必要があります。

小規模なチームでは、同じ人が設計とテスト設計を兼ねることになります。その場合、設計者自身がテストを設計するという状況が生まれ、第三者の目による検証という効果は薄れます。

全工程で導入する必要はありません。影響の大きい機能、複雑な業務ロジックの部分だけでW字を適用するという部分的な取り入れ方が現実的です。

アジャイル開発での活用

V字モデルはウォーターフォール専用ではありません。この点は誤解されやすい部分です。

スプリント内でV字が回る

スクラムなどの反復型開発では、スプリントと呼ばれる短い期間の中で、要件の整理から設計、実装、テストまでを一巡させます。

つまり、1つのスプリントの中でV字モデルに沿った作業が行われているとも言えます。工程の区切り方が違うだけで、対応しなければならない作業項目そのものは変わりません。

違いは進め方です。ウォーターフォールでは工程ごとにまとめて作業しますが、反復型ではスプリントを繰り返して完成に近づけます。やるべきことの種類は同じです。

対応関係の考え方は普遍的

「何を根拠に何を検証するか」という考え方は、開発モデルに依存しません。ここがV字モデルの本質です。

反復型でも、受け入れ条件（アクセプタンスクライテリア）を定めてから実装し、それを満たすかを確認するという流れを取ります。これは要件定義と受入テストの対応関係そのものです。

V字モデルを工程の名前として覚えるのではなく、対応関係の考え方として理解すると、どの進め方でも応用できます。

シフトレフトという考え方

近年よく語られるのが、テストや品質の活動を、より前の工程へ移すという発想です。シフトレフトと呼ばれます。

W字モデルも、自動テストをCI/CDに組み込む取り組みも、この方向にあります。共通するのは、欠陥を早く見つけるほど安いという前提です。

V字モデルの限界を理解していると、この発想の意味が分かります。テストが後半に集中するという構造的な問題を、どう緩和するかという話だからです。

実務で活かすポイント

対応関係を機能させるために必要なことを整理します。

たどれる状態を確保する

どの要件が、どのテストで検証されたかをたどれる状態を作ります。トレーサビリティと呼ばれます。

方法は単純で、要件に番号を振り、テストケースにその番号を記載します。要件一覧とテストケース一覧を突き合わせれば、検証されていない要件が見つかります。

IPAが公開する共通フレーム2013は、システムのライフサイクルを通じて必要な作業項目と役割を包括的に規定した枠組みです。工程と成果物の対応を整理する際の共通の拠り所になります。

完了基準を工程ごとに決める

各工程を終えてよい条件を、事前に決めます。これがないと、曖昧なまま次工程に進みます。

設計工程であれば、成果物のレビューが完了し指摘が解消されていること。テスト工程であれば、計画したケースの消化率と、残存不具合の水準です。

特に重要なのがテスト工程の開始基準です。前工程の品質が低いまま次のテストに入ると、そのテストが前工程の代わりになってしまいます。

受入テストの準備を早く始める

発注側にとって最も実務的な要点です。受入テストの準備は、要件定義が終わった時点で着手できます。

テストシナリオの作成、参加者の確保、テストデータの準備。これらを実装完了後に始めると、必ず間に合いません。

受入テストは発注側の稼働が必要な工程です。通常業務と並行することを前提に、早い段階から担当者の時間を確保しておきます。

まとめ

V字モデルは、開発工程とテスト工程を対にして配置したモデルです。要件定義は受入テスト、基本設計はシステムテスト、詳細設計は結合テスト、実装は単体テストと対応します。

利点は、設計書を根拠にテストを作れるため抜けが減ること、そして不具合の起因工程を特定しやすいことです。役割分担と進捗の把握もしやすくなります。

限界は構造そのものにあります。テストが後半に集中するため、上流の欠陥が後で見つかると手戻りが大きくなります。仕様変更にも弱く、設計書の品質に依存します。

この限界を補うのがW字モデルです。設計と並行してテスト設計を行うことで、欠陥を作られた工程で見つけられます。全工程でなく、重要な部分だけに適用する方法も有効です。

まずは自社の案件について、要件一覧とテストケース一覧を突き合わせてみてください。検証されていない要件が見つかれば、それがV字モデルの対応関係が機能していないという証拠になります。

開発とテストの進め方から、無料で相談できます 受け取った計画の妥当性を判断したい、社内に開発の知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら※オンライン完結／秘密厳守／助成金活用のご相談も歓迎