バグの数は予測できるのか？ 発想は斬新だけど評判の悪い「池の中の魚」モデル：山浦恒央の“くみこみ”な話（48）

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

　というわけで、新シリーズでは、この「ソフトウェア中の残存バグ数の推定」をテーマに取り上げ、今回から数回にかけて解説していきます。

　第1回となる今回は、「キャプチャー・リキャプチャー・モデル」、別名、ソフトウェア版「『池の中の魚』モデル（Fish-in-the-Pond Model）」を取り上げます。この技法は、エンジニアの基本姿勢から逸脱した一種の“トンデモ推定法”ですが、発想は非常にユニークで、なるほどと思わせる一面もあります。

1．残存バグ総数の推定による御利益

　まず、本題に入る前に、プログラムの中に何件のバグが潜んでいるか（残存バグ数）を高精度で推定できると、どんな「御利益」があるのか整理しておきましょう。

（1）品質を定量的に計測できる　
残存バグ数は、現在の「プログラム品質」を具体的な数字で表すのに、最も分かりやすく、的確な数値といえます。

（2）品質の改善度合いや推移が定量的に計測できる　
バグを摘出して修正するごとに、品質は上がります。エンジニアたるもの、どれだけ品質が上がったかと聞かれ、「まあまあ動くかな？」「かなり動くようになった」「ほぼ完璧ですよ」「バッチリ動きます」のように、米国のプロジェクトでよくある“どんぶりメトリクス”で回答してはなりません。きちんとした数値で表現すべきです。残存バグ数を高い精度で予測できると、品質の改善度合いを具体的な数値で表示できます。

（3）デバッグ工程で、プログラマーにバグ摘出の具体的な数値目標を与えられる　
きちんとした開発プロジェクトでは、コーディング工程が完了し、デバッグ工程に入る際、ただ漠然とバグを見つけ出すのではなく、プロジェクトマネジャーが各プログラマーに対し、「何件のバグを見つけなさい」と具体的な数値目標を提示します。そして、実際に摘出したバグ件数と目標数との比率で、デバッグ工程の進捗を表現します。例えば、あるプログラマーが開発したソフトウェアの残存バグ総数を60件と推測した場合、そのうち15件摘出していれば、デバッグ工程の進捗率は25％となります。こうすることで、目標スケジュールに対し、「3日遅れ」のような具体的な進捗制御が可能になります。この目的で使用する場合、プログラマーの尻をたたく意味で、「実際よりも少し多めに推定できる方式」が望ましいといえます。

（4）マーケットへの出荷時期を予測できる　
プロジェクトマネジャーの最重要作業の1つが、現在開発中のプログラムがいつ市場に出荷できるかを正確に予想することです。「出荷基準」にはいろいろなものがありますが、「残存バグ数がゼロになった」というのも非常に重要な基準です。

　以上のように、残存バグ数を高精度で予測できると、メリットが多いため、ソフトウェア工学の研究者は、いろいろな方法で残存バグ数を予測しようとしています。

2．「池の中の魚」モデル

　残存バグ数の予測方法のベースとなる技法で、最も有名かつ最も評判の悪いものが、池の中の魚モデルです。

　この技法は、動物学で用いる「母体数推定モデル」を応用したものです。池の中に魚が何匹いるかの母体数を推定する方法として、動物学者は「魚を捕獲し、目印を付けてリリースし、再捕獲する」方式を採ります。その具体的なステップを以下に示します（図1）。

図1　池の中の魚モデル

1. 魚を大量に捕まえて、目印を付ける　
   例えば、池に投網を打って、魚を大量に捕獲し、その魚の尻尾に赤いペンキで色を付けます
2. 捕獲した魚をリリースする　
   捕獲して尻尾を赤く塗った魚を池に返します
3. 数週間たって、再び魚を大量に捕獲する　
   尻尾の赤い魚が池にいる他の魚と十分に混じったころを見計らって、再び、池に投網を打って、魚を大量に捕獲します
4. 2回目に捕獲した魚の中に、尻尾の赤い魚が何匹含まれているかで母体数を推定する　
   2回目に捕獲した魚の中に、尻尾の赤い魚が何匹いるかをカウントし、母体数を推定します。例えば、1回目に80匹捕まえ、尻尾を赤く塗ってリリースし、2回目の捕獲で120匹捕獲したと仮定します。120匹の中に、尻尾の赤い魚が12匹いると（12／120＝10％）、「最初に捕獲した『80匹の尻尾の赤い魚』は、全体の10％」であると推測し、魚全体の母数は800匹と予測するのです

3．ソフトウェア版「池の中の魚」モデル

　ソフトウェア版の池の中の魚モデルが、キャプチャー・リキャプチャー・モデルです。「尻尾の赤い魚」をバグに見立て、ソースコードの中に何個のバグが存在するかを予測する方法です。以下のステップで、残存バグ数の推定を行います。

1. デバッグ工程に入る前に、各プログラマーのソースコードを集める　
   プロジェクトマネジャーは、プログラマー全員の全ソースコードを集めます。これが最初のステップで、「池の中の魚」モデルでいうところの「1回目の魚の捕獲」に相当します
2. ソースコードに人工バグを埋め込む　
   プロジェクトマネジャーは、各プログラマーに分からないよう、集めたソースコードに、無理やりバグを埋め込みます。この「人工バグ」が先の「尻尾の赤い魚」に相当します
3. バグ入りソースコードをデバッグする　
   プロジェクトマネジャーは、人工バグ入りのソースコードを各プログラマーに返し、「では、デバッグを開始してください」と指示します。バグを検出したら、プログラマーはバグレポートを書き、バグを修正します。このバグの中には、もともとプログラムに存在していたバグと、人工バグが混在しています
4. 人工バグの比率から、残存バグ総数を予測する　
   プロジェクトマネジャーはバグレポートを分析し、もともとプログラムに存在していたバグと、人工バグ（尻尾の赤い魚）に分類します。これにより、残存バグの総数を予測します。例えば、プロジェクトマネジャーが人工バグを12件埋め込み、プログラマーがデバッグで24件のバグを摘出し、うち8件が人工バグだった場合、人工バグは全体の33％となり、元のプログラムには36件のバグがあったことになります

4．ソフトウェア版「池の中の魚」モデルの評判が悪い理由

　ソフトウェア版の池の中の魚モデルは、考え方としては非常に面白く、「へぇ〜、なるほど。そんな方法があったのか！」と感心する人も少なくないと思います。しかし、発想が斬新だからといって、絶対的な効果があるとは限りません。実際、ソフトウェア版の池の中の魚モデルは、非常に評判が悪く、露骨に嫌悪感を表すソフトウェア開発者も少なくありません。なぜ、そんなにたたかれるのでしょうか。その理由を以下に示します。

（1）人工的なバグを埋め込む行為は、「品質向上」の基本姿勢に反する　
品質の高いプログラムを作りたいと思っているのに、プロジェクトマネジャーが無理やり人工バグを埋め込むという行為は、言語道断、神をも恐れぬ犯罪に思えてしまいます。エンジニアの良識に反し、心理的な抵抗感があります

（2）人工バグは、すぐに嗅ぎ分けられる　
棚の本を並べる順番や机の上の物の置き方には個性があり、誰かが少しでもいじるとすぐに分かります。同様に、プログラマーには、「設計癖」や「コーディング癖」があり、他人が触ると0.5秒で「これはオレのコーディングスタイルじゃない！」と嗅ぎ分けられてしまいます（英語で“smell-out”と呼びます）

（3）人工バグの修正時に、誤って正常部分も変更してしまう危険性がある　
人工バグも、もともと存在するバグと同様に、修正しなくてはなりません。この時に、間違って正常な部分も変更してしまう危険性があります。この確率は20％前後もあり、決して小さくありません。このバグは、人工バグがなければ、発生しなかったバグであり、まさに「余計なバグ」といえます。何とももったいない限りです

（4）最大の問題は「残存バグの推定値が、実際のバグ数よりもかなり小さい」　
無理やり人工バグを埋め込んでバグ総数を求めても、この推定値の精度が高くありません。実際の値よりもかなり低く、研究によるとその推定値は、実際の値の40％前後になるそうです。これだけ低いと、「摘出目標値」としてプログラマーに示して、尻をたたくことには使えません。やはり、（2）の嗅ぎ分けにより、人工バグを簡単に検出できてしまうことが効いているのでしょう

　以上の理由により、ソフトウェア版「池の中の魚」モデルは、アイデア自体は面白く、斬新ではありますが、すこぶる評判が悪く、「実際のプロジェクトで適用した！」という話は聞いたことがありません。

　というわけで、次回、これの改訂版である「2チーム制モデル」を取り上げます。ベースは「池の中の魚」モデルですが、人工バグを埋め込んだりはしません。こちらは、かなり現実的な方式なので、実際のプロジェクトで適用している企業もあります。（次回に続く）