※この記事は途中まで無料でお読みいただけます。続きはnote（有料）で公開しています。
はじめに
「Vモデルってウォーターフォール時代の話でしょ？」
こう話すエンジニアに、現場でたびたび出会います。アジャイルやスクラムが当たり前になった今、Vモデルは時代遅れだと思われがちです。しかし、これは大きな誤解です。
Vモデルは特定の開発手法の話ではありません。要件定義や設計で決めたことを、対応するテストで確認するという、品質保証の基本的な考え方です。この考え方を持てているかどうかが、システム開発の品質を大きく左右します。
この記事では、システム基盤開発を例にとりながら、Vモデルの本質をテスト工程の視点から解説します。教科書的な図の説明ではなく、現場でどう使うかに焦点を当てています。
Vモデルとは何か
Vモデルとは、開発工程とテスト工程を対応づけて考えるモデルです。
名前の由来は見た目の形にあります。左側に開発工程が並び、右側にテスト工程が並ぶ。その形がアルファベットの「V」に見えることから、Vモデルと呼ばれています。
ただし、大事なのは形ではありません。本質は次の一文に集約されます。
「ある工程で決めたことは、対応するテスト工程で確認する」
このイメージを図にすると、次のようになります。
ただし、工程の名称や対応関係はプロジェクトごとに異なります。ここで示すのはあくまで一例です。その前提で、システム基盤の開発に当てはめると次のような対応関係になります。
- 環境定義（実際の設定値・パラメータ）→ 単体テスト
- 詳細設計（製品ごとの設計内容）→ 結合テスト1（基盤に閉じた接続確認）
- 基本設計（処理方式・システム構成・採用製品）→ 結合テスト2（プロトタイプアプリを用いた確認）
- 要件定義・運用設計（可用性・性能・セキュリティ・運用要件など）
→ システムテスト・運用テスト・受入テスト
結合テストを2段階に分けているのは、確認の観点が異なるからであり、教科書的なVモデルをそのまま当てはめたものではなく、基盤開発の成果物粒度に合わせた整理です。
結合テスト1は基盤に閉じた機器間・システム間の接続確認です。結合テスト2はプロトタイプの業務アプリケーションを使い、基本設計で定めた処理方式や構成が実際に機能するかを確認します。基本設計の内容を検証するには、アプリが一部でも動く状態でないと確認できないため、この段階にアプリが入ってきます。
システムテストは「総合テスト」とも呼ばれ、基盤とアプリケーションが合流して行う最終的な全体検証です。プロジェクトによっては、運用テストや受入テストがシステムテストの一部として扱われることもあれば、システムテスト後の別工程として実施されることもあります。なお、運用テストは手順・承認フローの確認、受入テストはお客様がシステムを本番として受け入れるかの判断が目的であり、両者は異なります。
この対応関係が崩れると、品質の抜け漏れが発生します。「要件定義で決めたのにテストしていない」「テストしたが根拠となる設計が存在しない」。そういう状況を防ぐための考え方が、Vモデルです。
なぜ段階的なテストが必要なのか
テストを「最後に一度まとめてやればいい」と思っている人が、現場に一定数います。完成したシステムに対して動作確認をすれば十分、という考え方です。
しかし、これには重大なリスクがあります。
システムは複数の要素の集合で成り立っています。クライアント端末、ネットワーク、ネットワーク機器、サーバ、ストレージ。これらが組み合わさって、一つのシステムとして動作します。
この状態で一気にテストしようとすると、何が起きるでしょうか。
問題1：原因の特定に時間がかかる
想定どおりに動作しなかった場合、どこが悪いのかを特定するのが困難になります。ネットワークの設定ミスなのか、サーバのパラメータが間違っているのか、アプリケーションの処理が悪いのか。複数の要素が絡み合うため、原因の切り分けに膨大な時間がかかります。
本来であれば、単体テストで「このサーバの設定値は正しいか」を確認し、結合テストで「このサーバとあのサーバは正常に通信できるか」を確認する。問題が発生したときに、どの段階のどの要素が原因かを絞り込みやすい状態を作っておくことが重要です。
問題2：たまたま動いて終わってしまう
逆のパターンも怖いです。本来は網羅すべき条件を確認していないのに、たまたまテストが通ってしまうことがあります。
例えば、単体・結合テストでフェイルオーバーの検証をスキップし、システムテストでも正常系しか確認しなかったとします。システムが正常に動いているうちは問題が表面化しません。しかし本番で障害が発生したとき、初めて「フェイルオーバーが機能しない」と発覚する。これは最悪のシナリオです。
単体テスト、結合テスト、システムテストと段階を踏むことで、確認すべき項目を体系的に洗い出すことができます。
問題3：テスト項目が後から書けない
設計内容が曖昧なまま進むと、テスト工程で「何を確認すれば合格なのか」がわからなくなります。
「バックアップを取得すること」とだけ書かれていた場合、何をテストすればよいでしょうか。取得対象は何か。何時に取得するのか。何世代保持するのか。何時間以内に終わる必要があるのか。これが決まっていなければ、テスト項目に落とせません。
テスト項目は、テスト工程で突然生まれるものではありません。要件定義や設計で決めた内容から導き出されるものです。
そして、本来その工程で検出すべきバグが後続工程で発見されることを「すり抜け」と呼びます。
これは単なる発見タイミングのずれではありません。単体テストで見つかるべき設定ミスが結合テストやシステムテストで出てきた場合、「他にも同じ観点でのすり抜けがあるのではないか」という疑義が生じます。結果として、同じ観点の横並び確認が必要になり、場合によっては設計書、設定値、テスト項目の見直しが全体に波及します。
品質報告の場では、T型マトリックスという管理表が使われることがあります。
一般的には、縦軸に「実際に不具合を発見した工程」、横軸に「本来その不具合を摘出すべき工程」を置き、不具合がどの工程で検出され、どこですり抜けたかを可視化するものです。
対角線上に並ぶものは、本来の工程で適切に検出できた不具合です。一方、後続工程側にずれて計上されるものは、前工程で摘出できずに流出した不具合、つまりすり抜けを意味します。
たとえば、本来は単体テストで摘出すべき設定ミスが、結合テストやシステムテストで発見された場合、それは後工程へのすり抜けとして扱われます。このマトリックスを見れば、どの工程で検出力が弱いのか、どの工程で不具合が後ろ倒しになっているのかが一目でわかります。
「単体テストで検出すべき不具合が、なぜ結合テストやシステムテストまで残っていたのか」。その問いに答えられるかどうかが、テスト設計や品質分析の力を問われるポイントです。
テスト工程を段階的に設計し、各工程で検出すべき項目を明確にしておくことは、すり抜けリスクを下げるための最も基本的な手立てです。すり抜けの詳細なメカニズムと対策については、テスト編で改めて解説します。
バックアップ4時間以内という要件を例に考える
ここで、具体的な例を見てみましょう。お客様と次のような非機能要件を合意したとします。
DBおよびログのバックアップ時間は4時間以内とする
一見すると、シンプルな要件に見えます。しかし、この要件を実現し、テストで確認するためには、複数の工程にわたる設計が必要です。
要件定義の段階
この段階では「4時間以内」という目標を合意します。具体的な方式はまだ決まっていません。重要なのは、この数字が「何の性能要件か」を明確にしておくことです。性能・拡張性の要件であり、後工程のシステムテストで確認する項目です。
基本設計の段階
要件を実現するための方式を決めます。
- バックアップ対象は何か（DBのみか、ログも含むか）
- 取得先はどこか（サーバ内ディスクか、共有ストレージか、クラウドストレージか）
- 取得経路はどうするか（専用VLANを用意するか、本番ネットワークを使うか）
- 本番処理と同じ時間帯に実行しても問題ないか
これらを決めることで、システム構成と採用製品が固まります。
詳細設計の段階
採用する製品やミドルウェアを前提に、具体的な処理内容を決めます。
- バックアップジョブをどう構成するか
- どの順番で取得するか
- 圧縮・暗号化はするか
- エラー時の再実行ロジックはどうするか
- 失敗時の通知先はどこか
環境定義の段階
実際のパラメータを確定します。
- バックアップ対象のフォルダパス・ファイルパス
- 保存先のパス
- 実行スケジュール
- 保持世代数
- タイムアウト値
テストの段階
ここまで設計が積み上がって初めて、テスト項目が具体的に書けます。
- 本当に4時間以内に完了するか
- 対象ファイルに漏れはないか
- バックアップ失敗時にアラートが上がるか
- リストアできるか
- 本番相当のデータ量でも時間内に終わるか
Vモデルを理解していないと、「要件に4時間以内と書いてある」「バックアップジョブは作った」「テストで何となく動いた」で終わってしまいます。しかし現場では、それでは足りません。
ここまでは、Vモデルの基本的な考え方を整理しました。
以降では、現場でこの考え方をどう使うか、工程ごとの留意点、よくある失敗パターン、運用テストの位置づけまで踏み込んで整理します。
コメント