V字モデルの図の左右が「対応している」という意味だと知らずに眺めていた期間が、私には数年ありました。ただの矢印の折り返しだと思っていたんです。
図を見たことがない方でも読めるように、形から順に説明します。
対応関係だと分かった瞬間に、テスト計画の書き方が変わりました。
Vの左側は分解、右側は組み立て
まず形の説明をします。左上から下へ降りて、底で折り返し、右上へ登る。これがVです。
左側は要件定義から始まって、基本設計、詳細設計と降りていきます。扱う単位がどんどん小さくなる方向です。システム全体の話から、画面や機能の話になり、最後はプログラムを組み立てている細かい部品(関数やモジュールと呼びます)の話になる。分解していく動きです。
底が実装です。ここで実際にコードを書きます。
右側は逆で、単体テストから始まって、結合テスト、システムテスト、運用テストと登ります。扱う単位がどんどん大きくなる。部品ひとつの確認から、部品同士のつなぎ目、システム全体、そして業務として使えるかへ広がっていきます。
だからVの形になる。降りて、登る。
同じ高さのものが対応している
ここが要点です。V字モデルが言っているのは、左側のある段階と、同じ高さにある右側の段階が対応しているということです。先に一覧で出します。
要件定義 ── システムテスト / 運用テスト
基本設計 ── 結合テスト
詳細設計 ── 単体テスト
実装(底)
上の行が浅く、下の行が深い。この左右が組になっています。なお底に実装を置かず、実装と単体テストを対応させて4段で描く流派もあります。段数が違っても、左右が向き合っているという話は同じです。
詳細設計と単体テストが同じ高さにあります。詳細設計で「この部品に何を渡すと何が出てくるか」を決めたなら、単体テストはそれを確認します。
基本設計と結合テストが同じ高さです。基本設計で決めた画面と機能のつながりが、実際につながっているかを結合テストで見る。
要件定義とシステムテスト、そして運用テストが上のほうで向き合っています。要件定義で「こういう業務を回せるようにする」と決めたなら、それが回るかどうかを最後に確認する。
つまり右側のテストは、対応する左側の成果物から作れるという主張です。テストを思いつきで書くのではなく、左側に書いてあることを確認する形で書く。
対応が崩れると、テストが「動くか」の確認になる
私が失敗した話をします。
ある案件で、要件定義の文書に「月末に締め処理を行う」という一行しかない状態で進みました。基本設計にも詳細設計にも、締め処理の中身は書かれていない。実装した人の頭の中にだけありました。
システムテストの段階で、テスト項目を書く人が困りました。何が正しいのか、どこにも書いていない。結果として出てきたテスト項目が「締め処理を実行してエラーが出ないこと」でした。
これは動くことの確認であって、正しいことの確認ではありません。 エラーが出なければ通ってしまう。実際、締め対象の月の判定が1日ずれていたのですが、エラーは出ないのでテストは通りました。運用開始後に気づきました。
左側が薄いと、右側は「動くか」しか見られなくなる。V字モデルの図がいちばん言いたいのは、たぶんここだと思っています。
テストを先に書くとW字になる
V字モデルの派生としてW字モデルという言い方もあります。左側の各段階で、設計と同時にその段階のテストの設計もやってしまう考え方です。基本設計を書いたらその場で結合テストの項目も書く。Vが2つ重なってWに見えるのでその名前になっています。
私はこれを部分的に取り入れています。全工程では回していませんが、要件定義を書くときに「これはどうやって確認するのか」を1行添えるようにしました。書けないなら要件があいまいだという判定に使えます。
「使いやすくする」は確認方法が書けません。「登録を3画面から1画面にする」なら書けます。確認方法を書けるかどうかが、要件の具体性のものさしになるというのが、W字から借りた一番実用的な部分でした。
アジャイルとは排他ではない
V字モデルはウォーターフォールの説明図として出てくることが多く、反復型の開発とは相性が悪いと思われがちです。
ただV字が言っているのは順番ではなく対応関係なので、1回の反復の中にも成り立ちます。2週間のスプリント(反復の1区切りのこと。決めて作って見せるまでを1周として繰り返す期間です)の中で、決めたことと確認することが向き合っているか。向き合っていなければ、規模が小さいだけで同じ問題が起きます。
反復型の進め方そのものは別記事で扱いました。
工程の呼び方については、こちらにまとめています。
実装が速くなると左側が重くなる
最後に、いま起きている変化を書きます。
底の実装をAIに任せられるようになりました。私はClaude Codeで実装させることが多いのですが、Vの底が浅くなった感覚があります。降りて、すぐ登る。
そうすると左側の質がそのまま結果に出ます。どんな部品をどう作るかまで書いた指示、つまり詳細設計に相当する指示があいまいなら、あいまいなまま速く実装されるだけです。しかも速いので、間違ったものが大量に出てくる。
私はここで一度失敗しています。指示を短く書いて実装させ、出てきたものをレビューしようとしたら、確認の基準が自分の中にありませんでした。何と比べて正しいと言うのか。左側を書いていなかったので、右側で判断できなかった。V字が崩れた状態を自分で作っていました。
いまは実装を頼む前に、確認方法を先に書くようにしています。レビュー自体はツールに任せられます。
古いモデルだと思って読み飛ばしていたのですが、実装が速くなったことで、むしろ効くようになった図だと感じています。
