RDRAとAIエージェントで変わる要件定義の現場
# RDRAとAIエージェントで変わる要件定義の現場
「要件定義に3ヶ月かかった」の本当の理由
3ヶ月かかった。
あるプロジェクトで、要件定義だけにそれだけの時間を費やしたことがある。ヒアリングは20回以上。議事録は分厚いフォルダに積み上がった。でも「これで仕様が固まった」と確信できるタイミングは、最後まで訪れなかった。
なぜだったのか。
振り返れば、答えはシンプルだ。要件の構造が見えていなかったからだ。
機能要件のリストはあった。画面遷移の草案もあった。でも「この機能は誰のどの業務のためにあるのか」「この情報はどのシステムとどう連携するのか」——そういう関係性が、どこにも明示されていなかった。だから会議のたびに「やっぱりこれはどうなの？」が繰り返された。
RDRAとは何か
RDRA（Relationship-Driven Requirements Analysis）は、要件定義を「関係性の可視化」として捉えるフレームワークだ。
公式サイト（rdra.jp）を見ると、業務の関係者・システム・業務フロー・情報を整理し、それらの関係性を軸に要件を体系化する手法として説明されている。
平たく言うと、「誰が、何のために、何を使って、どう動くか」を図として書き出す。箇条書きの機能リストではなく、システムと業務の関係性をダイアグラムで表現するのがRDRAの本質だ。
従来型の要件定義との違いを並べるとこうなる。
| 従来の要件定義 | RDRA |
|---|---|
| 機能リスト | 関係性のダイアグラム |
| 「〇〇機能が欲しい」 | 「誰がどう使うか」 |
| 担当者の頭の中に散在 | 図として共有・検証 |
| 矛盾を後から発見する | 構造の上で矛盾が見える |
「うちの現場の話だ」と感じた人は多いはずだ。
なぜAIは「普通の要件定義」が苦手なのか
AIエージェントに要件定義を手伝わせようとして、うまくいかなかった経験はないだろうか。
「議事録を渡すので、要件を整理してください」
AIは整理する。それなりの箇条書きを返す。でも何かが足りない。
それが構造だ。
AIは文章から情報を抽出するのは得意だ。ところが、「この要件とあの要件は矛盾している」「このユーザーストーリーには前提となるシステムの記述がない」といった関係性の欠落を検知するのは難しい。
なぜか。関係性が明示されていないから。
議事録の中に「在庫管理機能が欲しい」と書いてあっても、それが「誰のどんな業務に紐づいているか」「他のどのシステムと連携するか」は書かれていない。AIは推測するしかなくなる。推測が多いほど、アウトプットの信頼性は落ちる。
ここが、AIを要件定義に使う際の盲点だ。
RDRAがAIとの相性が良い理由
ここで話がつながる。
RDRAが定義する要件は、関係性として構造化されている。
- アクター（利用者・外部システム）
- ユースケース（業務の行為）
- ドメインオブジェクト（業務上の情報）
- 状態遷移
これらが図として整理されているということは、AIにとっても「文脈を持った入力」になる。
実際にやってみると、次のようなことができる。
① ユースケースからAPIスペックを自動生成
アクターとユースケースが整理された状態で「このユースケースに必要なAPIエンドポイントを提案して」と投げると、AIは文脈を持って回答できる。「何のためのAPIか」が図から読み取れるからだ。
試しに「在庫管理者が在庫を更新する」というユースケースをRDRAで整理してからAIに渡したところ、更新・参照・通知の3つのエンドポイントが提案され、それぞれの入出力パラメータまで詳細に出力された。同じことを議事録だけ渡してやったときとは、精度が別次元だった。
② 要件の矛盾チェック
ユースケース図と情報モデルをセットでAIに渡し、「この情報がどのユースケースで参照・更新されるか確認して」と依頼する。
参照されているのに更新されていない情報があれば、それは設計の漏れかもしれない。AIはそれを淡々と指摘してくれる。人間がレビューすると「みんな知っているはず」という暗黙の前提で見落とすポイントを、AIは容赦なく洗い出す。
③ 自然言語ヒアリングからRDRA構造を抽出
ヒアリングメモをAIに渡し、「RDRAの観点でアクター、ユースケース、ドメインオブジェクトを抽出して」と聞く。すると叩き台になる構造が返ってくる。
もちろん、そのまま使えるわけではない。業務の深い部分はAIが理解しきれていないし、現場の文脈がないと間違いも多い。でも「ゼロから図を起こす」作業と「AIが出した叩き台を修正する」作業では、かかる時間が全然違う。
このフローが回ると、ヒアリングから最初のシステム仕様ドラフトまでのリードタイムが劇的に短くなる。私たちの実感では、初回ヒアリングから最初の仕様ドラフトまで1週間以内に持っていけるようになった。3ヶ月かかっていた時代から考えると、信じられない変化だ。
「RDRAの学習コストが高い」という反論に答える
RDRAは確かに学習コストがある。ダイアグラムの記法を覚え、チームに浸透させるまでには時間がかかる。
それは否定しない。
ただし、こう考えてほしい。
今のやり方——議事録の山から要件を拾い、Excelで管理し、ふんわりとした仕様書を書く——も、実は相当なコストを払っている。ただ、それが「普通のこと」になっているから見えていないだけだ。
RDRAに移行する最初の1〜2ヶ月はコストがかかる。でも3ヶ月目以降、チームの要件定義スピードは変わる。
そし て今は、AIという強力な補完がある。RDRAの記法を完全に覚えていないメンバーでも、「自然言語でヒアリングして、AIにRDRA形式に変換させる」フローが使える。記法の習得と業務の効率化を同時に進められるのは、AIとの組み合わせがあってこそだ。
要件定義は「書く作業」から「構造を作る作業」へ
結論を言う。
AIが要件定義を効率化するためには、要件自体が構造を持っていなければならない。
RDRAはその「構造」を提供する。AIはその「構造」の上で威力を発揮する。
この組み合わせは、まだ広く普及していない。だからこそ、今使い始めたチームには先行優位がある。
「要件定義に3ヶ月かかる」のは、要件が構造を持っていないせいかもしれない。一度、その前提から疑ってみてほしい。
*関連記事*
