統計の食わず嫌いを直そう（その11）、5分で残存バグ数を予測する方法：山浦恒央の“くみこみ”な話（83）（1/4 ページ）

「回帰分析」は統計分析の有力な手法であり、Excelさえあれば5分で統計的に根拠のある数字を出せます。今回はExcelのツールを使って簡単に残存バグ数を予測する方法を解説します。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

1.はじめに

　前回は「ワインを飲まずに、ワインの品質を予測する方法」と題して、ざっくりと相関分析の話をしました（統計の食わず嫌いを直そう（その10）、ワインを飲まずに品質を予測する方法）。

　「統計の食わず嫌いを直そう」の最終回となる今回は、「統計分析の双璧」のもう一方である回帰分析を用い、Excelの統計ツールで簡単に残存バグ数を予測する方法を解説します。この方法を使えば、5分程度で統計的に根拠のある数字を出せます。

　ソフトウェア開発のテストでは、いろいろな終了条件があります。その1つが「予測した残存バグ数のバグを摘出した」です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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