TRACERY Lab.(トレラボ)

TRACERY開発チームが、要件定義を中心として、システム開発で役立つ考え方や手法を紹介します。

見積り根拠の明確化と今後の展望〜AI時代の要件定義と見積もり その3

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

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

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

  • パネラー
    • 神崎善司(かんざき ぜんじ) 氏:以下、神崎
      • (株)バリューソース
    • 藤貫美佐氏(ふじぬき みさ) 氏:以下、藤貫
    • 濱井和夫氏(はまい かずお) 氏:以下、濱井
      • (株)NTTドコモソリューションズ
    • 高崎健太郎(たかさき けんたろう) 氏:以下、高崎
  • モデレータ
    • 佐藤 治夫(さとう はるお) :以下、haru

PMO視点での見積もり根拠の明確化

haru:前回は、RDRAAgentとRDRA×見積りシートが生み出す新しい価値(To-Be)について議論しました。

今回は、まず見積もり業務の観点からこのツールの価値を掘り下げます。

濱井さん、PMO*4の立場でプロジェクトをチェックする際、このツールはどのように役立ちそうでしょうか。

濱井:何よりも見積もりの根拠が明確になる点が最大の価値です。

従来の「とりあえず多めに積む」といった不透明な積み上げや、外部パートナーの見積もりに一定割合を上乗せするような安易な手法ではなく、裏付けのある安全な見積もりが可能になります。

説明責任を果たす上でも非常に強力な武器になるはずです。

KKD精度を磨くための比較対象としての活用

haru:高崎さんはいかがですか。

高崎KKDの精度を磨くための比較対象として活用したいですね。

AIによる体系的な算出結果と自分の直感を突き合わせることで、より精度の高い見積もりができるようになると感じています。

多忙を理由に曖昧なまま進めるのではなく、こうした客観的な指標を持つことは大切です。

haru:私の会社でも、見積もりの遅延が発注やスケジュールの遅れに直結することが課題となっていました。

RDRAでEP*5やLF*6を素早く算出し、短期間で根拠のある数字を出せれば、ビジネスのスピードが格段に上がります。これは現場にとって非常に大きな改善です。

今後の展望

haru:それでは最後に、今後このジャンルで取り組んでいきたい展望についてお聞かせください。

まずは神崎さんからお願いいたします。

神崎氏:仕様駆動開発との連携と画面ベースのリバースエンジニアリング

神崎:私は仕様駆動開発との連携を強化し、RDRAのモデルからプロトタイプを即座に生成する流れを作りたいと考えています。

また、システムを導入する具体的な環境(部署の制約やアクターの人数など)をいかに記述し、AIに理解させるかも重要な検討課題です。

ソースコードの解析よりも、画面ベースでの要件把握の方が実業務理解には近いため、画面一覧からボトムアップでRDRAのモデルを構築する仕組みも開発中です。

ドキュメントが残っていない現場でも、現行システムの画面から要件をリバースエンジニアリングできるようにしたいと考えています。

藤貫氏:実プロジェクトでのフィードバックと既存システム機能追加への適用

藤貫:私はこのツールの実用性をさらに磨き上げたいと考えています。

理論だけではなく、実プロジェクトでのフィードバックを元に改善を重ねていく予定です。MCISでの研究会等を通じて、現場での活用事例を深掘りしたいですね。

また、現在の新規開発向けだけでなく、既存システムの機能追加プロジェクトへいかに適用するかという実務的な課題にも取り組んでいきます。

高崎氏:手法を使い倒してAIを使いこなすスキルを磨く

高崎:まずは、神崎さんや藤貫さんが主導されているこれらの手法を、一人のフォロワーとして徹底的に使い倒し、AIを使いこなすスキルを磨いていきたいと考えています。

実際に触り続けることで見えてくる課題を大切にしたいです。

濱井氏:社内プロジェクトでの試行と既存システムのリバースエンジニアリング

濱井:非常に有効な手法だと確信しています。まずは自分の担当業務にしっかりと取り入れ、今年度は社内のさまざまなプロジェクトで試行したいと考えています。

生成AIを用いた既存システムのリバースエンジニアリングなど、可能性を広げていく活動に積極的に参加していきたいです。

上流の企画段階を支援する「匠MethodAgent」の開発

haru:ありがとうございます。私も現場でこれらを活用していきたいと考えています。

また、これに刺激を受けて、さらに上流の企画段階をサポートする「匠MethodAgent」の開発を進めています*7

企画のアイデアからモデルを生成し、RDRAの初期要望テキストへ繋げる仕組みで、2026年2月の公開を予定しています。

本日のパネルディスカッションを通じて、RDRAAgentとRDRA×見積りシートが、要件定義と見積もりの現場に「可視化と共通理解」「定量的な根拠」「サイクルの高速化」をもたらすことが明確になったと感じます。

登壇いただいた神崎さん、藤貫さん、そしてパネラーの濱井さん、高崎さん、本日は貴重なお話をありがとうございました。

この記事を書いた人
haru

佐藤治夫。株式会社ビープラウド代表取締役社長。TRACERYのプロダクトマネージャー。エンジニアとして活動を始めて以来、モデリングを中心としたソフトウェアエンジニアリングを実践している。Xアカウント: https://x.com/haru860

*1:LLM(大規模言語モデル)を活用し、要件の叩き台となるRDRA形式のモデルデータを自動生成する支援ツール。 https://github.com/kanzaki/RDRAAgent_v0.6

*2:RDRAの定義・分析シートと連携し、シンプルファンクションポイント法に基づいて工数・金額・期間の見積りを自動算出するスプレッドシート。

*3:伝わりやすくする目的で、話の流れを一部再構成しています。

*4:Project Management Office:プロジェクトマネジメントオフィス。組織内のプロジェクトマネジメントを支援・統括する部門や仕組み。プロジェクトの可視化、品質チェック、ガバナンスなどを担う。

*5:Elementary Process:要素処理:ユーザーや外部システムとのやり取りを伴う処理。SFPの詳細は、https://tracery.jp/articles/entry/rdra-estimation-method-automatically-calculating-effort-and-cost-from-requirements-model を参照のこと。

*6:Logical File:論理ファイル:システムが保持する論理的なデータ

*7:2026年2月17日に匠MethodAgentを公開済み。 https://github.com/haru860/takumi-method-agent/