V字モデルとは？設計とテストの工程対応表とW字モデルとの違い

V字モデルとは、開発の工程をVの字に並べ、左側の各設計工程で決めたことを、同じ高さにある右側のテストで確かめる、という対応関係を表した図です。 要件定義で決めたことは受入テストとシステムテストで、基本設計は結合テストで、詳細設計は単体テストで確かめます。

この記事では、設計とテストの対応を1枚の表にまとめ、各行に入力となる設計書・確かめる観点・テスト成果物・担当・完了基準の例を並べます。Vの形にそのまま描画できる Mermaid と PlantUML のコード、不具合が工程をまたぐほど手戻りが増えることを示す計算例、W字モデルとの違いと選び方も載せています。個々のテスト技法や設計書の書き方ではなく、工程と工程の対応関係に絞って説明します。

確認環境：Ubuntu 24.04、Python 3.11.15（手戻りの計算）、@mermaid-js/mermaid-cli 11.14.0 と Chromium 141（Mermaid 図の描画）、PlantUML 1.2025.4 と OpenJDK 21（PlantUML 図の描画）。テストレベルの用語は JSTQB の Foundation Level シラバス Version 2023V4.0.J02 で確認しました。確認日は 2026-10-06 です。

この記事の結論

• V字モデルは「左で決めたことを、同じ高さの右で確かめる」対応図です。
• 対応は3段です。要件定義↔受入テスト・システムテスト、基本設計↔結合テスト、詳細設計↔単体テスト。
• 対応するテストまで不具合が残ると、またいだ工程の数だけ直す成果物とやり直すテストが増えます。この記事の計算例では、要件定義の不具合をシステムテストで見つけると、同じ工程で見つけた場合の12倍の手戻りになりました。
• W字モデルは、対応するテストの設計を、設計工程と同じ時期に始める形です。違いは「テスト設計をいつ始めるか」にあります。

V字モデルの工程対応 早見表

V字モデルの図（MermaidとPlantUMLのコード）

V字の図は、コードから描けます。どちらも今回描画して、Vの形になることを確認したコードです。

Mermaid（ブロック図）

block-beta
    columns 7
    RD["要件定義"] space:5 ST["システムテスト<br>受入テスト"]
    space BD["基本設計"] space:3 IT["結合テスト"] space
    space:2 DD["詳細設計"] space UT["単体テスト"] space:2
    space:3 CD["実装"] space:3
    RD --> BD
    BD --> DD
    DD --> CD
    CD --> UT
    UT --> IT
    IT --> ST
    RD -- "要件を確かめる" --- ST
    BD -- "基本設計を確かめる" --- IT
    DD -- "詳細設計を確かめる" --- UT

7列のマス目にブロックを置き、左上から底へ下り、右上へ上がる配置にしています。矢印は工程の順番、矢印の無い横線は「同じ高さどうしで確かめる」対応を表します。

PlantUML

@startuml
!pragma layout smetana
skinparam defaultTextAlignment center
skinparam rectangle {
  RoundCorner 8
}
rectangle "要件定義" as RD
rectangle "基本設計" as BD
rectangle "詳細設計" as DD
rectangle "実装（コーディング）" as CD
rectangle "単体テスト" as UT
rectangle "結合テスト" as IT
rectangle "システムテスト" as ST
rectangle "受入テスト" as UAT

RD -down-> BD
BD -down-> DD
DD -down-> CD
CD -up-> UT
UT -up-> IT
IT -up-> ST
ST -up-> UAT

RD .right. UAT : 要件を確かめる
RD .right. ST : 要件を確かめる
BD .right. IT : 基本設計を確かめる
DD .right. UT : 詳細設計を確かめる
@enduml

2行目の指定は、PlantUML に同梱されている配置エンジンを使うためのものです。今回はこの指定で、Graphviz を入れていない状態でも描画できました。こちらは受入テストとシステムテストを別の箱にしており、要件定義から2本の破線が出ます。

図の読み方

横の線が、V字モデルのいちばん大事な部分です。 テストで「正しい」かどうかを判断する根拠は、同じ高さの設計書にあります。

設計とテストの工程対応表（設計書・観点・成果物・担当・完了基準）

4つの対応それぞれに、入力となる設計書、確かめる観点、テスト成果物、主な担当、完了基準の例を並べました。 完了基準の数値は例です。

表計算ソフトに貼る場合は、次のタブ区切りをコピーしてください。

設計工程（左側）    対応するテスト（右側） 入力となる設計書    確かめる観点  テスト成果物  主な担当    完了基準の例
要件定義    受入テスト   要件定義書（業務要件、業務の流れ）   業務が最初から最後まで回るか。利用者が迷わず使えるか  受入テスト計画書、業務シナリオ、受入テスト結果報告書  利用部門（開発側は支援）    業務シナリオを全件実施。重大な不具合が0件。利用部門の責任者が承認
要件定義    システムテスト 要件定義書（機能要件、非機能要件）、システム構成図   全機能が要件どおりか。性能・セキュリティ・運用などの非機能を満たすか  システムテスト計画書、システムテスト仕様書、結果報告書、不具合一覧   テストチーム  要件一覧の全項目にテストが対応。非機能の目標値を達成。残った不具合に対応方針がある
基本設計    結合テスト   基本設計書（画面遷移図、インターフェース設計、データの流れ）  機能と機能、画面と処理、ほかのシステムとのやり取りがつながるか 結合テスト仕様書、結果報告書、不具合一覧    開発チーム（PLが取りまとめ） インターフェース一覧の全件を確認。画面遷移の全経路を確認。重大な不具合が0件
詳細設計    単体テスト   詳細設計書（処理の流れ、入力チェック、条件分岐）    部品1つが設計どおり動くか。条件分岐、境界値、エラー時の動き  単体テスト仕様書またはテストコード、実行結果  実装した開発者 設計書の条件を全件確認。自動テストがすべて通る。網羅率の目標（例：分岐80%）を達成

対応表の使い方

• テスト仕様書を書く前に、同じ行の「入力となる設計書」がそろっているかを確かめます。 設計書に書かれていないことは、テストの期待結果を決められません。
• 不具合を見つけたら、どの行の設計書と食い違っているかを先に決めます。 結合テストで見つかっても、食い違いの相手が要件定義書なら、直す起点は要件定義書です。
• 完了基準は、設計工程のうちに仮で置いておきます。 「インターフェース一覧の全件」のように設計書の一覧を数える形にしておくと、テストの量を早い時期に見積もれます。

設計書の項目とテストを結ぶ（対応づけの例）

対応を保つには、設計書の項目に番号を付け、テスト側からその番号を参照します。架空の備品予約システムでの例です。

R-03 のように、非機能の要件は単体テストや結合テストに対応する相手がなく、システムテストで初めて確かめることがあります。この空欄は対応表にして初めて見えるので、設計の段階で「どのテストで確かめるか」を1行ずつ埋めておくと、確かめ忘れを防げます。

呼び名の揺れ対照表（外部設計・内部設計、UT/IT/ST/UAT、JSTQB）

工程の呼び名は組織や資料によって違います。名前が違っても、Vのどの高さにあるかで読み替えられます。

JSTQB の Foundation Level シラバス（Version 2023V4.0.J02）には「テストレベル」の項があり、本文ではコンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストという用語が使われています。別名と略語の列は、一般に使われている呼び方を並べたものです。

読み替えで気を付けたい点は2つです。

• 「結合テスト」は範囲が広い言葉です。システムの中の部品どうしをつなぐテストと、ほかのシステムとつなぐテストの両方を指すことがあります。計画書では、どこまでを結合テストと呼ぶかを最初に書いておきます。
• 「内部設計」を基本設計の後半に含める分け方もあります。 その場合、内部設計に対応するテストは結合テストの一部になります。呼び名ではなく「その設計書の内容を、どのテストで確かめるか」で対応を決めます。

工程の呼び方をそろえるための共通の枠組みとして、IPA が「共通フレーム2013」を公開しています。構想から開発、運用、保守、廃棄までの作業項目と役割を包括的に定めたもので、発注側と開発側で言葉を合わせるときの土台に使えます。

不具合が工程をまたぐと手戻りが増える（Pythonで計算）

V字の対応が大事な理由は、不具合が見つかるのが遅いほど、直す成果物とやり直すテストが増えるためです。架空の工数で計算します。

前提は次のとおりです。

# 架空の工数（時間）。直す作業と、やり直すテストを足し合わせる
stages = ["要件定義", "基本設計", "詳細設計", "実装", "単体テスト", "結合テスト", "システムテスト", "受入テスト"]
fix = {"要件定義": 2, "基本設計": 3, "詳細設計": 3, "実装": 4}            # 成果物を直す時間
retest = {"単体テスト": 2, "結合テスト": 4, "システムテスト": 6, "受入テスト": 4}  # テストをやり直す時間

def rework(origin, found):
    """origin の工程で入った不具合を found の工程で見つけたときの手戻り時間"""
    i, j = stages.index(origin), stages.index(found)
    assert i <= 3 and i <= j
    hours = sum(fix[s] for s in stages[i:min(j, 3) + 1])        # 原因の成果物から、作成済みの下流まで直す
    hours += sum(retest[s] for s in stages[4:j + 1])            # 実施済みのテストをやり直す
    return hours

print("| 入った工程 ＼ 見つけた工程 | " + " | ".join(stages) + " |")
print("|---|" + "---:|" * len(stages))
for origin in stages[:4]:
    row = []
    for found in stages:
        row.append(str(rework(origin, found)) if stages.index(found) >= stages.index(origin) else "－")
    print(f"| {origin} | " + " | ".join(row) + " |")

base = rework("要件定義", "要件定義")
for found in ("基本設計", "実装", "結合テスト", "システムテスト", "受入テスト"):
    h = rework("要件定義", found)
    print(f"要件定義の不具合を{found}で発見: {h}時間（同じ工程で見つけた場合の{h / base:.1f}倍）")

# V字とW字の比較（不具合20件。件数も割合も架空）
defects = {"要件定義": 8, "基本設計": 6, "詳細設計": 6}
pair = {"要件定義": "システムテスト", "基本設計": "結合テスト", "詳細設計": "単体テスト"}
early_rate = 0.5       # W字：テスト設計と設計レビューで、同じ工程のうちに見つかる割合
review_hours = 8       # W字：各設計工程で追加するレビューの時間

v_total = sum(n * rework(o, pair[o]) for o, n in defects.items())
w_total = 0
print("| 入った工程 | 件数 | V字：対応するテストで発見 | W字：半数を同じ工程で発見 |")
print("|---|---:|---:|---:|")
for o, n in defects.items():
    early = int(n * early_rate)
    v = n * rework(o, pair[o])
    w = early * rework(o, o) + (n - early) * rework(o, pair[o]) + review_hours
    w_total += w
    print(f"| {o} | {n} | {v} | {w} |")
print(f"| 合計 | {sum(defects.values())} | {v_total} | {w_total} |")
print(f"差: {v_total - w_total}時間（{(v_total - w_total) / v_total:.0%}減）")
# W字が得になる境目：同じ工程で見つかる割合を変える（件数の端数は切り捨て）
for rate in (0.0, 0.2, 0.3, 0.5, 0.7):
    t = sum(int(n * rate) * rework(o, o) + (n - int(n * rate)) * rework(o, pair[o]) + review_hours for o, n in defects.items())
    print(f"  同じ工程で見つかる割合 {rate:.0%}: W字 {t}時間（V字 {v_total}時間との差 {v_total - t:+}）")

実行結果のうち、前半の表です（単位は時間）。

要件定義の不具合を基本設計で発見: 5時間（同じ工程で見つけた場合の2.5倍）
要件定義の不具合を実装で発見: 12時間（同じ工程で見つけた場合の6.0倍）
要件定義の不具合を結合テストで発見: 18時間（同じ工程で見つけた場合の9.0倍）
要件定義の不具合をシステムテストで発見: 24時間（同じ工程で見つけた場合の12.0倍）
要件定義の不具合を受入テストで発見: 28時間（同じ工程で見つけた場合の14.0倍）

どの行も、右へ行くほど（見つけるのが遅いほど）数字が大きくなります。 要件定義の不具合は、対応するシステムテストで見つけると24時間、受入テストまで残ると28時間です。同じ工程のレビューで見つければ2時間で済みます。

この計算は「直す範囲が1か所にとどまる」単純な前提です。倍率そのものは前提の置き方で変わるので、数字ではなく「またいだ工程の成果物とテストが足し算で増える」という構造を読み取ってください。JSTQB のシラバスも、テストの原則の1つに「早期テストで時間とコストを節約」を挙げ、プロセスの早い段階で欠陥を取り除くと、その後の作業成果物にその欠陥に起因する欠陥が生じない、と説明しています。

W字モデルとの違い

W字モデルは、V字の設計工程それぞれに、対応するテストの設計とレビューを並行して重ねた形です。 開発の流れとテストの流れが2本並ぶので、Vが2つ重なったWの字になります。

flowchart LR
    subgraph D["開発の流れ"]
        direction LR
        RD["要件定義"] --> BD["基本設計"] --> DD["詳細設計"] --> CD["実装"]
    end
    subgraph T["テストの流れ（並行して進める）"]
        direction LR
        T1["要件のレビューと<br>システムテスト・受入テストの設計"] --> T2["基本設計のレビューと<br>結合テストの設計"] --> T3["詳細設計のレビューと<br>単体テストの設計"] --> T4["テストの実行<br>単体→結合→システム→受入"]
    end
    RD -.-> T1
    BD -.-> T2
    DD -.-> T3
    CD -.-> T4

V字モデルでも、テスト仕様書の「正解」は同じ高さの設計書から取ります。違いは、その作業を設計と同じ時期に行うか、実装のあとに行うかです。テスト担当が設計の時期から加わると、テストを設計する過程で「この要件は確かめようがない」「この条件の結果が書かれていない」といった設計書の抜けが見つかります。

V字とW字の手戻りを比べる（計算例）

先ほどのスクリプトの後半は、不具合20件（要件定義8件、基本設計6件、詳細設計6件）を置いて、V字とW字の手戻りを比べています。W字では、各設計工程にレビューの時間を8時間ずつ足し、不具合の半数が同じ工程のうちに見つかる、と仮に置きました。

差: 121時間（35%減）
  同じ工程で見つかる割合 0%: W字 366時間（V字 342時間との差 -24）
  同じ工程で見つかる割合 20%: W字 325時間（V字 342時間との差 +17）
  同じ工程で見つかる割合 30%: W字 303時間（V字 342時間との差 +39）
  同じ工程で見つかる割合 50%: W字 221時間（V字 342時間との差 +121）
  同じ工程で見つかる割合 70%: W字 180時間（V字 342時間との差 +162）

この前提では、W字のほうが121時間（35%）少なくなりました。一方で、同じ工程で見つかる割合が0%なら、レビューに足した24時間のぶんW字のほうが多くなり、20%で逆転します。 W字は「早い時期のレビューで不具合が見つかる」ことで効果が出る形なので、テスト担当が設計書を読める時期と体制を確保できるかが分かれ目になります。件数・時間・割合はすべて架空の値です。

V字・W字・ウォーターフォール・テストの四象限の違い

名前が似ていたり、同じ場面で出てきたりする4つを比べます。表しているものが違うので、どれか1つを選ぶ関係ではありません。

• ウォーターフォールとV字モデルは、同じ工程を別の向きから見たものです。ウォーターフォールは時間の順に左から右へ並べ、V字モデルは実装で折り返して、対応する工程の高さをそろえます。
• テストの四象限は、工程の高さでテストを分けません。 JSTQB のシラバスにも「テストの四象限」の項があります。短い反復の中では単体・結合・システムの順に工程を区切りにくいので、テストの種類を2つの軸で分けて抜けを点検します。
• 反復開発でも、V字の考え方は使えます。1つの機能について「受け入れの条件↔受け入れのテスト」「設計↔つなげたテスト」「コード↔単体テスト」の対応を、反復の中で小さく回します。

V字とW字のどちらを採るか：判断基準

軸は「テスト設計をいつ始めるか」です。

全部をW字にする必要はありません。 上段（要件定義↔システムテスト・受入テスト）だけテスト設計を前に寄せる形でも、計算例でいちばん差が大きかった部分を押さえられます。

W字で設計工程に足す作業

確かめて分かったこと

• Mermaid のフローチャートで左右2つのグループに分けて描くと、Vの形にならず上下に積まれました。 7列のマス目に置くブロック図に変えると、左上から底、右上へ上がるVの形で描画できました。
• PlantUML は、同梱の配置エンジンを指定する1行を入れると、Graphviz を入れていない状態でも箱と矢印の図を描けました。 下向き・上向き・右向きの矢印の指定だけで、手で座標を決めなくてもVの形になります。
• 手戻りの表は、どの行でも右へ単調に増えました。 増え方がいちばん大きいのは結合テストからシステムテストへ移るところ（6時間増）で、やり直すテストの時間が大きい工程ほど、その手前で見つける価値が高くなります。
• W字は必ず得になるわけではなく、この前提では早期に見つかる割合を20%にしたところで逆転しました。 レビューに使う時間と見つかる割合の両方を見て決める必要があります。
• 対応づけの表を作ると、非機能の要件に単体テスト・結合テストの相手が無いことが空欄として見えました。 対応表は、テストの根拠を示すだけでなく、確かめる場所が1つしかない要件を見つける道具にもなります。
• JSTQB のシラバスでは、日本でよく使う「単体テスト」「結合テスト」ではなく「コンポーネントテスト」「コンポーネント統合テスト」という用語が使われていました。資格の学習と日々の呼び名を行き来するときは、対照表が役に立ちます。

つまずきやすい点と整え方

よくある質問

Q. V字モデルとは何ですか？ A. 開発の工程をVの字に並べ、左側の設計工程と右側のテスト工程の対応関係を表した図です。要件定義は受入テスト・システムテストと、基本設計は結合テストと、詳細設計は単体テストと対応します。

Q. V字モデルとW字モデルの違いは何ですか？ A. テスト設計を始める時期の違いです。V字モデルは設計とテストの対応関係を示し、W字モデルはそれに加えて、対応するテストの設計とレビューを設計工程と同じ時期に並行して行います。

Q. V字モデルとウォーターフォールの違いは何ですか？ A. ウォーターフォールは工程を順番に進める進め方で、V字モデルはその工程どうしの対応関係を表す図です。同じ工程を、時間の順に並べるか、実装で折り返して高さをそろえるかの違いです。

Q. 基本設計に対応するテストは何ですか？ A. 結合テストです。基本設計書の画面遷移、インターフェース、データの流れを根拠に、機能どうしがつながることを確かめます。

Q. V字モデルはアジャイル開発では使えないのですか？ A. 対応関係の考え方はそのまま使えます。反復開発では工程を長く区切らないため、1つの機能について条件・設計・コードとそれぞれのテストの対応を、反復の中で小さく回します。

まとめ

• V字モデルは、左側の設計工程で決めたことを、同じ高さの右側のテストで確かめる対応図です。
• 対応は要件定義↔受入テスト・システムテスト、基本設計↔結合テスト、詳細設計↔単体テストの3段です。
• 対応表には入力となる設計書・確かめる観点・テスト成果物・担当・完了基準を並べ、設計工程のうちに仮で埋めておきます。
• 呼び名は組織で違います。外部設計・内部設計、UT・IT・ST・UAT、JSTQB の用語は、Vの高さで読み替えます。
• 不具合は、またいだ工程の数だけ直す成果物とやり直すテストが増えます。
• W字モデルは、テスト設計を設計工程と同じ時期に始める形です。上段だけ前に寄せる使い方もできます。
• V字の図は、Mermaid のブロック図と PlantUML のコードでそのまま描けます。

参考

• JSTQB「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02」（テストレベルの用語、テストの原則、目次の「テストの四象限」を確認）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf
• IPA「SEC BOOKS：共通フレーム2013」https://www.ipa.go.jp/publish/secbooks20130304.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。