　残存バグ数を回帰分析で求める方法を使えば、上司や顧客から「なぜ、このプログラムに残っているバグの数が217個と推定できたのか？」と問われた場合、「これまでのプロジェクトでのバグ発生個数を回帰分析して推定しました」と答えれば、「統計は、複雑怪奇な式だらけ」と敬遠している連中は、それ以上、踏み込んできません。一種の「工学的な魔除け」として、正しく悪用してください。

回帰分析は「工学的な魔除け」としても使えます（写真は魔除けではありません）

「山浦恒央の“くみこみ”な話」バックナンバー

2.いつ、テストを終える？

　ソフトウェア開発工数の半分は、テストとデバッグ工程といわれています。特に、組み込み系のソフトウェア開発では、プログラムのバグが使用者の身体や財産に直接的な損害を与えることがあるため、使用に耐える品質に仕上がるまでコテコテにテストします。

　そこで、ソフトウェア品質制御の永遠の課題の1つとして浮上するのが「どこまでテストをするか」、すなわち、テスト終了の判定基準となります。あらゆるケースの組み合わせを完全に網羅することは理論的に可能ですが、現実には不可能です（数千ステップのプログラムでも、100万年以上かかります）。テスト終了判定の別アプローチが、「終了条件をあらかじめ設定し、そこに達すれば品質は担保できた」と考える方式です。

　テスト終了判定の方法の1つが「残存バグ推定法」で、詳しくは山浦恒央の“くみこみ”な話（48）～（52）をご参照ください。残存バグ予測法は、テスト対象のプログラムに存在するバグを推定する手法です。

　例えば、これまで同じプロジェクトが同じようなソフトウェアを開発してきたとします。過去の統計データから1000ステップ当たり10件バグがあると仮定すると、今回の開発分が1万行ならば、100件のバグが存在することになります。よって、「100件バグが見つかるまでテストする」というアプローチでテストを実施する方法が考えられます（同じ人員構成で類似ソフトウェアを開発する場合、この方法は意外に高精度です）。

山浦恒央の“くみこみ”な話（48）～（52）

・サンプリングと、残存バグ数予測と、TV視聴率

・己を知れば、たったの30秒でバグ数が予測できる

・残存バグ数を予測する、「Gompertz曲線」による推定法とは？

・これなら残存バグ数を予測できる？健全で実践的な「2チーム制」モデル

・バグの数は予測できるのか？発想は斬新だけど評判の悪い「池の中の魚」モデル

　具体的な残存バグ予測法（アルゴリズム）は組織によって異なりますが、代表的な手法が「回帰分析」で推定した値です。この手法は「統計分析の王様」で、バグ数予測に限らず、見積もり式など多方面で活躍しています。今回は、回帰分析で理論武装をした「残存バグ数推定法」を紹介します。

回帰分析とは

統計の食わず嫌いを直そう（その10）、ワインを飲まずに品質を予測する方法
統計アレルギーの解消には、身近な分野で考えてみることも大切です。今回は「ワインを飲まずに、ワインの品質を予測する方法」を例に統計に触れてみましょう。
統計の食わず嫌いを直そう（その9）、昼休みにタダで統計分析をする方法
「統計分析」と聞くと面倒な感じですが、何を証明するか明確ならExcelで簡単にこなせます。Excelさえあれば追加費用はかからず、しかもランチタイムに終わるほどカンタンなのです。
統計の食わず嫌いを直そう（その8）、統計的に「王様の耳はロバの耳」と言うために
「王様の耳はロバの耳」と統計的に判定するには、どうすればいいのでしょうか？ロバの耳かも？という仮説を“検定”するための基本的な考え方を学びます。
統計の食わず嫌いを直そう（その7）、「鎌倉時代の平均ワイン消費量」と「平均値の検定」
「効果がある」と言うためには比較が必要です。新旧開発プロセスの生産性や品質の平均値を比べるためには、「平均値の差の検定」が必要となります。
食わず嫌いを直そう、朝顔の観察日記とデータ収集（その6）
難しそうな「統計」ですが、データの分析以上に重要なのが「収集」です。今回は、統計分析の前段階に相当する「データを集める」という部分に焦点を当てて解説します。