RDRAとは？4レイヤーをつなぐ5ステップ
目次
はじめに
要件定義で機能一覧、業務フロー、画面一覧を作ったのに、レビューで「この機能は誰の何のため？」「このデータはどこで更新する？」と質問が戻ってくることがあります。成果物が足りないのではなく、成果物同士の関係が切れていることが原因です。
RDRA（Relationship Driven Requirements Analysis）は、要件を関係性で組み立てる分析手法です。RDRA公式サイトは、要件定義を4つのレイヤーと各レイヤーのモデルで構成し、要素間の依存関係を使って要件を決めると説明しています。つまり目的は、決められた図をすべて描くことではありません。価値からシステム仕様まで「なぜ必要か」をたどれる状態を作ることです。
この記事では、RDRAの4レイヤーを実務でつなぐ順番を5ステップで整理します。初回から完全なモデルを目指さず、小さな業務範囲で要件の根拠と抜けを確認できる形にする方法です。
RDRAの4レイヤーとは
RDRA公式の説明では、要件定義を次の4つの視点で捉えます。
| レイヤー | 確認する問い | 主な整理対象 |
|---|---|---|
| システム価値 | なぜ作るのか | 目的、要求、価値、関係者 |
| システム外部環境 | どの業務で使うのか | 業務、利用場面、業務フロー |
| システム境界 | 誰・何と接続するのか | アクター、外部システム、ユースケース |
| システム | 内部で何を扱うのか | 情報、状態、振る舞い、条件 |
内側の仕様だけを先に決めると、その機能が必要な理由を説明できません。反対に、経営目標だけでは開発できる仕様になりません。4レイヤーをまたいで要素をつなぐことで、「この要求を実現する業務」「その業務を支えるユースケース」「ユースケースが扱う情報」という根拠の鎖ができます。
IPAの「ユーザのための要件定義ガイド 第2版」も、ビジネス要求、システム化要求、要件定義マネジメントを分け、主要ドキュメントではステークホルダー、ビジネスプロセス、データ、相互作用、インターフェースなどの整合を確認する構成です。RDRAは、それらを一枚の巨大な図に押し込むのではなく、複数のモデルを関係で結ぶための枠組みと考えると理解しやすくなります。
ステップ1：対象業務と価値を一文で固定する
最初に「誰の、どの業務を、どう良くするか」を一文で書きます。たとえば受発注管理なら、「営業担当が受注後の転記作業を減らし、当日中に正しい出荷指示を確定できるようにする」です。
この段階で、システム名や機能名を主語にしないことが重要です。「受発注システムを刷新する」では、達成したい価値を判定できません。対象者、対象業務、期待する変化、判定指標を置きます。
- 対象者：営業担当、出荷担当
- 対象業務：受注登録から出荷指示まで
- 期待する変化：二重入力と確認待ちを減らす
- 判定指標：当日確定率、差し戻し件数、処理時間
ここで書けない項目は、関係者へ確認すべき論点です。曖昧なまま機能一覧へ進まず、仮説には「未確認」と印を付けます。要件定義ヒアリングシートの7つの質問も使うと、事実・判断・例外を分けて収集できます。
ステップ2：外部環境を業務の開始から終了まで描く
次に、価値が生まれる業務を、開始条件から終了条件まで並べます。部門ごとではなく、一つの案件や情報がどう流れるかで区切るのがポイントです。
受発注なら「注文を受ける→内容を確認する→在庫を引き当てる→出荷を指示する→結果を通知する」と置きます。各工程には、実施者、入力、判断、出力、例外を添えます。正常系だけでなく「在庫不足」「価格の不一致」「承認者不在」も同じ段階で記録します。
業務フローをきれいに描くこと自体が目的ではありません。システム化する工程、人が判断する工程、外部サービスに依存する工程を区別するために描きます。詳しい作図手順はBPMNの書き方も参考になります。
レビューでは、開始条件と終了条件がつながっているか、担当不在の工程がないか、例外時の戻り先があるかを確認します。ここで業務の境界が決まると、後工程の「システムに何をさせるか」が安定します。
ステップ3：システム境界をアクターとユースケースで切る
業務フローの各工程から、システムとの接点を抽出します。人、組織、外部システムをアクターとして置き、アクターがシステムを使って達成することをユースケースとして表します。
悪い例は「登録機能」「検索機能」のような画面操作だけの名前です。これでは業務上の完了条件が分かりません。「受注内容を確定する」「在庫を引き当てる」「出荷結果を通知する」のように、業務上の目的が分かる動詞で書きます。
各ユースケースには、最低限次の5項目を添えます。
- 開始するアクター
- 実行のきっかけ
- 入力する情報
- 成功時の結果
- 失敗・保留になる条件
外部システムとのやり取りは、送受信する情報、タイミング、失敗時の扱いまで明記します。外部インターフェース一覧へつなげれば、境界の議論をAPIやファイル連携の仕様へ落とせます。
ステップ4：情報と状態をユースケースへ結び付ける
続いて、各ユースケースが参照・作成・更新する業務情報を整理します。受注、顧客、商品、在庫、出荷指示などの言葉を並べるだけでなく、それぞれの識別子、主要属性、関係、管理主体を決めます。
特に重要なのが状態です。受注なら「下書き→確認待ち→確定→出荷指示済み→完了」のように状態を置き、どのユースケースが状態を変えるかを結びます。すると、次の抜けを見つけやすくなります。
- 作成されるが、その後参照されない情報
- 更新するユースケースがない状態
- 複数部門が同じ項目を別の意味で使う箇所
- 外部システムと責任主体が重複する情報
- 取消後に実行できてしまう操作
状態の洗い出しは状態遷移図の書き方と組み合わせると具体化できます。すべての情報に状態図を作る必要はありません。承認、予約、契約、在庫など、順序や取消条件が品質に影響する対象へ絞ります。
ステップ5：縦と横のレビューで抜けを検出する
最後に、個々の図の見た目ではなく、要素間のつながりをレビューします。縦のレビューでは、価値から業務、ユースケース、情報まで根拠をたどります。横のレビューでは、同じレイヤー内の重複や矛盾を確認します。
| レビュー方向 | 確認例 |
|---|---|
| 価値→業務 | この業務変更はどの指標に効くか |
| 業務→ユースケース | システム化対象の工程に接点があるか |
| ユースケース→情報 | 入出力と更新主体が決まっているか |
| 情報→状態 | 状態を変える条件と権限があるか |
| 同一レイヤー内 | 用語、粒度、責任が重複していないか |
要素にはIDを付けます。たとえば要求をREQ-01、業務をBP-03、ユースケースをUC-07、情報をINFO-04とし、関連先を記録します。これで変更時に影響範囲を検索できます。要件トレーサビリティの考え方を早い段階から使う形です。
未接続の要素は即削除せず、「不要」「検討中」「接続漏れ」のどれかを判断します。未接続であること自体が、RDRAで得られる重要なレビュー結果です。
RDRA導入で避けたい3つの失敗
全ダイアグラムを最初から作る
RDRA公式は要求モデル、システムコンテキスト、業務フロー、情報モデル、状態モデルなど複数のダイアグラムを挙げていますが、プロジェクトの状況に応じて使い分けるとしています。1業務・1価値から始め、判断に必要なモデルだけを追加します。
記号の正しさだけをレビューする
記法が整っていても、価値と仕様がつながっていなければ要件の妥当性は判断できません。「この要素の根拠は何か」「変更するとどこに影響するか」を説明できるかを優先します。
図と一覧を別々に更新する
図、用語集、ユースケース一覧を別ファイルで管理すると、すぐに差分が生まれます。同じIDと名称を使い、変更理由と承認者を残します。AIで叩き台を作る場合も、推測と確認済み事実を分け、人が関係性を承認する運用が必要です。
まとめ：小さな範囲で「なぜ」をつなぐ
RDRAの価値は、成果物の枚数ではなく、要件の根拠をたどれることにあります。価値を一文で固定し、業務を描き、システム境界を切り、情報と状態を結び、縦横にレビューする。この5ステップなら、記法の習得そのものを目的にせず実案件へ導入できます。
まずは変更が多い一つの業務を選び、「要求→業務→ユースケース→情報」の接続表を作ってみてください。つながらない要素が、次のヒアリングで確認すべき論点です。
要件を議事録や表計算に散らさず、関係を保ったまま仕様へ育てたい場合は、Kakusillをご覧く ださい。業務情報から仕様を整理し、レビューと変更管理につなげられます。
