Vモデルによるシステム開発のフェーズを自動車に例えて説明する【SIer】

      2018/09/24


「要件定義とか基本設計とか、何をするのかわからない」
「システム開発の具体的な手法が知りたい」

この記事は、そんな方へ向けて書いています。

こんにちは、TEN(@02smwhere)です。

本記事では、企業における業務改善やシステム導入のプロジェクトが、どんな手法で進んでいくかご説明いたします。

さらに理解を含めるために、具体的なシステム開発手法であるVモデルについて、自動車の開発に例えて説明していくことにします。

本記事のまとめ
  • システム導入プロジェクトにおける各フェーズのゴール
  • Vモデルによるシステム開発の手法
スポンサーリンク

Vモデルの開発の始まりである “要件定義フェーズ”

スクリーンショット 2017 11 05 13 25 55

システム開発において、まず初めに行われるのが要件定義フェーズです。

現場やクライアントとのヒアリングを通じて、プロジェクトにおけるスコープ、達成条件を定義していきます。

目的は、後続フェーズの手戻りを防止したり、契約トラブルを回避するのが、主な目的です。

また、明確な成果物や課題、クライアントの要求を引き出して、ソリューションを提案するのが、コンサルタントとしての仕事になります。

 
自動車で表すと、新しい車のコンセプトを決める仕事に近いです。

「30代のファミリー層をターゲットにした、燃費の良い8人乗りのミニバンを、2年後の夏までに発売する!」といった具合ですね。

 
具体的な要件は、機能要件非機能要件に分かれています。

機能要件とは、システムが持つべき要素のことです。
提案やヒアリング結果をインプットとして、それらを分析・理解・識別していきます。

 
一方、非機能要件は性能、セキュリティ、パフォーマンスなど、機能以外のメカニカルな要素の意味合いが強いです。

システムのパフォーマンスによって、例えば同じプログラムでもパソコンのよって処理が3時間かかるか、10時間かかるかにより、書くべきプログラムすら変わってきてしまいます。

クライアントの要望や運用の条件、旧システムの実績、何秒以内に画面遷移するのがストレスのない一般的な基準なのか等、数値目標を達成できるようなサーバやアーキテクチャ関連の要件を固めていきます。

 

以上のステップを踏まえて、要件定義におけるアウトプットは次のようなものになります。


  • 業務フローや業務一覧
  • システムの使用例(ユースケース)
  • システム機能構成要素(画面やプログラム名)
  • インターフェースのイメージ
  • その他の概念図など

要件定義に続く上流工程 “基本設計フェーズ”

スクリーンショット 2017 11 05 13 26 42

続く基本設計フェーズでは、要件定義を達成するための仕様を明確にしていきます。

 
例えば、データの登録画面であるユーザインターフェース、レシートや給料明細といったレポート、それらを保管するデータベースなどです。

他にも、集計や送信などのバッチ処理、他システムとの連携、ログインや承認プロセスなどのインターフェースを詳細に詰めていきます。

バッチ処理とは、業務上のある区切りにおいて、システムのパフォーマンスなどのデータを一定期間・一定量、まとめて処理することです。

運用の負荷を下げることが主な目的であり、いわゆるリアルタイム処理対義語と考えてください。

これらを前フェーズをインプットとして精錬し、クライアントのレビューや最終合意を取っていきます。

基本設計フェーズにおいては、ハード面ソフト面の二面から、アウトプットが生成されます。

以下に、一覧をまとめておきましょう。


ソフトのアウトプット例
  • 画面遷移図(サイトマップ)
  • UI標準(フォント)
  • 画面設計書(配置)
  • 帳票設計書(リストなどのレイアウト、ロジック、式)
  • 論理データモデル設計書(使用項目)
  • バッチ設計書(データ量、実行頻度)
  • インターフェース設計書(システム間のやり取り、文字コード)

  • ハードのアウトプット例
  • ハードウェア(クライアントのコンピュータ、サーバ)
  • ソフトウェア(OS、アプリケーション)
  • ネットワーク(社内など狭い範囲でのLAN、電話や専用回線を使った広域通信やVPN含むWAN、インターネット)
  • アーキテクチャ
  • これは自動車に例えると、各ユニットの性能を定義するイメージです。

    ユニットとは、エンジン、シャシー、モーターなど、複数の小さな部品が組み合わさった、言わば大きめの部品のことです。

    システムと車も同様に、全体ではなく、まずはエンジンであればエンジンだけで目標性能が決められて、開発チームが割当てられます。

    スポンサーリンク

    具体的なシステム開発に当たる “詳細設計・開発フェーズ”

    スクリーンショット 2017 11 05 13 40 25

    基本設計に続くのが、詳細設計、そして開発フェーズです。

    設計の詳細をさらに明確にして、実際にプログラムを組める状態にして、プログラミングしていきます。

     
    このフェーズになると、クライアントと直接会議を行なうことは少なくなり、自社で業務に取り組むことが多くなってきます。

    なぜならば、プログラミングの方法も開発標準に則りますし、上流工程で要件は聞き出しきって、こなすべきタスクが明確で具体的になってくるためです。

     
    また、開発にはオフショア開発といって、人件費の安い海外拠点を用いる場合も多くなります、

    その場合、国内のコンサルタントはレビューをおこなうなど、クライアントと決めた基準を守れるような、高品質を担保する必要があります。

     
    自動車に例えるのであれば、各ユニットを構成するネジやギアなど、さらに細かい部品の設計や開発に移るイメージです。

    下請け業者に委任して開発をしてもらい、その性能を確かめつつ、製品への採用を決めていく…といった工程でしょうか。

     
    クライアントに提出するアウトプットとしては、以下のような成果物が考えられます。


    • 帳票やクラスの設計書
    • クラス間の繋がりや流れを表すシーケンス図
    • 詳細を追記した前フェーズまでの設計書
    • 具体的なソースコード

    ですが実際には、後続のテストフェーズの結果を持ってして、完了の判断をすることが多いです。

     

    システム開発全体の品質を担保する “テストフェーズ”

    スクリーンショット 2017 11 05 13 49 36

    さて、開発が済んだあとには、それらをテストするフェーズが待っています。

    実は前フェーズの時点で、すでにテストの計画は出来上がっていることが多いです。

    というのも、ここまでの要件定義、基本設計、詳細設計の成果物を持ってして、テスト計画や内容の検討、テストの実施や不具合修正、クライアントへの報告を行なうのが、このフェーズの目的だからです。

     
    上のVモデルを見ればわかるように、単体テストはプログラム単体をテストし、詳細設計の結果を確認していきます。

    同様に、プログラム同士のつながりを見る結合テストでは基本設計を確認し、製品全体を見るプロダクトテストでは要件定義を確認します。

     
    車に例えるのであれば、ネジの耐久性やサイズを図るのが、単体テスト。

    組み上がったエンジンの性能を確認するのが、結合テスト

    それらを完成車にしてコース走行をするのが、受入テストです。

     
    さらに性能負荷や耐久性、処理スピードなどのパフォーマンステスト、お客様の視点から当初のコンセプトが実現されているかを確認するユーザ受入テストがあります。

    これらを経て、展開・定着化前の最終確認とします。

     
    テストフェーズでは、必要条件が満たされているか確認するのが目的です。

    以下の視点に乗っ取り、それらを確かめていきます。

    • Varification(正しいやり方か、成果物やプロセスが正しいか、上流で確認する)
    • Validation(正しいことをしているか、前工程を正しく反映しているか、成果物の内容を確認する)
    • Testing(設計通りに動作しているか、そのプロセス通りか)

    さらに成果物としては、以下のものが挙げられます。


    • テストの環境、スケジュール、体制、方針、目的、報告ルールを記したテスト計画書
    • テスト条件と予想結果
    • 具体的なテスト実施単位のサイクルと実施項目
    • テストの手順を示したスクリプト

    Vモデルにおける開発の最終ステップ “移行フェーズ”

    StockSnap BSALH690F5

    以上をもってシステム開発は終了しますが、システムを利用可能にして、新業務を開始する環境を作らなければなりません。

    そのためのフェーズが移行フェーズであり、アーキテクチャやアプリケーションを含む新しいシステムを移行して、業務運用につなげていく必要があります。

     
    移行は、以下の三つの視点から実施されます。

    1つ目のシステム移行では、ユーザが利用できるように準備して、アプリのインストールやサーバの移行を行います。

    2つ目のデータ移行では、過去から蓄積してきた業務データや、今後も必要マスタデータなど、各データを必要なだけ投入していきます。

    3つ目の業務移行として、研修やサポート、実施後の分析改善を行っていきます。

     
    その際には、移行のスケジュールや体制が示された移行計画書、手順や具体的な作業、障害時の対応を含む移行設計書などが用いられます。

     
    自動車に例えるならば、ここまで来ると完成車メーカーの手を離れつつあり、販売ディーラーへ商品の説明を行ったり、車両整備のためのマニュアルを作ったりすることになります。

     

    システム導入後の業務である “保守・運用”

    OZP graindhibana1188 TP V

    実際にシステムが稼働した後にも、作業やサポートが継続することがあります。

    システム導入においては、開発者に責任があると無償で修理しなければならない、担保責任と呼ばれるものがあるのです。

     
    そのような保守業務においては、システムの改修やアップデート、インフラの修理や、新しいシステム導入の提案までを含みます。

    運用とは、システムの監視やデータバックアップ、サポートセンターの設置などが業務として挙げられます。

    成果物としては、マニュアルや実際の操作画面などのオペレーション手順書、監視項目の一覧、問い合わせに対応するための連絡先や運用方法などです。

     
    自動車においても、ただお客様に車を売りつけて終わりではなく、車検や定期点検、部品の交換に対応する必要がありますよね。

     
    合わせて読みたい>>>> 業務改善でSIの仕事をする意味を車に例えて解説する
     

    上流工程と下流フェーズが対になっているVモデル開発手法

    スクリーンショット 2017 11 05 12 32 38

    ここまで見てきたように、Vモデルによるシステム開発は、様々なフェーズを経て実行されていきます。

    Vモデルにおける開発手法では、あるフェーズでのテスト結果は、対になっている上流工程で決めたものをテストする関係になります。

     
    したがって、上流フェーズの人は下流に迷惑をかけないように、きっちり要件やスコープ、実現性のある予算やスケジュールを決めておくこと。

    下流フェーズの人は上流で既にヒアリングした内容や決定事項をきちんと把握し、責任感をもってプロジェクトに取り組むことが、非常に大切です。

     
    Fidget spinner 2343174 1280

    最近ではアジャイル開発といって、こういったフェーズに囚われないシステム開発も多くなってきてはいます。

    ですが、現状では本記事で説明したようなウォーターフォール型と呼ばれる、各フェーズを経て次のフェーズへ流れていく手法が主流です。
     
    Vモデルを理解し、どのフェーズにおいても他との業務の繋がりを意識しつつ、プロジェクトに取り組んでいきましょう。

     
    合わせて読みたい>>>> IT業界のビジネスを知るなら、アジャイル型とウォーターフォール型の開発手法の違いを知るべき
     

     - データ分析