「こ・れ・だ・け」モデリングは  アジャイルをさらに加速する

株式会社　メソドロジック  山岸　耕二  

1

アジャイルとモデリング

•  アジャイルではモデリングは不要なのか？？  – アジャイルはドキュメントを書かない、だからモデリングはしない？  

– モデリングは開発を遅くする？  

•  エンタープライズ開発では・・  – 複数のシステムが複雑系を成して絡み合っている  – データの移行やらなんやら  – 複雑な業務を対象とする  

2

スプリントに入る前にやるべきことがたくさんある  モデリングなしでは効率的に行えない

現実的なエンタープライズアジャイル

ちゃんと業務を知る

保守・運用のための整備

一定のリズムで走る

ちゃんとアーキテクチャを固める

スプリント以前のモデリング

•  要求モデル  

•  業務をとらえる３種のモデル  – サービスモデル、概念モデル、業務フロー  

•  アーキテクチャモデリング  – 主要なパターン（設計クラス図とシーケンス図）とサンプルコーディング  

•  ユースケース一覧  – プロダクトバックログへの展開  

4

スプリント中のモデリング

•  詳細設計のモデルは省略する  – 設計者と実装者が同じ  – 詳細レベルはコードの方が表現できる  

•  コミュニケーションのためのメモとしてモデルを多用する  – 使い捨て前提  

5

言葉より素早いコミュニケーションでアジャイルを加速

リリース後、運用準備のモデリング

•  ポリシーによる（紙の形式か情報として残ればいいか）  •  主要クラスと主要動作のシーケンス図、特殊なアルゴリズム  

•  ユーザーストーリーの集約  •  ビジネスルールの整理だけは怠りなく  

6

要求獲得のためのダイヤグラム

•  ビジネスユースケース図（ユースケース図）  •  業務フロー図（アクティビティ図）  •  概念クラス図（クラス図）    

ビジネスユースケース図

概念クラス図 業務フロー図

システムユースケース図

設計クラス図

要求開発（BA)

システム開発

サービスモデル

静的モデル 動的モデル

何をするか

何がどうあるか どう動くか

データ設計図

「これだけ」ビジネスユースケース図の例

サブジェクト

ビジネスアクター

ビジネスユースケース

関連

汎化関係

包含関係  include

「これだけ」業務フロー図の例

アクション

初期ノード

最終ノード

フォーク

ジョイン

分岐

マージ

「これだけ」概念クラス図の例

引出しと共通理解のための概念モデル

•  業務理解の概念モデルでアナリシスパターンを描かない  – 抽象化しすぎるとかえって特徴がわからない  

•  概念モデルを引きずりすぎない  – 使い捨ててもいい  – プロセスが重要（引出しのツール）  – 無理なトレーサビリティを求めない  

•  設計では別の概念が入ってきて折衷できないことが多い  •  共通に認識している＆残像がある　でOK  

共通の残像が醸成できれば十分な効果が望める

ビジネスモデリングの効用（よくある感想）

•  モデルを描く過程で不足情報を効率よく引き出せた •  個々人がそれぞれに持っていた業務のイメージの違いがよく認識できた。共通認識としてまとめることができた。

•  話し合いだけでは詰め切れなかった曖昧なところを明確にできた

•  何となく色々に使っていた言葉をきっちり定義できた •  関係する業務を広めに議論したことで、システム化スコープの輪郭をはっきりとつかむことができた

•  システムイメージが浮かび上がってきた •  データ構造がおおまかに見えてきた

まとめ

アジャイル開発をさらに円滑に進めるために    

　アジャイルな「こ・れ・だ・け」モデリングを

13