LASSIC Media らしくメディア
FP生産性の中央値｜規模別の比較と遅れを取り戻す人数の見積もり
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAの集計では、新規開発で1人が1か月に作れた規模（FP生産性）の中央値は15.07FPです。
- 規模が大きい案件ほど中央値は下がり、400FP未満の17.00が3,000FP以上では10.07になります。
- 規模が大きいほどばらつきは広がるので、増員の計算には中央値だけでなく、遅い場合と速い場合の値も使います。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
遅れを取り戻すために、あと何人に加わってもらえばよいのかを計算したい。けれども、過去の案件の実績を平均しても、次の案件に当てはまるとは思えない——。開発の遅れを立て直す現場では、こうした迷いが起こりがちです。必要な人数を計算するときに使う「1人が1か月でどれだけ作れるか」という数字が、社内にそろっていないためです。この数字を表すのがFP生産性で、ソフトウェアの規模を、開発にかかった工数（人数×時間で表した作業量）で割った値です。
規模の大きさ別の値は、公的な統計でも公表されています。自社の実績がまだ少ないときの目安として、使いどころのある数字です。ただし万能ではなく、中央値を1つ当てはめるだけでは、案件によっては大きく外れます。本記事では、開発体制を組む実務担当者に向けて、FP生産性の定義と集計の対象、規模ごとの中央値とばらつき、そして増員を決める前に確かめたい点を整理します。
目次
FP生産性とは
FPはファンクションポイントの略で、画面や帳票、扱うデータといった機能の数と複雑さから、ソフトウェアの規模を測る単位です。FP生産性は、このFPで測った規模を、開発にかかった工数で割った値です。値が大きいほど、同じ工数で大きな規模を作れたことになります。
IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、FP生産性を、FP規模を資料が定める開発5工程の工数で除算したものと定義しています。値は、人時（1人が1時間働く量）あたりと、人月（1人が1か月働く量）あたりの2通りで示され、人時から人月への換算では、1人月を160時間としています。*1 何人を何か月加えるかを考えるときは人月あたりの値が使いやすいので、本記事では主に人月あたりの値を扱います。
もとにするのは、同じ資料の表A2-2-4です。新規開発のFP生産性を、FPで測った規模の大きさ別に、全年度のデータをまとめて集計したもので、対象は672件の案件です。*1
集計に入っている案件
数字を使う前に、どの案件が集計されているかを確かめておきます。資料が集計の対象にしたのは、開発5工程がそろっている、開発プロジェクトの種別が新規開発である、FPの計測手法が明確である、FPの実績値が0より大きい、という4つの条件を満たす案件です。*1
FPで規模を測っていない案件や、工程の一部しか工数の記録がない案件は入っていません。自社の案件が、工程ごとの工数を記録し、FPで規模を測っているかどうかによって、この数字をどこまで参考にできるかが変わります。
社内の見積もりの手順そのものを整えたい場合は、工数見積り技法を外注で精度向上で見積もりの技法と、外部の力を借りて精度を上げる進め方を扱っています。
全体の中央値とばらつき
672件全体の中央値は、人月あたり15.07FPでした。中央値は、案件を値の小さい順に並べたときに真ん中に来る値です。同じように、下から4分の1の位置の値（P25）は8.54、下から4分の3の位置の値（P75）は29.74です。*1 真ん中の半数の案件だけを見ても、遅い側と速い側で3倍以上の差があります。
最も低い値は0.84、最も高い値は322.65で、標準偏差（値のばらつきの大きさを示す数値）は25.13でした。平均は23.07で、中央値の15.07より高く出ています。*1 一部の非常に高い値の案件が、平均を押し上げているためです。平均を割り算に使うと、多くの案件より速く進む前提で期間を見積もることになるので、目安には中央値を使います。
1人月あたり15.07FPという数字だけを見ると、残りの規模をこれで割れば必要な人月が出るように思えます。しかし、1つの数字で割った期間は、実際の案件では大きくずれます。次の節で見るように、この開きは規模によっても変わります。
規模が大きいほど中央値は下がるのか
資料は、規模を400FP未満、400FP以上1,000FP未満、1,000FP以上3,000FP未満、3,000FP以上の4つに分けています。件数はそれぞれ166件、221件、201件、84件で、足すと全体の672件になります。*1
| FP規模 | 件数 | P25 | 中央値 | P75 | 標準偏差 |
|---|---|---|---|---|---|
| 全体 | 672 | 8.54 | 15.07 | 29.74 | 25.13 |
| 400FP未満 | 166 | 11.23 | 17.00 | 31.19 | 19.95 |
| 400FP以上1,000FP未満 | 221 | 9.69 | 15.80 | 28.62 | 21.76 |
| 1,000FP以上3,000FP未満 | 201 | 7.16 | 14.25 | 32.36 | 26.92 |
| 3,000FP以上 | 84 | 5.76 | 10.07 | 17.80 | 35.71 |
中央値は、規模の小さい順に17.00、15.80、14.25、10.07です。*1 規模が大きい区分ほど低くなっています。いちばん小さい区分といちばん大きい区分の値から計算すると、差は6.93FPです。P25も11.23、9.69、7.16、5.76と、規模が大きいほど低くなっています。
規模の大きな案件ほど、標準的な案件でも1人月で作れる量が少ないということです。残りの作業量が同じでも、案件全体が大きいほど、1人月で進む量を少なめに見込んでおくと、期間を短く見積もりすぎずに済みます。なお、なぜ規模が大きいほど下がるのかは、この表では分析されていません。
規模とともに広がるばらつき
ばらつきのほうは、中央値とは逆の動きをします。標準偏差は19.95、21.76、26.92、35.71と、規模が大きい区分ほど大きくなっています。P75は31.19、28.62、32.36、17.80で、1,000FP以上3,000FP未満の区分だけが一つ前の区分より高く、規模とともに下がり続けてはいません。*1
つまり、規模が大きくなると、中央値は下がる一方で、案件ごとの差は広がります。いちばん大きい3,000FP以上の区分でも、P25が5.76、P75が17.80で、3倍以上の開きがあります。
規模の区分ごとに中央値を1つ当てはめても、実際の案件はこの幅のどこかに入ります。期間を1つの日付で約束すると、進み方の遅い案件だった場合に計画を立て直すことになります。複数の見積もりを並べて確かめる進め方は、システム開発の相見積もりの取り方で整理しています。
増員を決める前の4つの手順
ここまでの数字を、自社で増員を決める手順に置き換えると、次の4つになります。
1つ目は、残りの作業を数えられる単位にそろえることです。FPで数えられなければ、画面数や機能数など、社内で数えられる単位を使います。2つ目は、その単位あたりの生産性を、自社の過去の案件から出すことです。平均ではなく中央値にするのは、先に見たとおり、平均が高く出やすいためです。
3つ目は、中央値だけでなくP25とP75も使い、期間を1つの日付ではなく早い場合と遅い場合の2つで出すことです。4つ目は、遅い場合でも間に合うように体制を組むことです。遅れが出た場合に、いつ、何人に加わってもらうかを先に決めておきます。
4つ目を社員の採用だけでまかなうのは難しくなります。採用には時間がかかり、遅れが解消したあとも人数はそのまま残るからです。フリーランスを含む業務委託なら、遅れが出た期間だけ人を増やし、作業が片づいたら元の人数に戻せます。ただし、どこまで進んだかの判断まで委託先に任せると、期間の幅を社内で管理できなくなります。進み具合の見立ては社内に残しておきます。
何人を配置するかを決める手順は要員計画に必要な4つの数字と決める順番で、体制の中で外部の人材が占める割合は外部委託工数比率とは、中央値63.4％が示す体制の相場で扱っています。
つまずきやすい点
一つ目は、この表の数字を自社の案件にそのまま当てはめることです。集計は、記録の条件を満たした新規開発の案件に限られます。FPで規模を測っていない案件には、そのままでは使えません。自社の実績と並べて、どの規模の区分に近いかを確かめてから使います。
二つ目は、生産性の数字だけで体制を決めることです。この表は、どれだけ速く作れたかを示すもので、完成したあとの不具合の量は含みません。業種や使うプログラミング言語との組み合わせも示されていません。速さの目安として使い、品質は別の記録で確かめます。
三つ目は、遅れが目に見えてから候補者を探し始めることです。加わってもらうまでの間に、さらに遅れが広がります。
まとめ：FP生産性で確かめておきたい3つの点
FP生産性を増員の計算に使ううえで、確かめておきたい点は3つに整理できます。第一に、IPAの集計は、FPで規模を測り、工程ごとの記録がそろった新規開発の案件に限られること。第二に、規模が大きいほど中央値は下がる一方で、ばらつきは広がること。第三に、期間は中央値だけでなく幅で出し、遅い場合でも間に合う体制を先に決めておくことです。この3点を踏まえておけば、「人を増やしたのに、計算どおりに進まなかった」という事態を避けやすくなります。体制の組み方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
人時あたりの値も公表されていますか
公表されています。全体の中央値は1人時あたり0.094FP、P25は0.053、P75は0.186、平均は0.144でした。*1
改修の案件にも使えますか
表A2-2-4は新規開発だけの集計です。同じ節には改良開発と再開発の表もありますが、件数は改良開発が35件、再開発が8件で、資料も「データ数が少ない」と記しています。*1 改修の案件では、自社の実績をもとに考えるのが現実的です。
年ごとの変化は分かりますか
表A2-2-4は全年度のデータをまとめた集計なので、年ごとの動きは読み取れません。年度を絞った新規開発の表（46件）も同じ節にありますが、資料は件数が少ないことを理由に、数値の上下には言及しないとしています。*1
FPで規模を測っていない場合はどうすればよいですか
画面数や機能数など、社内で数えられる単位で過去の案件の規模と工数を集め、同じように中央値とP25・P75を出します。単位が違うのでIPAの数字とは直接比べられませんが、規模が大きい案件ほど幅が広がっていないかは、自社の実績でも確かめておきたい点です。
開発の遅れに合わせて人を増やしたいとき
見積もった期間の幅に合わせて、いつ、何人に加わってもらうかからご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」本編（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：A2.2節のFP生産性の定義、層別定義、表A2-2-4（FP規模別FP生産性・新規開発・全年度）の件数・分位点・標準偏差・平均、改良開発・再開発の表と年度を絞った表についての記述を参照（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。参考：資料の公開ページ（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集2022グラフデータ」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000103288.zip）。参考：同じ図表の値の確認として。著作権はIPAが保有（Copyright 2022 IPA）（2026年9月確認）
- *4 参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。参考：業種編3編・サマリー版・グラフデータという構成の確認として（2026年9月確認）
