LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

改修の案件だから、テストは軽く済むと考えていないでしょうか。

規模あたりで測ると、逆の形が出ます。

IPAの資料では、結合テストのケース数の中央値が改良開発で67.91件／KSLOCでした*1*2。

新規開発は37.63件です*2。改良開発のほうが多い形になります*2。

ただし行ごとにNが違うため、差の大きさではなく順序として読みます*2。

種別でテストの量が変わる

体制を組むとき、案件の種別で厚さを変えているでしょうか。改修だから軽い、新規だから重い、という置き方をしがちです。

その前提を確かめられる資料があります*1。IPAの「ソフトウェア開発分析データ集2022」で、公開は2022年9月26日、最終更新は2025年8月28日と記されています*1。

規模も示されています*1。これまでに収集した5,546プロジェクトの定量データから分析したと書かれています*1。

性質を先に書きます*1。この資料には「事業終了に伴い今後の発行予定はございません」と明記されています*1。最新の調査ではありません*1。

構成も確かめられます*4。本編のほかに業種編3編、サマリー版、マンガ解説版、グラフデータが公開されています*4。

沿革も書かれています*4。IPAは2005年からエンタプライズ分野の開発データを収集し、2020年に書籍版の名称を変えて現在の形になったとされています*4。

該当する節は本編の5.1です*2。SLOC規模あたりのテストケース数と検出バグ数が示されています*2。

扱う範囲を先に分けます*2。同じ5.1節には全開発種別をまとめた表もありますが、この記事では開発種別ごとの3つの表に絞ります*2。

対象の条件も書かれています*2。開発5工程のフェーズ有無がすべてそろったプロジェクトが対象です*2。

表記についても書いておきます*2。この節の工程名には短縮した表記が使われているため、この記事では言い換えて記載しています*2。

単位は件／KSLOCです*2。1,000行あたり何件のテストケースを作ったか、という形です*2。

数値の扱いを書きます*2*3。四分位は本編の表に示された値をそのまま引き、倍率と換算は表の値から筆者が算出しました*2*3。

グラフデータの著作権はIPAが保有しています*3。使用条件に従い、著作権表示としてCopyright 2022 IPAを記します*3。

まず結合テストの値を見ます*2。

結合テストは改良67.91、新規37.63

本編の表5-1-3は、改良開発のSLOC規模あたりの値を示しています*2。結合テストのケース数の中央値は67.91件／KSLOCでした*2。

Nは393です*2。3つの種別の中で最も多い件数になります*2。

表5-1-2は新規開発です*2。結合テストのケース数の中央値は37.63件／KSLOCで、Nは209でした*2。

表5-1-4は再開発です*2。中央値は39.30件／KSLOCで、Nは56です*2。

降順に並べると位置が見えます*2。改良開発67.91、再開発39.30、新規開発37.63の順です*2。

中央値どうしを割ると1.81倍です*2。改良開発が新規開発より多い形になります*2。

ただし差の大きさは論じません*2。Nが393と209で、同じプロジェクトの集合ではないためです*2。

読めるのは順序です*2。同じ単位で並べたとき、改良開発が上に来るという点までです*2。

10KSLOCで換算すると量が見えます*2。改良開発が679件、再開発が393件、新規開発が376件です*2。

資料は理由を説明していません*2。なぜ種別で水準が違うのかは書かれていません*2。

過去との比較は添えられています*2。本編は新規開発について35.70から37.63などあまり差はないと記し、改良開発については62.43から67.91などあまり差はないと記しています*2。

テストの自動化を土台から作る話は別に整理されています。QAテスト自動化を外注する基盤構築ガイドが参考になります。

次に、総合テストの側を見ます*2。

総合テストは改良24.84で新規の2.64倍

同じ3つの表に総合テストの行もあります*2。改良開発の中央値は24.84件／KSLOCでした*2。

Nは378です*2。結合テストの393とは違う件数になります*2。

新規開発は9.41件／KSLOCでした*2。Nは182です*2。

再開発は13.45件／KSLOCです*2。Nは54でした*2。

降順は結合テストと同じ並びです*2。改良開発24.84、再開発13.45、新規開発9.41の順になります*2。

中央値どうしを割ると2.64倍です*2。結合テストの1.81倍より開きが大きい形です*2。

ここでも差の大きさは論じません*2。Nが378と182で違うためです*2。

10KSLOCなら改良開発が248件です*2。再開発が134件、新規開発が94件になります*2。

工程どうしの関係も押さえます*2。どの種別でも、結合テストのほうが総合テストより中央値が高くなります*2。

再開発は過去と少し動いています*2。本編は43.21から39.30で多少の上下はあるが、あまり差はないと記しています*2。

ここまでで体制の話に移せます。改修の案件を新規と同じ厚さで組むと、規模あたりのケース数の水準に届かない形になります*2。

受入の側の進め方は別に整理されています。システム開発の検収・受入テストの進め方をご覧ください。

次に、幅と平均を押さえます*2。

P25とP75で3.8倍から6.7倍ひらく

幅を倍率にすると、この指標の性質が見えます*2。

結合テストの改良開発は5.40倍です*2。159.51を29.52で割った値です*2。

結合テストの新規開発は4.48倍でした*2。79.84を17.84で割った値です*2。

結合テストの再開発はいちばん狭いです*2。71.22を18.53で割ると3.84倍になります*2。

総合テストはさらに広がります*2。改良開発が6.65倍、再開発が6.61倍、新規開発が4.60倍です*2。

つまり真ん中の半分の案件だけで3.8倍から6.7倍ひらきます*2。種別を絞っても幅は残ります*2。

平均も見ておきます*2。総合テストの改良開発は平均1,026.89件で、中央値24.84の41.3倍になります*2。

標準偏差は12,534.04です*2。上端が219,000.0件／KSLOCという値を含んでいます*2。

結合テストの改良開発も同じ形です*2。平均661.59で中央値67.91の9.7倍、上端は100,000.0でした*2。

新規開発も離れます*2。結合テストの平均が258.33で中央値37.63の6.9倍、上端は37,310.81です*2。

だから平均は使えません*2。この節では中央値と四分位だけを見ます*2。

工程ごとに内製と委託を分ける実態は別に整理されています。工程別の内製化｜設計開発テストだけ委託が34.4％で扱っています。

次に、検出バグの側を押さえます*2。

検出バグはケース数と順序が逆になる

同じ3つの表には検出バグの行もあります*2。現象数と原因数の2通りで示されています*2。

結合テストの現象数を並べます*2。新規開発が1.565件／KSLOC、再開発が1.091、改良開発が0.976でした*2。

Nはそれぞれ違います*2。新規開発が156、改良開発が296、再開発が49です*2。

ケース数とは順序が逆になります*2。ケース数では改良開発が上でしたが、検出バグの現象数では新規開発が上に来ます*2。

原因数でも同じ向きです*2。新規開発が1.154、改良開発が0.996、再開発が0.593でした*2。

こちらもNが違います*2。新規開発が100、改良開発が263、再開発が22です*2。

ここで割り算をしてはいけません*2。ケース数の行と検出バグの行はNが違うため、ケース1件あたりのバグ数を出すことはできません*2。

現象数と原因数も比べられません*2。本編は、両者のデータを提出しているプロジェクト群の重なりが少ないため、数だけのデータでは比較できないことに留意されたいと明記しています*2。

だから読めるのは各行の中の順序だけです*2。同じ現象数の列で種別を並べる、という形にとどめます*2。

再開発の原因数はNが22です*2。件数が少ないので、この行は参考の範囲にとどめます*2。

総合テストの側も並べておきます*2。現象数は新規開発0.282、再開発0.228、改良開発0.164で、Nは141と48と281です*2。

資料は理由を説明していません*2。なぜケース数と検出バグで順序が逆になるのかは書かれていません*2。

体制の相場そのものは別の指標で測れます。外部委託工数比率とは、中央値63.4％が示す体制の相場で同じ資料の別の指標を扱っています。

再開発はNが少なく、過去比較は3種別とも横ばい

再開発の行は件数が少なめです*2。結合テストのケース数がN56、総合テストがN54でした*2。

検出バグはさらに少ないです*2。結合テストの現象数がN49、原因数がN22です*2。

だから水準の断定は避けます*2。この記事では改良開発と新規開発の対比を軸にし、再開発は間に置く形で読みます*2。

過去との比較は3種別とも添えられています*2。いずれも結合テストのテストケースについての記述です*2。

新規開発は35.70から37.63です*2。本編はあまり差はないと記しています*2。

改良開発は62.43から67.91でした*2。こちらもあまり差はないとされています*2。

再開発は43.21から39.30です*2。多少の上下はあるが、あまり差はないと記されています*2。

つまり3種別とも横ばいです*2。種別ごとの水準の違いは、この6年ほど続いてきた形だと読めます*2。

箱ひげ図も併載されています*2。本編は各表の検出バグ数について、対応する箱ひげ図を示すと記しています*2。

図表の対応も書かれています*2。表5-1-2はデータ白書2018の図表7-5-27、表5-1-3は7-5-33、表5-1-4は7-5-39に対応するとされています*2。

読めないことも押さえます*2。ケース1件あたりの重さ、種別ごとに水準が違う理由、自動化しているかどうかは含まれていません*2。

時点の限界もあります*1。この資料は2022年の公開で、事業終了に伴い今後の発行予定はないと明記されているため、それより後の傾向は読めません*1。

種別に合わせて体制を置く4段

ここまでの分布を、自社の手順に落とします*2。

SLOC規模あたりのテストケース数（IPA「ソフトウェア開発分析データ集2022」表5-1-2から表5-1-4に示された値。単位は件／KSLOC。工程名は言い換え。倍率は表の値から筆者が算出。行ごとにNが違い同じプロジェクトの集合ではない。Copyright 2022 IPA）

工程と種別	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を掛けて、下と上の見込みを2つ作ります。

4段目は工程を分けることです。結合テストと総合テストで別々に人を割り当てます*2。

順番を逆にすると崩れます。人数を先に決めると、種別による水準の違いが計画に入りません*2。

改修の案件では特に注意が要ります*2。規模あたりのケース数は改良開発のほうが高い水準なので、新規と同じ厚さでは届かない形になります*2。

それでも幅は残ります*2。同じ種別の中でも3.8倍から6.7倍ひらくので、実際に作ったケース数で位置を確かめる必要があります*2。

検出バグの数は体制の根拠にしません*2。ケース数の行とNが違い、ケース1件あたりの数も出せないためです*2。

実務では、決める作業と作る作業を分けることになります。何を確認するかの決めは社員が持ち、ケースの書き起こしと実行は外部の要員に任せる形が取れます。

ケースの作成は人を足せば量が増える種類の作業です。仕様の判断が要る部分と、手を動かす部分を切り分けておく必要があります。

期間を区切って入れるなら、フリーランスを含む業務委託の使い方が合います。テスト工程の数か月だけ人を足し、収まったら戻す形にします。

最後に時点を添えておきます*1。2022年公開の資料なので、直近の相場ではなく比較の基準として使う形になります*1。

まとめ：種別で厚さを変える

第一に、資料の性質です。IPAの「ソフトウェア開発分析データ集2022」は公開が2022年9月26日、最終更新が2025年8月28日となっており、これまでに収集した5,546プロジェクトの定量データから分析されています。事業終了に伴い今後の発行予定はないと明記されているため、最新の調査ではありません。四分位は本編の表に示された値で、倍率と換算は表の値から筆者が算出しました。グラフデータの著作権はIPAが保有しており、著作権表示としてCopyright 2022 IPAを記します。第二に、扱う範囲です。同じ5.1節には全開発種別をまとめた表もありますが、この記事では開発種別ごとの表5-1-2から表5-1-4に絞りました。工程名は短縮した表記が使われているため言い換えて記載しています。第三に、結合テストです。ケース数の中央値は改良開発が67.91件でNが393、再開発が39.30件でNが56、新規開発が37.63件でNが209でした。中央値どうしを割ると改良開発は新規開発の1.81倍です。第四に、総合テストです。改良開発が24.84件でNが378、再開発が13.45件でNが54、新規開発が9.41件でNが182でした。割ると2.64倍で、結合テストより開きが大きくなります。ただしNが違うため差の大きさは論じていません。第五に、幅と平均です。P75をP25で割ると3.84倍から6.65倍になります。総合テストの改良開発は平均1,026.89で中央値の41.3倍、上端が219,000.0であるため平均は根拠にしません。第六に、検出バグです。結合テストの現象数は新規開発1.565、再開発1.091、改良開発0.976でケース数と順序が逆になります。ただしNが違い、本編も現象数と原因数は数だけのデータでは比較できないと明記しているため、各行の中の順序だけを読みました。第七に、過去比較です。3種別とも本編はあまり差はないと記しており、種別ごとの水準の違いは続いてきた形だと読めます。ケース1件あたりの重さ、種別ごとに水準が違う理由、自動化の有無も今回の内容には含まれていません。

よくある質問

改修の案件はテストが軽く済みますか。

規模あたりで見ると逆の形です。IPAのソフトウェア開発分析データ集2022の表5-1-3では、改良開発の結合テストのケース数の中央値が67.91件／KSLOCでNが393でした。表5-1-2の新規開発は37.63件でNが209です。ただしNが違うため差の大きさは論じられません（確認日2026年9月4日）。

総合テストではどうなりますか。

同じ並びで開きが大きくなります。改良開発が24.84件／KSLOCでNが378、再開発が13.45件でNが54、新規開発が9.41件でNが182でした。中央値どうしを割ると改良開発は新規開発の2.64倍です。

平均は使えますか。

使えません。総合テストの改良開発は平均1,026.89で中央値24.84の41.3倍、標準偏差は12,534.04です。上端が219,000.0であるためで、結合テストの改良開発も平均は中央値の9.7倍になります。中央値と四分位だけを見ます。

バグの検出数も改良開発のほうが多いのですか。

順序が逆になります。結合テストの検出バグ現象数の中央値は新規開発1.565、再開発1.091、改良開発0.976でした。ただしNが156と49と296で違い、ケース数の行ともNが違うため、ケース1件あたりのバグ数は出せません。

この水準は最近も同じですか。

今回参照した資料の範囲では横ばいです。本編は結合テストのケース数について、新規開発は35.70から37.63、改良開発は62.43から67.91、再開発は43.21から39.30で、いずれもあまり差はないと記しています。ただし2022年公開の資料なので、それより後の傾向は読めません。

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。公開日・最終更新日・5,546プロジェクト・事業終了に伴う発行予定なしの記述の一次情報として（2026年9月確認）
2. *2　参考：IPA「ソフトウェア開発分析データ集2022」本編（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。表5-1-2から表5-1-4の四分位・平均・標準偏差・N・5章の前文の対象条件と比較不可の注記・過去年度との比較の記述として（2026年9月確認）
3. *3　参考：IPA「ソフトウェア開発分析データ集2022グラフデータ」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000103288.zip）。同じ表の値の確認として。著作権はIPAが保有（Copyright 2022 IPA）（2026年9月確認）
4. *4　参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。業種編3編・サマリー版・グラフデータという構成と、2005年からのデータ収集の沿革の記述として（2026年9月確認）