システム開発の成功は、最初のステップである「要件定義」にかかっているといっても過言ではありません。しかし、この要件定義の段階で「要件の伝え漏れ」や「関係者同士の認識の違い」、「システム全体を把握するのが難しい」といった問題にぶつかることは、決して珍しいことではないんです。
そんな悩みを解決するために生まれたのが、RDRA（ラドラ)です。RDRAは、視覚的に分かりやすいアプローチで、システムの全体像を「すばやく」「抜け漏れなく」明確にする画期的な要件定義手法として、開発現場で徐々に浸透しつつあります。
この記事では、RDRAがどんなものか、そしてどうやって活用するのかを、初心者の方でも理解できるようにわかりやすく解説します。
なお、この記事はRDRAの概要を紹介するものであり、より詳しい情報や実践的なテクニックについては、公式サイト（https://www.rdra.jp/）や、考案者である神崎善司さんの著書『モデルベース要件定義テクニック』『RDRA3.0ハンドブック』を参照ください。
RDRA（ラドラ）とは？その目的と特徴
RDRAは、株式会社バリューソース代表取締役社長の神崎善司さんが開発した要件定義のモデリング手法のこと。RDRAとは、Relationship Driven Requirement Analysis（リレーションシップ駆動要件分析）の略称で、読み方は「ラドラ」です。
神崎さんは、従来の要件定義が大量のドキュメント作成に頼り、システムと業務の関係性や価値が見えづらい課題に対して、この手法を考案しました。
システムの「つながり」を重視する考え方
RDRAの大きな特徴は、システムの「つながり」をとても大切にしている点です。システムの外側（どう使われるか）から内側（どんなデータや動きがあるか）まで、要素同士がどう関係しているかを可視化します。これにより、要件の「抜け漏れ」や「重複」を防ぎ、全体として矛盾がない状態を目指します。
書類作りではなく「見える化」する作業
要件定義と聞くと、分厚い書類を作るイメージがあるかもしれません。しかし、RDRAは「要件を見える化して、関係者全員で合意し、定義する」という作業として捉えています。
これにより、関係者全員がシステムの全体像を理解しやすくなり、スムーズな開発につながります。
RDRAの主要な特徴をサクッと解説
RDRAがなぜ注目されているのか、その主な特徴を簡潔にまとめました。
- 目で見てわかるアプローチ
絵や図を使って、システムに必要な機能や要素を視覚的に捉え、要件をはっきりさせます。 - 関係者全員の意見をまとめる
システムを使う人や関係者（ステークホルダー）の視点を積極的に取り入れ、使いやすいシステムを目指します。 - 少しずつ詳しくしていく
最初は大まかな全体像から始め、徐々に詳細な部分を固めていくので、途中で大事なことを見落としにくくなります。 - 変更に柔軟に対応できる
開発中に要件が変わってしまっても、その変更に柔軟に対応できるような仕組みになっています。
これらの特徴のおかげで、RDRAは「網羅的で矛盾のない要件」を効率的に組み立てることを可能にしているのです。
なぜRDRAが必要なの？ 従来の要件定義が抱える課題
RDRAが生まれた背景には、従来の要件定義が抱えていた、いくつかの大きな問題点があります。これらの問題を解決するために、RDRAは開発されました。
従来の要件定義の3つの課題
- 全体像がわかりにくい
「システムが何をするか」は書いてあるけど、「なぜそうするのか」という背景が不明なままで、途中で手戻りが発生しがち - 意見のすり合わせが非効率
要件定義のゴールがあいまいなせいで、話し合うべきことがはっきりせず、議論がまとまらない - ノウハウが属人化する
要件定義の進め方や知識が、特定の担当者しか知らない「ブラックボックス」になってしまい、全員で共有できるドキュメントが作られにくい
RDRAが目指す「理想の要件定義」
RDRAは、これらの課題を解決するために、以下のことを目指しています。
- システムの全体像をすばやく、抜け漏れなく明確にする
- 要件定義の進め方を「見える化」して、誰でも同じように進められるようにする
- 関係者全員が「早く」「漏れなく」「誤解なく」要件に合意できるようにする
- 特定の担当者しかわからない「属人化」を防ぎ、関係者全員で話し合うためのベースを作る
RDRAを活用すれば、従来の要件定義でつまずきがちだった課題をクリアし、プロジェクトをよりスムーズに進められるようになります。
RDRAはどんなものでできている？ 3つの構成要素
RDRAは、以下の3つの要素で構成されています。
1. RDRAモデル
RDRAモデルは、RDRAの要となるものです。このモデルを使って、システムの全体像を把握したり、すでにあるシステムを見える化したり、関係者同士のコミュニケーションを円滑にしたりすることができます。
2. RDRAレイヤー
RDRAレイヤーは、要件を整理するための4つの階層のことです。要件定義を進めやすくするために、システムとその周りの環境を「システム価値」「システム外部環境」「システム境界」「システム」の4つの層に分けて考えます。
また、RDRAのレイヤーには、「なぜ？」という「Whyの依存関係」があります。これは、下位のレイヤー（システム）から上位のレイヤー（システム価値）に向かって「なぜ？」と問いかけることで、要件に論理的なつながりを持たせる考え方です。
このつながりを意識することで、要件が抜け漏れなく、矛盾なく整理できます。
たとえば「システムにAという情報をもつ、なぜなら、ユースケースAでその情報を更新するから。ユースケースAは業務Aで必要になる。業務Aをすることで、ユーザーに価値Aを与える」というように、ひとつひとつの要件に意味付けができるのがRDRAの特徴です。
3. RDRAアイコン
RDRAには、各レイヤーで使うための「アイコン」が用意されています。これらのアイコンを組み合わせてモデルを作っていきます。アイコンは、プロジェクトに合わせて自由にカスタマイズすることも可能です。
RDRAはどんなときに役立つの？主な活用シーン
RDRAは、システムの要件定義だけでなく、さまざまな場面で力を発揮します。
RDRAの主な活用シーン
| 活用場面 | どう役立つのか |
|---|---|
| 要件定義をするとき | これから作るシステムの「To-Be」をはっきりさせるために使います。 |
| 既存システムの見える化 | 担当者しか知らないシステムや、古い資料しかないシステムでも、「As-Is」を効率的に把握できます。 |
| 複雑なシステムを開発するとき | 機能が多くて、互いに関係し合う要素がたくさんあるシステムでも、全体像を整理してくれます。 |
| 関係者が多いプロジェクト | 異なる部署や立場の人が関わるプロジェクトでも、全員の意見や期待をまとめ、認識の違いをなくします。 |
| 要件変更が多いプロジェクト | 変更があっても、それをモデルにすばやく反映させられるので、最新の情報を全員で共有しやすくなります。 |
| 大規模な開発プロジェクト | 開発メンバーやチームの数が多いときも、スムーズなコミュニケーションをサポートしてくれます。 |
RDRAは、ドメイン駆動設計（DDD） の前段階として使われることも多く、複雑なビジネスドメインをモデル化する際に役立ちます。また、アジャイル開発と組み合わせることで、要求の変更に柔軟に対応するアジャイルの強みと、要求を体系的に整理するRDRAの強みを活かし、より効率的な開発が期待されています。
RDRAを活用した要件定義の具体的な進め方については、公式サイトの「要件定義の進め方」ページで詳しく紹介されています。
RDRAを使った要件定義の進め方
RDRAを使った要件定義は、一般的に「3つのフェーズと9つのステップ」で計画的に進めます。一度で完璧を目指すのではなく、何度も見直して精度を上げていくのがポイントです。
3つのフェーズ
フェーズ1：議論のベースを作る
要件定義がまとまりにくいときでも、まずはざっくりと全体像を把握し、全員で話し合える土台を作ります。
フェーズ2：要件を組み立てる
フェーズ1で洗い出した要素（情報や状態など）を使って、要件に論理的なつながりを持たせていきます。
フェーズ3：仕様の具体化
ユースケース（UC）に条件やルールを付け足して、仕様化可能なレベルまで要件を具体的にしていきます。
9つのステップ
各フェーズは、さらに細かいステップに分かれています。
フェーズ1：議論のベースを作る
- Step1：システムの登場人物（アクター）と、関わる業務を洗い出し、どこまでをシステム化するのか決めます。
- Step2：業務の流れをざっくりと把握し、具体的な作業内容を見える化します。
- Step3：業務で扱う情報を明らかにし、システムで管理すべき情報を特定します。
- Step4：業務の中で「こういう状態になる」というものを洗い出します。
フェーズ2：要件を形作る
- Step5：業務からユースケース（UC）を導き出し、システム化する部分を整理します。
- Step6：洗い出した情報や状態とユースケースを関連づけて、要件の精度を上げていきます。
フェーズ3：仕様として使えるレベルまで詳細化する
- Step7：システムがどんなときに動くのか、という「条件」を整理します。
- Step8：「条件」を成り立たせるための「バリエーション」を洗い出します。
- Step9：それぞれの条件とバリエーションについて具体的な要素を洗い出すことで、実装に必要なレベルまで詳細にしていきます。
これらのステップを踏むことで、誰もが納得できる、質の高い要件定義が完成するのです。
RDRAを使うには？ モデリングツールをチェック
RDRAは、特定のツールに限定されず、さまざまなツールを使って定義したり、分析したり、見やすくしたりすることができます。とはいえ、初めてRDRAを実践する場合は、公式サイトで詳しく解説されている以下の表にある1〜3のツールを利用すると、仕組みを理解しやすいでしょう。
これらのツールやその活用方法について、バリューソースによるRDRAの公式サイトに詳しく紹介されています。 ツールを試したい方は、こちらのページから詳細をご確認ください。
| No. | ツール名 | 特徴 |
|---|---|---|
| 1 | RDRA定義・分析用Googleスプレッドシート | ・RDRAのモデルを表形式で表現し、従来のダイアグラム形式よりも素早く高精度にシステムを可視化できるツール ・各モデルの要素（業務、BUC、アクティビティ、ユースケース、アクター、外部システムなど）を複数のシートに整理し、モデル間の整合性をPivotなどで分析・検証可能 【ポイント】 ・初期段階で全シートをざっと埋めて全体像をつかむ。精度は後から上げることで素早く要件定義を進める ・各シート間の関連（例：アクターとUC、アクティビティと条件）を意識しながら何度も行き来し、整合性を高める ・RDRA定義がある程度進んだ段階で、分析機能を活用することで不整合の自動検証やモデル間の関係性分析が可能になり、精度をさらに高められる |
| 2 | RDRAGraph | ・RDRAの表形式で定義したモデル要素をグラフィカルに可視化・分析できるツール ・解析目的に応じ「影響度分析」と「全体俯瞰」2つの視点で要素の関係性を分析可能 【ポイント】 ・スプレッドシートの表形式データと連携することで、必要に応じてダイアグラムとして視覚化・俯瞰できるため、作業フェーズに応じて表と図を使い分けるのが良い |
| 3 | RDRA ZeroOne | ・LLM（大規模言語モデル）を活用して、未知の業種・業務に対してもビジネス背景や概要からRDRA要件定義のたたき台を素早く生成できるツール ・段階的に「文脈理解」「ビジネスアイディア」「ビジネスデザイン」「システム化検討」という4フェーズに分けて要件要素を洗い出す 【ポイント】 ・LLM出力はあくまで「たたき台」に過ぎず、反復的なLLM実行（壁打ち）と人による修正を組み合わせ精度を高めることが重要 ・たたき台生成後は、RDRA定義用GoogleスプレッドシートやRDRAGraphに内容をエクスポートし、詳細な要件定義や見直し、関係性検証に活用できる |
| 4 | PlantUML / Mermaid | ・テキストベースでRDRAの各種アイコンや図（システムコンテキスト図、業務フロー、状態遷移など）を記述することができ、手軽にRDRAモデルのビジュアル化が可能 ・Gitなどでのバージョン管理や差分確認に向いている |
| 5 | miro / Figjam | ・オンラインホワイトボードツールとして、非エンジニアも含む関係者とリアルタイムまたは非同期でRDRAのダイアグラムを共同作成・編集できるため、認識合わせや対話促進に活用可能 ・RDRAの各レイヤーに対応したアイコンや図形を自由に配置し、矢印で関係性をつなぐことで、複雑な要件やシステム構造を直感的に理解・共有しやすい |
RDRAを使うメリット
RDRAを導入すると、システム開発のプロジェクトにたくさんのメリットがあります。
コミュニケーションの質が上がる
図や絵を使うことで、関係者全員がシステムへの共通理解を深め、話し合いの質が上がります。また、議論の枠組みがはっきりしているので、話がそれずに、決めるべきことが明確になります。
品質が上がる
要件の抜け漏れが減り、矛盾がなくなるので、手戻りが減ります。「網羅性（もれがないか）」「整合性（矛盾がないか）」「表現力（わかりやすいか）」という要件定義の重要なポイントがすべて上がります。
システム設計の質が上がる
ユーザーの視点をしっかり反映できるので、使いやすいシステムを作れます。また、図で管理するので、要件が変わったときも、すばやく対応できます。
組織にノウハウがたまる
業務設計のノウハウやプロセスが組織全体に蓄積され、特定の担当者に頼らずに済みます。また、新人はプロダクトの構造を理解しやすくなり、ベテランも経験に頼らず論理的かつ網羅的に課題を見つけられるようになります。
RDRAの導入で気をつけたいこと（デメリット）
RDRAにはたくさんのメリットがありますが、導入する際には気をつけたい点もいくつかあります。
手間と時間がかかることがある
細かい図や資料を作る必要があるので、その分、時間や労力がかかることがあります。
※特に初期のRDRA1.0は、しっかりとダイアグラムを作成する必要がありました。ただし、RDRA2.0ではユースケース複合図の導入によりプロセスがスリム化され、さらにRDRA3.0で表形式のRDRA定義にしたことで資料作成の工数がぐっと減りました。
専門知識が必要になる
正確な図の作成や解釈には、RDRAに関するある程度の知識が必要です。
資料作りに時間を取られるリスク
細かい資料をたくさん作りすぎると、かえってプロジェクトの進行が遅れてしまう可能性があります。
全員の協力が不可欠
プロジェクトに関わる全員の積極的な参加が必要なので、協力が得られないと効果が下がってしまいます。
導入時に抵抗感があることも
慣れない手法なので、導入したばかりのころは「やることが増えた」と感じて抵抗感が出る人もいるかもしれません。
RDRAを活用して、要件定義の悩みを解決しよう
RDRAは、システムの全体像を「すばやく」「抜け漏れなく」「矛盾なく」明確にできる、とても優れた手法です。
「システム価値」「システム外部環境」「システム境界」「システム」という4つの層に分け、それぞれを「なぜ？」というつながりで結びつけていくことで、要件を論理的に組み立てられます。
RDRAは、要件定義だけでなく、すでに動いているシステムの調査や、プロジェクトの範囲を決めるときなど、いろいろな場面で役立ちます。
図を使ってコミュニケーションを円滑にしたり、一部の人しか知らない知識をチーム全体に広げたり、質の高いシステム開発を目指すうえで、RDRAは非常に有効なツールと言えるでしょう。
今回の記事ではRDRAの概要をご紹介しましたが、より実践的にRDRAを使った要件定義の進め方を知りたい方は、神崎さんの書籍や公式サイトをぜひ参考にしてみてください。
アイスリーデザインでは、ヒアリング・ビジネス要求定義から、要件定義、設計・開発・運用フェーズまで 一貫してご支援いたします。プロジェクトの特性に合わせ、最適な要件定義の手法や開発手法をご提案させていただきます。要件定義の段階で立ち止まってしまったり、次の設計・開発にどうつなげるか迷ったりされている場合は、ぜひお気軽にご相談ください。
神崎さんは企業向けに勉強会も開催しており、先日、弊社でも実際に研修を行っていただきました。モデリングツールを活用し、架空のプロダクトを題材に、要件定義を進めるデモ形式で実施された研修は非常に実践的で有意義なものでした。
RDRAはデザイナーとエンジニアの連携に有用な手法であり、ドメイン駆動設計（DDD）、OOUIと組み合わせることで良質なUX/UIを実現しやすくなると弊社としては考えています。こうした背景から、弊社ではRDRAを積極的に取り入れていく方針です。