ビジネス設計の勘所
『実践UML』などを翻訳された、依田さん。
時間短かったなあ。もっと長く聞きたかった。
ビジネス設計 = 要求開発である。
ビジョン分析をする。
プロジェクト目標設定書を作成する。
このとき、具体的な数値を設定する。
こうすることで(失礼だが)初めてお客様がイメージし始める。
要求開発の初期に作成する。
ユーザー以外の利害関係者(ステークホルダー)を調査し、意図を知る。
ビジネスのフロー、プロセスを書く。
どこから切り込めばいいか？
そのカテゴリの一般的な用語とユーザー独自の用語を対応付けて議論のきっかけにする。
フローを作成する。
ケースが多すぎて書けない？
大抵の場合商品やユーザーで例外フローがある。
基本フローをまず押さえる。
EA(Enterprise Archtect)や旧JUDE(astah*)で清書する。
アクターを定義する。
アクターとは役割である。
システムでまとめたいのは役割である。
人間は多重に役割を持つ。
役割で書いていくことが大切である。
ビジネスユースケース(ビジネスフロー全体図)。
ユースケースのシステム境界がビジネススコープとなる。ここが重要である。
ビジネスフロー図の一覧表を作成する。
大規模システムだとフローが大きくなるため、一覧にするとわかりやすい。
ドキュメント同士の関連性を大切にする(ドキュメント間で人間の翻訳を必要とさせないこと)。
ドキュメントの連続性を意識する。
ユースケースからビジネスフロー図を作成する。
要件を洗い出すことが大切であって、正確であることにこだわり過ぎない。
概念モデルが大切である。
概念モデル。
ユースケースに登場する概念だけをモデル化する。
後で作成する全体の概念モデルを楽に作成できる。ユースケース関で概念モデルを統合して作成すればよい。
概略技術スキーム。
概略ノード構成(ソフトウェアレイヤーやOSなどのハードウェアまで)
各ユースケースが通る技術ノードを把握する。
補助仕様書を作成する。
ライセンシングや保守性、ユーザビリティなど。
「網羅的で不整合であるよりも
コンパクトで整合性のある成果物を目指す。」
月に1回成果物間の同期を図る。
作業は「いつまでかかる」ではなく「月末までに何ができるか」を考える。
プロセスを中心にするとわかりやすいがコストがかかる。質も低くなる。
大阪ＮＤＳの挑戦〜現場からのレポート〜
レポートが網羅的ではあるけれども、
何を伝えたいのかハッキリしない内容になっていた。
少し厳しい言い方になっているけど…
企業色を薄くするとは言っていたけれど、
すごく企業色が強い発表だった。
もっとポイントを絞って、
改善行動とその結果をまとめて、
聴衆にどういう行動を起こしてほしいかというのを
熱く伝えればよいセッションになったのでは、と思う。
