RDRA×見積りの全体像と現場の課題〜AI時代の要件定義と見積もりその1

TRACERYプロダクトマネージャーの haru です。

2025年10月31日（金）に開催された勉強会『BPStudy#221〜AI時代の要件定義+見積を学ぼう』の第3部では、神崎氏が開発した「RDRAAgent*1」と、ITシステム可視化協議会（MCIS）が中心となって作成している「RDRA×見積りシート*2」をもとに、「AI時代の要件定義と見積もり」をテーマとしたパネルディスカッションが行われました。本記事ではその時の様子をお伝えします*3。

AI時代の要件定義と見積もり

その１: RDRA×見積りの全体像と現場の課題（本記事）
その２: RDRAAgentとRDRA×見積りシートが生み出す新しい価値
その３: 見積もり業務の革新と今後の展望

パネラー：
- 神崎善司(かんざきぜんじ) 氏：以下、神崎
  - (株)バリューソース
- 藤貫美佐氏(ふじぬきみさ) 氏：以下、藤貫
  - (株)NTTデータ・フィナンシャルテクノロジー、ITシステム可視化協議会（MCIS）会長
- 濱井和夫氏(はまいかずお) 氏：以下、濱井
  - (株)NTTドコモソリューションズ
- 高崎健太郎(たかさきけんたろう) 氏：以下、高崎
  - (株)アクティア COO
モデレータ：
- 佐藤治夫(さとうはるお) ：以下、haru
  - (株)ビープラウド代表取締役社長、この記事の筆者

パネリストの紹介
RDRAとRDRA×見積りシートの全体像
要件定義・見積もりの現場における課題（As-Is）

パネリストの紹介

haru：第3部のパネルディスカッションを始めます。本日は、先ほどご発表いただいた神崎さんと藤貫さんに加えて、(株)NTTドコモソリューションズの濱井さんと、(株)アクティアの高崎さんにパネラーとしてご参加いただいています。

まずは、簡単に自己紹介をお願いいたします。

濱井：NTTドコモソリューションズの濱井です。昨年の7月にNTTコムウェアから現在の社名に変更いたしました。

普段はSI業務においてプロジェクトマネジメントを担当する傍ら、IIBA*4（国際ビジネスアナリシス協会）にて、ビジネスアナリシス（BA）の普及活動に従事しています。

要件定義などの領域に強い関心があり、今回のディスカッションに参加させていただきました。

高崎：(株)アクティアでCOOを務めている高崎です。現在はCOOとしての業務よりも現場に出ることの方が多く、業務ドメインをいかにシステムへと繋げていくかを探求しています。

日々、さまざまなモデリング手法を学んでおり、本日はその知見を共有できればと考えています。

神崎：(株)バリューソースの神崎です。主に要件定義の支援や既存システムの可視化を行っています。

ここ数年は大規模言語モデル（LLM）に注力しており、いかにLLMに要件定義をさせるかという点に特化して活動しています。

藤貫：(株)NTTデータ・フィナンシャルテクノロジーの藤貫です。併せてITシステム可視化協議会（MCIS）の会長も務めております。

長年にわたり見積もりや開発管理プロセスに携わってきました。現在は定量化技法を企業内でいかに活用するかを専門領域として活動しています。

RDRAとRDRA×見積りシートの全体像

haru：本題に入る前に、本日のディスカッションで扱う2つのツール、RDRAとRDRA×見積りシートの全体像を再確認させてください（下図）。

RDRA側では、情報を階層構造として整理します。システム全体を業務で分割し、さらにそれをビジネスフローに対応するBUC（Business Use Case）という単位で細分化していきます。

業務フローのアクティビティから、システムの使用場面であるユースケースを抽出し、そこから画面、イベント（バッチ処理やAPI連携など）、情報（テーブルやエンティティ）を特定していきます。これらがRDRAの成果物です。

このRDRAの成果物を受け取り、RDRA×見積りシート側でシンプルファンクションポイント（SFP）を用いて見積もりを行います。SFPは、要素処理（EP：Elementary Process）と論理ファイル（LF：Logical File）に基づいて計測する手法です。

たとえば、画面3つとイベント1つであれば「4 × 4.6 = 18.4ポイント」、テーブルが4つあれば「4 × 7 = 28ポイント」といった具合に合計を算出します。

藤貫さんの作成した計算式では、登録系の画面は重みを考慮して係数を3とするなど、実務に即した調整がなされています。

さらに、このSFPのポイントをベースに、ウォーターフォール型とアジャイル型それぞれの見積りシートが用意されており、専門家である藤貫さんが作成された非常に精度の高いものになっています。

加えて、神崎さんが開発したRDRAAgentを活用すれば、LLMによってRDRAのモデルをテキストベースで自動生成できます。そのデータをスプレッドシートに貼り付けるだけで、概算見積もりまでが自動的に算出される仕組みです。

これに加え、テキストデータをグラフィカルに表示するRDRAGraphというツールも備わっています。

要件定義・見積もりの現場における課題（As-Is）

haru：それではパネルディスカッションに入っていきます。

最初の質問は「要件定義や見積もりに関して、開発現場にはどのような課題があるか」という点です。

これらのツールを使用しない従来（As-Is）の状況における課題について、まずは高崎さんの見解をお聞かせください。

高崎：要件定義や見積もりの段階以前に、そもそも「何を作るべきか」という点において、関係者間での認識合わせが非常に困難であると感じています。

これは顧客やプロダクトマネージャーとの間だけでなく、開発チーム内部でも同様です。そのため、可視化の重要性を痛感しています。

普段の業務でも、ホワイトボードへの書き出しやポンチ絵の作成に多くの時間を費やしていますが、この「認識を共有するための土台作り」が最も労力を要する部分ではないでしょうか。

濱井：同感です。要件定義の際、断片的な会話はできても、それが全体の中でどのような位置付けなのか、また他の要件と整合性が取れているのかを判断するのは非常に難しい作業です。

RDRAを用いて全体像を俯瞰し、抜け漏れがないことを証明できるのは大きな利点だと思います。

また見積もりについても、短期間で回答を求められるRFP*5などの場面で、精緻な見積もりは難しくとも、概略の規模感を迅速に算出できる点は、意思決定において非常に有効であると考えています。

加えて、グラフツールなどを用いて多角的なビューから関係性を確認することは、全体の整合性を保つ上で極めて有効だと感じています。

haru：RDRAのスプレッドシートには不整合をチェックする機能があり、そこを解消していくことで全体の整合性を担保できる仕組みになっています。

続いて藤貫さん、MCISでの活動を通じて感じる見積もりの課題について教えてください。

藤貫：見積もりの妥当性が失われる主な原因は、要件定義が不十分であること、そしてその成果物がユーザーに正しく理解されていないことにあります。

理解が伴わないまま見積もりを行っても机上の空論となりやすく、要件が不明確なままでは見積もりの幅が極端に広がってしまいます。

関係者全員が共通理解を持てる形で可視化することが見積もりの第一歩であり、その意味でRDRAの手法には非常に感銘を受けました。

haru：私自身の経験でも、要件の合意前に予算確保のための金額提示を求められ、不確かな数字が独り歩きすることへの危惧を感じる場面が多々ありました。

皆さんの話を伺って共通して見えてきたのは、要件定義と見積もりの根底にある「全体像を可視化し、関係者間で共通理解を形成する」という課題です。

次回は、RDRAAgentとRDRA×見積りシートを活用することで開発現場に生まれる新しい価値（To-Be）について議論が進みます。

tracery.jp

この記事を書いた人