RDRAが生まれた背景を説明 課題は何で？　　何を解決したかったのか

1. RDRAはどう形作られたか？

2. • ㈱バリューソース 代表取締役
• 神崎 善司
• Facebook page：要件定義の散歩道
https://www.facebook.com/youkennotsubo?ref=hl
• twitter：@zenzengood
•仕事
• RDRA導入支援

3. RDRA策定前
• ２０００年頃
• オブジェクト指向のキーワードで仕事をしていた
• モデリング支援、アーキテクチャ設計支援～、要件のとりまとめ
• でも問題はほとんどはフワフワ要件といきなり詳細機能仕様にあった
• 仕様に先立つ要件レベルでの仕事に移行
• 毎週 毎週 次は何をすればいい？
• そのころ見かけたプロジェクトの問題

4. 要件を決められない
• 空中戦が多い
• 同じ議論が繰り返される
• 何が決まって、何が決まっていない
かはっきりしない
• 誰かが決めてくれると思っている
• 誰も決めない
• 有識者、リーダー、PM～が言ったこ
とが要件になる
• 会議のたびにスコープが変わる
• スコープ決めの根拠があいまい
• 認識が共有されていない
• 全体像を誰もわからない
• 詳細な資料しかない
• 企画書のキラキラワードを落とし込
めない
• 「何のために」が分からない
• 「解決すべき課題は何？」
• システムに先立つ業務が分からない
• 場面ごとの詳細なことならわかる
• 業務フローの単位が分からない

5. 要件定義の精度が悪い
• 管理中心の進め方
• ガントチャートで管理したがる
• 大量の文書が出来上がってもう修
正できない
• 「一つ一つを完成させる」ながら
進む
• 全体俯瞰なきイテレーション
• 手戻りが増え続ける
• 暫定仕様が増え続ける
• 「とりあえずこうしよう」
• 正式仕様の足場がない
• 要件として何を定義するの？
• 機能を定義している
• 正確に見積れない
• 要求一覧に１００以上の要求
• 大量の課題と要求にてんてこ舞い
• プロジェクトのメンバーで既存シ
ステムを知っている人がいない
• 週数時間有識者の時間が取れる
• 価値だ！ 責務だ！
• システムに還元できない

6. 何が求められたのか
• 期日までに終わらせる
• 限られた打合せの中でまとめら
れる考え方をもつ
• 精度を高める仕組みをもつ
• 「整合性はあっていますか」
• 「網羅していますか」
• 見積り根拠を明確にしたい
• いつでも容易に要件を変更したい
• 共通認識を得られるようにしたい
• 議論がかみ合うようにしたい
• 要件をシステマティックに定義し
たい

7. 何を実現するか
• 要件を決める仕組みをもつ
• 要件の根拠を説明できる
• 変更の影響範囲を把握できる
• 表現することを明確にする
• WhatとWhyを表現する
• Howは表現しない
• ビジネスを表現できる
• 業務フローの単位を決める考え方
を持つ
• ビジネスルールを表現できる
• 共通認識のための地図をもつ
• 限られた打合せの中で確実に要
件を定義する
• 見積り可能な要素をもつ
• 精度の高い要件が定義できる
• 仕様の足場とする
• 要件自体を分析可能にする
• ツールが使える

8. RDRAの構造
システム価値 システム境界 システム
外部システム
要求
アクター
システム外部環境
利用シーン
業務フロー
バリエー
ション
条件
業務
ビジネス
ユースケース
業務
業務
業務
アクティ
ビティ
画面
ユースケース
イベント
情報
状態
状態
遷移
依存
依存関係が要件の
決め方を決める
組
織
組
織
業務
組
織 業務
組
織
ビジネス
コンテキスト
ビジネスユースケース
業務フロー
情報モデル 状態モデル
BUCがわかるとボ
リュームが分かり、
計画が立てられる
限られた打合せの中で
確実に要件を定義する
要件を決める
仕組みをもつ
共通認識のため
の地図をもつ
ビジネスルールは条件、
状態モデルで表現
ビジネスを
表現できる
見積りはシステム境界
とシステムで測れる
見積り可能な
要素をもつ
情報と状態で
ユースケース
を整合させる
全てのアイコンがつなが
り、それが妥当な場合に
整合している考えられる
精度の高い要件
が定義できる
Why
Why
Why
表現すること
を明確にする
What