- 更新日 2024.09.30
- カテゴリー システム開発
システム開発のV字モデルとは?仕組みやメリット、W字モデルとの違いを解説【2024年最新版】
システム開発の現場でよく使われる言葉「V字モデル」。プロジェクトに参画した経験のある企業・店舗担当者でも、意外と理解している方は多くないかもしれません。
「V字モデル」は、プロジェクトの成果物であるプログラムの品質を担保し、システム開発を成功に導く重要なマネジメント手法の1つ。担当者としてシステム開発プロジェクトを成功させるためにも、V字モデルとはなにかを理解しておくことが重要です。
そこで本記事では、V字モデルを採用することで得られる品質面のメリットを含め、システム開発担当者が知っておきたいV字モデルの基本を徹底解説!開発モデルごとに異なる、担当者の携わり方も紹介しますので、ぜひ参考にしてください。
※システム開発の依頼先を探している方はシステム幹事にご相談ください。予算や目的から最適な開発会社を選定させていただきます。相談料などは一切かかりません。
システム開発で採用されるV字モデルとはなにか
開発の工程とテストの相関をVの字で表したもの
V字モデルとは、システム開発における開発の工程と、そのテストの対応関係をVの字で表したものです。V字の左側に開発工程を上から順番に並べ、V字の右側に、開発工程に対応したテストを下から上に並べます。システム開発では様々なテストが行われますが、V字で表すことで、どの作業に対してどのテストが行われるか分かりやすくなります。
例えばウォーターフォール型と呼ばれる開発は下図のように、システム開発を順番通りに進めていく手法です。
ですが、この流れだけを見ると基本設計に対応するテストはどれに当たるのかが分かりません。そこでV字モデルを用いることで、どの作業に対してどのテストをするのかが分かりやすくなり、品質や進捗が管理しやすくなります。
- 要件定義の内容を総合テストで確認
- 基本設計の内容を結合テストで確認
- 詳細設計の内容を単体テストで確認
各工程でどんな作業やテストをするかの詳細は後ほど詳しく説明します。ここではウォーターフォールの開発をより分かりやすく表したものがV字モデルと考えてください。
ウォーターフォール型の開発の詳細は下記記事をご参照ください。
関連記事:ウォーターフォール開発とは?開発工程・メリット・向いているプロジェクトも解説
システム開発の品質管理についてより詳しく知りたい方は、以下の記事も参考にしてください。
関連記事:システム開発における品質管理とは?プロジェクトの成否を左右する重要性を解説
システム開発でV字モデルを採用するメリット
システム開発でV字モデルを採用するメリットは、主に以下の5つです。
以下で各項目の詳細を解説します。
確認・検証すべき項目が明確になる
V字モデルのメリットの1つめは、各開発工程に対応するテストが明確になっているため、どのテストで何を検証すれば良いかがわかりやすいことです。
例えば、基本設計に対応した結合テストでは「基本設計通りにプログラムが動作するか」を検証します。具体的には、「入力したデータに対して正しい値が返されるか?」「モジュール同士を結合した際にデータ連携ができているか?」などを確認します。
このように開発工程に対してテストの内容が決められることから、合理的にテスト工程を進められるでしょう。
作業の進捗が直感的に理解しやすい
V字モデルを採用すると、開発プロジェクトがいまどの段階にいるかを確認しやすくなります。小さい開発サイクルを繰り返すアジャイル型などと違い、各工程が段階的に進むからです。
また、開発工程と対応するテスト工程が図で視覚的に理解できることから、いまどの開発工程に対応するテストをしているかが開発に詳しくない人でもひと目でわかります。そのため、実際にシステム開発プロジェクトに参加していない上司などへの進捗の説明がしやすいというメリットも得られるでしょう。
各工程の責任者を明確にしやすい
基本的に各工程が明確に区切られていること、工程が終わってから次の工程に進むことなどから、工程ごとの責任者を明確にしやすい点もV字モデルのメリットの1つです。
例えば、要件定義ならプロジェクトマネージャー、詳細設計はシステムエンジニア、開発はプログラマーなどのように責任者を分けられます。
ただし、大規模なシステム開発や複雑なシステム開発の場合は工程をまたぐ作業があったり、同時進行したりすることもあるので注意しましょう。
不具合の修正を効率化できる
V字モデルでは開発工程に入る際に、各工程で行う作業やそれに対応するテスト工程で行うテストを詳細に設定します。そのため、テストで不具合が見つかった際にどの開発工程が原因だったかが明確にわかります。よって、不具合に対して素早く対応できます。
テスト工程と開発工程が対応していない開発モデルの場合、テストで不具合を発見してもどの開発工程に問題があったのかわかりにくい場合があります。その問題点を解決した開発モデルがV字モデルといえるでしょう。
大規模な修正が発生しにくい
V字モデルでは、細かい開発工程に対応するテストから順にテストをしていきます。そのため、小さい不具合を早めに発見して修正できることから大規模な修正が発生しにくい点がメリットです。
テスト工程が分かれていないと、結合した状態でのテスト中に不具合が見つかってもどこが原因かわかりにくくなってしまいます。仮にモジュール単位の小さな不具合だったとしても、全体をチェックしたり修正したりする手間が発生するおそれがあります。V字モデルならモジュール単位の不具合を確認・修正してから結合テストをするので、そのような事態を減らせるでしょう。
システム開発でV字モデルを採用するデメリット
システム開発でV字モデルを採用するデメリットは、主に以下の3つです。
以下で詳細を解説します。
柔軟性に欠ける
V字モデルは上流工程から下流工程に順番に進めていく形式の開発モデルのため、柔軟性があまりない点がデメリットの1つです。
例えば開発・実装・テスト・改良の一連の流れを繰り返すことが前提のアジャイル型の開発では、不具合修正や改善点の受け入れがスムーズにできます。
V字モデルの場合は、上流から下流へ工程の流れが決まっているため、開発の途中で不具合を見つけたり、改良案を取り入れたりすることが難しいといえます。よって、利用者の意見を取り入れながら短期間で改良を繰り返したいと考えているケースにはあまり向いていません。
大規模プロジェクトにあわないことがある
大規模なプロジェクトになると工程ごとにかかる手間や時間も膨大になりがちです。そのため、同時進行をせずに1つずつ順番に開発を進めるV字モデルでは、全体の開発期間も長くなることがあります。
一方で、テスト項目が細分化されていることから、テスト時に原因となった工程がわかりやすいという点は大規模開発に向いているといえます。大規模なシステムでいきなり結合テストをしてしまうと、どこに問題があるのかを特定するだけでも困難になりがちです。その点では、詳細テストから結合・統合テストへと進む形式のV字モデルの採用を検討しても良いかもしれません。
リスクを先送りしてしまうおそれがある
順番に工程を進めていくV字モデルは、リスクを先送りにしてしまうこともあります。小さな開発サイクルを作って繰り返すような開発モデルと違い、開発の上流工程にミスがあってもテスト工程に入るまで発見できないケースがあります。この場合、間にある開発の下流工程にもミスの内容が引き継がれてしまうかもしれません。
「後で対応するテスト工程で確認するから」と思わず、各開発工程の中である程度確認をした上で次の工程に進む仕組みにすることが大切です。
システム開発のV字モデルの工程
要求定義
上流の開発工程となる「要求定義」では、ユーザーテストとも呼ばれる「受け入れテスト」の設計が実施されます。
要求定義とは、開発するシステムに求める依頼側の要求・機能をまとめたもの。
どんな課題を抱えて、どうすれば解決できるのかを言語化していきます。
- 現状の課題(何に困っているのか)
- 理想の状態(どうなれば解決するのか)
- システム機能(どんな機能があれば良いのか)
例えば「○名が同時にアクセスして××を1秒以内に並列処理できるシステム」「○○ボタンをクリックすると、××と△△を処理できる機能」といった概要を決定します。
開発工程としての要求定義の粒度は「ユーザーがシステムで実現したいこと」なので、受け入れテストは「機能テスト」「ユーザビリティテスト」が中心となります。このフェーズを担当するのはPM(プロジェクトマネージャー)ですが、依頼側の積極的な関与も必須です。なぜなら、発注者とプロジェクトマネージャーの認識が一致していないと要求定義・受け入れテストが正しく実施できないからです。
開発工程 |
テスト |
主なテスト項目 |
内容 |
確認者 |
要求定義 |
受け入れテスト |
機能テスト |
実稼働時の状況を想定しながら システム全体の動作を検証する |
PM 依頼者 |
ユーザビリティテスト |
実際の業務、 それを想定したシナリオを 用意してシステムを稼働させ、 使用感・操作感などを チェック・検証 |
※要求定義に関する詳しい内容は下記の記事をご参考ください。
関連記事:システム開発における要求定義の重要性|要件定義との違いや要求定義の実態・改善ポイントを解説
要件定義
「要件定義」工程では、システムテストとも呼ばれる「総合テスト」の設計が実施されます。
要件定義とは、クライアントのニーズである要求定義を、これから開発するシステムでどのように実現していくかをまとめたもの。
下記のような内容を決めます。
- 開発目的
- 予算
- 必要な機能
- スケジュール(納期)
- 必要な人員(工数)
要件定義の粒度は「システムに実装された機能・非機能(性能などの機能以外の要件)要件が満たされているか」。
開発工程 |
テスト |
主なテスト項目 |
内容 |
確認者 |
要件定義 |
総合テスト |
確認テスト |
プログラムや、プログラム同士の連携に不具合がないか、 正しい挙動を示しているかを検証 |
PM 依頼者 |
評価テスト |
使い勝手、セキュリティ、障害時の耐性など、 システムの性能を評価して検証 |
|||
負荷テスト |
システムに大きな負荷をかけて稼働させ、 耐久性やパフォーマンスに問題が生じないかを確認・検証 |
※システム開発の要件定義についてより詳しく知りたい方は、以下の記事も参考にしてください。
関連記事:システム開発の要件定義とは?進め方や事例をわかりやすく解説(サンプル付)
基本設計
「基本設計」工程では「結合テスト」の設計が実施されます。
基本設計とは、要件定義をもとに、UI(ユーザーインターフェース)などの外側から見たシステムを設計するフェーズ。基本設計で行う作業内容は以下の通りです。
- 機能の洗い出し
- 扱うデータを整理
- 画面のレイアウトを決める
- 必要となるデータを明確化
基本設計に対応する結合テストとは、機能ごとに分割してプログラミングされたモジュールがサブシステムとしてキチンと連携できるかを結合させて確認するテストです。(モジュール:部品を集めて機能を持たせたもの)
基本設計の粒度は「基本設計書・仕様書通りにプログラムが動作するか」です。基本設計を担当するのはSE(システムエンジニア)やPMですが、依頼側が携わる最後のチャンスでもあります。
開発工程 |
テスト |
主なテスト項目 |
内容 |
確認者 |
基本設計 |
結合テスト |
ブラックボックステスト |
結合されたサブシステムに データを入力し、 正しい出力データが 返ってくるかを検証 |
SE PM 依頼者 |
インターフェーステスト |
機能間やモジュール間で データが正しく引き渡されるか検証 |
|||
トップダウン・ ボトムアップテスト |
サブシステムの上位、 もしくは下位モジュールから 順番に検証 |
※システム開発の基本設計についてより詳しく知りたい方は、以下の記事も参考にしてください。
関連記事:システム開発の基本設計とは?その位置付け・重要性・発注者としての関わり方を解説
詳細設計
「詳細設計」工程では「単体テスト」の設計が実施されます。
詳細設計とは、基本設計をもとに、プログラマーにわかる形でプログラミングの指示書・設計書を作成するフェーズです。詳細設計の工程の成果物は詳細設計書。
単体テストとは、プログラマーが開発・実装したモジュール単体が正常に動作するか確認するテストです。
詳細設計の粒度は「詳細設計書・仕様書通りにプログラムが動作するか」です。
※システム開発のテスト詳細設計についてより詳しく知りたい方は、以下の記事も参考にしてください。
関連記事:詳細設計とは?システム開発における位置付け・役割・成果物を解説
開発工程 |
テスト |
主なテスト項目 |
内容 |
確認者 |
詳細設計 |
単体テスト |
ホワイトボックステスト |
制作されたプログラムが 設計通りの処理を実行できるか? 網羅的に検証 |
SE |
※システム開発全体の流れを解説した記事もありますので、下記もご覧ください。
関連記事:システム開発の工程・流れをプロが解説!発注者が知っておくべきポイントを紹介
単体テスト
単体テストとは、プログラマーが開発・実装したモジュールが単体で正常に動作するか確認するテストです。
単体テストでは、プログラムの処理を検証する「ホワイトボックステスト」が中心となります。詳細設計を担当するのはSEであり、依頼側が携わることはほとんどありません。
ホワイトボックステスト:全てのプログラムが意図した通りに動作するかを確認
結合テスト
結合テストとは、複数のプログラムやモジュール(機能単位で分割されたプログラム)を結合して問題がないか確認するテストです。
結合テストでは「ブラックボックステスト」「インターフェーステスト」「トップダウン・ボトムアップテスト」が中心となります。
ブラックボックステスト:インプットに対するアウトプットが正常か確認
インターフェーステスト:異なるプログラムやモジュール同士のデータのやりとりを確認
トップダウンテスト:上位モジュールから下位モジュールへの連携を確認
ボトムアップテスト:下位モジュールから上位モジュールへの連携を確認
総合テスト
要件定義に対応する総合テストとは、納品される前のシステム(プログラム)が、要件定義を満たしているのかを開発側が確認するテストです。
総合テストでは「確認テスト」「評価テスト」「負荷テスト」が中心となります。要求定義同様、PMおよび依頼側の関与が重要になります。
確認テスト:プログラムやプログラム同士の連携に問題はないか確認
評価テスト:利便性やセキュリティ、障害への耐性などを評価・検証
負荷テスト:システムに負荷をかけて問題が発生しないかを確認
受け入れテスト
要求定義に対応する受け入れテストとは、最終的に納品されるシステム(プログラム)が、要求定義を満たしているのかを依頼側のユーザーが確認するためのテストです。
実際にシステムを動作させる環境を想定したテストが行われます。業務で使用する場合と同じように操作をして、システムが想定通りの動作をするか確認する作業です。また、連携が必要な別のシステムとの連携もこの工程でテストします。
一般的には開発を依頼した発注者側の主導でテストしますが、知識や技術がない場合などは第三者機関に依頼して検証してもらうことも可能です。
アジャイル型開発にV字モデルは採用できる?
ここまでで、ウォーターフォール型システム開発を例に、V字モデルの概要・メリットを解説してきましたが、近年採用されることの多くなったアジャイル型開発に「V字モデル」は適用できないのか?と疑問を感じた方がいるかもしれません。
アジャイル型開発とは、おおまかに策定されたシステム要件を細かい機能に分割し、優先度の高い順に「計画」>「設計」>「実装」>「テスト」>「リリース」を1つのサイクルとした「イテレーション(反復)」を繰り返し、システムの完成を目指す開発モデルのこと。
アジャイルのV字モデルではユーザーの参加が必須
アジャイル型にV字モデルを採用する際に必須となるのが、ユーザーと開発チーム、あるいはプロダクトオーナー(ウォーターフォール型でいうPM)との密接なコミュニケーションです。
アジャイル型でV字モデルを機能させようとしても、実態としてユーザー側の代表が常に参加できない、間に第三者が入ってしまうことが起きがち。イテレーション間が1〜3週間程度と短く、完成までが長期にわたりがちなことも課題の1つとなるでしょう。
アジャイル型システム開発にV字モデルを採用する場合は、こうした品質管理上の問題を踏まえたうえで、関係者がしっかりプロジェクトにコミットできるのか、実現可能性も検討することが重要になります。
※アジャイル開発についてより詳しく知りたい方は、以下の記事も参考にしてください。
関連記事:アジャイル開発とは?メリット・デメリット、発注側の注意点を解説
関連記事:アジャイル開発のおすすめシステム開発会社11選
V字モデルの進化型であるW字モデル
W字モデルとは、開発の最初のほうからテスト設計を開始し、開発の作業とテストを常に同時進行で行うモデルのこと。
プロジェクトマネジメント手法として、V字モデルは理にかなっているように思えます。しかし、上流の各工程でテスト設計を実施するため担当者に負担がかかる、第三者の視点がないためテスト設計に抜け・モレが生じる可能性があるという問題点もあります。こうした問題点を補完する目的で、V字モデルを進化させたものが「W字モデル」です。
上流工程の段階からテストエンジニアが参加し、各テスト設計のレビューも実施するW字モデルなら、「品質をより担保しやすくなる」「早い段階でテスト設計を詰められる」などのメリットが得られます。
W字モデルを採用することで「工程の後戻りリスク削減」「最終的な成果物の品質担保」「コスト削減」など、V字モデルで得られるメリットをより効果的に強化していくことが可能です。
V字モデルとW字モデルの違い
V字モデルは開発工程を全て終えてからテスト工程に入るのに対し、W字モデルはレビューという形で開発工程の合間にテストを同時進行します。そのため、上流の開発工程での設計ミスの早期発見に期待できるでしょう。
また、W字モデルは開発工程とそれに対応するレビュー工程の責任者を別々にできるため、開発工程の責任者の負担を軽減できる点もV字モデルとの違いといえます。
開発の上流工程でのミスを早期発見したり、開発工程の責任者の負担を分散させたりしたい場合にはW字モデルのほうが向いています。
W字モデルに対応できるシステム開発会社は多くない
いいことずくめのように思えるW字モデルではありますが、日本ではまだまだ浸透しているとはいえないのが現実。システム開発の品質を高めるためにはW字モデルが有効ですが人材などのリソース問題もあり、対応できるシステム開発会社は多くないのが実情です。
【まとめ】システム開発におけるV字モデルを紹介しました
システム開発におけるV字モデルとは何か調べているシステム開発担当者の方に向け、本記事では以下の内容を紹介しました。
- V字モデルを採用することで得られるメリット・デメリット
- 知っておきたいV字モデルの基本
- W字モデルの概要やV字モデルとの違い
失敗も少なくないシステム開発プロジェクトでは、V字モデル・W字モデルによる品質管理が欠かせないことが理解できたのではないでしょうか?しかし、依頼側として品質管理に携わりたいと感じていても、全てを自社でコントロールするのは不可能。パートナーとしてのシステム開発会社の協力が不可欠です。
そのためには、品質管理への高い意識を持つ、優良なシステム開発会社を選定することが重要なのです。V字モデル・W字モデルに対応できるシステム開発会社を探したいとお悩みの方は、システム幹事へご相談ください。
コンサルタントのご紹介
岩田
専任のコンサルタントが、
お客様の予算と目的を丁寧にヒアリング。
最適な会社をピックアップ・ご紹介させていただきます!
初心者の方でも安心してご相談いただけます。
必ず開発会社に発注する必要はありません。システム開発の相場の情報から最適な会社選びまで無料でサポートします。お気軽にご相談ください。
Q. システム開発のV字モデルとは何ですか?
システム開発のV字モデルとは、システム開発における開発の工程と、そのテストの相関をVの字で表したものです。V字モデルの工程として「要求定義」「要件定義」「基本設計」等が挙げられます。それぞれの内容は記事内で詳しく解説していますので、ぜひご覧ください。
Q. システム開発のV字モデルのメリットは?
システム開発のV字モデルのメリットは「テストを合理的に実施できること」「どの作業に対してどのテストが行われるか分かりやすい」などです。詳細は記事内で紹介していますので、ぜひご覧ください。
この記事を書いた人
梓澤 昌敏
専門分野: 音楽・映像制作、オウンドメディア、ビジネス
音楽・映像制作の現場を経て、スタジオ構築側の業界へ。マネージャー・コンサルタントとして制作現場の構築に携わる一方、自社オウンドメディアの立ち上げを含むマーケティングも担当してきました。現在アメリカ在住。作曲を含む音楽制作も提供しています。
このライターの記事一覧