食わず嫌いを直そう、統計計算の王様「平均値」の落とし穴（その4）：山浦恒央の“くみこみ”な話（76）（2/4 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），MONOist]

2.平均値の落とし穴

　平均値は、簡単に計算でき、非常に強力で、「統計データ処理の王様」と言えますが、注意点がいくつかあります。

• 2.1　とんでもなくスーパーなエンジニアがいる場合

　例えば、表.1のデータで、E君が驚異的な生産性を発揮した場合を考えましょう。その場合、チームの平均的な生産性はどうなるでしょう。表.4に例を示します。

表.4　あるプロジェクトのプログラマ1カ月の生産性（LOC）-2
名前	生産性（LOC）
エンジニアA	770
エンジニアB	1030
エンジニアC	940
エンジニアD	410
エンジニアE	4100
平均	1450

　エンジニアA〜Dの生産性は、表.1も表.4も同じですが、E君の値だけが4100と驚異のデータを示しています。E君の頑張りにより、表.1と比較して平均値は828から1450へ急上昇しました。このように、データ内に他の数値と大きく懸け離れたものがあると、平均値はそれに引っ張られてしまいます。

　一般的なソフトウェア開発での1カ月のプログラマの生産性が1000ステップ前後と考えると、E君はある意味、異常です。E君のようなデータを、統計学で「外れ値」と呼び、場合によっては除外して考える必要があります。

• 2.2　見掛けの平均が同じでも……

　見掛け上の平均値が同じでも、データの傾向が大きく異なる場合があるので注意が必要です。例えば、表.5の「5人のプロジェクトでの生産性」を考えましょう。ただし、チームAの「エンジニアA」とチームBの「エンジニアA」は同じ人ではなく、単に5人の中の1人とお考えください。

表.5 2つのプロジェクトのエンジニアの生産性（LOC）
名前	チームAの生産性（LOC）	チームAの生産性（LOC）
エンジニアA	850	350
エンジニアB	1090	2030
エンジニアC	900	1500
エンジニアD	1050	440
エンジニアE	890	460
平均	956	956

　表.5は2つのプロジェクトのエンジニアの1カ月あたりの生産性を表したものです。2つのプロジェクトの平均値は同じですが、特徴は大きく異なります。

　プロジェクトAは、それぞれのエンジニアが900〜1000行付近の平均的な生産性を持っているのに対し、プロジェクトBは、エンジニアB、Cを除き生産性がぱっとしません。BとCが頑張ってプロジェクトの生産性を上げ、A、D、Eは足手まといになっている感があります。こんな状況は、平均値を見ただけでは分かりません。平均値だけで判断するのは危険です。