システム構築の考え方（5原則・V字・V&V）
G-8 上流開発管理 ＞ G. 実行管理（プロジェクト） 元資料: ◆システム構築の考え方（8枚）
目的・概要
◆システム構築の考え方
考え方・観点
品質の作り込みと確認
- Ｖ字モデル
- 要求定義
- 要件定義
- 基本設計
- 詳細設計
- ビジネス
- 要求
- システム
- 要求
- システム
- 外部要求
- システム
- 内部要求
- プログラミング／単体テスト
- 運用テスト
- ユーザー受け入れ
- テスト
- システムテスト
- 結合テスト
- 検証
- 検証
- 検証
- 検証
- 妥当性確認
- 妥当性確認
- 妥当性確認
- 妥当性確認
- 品質の作り込みプロセス
- 品質の確認プロセス
- お客様の関与度合い
- 高
- 検証
- 妥当性
- ・・当該工程、直後の工程での整合がとれているか
- ・・全体最適が行われているか
品質の作り込みと確認／テスト戦略との関連
- Ｖ字モデル
- 要求定義
- 要件定義
- 基本設計
- 詳細設計
- ビジネス
- 要求
- システム
- 要求
- システム
- 外部要求
- システム
- 内部要求
- プログラミング／単体テスト
- 運用テスト
- ユーザー受け入れ
- テスト
- システムテスト
- 結合テスト
- 検証
- 検証
- 検証
- 検証
- 妥当性確認
- 妥当性確認
- 妥当性確認
- 妥当性確認
- 品質の作り込みプロセス
- 品質の確認プロセス
- お客様の関与度合い
- 高
- 検証
- 妥当性
- ・・当該工程、直後の工程での整合がとれているか
- ・・全体最適が行われているか
V＆V（Verification & Validation）
- V&V（検証と妥当性確認： Verification & Validation）とは、仕様適合性を確認するVerification（検証）と、ニーズ充足性を確認するValidation（妥当性確認）という観点の異なる2種類のプロセスの総称である。「正しく作れていることの確認」と「正しいものを作れていることの確認」は関係しているものの、本質的な意味は異なる。
- （中略）
- Wallaceらは、V＆Vの利点として次のものを挙げている
- リスクが高い問題の早期発見
- システム要求に対する成果物の評価
- 品質と開発進捗状況に関する情報の継続的な共有
- システムのできばえが順次見えることによるユーザーとの早期調整
- 出典： ソフトウェア品質知識体系ガイド第3版（SQuBOK V3） より
V字における対応工程の認識①
- 様々な解釈があるので、
- 事前の工程定義（認識合わせ）が必要
V字における対応工程の認識②
- 様々な解釈があるので、
- 事前の工程定義（認識合わせ）が必要
イメージ図
手順・進め方
手法・理論
システム構築５原則 by シーズメッシュ
- １） システム以前に課題ありき
- システム化を検討する前に、ビジネス戦略上の課題、業務の課題、システムに対する要求を明確に区別する必要がある
- それらは、ビジネス影響も踏まえ 「 ビジネス課題＞ 業務課題＞ システム要望／課題 」 という構図で捉える
- ２） 戦略なきシステム化は罪と考えよ
- 新たにシステム化を検討する場合は、必ず上位戦略のどんな課題を解決するかを明らかにする
- 既存システムの場合は、システム上の課題が業務上のどんな課題を解決するか、その結果がビジネスにどのようなインパクトをもたらすかを明らかにする
- ３） 要件には理由が存在し、理由には意志が存在する
- 理由のない要件は無くても困らない要求から発生する
- 理由の明確さは、戦略や業務影響から”解決すべき”という意志によって浮き彫りになる
システム構築５原則 by シーズメッシュ
- ４） 作るが2割、動かすが8割で考えよ
- システムは動いてから価値を発揮するものであり、8割は、動いた後にどう改善し、運用を維持するかがカギとなる
- 多くは、いつまでに何をどう作るかにフォーカスされがちなため、システムが生み出す価値に重きを置いて構想を組み立てる必要がある
- ５） 投資は客観性と納得性で判断せよ
- まずは方針(*1)に基づく判断基準を設定する・・客観性
- *1 ・・小さな成功を積み重ね,利益を創出する、リスクを取って先行投資する、等
- その投資（コスト）がビジネス／業務に価値をもたらす根拠を明らかにする・・納得性
- まずは方針(*1)に基づく判断基準を設定する・・客観性
ソフトウェア開発 ～失敗から生まれた原理原則～
- IPA/SEC「実務に活かすIT化の原理原則17ヶ条」より
- 原理原則[1] ユーザとベンダの想いは相反する
- 原理原則[2] 取り決めは合意と承認によって成り立つ
- 原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則[4] ステークホルダ間の合意を得ないまま，次工程に入らない
- 原理原則[5] 多段階の見積りは双方のリスクを低減する
- 原理原則[6] システム化実現の費用はソフトウェア開発だけではない
- 原理原則[7] ライフサイクルコストを重視する
- 原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
- 原理原則[9] 要件定義は発注者の責任である
- 原理原則[10] 要件定義書はバイブルであり，事あらばここへ立ち返るもの
- 原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則[12] 表現されない要件はシステムとして実現されない
- 原理原則[13] 数値化されない要件は人によって基準が異なる
- 原理原則[14] 「今と同じ」という要件定義はありえない
- 原理原則[15] 要件定義は「使える」業務システムを定義すること
- 原理原則[16] 機能要求は膨張する。コスト，納期が抑制する
- 原理原則[17] 要件定義は説明責任を伴う
- 出典： http://sec.ipa.go.jp/publish/tn10-001.html
