生産管理の基本！QCDで一番重要視すべきは？
branchpine
中小企業診断士ぶらんちブログ
【経営情報システム】V字モデルとは
branchpine
記事内に商品プロモーションを含む場合があります
こんにちは。ぶらんちです。本日はシステムエンジニア出身ITコンサルタントの本領発揮ということで、経営情報システムよりV字モデルについて紹介いたします。
Contents
スポンサーリンク
システム開発の流れはV字モデルで覚える
ぶらんちがまだ新人SEだった頃、社会の契約プロセスが全く分からず、何がどうなればシステム開発が開始して完了するのか理解できませんでした。
そんな時に、「まずこれを覚えなさい」を教えられたのがＶ字モデルです。
V字モデルは最も一般的な開発手法であるウォータフォール型開発における、一連の流れを図示したものです。
（実際は発注前段階のプロセスがあるので図に足しました）
要件定義からシステム開発まで、業務フローをプログラミングコード化できるよう徐々に設計を細かくしていきますが、テスト工程については細かい挙動から要件実現に向かってだんだんテスト規模を大きくしていきます。
システム開発のプロジェクトマネージャー（PM）はV字モデルに沿って進捗管理を行います（契約形態についてもV字モデルに沿って選択しますが、また別の機会に解説します）。
ちなみに各工程のことをフェーズを言います。以降はフェーズごとに解説します。
システム構想フェーズ
業務の自動化や現状のシステムが老朽化してしまった場合など、システム化検討を開始する場合は以下のことを取りまとめます。
- システム化の目的・背景
- システム化する業務要件（システム化範囲）
- 期待する効果
- プロジェクトの予算
- 全体スケジュール
- プロジェクト体制
- 開発ベンダー（事業者）選定
通常、システム部門が実際に利用するユーザー部門と調整し取りまとめていきます。ただし、システム化したいニーズはまとめられても、それらを実現できるサービス・機能がこの世に存在するのかは調べてみないと分かりません。
発注者は大抵専門家ではないので、RFIやRFPを発行し、開発ベンダーを選定します。
- RFI（Request For Information：情報提供依頼書）
システム化の目的や業務要件をまとめた文書。開発ベンダー数社に送付して、現在提供しているサービス内容や開発実績など、RFP作成に必要な情報を収集する。 - RFP（Request For Proposal：提案依頼書）
開発ベンダーに提案を依頼する文書。システムの主要な機能や利用時間・保守運用条件などを記載する。基本的にRFIを依頼した開発ベンダーに提示する。
発注者は、各社から提示された提案を比較し、最も良い提案を頂いた開発ベンダーを採択する。
要件定義フェーズ
要件定義とは業務フローの内容を出来るだけ定量的に定義することです。要件定義は厳密には業務要件定義とシステム化要件定義に分かれます。業務要件定義はRFPを作成するために行うものですので、本フェーズの要件定義とはシステム化要件定義のことを指します。
要件定義のイメージ
- 業務要件定義（RFPでの記述）
同時アクセスに制限を設け、上限を超えるアクセスがあった場合は「しばらくお待ちください」ページを表示できること。 - システム化要件定義（要件定義書での記述）
同時アクセス数は200とする。
200を超えるアクセスがあった場合は「しばらくお待ちください」ページを表示する。
尚、同一IPアドレスから50を超える同時アクセスを検知した場合は、不正操作と見做し当該IPアドレスに対してのみ即座に「しばらくお待ちください」ページを表示する。
設計フェーズ
要件定義が完了したら、設計フェーズに遷移します。
設計フェーズは、基本設計（外部設計）と詳細設計（内部設計）に分かれます。
基本設計（外部設計）フェーズ
基本設計（外部設計）とは、システムの基本となる設計のことです。要件定義フェーズで決定した機能や性能、制約条件などを基にし、主にユーザー操作など目に見える部分の設計（操作画面の遷移、データ出力方式等）を行います。
合わせて、セキュリティ仕様や運用・保守計画なども本フェーズで設計します。
詳細設計（内部設計）フェーズ
詳細設計（内部設計）とは、システム内部のデータ設計等、実際に開発・構築に必要な設計のことです。主にプログラム開発担当者やプログラミングを行うメンバーに向けた設計なので、これまでのフェーズでは資料数は最も膨大となります。
ここまで来ると専門的な内容も多く含まれるので、専門知識がない者が成果物の中身を理解することが難しくなってきます。発注者側は内容説明の機会（レビュー）を多く設ける等、ベンダーとのコミュニケーションを密にしてチェック体制を整備する必要があります。
構築（開発）フェーズ
設計フェーズで作成した設計書を基に構築・開発を行います。
（とにかく作る！！！ひたすら作る！！！）
テストフェーズ
構築・開発が完了したら、即本番移行とはならず、幾重もテストを重ねて正常性を確認します。
各テストは詳細設計から順に遡って確認していくイメージです。
単体テスト
詳細設計のうち、モジュール単体に対するテストを行います。プログラミングの最小単位であるモジュールごとにテストを行うことで、まずそのモジュールにバグがないかを確認します。
結合テスト
詳細設計のうち、各モジュールを結合して行うテストのことです。システムによってモジュールの規模が異なるので、結合テストの段階で大規模テストになることもあります。
システムテスト
サブシステムや複数の機能を全て統合したテストのことです。基本設計で定義された機能や性能を満たしているかを確認するものであり、開発者側が実施する最後のテストです。
運用テスト・受入テスト
発注者側が実際に新システムを利用して業務に支障がないことを確認する最終テストのことです。要件定義の内容が実現されているか、ユーザー視点で確認します。
検収のために行うテストでもあるため、不具合や仕様誤りを見逃してしまうと本番稼働時に業務支障が発生する事態となる上、修正には追加費用がかかる可能性が高いです。
なので、発注者側はユーザー利用部門の協力を得て、さまざまな業務ケースを可能な限り実施する必要があります。
まとめ
如何でしたでしょうか。
上記一連の流れを、開発ベンダー側で対応するのがシステムエンジニア、発注者側を支援する立場で参画するのがITコンサルタントです。
ちなみにぶらんちはITコンサルタント×中小企業診断士（登録前だけど）です。上記支援のほか、ITコンサルタントには出来ないご支援も可能です。何かありましたら問い合わせフォームまでお願いしますww
ABOUT ME
システムエンジニアとして14年間キャリアを積んだ後にコンサルティングファームに転職。ITコンサルタントとして従事する傍ら、中小企業診断士として伴走支援を実施中。
