LASSIC Media らしくメディア
改良開発と新規開発のテスト量の違い｜改修でも軽くならない理由
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAの資料では、1,000行あたりの結合テストのケース数の中央値は、改良開発が67.91件、新規開発が37.63件でした。
- 総合テストでも改良開発は24.84件で、新規開発の9.41件を上回ります。
- 改修の案件を新規開発と同じ人数で組むと、資料にある改良開発の水準までテストケースを作りきれなくなりがちです。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
改修の案件だから、テストは軽く済むはずだ。新規開発と同じ人数を付けておけば足りるだろう——。テスト工程の体制を決める場面では、こうした考えで人数を決めてしまうことがあります。ところがIPAの資料では、1,000行あたりの結合テストのケース数の中央値が、改良開発で67.91件、新規開発で37.63件でした。*2 改良開発とは、すでに動いているシステムに機能を加えたり直したりする開発で、新規開発はシステムを一から作る開発を指します。
種別ごとのテスト量を知っておくと、テスト工程に何人を割くかを見積もる手がかりになります。ただし、この値は万能ではありません。同じ種別の中でも案件ごとの差は大きく、資料も2022年に公開されたものです。本記事では、開発チームの体制を決める担当者に向けて、種別ごとのテスト量の違い、平均ではなく中央値で見る理由、見積もりの手順、そして外部に頼むときに確認したい点を整理します。
目次
改良開発・新規開発・再開発とは
IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、開発の種別を新規開発、改良開発、再開発の3つに分け、種別ごとにテストの値を表にしています。*2 再開発は、既存のシステムを作り直す開発です。同じ「既存のシステムに関わる仕事」でも、機能を加える改良開発と、作り直す再開発は別の種別として集計されています。
この資料は2022年9月26日に公開され、2025年8月28日に最終更新されました。これまでに収集した5,546プロジェクトの定量データから分析したもので、「事業終了に伴い今後の発行予定はございません」と明記されています。*1 新しい版が出ない資料なので、最新の水準を示すものではなく、種別どうしを比べる基準として使います。
テスト量の単位は件／KSLOC（1,000行あたりの件数）です。プログラム1,000行あたり、何件のテストケースを作ったかを表します。*2 行数で割っているので、規模の違う案件どうしでもテストの手厚さを比べられます。
結合テストのケース数
結合テスト（部品を組み合わせて動きを確かめるテスト）のケース数の中央値は、改良開発が67.91件、再開発が39.30件、新規開発が37.63件でした。*2 N（集計に使われたプロジェクト数）は改良開発が393、再開発が56、新規開発が209です。
中央値どうしを割ると、改良開発は新規開発の1.81倍になります。ただし、Nが393と209で違い、同じプロジェクトの集まりを比べたものではありません。1.81倍という倍率よりも、「改良開発のほうが多い」という順序として受け止めます。
1万行（10KSLOC）の案件に当てはめて計算すると、結合テストのケース数は改良開発で679件、再開発で393件、新規開発で376件になります。テストの自動化から整える場合は「QAテスト自動化を外注する基盤構築ガイド」で進め方を扱っています。
総合テストのケース数
総合テスト（システム全体を通して確かめるテスト）でも、並びは同じです。中央値は改良開発が24.84件、再開発が13.45件、新規開発が9.41件でした。*2 中央値どうしを割ると改良開発は新規開発の2.64倍で、結合テストの1.81倍より開きが大きくなります。
1万行の案件に当てはめて計算すると、総合テストのケース数は改良開発で248件、再開発で134件、新規開発で94件です。どの種別でも、結合テストのほうが総合テストより中央値が高くなっています。テスト工程の人員は、結合テストと総合テストで分けて見積もると、実際の作業量に近づけやすくなります。
ここでもNが違うため、2.64倍という値は目安にとどめます。受け入れる側のテストについては「システム開発の検収・受入テストの進め方」で整理しています。
なぜ平均ではなく中央値で見るのか
平均を使わないのは、ごく一部の極端な案件に値が引っ張られるためです。総合テストの改良開発は、平均が1,026.89件で、中央値24.84件の41.3倍でした。いちばん大きい案件は219,000.0件／KSLOCに達しています。*2 平均で見積もると、ほとんどの案件にとって現実離れした人数になります。
結合テストも同じ傾向です。改良開発は平均661.59件で中央値の9.7倍、新規開発も平均258.33件で中央値の6.9倍です。*2 そのため、中央値と、小さいほうから4分の1の位置の値（P25）、4分の3の位置の値（P75）だけを見ます。
多めの案件（P75）が少なめの案件（P25）の何倍かを計算すると、結合テストは改良開発が5.40倍、新規開発が4.48倍、再開発が3.84倍でした。総合テストは改良開発が6.65倍、再開発が6.61倍、新規開発が4.60倍です。極端な案件を除いても3.8倍から6.7倍の開きがあり、種別を決めても案件ごとの差は大きく残ります。
検出バグの数との違い
同じ表には、テストで見つかったバグの数も載っています。結合テストで見つかったバグの件数（現象数）の中央値は、新規開発が1.565件、再開発が1.091件、改良開発が0.976件でした。*2 ケース数では改良開発が上でしたが、バグの数では新規開発が上に来ており、順序が逆になっています。
バグの原因の件数（原因数）で見ても、新規開発が1.154件、改良開発が0.996件、再開発が0.593件で、新規開発が上です。*2 ただし、ケース数の行とバグ数の行はNが違うため、2つを割ってケース1件あたりのバグ数を出すことはできません。順序が逆になる理由も、資料には示されていません。
現象数と原因数どうしも比べられません。本編も、現象数と原因数の両方のデータを出しているプロジェクトの重なりが少なく、そのまま比べることはできないと注意しています。バグの数は、それぞれの行の中で種別の順序を見るための値で、テストの人員を決める根拠には使わないほうが無難です。
テスト体制の見積もり方
ここまでの値を使うと、テスト工程の体制は次の4段で見積もれます。表の値は本編の表5-1-2から表5-1-4をまとめたものです。
| 工程と種別 | P25 | 中央値 | P75 | P75÷P25 | N |
|---|---|---|---|---|---|
| 結合テスト・改良開発 | 29.52 | 67.91 | 159.51 | 5.40倍 | 393 |
| 結合テスト・再開発 | 18.53 | 39.30 | 71.22 | 3.84倍 | 56 |
| 結合テスト・新規開発 | 17.84 | 37.63 | 79.84 | 4.48倍 | 209 |
| 総合テスト・改良開発 | 8.54 | 24.84 | 56.75 | 6.65倍 | 378 |
| 総合テスト・再開発 | 4.13 | 13.45 | 27.29 | 6.61倍 | 54 |
| 総合テスト・新規開発 | 4.69 | 9.41 | 21.57 | 4.60倍 | 182 |
- 1段目：案件が改良開発か、新規開発か、再開発かを、規模を出す前に決める
- 2段目：種別と工程が合う行の中央値に、対象の行数（KSLOC）を掛ける
- 3段目：P25とP75も掛けて、少ない場合と多い場合の見込みを作る
- 4段目：結合テストと総合テストで、別々に人を割り当てる
順番を逆にして人数を先に決めると、種別によるテスト量の違いが計画に入りません。とくに改修の案件は、規模あたりのケース数が新規開発より高い水準なので、新規開発と同じ人数では足りなくなりがちです。種別を決めても3.8倍から6.7倍の開きは残るため、テストが始まったら実際に作ったケース数を表の値と見比べ、見込みより多いか少ないかを確かめます。
たとえば1万行の改修の案件なら、結合テストのケース数は中央値から679件と計算できます。人数は、この件数と、自社で1人が1日に書いて実行できるケースの数から割り出します。ケース1件あたりの作業の重さは資料に含まれていないので、自社の過去の案件の実績を使います。バグの数は、前の節で見たとおり人数を決める根拠にはしません。
外部に委託するときに確認しておきたい点
テストの作業は、何を確かめるかを決める作業と、ケースを書き起こして実行する作業に分けられます。前者は仕様の判断が要るので社員が担当し、後者は外部の専門人材に任せる、という分け方が取れます。ケースの書き起こしと実行は、人を増やした分だけ進めやすい作業だからです。
委託するときは、「どの機能の結合テストのケースを、何件、いつまでに書いて実行するか」まで決めてから頼むと進めやすくなります。テスト工程の数か月だけ人を追加し、終わったら元の体制に戻すなら、フリーランスを含む業務委託の使い方が合います。工程ごとに内製と委託をどう分けているかは「工程別の内製化」で、同じ資料にある外部委託の工数の割合は「外部委託工数比率とは」で扱っています。
まとめ：テスト量で確かめておきたい3つの点
テスト工程の体制を決めるうえで、確かめておきたい点は3つに整理できます。第一に、案件が改良開発か新規開発かを先に決め、改修の案件は規模あたりのケース数が多いことを前提にすること。第二に、平均ではなく中央値とP25・P75で、少ない場合と多い場合の見込みを作ること。第三に、結合テストと総合テストで人員を分けて見積もり、テストが始まったら実際のケース数で見込みを確かめることです。この3点を踏まえておけば、「改修だから軽いと思っていたのに、テストが終わらない」という事態を避けやすくなります。テスト工程の人員の確保に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
種別ごとのテスト量の違いは、最近の案件でも同じですか
過去の版と比べると大きな変化はありません。本編は結合テストのケース数について、新規開発は35.70件から37.63件、改良開発は62.43件から67.91件、再開発は43.21件から39.30件と比べ、いずれもあまり差はないと記しています。*2 ただし2022年公開の資料で今後の発行予定はないため、それより後の傾向は公表されていません。*1
再開発の値はどう扱えばよいですか
参考にとどめるのが無難です。再開発は結合テストのケース数がN56、総合テストがN54で、バグの原因数はN22と、ほかの種別より集計に使われた案件が少なくなっています。*2 見積もりの軸は改良開発と新規開発の値に置き、再開発はその間の値として見ておくと扱いやすくなります。
総合テストでも、バグの数はケース数と順序が逆になりますか
はい、逆になります。総合テストで見つかったバグの現象数の中央値は、新規開発が0.282件、再開発が0.228件、改良開発が0.164件で、Nは141、48、281でした。*2 結合テストと同じく、ケース数の行とNが違うため、ケース1件あたりの数は出せません。
テスト工程の体制を相談したいとき
テスト工程に何人を割くか、案件の種別に合わせた見積もりからご相談いただけます。
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。5.1節の表5-1-2（新規開発）・表5-1-3（改良開発）・表5-1-4（再開発）の四分位・平均・標準偏差・N、5章の対象条件、現象数と原因数は比較できないとの注記、過去の版との比較を参照（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集2022グラフデータ」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000103288.zip）。出典：同グラフデータ。表の値の確認に使用。著作権はIPAが保有（Copyright 2022 IPA）（2026年9月確認）
