　コーディングが終わり、コンパイルエラーも消え、いざデバッグ工程に突入――。このとき、「プログラムの中に隠れているバグの総数を正確に推定できたらなぁ……」と考えたことはありませんか？こう考えるのは何もプログラマーだけではありません。プロジェクトマネジャーも、プロジェト管理や品質制御の観点から、バグ総数を高精度で予測することを夢見ています。

　本コラムの第48、49回で「キャプチャー・リキャプチャー・モデル（別名：ソフトウェア版「池の中の魚」モデル）」と、その改良版「2チーム制」モデルを取り上げました。そして、続く第50回では、品質エンジニアが大好きな「Gompertz曲線」を使った残存バグ数の推定法を解説しました。


	関連リンク：
⇒	バグの数は予測できるのか？発想は斬新だけど評判の悪い「池の中の魚」モデル
⇒	これなら残存バグ数を予測できる？健全で実践的な「2チーム制」モデル
⇒	残存バグ数を予測する、「Gompertz曲線」による推定法とは？

　今回は「バグ率からの予測」「統計データに基づくバグ数予測」について紹介します。たったの30秒で推定できる上に、意外と精度も低くありません。

1．バグ率と総バグ数の推定

　バグ率からの総バグ数の予測とは、「過去のプロジェクトでの『1KOLC（1000ステップ）当たりのバグ数』を計算し、今回のプロジェクトのソースコード行数に乗じる」という方式です。この方式は手軽な割に、推定精度はそれほど低くありません。

　総バグ数は、2つ以上の推測法で予測すべきですが、「バグ率による推定」は、「主」とはなり得ないまでも、「従」として、2番目の方法として十分に使えます。

　簡単に推測できるのですが、「エンジニアリングとは何か？」が関係してくるため、意外と奥の深い推測法でもあります。

2．自分のデータを知っていますか？

　例えば、野球の選手はプロ／アマを問わず、自分自身のデータを知っています。野手ならば、打率、出塁率、守備率、盗塁数、4つのベースを1周するのにかかる時間などを認識しています。また、投手であれば、勝ち負け数、防御率、奪三振数くらいはきちんと把握しているでしょう。

　これと同様にプログラマーも「自分自身の統計情報」を知っておくべきです……が、お察しの通り、現実にきちんと認識しているエンジニアはほとんどいないと思います。

　というわけで、ここでは最低限知っておくべき2つを紹介します。簡単に計算できますので、ぜひ把握しておきましょう。

生産性　
1つの開発プロジェクトで、費やした月数（機能定義からテスト終了まで）と、作成したソースコード行数から、生産性（1カ月当たりに新規開発したステップ数）を計算します。1KLOC（1000ステップ）／月前後が平均的な目安となります。
バグ率　
作成したソースコード行数と、机上デバッグ以降に摘出したバグ数から、1KLOC当たりのバグ数を計算します。プロの平均的な目安は、4～5個／KLOC、学生などのアマチュアのプログラミングでは、10個／KLOCを大きく越えると思われます。

　上記以外に、自分の「バグの作り込み癖」、例えば“境界・限界条件を誤認識する傾向にある”といったことを留意しておくとよいでしょう。また、生産性とバグ率が、経験したプロジェクトによって、あるいは年によって、どのように推移してきたかも把握しておくべきです。

　プログラマーを新規採用したり、別のプロジェクトに参加してもらったりするときに“面接（面談）”が行われます。筆者が面接担当者なら「これまでどんなプロジェクトに関わってきましたか？」という王道的な質問の他に、

あなたは自分でどんなソフトウェア開発エンジニアだと思いますか？具体的な数値を挙げて説明してください

と聞きます。

　この時、自分の生産性とバグ率をきちんと答えられる人は、数値の良しあし以前に、エンジニアとして自分の能力を客観的に認識できている人だと理解され、高評価が得られます。