〒160-0023
東京都新宿区西新宿3-2-9

TEL : 03-5324-2452

システム開発のVモデル

■Vモデルとは何か?
システム開発のVモデルとは、ウォーターフォール型のシステム開発において適用することができるフレームワークです。ウォーターフォール型の他にもアジャイル型と呼ばれるシステム開発の形態もありまあすが、アジャイル型にはVモデルを適用することはできません。

Vモデルはシステム開発の時系列の流れを表しており、「要件定義」、「基本設計」、「詳細設計」、「開発」、「単体テスト」、「システムテスト」、「受入テスト」のというフェーズがあります。「要件定義」は「要求定義」、「システムテスト」は「結合テスト」等と呼ばれることもありますので、会社やプロジェクトにおいて、各フェーズとテストの名称を事前に定義づけて共通理解をはかっておくことが必要となります。

また、Vモデルの特徴的な考え方が「要件定義」から「開発」までの各フェーズに対応してテストが定義されていることです。「要件定義」が正しくシステムに反映されているか否かをテストするために「受入テスト」があります。そして、「基本設計」には「システムテスト」、「詳細設計」には「単体テスト」が対応するテストとして存在しています。

Vモデルに当てはめて考えることで、「受入テスト」でNGとなるのは、「要件定義」が「基本設計」や「詳細設計」に正しく反映されていなかったか、もしくは、「要件定義」自体が正しく行われていなかったためという具合に問題の原因を分析することも可能となります。

[page_title]

■各フェーズについて
次にVモデルで定義されている各々のフェーズについて、誰が、何をするのかについて概要を記載していきたいと思います。誰が(担当者)については、会社やプロジェクトによって異なってくるもので、定まったものではなく、イメージとして記載しています。

要件定義
[担当者] 主にシステムを使用するユーザー、実際に業務を行っている担当者
[内容] システムを導入しようしている対象業務の業務フローや業務記述書を作成することから始まり、システム化に際しての要件を明確にする
[アウトプット] 要件定義書

基本設計
[担当者] 主にIT部門
[内容] 要件を実現するために、システム全体をどのような構造にするかを明確する
[アウトプット] 基本設計書

詳細設計
[担当者] 主にIT部門
[内容] 実装する必要がある一つ一つの機能の詳細な仕様を設計する
[アウトプット] 詳細設計書

開発
[担当者] 主に開発ベンダー
[内容] 詳細設計に基づいて、コーディングをする
[アウトプット] 開発されたシステム

単体テスト
[担当者] 主にIT部門
[内容] 詳細設計書通りに各機能が開発されているかテストをする
[アウトプット] 単体テスト仕様書、及び結果表

システムテスト
[担当者] 主にIT部門
[内容] 基本設計書通りにシステムが構築されているかテストをする
[アウトプット] システムテスト仕様書、及び結果表

受入テスト
[担当者] 主にシステムを使用するユーザー、実際に業務を行っている担当者
[内容] 要件定義書通りにシステムが開発されているかテストをする
[アウトプット] 受入テスト仕様書、及び結果表

■Vモデルの観点から見たシステム開発の失敗原因
システム導入をする際に良く起こりがちで致命的な失敗は、システム開発してローンチしてみたものの実際の業務に適合しておらず、システムが使われなくなってしまうというものです。そして、この失敗は何故起こったのかという犯人探しが行われ、開発ベンダーの開発力が無いことやテストがしっかり行われていなかったことなどがやり玉に挙げられます。

しかし、多くのシステム開発の失敗原因を掘り下げてみると、実は「要件定義」がしっかり行われていなかったことが原因であることが多いように思います。「要件定義」がしっかり行われていないと、受入テストの段階やシステムローンチ後に業務ユーザーが実際にシステムを使ってみて、システムの機能が実際の業務に適合していないことが判明してしまいます。Vモデルで、一歩引いて考えてみると起こるべくして起こった失敗なのですが、システム開発の現場では、こうした事象が多く発生しがちです。このような、不十分な「要件定義」により使えないシステムが出来上がる真因は3つほどに集約されるのかもしれません。

一つ目は、「要件定義」の段階で適切なユーザーを巻き込めていないこと。システムに置き換えようとしている業務の全体像を理解して、詳細な要件出しを出来るような担当者が担っていないと「要件定義」が適切に行われないことになります。
二つ目は、システム開発の期間が短すぎること。システム開発に係る予算が少ない場合などに、システム開発期間を短縮しようする動きがでてきます。このような場合に、「要件定義」に十分な時間を費やすことができなくなってしまいます。
三つ目は、答えありきのシステム導入となってしまっていること。これは、グローバル企業などでよく起こりがちなのですが、本社のグローバル・システムを無理やりローカルのオペレーションに適合させようとして、ローカルの現場業務に適合しないシステムとなってしまうような場合が考えられます。このケースもフィット・アンド・ギャップ・テストのような広い意味での「要件定義」が不十分であることやローカルの現場ユーザーの意識改革が上手くいかなかったことにより使えないシステムが出来上がってしまったと考えることができるのかもしれません。

このようにシステム導入の失敗事例を掘り下げていくと、業務の生産性を高めるというような本質的な目的が忘れ去られて、システムを導入することが目的になってしまい、最も重要なユーザーによる要件定義が疎かになってしまっていたということが真因である事が多いように思います。