見積もりの妥当性確認は、何から始めますか
提示された見積書にFP（ファンクションポイント）の算出根拠が明記されているかを、まず確認します。記載が無ければ、開示を依頼するところから始めます。
御社が受け取った見積もりに「総FP値」や「FPあたりの単価」の記載が無い場合、工数の妥当性を客観的に検証できません。算出根拠は、交渉の出発点になります。
FP（ファンクションポイント）法とは
ファンクションポイント法とは、システムが持つ画面数や機能の数、複雑さを点数化し、開発規模を測る見積もり手法です。
IPAが公開する「ソフトウェア開発分析データ集2022」は、2004年以降に蓄積した5546件のプロジェクトデータを分析したものです（出典: IPA『ソフトウェア開発分析データ集2022』、https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。うち直近6年間の1479件からは、工数、工期、規模、生産性、信頼性等の基本項目が分析されています（出典: IPA『ソフトウェア開発 分析データ集2022』全業種編、https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。
このデータを使い、御社の見積もりが公的な水準からどれだけ離れているかを確認する方法を、次の見出しから具体的に説明します。
算出根拠の開示を依頼する際の伝え方
算出根拠が見積書に記載されていない場合は、次の3点を依頼すると回答を得やすくなります。
- 総FP値とその算出方法
- 投入予定人月（人数と期間）
- FP規模別の生産性を用いた場合の根拠
依頼する際は「精査のため」ではなく「社内稟議で工数の裏付けが必要なため」と伝えると、ベンダ側も対応しやすくなります。
FP当たりの生産性は、どの程度が妥当な目安ですか
IPAの公的統計では、開発類型別にFP規模あたりの生産性（FP/人月）が公表されており、これを見積もりの工数と照らし合わせる目安にできます。
IPAが公開する「ソフトウェア開発分析データ集2022」は、2004年以降に蓄積した5546件のプロジェクトデータを分析したものです（出典: IPA『ソフトウェア開発分析データ集2022』、https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。うち直近6年間の1479件からは、工数、工期、規模、生産性、信頼性等の基本項目が分析されています（出典: IPA『ソフトウェア開発 分析データ集2022』全業種編、https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。このデータは、新規開発、改良開発、再開発という開発類型ごとに区分されている点が特徴です。
| 確認項目 | 内容 |
|---|---|
| 分析対象件数（全体） | 5546件 |
| 直近6年間の分析対象件数 | 1479件 |
| 生産性の区分方法 | 開発類型別（新規開発、改良開発、再開発）にFP規模あたりの生産性（FP/人月）を算出 |
| 難易度による使い分け | 自社に過去実績が無い場合、中央値、最小値、最大値をシステムの難易度に応じて選択する設計 |
御社の見積もりが該当する開発類型を確認したうえで、同じ区分の生産性データと照らし合わせることが、比較の第一歩になります。中央値だけでなく最小値、最大値も公表されているため、難易度が高いシステムであれば低い側の生産性と比較するなど、幅を持って判断します。
ファンクションポイント法は、規模を客観的に評価できる手法として位置づけられています。類推見積法など他の手法と組み合わせることで、より精度の高い工数見積もりが実現できるとされます。単独の指標として鵜呑みにせず、複数の視点から確認する姿勢が重要です。
見積書に記載された具体的な数値をこの生産性データと突き合わせる手順は、次の見出しで説明します。
見積書のどの数値を、公的統計と比較すればよいですか
見積書に記載された総FP値と投入予定人月を照らし合わせ、算出したFP/人月が公的統計のレンジから大きく外れていないかを確認します。
具体的な手順は、次の3つです。
- 手順1 総FP値を確認する（所要時間の目安: 5分） 見積書の内訳、または開示を依頼した算出根拠資料から、総FP値を確認します。
- 手順2 投入人月で割って生産性を算出する（所要時間の目安: 5分） 総FP値を投入予定人月で割り、FP/人月を算出します。
- 手順3 公的統計のレンジと比較する（つまずきやすい点: システムの難易度によりレンジ自体が変わる） 算出したFP/人月を、御社のシステムに近い開発類型の生産性データと比較します。
IPAが公開する「ソフトウェア開発分析データ集2022」は、2004年以降に蓄積した5546件のプロジェクトデータを分析したものです（出典: IPA『ソフトウェア開発分析データ集2022』、https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。うち直近6年間の1479件からは、工数や規模とあわせて生産性も分析されています（出典: IPA『ソフトウェア開発 分析データ集2022』全業種編、https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。同じ開発類型（新規開発、改良開発、再開発)の数値と突き合わせることが、比較の精度を高めます。
手順3でつまずきやすいのは、難易度の異なるシステムを同じレンジで比較してしまう点です。複雑な画面遷移を持つシステムと、定型的なバッチ処理が主体のシステムでは、同じFP規模でも妥当な工数は大きく変わります。実装に携わる立場からは、機能の数だけでなく、連携先システムの多さや例外処理の複雑さも生産性に影響する点を見落とさないようにしたいところです。
算出したFP/人月がレンジから外れていた場合の具体的な対応は、次の見出しで説明します。
見積もりが相場より高い、または低いときはどう対応しますか
生産性が公的統計のレンジより著しく低い場合は算出根拠の再提示を求め、著しく高い場合は品質担保の方法を確認します。
工数が多すぎる場合の交渉ポイント
算出したFP/人月が公的統計のレンジより著しく低い場合、まず難易度や連携範囲の違いで説明がつくかを確認します。
IPAは、企業から収集したソフトウェア開発プロジェクトの定量データを継続的に分析しています。「ソフトウェア開発分析データ集2022」では、これまでに収集した5546件のプロジェクトデータが分析対象になっており、これに先立つ「ソフトウェア開発データ白書2018-2019」でも、34社から4564件のプロジェクトデータが集まっています（出典: IPA『ソフトウェア開発分析データ集2022』、https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html。IPA『ソフトウェア開発データ白書2018-2019』のご紹介、https://www.ipa.go.jp/archive/files/000070064.pdf）。これだけの母数と比較しても著しく生産性が低い場合、既存のレガシーシステムとの連携やデータ移行が背景にある可能性があります。
経済産業省の「DXレポート」を紹介する複数の記事では、約8割の企業がレガシーシステムを抱え、そのうち約7割が「デジタル化の足かせになっている」と回答していると引用されています（出典: 経済産業省『DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～』を紹介する記事で広く引用されている数値、https://www.meti.go.jp/policy/it_policy/dx/20180907_03.pdf）。御社の案件が既存システムとの連携を伴う場合、この事情が工数に反映されている可能性を踏まえたうえで、具体的にどの作業に工数がかかっているかを質問します。それでも説明が付かない場合は、他のベンダから相見積もりを取り、比較検討します。
工数が少なすぎる場合に確認すべきリスク
逆に、算出したFP/人月が公的統計のレンジより著しく高い場合は、テストや例外処理が省略されていないかを確認します。
生産性が極端に高い見積もりは、要件の理解が浅いまま概算で出されている可能性があります。契約前に、テスト工程の内容と、要件変更が生じた場合の対応方針を書面で確認しておくと、後工程でのトラブルを避けやすくなります。
こうした判断を誤りやすいパターンについては、次の見出しで具体的に説明します。