はじめに
株式会社ネクストスケープ Chief Technology Office所属の小野塚です。
当社が要件定義のツール、フレームワークとして利用しているものとしてRDRAというものがあります。
以前このネスケラボでも私の方で幾つか記事を書かせていただきました。
もしお時間許せば先に以下の２つの記事だけでも読んでいただいた方がより興味深く読めるかもしれません。
あらためて説明しておきますと、このRDRA、こちらは株式会社バリューソースの代表、神崎善司さんという方が考えたものでして、このフレームワークに従って要件定義を行うことである程度のレベル・粒度で資料を作成することができます。
そして神崎さんはこのAIの時代においてRDRAを更にバージョンアップさせる試みを行っております。
RDRAはその業務を全く知らない人でもある程度要件定義ができるようになるためのフレームワークなわけですが、お客様とのコミュニケーションを必要とするものであるため、業務知識が全くのゼロベースとなるとお客様にとっても自身にとっても負担が大きいものになります。
その部分をAIを使うことで軽減させて、更に進化させることができるのではということで私自身も非常に期待しつつ、神崎さんの発表を毎回楽しみにしておりました。
そして先日公開されたのがRDRA Agentと呼ばれるものになります。
具体的な内容はこの後説明させていただきますが、こちらはClaude Code上で動作するものになります。
そして、別の有志の方がこのRDRA AgentのCursor版を作成してくれました。
私自身、Cursorをメインに使っていることもあり、早速こちらを使わせていただきまして、今回この記事でその感想を書かせていただければと思います。
使用するにあたっては上記リポジトリからZIPでダウンロードしてもらうか、あるいは以下のリリースページからZIPでダウンロードし、解凍してください。
そして解凍したプロジェクトをCursorで開きます。モデルはこれでなければというのは無いのですが、今回はComposer1でいきます。
というのも結構時間がかかりますのでまずはお試しで「どういった流れでどういった出力が行われるのか見てみたい」ということであれば高速なモデルがお勧めです。
解凍したプロジェクトのファイル構成は以下になります。
RDRAAgentCursor/
├── .cursor/ # Cursorのコマンドとルールフォルダ
├── 0_RDRAZeroOne/ # RDRAZeroOneの出力フォルダ
├── 1_RDRA/ # RDRAの出力フォルダ
├── 2_RDRASpec/ # RDRASpecの出力フォルダ
├── RDRA_Knowledge/ # ナレッジベース
├── Samples/ # サンプルプロジェクト
├── .gitignore
├── 初期要望.txt
├── 妥当性検証環境.csv
└── README.md
まずはルートディレクトリに初期要望.txtを用意します。
お試しで。。ということであれば既に同じ場所にサンプルファイルがありますので、それをそのまま使ってみてください。
そのサンプルとしての初期要望.txtでは訪問介護システムとして以下のような記述があります（文字が小さくてスミマセン。ブラウザの拡大機能等で見ていただければ。。）。
他にもSamplesフォルダ配下にはいつものRDRAのサンプルとして挙げられている図書館システムと貸し会議室SaaSの初期要望.txtがありますので、自身の考えたシステムで利用する場合の参考にもしていただければと思います。
要件定義
さて、まずは「要件定義」です。
Cursorのプロンプト入力欄で「/」（スラッシュ）を入力するとRDRAAgentのコマンドが出てくるはずです。
そこで「/01-ZeroOne/01-フェーズごとの要件定義」または「/01-ZeroOne/01-一括要件定義」を選んでください。
お試しの場合、とりあえずは「一括要件定義」でいいと思います。
以下のようにフェーズ１からフェーズ５までの作業が実行されます。
「0_RDRAZeroOne」フォルダ配下には更にフェーズ毎にフォルダが切られておりまして、各フェーズに応じて必要なファイルが作成されていくのがわかります。
フェーズ１から５まで終わった結果が以下になります。
アクターや外部システム等、RDRAを知っている方であればおわかりになると思いますが、RDRAで扱う情報が出力されているのがわかります。
例えば「1_RDRA アクター.tsv」は以下のようになります。
そのシステム、今回は訪問介護システムに関係するアクターが挙げられています。
要件定義とはいえ、基本的にはRDRA Agent、つまりAIでアクターや業務、状態モデル等の洗い出しを行ってくれますので、こちらはチェックするのみとなります。
とはいえ、足りない部分があれば一旦初期要望.txtに戻り、追記を行って再度要件定義を実施します。
RDRAにおけるイテレーション
もし、最初の初期要望.txtにあまり情報が無かった場合、例えば私が要件定義を依頼されたもののの、あまり内容が思い浮かばない場合があると思います。
今までのRDRAのやり方であればお客様との打合せで直接インタビューを行うのですが、お客様としてもせめて叩き台が無いと話しづらいということもあるかと思います。
そういった場合は再度ここまで出力してもらった内容を元にAIに肉付けしてもらうのも手です。
例えば図書館のシステムで同様にフェーズ１～５を実行し、それを元に再度初期要望.txtを見直してもらった結果が以下になります（赤い行が削除、緑が追記です）。
「背景」も以下の１行だけだったのが、
「市内の全図書館を一括で管理するシステム」
以下のように色々と肉付けされていますので、これを元に再度ステークホルダーであるお客様と話し合い、どれが合っているか、間違っているかを直していくと更に詳細なものが出来上がります。
「市内の全図書館（中央館および分館）を一括で管理するシステムを導入し、蔵書・会員・貸出状況を全館で共有可能とする。
現状は館ごとに業務が分断されており、貸出・返却・予約・蔵書棚卸・蔵書補充などの業務が人手に依存しているため、職員の負担が大きくなっている。」
つまり、図書館業務に置いてあまり詳しくなくともAIの力を借りることで「とっかかり」ができるわけです。
それが合っているかどうかは実はあまり重要ではなく、RDRAは「コミュニケーションツール」でもありますので、このような形で叩き台を作り、それを元にお客様から「インタビュー」を行い、要件をより詳細に詰められるかどうかが重要となります。
そしてまたフェーズ１～５を実行し、より詳細な資料を作成していき、この後説明するRDRAGraph等でお客様と認識が合っているかを詰めていきます。
インタビューとインサイト
ここでちょっと横道に逸れますが、上で書いたように当社はお客様と要件定義を行うにあたっての聞き取りを「インタビュー」と呼んでいます。
聞き取りであれば「ヒアリング」でもいいじゃないかと思われるかもしれませんが、インタビュー＝Interview、「Inter」は「間」、「View」は見えているもの。つまり、お互いの間で見えているものが違うので、それをRDRAモデルなどで「合ってるよね？」と確認しながら進めていく——そのため「インタビュー」と呼んでいます。
そしてもう一つ、インタビューで大切にしていることがあります。
それは、お客様の中に融け込み、お客様の目線で物事を見るという姿勢です。
皆さんもご経験があるかもしれませんが、要件定義の段階ではお客様はまだ正解を知らず、その要望が明確になっていないことがあります。
そのため、インタビューした内容を元に我々から「インサイト」、つまり洞察した結果を描き出し、お客様にお見せする。このとき、お客様の立場に立てていなければ、的外れなインサイトになってしまいます。
そのために必要なのが「コミュニケーション」であり、そのためのツールとしてRDRAのような要件定義手法が存在すると思っています。
繰り返しになりますが、RDRAやRDRA Agentはあくまでフレームワークやツールであり、重要なのは如何にお客様とコミュニケーションを取り、インタビューを行い、インサイトを提示できるかです。
AI自体もそのための補助的な存在であり、プログラミング同様、要件定義を全て任せることはできません。
例えば、お客様がプロトタイプを触っていて「なんとなく使いにくい」とおっしゃったとき、その言葉の裏にある本当の課題——業務フローの問題なのか、UIの問題なのか、あるいは組織間の調整の問題なのか——を見抜くには、表情や声のトーン、言葉の裏等、様々な情報を読み取る必要があります。
さらに言えば、お客様自身がまだ言語化できていない潜在的なニーズを引き出すには、信頼関係の構築が不可欠となります。
こうした「人と人との間でしか生まれない理解」は、現時点のAIでは代替できないと考えています。
そういう意味では「EQ（心の知能指数）」というのも重要なファクターだと思っているのですが、これはまた別の機会でお話しできればと思います。
RDRAGraphへの取り込み
さて話は戻りまして、次にRDRA2.0で考えられたRDRAGraphというツールがありますので、そのツールに合わせて今まで作成されたデータを成形し、RDRAGraphで表示できるようにします。
コマンド「/02-RDRA/01-RDRAGraphを表示」を選択し、実行してみてください。
内部でデータが生成され、外部ウェブサイトとして用意されたRDRAGraphの画面が立ち上がります。
ここでちょっとつまづくかもしれないポイントがありまして、「1_RDRA」フォルダ配下の「関連データ.txt」の内容がこの画面が出た時点でクリップボードに貼り付けられている（コピーされている）必要があります。
そうしないと上のスクリーンショットのダイアログにある「クリップボードから読み込み」ボタンを押しても何も表示される「？」状態になってしまいます。
一応プロンプトでのやり取りを見ているとコピーのコマンドは実行されているようなのですが、私の環境ではうまくいきませんでした。
そういった場合はCursorで「関連データ.txt」を開き、自分でコピーした上で上記ブラウザのダイアログ「クリップボードから読み込み」をクリックしてもらうのが良いと思います。
そうすると以下のようにRDRAのコンテキスト図が表示されます。
更に上記図の「サービススタッフ管理コンテキスト」をクリックすると別ウィンドウで以下のようにそのコンテキストにおけるユースケースや状態が表示されます。
RDRA定義の妥当性の検証もできます。
では、更に論理データ構造やUIも検討してもらいましょう。
仕様の作成
「/03-RDRASpec/01-仕様の作成」を実行します。
すると以下のような論理データモデルがMermaidで出力されます。
Mermaidビューワーで見れば以下のように論理データ構造がグラフィカルに表示できていることがわかります。
あとは「03-画面編集の表示」を実行すると以下のような画面編集というページがローカルサーバーで起動します。
これはRDRA1.0の画面モデルと同じものといいますか、正確にはそれを更に進化させたものになります。
右側の一覧から例えば「訪問介護計画」ー＞「スケジュール調整」を選択すると「サービススタッフ要望確認画面」の表示内容、行える操作、対象データのCRUDが一目でわかるようになっています。
画面モデルはRDRA2.0では使われなくなったものなのですが、個人的にはあった方が良いのではないだろうかと思っていたものでして（最初に挙げた過去記事の「RDRAを使った要件定義その２ RDRA1.0と2.0の違い」でも触れています）、これがWeb画面上でより詳しく、わかりやすく参照できるようになったのは嬉しかったです。
終わりに
他にも色々と出力されているものについてご紹介したいと思うのですが、RDRAAgentの全てをこの記事だけで紹介することは難しいため、一旦ここまでとさせてください。
RDRAは様々な図（モデル）＝視点で要件、仕様を俯瞰し、辻妻が合わなければそこを修正して。。という流れを繰り返し行う必要があるのですが、各モデルにおいて抜け漏れを見つけるたび、あるいは仕様が変わるたびにアップデートする必要があり、それが負担となっていたことがありました。
しかしながらRDRAAgentを使うことで、そのイテレーションを素早く行うことができるわけです。そしてAIの力を借りて仕様の抜け漏れやそもそもの業務知識の不足を補うこともできます。
是非皆さま使ってみてはいかがでしょうか。
最後に、要件定義を経験された方には言わずもがなではございますが、要件定義自体は非常に難しいものであり、RDRAやRDRA Agentが銀の弾丸になるわけではありません。
とはいえ、拠り所や手がかりが無ければ要件定義はますます困難なものとなりますので、RDRAやRDRA Agent（AI）がそのとっかかりとなり、今皆様が行っている、あるいは行おうとしている要件定義が少しでも楽なものに、そして少しでも成功に近づいてくれれば嬉しい限りです。
当社ネクストスケープはこのように生成AIを始めとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。
（以下当社お問合せフォーム）
当社では一緒に働いてくれる仲間を募集しています。是非以下のサイトよりお申込みください。
