サンプリングと、残存バグ数予測と、TV視聴率：山浦恒央の“くみこみ”な話（52）（1/2 ページ）

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第5回では、「サンプリング」による残存バグ数予測について解説する。サンプルとなるテスト項目をどのように選ぶかが“鍵”だ！

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

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

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

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

　今回は、サンプリングによる残存バグ数予測について解説します。これが【プログラム中の残存バグ数の推定】シリーズで紹介する最後の手法となります。

1．サンプリングによる予測の基本

　対象母体の全てをチェックできないので、母体の中から適当に幾つかを選んで、母体を予測する。これがサンプリングです。「大きいものは小さくせよ」は、ソフトウェア開発の基本ですね（注1）。

　サンプリングを用いた残像バグ数予測は、具体的に以下のステップで実施します。

（1）テスト項目を設計し、作成する
　ソースコード10ステップ当たり1件のテスト項目を作るのがおおよその目安

（2）テスト項目の中から、何件かをサンプリングする
　テスト項目の中から、数％をサンプリングする。“どのようにサンプリングするか”が鍵となる（詳しくは後述）

（3）サンプリングしたテスト項目を実行する
　テストには、机上テストとマシンテストがある。残存バグの予測では、マシンテストで実施することが多い

（4）サンプリングの割合と出たバグの数から、残存バグ数を推定する
　母数がa件あるテスト項目の中から、b件を選んで実行したところ、c件のバグが出た。この場合、残存バグ数「bug_numb」は、以下のように求められる。

式：

bug_numb ＝ c ＊ b／a

※注1：この他、「複雑なものは単純にする」「大きいものは分割する」「小さいものは拡大する」などがあります。ソフトウェア設計の大原則である「大きいものは分割する」は、イタリアの政治思想家ニッコロ・マキャヴェッリが『君主論』で説いた「分割して統治せよ」に通じるところがあり、興味深いですね。

2．残存バグ数予測とTV視聴率

　「サンプリングによる予測」と聞いて、TVの視聴率を最初に思い浮かべる人も多いのではないでしょうか。視聴率が1％違うだけで、視聴者数が数百万人も違ってきます。

　TVの視聴率は、番組の継続・中止や、スポンサー料金に大きく影響するので、キチンと算出しなければなりませんが、意外にも調査標本数が少なくて驚きます。例えば、関東地方の調査標本数は、600世帯前後とのことです。関東地方の全世帯数が1500万件あると考えると、その少なさがよく分かりますね。ただ、視聴率は非常に重要な数値ですし、その調査方法は統計理論の塊といえますので、思い切り“理論武装”していることでしょう。

　実際、600世帯（600／15000000 ＝ 0.004％）というごく少数のサンプリングで、これほど重大な数字を計算するというのは、ある意味「スゴいなぁ」と感動すら覚えます。1世帯がそのTV番組を見るか見ないかで、視聴率が0.2％も違ってきますので、かつて買収事件に発展したこともありました。

　このように、TV視聴率とサンプリングの話は、かなり奥が深く・面白いので、興味のある方は、例えば、こんなWebサイトをのぞいてみてはいかがでしょうか。きっと、品質制御のヒントがたくさん見つかることでしょう。