rdra4 ddd

RDRA for DDD

短期間にシステムの全体像をつかむ

2017/4/12

1

わたしは…

㈱バリューソース代表取締役社長

神崎善司

[email protected]

要件定義の散歩道：https://www.facebook.com/youkennotsubo

twitter：@zenzengood

要件定義手法の開発

RDRA Relationship driven requirement analysis

普段はシステム企画・要件定義などの支援

既存システムの可視化支援

セミナー開催（要件定義、モデリング）

要件定義用ツールの開発

2

mailto:[email protected]

なんでこうなるのか？

RDRAができた背景

XXXXXXX

XXXXXXXXXX

XXXXXXXXXXXXXXXXXXX

AAAAAAAAAAAAAAAAAAAAAAAAA

日付

担当者A担当者B

担当者B担当者A

タスク

担当者

この方向に圧縮する思考になる

変更の影響が大きい

早い段階から個人ワークが始まる

辻褄が合っていない大量のドキュメント

誰も説明できない

要件を変えたくてもどこに影響が出るか分からない

要件定義の途中から要件が変えられなくなる

RDRA for DDDのスタンス

4

RDRAとドメインモデルの関係

RDRAは本来開発方法を選ばない Howは扱わない

RDRA for DDDのスタンス

深い分析は開発側（ドメインの分析）に任せ、RDRAは整合のとれた要件を定義することに徹する RDRA 広く浅く分析

ドメイン分析深く分析

ガツンと中心となる概念をつかんで、育てていく

RDRA Domain

RDRAが外から攻め

ドメインモデルが中核から攻める

ドメインモデル RDRA

広く網を張り徐々に固めていく

5

RDRAで枠組みを決める

6

RDRAの役割構成要素の洗い出し深い分析のための構成要素を洗い出すスコープ決め構成要素をつなげスコープを見極める分類コンテキストの見極め、業務分類の見極め

全体の枠組みを押さえながら進める

RDRAで外枠を固めて安定したサイクル（タイムボックス）が回るようにする

タイムボックスで育てていく

要求側・開発側

7

通常中規模以上のプロジェクトでは要求側（情シス）と開発側（ベンダー）は分かれる契約形態やスキルセットなどの要因で別れる

要求側開発側

要件定義

開発計画プロトプロト

構築

分析設計実装テスト





プロト

継続的インテグレーション

受入テスト要求側

開発側

アーキテクチャ構築Or

先行開発

フィードバック

プランニングのベース

• 要件を固めるまでに試行錯誤がある• ステークホルダーの意見調整に時間がかかる

• 多くの場合要求側はソフトウェアエンジニアに慣れていない

• 決まったことを教えてほしい• 情報の詳細度ではなく決めたことを教えてほしい

要件と開発の両輪でまわす要件定義と開発の両輪で回す

要求側 ⇒ RDRAの構成要素を洗い出し、分類とスコープを識別する

開発側 ⇒ 中核となる概念を中心に深い分析を行う

２つのチームが外側と内側から並行して進める

開発

要件定義

計画プロトプロト

構築






受入テスト

プロト


要求側（情シス）

開発側

8

RDRA

ドメインモデル

RDRAとは

RDRA：Relationship driven requirement analysis

要件定義の仕組み

9

要件定義には何を定義すればいいのか

システム

もの

サービス

機能

データ

機能

機能

利害関係者

ユーザ

外部システム

業務

RDRAでは「要件定義の対象をシステムとシステムを取り巻く環境」と考える

システムを取り巻く環境

システム

要件定義書

10

要件定義では何が定義されないといけないのか

システム

もの

サービス

機能

データ

機能

機能

利害関係者

ユーザ

外部システム

業務

•その機能が使用するデータは？

•システムに必要な機能は？

•その時の入出力情報は？

•システムとの接点は？

•どのようにシステムは使われるのか？

•どのような人、外部システムと関わるのか？

•このシステムの目的（価値）は？

11

もの

サービス

システム価値

ものサービス利害関係者

ユーザ

要件定義の構造を定義する

システム外部環境

外部システム

システム

機能

データ

機能

機能

利害関係者

ユーザ

外部システム

システム

システム境界

機能データ

機能

•システム価値

•システム外部環境

•システム境界

•システム

要件定義の構造

12

システム価値

ものサービス

利害関係者

ユーザ

要求

価値

外部システム

要件分析の枠組み構成要素

１．【システムの価値】を捉える

•対象業務に関わる人を洗い出す•関係する外部システムを洗い出す•要求を捉える

２．【システム外部環境】を捉える

•対象業務の流れを捉える•対象業務に関わる概念を明らかにする•システムの利用シーンを明らかにする

３．【システム境界】を捉える

•ユーザインターフェースを明らかにする•外部システムとのインターフェースを明らかにする

４．【システム】を定義する

•機能を明らかにする•データを明らかにする•ドメインの構造を把握する

システム外部環境

システム

機能データ

機能

システム境界

利用シーン

13

コンテキストモデルからシステム境界まで

１．対象業務に関わる人と外部システムを把握する

clas s システムコンテキスト

業務名

<<システム>>Xxxxシステム

システム主体者１システム主体者２

システム主体者３

システム主体者４

業務主体者５

外部システム

コンテキストモデル

要求モデル

外部システム

人（アクター）

システム

要求要求

要求

２．下記関係者の要求を把握する

４．業務の中でシステムが関わる部分を把握する

３．業務を組み立てる

uc ユースケース

ＸｘｘｘをＹｙｙｙする

ＸｘｘｘをＷｗｗｗする

ＵｕｕｕをＬｌｌｌする

システム主体者１

システム主体者２



KkkkkをXする

OをOnnnnする

業務モデル

対象業務に関わる人と外部システムを要件定義の起点とする

イベントモデル

プロトコルモデル

５．外部システムとのイベントを捉える

６．外部システムとのプロトコルを整理

同じように利用シーンからユースケースを導き出す 14

ユースケースから機能、データまで

システム

７．ユースケースに関わるユーザーインターフェーズを洗い出す

uc ユースケース

ＸｘｘｘをＹｙｙｙする

ＸｘｘｘをＷｗｗｗする

ＵｕｕｕをＬｌｌｌする

システム主体者１

システム主体者２



KkkkkをXする

OをOnnnnするイベントモデル

プロトコルモデル

８．ユースケースを実現する機能を洗い出す

cus t om 画面モデル

<<画面>>商品登録画面

- 商品名- 取引先- 荷姿- 発注単位- 商品カテゴリ

<<画面>>販売状況照会

- 月- 商品カテゴリ

<<画面>>発注登録

- 商品- 発注日- 発注数量- 入荷予定日

<<画面>>商品説明

- 商品カテゴリ

<<画面>>カート処理

- 受注番号

<<画面>>受注照会

- 顧客名- 受注日

商品売上詳細

- 商品- 売上数量- 売上金額

詳細説明

- 商品説明

カート内商品

- 商品- 数量

<<画面>>決済処理

- 顧客名- 住所- 決済方法

受注商品

- 商品- 受注数量

画面帳表モデル

act 機能モデル

<<funct ion>>Uuuu機能

<<funct ion>>Zz z z機能

<<funct ion>>Ｘｘｘｘ機能

<<funct ion>>Ｙｙｙｙｙ機能

機能モデル

act 機能モデル

<<funct ion>>Uuuu機能

<<funct ion>>Zz z z機能

<<funct ion>>Ｘｘｘｘ機能

<<funct ion>>Ｙｙｙｙｙ機能

clas s データモデル２

<<datamodel>>AAAＸｘｘｘ

- xxx11: int- xxx12: int- xxx13: int

Ｘｘｘｘ

<<datamodel>>AAAＸｘｘｘ１

- x1xx11- x1xx12- x1xx13

<<datamodel>>AAAＹｙｙｙ

- yyy1- yyy2- yyy3

Ｕｕｕｕ

- uuu1- uuu2- uuu3

<<datamodel>>AAAＪｊｊｊ

- jjj1- jjj2- jjj3

<<datamodel>>AAAＯｏｏｏ

- eeee1: int- eeee2: int- eeee3: int

Ｘｘｘｘ

<<datamodel>>AAAＸｘｘｘ２

- x2xx1- x2xx2- x2xx3

ＸｘｘｘＸｘｘｘ３

- x3xx1- x3xx2- x3xx3

データモデル

９．アクションを機能に対応付ける

画面・ユースケースモデル

ユースケースモデル

機能モデル

システム境界

１０．データを洗い出す

１１．機能とデータを付き合わせる

機能複合モデル

15

システム価値システム外部環境システム境界システム

ＵＣ：ユーケース

全ての情報をつなげる

コンテキスト

利用シーン

業務

イベント

ユースケース概念

画面・帳表

機能

データ

要求


利用シーン＆ＵＣ

業務＆ＵＣ

状態

ＵＣ＆画面

ＵＣ＆機能

プロトコル

16

各要素がつなげる

17

画面

ユースケース機能

データ・ドメイン

外部システムイベント

要求

関係が整合性、網羅性を確保する

システム地図の構成要素

利用シーン

システム価値システム外部環境システム境界システム

ＵＣ：ユーケース

RDRA for DDD

コンテキスト

利用シーン

業務フロー

イベント


要求

状態

プロトコル

オプション

オプション

UC

情報or

情報

画面

イベント

「システム境界」の詳細化と「システムの分析」は開発側に任す

18

データではなく情報

ユースケースを安定させるために「情報」を活用

状態遷移をユースケースに対応させてもよい

業務フローか利用シーンのどちらか

業務フローか利用シーンごとに機能複合モデルを作る

情報の構造化はしなくてよい、構造化はドメインモデルで行う

現場で認識している状態を明示することが大事

ビジネスユースケースと捉えてもよい

要求側と開発側でのモデルイメージ

19

要求側：広く浅く分析するためのモデル

開発側：深く分析するためのモデル

要件定義受入テスト

開発計画プロトプロト分析設計実装テスト





プロト

ドメインロバストネス図

機能連携図

UC

状態

状態遷移図

コンテキスト業務フロー

要求利用シーン

ビジネスルール

XXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXX

シナリオ

XXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXX

シナリオ

要求側

開発側

RDRA for DDD システム地図

要件としての整合性、網羅性を確保する

システム地図の構成要素

画面

ユースケース

情報

外部システム

イベント

利用シーン

20

要求側と開発側の関わりイメージ

21

開発側のイテレーションに要求側メンバーが関わるイテレーション毎の分析で要求側メンバーと深く分析する

分析

要求側と開発側の密なコミュニケーション

シナリオ

状態遷移図

ドメインモデル

要件定義

開発計画プロトプロト

構築






プロト


要求側

設計・実装・テスト

開発側

要求側開発側

受入テスト

フィードバック

要件の深堀

RDRA for DDDの適用

22

変化に耐えられる軸

軸があれば変化してもぶれない要件定義軸：RDRA 広く浅い分析

開発軸：ドメインモデルコンテキスト単位の深い分析

開発

要件定義

プロト非機能要求

プロトプロト

構築

分析設計実装

分析設計実装

分析設計実装

分析設計実装

分析設計実装

受入テスト非機能要求

要件定義の軸

開発の軸

23

網羅は全てを洗い出すことではない

24

網羅性が必要な理由 ✖ 詳細な一覧ができたら開発できる

○ 全体を俯瞰できる主要な構成要素が見えたら開発を開始できる

開発

要件定義非機能要求

アーキテクチャ構築Or

先行開発

構築

受入テスト

～

計画

主要な構成要素が見えた

計画計画計画計画計画計画計画

開発イテレーションスタート

一覧

RDRAで要件の整合を維持する

開発

要件定義

計画プロトプロト

アーキテクチャ構築 Or 先行開発

構築






受入テスト

プロト

RDRAが開発のタイムボックスを回していく地図となる

広く浅く分析

深い分析

25

まとめ

26

頭のなかを可視化

RDRA for DDDの構成要素

画面

ユースケース

情報

外部システム

イベント

利用シーン

メンバーの頭の中を可視化し、統一した要件としてまとめる

27

RDRAの弱点

ビジネスルール、シナリオを整理する枠組みが未整理

開発

要件定義

プロト非機能要求

プロトプロト

構築

分析設計実装

分析設計実装

分析設計実装

分析設計実装

分析設計実装

受入テスト非機能要求

スムーズにイテレーションを回すためにはビジネスルールの明確化がタイムリーに必要

28

ビジネスルールの整理の手順

シナリオの洗い出し

29

RDRA ワークショップ 2017/4/18

２時間でシステム地図を作成する

やっぱり手を動かさないとわからない

30

rdra4 ddd

Engineering