統計の話をしようじゃないか - ソフトウェア品質のための統計入門（No.6 実務に効くグラフの正しい使い分け）

「統計の話をしようじゃないか」第6回では、実務におけるグラフの使い分けをテーマに扱います。

データを相手に“伝える”場面では、グラフの使い方が極めて重要です。
どんなに分析が正しくても、グラフの選び方や描き方を誤ると、誤解や不信感を招くことにもなりかねません。

今回は、実務で頻出する以下の6つの基本グラフについて、使い分けのポイントを整理します。

• 棒グラフ（Bar Chart）：カテゴリごとの数量比較に最適
• 折れ線グラフ（Line Chart）：時系列の変化やトレンドの把握に有効
• 散布図（Scatter Plot）：2つの数値間の関係性を可視化
• ヒストグラム（Histogram）：連続データの分布形状を把握
• 箱ひげ図（Box Plot）：ばらつき・偏り・外れ値の視覚化に最適
• パレート図（Pareto Chart）：重点対策の判断や優先順位付けに活用

さらに、「やってはいけないグラフ」の例も交えて、説得力のある資料づくりの視点も共有します。

棒グラフ（Bar Chart）は、カテゴリごとの「数の違い」を視覚的に把握できる最も基本的なグラフです。
データの傾向やバランスをつかむのに優れており、品質分析の最初の一歩としても非常に有効です。

以下は開発チーム別のレビュー指摘件数の例です。

• バグ種別ごとの件数（例：ロジック系 vs UI系）
• 月ごとのレビュー数（時系列分析の第一歩として）
• 開発チーム別の生産性（例：ストーリーポイントごとの完了件数）

カテゴリごとの「量の比較」が目的であれば、棒グラフが最適です。
また、データの傾向（例：Aチームだけ異様に多い）などもひと目で把握できます。

• 縦軸が数量、横軸がカテゴリ（数値 vs 分類）
• 棒の長さや高さが意味を持つ
• 項目数が多くても比較しやすい
• 順序性のないカテゴリデータ（名義尺度）に向いている

※横向きの棒（横棒グラフ）を使えば、ラベルの読みやすさが向上します。

• 月や工程フェーズなど順序性のあるデータには折れ線グラフの方が適しています。
  棒グラフにしてしまうと「時系列の流れ」が分かりにくくなります。
• 棒の色に意味がある場合（例：重大度の違いなど）、凡例がないと誤解を招くため注意が必要です。
• グラフの順番（並び） も意識すべきです。アルファベット順や適当な順番にすると、傾向が読み取りにくくなります。

折れ線グラフ（Line Chart）は、時間の経過にともなう変化やトレンドを表現するのに非常に適したグラフです。
ソフトウェア開発では、進捗状況や品質の推移を可視化するために頻繁に用いられます。

以下は週単位のレビュー完了率の推移の例です。

• 日次や週次のバグ発生件数の推移（異常の早期発見に）
• 月次のレビュー完了率（改善効果の確認に）
• 工程別のテスト通過率（各フェーズの安定性評価に）

「流れ」や「増減傾向」を把握することが目的なら、折れ線グラフが最も効果的です。
特に、改善活動の効果測定や異常検知において有用です。

• X軸は時間軸が基本（日、週、月など）
• 複数の系列（チーム別・カテゴリ別など）を線の色や形で分けて同時表示できる
• トレンド線や目標線を重ねることで、目標との差分や傾向を直感的に把握できる
• データ点が多い場合でも、折れ線でつなぐことで滑らかな変化として把握できる

• 順序性のないデータ（カテゴリ型）を無理に折れ線で表現すると、誤解されやすい（例：レビュー担当者別のバグ数など）
• データ点が少ない場合（例：3点だけ）には、直線が逆に強調されすぎて「トレンド」として誤認される可能性がある
• 急激な変化があると視覚的に強い印象を与えてしまい、冷静な判断を妨げることもある

折れ線グラフは「時系列を扱うグラフの基本」です。
ただし、使いどころを間違えると、誤解や過信のもとになるため注意が必要です。

散布図（Scatter Plot）は、2つの数値データ間の関係性（相関）を視覚化するために用いられます。
ソフトウェア品質管理においても、さまざまな変数間のつながりを把握するのに効果的です。

以下はレビュー所要時間と指摘数の関係の例です。

• テストケース数とバグ件数の関係：テスト設計の有効性を評価
• レビュー所要時間と指摘数の関係：レビューの質や効率性の確認
• 修正工数と影響範囲の関係：大きな変更ほど手間がかかるか？を検証

「相関があるのか」「どの程度の傾向があるか」をひと目で把握したい場合に最適です。

• X軸・Y軸に連続的な数値データを取る（例：所要時間、件数、行数など）
• 相関の有無だけでなく、外れ値（明らかに他と異なる点） の検出にも有効
• 傾向線（回帰直線(※1)）を追加することで、関係性の方向性（正・負）や強さが明確になる
• 散布の形状（縦長・横長・分布の幅）から、関係の性質を視覚的に理解できる

• カテゴリデータ（例：担当者名やモジュール名）を散布図にしても意味をなさない
  → この場合は棒グラフや箱ひげ図を選ぶ方が適切です。
• 点が密集して重なりすぎると、分布の実態が見えづらくなる
  → 透明度（alpha）や点サイズの調整、Jitter（微小なズラし） で視認性を改善できます。
• 点が時系列を含んでいる場合は、色やマーカーの変化で時間を表現する工夫も有効です。

散布図は「関係性を探るための第一歩」です。
ただし、相関があるからといって因果関係があるとは限らない点には注意が必要です。

ヒストグラム（Histogram）は、連続データの分布特性を視覚的に捉えるための基本的な手法です。
値の範囲をいくつかの「ビン（bin）」(※2)に区切り、それぞれのビンに属するデータの件数（頻度）を棒の高さで表現します。

以下はテスト所要時間の分布を可視化した例です。

• 応答時間、処理時間、テスト実行時間、メモリ使用量、レビュー所要時間など、連続値を含む定量データの分布を確認したいとき
• データのばらつき、偏り、外れ値、山の数（多峰性） などをひと目で把握したいとき
• 正規分布かどうかを直感的にチェックしたいとき（記述統計や仮説検定（※3）の前提確認として）

• データ全体の形状（分布） を可視化できる
  → 例：左右対称、右に歪んでいる、複数の山がある（多峰性）など
• 平均値・中央値・最頻値を重ねて表示すると、代表値の違いも理解しやすくなる
• ビンの数を調整することで、ざっくりか詳細に分布を観察できる（多すぎても少なすぎてもNG）
• 他の分布（例：正規分布）と重ねて比較することで、「どのくらいズレているか」もわかる

• ビンの幅や数の設定により、見た目の印象が大きく変わる
  → 一定のルール（Sturgesの式、Freedman–Diaconisの法則など）を使うか、目的に応じて調整する
• 離れた外れ値があると、スケールが崩れて全体の形がつかみにくくなる
  → ログスケールや外れ値を分離して別表示する方法もある
• カテゴリデータや離散的な値には不向き（棒グラフを使う方が適切）

ヒストグラムは「まず最初に見るべきグラフ」のひとつです。
分布の形状がわかれば、どの代表値やばらつき指標が適切か判断しやすくなります。

箱ひげ図（Box Plot）は、データの広がりや偏り、外れ値の有無を一枚で視覚化できる強力なグラフです。
四分位数をベースにしており、中央値・四分位範囲（IQR）・最大・最小・外れ値などが同時に確認できます。

以下は各チームのバグ修正所要時間の分布を比較した例です。

• レビュー時間、修正工数、テスト実行時間などの“ばらつきのある連続データ” の可視化
• 複数チームや月ごとのばらつきを比較したいとき
• 工程ごとの安定性や異常の有無をチェックしたいとき（例：ある月だけ極端に外れ値が多い）

• 箱の中央線：中央値（第2四分位数）
• 箱の上下：第1四分位数（Q1）～第3四分位数（Q3） → 四分位範囲（IQR）
• ひげ（線）：一般に「Q1 − 1.5×IQR」～「Q3 + 1.5×IQR」まで
• 外れ値（Outliers）：ひげの範囲を超えたデータ点（●などでプロットされる）
• 分布の偏り（歪み）も箱の位置やひげの長さから読み取れる

• 箱の形や外れ値の有無だけで“異常”と判断しないこと
  → 分布の偏りや極端なばらつきがデータの性質に由来する場合もある
• サンプル数が極端に少ないと正確な解釈が難しい
  → 外れ値が多く見えても、単なるばらつきの可能性も
• 複数グループの比較時は軸のスケール統一に注意

箱ひげ図は「分布の広がり・偏り・外れ値」を同時に捉えられる便利なツールです。
平均だけでは見えない“実務上のリスク”を把握するために、まず描いておくべきグラフのひとつです。

また箱ひげ図については別の記事でも紹介しています。よろしければご覧ください。

• 箱ひげ図で外れ値を確認する
• 箱ひげ図と散布図を同時に描画して概要を把握する(描画編)
• 箱ひげ図と散布図を同時に描画して概要を把握する(層別・分析編)

パレート図は、棒グラフと折れ線グラフを組み合わせたグラフで、要因別の件数とその累積割合を同時に可視化できます。
「重要少数 vs. 些末多数（80:20の法則）」を見極めるために使われ、リソースの集中配分や改善の優先順位付けに適しています。

以下はバグ種別ごとの件数と累積寄与率を表示した例です。
この例では、上位3種類のバグ「ロジック」「UI」「仕様漏れ」に対処できれば、全体の80％近いバグを対処できることがわかります。

• 赤い棒：バグ件数（多い順）
• 青い線：累積寄与率（％）
• 左軸：件数、右軸：％

• バグの発生原因別、レビュー指摘内容別など、カテゴリ毎の発生数を可視化
• 品質改善の優先順位付け
• 重要度の高い問題に集中した対応を行いたいとき

• 棒グラフ：各カテゴリの発生件数（多い順）
• 折れ線グラフ：累積寄与率（％）
• 通常、左側の数カテゴリが全体の大部分（80％）を占める
• 視覚的に“重要な少数”と“些末な多数”を区別可能

• カテゴリの並び順は“発生数の多い順”にしないと意味がない
  → 順序をバラバラにすると累積線の意味が失われる
• 棒グラフの縦軸（件数）と折れ線の縦軸（％）は別軸であるため、軸ラベルを明示しないと混乱を招く
• “上位数カテゴリ”だけで対応して良いかどうかは現場の判断も必要
  → 重大な問題が少数カテゴリに隠れている場合もある

パレート図は「何を優先すべきか？」を教えてくれる“判断の道具”です。
限られたリソースを効果的に配分するための可視化手段として、品質分析の現場で非常に有用です。

データを伝えるはずのグラフが、逆に誤解や混乱を招くこともあります。
以下は、実務で見かける「ありがちだけど避けたいグラフ表現」です。

• 3Dグラフ（見た目重視で誤読を招く）

  • 棒や円グラフの立体表示は奥行きの錯覚により、実際の数値比率を正確に認識しづらくなります。
  • 特に円グラフでは、手前の扇形が大きく見えるため、割合の誤読が起きやすい。
    → 原則、2D表現で十分です。

• 装飾過多なグラフ（色・影・アニメーションが多すぎる）

  • グラデーション・アニメーション・過剰な色数は、本来の数値の比較よりも見た目のインパクトに目がいってしまう危険があります。
  • 読み手の集中をそらし、何を伝えたいのかが不明確になりやすい。
    → 色数は3色程度に抑え、強調したい部分だけ目立たせるのが原則。

• スケールの異なる軸を並べる（誤った印象を与える）

  • 左軸と右軸でスケールが異なるグラフを安易に組み合わせると、「2つの線が似た動きをしているように見える」錯覚を起こしやすくなります。
  • 意図的に操作されているような印象を与えてしまうケースも。
    → 二軸グラフは補足説明を明示し、軸ラベルをはっきりと記載すること。

グラフの目的は「伝えること」であって「飾ること」ではありません。
相手の誤読を誘わない、誠実で分かりやすい表現を心がけましょう。

• グラフは「比較」「変化」「関係」を示す道具。それぞれに適した形式を使おう
• データの種類（カテゴリ or 数値、時系列 or 非時系列）に応じた選択が必要
• 不適切なグラフは“嘘”になりかねない。常に「伝わること」を優先しよう

次回は「PythonとExcelで描く統計グラフ入門」です。
実際のコードとともに、実務ですぐに使えるグラフの描き方、ツールの使い方をお届けします。

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

データ分析にご活用いただければ幸いです。