システムプロジェクトは、システムを利用する発注者とシステムを開発する開発者との距離があり、意識があっていないときは、必ず失敗する。
発注者のシステムに対する要求・要件を、開発者が的確に把握し、システムの設計に反映できていないことが原因である。
それを防ぐには開発者は、発注者の考えをすべてコピーすればよいのかというとそうではない。発注者自身は、システムに対する要求・仕様を網羅的に理解しているわけではない。発注者は、日常実施している業務についてはほぼ理解しているが、異常系の処理やシステムも含めた運用全体からみた要件については十分理解しているわけではない。故に開発者は、発注者からのヒリアング結果を要件定義書に落とし、このようなケースの場合はどうするのかと発注者へ投げかけ、発注者に検討依頼する必要がある。このように発注者と開発者とのシステムの仕様を最終的に合意にするための検討の枠組み（フレームワーク）について大手Ｓｉｅｒ９社で作成したのが「発注者ビューガイドライン」である。
このガイドは、外部設計のコツを「画面」、「システム振舞い」、「データモデル」に分けて説明している。分かりやすくまとまっており、システムコンサルタント、上級ＳＥには必須の書籍である。
外部設計での発注者と開発者の認識を合意するときの留意点として以下があげられる。
① 発注者が日頃使っていることばや用語、図表を使わなければ
伝わらない。
② 発注者の価値観や要求と合致すれば理解され合意されやす
くなるが、合致しなければ受け入れられないか、抵抗される。
③ 発注者は期待することしか見ないし、聞かない。
④ ルールもなく、設計書をただ見せただけでは受け入れてもらえ
ない。
外部設計のコツを（1)システムの振舞い編、(2)画面編、(3)データモデル編に分けて説明している。外部設計とガイドラインの関係は以下のとおりである。
◆画面遷移・定義 ⇒ガイドライン画面編
◆業務ロジック ⇒ガイドライン画面編＋システム振舞い編
◆システム化した業務の流れ⇒システムの振舞い編
◆データベースの仕様 ⇒データモデル編
また、外部設計を、要件定義を詳細化し、内部設計へつないで行くための工程と位置づけ、外部設計を以下の３つの段階に分けている。
① 仕掛期：発注者の要求を開発者がもれなく聞きだし理解する。
② 充実期：工程成果物の品質を高める。
③ 完成期：承認に向け、発注者が適切な判断を与える。
(1) システム振舞い編
以下の作業ステップで、
① システム化業務一覧、
② システム化業務フロー、
③ システム化業務説明書を作成していく。
STEP１:主要なシステム化業務を洗い出す。⇒システム化業務一覧。
STEP2：システム化業務の流れを作成する。⇒システム化業務フロー。
STEP3：システム化業務の内容を仕様化する。⇒システム化業務説明書。
STEP4：工程成果物間の整合性を確認する。
システム化業務一覧を書くためのコツ。
コツ１：階層構造に分けて記述する。
大機能（発注業務）⇒中機能（発注書作成）
⇒小機能（発注書変更）
コツ２：システム利用作業に対応する利用者を記述。
システム化業務フローを書くためのコツ。
コツ１：人手の作業、システム化業務（システム利用作業、機能）に
分類して記述。
ｼｽﾃﾑ利用作業＝人とｼｽﾃﾑとのやり取りにかかわる業務。
機能＝システムによって自動化される業務。
コツ２：詳細を隠蔽して大きな流れを記述。
システム化業務フローを階層化して書く。
システム化業務説明書の作成のコツ。
コツ１：基本・代替・例外の３つのシナリオを考える。
基本＝正常処理
代替＝条件によって使い分ける場合。
例外＝業務上の例外的なシナリオ(特定の日だけの特別な
顧客処理)
コツ２：シナリオを利用者とシステムに分けて記述。
基本・代替・例外それぞれに対し、利用者の操作とシステムの
処理を分ける。
基本（利用者：受注入力画面を立ち上げる。ｼｽﾃﾑ処理：受注
入力画面を返す。）
工程間の整合性を確認する場合のコツ。
コツ１：システム化業務一覧とシステム化業務フローで、システム利用
作業の利用者の観点が合っているかを確認する。
利用する立場でシミュレーションすることにより利用範囲、仕
様の不整合を発見することができる。
(2) 画面編
画面に関する６つの成果物を作成する。
① 画面一覧
② 画面レイアウト
③ 画面遷移図
④ アクション明細
⑤ 入出力項目
⑥ 画面遷移・レイアウト共通ルール
画面レイアウトを合意するときのコツ
コツ１：画面上の情報配置を統一する。
「共通の画面部品を表示するエリア」「情報を表示するエリア」
「説明文を配置するエリア」「操作ボタンを配置するエリア」など
に分割。
コツ２：表の枠が固定か可変かに注意する。
検索結果表示が３列の場合、検索結果が１列の場合の表示、
４列の場合の表示をどうするかを明記する。
コツ３：入出力データは画面を見ながら仕様をつめる。
「どのデータの入力が必須か」「入力の条件は何か」
「データをどう出力するか」
コツ４：ボタンはボタンらしく記述する。
ボタンとテキストボックスの区別がつきにくい。ボタンには
影をつける。
コツ５：表示する文字列の役割を明確にする。
画面遷移図を合意するときのコツ
コツ１：画面遷移は上から下へ、左から右に遷移するように配置する。
コツ２：一つの画面で一つの処理が完結しない場合の面名は、業務
的に意味のある識別名にする。
そうでないと画面遷移上で実際の画面が想起しづらい。
コツ３：例外や条件分岐の書き方としては、業務のコトバで条件分岐
をきちっとかく。（内部変数等を書かない。）
あいまいさを取り除くレビューするときのコツ
コツ１：画面遷移、画面レイアウト、入出力項目の資料をレビューの
際に同時に参照できる別々の冊子として用意する。
コツ２：業務の流れ、画面遷移のレビューを実施してから画面レイ
アウトのレビューを実施する。
コツ３：レビューの際にエラー表示を具体的に説明し、表示の妥当性
判断に役立てる。
(3)データモデル編
データモデルで作成する成果物は以下の４つ。
①ＥＲ図
②エンティティ定義書 エンティティ名、属性名、型、長さ、制度、
必須、主キー、説明
③エンティティ一覧 エンティティ名」、エンティティ種別（リソース
／イベント）、定義
④ＣＲＵＤ図（エンティティのインスタンス）と機能
CREATE、READ、UPDATE、DELETE
・システム振る舞い編と画面編では打ち合わせごとに工程成果物の詳細度が高まる。
・開発者はデータモデル編でもレビューで工程成果物の詳細化を期待する。
・発注者はいきなりデータモデルをレビューすることに抵抗がある。
レビューを５回に分けて行う。
一回目：①エンティティ・属性の抽出、②データモデルの概要説明、
⑦業務量の確認
コツ１：データモデルの概要を業務や大きな機能レベルでまとめて、
エンティティの候補を確認する。
コツ２：扱うエンティティをグルーピング（イベント系、リソース系）した
資料を作成して確認する。
担当者をアサイン。業務間の連携を確認。
二回目：①エンティティ・属性の抽出、②データモデルの概要説明、
⑤業務とデータの関係の確認
コツ１：システムが扱う情報を俯瞰できる資料を作成し、システムが
扱う情報の範囲を確認する。業務フロー図利用
三回目：③データモデルの詳細説明、④データの変化の確認、
⑤業務とデータの関係の確認
コツ１：画面レイアウトとＥＲ図を対応づけて確認する。
四回目：③データモデルの詳細説明、⑥他システムとやりとりする
データの確認、⑦業務量の確認
コツ１：エンティティをリソース系とイベント系にタイプわけして、色付け
をする。
コツ２：イベント系エンティティをデータの発生順序でソートして記述。
システム化業務フローに沿ったデータの発生順が理解しやす
くなる。
コツ３：発注者への確認事項をＥＲ図にコメントとして直接記述し、
議論のポイントを明らかにする。
五回目：ＣＲＵＤ図を合意 ③データモデルの詳細説明、⑦業務量の
確認
コツ１：エンティティの作成、参照、更新と削除タイミングを確認ポイント
に絞って表で説明する。
確認したいサブシステムやエンティティなどを絞って、タイミングを
横軸に、エンティティ名とその作成、参照、更新と削除タイミングを
縦軸に表現する。
代表的なコツのみを上げてきたが、本の巻末に１８７個のコツの一覧
が出ている。
大変有益なノウハウなので、組織として使い込んでいくようにしたい。
0 件のコメント:
コメントを投稿