統計の話をしようじゃないか - ソフトウェア品質のための統計入門（No.2 データとの正しい向き合い方）

「統計の話をしようじゃないか」第2回は、統計を扱う前提となる「データそのもの」との向き合い方についてお話しします。
どれだけ立派な分析手法を使っても、元となるデータが適切でなければ意味がありません。
ここでは、以下の3つの観点から、データの基本を押さえていきましょう：

• データの種類（定性・定量＋尺度）
• 測定値と誤差の関係
• 良いデータを集めるための条件

統計におけるデータは、大きく分けて「定性データ」と「定量データ」の2種類に分類されます：

意味や属性を持つデータで、数値ではなくラベルやカテゴリで表されるものです。

• 例：バグの種類（UI, ロジック, 性能）
• 例：レビュー判定（OK / NG / 要再確認）
• 例：テスト結果（合格 / 不合格）

特徴：

• 数値計算はできない（平均などは出せない）
• 比率や出現頻度の比較には使える

さらに質的データは次の2つに分類されます：

• 名義データ：順序に意味のないラベル（例：バグの種類）

• 順序データ：順序に意味があるデータ（例：レビュー評価S > A > B > C）

数量として測定されたデータで、数値そのものに意味があります。

• 例：不具合件数、テスト実行時間、コード量（KLOC）
• 例：修正にかかった日数、バグ密度

特徴：

• 記述統計（平均・分散など）や推測統計の対象になる
• 折れ線グラフや散布図などで可視化しやすい

さらに量的データも次の2つに分かれます：

• 離散データ：飛び飛びの数値（例：バグ件数）

• 連続データ：連続する範囲の値（例：メモリ使用量）

またデータには、意味合いや扱い方が異なるものがあります。
統計手法や可視化方法を正しく選ぶためには、「尺度（スケール）」の理解が不可欠です。

• 単なるラベル（例：バグの種類、エラーコードの分類）
• 計算できるのは出現回数や最頻値

• 順序に意味がある（例：レビュー評価、満足度アンケート：満足 > 普通 > 不満）
• 中央値や順位比較は可能だが、平均計算は不適切な場合も

• 等間隔に意味があるが、絶対的な0がない（例：日付、温度℃）
• 足し算・引き算・標準偏差などは可能

• 絶対的な0があり、すべての演算が可能（例：実行時間、欠陥件数）
• 統計分析や可視化で最も多く使われる尺度

これら４つの尺度の違いを表で示します。

たとえば、不具合密度（件/KLOC）は比率尺度であり、平均・分散・トレンド分析が可能です。
下図は、リリースごとの不具合密度の推移を表しており、0.8件/KLOCを下回ることで目標が達成されつつあることが読み取れます。

尺度の違いは、適用できる統計手法・グラフの種類・解釈の仕方を左右します。

どんなに注意深く測定しても 必ず誤差が生じます（ばらつきを含む）。
これを理解していないと、データを盲信して誤った判断をしてしまう危険があります。

ソフトウェアの品質データ（レビュー時間やバグ発生率など）の測定値には再現性の限界があります。
単一の測定結果だけで判断せず、「測定にはばらつきがある」という前提を持つことが重要です。
次の図は、同じテスト項目を10回測定した場合のばらつきの実例です。

• 例：テスト実行時間を測ったら、毎回1〜2秒ほどばらつく

このように、同じ対象を測っても毎回完全に同じにはならないのが現実です。

品質データを扱う現場では、「ばらつき」と「偏り」を混同してしまうと、誤った改善判断につながります。
測定誤差にも異なるタイプがあることを理解し、使い分けることが求められます。
以下の図は、「系統誤差」と「偶然誤差」の典型的な違いを表しています。

1. 系統誤差：常に同じ方向に偏る誤差（例：測定器が0.5秒速く表示する）
2. 偶然誤差：測定のたびにランダムに生じる誤差（例：環境のノイズや測定者の違い）

品質改善の判断を「1回の測定結果」に頼るのは非常に危険です。
測定結果はばらつきを含むため、変化が統計的に有意かどうかを判断するには、統計的な見方が不可欠です。
次の図は、変更前後の測定結果のばらつきを比較したものです。中央値の違いが有意かどうか、あなたはどう読み取るでしょうか？

• 1回の測定だけで判断するのは危険
• 誤差を統計的に扱うことで、「本当に変化したか？」を判断できる

データはあくまで「不確かさを含んだ観測値」である、という姿勢が重要です。

統計は 「良いデータ」 があってこそ意味を持ちます。では、良いデータとはどんなものでしょうか？

1. 正確性：記録ミスや単位ミスがないか？
2. 一貫性：測定方法や記録ルールが統一されているか？
3. 網羅性：必要な範囲のデータが抜けなく取られているか？
4. タイムリーさ：必要な時点のデータが取得されているか？
5. 客観性：主観や感覚によるバイアスが混入していないか？
6. 目的適合性：このデータは、分析・判断したい目的に合っているか？

例：「不具合の原因分析」が目的なら、発生フェーズや影響範囲などが含まれているか？

• 不具合件数のカウントで現象数と原因数を区別せずに集計している（定義の不明確さ）
  → バグの定義と分類ルールを文書化し、集計ルールを明確にする
• 担当者によって「バグ」と記録する基準が異なる（主観の混入）
  → 記録ルールを定めて、定義の標準化とレビューを実施する
• テスト時間の記録が手書き＆後日入力（信頼性の欠如）
  → 自動収集や即時入力の仕組みを導入し、信頼性を担保する

「とりあえず取っておけばいい」では、いざ分析の段階になって使いものにならないケースが多々あります。

• 誰が、何を、どう記録するか を明確に
• データ定義書や記録ルール表 を整備することが重要

実際の現場では「記録フォーマットが曖昧」「担当者ごとに記録粒度が違う」などで、集めた後に集計できないケースが少なくありません。
だからこそ、記録設計と関係者への周知が収集より先に必要なのです。

• データには「定性」と「定量」があり、使える統計手法が異なる
• 測定値は常に誤差を含むため、複数回の観測や誤差の考慮が必要
• 良いデータを集めるには、記録ルールや定義の明確化が不可欠

次回は、いよいよ「記述統計」の世界へと進み、平均・中央値・最頻値の使い分けについて学んでいきましょう。

こちらに統計関連情報をまとめています。

データ分析に活用して頂ければ幸いです。