外部設計で作るドキュメントについて

ＩＰＡの「機能要件の合意形成ガイド」の話を聞いてきた！

この「機能要件の合意形成ガイド」は、外部設計での合意形成で
（「機能要件の合意形成」ってあるけど、要求仕様の機能要件じゃなくって、
　それが決まった後の話）途中に、外部設計でつくる、工程成果物の話が出てくるよ！



機能要件に関する発注者と開発者の合意形成を目指して

・要件定義を終わって、外部設計を出すときのノウハウ

■「機能要件の合意形成ガイド」の開発背景

・機能要件の合意形成ガイドって何？
　　合意形成のためのコツ
　　手戻りを防止するコツ
　　コンテンツ：７つのドキュメント
　　　　概要
　　　　画面
　　　　業務フロー
　　　　データモデル
　　　　帳票
　　　　バッチ処理
　　　　外部インターフェース

・作った背景
　システム開発における手戻りコスト
　あとで見つかるほど、戻る
　　　設計工程でしっかり物を作る

　昔は業務要件は簡単
　　人
　　システム
　→システムが複雑になってきた
　→ステークホルダー：利害関係者がいっぱい

要件定義：発注者＝きめるところまで
外部設計：開発ベンダー
　　→作業者も変わる、組織も変わる
　　→認識の合意：難しい→これを作った

・開発の歩み
　　発注者ビュー検討会
　　　発注者ビューガイドライン
　　ＩＰＡ　機能要件の合意形成技法ＷＧ

　→ＣＤ−ＲＯＭの中に入っている
　　Ｗｅｂでも公開：月７００〜８００件も見てもらっている

■機能要件の合意形成ガイドの目的
・認識のそごうを防ぐためのノウハウ
　　→体系的に示しているものではない
　　→どんな場面でもよいわけではない
　　→事例

技術領域：６つにわけて纏めている
　　→工程成果物を想定
・システム振る舞い編
　：業務フロー／業務説明／業務一覧／共通ルール
・画面編
　：画面遷移／画面アクション明細／画面レイアウト／画面入出力項目一覧
　　画面一覧／画面遷移・レイアウト共通ルール
・データモデル編
　：ER図／エンティティ一覧／エンティティ定義／ＣＲＵＤ図
　　その他資料（データ辞書／ファイル一覧・定義等）
・外部インターフェース編
　：外部システム関連図、外部インターフェース一覧／外部インターフェース項目説明
　　外部インターフェース処理説明
・バッチ編
　：バッチ処理一覧／バッチ処理定義／バッチ処理フロー／バッチ処理共通ルール
・帳票編
　：帳票概要／帳票一覧／帳票編集定義／帳票項目説明／帳票レイアウト

・合意形成とは：合意成熟度と４つの作業

　合意成熟度
　　　仕掛
　　　　言い切った・聞ききった→要件定義が完了
　　　充実
　　　　図表に書いてレビュー
　　　完成
　　　　合意内容を確認・管理

　４つの作業
　　・言い切る／聞ききる
　　　　目的範囲・制約条件（法律とかも）
　　・図表に書く
　　　　共通ルール／整理して書く
　　・もれ矛盾なくチェック
　　　　共通ルールにもれ・矛盾はないか？他の工程との整合性
　　　　複数のドキュメントを付け合せて
　　・レビュー
　　　　そごうがない／想定・前提

・中身（目次構成）

　３章構成
　　１．工程成果物の定義
　　２．工程成果物の詳細説明
　　３、コツの紹介

　メリットが書かれている

・適用例
　ユーザー役割ごとに書くとか
　画面レイアウトと遷移図を付き合わせる
　データモデル：データを入れてチェック

・事例のまとめ
　どの局面でも通用するわけではない
　唯一の階ではない
　全体を俯瞰するコツではない

・発注者側の要求確認編
＜＜問題事例＞＞
　　ドキュメントを比較していない
　　レビューを１つしか見ていない
　　申請と承認を同じ人でできるようにしてしまった
　　　　→ロールの説明がしてなかった
　　　　→開発にどんどん進んだ
　　→対応：業務要件が満たされていることをレビューすること！
　　思ったものとできたものが違ってた
　　　　→ラフスケッチを見せていない
　　　　：
　　　　：
　　（以下、にたような事例なので、省略）
＜＜まとめ＞＞
　・あいまいな発注→言い切るコツ（ID02T001)
　　　　事前に文書にまとめて伝える
　　　　文書：要件定義にあるもの
　　　　　　　システムを利用する組織・拠点と役割
　　　　　　　システムに対するイメージ
　　　　　　　システム対象範囲
　　　　　　　業務の流れ、手順
　　　　　　　重要な日付・期間
　　　　　　　目的、効果
　　　　　　　方式、制度、準拠すべき規則
　・正確に伝えたつもりでも、伝わっていない→レビュー


・まとめ
　　４つのコツを纏めたもの
　　６つの技術領域
・利用場面
　　開発標準
　　社内教育・グループレビュー