机能要件に关する发注者と开发者の 合意形成を目指 .ppt

* 少々手前味噌的ですが、ＷＧ参加の各社等での活用状況はこの表にまとめたとおりです。 * 例えば、 ベンダへ 設計書を作ることを目的としていませんか？ ユーザから聞いたことだけでシステムを作ろうとしていませんか？ 標準を定めた時の熱い情熱が冷めてはいませんか？ （機械的にドキュメントを作ることを奨励していませんか？） （「書く」意味が廃れていませんか？） （「書けば仕事が終わり」などと考えていませんか？） ツールの使い方やそのツールへの登録情報を意識しすぎた設計内容になっていませんか？ ユーザへ ベンダから聞かれたことを答えるだけでよいシステムが出来ると考えていませんか？ 枝葉末節にこだわりすぎで大きな視点が欠けていませんか？（→システム振舞い） 共通 一度決めた標準をずーっと見直さずに使い続けていませんか？ * 「機能要件の合意形成ガイド」は、概要編と６つの「技術領域」の分冊である画面編、システム振舞い編、データモデル編、帳票編、バッチ編、外部インタフェース編の合計７つの分冊から構成されています。 概要編には??? その他６編には、それぞれの技術領域特有の進め方や「コツ」を掲載しています。 それでは、概要編から　　「合意形成の進め方」　　　について解説します。 * 本ガイドでは、外部設計の工程での作成される、成果物に対してコツをまとめています。 その成果物を工程成果物と呼んでいます。 各工程成果物の名称はケースバイケースで変わり、また独立したドキュメントであるとは限りません。 １つのドキュメントが複数の工程成果物を含むこともあります。 また、本ガイドで使っている工程成果物が、外部設計で必要なドキュベントを全て網羅している訳では限りません。 システム振舞い編では、次の４つの成果物を想定しています。 システム化業務一覧 システム化業務フロー システム化業務説明 しステム化振舞い共通ルール * 画面編では、次の６つの成果物を想定しています。 画面一覧 画面遷移図 画面アクション明細 画面レイアウト 画面入出力項目一覧 画面遷移?レイアウト共通ルール * データ編では、次の４つの成果物を想定しています。 ＥＲ図 エンティティ一覧 エンティティ定義 ＣＲＵＤ図 その他（データ辞書等） 画面遷移?レイアウト共通ルール * 開発対象となる業務システムとそれ以外の業務システム（同一企業内／企業外を問わず）との間で発生するデータのやりとりを外部インタフェースと定義しています。 外部インタフェース編では、次の４つの工程成果物を想定しています。 外部システム関連図 外部インタフェース一覧 外部インタフェース項目説明 外部インタフェース処理説明 * バッチ編では、次の４つの工程成果物を想定しています。 バッチ処理一覧 バッチ処理フロー バッチ処理定義 バッチ処理共通ルール * 帳票編では、次の５つの工程成果物を想定しています。 帳票一覧 帳票概要 帳票項目説明 帳票レイアウト 帳票編集定義 * この図は、ガイド作成の議論の際に利用したものです。 合意形成は、発注者と開発者の協同作業であり、外部設計工程を通して段階を踏んで徐々に成熟していきます。 外部設計工程で作る成果物は、ある時点それぞれのスナップショットです。 外部設計工程で作る成果物をうまく利用して、合意形成を進めるためには、その成果物の書き方だけではなく、こう形成に向けての段階の踏み方が重要となります。 本ガイドではこの合意形成の段階のことを合意成熟度のレベルと呼びます。 また、大量な設計内容の合意形成を図るためには、通常次の３段階を踏んでいると想定し、その各段階を本ガイドではそれぞれ「仕掛レベル」「充実レベル」「完成レベル」と呼びます。 また、この３段階を進めるためのコツを洗い出し、それらのコツをどういう作業局面で使うかで分類?整理しています。作業は次の４つに分類しています。 業務要件を、発注者が　「言い切り」、開発者が　「聞き切る」　コツ 開発者が「図表に書く」　コツ 開発者が内部レビューで「もれ／矛盾をチェックする」　コツ 発注者と開発者が　「一緒にレビューする」　コツ という４つの作業を重視しています。 続いては「合意成熟度のレベル」について解説します。 * 「合意成熟度レベル」とは、合意形成の進み具合を表してします。 「仕掛」、「充実」、「完成」の３つのレベルからなります。一般的には工程の初期、中盤、終盤に対応します。 また、この図は前のスライドで説明した４つの作業との対応を示しています。 最初の仕掛レベルでは、言い切る/聞き切る作業が中心です。 それが、充実レベルに進むにつれ、図表に書く作業やもれ/矛盾をチェックする作業が中心になります。 更に、完成レベルにな