An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

偉大なるバグ狩り：なぜバグを数えるだけでは不十分なのか

あなたは、何千人ものゲストに巨大な晩餐会を提供しようとしているシェフだと想像してください。ドアを開ける前に、あなたのチームにはテイスター（ベータテスター）がいます。彼らは料理を食べては、「ねえ、このスープは塩辛すぎるよ！」とか「このケーキの中に石が入ってる！」と叫んでいます。あなたは彼らが見つけた問題を修正します。しかし、ここで恐ろしい疑問が浮かびます。もし今、ドアを開けたとしたら、通りかかるランダムなゲストが、あなたが完全に見逃した「石」を噛んでしまう確率はどのくらいでしょうか？

これは、コンピュータサイエンスにおける「ソフトウェア信頼性」と呼ばれる問題の核心です。何十年もの間、開発者は「数えること」によってこの問いに答えようとしてきました。彼らは「キッチンにはあと何個の石が残っているか？」と尋行います。彼らは複雑な数学を用いて、隠れたバグの総数を推測しようとします。しかし、落とし穴があります。たとえ「石が10個残っている」と分かったとしても、それが「パントリーの奥の方にある（一人しか見つけられない場所）」のか、それとも「正面のドアの真上に巨大な岩が置かれている（誰もが躓く場所）」のかまでは教えてくれないのです。従来の方法は、石の数を数えることに固執するあまり、その石が「どこにあるか」によって危険度が全く異なるという事実を無視して行き詰まってしまうことがよくあります。

これを解決するために、私たちは「石を数える」のをやめ、「人を数える」必要があります。私たちは、ランダムなユーザーが実際に問題に遭遇する確率を知る必要があるのです。この論文はその問いに正面から取り組んでいます。つまり、「あと何個のバグが残っているか？」と問うのではなく、「ユーザーがこれまでに見たことのないバグに遭遇する確率はどのくらいか？」と問うているのです。驚くほどシンプルな方法があります。それは、テスターが「同じバグを複数回発見した頻度」に着目するというトリックです。

---

論文の核心： 「ワンタイム・ワンダー（一度きりの驚き）」の法則

著者であるカルロス・M・エルナンデス＝スアレスとカーラ・エルナンデス＝クエバスは、巧妙なショートカットを提案しています。彼らは、隠れたバグに遭遇するリスクを予測するためには、バグの総数を知る必要も、ソフトウェアの構造を知る必要も、さらには何人のユーザーが使用しているかを知る必要もないと示唆しています。ただ、バグ報告を見て、ある特定のものを数えるだけでよいのだと言います。それは、**「ちょうど一度だけ報告されたバグ」**です。

例え話を使ってみましょう。あなたが、町にどれだけの種類のエイリアンが訪問しているかを突き止めようとしている探偵だと想像してください。あなたには目撃記録があります。

• もし「ゾグ」が50回記録されていれば、ゾグはありふれたエイリアンだと分かります。
• もし「キル」が3回記録されていれば、キルは少し珍しい存在です。
• しかし、もし「ブラープ」がたった一度だけ記録され、二度と現れなかったとしたら、それは何を意味するでしょうか？

論文は、この「ブラープ（一度きりの目撃）」こそが鍵であると主張しています。彼らは、これらの単発の目撃回数（$s$）を総目撃回数（$n$）で割った値を「保守的な上限（conservative upper bound）」と呼んでいます。平易な言葉で言えば、「一度だけ報告されたバグの割合」は、ユーザーが未知のバグに遭遇してしまう割合に対する、安全な「ワーストケース」の予測値であるということです。

なぜこれが機能するのか（「閉ざされたドア」の論理）

あなたはこう疑問に思うかもしれません。「もしバグの背後に別のバグが隠れていたらどうなるのか？ 例えば、鍵のかかったドアの裏に秘密の部屋があるような場合だ」と。著者らは、この点について見事な論理を展開しています。

ソフトウェアを、多くの部屋がある巨大な屋敷だと想像してください。いくつかのバグは廊下にあります（見つけやすい）。いくつかのバグは、鍵のかかったドアの向こうにある秘密の部屋にあります（見つけにくい）。

• ユーザーが鍵のかかったドア（バグ）に当たると、その背後にある秘密の部屋に入ることはできません。
• したがって、秘密の部屋に到達できる人数は、常に「鍵のかかったドアに当たった人数」以下になります。

著者らは、この「入れ子構造」があるため、隠れた部屋を心配する必要はないことを示しています。あなたが見つけた「一度だけ報告された」バグが、すでに隠れたもののリスクを説明しているのです。もしあるバグが一度だけ報告されたなら、それはその背後にあるすべてのリスクを制限する「ドア」として機能します。したがって、単発の報告を数えるだけで、家全体をカバーするのに十分なのです。

彼らが何を行い、何を見出したか

著者らは単に推測しただけではありません。彼らは「カノニカル・フォーム（標準形）」（色とりどりのボールが入った特別な瓶や壺のようなものと考えてください）と呼ばれる数学的モデルを構築しました。彼らは、バグ報告をこの瓶からボールを取り出す行為として扱えば、$s/n$（一度だけ現れるボールの割合）が「欠落している質量（unseen bugs）」の**最大尤度推定値（maximum-likelihood estimate）**になることを数学的に証明しました。

決定的なのは、この推定値が**保守的（conservative）**であると示したことです。これは、リスクを過小評価するのではなく、過大評価する傾向があることを意味します。

• なぜこれが良いのか： ソフトウェアをリリースするかどうか判断する開発者にとって、安全であることが重要です。もし数学が「バグの確率は5%です」と言い、実際の確率が3%であれば、あなたは安全です。しかし、もし数学が3%と言い、実際が5%であったなら、あなたは窮地に陥ります。この手法は、常に用心深く、慎重な側に立つことを保証します。

彼らは、コンピュータ・シミュレーション（既知の正解を持つ偽のバグ集団を作成すること）を用いて、このアイデアをテストしました。

• 20個のバグを用いたテストでは、ユーザー数（サンプルサイズ）を増やしていく（25から400へ）につれて、彼らの推定値（$s/n$）は常に、真の未発見バグの数よりも高いか、あるいは等しい値を示しました。
• 例えば、100人のテストユーザーを用いた場合、真の未発見リスクは0.0059でしたが、彼らの推定値は0.0063でした。推定値はわずかに高かった（保守的であった）ものの、決して低くなることはありませんでした。

これは「何ではない」のか（ゲームのルール）

論文は、この手法ができないことについても非常に明確に述べており、ここを正しく理解することが重要です。

1. これはバグを数えるためのものではありません。 「あと50個のバグが残っている」とは教えてくれません。「ユーザーがバグに遭遇する確率は2%である」ということを教えるのです。
2. これは公開されているバグリストのためのものではありません。 著者らは、インターネット上の標準的なバグデータベースに対してこの手法を用いることを明確に否定しています。なぜなら、そのようなリストでは、たとえ1,000人がそのバグを見つけたとしても、通常は一人の人間によって一度だけ報告されたものとして扱われるからです。それでは「カウント」が失われてしまいます。この手法を使うには、「このバグは50人の異なるユーザーによってヒットした」というデータが必要です。
3. これは未来を予言する魔法の水晶玉ではありません。 これは「今、この瞬間」のリスクのスナップショットを与えるものです。バグを修正して再度テストする場合、計算し直す必要があります。

結論

この論文は、リリース判断に対して、直接的で実直な答えを提示しています。それは、「暗闇に隠れているバグの数を心配する必要はない。テスターがちょうど一度だけ見つけたバグの数を見なさい。その数を総テスト数で割ったものが、ユーザーがあなたが見逃したバグに捕まる確率についての、安全な上限値となる」ということです。

これは、複雑で恐ろしい不確実性を、シンプルで安全な数値へと変えるツールです。ソフトウェアが出荷される際、開発者がユーザーに対するリスクを、明確かつ保守的な視点で把握できるようにするためのものです。