シリーズ: モデルベース要件定義手法RDRA
- 要件定義手法RDRAの概要と全体像（本記事）
- RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
- RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
- RDRAによる要件定義の進め方〜第3フェーズ：整合性・網羅性を確認し精度を上げる（近日公開予定）
- RDRAの成果物と設計フェーズとの連携（近日公開予定）
- RDRA Agentの紹介（近日公開予定）
- RDRAと見積（近日公開予定）
TRACERYプロダクトマネージャーの haru です。
要件定義は、システム開発の成否を左右する重要なプロセスです。しかし実務では、一定のフォーマットや手順に沿って整理していても、要件同士の関係性が十分に可視化されなかったり、関係者ごとに解釈がずれたり、設計段階で手戻りが発生したりと、多くの課題が生じがちです。
筆者は2020年から実プロジェクトで RDRA を活用してきました。いまでは、RDRAを使う前にどのように要件定義を進めていたのか思い出せないほど、日々の実務に深く根付き、なくてはならない手法になっています。要件の整理・構造化・合意形成が自然に進み、要件定義の質とスピードは大きく向上しました。
RDRA（ラドラ）（Relationship Driven Requirement Analysis）は、要件同士の関係性を構造的に整理し、ビジネスとシステムを一体として可視化するための要件定義手法です。関係者間で共通の前提と構造を共有しながら要件を具体化できるため、認識齟齬や手戻りの少ない開発を実現できます。
本記事では、RDRAの基本的な考え方から、V字モデルにおける位置付け、4つのレイヤー構造、さらに実務を支える各種ツールまで、RDRAの全体像を体系的に解説します。
RDRAの概要
RDRAは「Relationship Driven Requirement Analysis」の略で、株式会社バリューソースの神崎善司氏が提唱する要件定義手法です。
システムを構成する要素同士の関係（Relationship）を定義することで、システム全体の構造を明確に捉え、可視化することができます。
要件を構造的に捉えることの価値
要件を構造的に捉えることの価値は、要件を個々の点としてではなく、「関係性によって意味づけられた全体構造」として整理できる点にあります。
RDRAでは、要素同士の関係を起点に要件を定義するため、個々の機能やルールがどの要素と結び付いているのかを明確にしながら、要件を積み上げていくことができます。
その結果、要件の抜け漏れや重複、矛盾といった問題を要件定義の早い段階で発見しやすくなり、「なぜこの要件が必要なのか」「この要件がなくなると何が困るのか」といった説明も、論理的に行えるようになります。
これは、後工程での手戻りや、完成後に「使われないシステム」になるリスクを下げることに直結します。
さらに、変更や追加が発生した場合でも、関係性をたどることで影響範囲を把握できるため、感覚や経験に頼らない判断が可能になります。
その結果、開発者・業務担当者・意思決定者の間で共通の理解を持ちながら議論でき、要件定義における合意形成を安定して進められます。
システム開発全体（V字モデル）での位置づけ
RDRAは要件定義の手法であり、主にV字モデルにおける要件定義（業務要件定義、システム要件定義）に位置付けられます（下図）。
RDRAでは、企画プロセスで整理された事業の背景や狙い、要求を入力として受け取り、「システム価値レイヤー」で定義します。
業務要件定義の内容は、「システム外部環境レイヤー」、システム要件定義の内容は、「システム境界レイヤー」「システムレイヤー」の二つで定義します。
RDRAのレイヤーについては、後述します。
また、RDRAの成果物は、要件を関係性を含んだ構造として表現しているため、要件定義の後プロセスである基本設計に対しても、「なぜその機能が必要なのか」という意図を保ったまま情報を引き渡すことができます。
その結果、要件定義と設計の間で起こりがちな解釈のズレや属人化を防ぎ、V字モデル全体を通した一貫性のある開発を支える役割を果たします。
RDRAの全体像
RDRAの全体像を下図に示します。
RDRAは4つのレイヤーで構成されます。以降では、各レイヤーの役割と、それぞれを構成する要素やモデルについて説明します。
システム価値レイヤー
システムが実現すべき価値に着目します。「このシステムは誰にとって、どのような価値を提供するか」を明らかにします。
| 要素 | 説明 |
|---|---|
| 要求 | 機能要求、非機能要求。システムで何を実現するか。 |
| アクター | システムを利用する人や組織の役割。 |
| 外部システム | 連携が必要な既存システムや外部サービス。 |
システムレイヤーの要素を取りまとめるためのモデルには、以下のようなものがあります。
| モデル | 説明 |
|---|---|
| アクター群 | 同じ役割をもつアクターをまとめる。 業務・BUCとの関わりを、俯瞰的な視点で見ることができる。 |
| 外部システム群 | 同じ役割をもつ外部システムをまとめる。業務・BUCとの関わりなど、俯瞰的な視点で見ることができる。 |
システム外部環境レイヤー
システムがどのように使われるかを表します。「誰が何の業務を行い、その結果どんな価値を提供するか」を業務フローとして示します。
| 要素 | 説明 |
|---|---|
| 業務 | ビジネスの最上位のまとまり。例：販売管理や在庫管理など。 |
| ビジネスユースケース（BUC） | 業務フローの単位。 |
| アクティビティ | 人やシステムが行う仕事の単位。 |
システム境界レイヤー
ユーザーや他の外部システムがシステムとどう関わるかを示します。システムとのインターフェースを明確にします。
| 要素 | 説明 |
|---|---|
| ユースケース（UC） | システムが提供する具体的な機能単位。 |
| 画面 | UI（画面や帳票等) |
| イベント | 外部のシステムやアクターとのインターフェース。 |
| タイマー | ビジネス上の締切（例：月末締、定時実施） |
| 情報 | ユースケースから参照する。システムレイヤーの節を参照のこと |
| 条件 | ユースケースから参照する。システムレイヤーの節を参照のこと |
システムレイヤー
システム内部を表現します。
| 要素 | 説明 |
|---|---|
| 情報 | システムが扱う概念的なデータとその関係。 |
| 状態 | 業務上管理すべき対象のとりえる状態（「注文」の状態の例：「受注済」、「出荷準備中」など）。 |
| 条件 | 業務上またはシステム上のビジネスルール。 |
| バリエーション | ビジネス上認識している区分や種別。「会員ステータス」の例：「プラチナ」「ゴールド」「シルバー」 |
システムレイヤーの要素を取りまとめるためのモデルには、以下のようなものがあります。
| モデル | 説明 |
|---|---|
| コンテキスト | 同じ役割をもつ情報、状態、条件、バリエーションをまとめる。システムの特定領域（ドメイン）のシステムレイヤーの要素をまとめて管理する単位として利用できる |
| 情報モデル | 複数の「情報」をひとつのモデルにまとめたもの |
| 状態モデル | 複数の「状態」と、それらの間の遷移をまとめて定義したモデル |
RDRAのモデルを定義するためのツール
RDRAには、目的に応じて複数のツールが用意されています。それぞれの役割と関係性を、下図に示します。
RDRAによる要件定義作業の中心となるのが、「RDRA定義・分析Sheet」です。（図書館管理システムのサンプル）
このシートでは、システムを構成する要素と、それらの関係性を表形式で整理・定義します。要件を関係性とともに構造化して記述することで、RDRAモデルの基盤となる情報を一元的に管理できます。
さらに、シートで定義した内容をグラフィカルなモデルとして視覚的に俯瞰するためのツールが「RDRA Graph」です。個々の要素のトレーサビリティや集約した単位での凝集度や結合度の把握など、さまざまな視点から定義情報を分析し、定義の精度を上げることができます。
RDRA Graphは「関連データシート」のデータをクリップボードにコピーし、シート内のリンクから起動できます。
RDRA Graphの画面が起動されたら、ヘッダメニューの「OBJECT LIST」や「DIAGRAM」からモデルを参照してください。なお、RDRA Graphで表示したモデルは参照専用です。
また、LLMを活用してモデルの叩き台を生成する支援ツールとして、「RDRA ZeroOne」と「RDRA Agent」が用意されています。「RDRA ZeroOne」はWeb画面から、「RDRA Agent」はCLIから実行でき、RDRA形式のモデルデータを自動生成します。
これらのツールで生成したテキストデータを「RDRA定義・分析Sheet」に取り込むことで、要件を一から手作業で整理する負担を大幅に削減でき、要件定義の初期立ち上げを高速化できます。その結果、検討や、分析、合意形成といった本質的な作業に、より多くの時間を充てることが可能になります。
まとめ
本記事では、RDRAの基本的な考え方から、V字モデルにおける位置付け、4つのレイヤー構造、そして実務を支える各種ツールまで、RDRAの全体像を解説しました。
RDRAの本質は、要件を個別の項目として管理するのではなく、要素同士の関係性を軸にシステム全体を一つの構造として捉える点にあります。これにより、要件の抜け漏れや矛盾を早期に発見できるだけでなく、「なぜ必要なのか」を説明可能な、納得感のある要件定義を行えるようになります。
筆者自身、2020年から複数の実プロジェクトでRDRAを継続的に活用してきましたが、企画から設計へと情報を一貫した形で引き継ぎやすいため、解釈のズレや属人化を防ぎ、後戻りの少ない開発を実現できています。
また、GoogleSheet・RDRAGraph・LLMツールを組み合わせることで、構造化と可視化、そして自動生成を両立し、要件定義のスピードと品質を同時に高められる点も大きな強みです。
要件定義を「作業」ではなく「構造を設計するプロセス」として捉え直したい方にとって、RDRAは有効な選択肢の一つです。
次回からは、図書館システムのサンプルを題材に、RDRAの詳細について順を追って確認していきます。
参考書籍
