LASSIC Media らしくメディア
開発案件の種別で比べる費用相場｜中身が分かる比べ直し方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAのデータでは、開発案件の51.5%が改修・保守、29.1%が新規開発で、種別ごとに比べるべき相場の値が違います。
- プログラムの規模は、平均が中央値の約4.79倍と大きく離れているため、平均では比べられません。
- 相場と比べるときは、種別を先に決め、中央値と、下から4分の1・4分の3の位置の値で自社の案件の位置を確かめます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
遅れている案件に人を追加するかどうか、業界の相場と比べて決めたい。けれども手元の相場が、どんな案件を集めた値なのかが分からない——。開発の体制を決める現場では、相場の中身を確かめないまま比べてしまうことが起こりがちです。開発案件の種別とは、案件を新規開発や改修・保守などに分けた区分のことで、IPA（情報処理推進機構）が集めたデータでは、案件の51.5%が改修・保守でした。*1
種別を分けておけば、自社の案件を同じ種類の案件の値と比べられます。ただし種別をそろえて比べるのは万能ではなく、案件が遅れた理由までは示してくれません。本記事では、開発の体制や要員を決める担当者に向けて、種別の内訳、規模の比べ方、相場と比べる手順、そして外部に頼むときに確認したい点を整理します。
目次
開発案件の種別とは
IPAが公開している「ソフトウェア開発分析データ集2022」は、企業から集めた開発プロジェクトのデータをまとめた資料です。表紙には「5,546プロジェクトの定量データからソフトウェアの信頼性を中心に分析」と記され、2016年度から2021年度の案件を分析の対象として、2014年度から2019年度の案件の集計と比べています。*1 この資料は、開発案件の種別を6つに分けて件数を集計しています。
6つの種別は、新規開発、改修・保守、拡張、再開発、パッケージ利用開発、OSS（誰でも使えるよう公開されたソフトウェア）を含む流用開発です。この設問に回答のあった1,479件のうち、改修・保守が761件（51.5%）、新規開発が430件（29.1%）でした。残りは拡張が123件（8.3%）、再開発が107件（7.2%）、パッケージ利用開発が48件（3.2%）、OSSを含む流用開発が10件（0.7%）です。*1
改修・保守と新規開発を合わせると1,191件で、全体の80.5%になります。集まった案件のおよそ半分は、すでに動いているシステムを修正する改修・保守の案件です。そのため、種別を分けずに全体の値を相場として使うと、比べる相手の半分ほどが改修・保守の案件の値になります。
なぜ種別を分けて比べるのか
遅れている案件に人を追加するかどうかを決めるとき、業界の相場と比べて、自社の案件の要員数や規模が相場より多いか少ないかを確かめることがあります。このとき、比べる相手の値がどの種別の案件から出たものかを確かめておかないと、判断を誤りやすくなります。
種別ごとの要員数やテストの量は、同じ資料の別の節で集計されています。月あたりの要員数を種別で比べた値は「開発の種別ごとの月あたりの要員数」で、テストの量を新規開発と既存システムの改良で比べた値は「種別ごとのテスト量の違い」で扱っています。
種別の割合はどう変わってきたか
資料は、今回の分析対象を2014年度から2019年度の案件の集計と比べています。新規開発は32.5%から29.1%へ、改修・保守は45.8%から51.5%へ変わりました。*1 差を計算すると、新規開発が3.4ポイント減り、改修・保守が5.7ポイント増えています。資料も、以前から新規開発が減り、改修・保守が増えつつある傾向にあるとしています。
要員を探すときも、任せたい案件が新規開発なのか改修・保守なのかを先に決めておくと、候補者に求める経験を伝えやすくなります。同じエンジニアでも、一から作る仕事と、すでに動いているシステムを直す仕事では、確かめたい経験が違うためです。
プラットフォームの内訳
資料は、案件のプラットフォーム（システムを動かす基盤）も集計しています。1つの案件で最初に挙げられたもの（第1回答）を数えた結果、回答のあった1,390件のうち、Linux系が427件（30.7%）、Windowsのサーバ系が415件（29.9%）でした。*1 続いてWindowsのPC系が220件（15.8%）、メインフレーム系が129件（9.3%）、UNIX系が116件（8.3%）、その他が83件（6.0%）です。
Windowsの2つを合わせると635件（45.7%）、Linux系とUNIX系を合わせると543件（39.1%）になります。メインフレーム（大型の汎用コンピューター）系は1割に届かず、集まった案件の大半はサーバ系とPC系の環境です。自社の案件がメインフレームで動いている場合は、この資料の値をそのまま当てはめてよいかを慎重に考える必要があります。
件数が種別の1,479件と違うのは、設問ごとに回答のあった案件の数が違うためです。次に見る規模の集計は1,350件で、種別・プラットフォーム・規模の3つの集計は同じ案件の集まりではありません。それぞれ別の表として集計されており、種別とプラットフォームを掛け合わせた値は示されていません。
なぜ平均では比べられないのか
案件の規模は、SLOC（プログラムの行数）で集計されています。単位はKSLOC（千行）で、回答のあった1,350件の中央値は31.8KSLOCでした。四分位（小さい順に並べて4等分した区切り）で見ると、下から4分の1の位置にあたるP25が9.9KSLOC、4分の3の位置にあたるP75が96.1KSLOCです。*1
一方、平均は152.2KSLOCで、中央値との比を計算すると約4.79倍になります。最も大きい案件は21,759.0KSLOCでした。*1 ごく一部の大きな案件が平均を引き上げているため、平均は中央値から大きく離れています。
資料によると、100KSLOC以下の案件がおよそ4分の3を占め、中央値は2014年度から2019年度の32.6KSLOCとほとんど変わっていません。*1 自社の案件の規模を比べるときは、平均ではなく、中央値とP25・P75の3つの値のどこに入るかで位置を確かめます。P75をP25で割ると約9.71倍あり、同じ資料の中でも案件の規模には大きな開きがあるためです。
相場とどう比べるのか
ここまでの内訳をもとに、遅れている自社の案件を相場と比べる手順を4つに整理すると、次のようになります。
| 手順 | やること | 理由 |
|---|---|---|
| 1 種別を選ぶ | 遅れている案件が新規開発か、改修・保守かなど、種別を1つに決める | 集まった案件の51.5%が改修・保守で、種別を決めないと別の種別の値と比べることになる |
| 2 規模の位置を見る | 自社の案件の規模が、中央値とP25・P75のどこに入るかを確かめる | P25とP75で約9.71倍の開きがあり、中央値だけでは自社の案件が大きい側か小さい側かが分からない |
| 3 中央値で比べる | 平均ではなく、中央値と四分位を使って比べる | 平均は一部の大きな案件に引き上げられ、中央値の約4.79倍になっている |
| 4 不足分だけ補う | 相場から外れている分だけを、人の追加か期間の延長で補う | 資料の案件の集まりが自社と近いとは言い切れず、体制全体を一律に増やすと判断を誤りやすい |
4つ目の手順で足りないと判断した作業は、外部の専門人材に任せる候補になります。フリーランスを含む業務委託は、作業の中身と期間を決めて依頼できるため、一時的に足りない分を補うのに向いています。一方で、1つ目から3つ目までの手順は、自社で行います。どこが足りないかを自社で決めておかないと、委託先に何を任せるのかがはっきりしないためです。
体制の相場として外部に任せた作業量の割合を扱った「外部委託工数比率とは」と、規模ごとの生産性を扱った「FP生産性とは」も、同じ資料の別の節をもとにしています。種別と規模の位置を確かめたうえで、あわせて使うと比べる材料が増えます。
つまずきやすい点
一つ目は、種別を決めないまま全体の値と比べてしまうことです。新規開発の案件を全体の値と比べても、新規開発の相場と比べたことにはなりません。まず自社の案件の種別を決め、その種別の値を探すところから始めます。
二つ目は、3つの集計を組み合わせてしまうことです。種別は1,479件、プラットフォームは1,390件、規模は1,350件の集計で、同じ案件の集まりではありません。「改修・保守で、Linux系の案件の規模」のような値は、この集計からは求められません。
三つ目は、この資料の値を業界全体の値として扱うことです。集計の対象は、IPAにデータを提供した企業のプロジェクトで、業界全体から偏りなく選んだ案件ではありません。*1 また、ここで見た集計は案件の属性をまとめたもので、種別ごとの規模や工期、案件が遅れたかどうかは含まれていません。相場は目安として使い、自社の案件と種別や環境が近いかを確かめてから比べます。
まとめ：開発案件の種別で確かめておきたい3つの点
開発案件の種別を踏まえて相場と比べるうえで、確かめておきたい点は3つに整理できます。第一に、遅れている案件の種別を1つに決め、同じ種別の値と比べること。第二に、規模は平均ではなく、中央値とP25・P75の3つの値で位置を確かめること。第三に、相場から外れている分だけを、人の追加か期間の延長で補うことです。この3点を踏まえておけば、「相場より人が少ないと思って増やしたのに、比べた相手が別の種類の案件だった」という事態を避けやすくなります。足りない作業を誰に任せるかに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
規模の集計に使われている「実効SLOC」とは何ですか
コメント行と空行を除いて数えたプログラムの行数です。IPAの資料は、規模の集計にこの数え方で数えた行数（実効SLOC実績値）を使っています。*1 自社の案件と比べるときは、社内の数え方がコメント行や空行を含めていないかを先に確かめておくと、比べやすくなります。
プラットフォームの「第1回答」だけを数えると、何が起きますか
複数の環境で動く案件も、最初に挙げられた1つの環境として数えられます。*1 たとえばWindowsのサーバ系とLinux系の両方を使う案件は、どちらか一方にしか入っていません。自社の案件が複数の環境にまたがるときは、主に使う環境で比べることになります。
資料には、ここで紹介した以外の集計もありますか
あります。資料の1.2節は主な集計項目を紹介したもので、そのほかの集計項目はA3.1節に掲載されています。*1 規模の分布も、200KSLOC以下を10KSLOC刻みで並べた図で示されています。
ソフトウェア開発分析データ集は毎年出ていますか
IPAのソフトウェア開発分析データ集は、年度ごとに公開されています。*3 相場として使うときは、どの年度版の値かを確かめておきます。本記事では2022年版を使っています。
開発の体制を相談したいとき
遅れている案件で足りない作業の洗い出しから、ご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：IPA「ソフトウェア開発分析データ集2022」（独立行政法人情報処理推進機構 社会基盤センター）。表紙の記載、分析対象の年度、1.2.1の開発プロダクトの種別、1.2.4のプラットフォーム、1.2.5のSLOC規模を参照。図と表は資料の数値をもとに作成（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。1.2.1（累積件数と比率）、1.2.4（第1回答の件数と比率）、1.2.5（N・下端・P25・中央値・P75・上端・平均・標準偏差）の資料本体（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。データ集が年度ごとに公開されていることを参照（2026年9月確認）
