Fight the Future

Java言語とJVM、そしてJavaエコシステム全般にまつわること

要求開発アライアンス西日本勉強会#2に行ってきた。

ビジネス設計の勘所

『実践UML』などを翻訳された、依田さん。

時間短かったなあ。もっと長く聞きたかった。


ビジネス設計 = 要求開発である。

ビジョン分析をする。


プロジェクト目標設定書を作成する。

このとき、具体的な数値を設定する。

こうすることで(失礼だが)初めてお客様がイメージし始める。

要求開発の初期に作成する。

ユーザー以外の利害関係者(ステークホルダー)を調査し、意図を知る。


ビジネスのフロー、プロセスを書く。

どこから切り込めばいいか?

そのカテゴリの一般的な用語とユーザー独自の用語を対応付けて議論のきっかけにする。


フローを作成する。

ケースが多すぎて書けない?

大抵の場合商品やユーザーで例外フローがある。

基本フローをまず押さえる。

EA(Enterprise Archtect)や旧JUDE(astah*)で清書する。


アクターを定義する。

アクターとは役割である。

システムでまとめたいのは役割である。

人間は多重に役割を持つ。

役割で書いていくことが大切である。


ビジネスユースケース(ビジネスフロー全体図)。

ユースケースのシステム境界がビジネススコープとなる。ここが重要である。


ビジネスフロー図の一覧表を作成する。

大規模システムだとフローが大きくなるため、一覧にするとわかりやすい。

ドキュメント同士の関連性を大切にする(ドキュメント間で人間の翻訳を必要とさせないこと)。

ドキュメントの連続性を意識する。


ユースケースからビジネスフロー図を作成する。

要件を洗い出すことが大切であって、正確であることにこだわり過ぎない。

概念モデルが大切である。


概念モデル。

ユースケースに登場する概念だけをモデル化する。

後で作成する全体の概念モデルを楽に作成できる。ユースケース関で概念モデルを統合して作成すればよい。


概略技術スキーム。

概略ノード構成(ソフトウェアレイヤーやOSなどのハードウェアまで)

ユースケースが通る技術ノードを把握する。


補助仕様書を作成する。

ライセンシングや保守性、ユーザビリティなど。


「網羅的で不整合であるよりも

コンパクトで整合性のある成果物を目指す。」


月に1回成果物間の同期を図る。

作業は「いつまでかかる」ではなく「月末までに何ができるか」を考える。


プロセスを中心にするとわかりやすいがコストがかかる。質も低くなる。


大阪NDSの挑戦〜現場からのレポート〜

レポートが網羅的ではあるけれども、

何を伝えたいのかハッキリしない内容になっていた。

少し厳しい言い方になっているけど…


企業色を薄くするとは言っていたけれど、

すごく企業色が強い発表だった。


もっとポイントを絞って、

改善行動とその結果をまとめて、

聴衆にどういう行動を起こしてほしいかというのを

熱く伝えればよいセッションになったのでは、と思う。