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

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

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

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

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

• パネラー：
  • 神崎善司(かんざき ぜんじ) 氏：以下、神崎
    • (株)バリューソース
  • 藤貫美佐氏(ふじぬき みさ) 氏：以下、藤貫
    • (株)NTTデータ・フィナンシャルテクノロジー、ITシステム可視化協議会（MCIS）会長
  • 濱井和夫氏(はまい かずお) 氏：以下、濱井
    • (株)NTTドコモソリューションズ
  • 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
    • (株)アクティア COO
• モデレータ：
  • 佐藤 治夫(さとう はるお) ：以下、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/

RDRAAgentとRDRA×見積りシートが生み出す新しい価値〜AI時代の要件定義と見積もり その2

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

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

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

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

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

価格競争からの脱却と商談初期段階での解像度向上

haru：前回は、要件定義や見積もりの現場における課題（As-Is）について議論しました。

今回は、RDRAAgentとRDRA×見積りシートを活用することで、どのような新しい価値が生まれるかというTo-Beのテーマで議論していきます。

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

神崎：見積もりという観点では、契約前の競合案件において価格だけで判断される状況を打破できる可能性があります。

顧客の予算感と必要な機能のコストが乖離している場合、単に予算に合わせるのではなく、提供価値をいかに明確にするかが鍵となります。

商談段階では詳細な業務や機能が不透明なことも多いですが、AIを活用して解像度を上げることで、初期段階から具体的なビジネスの議論が可能になる点は大きな価値です。

haru：コンペの際、大規模案件の見積もりには膨大な工数がかかりますが、RDRAAgentとRDRA×見積りシートを使えば数日で概算を出せる可能性があります。

最初の要件の「叩き台」をAIが即座に生成してくれるメリットは大きいですね。

要件定義のキャッチボールサイクルの劇的な短縮

haru：濱井さんはどうお考えですか。

濱井：顧客自身も要望が漠然としていることが多いため、AIによって全体像が示されることで、「ここはこうしたい」といった真のニーズを引き出しやすくなります。

要件定義のキャッチボールのサイクルを劇的に早めることができるでしょう。

もし仮に、顧客に具体的なこだわりがない場合、提示された内容でそのまま進んでしまうという危うさは孕んでいますが、サイクルを迅速化できるメリットは大きいと考えます。

神崎：ただし、AIは情報を膨らませがちですので、いかに適切に制御するかが運用上の重要事項となります。

haru：私自身、RDRAAgentのサンプルで訪問介護システムを試作してみましたが、画面、イベント、データがバランスよく抽出されており、非常に実用的だと感じました。

KKDと体系的な数値の比較による見積り精度の向上

haru：高崎さん、見積もりシートとRDRAの連携についてはどう思われますか。

高崎：これまでは時間的制約からKKD（経験・勘・度胸）に頼らざるを得ない場面も多かったのですが、体系的な数値と比較することで、自身の見積もり精度の向上も期待できそうです。

何より、専門家が作成した信頼できる見積もりシートを活用できる点は非常に心強いです。

haru：このシートで特に秀逸なのは、「工数に対する開発期間の妥当性」を瞬時にグラフ化できる点です。経験や勘で「これは厳しい」と感じていた内容を、客観的なデータとして可視化できます。

たとえば、100人月規模の開発に対して極端な短納期を求められた場合でも、複数の業界団体が公開している標準データと比較することで、スケジュールに論理的な無理があることを、経営層や顧客へ定量的に説明する強力な根拠になります。

感覚論ではなく、データに基づいて議論できるため、現場任せの属人的な判断から脱却し、合意形成やリスク説明の精度を大きく高められる点も大きな価値です。

要件定義と見積もりの同時進行による早期スコープ調整

haru：藤貫さん、要件定義のスピードアップは見積もり側にどのような影響を与えますか。

藤貫：要件定義と見積もりが同時に進行できる点は極めて重要です。

要求が膨らみすぎた場合でも、リアルタイムに規模感が把握できれば、早い段階でスコープの調整や意思決定を行うことができます。

これまではこの調整に多大な手間がかかっていましたが、可視化ツールがあればよりスムーズに管理できるようになるでしょう。

シンプルファンクションポイント（SFP）の堅牢性

haru：私は今回、このシートで採用されているシンプルファンクションポイント（SFP）を学習しましたが、『シンプル』という接頭辞とは裏腹に、本格的なIFPUG法*4と比較しても計測結果のブレが少ない、非常に堅牢な手法であることを知りました。

藤貫：その通りです。何をファンクションとして捉えるかという根本的な考え方は同じであり、個々の複雑さよりもファンクションの種類と数を重視しています。

アクターごとに振る舞いが異なれば別のファンクションとしてカウントするRDRAの考え方を踏襲しており、実務上十分な精度を保てると考えています。

haru：今回の議論を通じて、RDRAAgentとRDRA×見積りシートの活用が「商談初期段階の解像度向上」「要件定義サイクルの高速化」「定量化された見積もり」「要件定義と見積もりの同時進行」という4つの新しい価値を生み出すことが見えてきました。

次回は、PMOの観点から見たRDRA×見積りシートの価値と、各パネリストの今後の展望について議論が進みます。

この記事を書いた人

haru

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

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

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

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

*4:IFPUG: International Function Point Users Group。ファンクションポイント法の標準化を推進する国際組織。同団体が定めるIFPUG法やシンプルファンクションポイントは、ファンクションポイント法のデファクトスタンダードとして広く利用されている。

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
    • (株)ビープラウド代表取締役社長、この記事の筆者

パネリストの紹介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この記事を書いた人

haru

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

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

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

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

*4:International Institute of Business Analysis：国際ビジネスアナリシス協会。ビジネスアナリシスの専門家団体。 https://www.iiba.org/

*5:Request For Proposal：提案依頼書。発注者が受注候補のベンダーに対し、提案を依頼するために発行する文書。

RDRAで見積りを行う方法その4〜アジャイル開発編

シリーズ: モデルベース要件定義手法RDRA

• 要件定義手法RDRAの概要と全体像
• RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
• RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
• RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
• RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
• RDRAの成果物と設計プロセスとの連携
• 要件定義をAIで加速する「RDRAAgent」その1〜LLMがモデルの叩き台を自動生成
• 要件定義をAIで加速する「RDRAAgent」その2〜要件を仕様化するRDRASpec
• RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する
• RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編
• RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編
• RDRAで見積りを行う方法その4〜アジャイル開発編（本記事）

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

前回の記事までは、「RDRA×見積りシート」によるウォーターフォール開発の見積り方法を解説してきました。

アジャイル開発では、「一定の人数のチームを組成し、その体制を維持しながら一定期間で開発を進める」という特性があり、ウォーターフォール型開発とは異なる見積りアプローチが必要です。

これは、予算確保や契約上の制約（アジャイル開発では準委任契約が採用されることが多い）により、一定期間・一定体制での計画が求められるケースが多いためです。

本記事では、「RDRA×見積りシート」のアジャイル開発用見積りシートを用いた見積りの考え方と全体の流れを解説します。

アジャイル開発用見積りシートの全体像

下図にアジャイル開発用見積りシートの全体像を示します。

アジャイル開発用見積りシートの全体像

アジャイル開発用見積りシートでは、要件モデルを起点に、次の4ステップで見積りを導出します。

1. 要件モデルから機能規模（SFP）を算出
2. 機能規模を生産性で割り、開発工数（人月）を算出
3. チーム体制から開発期間を算出
4. ロール別の要員数と単価から総費用を算出

ウォーターフォール開発と同様に、要件モデル → 規模 → 工数 → 期間 → 費用という一貫した流れで見積りを行いますが、アジャイル開発では「スコープを固定する」のではなく、「体制と期間を固定する」点が大きく異なります。

SFPを算出し、SFPを開発工数（人月）に変換する

SFPとは、シンプルファンクションポイント法（Simple Function Point）の略で、システムの機能規模を簡易的に定量化するための手法です。

要件モデルからSFPを算出し、それを生産性で割ることで開発工数（人月）を導出します。このプロセス自体はウォーターフォール用見積りシートと共通です。

なお、アジャイル開発ではストーリーポイントを用いるケースも多くありますが、SFPは以下の点で有効です。

• 要件モデルと直接対応付けられる
• プロジェクト初期段階でも算出可能
• 見積りの客観性・再現性を担保できる

そのため、アジャイル開発用見積りシートではストーリーポイントの代替ではなく、初期見積りの基準軸としてSFPを活用します。

実務では、この初期見積りをもとにスプリント開始後にストーリーポイントへ再スケーリングする、といった使い方も可能です。

SFPによる開発工数の算出方法の詳細については、RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編の「SFPを算出する」「SFPを開発工数（人月）に変換する」の章を参照してください。

SFPを開発工数（人月）に変換する

開発期間を算出する

開発工数が算出できたら、次に「どの期間で開発できるか」をチーム体制から導出します。

アジャイル開発では、一定のチームを維持しながら開発を進めるため、以下の考え方を取ります。

• 期間ではなく体制（キャパシティ）を固定する
• 工数をそのキャパシティで割ることで期間を算出する

具体的には、シニア開発者・開発メンバーそれぞれの人数と稼働率をもとに、月あたりの開発要員数を算出し、次の式で開発期間を求めます。

開発期間 ＝ 全体の開発工数 ÷ 月あたりの開発要員数

開発期間を算出し、月あたりのSFP数を確認する

たとえば、全体の開発工数が16人月であり、月あたりの開発要員数が4人の場合、開発期間は4か月となります。

ただし、この計算はあくまで理想的な並列化を前提とした近似値です。実務では以下の要因により乖離が発生します。

• コミュニケーションコストの増加
• スキル差による生産性のばらつき
• 作業の依存関係による並列化の制約

そのため、算出結果はそのまま確定値として扱うのではなく、後述する見積り誤差とあわせて判断することが重要です。

実務では、この理論値に対してバッファを持たせる、もしくは過去実績から補正係数を掛けるといった調整が一般的です。

総費用を算出する

次に、開発体制をロール単位で分解し、それぞれの要員数と単価から総費用を算出します。

対象となる主なロールは以下の通りです。

• プロダクトオーナー
• 開発マネージャー(SM)
• シニア開発メンバー
• 開発メンバー
• インフラメンバー
• 移行メンバー

それぞれについて、月あたりの要員数と単価を設定し、以下の式で費用を算出します。

ロール別費用 ＝ 月あたりの要員数 × 単価 × 開発期間

これを合計することで総費用を導出します（下図）。

総費用を算出する

ロールごとに分けて積算することで、以下のメリットがあります。

• 費用の内訳が明確になる
• 見積りの妥当性を説明しやすくなる
• 要員構成の調整によるコスト最適化が可能になる

なお実務では、インフラや移行といったロールは期間全体で均等に投入されるとは限らず、特定のタイミングで増減します。

本シートでは平均化した値として扱いつつ、必要に応じて補正する前提で利用します。

見積り誤差の推定

見積りは単一の数値ではなく、幅（レンジ）で提示することが重要です。

特にアジャイル開発では、スコープが変動する前提で進むため、不確実性を織り込んだ見積りが不可欠です。

アジャイル開発用見積りシートでは、ウォーターフォール用見積りシートと同様に、要件の検討状況を設定することで、総費用の下限〜上限を自動算出できます。

このレンジは主に以下の要因で変動します。

• 要件の不確実性
• 技術的難易度の不透明さ
• チームの生産性のばらつき

見積りレンジを提示することで、関係者は「どの程度のリスクを含んだ計画なのか」を理解した上で意思決定できます。

初期段階では±50%程度の幅を持つことも珍しくなく、要件の具体化に伴い徐々に収束していきます。

考え方の詳細はRDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編の「見積り誤差の推定」の章を参照してください。

見積り誤差の推定

最後に

本記事では、「RDRA×見積りシート」のアジャイル開発用見積りシートを用いて、要件モデルから算出したSFPを起点に、体制（キャパシティ）から開発期間を導き、ロール別の要員数と単価から総費用を算出するまでの流れを解説しました。

アジャイル開発の見積りは、「スコープを固定する」のではなく、「体制と期間を固定し、その中で提供できる価値を最大化する」という前提に立つ必要があります。そのため、見積りは単なる金額算出ではなく、どの体制で、どの程度の価値を、どの期間で提供するのかを定義する行為でもあります。

「RDRA×見積りシート」を用いることで、要件モデルという共通の基盤から、ウォーターフォール・アジャイルいずれの開発手法においても一貫したロジックで見積りを導出できます。 これにより、見積りを経験や勘に依存させるのではなく、説明可能で再現性のあるプロセスとして扱うことが可能になります。

プロジェクト初期の見積り精度を高めたい場合や、顧客への説明責任を果たす必要がある場面で、本手法は特に有効です。

実務では、この見積り結果を初期計画として活用し、開発の進行に応じて継続的に見直していくことが重要です。本手法が、そのための基準軸として機能すれば幸いです。

この記事を書いた人

haru

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

RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編

シリーズ: モデルベース要件定義手法RDRA

• 要件定義手法RDRAの概要と全体像
• RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
• RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
• RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
• RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
• RDRAの成果物と設計プロセスとの連携
• 要件定義をAIで加速する「RDRAAgent」その1〜LLMがモデルの叩き台を自動生成
• 要件定義をAIで加速する「RDRAAgent」その2〜要件を仕様化するRDRASpec
• RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する
• RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編
• RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編（本記事）
• RDRAで見積りを行う方法その4〜アジャイル開発編

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

前回の記事では、「RDRA×見積りシート」を用いてSFP（Simple Function Point）から工数を算出する方法を解説しました。

しかし、工数が算出できただけでは、見積りとしては十分とは言えません。ステークホルダーが最終的に知りたいのは、「いつ完成するのか（工期）」と「いくらかかるのか（金額）」です。

本記事では、算出した工数を起点に、COCOMOモデル*1による工期の算出、要件の不確実性を踏まえた見積りレンジの提示、そしてロール別単金を用いた見積金額の算出までを解説し、「RDRA×見積りシート」を活用した見積りの全体像を示します。

工期（標準）とリリース時期

工期は工数をもとに算出します。

「RDRA×見積りシート」では、工期の算出にCOCOMOモデルを採用しています。

COCOMOモデルは、多数のプロジェクト実績に基づく統計モデルであり、工期や工数の見積りを一定の根拠に基づいて算出できる点に特徴があります。

経験や勘に依存しがちな見積りに対して、パラメータ化されたモデルを用いることで、客観性や再現性を高められる点に強みがあります。

「RDRA×見積りシート」では、算出された工数をもとに、COCOMOモデルに基づく非線形の関係式を用いて工期へと変換しています。これにより、単純な人数割りでは表現できない現実的な制約(人員を増やしても工期が比例して短縮されない特性)を反映した、現実的なスケジュールの目安を得ることができます。

特に重要なのは、この特性により、「遅れているから人を増やせば間に合う」といった非現実的な判断を防げる点です。

COCOMOモデルを用いることで、スケジュールの妥当性を一定の根拠に基づいて評価でき、無理のある計画を早い段階で見直すための判断材料を得ることが可能になります。

これは、いわゆるブルックスの法則*2（遅れているプロジェクトに人員を追加すると、さらに遅れる）とも整合する考え方です。

下図では、総工数42.4人月を前提に、工期7.0か月を算出しています。さらに、「構築開始」欄に開始日を入力することで、リリース時期を具体的な年月日として即座に算出できます。

工期（標準）とリリース時期

工期の算出・補正

「構築開始日」と工期（標準）の月数をもとに、各工程（基本設計・詳細設計・製造・結合テスト・総合テスト）の工期（月数）と開始日および終了日が自動的に算出されます。

工期の算出・補正

各工程の月数は「工期（標準）× 各工程の比率」で算出され、以下の比率に基づいて分配されます。

• 基本設計: 20.0%
• 詳細設計: 15.0%
• 製造: 25.0%
• 結合テスト: 20.0%
• 総合テスト: 20.0%

この比率は「ソフトウェアデータ白書2018-2019（IPA発行）*3」を参考にした、一般的な初期値です。

上記比率はあくまでベースラインであり、すべてのプロジェクトにそのまま適用できるものではありません。

たとえば、要件の複雑性が高い場合や不確実性が大きい場合は設計工程の比率を高める、品質要求が厳しい場合はテスト工程の比率を厚くする、といった調整が前提となります。

そのため、「RDRA×見積りシート」ではこの比率を出発点としつつ、「工期補正」欄によってプロジェクト特性に応じた柔軟な調整を行うことを想定しています。

工程ごとのスケジュールを調整したい場合は、「工期補正」欄の割合を変更することで、プロジェクト特性に応じた柔軟な調整が可能です。

工期、工数の最終調整

ここまでの入力により、工数と工期が算出されます。「9. 工数・期間サマリ」欄では、全工程の工期と工数をまとめて確認でき、全体像を把握できます（下図）。

工期、工数の最終調整

最終的な数値を調整したい場合は、青色の入力欄を編集することで、「全工程工数」と「全工程期間」が再計算されます。

【注意】 「9. 工数・期間サマリ」欄で行った調整は、前段で入力した各項目の値には反映されません。そのため、前段の各入力値を修正するか、「9. 工数・期間サマリ」欄で最終調整を行うかは、プロジェクトの状況や運用方針に応じて選択してください。

見積り誤差の推定

見積りは単一の数値として提示するよりも、幅（レンジ）を持たせることで不確実性を明示でき、リスクを織り込んだ判断が可能になります。特に要件が十分に固まっていない段階では、確定値ではなく幅を提示することで、過度な期待や誤解を防ぎ、関係者間で現実的な合意形成を行いやすくなります。

「RDRA×見積りシート」では、要件の検討状況に応じて、工数および工期の幅（下限〜上限）を自動算出します。幅の大きさは「要件の検討状況」欄に設定した値によって決まり、要件の不確実性が高い場合は幅が広く、要件が具体化するにつれて幅が狭くなる仕組みになっています（下図）。

見積り誤差の推定

これにより、初期検討フェーズでは幅を持たせた概算見積りを提示し、要件が固まるにつれて徐々に精緻化していく、といった段階的な見積り運用が可能になります。

要件の検討状況は、以下の4段階から選択できます。設定した段階に応じて、見積りの幅（下限〜上限）が自動的に決定されます。

• A：ほぼすべての要件が洗い出され、粒度も揃っている：-15％ 〜 +20％
• B：主要な要件は抽出されているが、粒度にばらつきがある：-20％ 〜 +30％
• C：大まかな要件は整理されている：-30％ 〜 +50％
• D：要件が非常に粗く、未確定要素が多い：-50％ 〜 +100％

この区分により、要件の成熟度に応じた見積りレンジを設定でき、不確実性の大きさを数値として明示できます。

見積金額の算出

見積りはいよいよ最終段階です。

各ロールの単金（1人あたりの月額単価）に工数を掛け合わせることで、見積金額が算出されます（下図）。

見積金額

単金は、開発プロジェクトに関与するロールごとに設定します。ロール別に単価を設定することで、体制構成やスキルレベルの違いを反映でき、より実態に即した見積りが可能になります。また、どのロールにどれだけコストがかかっているかが明確になるため、コスト構造の把握や体制最適化の検討にも活用できます。

単価は企業や案件特性によって異なるため、自社の原価構造や市場単価を踏まえて適切な値を設定してください。

ロールと工数の対応関係は以下のとおりです。各ロールの想定業務と、単金設定時に考慮すべきポイントを併記します。

ロールと工数	説明
管理者：管理工数	プロジェクトマネージャー(PM)やプロジェクトマネジメントオフィス(PMO)など、進捗・品質・リスク・ステークホルダー調整を担うロール。シニア層が中心になるため単金は相対的に高めに設定されるのが一般的。複数のPMO要員やアシスタントが関わる場合は、その平均人月単価を設定するか、役割に応じて後述の「その他担当者」に按分する運用が考えられる。
開発担当者：開発工数	基本設計・詳細設計・製造・テストなど、実装の中核工程を担うロール。アーキテクト／リードエンジニア／一般メンバーといった階層がある場合は、体制比率を踏まえた加重平均の単金を設定すると実態に即す。
基盤担当者：基盤工数	インフラ構築、ネットワーク、クラウド環境(IaC含む)、ミドルウェア、セキュリティ基盤など、非機能要件の実装を担うロール。クラウド利用料などのランニングコストは単金とは別枠で管理する点に注意が必要。
移行担当者：移行工数	既存システムからのデータ移行、移行ツールの開発、リハーサル、切替作業を担うロール。短期集中で稼働する特性があるため、ピーク時の要員単価を基準に設定するのが実務的。
運用準備担当者：運用準備工数	運用設計、手順書整備、運用チームへの引き継ぎ、監視・バックアップ・障害対応体制の構築を担うロール。リリース直前に稼働が集中するため、開発担当者とは別立てで工数・単金を見積もることで、運用移行フェーズの見落としを防げる。
その他担当者：その他の工数	上記のロールに収まらない作業に対応するバッファ枠。ユーザー部門との調整役、ドキュメンテーション専任、技術調査・PoC要員、予備費的なコンティンジェンシーの按分先などに活用できる。何に使っているかを明記しておくと、金額交渉の場で説明がしやすくなる。

このようにロール別に単金を設定し、工数と掛け合わせることで、総額だけでなく内訳の根拠が明確になり、見積りの妥当性を説明しやすくなります。

また、ロール別の内訳はそのまま体制計画の叩き台としても機能するため、見積りフェーズと体制設計フェーズの接続がスムーズになるというメリットもあります。

最後に

本記事では、前回の記事で算出した工数をもとに、COCOMOモデルによる工期の導出、工程別スケジュールの算出・補正、見積り誤差のレンジ提示、そしてロール別単金による見積金額の算出までを解説しました。

これにより、「RDRA×見積りシート」を使ったウォーターフォール開発の見積りの全体像が完成しました。

要件モデルから出発し、SFP → 工数 → 工期 → 金額と、一貫した根拠の連鎖で見積りを導出できることがお分かりいただけたかと思います。

「RDRA×見積りシート」では、見積りの各段階で補正や調整の仕組みが用意されているため、統計モデルによる客観性を保ちながら、プロジェクト固有の事情を反映した現実的な見積りを作成できます。

また、見積り誤差のレンジを提示することで、要件の成熟度に応じた不確実性をステークホルダーと共有でき、過度な期待や認識のズレを防ぐことにも繋がります。

次回は「RDRA×見積りシート」のアジャイル開発における活用方法を紹介します。

tracery.jp

この記事を書いた人

haru

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

*1:ソフトウェア開発プロジェクトにかかる工数や期間などを見積もる手法の一つ。詳細は、IT用語辞典 e-Words COCOMO【COnstructive COst MOdel】 を参照のこと。

*2:ソフトウェア開発におけるプロジェクトマネジメントの経験則であり、「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」という原理を示す。1975年にフレデリック・P・ブルックスが著書『人月の神話（The Mythical Man-Month）』で提唱した。

*3:「ソフトウェアデータ白書2018-2019（IPA発行）」のp.179、図表7-1-3「工程別の実績月数の比率の基本統計量（新規開発）」における"中央値"。

RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編

シリーズ: モデルベース要件定義手法RDRA

• 要件定義手法RDRAの概要と全体像
• RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
• RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
• RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
• RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
• RDRAの成果物と設計プロセスとの連携
• 要件定義をAIで加速する「RDRAAgent」その1〜LLMがモデルの叩き台を自動生成
• 要件定義をAIで加速する「RDRAAgent」その2〜要件を仕様化するRDRASpec
• RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する
• RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編（本記事）
• RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編
• RDRAで見積りを行う方法その4〜アジャイル開発編

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

システム開発の見積りは、多くの場合「経験」と「勘」に依存しています。 同じシステムでも、担当者によって見積りが大きく異なることも珍しくありません。

「RDRAx見積りシート」は、RDRAで整理された要件モデルをもとに、機能規模（SFP）を算出し、それを工数・工期・見積金額に変換することで、根拠のある見積りを作成できる仕組みです。

本記事では、ウォーターフォール用見積りシートを例に、最初のステップである「工数算出」の仕組みと考え方を解説します。

ウォーターフォール用見積りシートの全体像

下図にウォーターフォール用見積りシートの全体像を示します。

ウォーターフォール用見積りシートの全体像

ウォーターフォール用見積りシートは、次の3段階で見積りを算出します。

1. 要件モデルから機能規模（SFP）を算出
2. 機能規模を生産性で割り、開発工数を算出
3. 工数から工期と見積金額を算出

本記事では、そのうち工数の算出方法に絞って説明します。

SFPを算出する

SFPとは、シンプルファンクションポイント法（Simple Function Point）の略で、システムの機能規模を簡易的に定量化するための計測手法です。

「RDRAx見積りシート」のSFPでは、次の2種類の要素をカウントすることで開発規模をポイントとして算出します。

• EP（要素処理）
  • RDRAの要素
    • 画面
    • イベント（外部システムとのインターフェース）
    • タイマー（定時バッチ処理）
• LF（論理ファイル）
  • RDRAの要素
    • 情報（データ）

SFPの詳細は、前回の記事の「シンプルファンクションポイント法（SFP）とは」を参照してください。

EP数とLF数の確定

「参照設定」シートで実施します。

EP（要素処理）基礎数は、RDRAから抽出した画面・イベント・タイマーを元に自動で算出されます。算出値を変更したい場合は、「EP基礎数（補正）」列に値を入力することで上書きできます（下図）。

EP基礎数の補正

たとえば、特定の画面やイベントなどのビジネスロジックが複雑であることが事前に分かっている場合は、その複雑さを反映した値に修正することで、より実態に即した工数算出が可能になります。

LF（論理ファイル）数は、シート上での直接変更はできません。変更が必要な場合は、「RDRA定義・分析Sheet」の「情報」シートを修正してください。

ここからは、ウォーターフォール用見積りシートの各項目について説明します。

SFPの算出

「参照設定」シートで算出された「EP（要素処理）数」と「LF（論理ファイル）数」をもとに、SFPで定められた計算式に従ってSFPが算出されます（下図の「全体SFP」）。

SFP算出

ポイントとは

開発の見積りにおいて、ポイントとは「開発規模の尺度」であり、システムの「大きさ」を表す単位です。画面数や機能数など、システムが持つ要素をもとに算出するため、人やチームのスキル・開発環境に依存しない客観的な指標となります。

同じ規模のシステムであれば、プロジェクトや組織が異なっても同じポイントが算出されることが理想であり、見積りの根拠を共通言語として関係者間で共有できる点が大きなメリットです。

アジャイル開発では、ユーザーストーリーごとに相対的な規模を見積もるストーリーポイントが広く使用されます。

絶対的な作業時間ではなく、チーム内の相対比較で規模を表すため、見積りのスピードと柔軟性が高まる点が特徴です。

SFPを開発工数（人月）に変換する

ポイントから工数を算出するには、「生産性」を用いて以下の式で計算します。

工数 = ポイント ÷ 生産性

生産性は、組織の開発能力を表す重要な指標です。

見積りの精度は、この「生産性」の設定に大きく依存します。

実際のプロジェクトでは、同じ規模のシステムでも以下によって生産性は大きく変化します。

• 開発チームのスキル
• 開発プロセス
• 技術スタック
• 非機能要件の厳しさ

ウォーターフォール用見積りシートでは、「全工程開発生産性」を入力することで、開発工数（人月）が自動で算出されます。

全工程開発生産性とは、1人月あたりに消化できるポイント数を示す指標です。たとえば、値が10の場合、1人月で10ポイント分の開発が可能であることを意味します。この値はチームのスキルや過去の実績をもとに設定するため、プロジェクトの特性や組織の経験値を見積りに反映できます。

なお、アジャイル開発における生産性の指標としてベロシティがあります。これは、1スプリント（通常1〜4週間）で完了できる作業量をストーリーポイントの合計値で表したものです。

ウォーターフォールの「全工程開発生産性」とアジャイルの「ベロシティ」は、どちらも「単位期間あたりの生産性」を示すという点で共通しており、概念として対応しています。

下図の例では、240ポイントの開発規模に対して、全工程開発生産性を10SFP/人月と設定した結果、開発工数が24人月と算出されています。

全工程開発生産性を自組織の実績に即した適切な値に設定することで、規模に対して精度の高い工数算出が可能になります。

値を変更する場合は、「全工程開発生産性」の欄を直接入力してください。

過去のプロジェクト実績や業界標準値を参考に設定することを推奨します。

SFPを開発工数（人月）に変換する

開発工数（工程別）の算出

全工程開発工数をもとに、各工程（基本設計・詳細設計・製造・結合テスト・総合テスト）の開発工数を算出します。

全工程開発工数は、以下の比率に基づいて各工程に分配されます。

• 基本設計: 15.0%
• 詳細設計: 20.0%
• 製造: 35.0%
• 結合テスト: 15.0%
• 総合テスト: 15.0%

この比率は「ソフトウェアデータ白書2018-2019（IPA発行）*1」を参考に設定されています。

一般的なウォーターフォール開発では、製造工程が最も工数を占めますが、設計工程・テスト工程も相応の割合を要します。多くの統計データでは、以下のような傾向が見られます。

• 製造（実装、単体テスト）：30〜40%
• 設計（基本設計、詳細設計）：30〜40%
• テスト（結合テスト、総合テスト）：20〜30%

初期値はこの傾向に沿った設定となっていますが、プロジェクトの特性や組織の標準工程比率に合わせて変更したい場合は、「開発工数比率（見直し後）」欄の値を直接入力することで、各工程の開発工数を調整できます。

SFPを開発工数（人月）に変換する

開発規模に比例しない工数（基盤工数、移行工数など）をユーザーが入力する

SFPで算出したポイントに関係のない工数を、工程ごとに入力します（下図）。

開発規模に比例しない工数（工程別）

• 基盤工数
  • インフラ構築・ミドルウェア設定・開発環境整備など、システム基盤の構築に必要な工数
• 移行工数
  • 既存システムのデータや機能を新システムへ移行するための設計・実装・検証に必要な工数
• 運用準備工数
  • 運用マニュアルの整備・監視設定・運用担当者へのトレーニングなど、本番稼働に向けた準備に必要な工数
• その他の工数
  • 上記に分類されないプロジェクト固有の作業（外部機関との調整、セキュリティ対応など）に必要な工数

各工程の全体工数欄には、開発工数（工程別）と、開発規模に比例しない工数の合計値が算出されます。

管理工数を算出する

管理工数とは、プロジェクトマネジメントに必要な工数です。

進捗管理・品質管理・リスク管理・顧客折衝（定例会議・報告業務を含む）・メンバーへの指示・調整など、開発作業そのものではなく、プロジェクトを円滑に推進するために必要な作業が該当します。

管理工数は、一般的に以下の式で算出されます。

管理工数 = （開発工数 + 開発規模に比例しない工数）× 管理工数率

管理工数率は初期値として10%が設定されており、各工程の「管理工数」欄に自動で算出されます（下図）。

管理工数の算出

プロジェクトの規模や複雑さ、組織の標準に応じて「管理工数比率」欄の値を変更することで、管理工数を調整できます。

一般的に、プロジェクトの規模が大きいほど、あるいは関係者や開発拠点が多いほど、管理工数の割合は高くなる傾向があります。

過去のプロジェクト実績を参考に、実態に即した値を設定することを推奨します。

全体工数と開発工程ごとの工数を算出する

これまで算出した各種の工数を、以下の式で合計します。

全体工数 = 開発工数 + 開発規模に比例しない工数 + 管理工数

全体および工程別の工数合計が自動で算出されます（下図）。

全体工数

この合計値が、工期算出や見積金額算出の基礎となります。

最後に

本記事では、「RDRAx見積りシート」のウォーターフォール開発用シートにおける工数算出の仕組みを説明しました。

工数算出の流れを整理すると、以下のようになります。

1. RDRAの要件モデルからSFPを算出する
2. SFPと全工程開発生産性をもとに、開発工数（工程別）を算出する
3. 開発規模に比例しない工数（基盤・移行・運用準備など）を入力する
4. 管理工数を算出する
5. 手順2〜4で算出・入力した工数を合計し、全体工数と工程別工数を確定する

RDRAx見積りシートの特徴は、以下の構造で見積りを行う点にあります。

要件モデル → 機能規模 → 工数 → 工期・金額

これにより、見積りの根拠を「経験」ではなく「モデル」に基づいて説明できるようになります。プロジェクト関係者との合意形成や、見積り精度の継続的な改善にもつながります。

次回の記事では、算出した工数をもとに工期と見積金額を算出する方法について説明します。

tracery.jp

この記事を書いた人

haru

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

*1:「ソフトウェアデータ白書2018-2019（IPA発行）」のp.184、図表7-1-16「工程別の実績工数の比率の基本統計量（新規開発）」における"中央値"。）

RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する

シリーズ: モデルベース要件定義手法RDRA

• 要件定義手法RDRAの概要と全体像
• RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
• RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
• RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
• RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
• RDRAの成果物と設計プロセスとの連携
• 要件定義をAIで加速する「RDRAAgent」その1〜LLMがモデルの叩き台を自動生成
• 要件定義をAIで加速する「RDRAAgent」その2〜要件を仕様化するRDRASpec
• RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する（本記事）
• RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編
• RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編
• RDRAで見積りを行う方法その4〜アジャイル開発編

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

システム開発の見積りは、多くの場合「経験と勘*1」に依存しています。

要件定義が完了しても「この規模ならだいたい○人月」といった形で見積りが決まることは珍しくありません。

その結果、次のような問題が発生します。

• 見積りの根拠を説明しづらい
• 担当者によって見積り結果がばらつく
• スコープ調整や意思決定の材料として使いにくい
• 見積りの妥当性を巡って顧客との認識齟齬が発生する

本来、要件定義の段階で必要なのは、個々の機能を精緻に積み上げた見積りではなく、全体規模を把握するための概算見積りです。

概算見積りが予算から大きく外れている場合は、設計に進む前にスコープを見直す必要があります。逆に、概算で予算内に収まる見込みが立てば、プロジェクトを前に進める判断ができます。

概算段階で迅速かつ根拠のある見積りを算出できれば、開発プロジェクト全体の意思決定のスピードと質は大きく向上します。

RDRAでは、業務イベント、画面、情報などの要素をモデルとして構造化して定義します。これらの要素は、ソフトウェア規模見積り手法であるファンクションポイント法における「処理」と「データ」に自然に対応します。

この対応関係を利用し、RDRAで構造化された要件から概算見積りを算出するツールが、IT システム可視化協議会（MCIS）が中心となって作成している 「RDRA×見積りシート」 です。

「RDRA×見積りシート」は、RDRA定義・分析シートと連携し、シンプルファンクションポイント法に基づいて工数・金額・期間の見積りを自動算出します。

要件の構造がそのまま見積りの根拠になるため、勘や経験に依存しない、説明可能な見積りを行うことができます。

本記事では、「RDRA×見積りシート」を用いて、RDRAのモデルから概算見積りを算出する方法を紹介します。

シンプルファンクションポイント法（SFP）とは

「RDRA×見積りシート」で使用している シンプルファンクションポイント法（以下、SFP：Simple Function Point） は、ソフトウェアの機能規模を計測するための手法です。

SFPでは、システムの機能を次の2種類の要素として数え上げます。

• EP（Elementary Process：要素処理）：ユーザーや外部システムとのやり取りを伴う処理
• LF（Logical File：論理ファイル）：システムが保持する論理的なデータ

EPとLFの数を数えることで、ソフトウェアの機能規模を算出できます。

SFPは、国際ファンクションポイントユーザ会（IFPUG）が策定した従来のファンクションポイント法（IFPUG法）を簡素化した手法です。

IFPUG法では処理の複雑度を判定する必要がありますが、SFPではその判定を省略することで、迅速に規模を算出できるようになっています。

そのため、IFPUG法が基本設計後の計測に適しているのに対し、SFPは企画段階や要件定義段階の概算見積りに適しているとされています。

SFPは簡素化された手法ではありますが、現実的なモデルケースにおける計測精度は、IFPUG法と比較して -13％〜+20％の範囲に収まると報告されています。

概算見積りとしては十分に実用的な精度です。

また、IPAの「2023年度ソフトウェア開発アンケート結果」によると、ファンクションポイント法はユーザー企業の35％、ベンダー企業の45％、全体では39％の企業で利用されています。

業界標準として広く利用されている手法であり、見積り結果をステークホルダーへ説明する際の共通言語としても機能します。

SFPの詳細は、MCISのサイトのファンクションポイント（FP）概要を参照してください。

RDRA×見積りシートの使用方法

RDRA×見積りシートを使って最初の見積りを算出するまでの手順は、次の2ステップです。

1. テンプレートをコピーする
2. RDRA定義・分析シートのURLを設定する

テンプレートからのコピー

MCISが提供しているGoogleスプレッドシートをコピーして使用します。

なお、2026年4月現在、このテンプレートは非公開です。利用を希望する場合は、MCISへお問い合わせのうえ、使用条件等をご確認ください。

RDRA定義・分析シートのURLを設定する

RDRA×見積りシートの「参照設定シート」に、RDRA定義・分析シートのURLを記載します。

URLを設定すると、RDRA定義・分析シートから要素が自動的に読み込まれ、SFPで使用するEP（要素処理）数とLF（論理ファイル）数が計算されます（下図）。

RDRA定義・分析シートとRDRA×見積りシートの連携

EP（要素処理）数とLF（論理ファイル）数は、RDRA定義・分析シートに定義された要素をもとに自動集計されます。

ファンクション	シート	カウントする要素
EP	BUCシート	・画面：UI（画面や帳票等） ・イベント：外部のシステムやアクターとのインターフェース ・タイマー：ビジネス上の締切（例：月末締、定時実施）で実行される処理
LF	情報シート	・情報：システムが扱う概念的なデータとその関係

上図では、以下のように計算されています。

• EP（要素処理）：36
• LF（論理ファイル）：8

工数、金額、開発期間の出力

参照設定シートで算出されたEP数とLF数をもとに、見積り結果が自動的に計算されます。

見積りは、次の2種類の開発モデルに対応しています。

• ウォーターフォール開発
• アジャイル開発

EP数とLF数から、下図のような見積り結果が自動的に算出されます。

見積りの出力

シート上では、次のようなパラメータを調整できます。

• 人月あたりの生産性
• 開発プロセスごとの工数比率
• 人月単価

プロジェクトの状況に合わせてこれらを設定することで、見積り結果を調整できます。

見積り工数、開発期間の妥当性確認

「RDRA×見積りシート」では、算出された工数（人月）と開発期間をグラフにプロットし、業界標準のデータと比較できます。

比較には、以下の団体が公表しているソフトウェア開発の標準的な工数・開発期間の関係を使用しています（下図）。

• 日本情報システム・ユーザー協会（JUAS）
• 情報処理推進機構（IPA）
• 経済調査会

見積り工数、開発期間の妥当性確認

見積り結果を、標準的な工数と開発期間の曲線と比較することで、以下の観点を視覚的に確認できます。

• 開発期間が長すぎないか
• スケジュールが過密になっていないか

たとえば、標準曲線より大きく上に外れている場合は、開発期間が長すぎる可能性があります。

逆に大きく下に外れている場合は、スケジュールが過密になっている可能性があります。

このように、業界標準との乖離を可視化することで、スコープやスケジュールの見直しを早期に判断できます。

最後に

本記事では、RDRA×見積りシートの使用方法を紹介しました。

RDRAを用いることで、要件を構造化して整理できるだけでなく、その構造をそのまま見積りの根拠として利用できます。

その結果、以下の効果が期待できます。

• 見積りの根拠を説明できる
• 担当者によるばらつきを減らせる
• スコープ調整や意思決定の材料として活用できる

要件定義と見積りを切り離すのではなく、要件モデルと見積りを連携させることで、より合理的なプロジェクト計画を立てることが可能になります。

「RDRA×見積りシート」は、要件定義と見積りを結びつける実践的なアプローチです。

次回の記事では、「RDRA×見積りシート」のウォーターフォール用見積りシートで、工数を算出する方法や考え方について詳しく説明します。

tracery.jp

この記事を書いた人

haru

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

*1:「度胸」を加えて、KKD（経験・勘・度胸）と呼ばれることも多い。

要件定義をAIで加速する「RDRAAgent」その2〜要件を仕様化するRDRASpec

シリーズ: モデルベース要件定義手法RDRA

• 要件定義手法RDRAの概要と全体像
• RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
• RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
• RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
• RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
• RDRAの成果物と設計プロセスとの連携
• 要件定義をAIで加速する「RDRAAgent」その1〜LLMがモデルの叩き台を自動生成
• 要件定義をAIで加速する「RDRAAgent」その2〜要件を仕様化するRDRASpec（本記事）
• RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する
• RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編
• RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編
• RDRAで見積りを行う方法その4〜アジャイル開発編

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

前回は、LLMを活用してRDRA形式の要件モデルを自動生成するツール「RDRAAgent」を紹介しました。

RDRAAgentには、生成した要件を仕様化するための機能「RDRASpec」が用意されています。

仕様化とは、要件を開発チームが設計・実装できるレベルまで具体的かつ明確に定義することです。

つまり、「何を実現したいか（要件）」を「どう実現するか（仕様）」へ変換する作業であり、仕様化は要件の曖昧さを排除し、開発時の認識のずれや手戻りを防ぐうえで欠かせません*1。

本記事では、この「RDRASpec」の機能について紹介します。

RDRASpecが作成する仕様

RDRASpecでは、以下の3種類の仕様を作成します。

• 論理データモデル
• ビジネスルール
• 画面仕様

仕様の作成方法

仕様化した成果物を作成するには、メニューから21.仕様の作成：論理データ構造/画面/ビジネスルールを選択します。 実行が完了すると、2_RDRASpecフォルダ内に以下のファイルが出力されます。

• 論理データモデル.md
• ビジネスルール.md
• 画面仕様.json

以下では、RDRASpecが作成する論理データモデル、ビジネスルール、画面仕様のそれぞれについて説明します。

論理データモデル

論理データモデル.mdには、以下の内容が出力されます。

• エンティティ定義
• ER図（Mermaid形式）
• 論理データモデルの設計ポイント
• データモデルの実用性

上記のうち、エンティティ定義とER図（Mermaid形式）について以下で説明します。

エンティティ定義

データモデルを構成するエンティティを、データ名（エンティティ名）、項目名、タイプ（型）、主キーかどうか（isKey）、説明の各要素で定義し、表形式で表したものです（下図）。

エンティティ定義（一部）

ER図（Mermaid形式）

エンティティ定義をもとに、エンティティ間のリレーションシップをER図（Mermaid形式）で表したものです（下図）。

ER図（Mermaid形式）

ビジネスルール

ビジネスルールが、条件、バリエーション、および状態モデルの関係を元に定義されます（下図）。

ビジネスルール

RDRAAgentに含まれている訪問介護システムのサンプルでは、以下のカテゴリのビジネスルールが出力されました。

• スケジュール管理
• スタッフ管理
• 会員管理
• 請求計算
• 施設管理
• 法規制対応

このように、RDRAで定義した条件・バリエーション・状態モデルの情報をもとに、業務上の判断基準や制約がビジネスルールとして体系的に整理されます。

画面仕様

画面仕様.jsonには、BUC（ビジネスユースケース）とアクターごとの画面情報が出力されます。

BUC・アクター別画面の表示

画面仕様を確認するには、メニューから22.BUC・アクター別画面を表示するを選択します。

選択すると、PC上でHTTPサーバーが起動し、ブラウザが自動的に開いて画面イメージが表示されます。

下図は、スケジュール計画業務のスケジュール計画フローの業務において、サービススタッフが操作する「スタッフスキルと要望提供画面」を開いた例です。

BUC・アクター別画面

現時点で確認できる画面仕様は簡易的なものですが、画面に表示されたデータ項目を見ながら、項目の過不足や名称の妥当性を検証する用途に活用できます。

たとえば、要件定義の段階で画面項目の抜け漏れを早期に発見し、手戻りを防ぐといった使い方が効果的です。

仕様化の参考書籍

要件（要求）の仕様化についてより深く理解したい方は、以下の書籍が参考になります。

【改訂第２版】［入門＋実践］要求を仕様化する技術・表現する技術 ～仕様が書けていますか？

最後に

本記事では、RDRAAgentの仕様化機能「RDRASpec」を紹介しました。

RDRASpecを活用することで、要件定義で整理した情報をもとに、論理データモデル・ビジネスルール・画面仕様といった設計の入力となる成果物を効率的に作成できます。

定義した要件をRDRASpecで仕様化することで、要件の解像度が上がり、曖昧さや矛盾を早期に発見できます。これにより、要件の適切性を具体的な仕様レベルで検証でき、後のプロセスでの手戻りリスクを低減できるでしょう。

次回は、RDRAで定義した要件をもとに見積りを算出する方法を紹介します。

tracery.jp

この記事を書いた人

haru

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

*1:本メディアでは、「要件の仕様化」を「基本設計」プロセスに含めます。仕様化とは要件を「どう実現するか（How）」を定義する作業であり、設計の領域に属すると考えるためです。ただし、「要件の仕様化」を要件定義プロセスに含めるか、基本設計プロセスに含めるかは議論が分かれるところです。要件定義に含める場合は、要件定義の段階でHowにまで踏み込んだスコープを扱い、基本設計ではそれをインプットとしてさらに精緻化していくという考え方になります。いずれの立場をとるにせよ、要件と仕様の境界を開発チーム内で合意しておくことが重要です。