■ 1. イベントストーミング
- 付箋を使って業務の流れを可視化するワークショップ形式の手法
- 業務が複雑で関係者の認識がバラバラな場合に活用する
- 壁やホワイトボードに大きな紙を貼り、業務の出来事を時系列に配置する
- 要素と役割（色分け）:
- ドメインイベント（オレンジ）: 業務上の事実を過去形で表現し主役となる
- コマンド（青）: イベントを引き起こす操作（例: 「予約する」）
- アクター（濃黄）: 操作実行者（利用者、管理者など）
- 集約（薄黄）: コマンドが作用する対象のまとまり
- ポリシー（紫）: 「イベントが起きたら次に何をするか」という業務ルール
- 外部システム（ピンク）: 連携先システム
- リードモデル（緑）: 判断時に参照する情報・画面
- ホットスポット（赤）: 疑問・対立・未確定の論点
- 基本フロー:
- アクターがコマンドを実行する
- コマンドが集約に作用する
- 集約がドメインイベントを生む
- ポリシーが反応して次のコマンドを呼ぶ
- 3段階の深掘り:
- ビッグピクチャー: ドメインイベントのみを時系列配置し業務全体を俯瞰
- プロセスモデリング: コマンドなど他要素を加え因果関係を詳化
- ソフトウェアデザイン: 集約中心に実装意識で粒度を落とす
- メリット:
- 早期に業務全体像とズレを発見できる
- 開発者だけでなく業務担当者も参加し認識を統一できる
- 例外パターンや論点が自然と可視化される
- デメリット:
- 正式な仕様書は完成しない
- 初期段階の業務理解地図に留まる
■ 2. RDRA
- 要件を関係性で整理するための手法
- イベントストーミング後に要件を体系的にまとめる際に活用する
- 4つのレイヤー構造（上から下へ）:
- システム価値: 利用者・外部システム・システム必要性を明確化
- システム外部環境: 業務フロー・利用シーンを描写
- システム境界: 画面（バウンダリ）・機能（ユースケース）
- システム: 扱う情報・状態変化・条件・バリエーション
- 上のレイヤーが下のレイヤーの「なぜ必要か」を説明する入れ子構造を持つ
- 各層がすべて上層にたどれるようにつながる
- メリット:
- 「なぜその機能が必要か」が可視化される
- 機能を並べても見えにくい業務とのつながりを明確にする
- 要件同士の関連性が明確になり抜け漏れを発見しやすい
- デメリット:
- 最初は型に慣れる必要がある
- 複雑に見える可能性がある
■ 3. ICONIX
- 要件から設計・実装へつなげるための手法
- 画面・処理・データ・オブジェクト責任を整理する
- ユースケース（利用者がシステム使用で何かを達成する一連の流れ）を中心とする
- ロバストネス分析（ユースケースと設計間の曖昧さを減らす工程）:
- バウンダリ（境界）: 利用者が触れる画面・入り口
- エンティティ: 扱うデータ（予約、空き枠など）
- コントロール（制御）: 処理・ロジック
- 基本ルール:
- 利用者は画面としか話せない
- 画面とデータは直接つながらず必ず処理を経由する
- 実施プロセス:
- ユースケースをロバストネス分析で図化する
- 文章では読み飛ばしていた抜けが図にすると可視化される
- シーケンス図・クラス図へ落とし込む
- メリット:
- 要件からコードまでのつながりが見えやすい
- 曖昧さが図で可視化される
- デメリット:
- 業務探索には向かない
- 初期段階では不適切
■ 4. 3つの手法の使い分け
- 業務全体像が見えていない場合: イベントストーミングを選択
- 要件の抜け漏れ・矛盾を減らしたい場合: RDRAを選択
- 要件を設計・コードにつなげたい場合: ICONIXを選択
- 実務では単体よりも組み合わせが効果的
■ 5. DDDとの連携フロー
- イベントストーミングで出来事を洗い出す
- RDRA + DDD同時進行で状態・パターンを体系的に整理する
- DDDの設計に落とし込む（特にアプリケーション層設計にRDRA情報が重要）
- 注意点:
- イベントストーミングが浅いまま設計へ進むと行き詰まる
- RDRAを「後付けの清書」にせず矛盾発見とDDDへの情報提供に活用する
■ 6. その他の関連手法
- ユーザーストーリーマッピング: 体験を時系列化
- BPMN: 業務フロー図化
- 要求分析ツリー: 目的から手段へ掘り下げ
- 新手法導入前に確認すべき事項:
- 手法の概要
- 使用可能な場面
- 解決する悩み
- 前後工程との接続方法
■ 7. 推奨フローとまとめ
- 要件定義プロセスの推奨順序:
- まず業務を理解する（イベントストーミング）
- 次に要件を整理する（RDRA）
- 最後に設計へつなげる（ICONIX）
- 初心者はイベントストーミングから開始することが推奨される
- 関係者集約が難しい場合や業務が見える場合はRDRAから進めてもよい
- 理想的フロー: イベントストーミングでイベント洗い出し→RDRAで状態やパターン整理→DDDの設計へつなげる
- 3手法を組み合わせることで、要件定義がドキュメント作成から業務理解と良設計実現のプロセスへ昇華する