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

「機能要件の合意形成ガイド」とその開発背景 「機能要件の合意形成ガイド」って何？ 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するためのコツを集めたもの 事例１：わかりにくい設計書 事例：わかりにくい画面遷移ドキュメント ユーザの役割（一般ユーザ、サプライヤ、管理者）毎に、異なる遷移を表現しようと、以下の様な遷移図を持っていくと、お客様に「意味がわからない」といわれた。 事例１：わかりにくい設計書 何故、そのようなことになってしまったのか？ ユーザ役割毎に画面遷移順序が異なるにも拘わらず、１つの画面遷移ドキュメントに収めてしまったから。 事例１：わかりにくい設計書 適用できるコツ（書き方のコツ） 事例１：わかりにくい設計書 事例２：出来上がった画面遷移をレビューする 事例２：出来上がった画面遷移をレビューする 適用できるコツ（レビューのコツ） 事例３：発注者と一緒にレビューする 事例３：発注者と一緒にレビューする 適用できるコツ（レビューのコツ） 事例のまとめ（適用する上での注意事項） 取り上げたものは、「お客様との齟齬を防止するノウハウ」 ガイドにおいてはこのノウハウをコツと呼ぶ 「機能要件の合意形成ガイド」はこのようなコツが満載 コツについてケーススタディからわかること どの局面にも通用するわけではない コツの適用可能/不可能はプロジェクト（システム）の特性により異なる。 　（例えば、CRUD図は顧客納品物/レビューの対象ではない。） 唯一の解ではない たとえば、画面遷移の過不足をチェックする方法はこれだけではない コツは“森”ではなく“木”に近い 大局的な作業プロセスや、成果物構成などを規定するものではなく、特定の場面において役立つノウハウ（記述の仕方、振る舞い）。 事例１：例外業務システム処理の設計漏れ 事例：会計システムの振込処理における誤振込時の組戻し処理の漏れ 会計システムの振込処理において、誤振込が発生した場合、財務部が金融機関に連絡をした上で、振込データの戻しとこれに伴う会計処理（組み戻し処理）を行うことになっているが、会計システムでは組み戻し処理が設計されていなかった。 本番直前の運用テストの段階で財務部からの指摘で組み戻し処理が抜けている事が判明。急遽追加することになった。 事例１：例外業務システム処理の設計漏れ 何故、そのようなことになってしまったのか？ レビュー時に業務フローとシステム化業務フローを比較?検証しなかったから。システム化業務フローを見ていただけでは例外業務である組み戻し処理が抜けていることに気付かなかった。 事例１：例外業務システム処理の設計漏れ 適用できるコツ（言い切る／聞き切るコツ） 事例２：業務運用パターンの確認漏れ 事例２：業務運用パターンの確認漏れ 事例２：業務運用パターンの確認漏れ 適用できるコツ（レビューのコツ） 事例３：要求した画面イメージと異なる 事例３：要求した画面イメージと異なる 事例３：要求した画面イメージと異なる 適用できるコツ（言い切る／聞き切るコツ） 事例４：意図しない画面遷移 事例４：意図しない画面遷移 事例４：意図しない画面遷移 適用できるコツ（レビューのコツ） 事例５：無駄な類似した帳票の開発 事例５：無駄な類似した帳票の開発 事例５：無駄な類似した帳票の開発 適用できるコツ（言い切る／聞き切るコツ） 事例６：現場業務に精通しない担当者からの帳票要求 事例６：現場業務に精通しない発注者の帳票要求 事例６：現場業務に精通しない発注者の帳票要求 適用できるコツ（レビューのコツ） 適用事例のまとめ(1/3) 発注者が開発者に曖昧な要件を提示すると、出来上がるシステムは発注者が意図するものと異なるものとなる可能性が高くなる。 出来るだけ要件の曖昧さを排除し、開発者に正確に伝える事が肝要 言い切るコツの活用（特にコツID02T001）発注者はシステムに求めるイメージ、業務上のルール、仕事のやり方などを文書にとりまとめ、具体的に開発者に伝える。 発注者は開発者に要件を正確に伝えた心算でいても、正確に伝わっているとは限らない。 要件が正しく伝わっている事を確認する事が肝要 レビューのコツの活用 適用事例のまとめ(2/3) 適用事例のまとめ(3/3) まとめ * 少々手前味噌的ですが、ＷＧ参加の各社等での活用状況はこの表にまとめたとおりです。 * 例えば、 ベンダへ 設計書を作ることを目的としていませんか？ ユーザから聞いたことだけでシステムを作ろうとしていませんか？ 標準を定めた時の熱い情熱が冷めてはいませんか？ （機械的にドキュメントを作ることを奨励していませんか？