News / blogお知らせ / ブログ

Vモデルとは何か

Vモデルとは、ソフトウェア開発の進め方（開発手法）のひとつです。

名前の通り、工程の流れが
アルファベットの「V」の形になっています。

左側が「設計」、
底が「コーディング」、
右側が「テスト」。

ざっくり言うと、

「設計したものが、ちゃんと作れているかを確認しながら進める」

という考え方です。

お客様が求めるものをちゃんと作れているか、
最終的に確認するための構造として、
現場でよく採用されています。

左側：設計フェーズ

要件定義

まず最初のフェーズが要件定義です。

ここでやることは、
「お客様が何を作りたいのかを明確にすること」です。

• 予算はどれくらいか
• いつまでに作りたいか
• どういう背景があって、何を作りたいのか

これを深掘りして、仕様を固めていきます。

たとえば、お客様が「Aというものを作りたい」と言ったのに、
出来上がったのが「B」だったとしたら。

当然、お客様は満足しません。

それを防ぐために、
大枠をしっかり決めていくのが要件定義の役割です。

基本設計

要件定義が固まったら、次は基本設計です。

ここでは、
どんなモジュールで構成するのかなど、
システム全体の大枠を作っていきます。

コーディングに入る前の設計図を描くイメージです。

詳細設計

基本設計の大枠をさらに細かく落とし込むのが詳細設計です。

• 画面のレイアウトをどうするか
• フロントエンドからバックエンドへのAPIをどう設計するか

要件定義で決めた「作りたいもの」を、
実際に開発できる形まで具体化していく工程です。

底：コーディング

詳細設計が完成したら、
いよいよコーディングに入ります。

ここがVの一番下の部分。

設計書をもとに、実際にシステムを作っていきます。

右側：テストフェーズ

コーディングが終わったら、今度は右側に上がっていきます。

単体テスト

まず最初が単体テストです。

詳細設計で決めた仕様通りに、
コーディングしたものが動くかを確認します。

APIが設計通りに動いているか。
実装したそれぞれの機能が、ちゃんと動作しているか。

「個々のパーツが正しく動いているか」
を細かく確認していくフェーズです。

結合テスト

単体テストで確認したパーツを、
今度は組み合わせて動かすのが結合テストです。

ここで重要なのは、

「単体では動いていたものが、
つなげた時にも正しく動くか」

という観点です。

引数の受け渡しがうまくいっていなかったり、
連携部分で不具合が起きていないかを確認します。

受け入れテスト

単体・結合テストが開発チーム内でのテストとすると、
最後の受け入れテストはお客様が行うテストです。

要件定義で決めた仕様書通りに、
システムが動いているか。

お客様の要望がしっかり叶えられているかを、
最終的に確認するフェーズです。

テストでNGが出たら？

当然、テストをしていると不具合が出ることがあります。

NGが出たら、まずテストを一旦止めます。

そして、
どういった不具合が発生しているのかを解析して、
コーディングに戻って修正する。

単体テストで不具合が出れば詳細設計を見直し、
結合テストで問題が出ればつなぎ目を確認する。

Vモデルの構造上、
左側（設計）と右側（テスト）が対応しているので、
不具合が出た時にどこに戻ればいいかが明確なんです。

これがVモデルの強みのひとつでもあります。

ちなみに、テストのドキュメントは現場によって様々ですが、
Excelで管理されているケースが多いです。

大項目・中項目・小項目と整理されていて、
テスト項目ごとに結果を記録していく形式が一般的です。

最後に

Vモデルは、
「作ったものがちゃんと使えるものになっているか」を
構造的に確認するための開発手法です。

現場に入ると当たり前のように使われていますが、
流れを理解しておくだけで、

• 今自分が何のために何をしているのか
• 不具合が出た時にどこに戻るべきか

がぐっと整理されます。

「現場でもっと活躍できるようになりたい」
「開発の上流工程にも挑戦してみたい」

そんな想いがある方は、
ぜひ一度お話ししましょう。

現役エンジニア兼社長の僕が、
直接お話を伺います。