己を知れば、たったの30秒でバグ数が予測できる：山浦恒央の“くみこみ”な話（51）（1/2 ページ）

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第4回では、たったの30秒で推定できる割に、意外と精度も低くない「バグ率による総バグ数予測」を取り上げる。

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），MONOist]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と聞きます。

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

　業務としてのプログラミング経験がない学生も同様です。授業のプログラミング演習などでコーディングをしたり、趣味のプログラミングでソースコードを書いたりしたはずです。その際、プログラムが意図通りに動作するよう、きちんとデバッグ・テストし、バグを修正したことでしょう。

　生産性やバグ率を意識することは、「プログラム開発が工学である」こと、すなわち、投下したコスト、時間、人月に対する生産効率や品質を意識することであり、アマチュアや趣味の範囲を越えた「レベルの高いエンジニア」であることの証拠となります。

　真のプロジェクトマネジャーであれば、個人ではなく、過去のプロジェクト全体のデータ、例えば、開発したソースコード行数、開発期間、コスト、総人月、バグ総数などをきちんと認識していますし、それを簡単に計算できます。そして、算出したデータを使って、今回、開発するソフトウェアの総バグ数を推測します。