統計の話をしようじゃないか - ソフトウェア品質のための統計入門（No.1 統計って何？ ソフトウェア品質になぜ必要？）

あるIT企業のとある部門。

部長（品質保証）：「先日のリリース、バグがやけに多かった気がするんだけど、どうなんだ？」
開発リーダー：「そうですね…たしかにちょっと多かったかも、って印象はあります」
部長：「“印象”ねぇ…数字ではどうなってる？」
開発リーダー：「え、ええっと…」
部長：「それと、先月追加したテスト、あれ効果出てる？ 不具合減った？」
メンバー：「体感では減ってる気はしますが…はっきりとは…」

こんな会話、IT企業の現場では珍しくありません。
このように、“気がする”や“たぶん”で品質を語っていては、本当の問題は見えてきません。
プロジェクトの品質を左右する判断に、感覚的な印象だけで向き合っていてよいのでしょうか？

ここで必要になるのが「統計」です。

統計とは、ばらつきのある現実を数値で捉え、根拠を持って判断するための道具。
「正しく測って、見える化し、考える」──それが品質向上の第一歩です。

とはいえ、「統計」と聞くだけで難しい数式やグラフを思い浮かべて尻込みする人も多いでしょう。
でも安心してください。この連載では、ソフトウェア開発や品質管理に関わる方が、実務で使える視点から、統計の考え方をやさしく紹介していきます。

まずは、「そもそも統計って何なのか？」という基本から、一緒に見ていきましょう。

「統計」という言葉を聞いて、どんなものを思い浮かべるでしょうか？
グラフ、平均、分散、正規分布…あるいは、なんだか難しそうな数式でしょうか？

しかし、統計の本質はとてもシンプルです。
「データを集め、整理し、分析し、意味のある情報を引き出す方法論」、それが統計です。

私たちは、日常生活でも仕事でも、知らず知らずのうちに“統計的な判断”をしています。

日常では

• 「このカフェ、いつも混んでるから時間をずらそう」
• 「最近、寝る前にスマホを見る時間が長くなった気がする」
• 「雨が降りそうな雲行きだから、傘を持って出かけよう」

こうした判断は、過去の経験や観察（＝データ）をもとに、これからの行動を決めている例です。
つまり、自然と“データから傾向を読み取り、意思決定している” のです。

また、仕事でも

• 「今月のレビュー指摘数、いつもより少ないかも？」
• 「最近、テスト実行にかかる時間が延びてる気がする…」
• 「この作業、チームAよりチームBの方が完了が早い傾向があるな」

これらもまた、日常と同じように、データの積み重ねから“変化”や“差”を感じ取り、判断している行為です。

つまり、統計は“専門家だけが使う難しい技術”ではありません。
すでに私たちの中にある「直感的なデータの活用力」を、より正確に、より信頼できる形にするための技術なのです。

そして実務において統計は、次のような形で課題解決や意思決定を支える強力な武器になります：

• プロジェクトの進捗や品質の傾向を把握する
• 異常の兆候を早期に察知する
• 改善策の効果を客観的に評価する
• チームや顧客に納得感ある説明を行う

「見えないものを、見えるようにする」──
それこそが統計の最大の価値であり、品質の向上や再発防止にも直結します。

次のセクションでは、統計の中心的な考え方である「記述統計」と「推測統計」の違いについて見ていきましょう。

統計の世界は大きく「2つの柱」で構成されています。
それが 記述統計 と 推測統計（推計統計とも呼ばれます）です。
この2つの柱を理解すれば、「データをどう見るか」「どう判断するか」という基本姿勢が身につきます。

この2つは、「手元にあるデータをどう扱うか」という視点から明確に役割が分かれています。

記述統計は、手元にあるデータそのものを「整理」「要約」「可視化」するための技術です。

たとえば、次のような処理が記述統計に該当します：

• 平均値・中央値・最頻値などの 代表値 を算出する
• 標準偏差・分散・レンジ（範囲）といった ばらつきの指標 を求める
• ヒストグラムや箱ひげ図などで データの分布を可視化 する

例：不具合チケットの件数を週別に集計し、棒グラフで傾向を見る

記述統計の強みは、「今どうなっているか」を明確に把握できる点です。
プロジェクトの進捗確認、レビュー結果の傾向分析、日報の定量化など、日常業務にすぐ活かせます。

記述統計の肝は「現状をつかむ力」

記述統計は、まさに「今、何が起きているのか？」を見える化するための技術です。
たとえば、テスト実行結果のパス率、不具合の発生タイミング、コードレビューの指摘数などを整理することで、工程のボトルネックや安定性が明確になります。

• 代表値（平均・中央値） → 不具合発生の中心傾向
• 散布度（標準偏差） → 安定性のばらつき
• ヒストグラムや箱ひげ図 → 分布の形と外れ値の検知

統計がなければ、これらは「なんとなく多い／少ない」といった印象評価にとどまりがちです。
記述統計を用いれば、数値としてはっきりと根拠を持って語ることができます。

推測統計は、「手元の一部のデータ（標本）」から「全体（母集団）」の性質を推定する手法です。
つまり、限られた観測結果をもとに、見えない部分を推し量る技術です。

主に次のような分析が含まれます：

• 信頼区間：真の平均値がどの範囲にあると信じられるか
• 仮説検定：改善施策の効果が“偶然ではない”と言えるかどうか

例：「新しいテストプロセス導入後のバグ件数は、本当に減ったと言えるのか？」

推測統計の肝は「判断する力」

推測統計は「これで大丈夫か？」「変化は本物か？」を判断するために使われます。

たとえば：

• 新しいレビューガイドラインで指摘数が減った → それは偶然ではないのか？
• 品質目標を達成しているように見える → 本当に信頼できる範囲にあるのか？

これらを検証するには、サンプルから全体を推測する手法＝推測統計が必要になります。
信頼区間、仮説検定、p値などの考え方がここで活躍します。

統計には実はもう1つ、ベイズ統計（Bayesian Statistics） という考え方があります。
これは、観測されたデータに加えて、「事前に持っている知識（事前確率）」を加味して推論する方法です。

ただし、ベイズ統計は確率の定義からして異なる「別の体系」であり、専門的な応用が多いです。
このシリーズではまず「頻度主義的」な統計、すなわち 記述統計と推測統計 に絞って解説します。
ベイズ統計については、シリーズの後半または番外編として紹介したいと思います。

ソフトウェア開発の現場では、「品質」は日々変動しています。
不具合の件数、検出タイミング、修正コスト、テストの通過率──どれひとつとして完全に一定ではありません。

このような “ばらつき”こそが、品質リスクの本質です。
そして、このばらつきを無視して感覚で判断してしまうと、重大な見落としや判断ミスにつながります。

そこで必要なのが、「数値で捉え、傾向を見極める」ための統計です。

ばらつきを数値化し、異常を検知し、工程の安定を保つ。
これこそが、ソフトウェア品質管理における統計の役割です。

ソフトウェア開発では、想像以上に多くの場面で統計が使えます。
記述統計と推測統計の両方がそれぞれの役割を果たします。

• 不具合件数のトレンド分析（記述統計）
  　→ 週ごとのバグ報告数を集計し、リリースごとの品質傾向を把握

• プロセス改善効果の検証（推測統計）
  　→ 新しいレビュー手順を導入後、指摘件数が減ったか？仮説検定で判断

• 工程の安定性確認（記述統計 + 管理図）
  　→ テストの通過率をX̄-R管理図で監視し、異常の兆候を早期検出

• 外れ値の特定と原因分析（記述統計）
  　→ 修正に異常に時間がかかったバグを特定し、再発防止の対策につなげる

• 目標達成度の評価（推測統計）
  　→ 「不具合密度を0.8件/KLOC(※1)以下に抑える」という品質目標に対し、実際の値が達成基準内かを統計的に確認

このように統計は、現状を把握し、改善を進め、品質を維持するための全工程において活用可能です。

※1：KLOC（Kilo Lines of Code）：ソフトウェア工学における規模（Size）や生産性、品質指標として用いられる単位です。1,000行のソースコードを1 KLOC表記します。

「品質は作り込むもの」とよく言われます。
しかし実際には、品質は測って、見て、制御してこそ守れるものです。

統計的品質管理（SQC）は、製造業で発展してきました。
しかし近年では、ソフトウェア開発のような“目に見えにくい製品”においてこそ、その意義が再評価されています。

不具合票、レビュー記録、テストログ──私たちはすでに多くのデータに囲まれています。
それらを“数字として扱い”、改善に活かすことこそが、統計の真価なのです。

統計は単なる分析ツールではありません。
品質マネージャやエンジニアにとって、次のような力を身につけるための“思考技術”でもあります。

• 感覚や思い込みに流されない 定量的判断力
  　→ 「なんとなくバグが減った」ではなく「p値0.01で有意に減った」と言える

• 「なぜそう言えるのか？」に答える 説明力
  　→ 客観的な根拠でチームや上司、顧客を説得できる

• 改善効果を示す 証明力
  　→ 施策の効果が“偶然”か“実力”かを見極められる

• 見える化による 可視化スキル
  　→ ヒートマップやグラフでデータを直感的に伝える資料を作れる

統計の考え方を身につけることは、
「経験と勘に頼る現場」から「データで判断できる現場」への進化でもあります。

そしてそれは、“品質を自信を持って語れる人材”への第一歩なのです。

さあ、冒頭で話をしたIT企業の担当者の会話はどう変化したでしょうか。

部長（品質保証）：「先月のリリース、バグの傾向はどうだった？」
開発リーダー：「はい、前回に比べてバグ件数は18件から11件に減少しました。95%信頼区間でも明らかな差が出てます」
部長：「なるほど、追加したテストの効果が出たということか？」
メンバー：「はい。導入後のバグ密度は 0.9 → 0.5 件/KLOC に下がっており、仮説検定でも有意差ありと判定されています」
部長：「いいね。効果が数値で示されていると安心できるな」

• 統計は、データから「正しく判断する」ためのツール
• 記述統計と推測統計を使い分けることで、実務の改善が可能に
• ソフトウェア品質において統計は不可欠なスキル

次回は、「データとの向き合い方」をテーマに、
定性／定量データの違いや、測定値とその誤差、良いデータとは何かについて詳しく解説していきます。

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

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