LASSIC Media らしくメディア

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

リリースしたあとに、直したはずの機能から呼び出しが来る。次の案件に入れたはずの担当者が戻ってきます。

対応そのものはすぐ終わるのに、予定はその都度ずれます。何件来るかを誰も持っていないからです。

手がかりは、リリース後の不具合を集めた統計です。

IPAの資料では、新規開発の発生不具合密度の中央値が1KSLOCあたり0.021件でした*1。全年度でN＝103です*1。

同じ集計の平均は0.140件です*1。中央値の6.7倍で、上に長い分布になっています*1。

直したはずの機能から呼び出しが来る

不具合対応そのものは、たいてい長くかかりません。原因が分かれば直せる範囲に収まります。

読めないのは件数です。何件来るかが分からないので、次の案件に何人出せるかも決まりません。

この件数の分布を集計した資料があります*1。IPAの「ソフトウェア開発分析データ集2022」で、今回見るのは業種編の製造業です*1。

資料の規模も示されています*1。5,546プロジェクトの定量データを分析したものです*1。

数値の出所も断っておきます*1。表2-1-1、表2-1-2、表2-1-4に示された値をそのまま引きました*1。

倍率は、その値から筆者が算出しました*1。資料に載っている数字ではありません*1。

欄名の呼び替えも先に断ります*1。この記事では「下端」「上端」と呼びますが、資料では分布の両端を示す別の欄名になっています*1。値そのものは資料のものです*1。

出典はIPA「ソフトウェア開発分析データ集2022 業種編（製造業）」です*1。示された値を用いて図と表を作成する編集と加工を筆者が行いました*1。

発生不具合密度とはKSLOCあたりの件数

先に定義を確かめます*1。SLOC発生不具合密度は、KSLOCあたりの発生不具合数とされています*1。

KSLOCの意味も書かれています*1。SLOCはソースコード行数で、1,000SLOCが1KSLOCです*1。

数える期間も定義されています*1。発生不具合数は、システム稼動後6か月間の累計値を基本的に用いるとされています*1。

ただし例外も明記されています*1。そのデータが無い場合は、他の期間の累計値を使用するとされています*1。

ここは読み方に関わります*1。6か月ではない期間の値が混ざっているため、「6か月で0.021件」と言い切ることはできません*1。

層別の条件も示されています*1。開発5工程がそろっているもの、開発プロジェクトの種別が明確なもの、主開発言語が明確なものが対象です*1。

種別の分け方も書かれています*1。新規開発は種別が新規開発のもの、改良開発は改修・保守か拡張のいずれかです*1。

中央値0.021件、平均0.140件で6.7倍の開き

まず全年度の新規開発から見ます*1。表2-1-4で、全体はN＝103でした*1。

4本の値を並べます*1。中央値が0.021件、P25が0.000件、P75が0.122件、標準偏差が0.284件です*1。

下端と上端も示されています*1。下端が0.000件、上端が2.005件でした*1。

平均は0.140件です*1。中央値0.021件で割ると6.7倍になります*1。

この形は上に長い分布です*1。多くが0の近くに寄り、少数の大きい値が平均を引き上げています*1。

ですから掛け算の前提には中央値を置きます*1。平均を件数の見込みに使うと、多くの案件では過大になります*1。

資料自身も概算を書いています*1。10万行で2個の不具合が発生するのが相場であり、これは中央値での概算だとされています*1。

平均で計算した場合も併記されています*1。平均値であれば1万行で1個強だとされています*1。

同じ資料の中に、水準の違う2つの概算が並んでいることになります*1。どちらを使うかで人数の見込みが変わります*1。

規模帯で上端が入れ替わる

次に規模帯で分けます*1。表2-1-4は4つの帯に分かれています*1。

40KSLOC未満はN＝40でした*1。中央値0.000件、P25が0.000件、P75が0.261件、標準偏差が0.292件、上端が1.013件、平均が0.178件です*1。

40KSLOC以上100KSLOC未満はN＝30でした*1。中央値0.040件、P75が0.101件、標準偏差が0.376件、上端が2.005件、平均が0.149件です*1。

100KSLOC以上300KSLOC未満はN＝21でした*1。中央値0.047件、P75が0.165件、標準偏差が0.166件、上端が0.640件、平均が0.113件です*1。

300KSLOC以上はN＝12でした*1。中央値0.002件、P75が0.023件、標準偏差が0.071件、上端が0.240件、平均が0.035件です*1。

中央値の並びを追います*1。0.000件、0.040件、0.047件、0.002件です*1。規模が上がるにつれて増える形にも減る形にもなっていません*1。

平均の並びは違います*1。0.178件、0.149件、0.113件、0.035件と単調に下がります*1。

ここで上端が入れ替わります*1。中央値の上端は100KSLOC以上300KSLOC未満の0.047件、P75の上端は40KSLOC未満の0.261件でした*1。

標準偏差ではまた別です*1。上端は40KSLOC以上100KSLOC未満の0.376件です*1。

つまりどの欄で並べるかで上端の帯が変わります*1。ですから「規模が大きいほど不具合が出る」とも「小さいほど出る」とも書けません*1。

理由は資料に記載がありません*1。帯ごとのNが12から40までの幅で、細かい順位を扱える件数ではないという点も添えておきます*1。

改良開発は1件の値で平均が動く

改良開発の集計も載っています*1。表2-1-2で、全体はN＝36でした*1。

4本の値を並べます*1。中央値が0.000件、P25が0.000件、P75が0.041件、標準偏差が3.062件です*1。

中央値が0.000件という点を押さえます*1。半分以上のプロジェクトでは、集計期間の不具合が0件でした*1。

それでも平均は0.601件です*1。上端18.421件が平均を引き上げています*1。

帯で見るとさらにはっきりします*1。20KSLOC未満はN＝19で、中央値もP75も0.000件でした*1。

同じ帯の上端が18.421件です*1。平均は1.076件、標準偏差は4.209件でした*1。

20KSLOC以上40KSLOC未満はN＝11でした*1。中央値0.000件、P75が0.060件、上端が0.220件、平均が0.044件、標準偏差が0.076件です*1。

残りの帯は値が示されていません*1。40KSLOC以上100KSLOC未満はN＝2、100KSLOC以上300KSLOC未満はN＝4で、いずれも欄が空欄でした*1。300KSLOC以上はN＝0です*1。

ですから改良開発では帯の比較をしていません*1。値が示されている帯が2つしかないためです*1。

2022年度分だけを見ると件数が足りない

年度を限った集計も載っています*1。表2-1-1で、新規開発の2022年度分です*1。

全体はN＝27でした*1。中央値が0.018件、P75が0.116件、標準偏差が0.419件、上端が2.005件、平均が0.184件です*1。

帯ごとの値は限られます*1。40KSLOC未満はN＝14で、中央値0.000件、P75が0.214件、上端が0.725件、平均が0.166件、標準偏差が0.276件でした*1。

残りの帯はほぼ空欄です*1。40KSLOC以上100KSLOC未満はN＝8で中央値0.045件だけ、100KSLOC以上300KSLOC未満はN＝5で中央値0.000件だけが示されています*1。300KSLOC以上はN＝0でした*1。

資料は前の期との比較も書いています*1。新規開発の平均値が2014年度から2019年度の0.136件から0.184件へ、P75が0.074件から0.116件へ増加しているとされています*1。

ただし但し書きが付いています*1。データ件数が少ないので参考程度にする、と資料に明記されています*1。

改良開発についても同じ形の記述があります*1。平均値が0.869件から0.601件へ、P75が0.140件から0.041件へと、新規開発とは逆に減少しているとされています*1。

こちらにも同じ但し書きが付いています*1。データ件数が少ないので参考程度にするとされています*1。

ですからこの記事では、増えたか減ったかを結論にしていません*1。使うのは全年度のN＝103の分布です*1。

この集計から読めないこと

使う前に、限界を並べておきます*1。

第一に、不具合の重さが含まれません*1。1件がどれだけの影響だったかは示されていません*1。

第二に、直すのにかかる時間も含まれません*1。件数の密度だけが示された集計です*1。

第三に、期間が混ざります*1。稼動後6か月間の累計値が基本ですが、そのデータが無い場合は他の期間の累計値が使われています*1。

第四に、件数の少ない区分では値が示されません*1。改良開発の2つの帯と、2022年度分の3つの帯が該当します*1。

第五に、因果が読めません*1。規模帯と密度の関係について、資料は理由を示していません*1。

第六に、各帯は別々のプロジェクトです*1。同じ案件が大きくなったときの変化ではありません*1。

第七に、下端が0.000件です*1。集計期間に不具合が0件だった案件が含まれるため、密度を人数に直す計算では0の扱いを決めておく必要があります*1。

第八に、範囲があります*1。この集計は製造業の分だけです*1。ほかの業種や2022年度より後の傾向は読めません*1。

不具合対応を要員に載せる4段

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

SLOC発生不具合密度［件/KSLOC］（出典：IPA「ソフトウェア開発分析データ集2022 業種編（製造業）」表2-1-4・表2-1-2。発生不具合数はシステム稼動後6か月間の累計値を基本とし、そのデータが無い場合は他の期間の累計値。資料が分布の両端を示す欄を下端・上端と呼び替えている（値は資料のもの）。倍率は示された値から筆者が算出。示された値を用いて表を作成する編集・加工を筆者が行った）

区分	N	P25	中央値	P75	上端	平均	標準偏差
新規開発・全年度・全体	103	0.000	0.021	0.122	2.005	0.140	0.284
40KSLOC未満	40	0.000	0.000	0.261	1.013	0.178	0.292
40KSLOC以上100KSLOC未満	30	0.000	0.040	0.101	2.005	0.149	0.376
100KSLOC以上300KSLOC未満	21	0.000	0.047	0.165	0.640	0.113	0.166
300KSLOC以上	12	0.000	0.002	0.023	0.240	0.035	0.071
改良開発・全体	36	0.000	0.000	0.041	18.421	0.601	3.062
改良開発・20KSLOC未満	19	0.000	0.000	0.000	18.421	1.076	4.209
改良開発・20KSLOC以上40KSLOC未満	11	0.000	0.000	0.060	0.220	0.044	0.076

1段目は、出た件数を数えることです。直した記録ではなく、来た件数を月ごとに並べます。

2段目は、直す作業と決める作業を分けることです。原因を切り分ける判断と、直して確かめる手を切り離します。

3段目は、直す側を期間で区切ることです。何件までを何日間で受けるかを先に置きます。

4段目は、区切った枠を外へ出すことです。件数が読める部分から動かします。

この順番にする理由は、分布に出ています*1。中央値は0.021件で、平均は0.140件でした*1。

平均で枠を作ると、多くの案件では余ります*1。中央値で作ると、上端に当たった案件で足りません*1。

ですから枠は中央値で置き、あふれた分を外で受ける形にします。P75の0.122件が、その受け止め幅の目安になります*1。

改良開発の並びも同じ方向を指します*1。中央値0.000件の帯でも上端は18.421件でした*1。

実務では、3段目と4段目が外部要員の枠になります。フリーランスを含む業務委託は、この枠と相性があります。件数と期間を区切って渡し、片づいたら戻せるためです。

逆に、2段目の切り分けまで渡すと、判断が外に出ます。どこまでを直すと決めるかは社内に残します。

遅れの原因をどこで切るかは、開発の遅延の原因、変更管理ができているのは51.9％で整理しています。

件数を人数に置き換える段では、月あたりの要員数の違い、新規開発7.7人と改修・保守5.6人が下敷きになります。

残った量を数える手順はテストケース数は規模あたり結合51.7件、残量を見積る手順で扱っています。

中央値を掛け算の前提に置く理由は、FP生産性とは、規模が大きいほど中央値が下がる指標でも同じ形で出しています。

最後に範囲を添えておきます*1。この集計は製造業の分で、ほかの業種や2022年度より後の傾向は読めません*1。

まとめ：中央値で枠を置き、あふれた分を外で受ける

第一に、資料です。IPAの「ソフトウェア開発分析データ集2022」は5,546プロジェクトの定量データを分析したもので、今回見たのは業種編の製造業です。業種編は本編と同じ章節番号と図表番号を使うため、抜けている番号が生じると資料に書かれています。第二に、定義です。SLOC発生不具合密度はKSLOCあたりの発生不具合数で、1,000SLOCが1KSLOCです。発生不具合数はシステム稼動後6か月間の累計値を基本的に用いますが、そのデータが無い場合は他の期間の累計値が使われています。第三に、数値の扱いです。表2-1-1・表2-1-2・表2-1-4に示された値をそのまま引き、倍率はその値から筆者が算出しました。資料が分布の両端を示す欄は、この記事では下端・上端と呼び替えています。値そのものは資料のものです。第四に、新規開発の全年度です。全体はN＝103で、中央値0.021件、P25が0.000件、P75が0.122件、標準偏差0.284件、上端2.005件、平均0.140件でした。平均は中央値の6.7倍で、上に長い分布です。資料も10万行で2個という中央値での概算と、平均値なら1万行で1個強という2つの数字を併記しています。第五に、規模帯です。中央値は0.000件、0.040件、0.047件、0.002件で単調ではありませんが、平均は0.178件、0.149件、0.113件、0.035件と単調に下がります。中央値の上端は100KSLOC以上300KSLOC未満、P75の上端は40KSLOC未満、標準偏差の上端は40KSLOC以上100KSLOC未満で、欄ごとに上端の帯が違います。第六に、改良開発です。全体はN＝36で中央値0.000件、P75が0.041件ですが、上端は18.421件、平均は0.601件、標準偏差は3.062件でした。20KSLOC未満は中央値もP75も0.000件で、上端18.421件、平均1.076件です。値が示されない帯があるため帯の比較はしていません。第七に、限界です。不具合の重さも直す時間も含まれず、集計期間には6か月以外の値が混ざります。

よくある質問

発生不具合密度とは何ですか。

IPAのソフトウェア開発分析データ集2022では、SLOC発生不具合密度をKSLOCあたりの発生不具合数と定義しています。1,000SLOCが1KSLOCです。発生不具合数はシステム稼動後6か月間の累計値を基本的に用いますが、そのデータが無い場合は他の期間の累計値が使われます（確認日2026年9月7日）。

相場はどのくらいですか。

業種編（製造業）の表2-1-4では、新規開発の全年度がN＝103で中央値0.021件／KSLOC、P25が0.000件、P75が0.122件、平均0.140件、標準偏差0.284件でした。資料は10万行で2個が中央値での概算、平均値であれば1万行で1個強と書いています。

見積りには平均と中央値のどちらを使えばよいですか。

この分布ではP25も下端も0.000件で、平均0.140件は中央値0.021件の6.7倍です。上に長い分布なので、掛け算の前提には中央値を置き、あふれた分を別に受ける形にします。倍率は示された値から算出しました。

規模が大きいほど不具合は増えますか。

この集計からは言えません。中央値は40KSLOC未満0.000件、40KSLOC以上100KSLOC未満0.040件、100KSLOC以上300KSLOC未満0.047件、300KSLOC以上0.002件で単調ではありません。中央値とP75と標準偏差で上端の帯が入れ替わります。理由は資料に記載がありません。

改良開発はどうなっていますか。

表2-1-2では全体がN＝36で中央値0.000件、P75が0.041件ですが、上端は18.421件、平均は0.601件、標準偏差は3.062件でした。20KSLOC未満は中央値もP75も0.000件で上端18.421件です。値が示されない帯があるため帯の比較はしていません。

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。資料の構成・業種編3編の公開・5,546プロジェクトという分析対象の一次情報として（2026年9月確認）
2. *2　参考：IPA「ソフトウェア開発分析データ集2022（製造業編）」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102174.pdf）。表2-1-1・表2-1-2・表2-1-4の分位点と平均と標準偏差、発生不具合密度の定義、集計期間、層別の条件、前の期との比較と但し書きの一次情報として。示された値を用いた図表の作成という編集・加工を筆者が実施（2026年9月確認）
3. *3　参考：IPA「ソフトウェア開発分析データ集2022」本編（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。業種編が本編と同一の章節番号・図表番号を用いるという構成の確認として（2026年9月確認）
4. *4　参考：IPA「ソフトウェア開発分析データ集」一覧（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに資料が公開されているという構成の確認として（2026年9月確認）