バグの相場観は？どれだけ出すの？(ソフトウェア分析)

ソフトウェア開発中にバグはどれだけ出るのでしょうか。出すのでしょうか。リリース後の運用中のバグはゼロであるべきですが、開発中に発見するバグはゼロでなくても構いません。開発中にデバッグすればいいのですから。逆に開発中に多くの、可能ならすべてのバグを発見するのが望ましく、この意味では多くのバグが出る方がいいかもしれません。でも開発中のバグが多いと、それは開発そのものが失敗している可能性が大です。これから開発中のバグは一定の範囲が適当で、その相場観が大事になります。ここではこの相場観を見ていくことにします。

開発中のバグはどれくらい？

ソフトウェア開発中にバグはどれくらい出るのでしょうか。どれくらいバグを出してしまうのでしょうか。

開発中のバグは悪いものか？

ソフトウェア開発が完了して、製品をリリースして、運用に入ったときに出るバグは悪いものです。もしかしたらインシデント、事案になるかもしれません。

しかし開発中のバグは悪いものとは限りません。いえ、「バグは正義」です。でも本当はバグが正義ということではなく、バグを発見することこそが正義です。
でもバグが出たこととそのバグを発見したことは同じなので、ここでは気にしないでください。
「バグを作ったのではなくバグを発見した」この方が気が楽です。

でもバグを発見するためにはバグを作らなければなりません・・とは言いません。とにかく、運用中にそのバグが出なかったことを喜びましょう。

（考察）バグは自然現象なのか？

ここで少し考察をしてみます。ソフトウェアを開発するとバグは出ます。まるで自然現象かのように、自然にバグは出ます。一定の開発コストを掛け、一定のスキルのメンバで開発していると、自然にバグが出ます。まるで「バグは自然現象」のようです。

もちろんバグは自然現象ではなく、人間が作り込む人工物です。そう「バグは人工物」なのです。でも一定の数が集まるとポアソン分布のように自然現象と同じように見えてしまいます。だからバグは自然現象なのです。

自然現象のように考えれば、雨が降っても誰もが責任を負わないように、バグが出ても誰の責任でもありません（断言）。
もちろんリリース後の運用中のバグに対する責任追及はされます（断言）。

なお、この考察は秘密です。誰にも言わないようにした方が身のためです。

バグはどれくらい発見すればいいのか？

ソフトウェア開発中のバグはどれくらい出ているのでしょうか。バグがどのくらい出るかと言うと以下のような感じに出ます。
出典：IPA ソフトウェア開発分析データ集2022
（ちなみに私がこのデータ集を担当していました。って宣伝？）

出典：IPA ソフトウェア開発分析データ集2022
https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf
p.57 表5-1-1 SLOC 規模あたりのテストケース数、検出バグ数(全開発種別)

ここで「現象」となっているのは、テストケースを実行させて、ただちに見つかったバグのことです。「原因」となっているのは、現象として現れたバグの原因を追究して、原因で区分したものです。

例えば、総合テスト（システムテスト、システム適格性確認 テスト(共通フレームワーク2013)）では、現象のバグ密度（ソースコード1000行当たりのバグ数）の中央値は 0.986 件/KSLOCです。
つまり、「1000行当たり約1個のバグ」が見つかるということになります。これは覚えやすい数値ですので、ぜひ、覚えてください。試験に出ます。

次に上記の四分位表から、25%地点(P25)から75%地点(P75)の範囲を見ると、0.429～2.311 件/KSLOCになります。
つまり「1000行当たり0.5から2.5個のバグ」の範囲に半分のプロジェクトが入ることになります。この範囲に入っていないときは注意しましょう。きっと何かの問題がありません。たぶん。

これくらいのバグをシステムテストで見つけることが相場です。つまりこれくらいがバグの相場観です。

この相場観の範囲に入っていれば、顧客や上司に堂々と主張できます。IPAの分析データ集の相場と同じくらいだと主張できます。
もし範囲外だった場合は、IPAの分析データ集の存在を言わないでおきましょう。それが身のためかもしれません。

ソフトウェア開発のデータ引用元：ソフトウェア開発分析データ集2022 | 社会・産業のデジタル変革 | IPA 独立行政法人 情報処理推進機構
# 私が担当していましたので、上記に関する質問やコメントなどもここで受け付けています。