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

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

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要員、予備費的なコンティンジェンシーの按分先などに活用できる。何に使っているかを明記しておくと、金額交渉の場で説明がしやすくなる。