　ソフトウェア業界でのプロセス改善は、他の製造業に比べて歴史が非常に浅く、また、効果の出にくい傾向にあります。それでも、吉野家の牛丼の「うまい、やすい、やすい」を目指し、低コスト、高品質、短納期のソフトウェアを作るため、各会社であらゆる方法を試しています。例えば、開発支援ツール（テスト自動生成ツール、トレーサビリティツール）を導入し、人手による作業を極限まで減らす試みや、開発プロセス（CMMIやISO）をベースにしてプロセス改善を目指す組織までさまざまです。

　改善活動では、データを測定し、効果が本当に出ているか確かめねばなりません。効果の検証方法はさまざまですが、最も簡単で時間がかからないのは、改善前と改善後の2グループのデータを収集し、検証することでしょう。例えば、100のプロジェクトに対し、ツール導入前後の工数、コスト、バグ密度の算術平均を取って比較するなどです。

　全プロジェクトのデータを同じタイミングで収集できれば何の問題もありませんが、実際に全数調査はまず不可能です。従業員数が1000人を越える企業の場合、3人×1カ月の小さなプロジェクトから、70人で3年以上かかる巨大プロジェクトまで多数あり、新プロセスのデータを全て収集することは非現実的です。3年待って検証しても良いでしょうが（*1）、3年後に効果があると分かっても、野球の試合に負けた原因を翌日、評論家が分析するのと同じ結果になります。

　全数チェックではなくサンプリングする場合、「たまたま、生産性が上がった」のか、「プロセス改善の成果」なのかをきちんと判定する必要があります。TVの視聴率や選挙の当確判定は統計的な裏付けを取っています（詳しくは、山浦恒央の“くみこみ”な話 52：サンプリングと、残存バグ数予測と、TV視聴率）をご覧ください。プロセス改善の効果は、統計的な手法を使用して有効性を示す必要があります。

　今回は、2つのグループを比較する統計手法である「平均値の差の検定」の理論武装的な部分に焦点を当てて紹介します。

（*1）：大規模プロジェクトでもプロセス改善が有効かどうか考察するのは、決して無駄ではありません。データ検証は、大半が小規模プロジェクトの場合が多く、規模の大小は重要なファクターですが、管理者としてはなるべく早い段階で効果を検証したいのも事実です。