検索
連載

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

思わず身構えてしまう「統計」ですが、手をつけてしまえば何とかなるものです。今回はデータ解析手法の“王様”である「平均」について、解説します。

Share
Tweet
LINE
Hatena

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は足手まといになっている感があります。こんな状況は、平均値を見ただけでは分かりません。平均値だけで判断するのは危険です。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る