LASSIC Media らしくメディア

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

外部エンジニアに任せた開発で、稼動後に不具合が出た。何件までなら想定の範囲なのか。件数だけを見ても、想定内かどうかは決まりません。自社の数え方と相手の数え方がそろっていなければ、そもそも同じものを比べていないからです。

出発点になる公的な集計があります。IPAの「ソフトウェア開発分析データ集2022」です。*1 この分析データ集の発行事業は終了し、今後の発行予定はないとされています。*2 2022年版が最後の版です。*2

この記事では、この集計が不具合をどう数えているか、どんな条件で選んだ378件なのかを確かめ、外部エンジニアと先に決めておく項目を挙げます。断っておくと、この集計は開発を外注したかどうかで不具合密度を分けてはいません。

2.6件／KFPは何をどう数えた値か

まず、この集計が測っているものです。IPAは、FP（ファンクションポイント。画面や帳票など機能の数からソフトウェアの規模を数える単位）で規模を計測しているプロジェクトを対象に、1FPあたりの発生不具合数を出しています。*1 ただし表の値は1KFP、つまり1,000FPあたりの件数です。*1 2.6件／KFPは1,000FPあたり2.6件です。

数える期間も決められています。IPAは、発生不具合数はシステム稼動後6か月間の累計値を基本的に用いるが、そのデータが無い場合は他の期間の累計値を使用する、としています。*1 稼動とは、作ったものを業務で使い始めることです。6か月以外の期間で数えた案件が何件あるかは、資料には書かれていません。

対象は、全年度の新規開発で計測手法が明確なプロジェクトです。*1 改良開発と再開発は別の表になります。*1 条件に合った378件で、発生不具合密度の中央値は2.6件／KFPでした。*1 平均は12.7件／KFP、最大値は318.3件／KFPです。*1

中央値と平均がこれだけ離れるのは、大きな1件が引き上げているからではありません。平均12.7に378を掛けると、密度の合計はおよそ4,800です。半分の189件は2.6以下なので、その合計は多くても約491です。残りの189件でおよそ4,310を占める計算になり、上側の半分だけの平均はおよそ22.8件／KFPです。高い値がまとまってある分布です。この計算はこの記事で行いました。

2.6件／KFPは密度であって件数ではありません。件数に直すには、自社の規模をFPで測り、それを1,000で割ったKFPの数を掛けます。1,000FPの案件なら1KFPなので、中央値どおりなら2.6件という見当になります。資料の表はFP規模でも行を分けているので、自社の規模に近い行はそちらで見ます。

378件は近年6年間に絞られていない

次に、どこから選んだ378件かです。IPAは2005年度から分析結果を公開しており、データ件数は累計5,546件です。*1 収集対象の基礎データは、ソフトウェア開発ベンダー35社の協力を得たものだとされています。*1 35社が出したデータなので、業界全体の平均ではありません。

集計の範囲は一律ではありません。最近の実態に即した統計情報を提供するために主な統計値を近年6年間のデータに基づき算出することとしたが、信頼性や生産性など統計値の一部は5,546件全件を対象に算出している、と書かれています。*1 近年6年間とは2016年度〜2021年度のことです。*1

不具合密度は、この資料では信頼性として扱われています。信頼性とは、リリースしたあとに不具合がどれだけ出たかを表す指標のまとまりのことです。*1 表3-1-4の対象も全年度で、近年6年間には絞られていません。*1 2016年度より前の案件も入り得ます。何件がいつの案件かは、この表の説明には書かれていません。

FPのデータそのものも減っています。FP実績値のあるデータが2014年度～2015年度の115件から、2020年度～2021年度は29件と1/4程度に大幅減少している、とされています。*1 一方でソースコードの行数のあるデータは、同じ2つの期間を比べてもほとんど差はないとも書かれています。*1 近年のFP計測案件だけなら、もっと小さい集まりです。

不具合を数える手順を3つ決める

ここからは、外部エンジニアと数え方をそろえる手順を3つ挙げます。資料が書いている前提を、自社の取り決めに置き直したものです。手順の組み立てはこの記事で行いました。

1つめは、何を1件と数えるかを決めることです。資料は発生不具合数としか書いておらず、内訳の分け方までは示していません。仕様の解釈違いを1件に含めるか、同じ原因から出た複数の現象を1件にまとめるか。ここがずれていると、件数はいくらでも動きます。

2つめは、いつから いつまで数えるかを決めることです。資料の起点はシステム稼動で、期間の基本は6か月間の累計です。*1 リリース日と稼動日が違うなら、どちらを起点にするかを先に決めます。資料の側にも6か月以外の案件が混じっているので、比べるときは自社の期間を書き添えて、ぴったり重なる値ではない前提で扱います。

3つめは、何で割って密度にするかを決めることです。この表はFPで割った値です。*1 同じ資料にはソースコードの行数で割った章も別にあり、単位が違えば値も別物です。割る単位を先に決めないと、密度どうしを比べられません。

つまずきやすい難所

この数字を外部エンジニアとの話に持ち込むとき、引っかかる点が3つあります。

1つめは、FPを測っていなければ比べる土台が無いことです。対象は計測手法が明確なプロジェクトに限られています。*1 何をもって明確とするかの基準は、この表の説明には出てきません。FPを数えていない現場では、資料の値を比べる相手にするのではなく、決めるべき項目の一覧として使うことになります。まず自社の数え方を決めて1件か2件を実測し、その値を社内の基準にします。これはこの記事の読み方です。

2つめは、平均と中央値の取り違えです。中央値は2.6件／KFPですが、平均は12.7件／KFPです。*1 委託先が自分たちの実績として平均を挙げてきたときは、中央値もあわせて聞くことになります。上側に高い値がまとまっていると、平均は真ん中から大きく離れるからです。

3つめは、この集計が外注の有無で分けていないことです。このデータ集は外部委託の工数比率、つまり開発の工数のうち外に委託した割合も第1章で集計していますが、*1 外注の有無で不具合密度を分けた表はありません。この資料が使えるのは、発注側と委託先が同じ物差しを持つところまでです。

テストをどこまで任せるかの区分は、別の記事「外部エンジニアのテスト体制、IPAが定める4つの区分」で扱いました。

外注時に確認しておきたい点

発注する側が、数え方と直し方を契約の前に決めておくと、あとで件数の話をしやすくなります。この3つはこの記事で挙げたもので、資料が契約条項を示しているわけではありません。

1つめは、数え方と期間を契約書か議事録に文書で残すことです。何を1件とするか、いつから いつまで数えるか。資料の基本にそろえるなら、起点は稼動、期間は6か月です。*1

2つめは、見つけた不具合を誰がいつ直すかを、提供範囲として確かめることです。提供範囲とは、契約で引き受けると決めた作業の範囲のことです。夜間や休日の復旧対応が含まれるかどうかは契約によって違います。含まれない前提なら、社内の当番を先に決めることになります。

3つめは、直した結果をどこに記録するかです。件数を数えるなら、起票（不具合を課題として登録すること）から修正までを1か所に残します。外部エンジニアが使う課題管理の場所を、契約の開始時に決めます。

まとめ：件数より先に数え方をそろえる

読み取れることは4つです。第一に、IPAのソフトウェア開発分析データ集2022では、新規開発378件の発生不具合密度の中央値が2.6件／KFPでした。第二に、平均は12.7件／KFPで中央値の5倍近くあります。最大値318.3件／KFPの1件を除いても平均はほとんど下がらないので、外れ値1件では説明がつきません。出発点に置くなら中央値です。第三に、IPAは発生不具合数として稼動後6か月間の累計値を基本的に用い、そのデータが無い場合は他の期間の累計値を使用するとしています。6か月以外が何件あるかは書かれていません。この表の対象も全年度で、近年6年間には絞られていません。第四に、FPを測っていない現場では比べる土台がないので、この資料は比べる相手ではなく、決めるべき項目の一覧として使います。なお、この集計は外注の有無で不具合密度を分けていません。

よくある質問

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：独立行政法人情報処理推進機構「ソフトウェア開発分析データ集2022」。はじめにの記述（2005年度からの公開、ソフトウェア開発ベンダー35社の協力、累計5,546件、主な統計値を近年6年間で算出する一方で信頼性や生産性など一部は全件を対象とすること、本書の主な対象が直近6年間すなわち2016年度～2021年度であること、FP実績値のあるデータが2014年度～2015年度の115件から2020年度～2021年度は29件へ減少しソースコードの行数のデータはほとんど差がないこと）、第3章のFP信頼性の定義（1FPあたりの発生不具合数、稼動後6か月間の累計値を基本とすること）、3.1.4「FP規模とFP発生不具合密度：新規開発(全年度)」の対象条件と表3-1-4のN・中央・最大値・平均およびFP規模で行が分かれていること、改良開発と再開発が別の表であること、1.3.2に外部委託の工数比率が第1章で集計されていること、第2章にソースコードの行数で割った章があることの一次情報として（2026年9月確認）
2. *2　参考：IPA「ソフトウェア開発分析データ集2022」公開ページ（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本データ集の発行事業が終了し今後の発行予定がないこと、および本編PDFと正誤表の所在の確認として（2026年9月確認）

Tweet