LASSIC Media らしくメディア
月あたりの要員数の中央値｜開発種別で見る体制の目安
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAの資料では、月あたりの要員数の中央値は全体で6.3人、新規開発で7.7人、改修・保守で5.6人でした。
- この値は実際の人数を数えたものではなく、案件ごとの工数を月数で割って求めた値です。
- 開発種別を絞っても案件ごとの差は大きいため、中央値だけでなく、人数の少ない側と多い側の値も見て体制の目安にします。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
遅れている案件に、あと何人を追加すればよいのか。社内の前例をもとに決めたものの、多すぎたのか少なすぎたのかは後になって分かる——。開発体制を決める現場では、こうした迷いが起こりがちです。月あたりの要員数とは、1つの案件にひと月あたり何人が携わっていたかにあたる値で、案件の工数（作業にかかった時間の合計）を、開発にかかった月数で割って求めます。
開発種別ごとの中央値を知っておくと、自社の体制の人数が世の中の案件と比べて多いのか少ないのかを確かめる手がかりになります。ただし万能ではなく、同じ開発種別の中でも案件ごとの差は大きく残ります。本記事では、開発体制を決める担当者に向けて、月あたりの要員数の求め方、開発種別ごとの違い、人を追加する前に決める順番、そして外部に頼むときに確認したい点を整理します。
目次
月あたりの要員数とは
IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、2022年9月26日に公開され、2025年8月28日に最終更新された資料です。これまでに収集した5,546プロジェクトの定量データから分析したもので、「事業終了に伴い今後の発行予定はございません」と明記されています。*1 新しい版は出ないため、いまの水準を示す資料ではなく、自社の体制と比べるときの基準として使います。
この資料の表1-3-5が、プロジェクトの月あたりの要員数を開発種別ごとにまとめています。開発種別は、システムを一から作る新規開発、すでに動いているシステムを直す改修・保守、既存のシステムを作り直す再開発、機能を加える拡張、パッケージ利用開発、OSS（ソースコードが公開されたソフト）を含む流用開発の6つです。
注意したいのは、この値が実際に何人いたかを数えたものではない点です。本編は「実際の要員数を集計したものではないことに留意されたい」と記しています。案件ごとに、開発の5つの工程でかかった実績工数を実績月数で割り、さらに人時換算係数で割って求める導出指標（ほかの値から計算で求めた指標）で、工数の単位が人時のときは、人月人時換算係数として160を使うと書かれています。*2 人時は1人が1時間働いた作業量、人月は1人がひと月働いた作業量のことで、この値は1人月を160人時として数えています。自社で1人月を別の時間数で数えているなら、比べる前にそろえておきます。
全体の中央値と分布
表1-3-5の全体の行では、N（集計に使われたプロジェクト数）が975、中央値が6.3人でした。P25（小さいほうから4分の1の位置の値）は3.4人、P75（大きいほうから4分の1の位置の値）は12.3人です。*2 真ん中の半分の案件が、ひと月あたり3.4人から12.3人の体制に収まっていることになります。
本編は分布の形について、3人から4人の分布が最も多く、10人以下が7割弱を占めていると記しています。*2 ひと月に13人以上が作業する体制は、人数の多いほうから4分の1に入ります。反対に、3人ほどで進んでいる案件も珍しくありません。
単位は「月あたり」なので、自社の体制と比べるときも、案件に関わった人の延べ人数ではなく、その月に作業している人数を数えます。人数だけでなく体制そのものを見直して費用を抑える進め方は、開発体制の見直しについての記事で扱っています。
開発種別ごとの違い
開発種別で分けると、新規開発の中央値は7.7人（N279）、改修・保守は5.6人（N491）でした。*2 表の値から計算すると差は2.1人、倍率は1.375倍で、新規開発のほうが人数の多い体制になります。改修・保守は6つの開発種別の中で最も件数が多く、全体の値に近い水準です。
P25とP75で比べると、人数の多い案件ほど差がさらに広がります。新規開発はP25が4.4人、P75が17.9人で、改修・保守はP25が3.0人、P75が11.2人です。*2 P75どうしでは6.7人の開きがあり、新規開発では、人数の多い案件がかなり大きな体制を組んでいることが分かります。
ほかの開発種別では、再開発が7.4人（N81）で新規開発に近く、拡張が5.4人（N78）で改修・保守に近い値です。パッケージ利用開発は3.8人でした。*2 ただし、パッケージ利用開発はNが36、OSSを含む流用開発はNが10と件数が少ないため、この2つは参考にとどめます。
なぜ平均ではなく中央値で見るのか
平均を使わないのは、ごく一部の極端な案件に値が引っ張られるためです。全体の平均は12.7人で、中央値6.3人の2.02倍でした。月あたりの要員数がいちばん大きい案件は改修・保守の309.4人、拡張でも221.1人に達しています。*2 拡張は平均が17.5人で、中央値5.4人の3.24倍です。平均で比べると、ほとんどの案件にとって現実から離れた人数になります。
中央値に加えて、P75がP25の何倍かを計算すると、案件ごとの差の大きさが分かります。全体は3.62倍、新規開発は4.07倍、改修・保守は3.73倍、拡張は5.24倍、再開発は2.70倍でした。極端な案件を除いた真ん中の半分だけでも3倍前後から5倍の開きがあり、開発種別を絞っても差は大きく残ります。中央値の1つの値だけで人数を決めず、P25からP75の幅で見るのはこのためです。
OSSを含む流用開発だけは、P75がP25の1.67倍と幅が狭く、平均の6.0人が中央値の6.8人を下回っています。*2 ほかの開発種別と値の散らばり方が違いますが、Nが10しかないため、流用開発に共通する性質なのか、件数が少ないためなのかは切り分けられません。
工数の表と組み合わせるときの注意
同じ本編の表1-3-4は、プロジェクト全体の工数を人時換算で示しています。Nは1,444、中央値は7,395人時で、P25が3,105人時、P75が20,446人時でした。*2 中央値を160人時で割ると、46人月ほどの規模にあたります。本編は、5000人時以下のプロジェクトがおよそ4割を占めるとも記しています。P75はP25の6.58倍で、要員数よりも幅が広い分布です。
ここで、工数の中央値を工期（開発にかかった月数）の中央値で割れば要員数の中央値が出る、と考えたくなりますが、この計算はできません。表1-3-4はプロジェクト全体の工数を集計しているのに対し、表1-3-5の導出指標は開発5工程の実績値から求めており、集計の基準が違います。Nも1,444と975で、同じプロジェクトの集まりではありません。
導出指標は案件ごとに工数を月数で割り、その結果を集めて中央値やP25・P75を出したものです。それぞれの中央値は別の案件の値なので、割っても実在するどの案件の人数にも当たりません。工数の表は案件の規模を比べるために、要員数の表は体制の人数を比べるために、分けて使います。
人を追加する前に決める順番
ここまでの値を使うと、遅れている案件に人を追加するかどうかは、次の4つの手順で考えられます。表は、開発種別ごとの値を本編の表1-3-5からまとめたものです。
| 開発種別 | P25 | 中央値 | P75 | N |
|---|---|---|---|---|
| 全体 | 3.4 | 6.3 | 12.3 | 975 |
| 新規開発 | 4.4 | 7.7 | 17.9 | 279 |
| 改修・保守 | 3.0 | 5.6 | 11.2 | 491 |
| 再開発 | 4.7 | 7.4 | 12.7 | 81 |
| 拡張 | 2.5 | 5.4 | 13.1 | 78 |
| パッケージ利用開発 | 1.9 | 3.8 | 8.0 | 36 |
| OSSを含む流用開発 | 4.2 | 6.8 | 7.0 | 10 |
- 手順1：残っている工数を人時で、残っている期間を月数で出す
- 手順2：開発種別に合う行の中央値と、いまの体制の人数を並べる
- 手順3：いまの人数や追加後の人数が、P25からP75の間に入るかを確かめる
- 手順4：人を増やしても間に合わない分は、作業の量か期間のどちらかで調整する
たとえば改修・保守の案件で、ひと月に20人が作業する体制を組むとします。改修・保守のP75は11.2人なので、20人は人数の多いほうから4分の1の境目を大きく超えます。それでもその人数が必要なら、なぜ必要なのかを残りの工数と期間から説明できるようにしておきます。順番を逆にして人数を先に決めると、残っている工数と合っているかを確かめる機会がなくなります。
この表は、あくまで世の中の案件と比べるための目安です。案件ごとに工数と月数を記録しておけば、自社の案件で同じ計算をして、自社の中央値と比べられるようになります。業界の値と自社の値を並べておくと、次の案件で体制を決めるときの根拠がはっきりします。
外部に委託するときに確認しておきたい点
人を追加するときは、追加する人に何を任せるかを先に分けておきます。仕様の判断や作業の優先順位を決める部分は社員が受け持ち、プログラムの作成やテストのように、決まった内容を進める作業を外部の専門人材に任せる、という分け方が取れます。工程ごとに内製と委託をどう分けているかは工程別の内製化についての記事で、要員が足りないままレガシーシステムの刷新を進める場面はレガシー刷新と要員の不足についての記事で扱っています。
遅れを取り戻すための数か月だけ人を追加し、落ち着いたら元の体制に戻すなら、フリーランスを含む業務委託の使い方が合います。委託するときは、どの作業を、いつまでに、ひと月あたり何人で進めるかまで決めてから頼むと進めやすくなります。追加したあとの人数も、開発種別に合う行のP25からP75の幅と見比べておくと、多すぎる体制を組むのを避けやすくなります。
まとめ：月あたりの要員数で確かめておきたい3つの点
月あたりの要員数を体制づくりに使ううえで、確かめておきたい点は3つに整理できます。第一に、この値は実際の人数ではなく、工数を月数で割って求めた導出指標だと知っておくこと。第二に、開発種別に合う行の中央値だけでなく、P25とP75の幅で自社の体制と比べること。第三に、人数を先に決めず、残っている工数と期間を出してから追加する人数を考えることです。この3点を踏まえておけば、「人を追加したのに、かえって多すぎる体制になっていた」という事態を避けやすくなります。追加する人の確保に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
業種ごとの月あたりの要員数はありますか
本編とは別に、業種編が3編公開されています。プロジェクト数の多い金融・保険業、情報通信業、製造業の3業種について、本編と同じ分析を行ったとされています。*1 自社の業種がこの3つに当てはまるなら、本編の値と業種編の値を並べて見ておくと比べやすくなります。
案件の工数の規模は、以前と比べて変わっていますか
大きな変化はありません。本編は工数の中央値7395人時について、2014年度から2019年度の値と比較してわずかに減少しているが、あまり差はないと記しています。5000人時以下のプロジェクトがおよそ4割を占める形も、あまり変わっていないとされています。*2
人を追加すれば、遅れは取り戻せますか
この資料からは判断できません。要員数と遅延の関係や、途中から人を追加した効果を示す集計は載っていないためです。資料から分かるのは、開発種別ごとの月あたりの要員数の分布までなので、追加するかどうかは残っている工数と期間から判断します。
開発体制の人数を相談したいとき
残っている工数と期間に合わせて、どの作業に何人を追加するかの整理からご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：IPA「ソフトウェア開発分析データ集2022」公開ページ。公開日・最終更新日、5,546プロジェクト、事業終了に伴い今後の発行予定がないこと、業種編の対象業種を参照（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」本編（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：同本編PDF。表1-3-5（プロジェクトの月あたりの要員数）・表1-3-4（プロジェクト全体の工数）の四分位・平均・標準偏差・N、導出指標の定義と注意書き、過去との比較の記述を参照（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集2022グラフデータ」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000103288.zip）。出典：同グラフデータ。表の値の確認に使用。著作権はIPAが保有（Copyright 2022 IPA）（2026年9月確認）
