シリーズ: モデルベース要件定義手法RDRA
- 要件定義手法RDRAの概要と全体像
- RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
- RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
- RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける（本記事）
- RDRAによる要件定義の進め方〜第3フェーズ（２）：整合性を確認し、精度を高める
- RDRAの成果物と設計プロセスとの連携
- RDRA Agentの紹介（近日公開予定）
- RDRAと見積（近日公開予定）
TRACERYプロダクトマネージャーの haru です。
RDRAの要件定義は、思考を段階的に深めていくために、3つのフェーズに分けて進めます。
第1フェーズでは、RDRAモデルの枠組みとなる要素を定義します。
第2フェーズでは、「システム要件定義」に該当するシステム境界レイヤーおよびシステムレイヤーを中心に具体化します。
第3フェーズでは、システムレイヤーの要素同士を関連付け、要素間の関係を確定させます。そのうえで、定義内容全体に抜けや矛盾がないかを横断的に検証します（下図）。
第3フェーズまで終了することで、要件の「仕様化」が可能になります*1。
要件の「仕様化」とは、要件を具体的な仕様へと落とし込むことです。
仕様とは、要件定義で抽出された開発品目について、開発者が実装をイメージできるレベルまで、インターフェース仕様や処理ロジックを明確にしたものを指します。
たとえば、要件定義で「会員登録」画面という開発品目が抽出された場合には、「会員登録」画面の具体的なレイアウト、画面項目の配置、各項目の振る舞いを定義します。
この記事では、第3フェーズのうち「システムレイヤーの要素同士の関連付け」の具体的な進め方を説明します。
バリエーションを洗い出す
バリエーションとは、ビジネス上あらかじめ定義された区分を持ち、対象をどの観点で分類するかを定めるモデル要素です。
たとえば「会員種別」は、会員をどの種類に分けて扱うかを示す分類の軸です。
そして、「大人」「子供」といった具体的な区分が、その分類の軸に属するバリエーションの値です。
バリエーションが表すのは、名称による種別だけではありません。ビジネスルールの詳細条件を示す区分も、バリエーションに含まれます。
たとえば、遅延日数に応じて取扱いを分ける場合には、遅延日数が3日未満、7日未満、7日以上といった数値条件による区分を定義します。
バリエーションと状態の違い
RDRAでは、「バリエーション」と「状態」を明確に区別します。両者は似ているように見えますが、モデル上の役割が異なります。
状態とは、対象が時間の経過や業務プロセスの進行に伴って取り得る状況を指します。会員であれば、「仮登録」「登録済」「退会」などが状態です。
状態は業務の流れの中で変化し、遷移という振る舞いを持ちます。
一方、バリエーションは分類の概念です。対象の種類の違いや、ビジネスルールの詳細条件を表します。
分類の軸（バリエーション）と、時間変化の軸（状態）を明確に区別することで、業務理解を安定させ、設計の精度を高める前提になります。
バリエーションの定義
バリエーションは、「バリエーション」シートに記載します（下図）。
バリエーションが持つ複数の値は、「値」列に「、」区切りで記載します。
情報の精度を上げる
情報とは、システムが扱う概念的なデータとその関係のことです。
情報を、バリエーションや状態モデルと関連付けることで、その情報がどのような区分を取り得るのか、またどのように変化していくのかを明確にできます。
結果として、データ定義とビジネスルールの対応関係が明確になります。
情報とバリエーションを関連付ける
情報が取り得るバリエーションを、「情報」シートの「バリエーション」列に記載します（下図）。
上記のシートでは、「会員」という情報が「会員種別」というバリエーション（大人、子供）を取り得ることを明示しています。
RDRA Graphで確認すると、「会員」という情報と「会員種別」というバリエーションが関連付けられていることが可視化できます（下図）。
情報と状態モデルを関連付ける
情報が取り得る状態を定義した状態モデルが存在する場合は、その名称を「情報」シートの「状態モデル」列に記載します。
記載することで、その情報がどのような状態遷移を持つのかが明示されます。
RDRA Graphで確認すると、「蔵書」という情報が「蔵書の状態」という状態モデルと関連付けられていることがわかります（下図）。
条件の精度を上げる
「条件」とは、業務上またはシステム上で適用されるビジネスルールを指します。
条件と関連要素との対応関係を明確にすることで、どの要素がどの条件によって規定されるのかが整理され、ビジネスルールの解釈の揺れを防ぎ、定義の精度を高めることができます。
条件とバリエーションを関連付ける
ビジネスルールに基づいて結果を判定する際に、その判定の軸となるバリエーションを「条件」シートの「バリエーション」列に記載します（下図）。
上記のシートでは、「会員種別」と「遅延日数」をバリエーションとして記載しています。これは、ビジネスルールの結果が、これら二つの分類軸の組み合わせによって決まることを示しています。
この場合、縦軸を「会員種別」、横軸を「遅延日数」として整理すると、下表のような構造になります。
各マスは、バリエーションの組み合わせごとに適用されるビジネスルールの結果を表しています。
| 会員種別＼遅延日数 | 3日未満 | 7日未満 | 7日以上 |
|---|---|---|---|
| 大人 | 制限なし | 1冊制限 | 貸出不可 |
| 子供 | 制限なし | 貸出不可 | 貸出不可 |
このようにバリエーションを明示することで、ビジネスルールを構造として捉えることができ、条件の抜け漏れや重複を検証しやすくなります。
RDRA Graphで確認すると、「貸出制限」という条件が「遅延日数」と「会員種別」というバリエーションと関連付けられていることがわかります（下図）。
条件と状態モデルを関連付ける
ビジネスルールに基づいて結果を判定する際に、その判定の軸となる状態モデルを「条件」シートの「状態モデル」列に記載します（下図）。
上記のシートでは、「蔵書の状態」を状態モデルとして記載しています。
これは、ビジネスルール「貸出予約一覧出力条件」の結果が、「蔵書の状態」によって決まることを示しています。
RDRA Graphで確認すると、「貸出予約一覧出力条件」という条件が「蔵書の状態」という状態モデルと関連付けられていることがわかります（下図）。
最後に
第3フェーズとして、システムレイヤーの要素同士の関連付けを説明しました。
バリエーション、状態、情報、条件を結び付けることで、「どの情報にどの分類軸が適用されるのか」「情報がどの状態遷移を持つのか」などが構造として明らかになります。
この関連付けにより、開発対象となるシステムモデルの網羅性が高まります。
RDRAの要件定義は、要素同士の関係を設計し、構造として意味を持たせることが重要です。
システムレイヤーまで関連付けが完了したモデルは、静的な構造（情報、状態、条件、要素同士の関連等）と動的な振る舞い（状態遷移、条件による分岐）の整合が取れた状態となるため、解釈のずれを生むことなく、そのまま仕様へと展開できる設計基盤となります。
次回は、第3フェーズの後半として、モデル全体を見直し、矛盾を解消して整合性を高める取り組みについて説明します。
参考書籍
*1:参考書籍のRDRA3.0 ハンドブック: 根拠を持った要件定義を素早く正確にでは、フェーズ3は、プロジェクトの状況や後続プロセスによっては、必ずしも実施する必要がない旨が記載されている。
