シリーズ: モデルベース要件定義手法RDRA
- 要件定義手法RDRAの概要と全体像
- RDRAによる要件定義の進め方〜フェーズ1：枠組みを作る（本記事）
- RDRAによる要件定義の進め方〜フェーズ2：要件を組み立てる（近日公開予定）
- RDRAによる要件定義の進め方〜フェーズ3：整合性・網羅性を確認し精度を上げる（近日公開予定）
- RDRAの成果物と設計フェーズとの連携（近日公開予定）
- RDRA Agentの紹介（近日公開予定）
- RDRAと見積（近日公開予定）
TRACERYプロダクトマネージャーの haru です。
RDRAによる要件定義は、要件を個別に整理するのではなく、まず全体の構造を明らかにし、その上で要素同士の関係性を定義しながら段階的に具体化していく点に特徴があります。
そのため、要件定義は主に次の3つのフェーズに分けて進めます。
- フェーズ1：枠組みを作る（議論の土台作り）
- フェーズ2：要件を組み立てる
- フェーズ3：整合性・網羅性を確認し、精度を高める（要件定義の仕上げと仕様化の準備）
なかでもフェーズ1は、後続フェーズで扱う要件の方向性やスコープを定める重要な段階です。
ここで認識のずれや抜け漏れがあると、以降の要件定義全体に影響を及ぼします。
本記事では、このフェーズ1に焦点を当て、RDRAを用いて枠組みをどのように構築していくのかを具体的に説明します。
フェーズ1の進め方の概要と目的
フェーズ1では、RDRAモデルの枠組みとなる要素を定義します。
- システム価値レイヤー
- 機能要求、非機能要求
- アクター
- 外部システム
- システム外部環境レイヤー
- 業務
- ビジネスユースケース（BUC）
- アクティビティ
- システム境界レイヤー
- ユースケース（UC）
- システムレイヤー
- 情報
- 状態
定義は、システム価値レイヤーから始め、システム外部環境レイヤー、システム境界レイヤー、システムレイヤーの順に、左から右へ進めます。
フェーズ1の目的は議論の土台を作ること
フェーズ1の目的は、システム化対象となる業務全体とシステム化の範囲を早期に可視化し、関係者間で共通認識を形成するための「議論の土台」を整えることです。
そのため、このフェーズでは詳細な正確さには踏み込まず、後続フェーズでの精緻化を前提として、対象となる要素を漏れなく洗い出すことを重視します。
参考書籍『RDRA3.0 ハンドブック: 根拠を持った要件定義を素早く正確に』では、フェーズ1は時間をかけすぎず、スピーディーに要素を洗い出すことを重視すると述べられています。そのため、以下のような目安で時間を配分することが推奨されています（下表）。
| フェーズ | 内容 | 時間の割合 | 1か月(20日)の場合 |
|---|---|---|---|
| 1 | 枠組みを作る | 10% | 2日 |
| 2 | 要件を組み立てる | 60% | 12日 |
| 3 | 整合性・網羅性を確認し精度を上げる | 30% | 6日 |
システム価値レイヤーを定義する
第1フェーズでは、システム価値レイヤーを構成するすべての要素（機能要求、非機能要求、アクター、外部システム）を対象とします。
これら、システムが「何の価値を提供するのか」を表す要素を最初に明らかにすることで、以降の要件定義を進めるための明確な起点を定めます。
機能要求、非機能要求を記載する
要件定義の開始時点で、すでに明らかになっている機能要求および非機能要求を、「機能要求」シートと「非機能要求」シートに記載します。
これら2つのシートに記載された内容は、他のRDRAシートとは関係付けられず、RDRA Graphにも反映されません。
本シートの目的は、要件定義を進める過程において、開発にあたり前提となっている大きな要求を立ち戻って確認できるようにすることです。
具体的な機能要求は、RDRAの他のシート（例：「BUC」シートにおけるユースケースや画面）として定義されるため、本シートには詳細な要求は記載しません。
そのため、システムが目指すべき方向性を示す観点から、特に重要な要求のみに絞って記載します。
上図の「機能要求」シート、「非機能要求」シートの「アクター」には、ヒアリングなどで要求を出したアクターの名前を記載します。
アクターをリストアップする
システムに関わる人の役割（アクター）を「アクター」シートに定義します。
アクターをリストアップすることで、後続の定義において、業務やアクティビティについて、誰の役割として行われるものか、システムで支援すべき作業か、どの立場の利用を想定したユースケースかを判断できるようになります。
外部システムをリストアップする
関係する外部システムを「外部システム」シートに記載します。
第1フェーズでは詳細なインターフェース設計には踏み込まず、社内の他システムや外部サービスとの連携有無と関係性を整理します。
これにより、どの機能を自システムで担い、どの機能を外部システムに委ねるのかを判断できるようになり、後続のユースケース定義や外部インターフェースの検討を円滑に進められるようになります。
システム外部環境レイヤーを定義する
第１フェーズでは、システム外部環境レイヤーを構成するすべての要素（業務、ビジネスユースケース、アクティビティ）を対象とします。
ただし、第１フェーズの目的は、システムの全体像を明らかにし、関係者間で共通認識を形成するための「議論の土台」を整えることにあるため、すべての要素を正確に洗い出す必要はありません。
業務やビジネスユースケースを洗い出すことで、システム化対象のスコープがおおよそ把握できれば、このフェーズの目的は達成できます。
業務、ビジネスユースケースを洗い出す
システム化の対象となる「業務」と、その業務を構成する「ビジネスユースケース」を、「BUC」シートの「業務」列と「BUC」列に定義します（下図）。
「BUC」シートは、RDRAによる要件定義のコアとなるシートです。
ここでいう1つの「業務」とは、部署や課やチームなどの組織単位で担われる業務のまとまりを指します。
ビジネスユースケースは業務フローを表す単位であり、1つのビジネスユースケースは1つの業務フローに対応します。
アクティビティを洗い出す
ビジネスユースケース（1つの業務フロー）を構成する「アクティビティ」を洗い出し、「BUC」シートの「アクティビティ」列に記載します（下図）。
アクティビティとは、業務フローの中で実行される個々の作業や行動を指します。
アクティビティを洗い出すことで、1つのビジネスユースケースが、業務フローを一連の目的を持った流れとして過不足なく表しているかを確認できます。
その結果、ビジネスユースケースが大きすぎる場合は分割し、細かすぎる場合は統合することで、後続フェーズに進むための粒度を揃えられます。
システム境界レイヤーを定義する
第1フェーズでは、システム境界レイヤーの要素として、ユースケース（UC）を対象とします。
ユースケースを洗い出すことで、どの業務をシステムでサポートするのかが明らかになり、システム化の範囲を可視化できます。
ユースケースのリストアップ
業務フローを構成するアクティビティのうち、システムを使用するアクティビティに対してユースケースを定義し、「BUC」シートの「UC」列に記載します（下図）。
「アクティビティ」列の右隣にユースケースを記載することで、当該アクティビティに対応するユースケースであると定義されます。
システムレイヤーを定義する
第1フェーズでは、システムレイヤーの要素として、情報および状態を対象とします。
「情報」とは、システムが扱う概念的なデータおよびそれらの関係を指します。
「状態」とは、業務上管理すべき情報が取り得る状態*1を指します。
ここでは、業務、ビジネスユースケース、業務フロー（アクティビティ）、ユースケースを洗い出す過程で現れた概念を、「情報」や「状態」として整理し、一覧化します。
詳細な構造や厳密な定義には踏み込まず、まずはシステムで扱う対象を把握することを重視します。
これにより、システムがどのようなデータを扱うのかという観点からシステムの輪郭が明確になります。
また、業務は状態の変化を前提に進むため、状態を整理することで、業務とシステムの関係性を捉えられるようになります。
情報のリストアップ
システムで扱うデータを「情報」シートに記載します（下図）。
シート内の「コンテキスト」とは、同じ役割を持つ情報、状態、条件、バリエーションをまとめる単位です。
システムの特定領域（ドメイン）におけるシステムレイヤーの要素を整理し、まとめて管理するために利用します。ドメイン駆動設計における「区切られた文脈（Bounded Context）」を想定すると、設計プロセスへつなげやすくなります。*2
状態のリストアップ
状態を、「状態」シートに記載します（下図）。
最後に：第1フェーズの成果物の全体像
第1フェーズの成果物の全体像を下図に示しました。
フェーズ1では、企画プロセスで検討された内容を前提に、「要求の確認」と「業務要件定義」を重点的に進めます。
これは、RDRAにおけるシステム価値レイヤーおよびシステム外部環境レイヤーに相当します。
また、業務要件定義からシステム要件定義へとつなぐために、システム境界レイヤーとしてユースケースを抽出し、あわせて情報や状態を洗い出すことで、システム全体の輪郭を明らかにしました。
これらの作業を通じて、要件定義全体の前提となる「枠組み」が定まります。フェーズ1で行っているのは要件を細かく詰めることではなく、システムの価値、業務の全体像、システム化の範囲を構造として整理し、関係者間で共有可能な状態を作ることです。
この段階では、正確さや完成度よりも、後続フェーズで議論を進めるための共通の前提を揃えることを重視します。
フェーズ1で認識のずれやスコープの誤りを残したまま進むと、フェーズ2以降で要件を精緻化しても、手戻りや判断の迷いが生じやすくなります。
続くフェーズ2では、フェーズ1で整えた枠組みを前提として、「システム要件定義」を中心に要件を具体化していきます。
具体的には、次のような作業を通じて、要件同士の関係性を明確にしていきます。
- ユースケースの詳細化（画面、イベント、情報、条件、タイマーの抽出とユースケースへの関連付け）
- システムレイヤーの詳細化（情報、状態、条件、バリエーションの定義）
- アクターと画面の関連付け（どのUIからアクターが操作するかを定義する）
- 外部システムとイベントの関連付け（外部システムと外部インターフェースの関連付け）
次回は、フェーズ2の進め方を説明します。
参考書籍
*1:「注文」の状態の例：「受注済」、「出荷準備中」など
*2:参考記事：重要なツールとして進化した、区切られた文脈〜「ドメイン駆動設計をはじめよう」翻訳者・レビュアー対談その4 - TRACERY Lab.（トレラボ）
![[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?](https://m.media-amazon.com/images/I/51hV6os4M5L._SL500_.jpg "[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?")
