QC7つ道具とは？新QC7つ道具との違いと品質改善での使い分け

不具合が減らない、原因の議論が毎回堂々巡りになる、改善したはずなのに効果が数字で示せない。品質改善でよく起きるこうした行き詰まりの多くは、「データの見せ方」と「考えの整理の仕方」が決まっていないことが原因です。

そこで役立つのが、製造業で半世紀以上使われてきた品質管理の基本ツール群「QC7つ道具」です。数値では表せない情報を扱う「新QC7つ道具」という手法群もあります。

この記事では、QC7つ道具の7手法と新QC7つ道具の7手法を、1つずつ解説します。そのうえで、両者の違いと使い分けの判断基準を整理します。

ソフトウェアテスト・品質保証の現場での使い方も紹介します。製造業の事例だけでは、イメージしにくい部分です。欠陥分析、原因分析、欠陥密度の推移管理という実務のシーンに沿って説明します。

---

QC7つ道具とは？品質改善の基本となる7つの分析手法

QC7つ道具の定義と目的

QC7つ道具とは、主に数値データを整理・可視化して、品質上の問題を発見し、原因を突き止めるための7つの統計的手法の総称です。QCは Quality Control（品質管理）の略で、日本語では「QCの七つ道具」「QC七つ道具」とも表記されます。表記は違っても指しているものは同じです。

QC七つ道具の背景にあるのは「品質改善は専門家だけでなく現場の全員が担うもの」という考え方です。統計の知識がなくても描け、図にすることで誰の目にも問題が見える。この「現場の誰もが使える」という設計思想こそが、QC7つ道具が長く使われ続けてきた理由です。

QC7つ道具を使う目的は、大きく次の4つに整理できます。

1. 現状把握：何がどれだけ起きているのかを数字で掴む
2. 重点化：限られた工数をどの問題に投じるべきかを決める
3. 要因分析：問題がなぜ起きるのかを構造的に洗い出す
4. 効果確認：対策を打った後に、本当に改善したかを検証する

QC7つ道具は「勘と経験と度胸」で語られがちな品質の議論を、事実とデータに基づく議論へ引き上げる共通言語です。この点はソフトウェア開発でも変わりません。

「QC7つ道具」「QCの七つ道具」「QC七つ道具」の表記の違い

調べているとき、「QC7つ道具」「QCの七つ道具」「QC七つ道具」という3通りの書き方に出会って、戸惑った方もいるかもしれません。結論から言うと、この3つはすべて同じ手法群を指しており、内容に違いはありません。

品質管理の公式文献では、漢数字の「QC七つ道具」が使われることが多いです。社内資料やWeb記事では、読みやすさを優先して算用数字の「QC7つ道具」が使われる傾向があります。

「QCの七つ道具」は、助詞を挟んだ口語的な言い方です。覚えるべき中身は共通なので、表記の違いを気にする必要はありません。

QC7つ道具の一覧と役割

まずは全体像を押さえましょう。QC7つ道具の7手法と、それぞれが何を明らかにする道具なのかを一覧にまとめます。

手法	何を見る道具か	主な使いどころ	扱うデータ
パレート図	問題の重要度の順位と累積比率	重点課題の絞り込み	件数・金額
特性要因図	結果と要因の因果構造	原因の洗い出し	言語＋数値
グラフ	数値の傾向・内訳・比較	現状の共有・報告	数値全般
チェックシート	事実の記録と発生パターン	データ収集・点検	件数
ヒストグラム	データの分布とばらつき	規格との適合確認	計量値
散布図	2つの変数の相関関係	要因の妥当性検証	対になる数値
管理図	時系列での工程の安定性	異常の早期検知	時系列数値

文献によっては、「グラフ」の代わりに層別を7つに数えます。層別とは、データを機種・工程・担当者・時期などの切り口で分けて、分析することです。単独の図ではなく、全手法に共通する考え方にあたります。

本記事では「グラフ」を7つに含め、層別は各手法の土台として扱います。

QC7つ道具の覚え方

7つを丸暗記するのは大変です。「データを集める → 全体を見る → 絞り込む → 原因を探る → 監視する」という改善の流れに沿って並べると、自然に覚えられます。

• 集める：チェックシート
• 全体を見る：グラフ、ヒストグラム
• 絞り込む：パレート図
• 原因を探る：特性要因図、散布図
• 監視する：管理図

頭文字を並べる語呂合わせもよく使われます。「パ（パレート図）特（特性要因図）グ（グラフ）チェ（チェックシート）ヒ（ヒストグラム）サン（散布図）カン（管理図）」の順です。

---

QC7つ道具の7手法を1つずつ解説

ここからはQC七つ道具の7手法を、「何を見る道具か」「いつ使うか」「作り方の手順」「ソフトウェア品質での具体例」の4点セットで解説します。

1. パレート図｜どこから手を付けるかを決める

何を見る道具か：項目別の発生件数を多い順に棒グラフで並べ、その累積比率を折れ線で重ねた図です。「全体の問題の大部分は、少数の項目が引き起こしている」というパレートの法則（80対20の法則）を目で確認するために使います。

いつ使うか：改善テーマを決める最初の段階です。問題が10個も20個も並び、どれから着手すべきか判断できないとき、工数の優先順位を決められます。

作り方の手順

1. 分類の切り口（不具合の種類、発生機能、原因工程など）を1つ決める
2. 切り口ごとに件数を集計し、多い順に並べ替える
3. 件数を棒グラフで描く（「その他」は件数に関わらず最後に置く）
4. 累積比率を計算し、右側の第2軸に折れ線で重ねる
5. 累積70〜80%に達するまでの項目を重点対象として選ぶ

ソフトウェア品質での具体例：システムテストで検出した欠陥300件を「発生機能別」で集計します。すると、全体の72%が「帳票出力」「権限管理」「外部連携」の3機能に集中していた、というケースです。

コツは、分類の切り口を変えて何枚か描くことです。「機能別」「原因工程別」「重要度別」の3視点で描くと、どこを直せば効くのかが立体的に見えてきます。

欠陥を分類する前提として、「バグ」「欠陥」「故障」「エラー」といった用語の定義がチーム内で揃っている必要があります。用語がぶれたままでは、パレート図の分類も揺れてしまいます。

バグ・欠陥・故障・エラーの違いもあわせて確認しておくと、分析の精度が上がります。

2. 特性要因図（フィッシュボーン）｜原因を構造的に洗い出す

何を見る道具か：結果（特性）に影響を与える要因を、魚の骨のような形で階層的に整理した図です。形状からフィッシュボーン図、考案者の名前から石川ダイアグラムとも呼ばれます。QC7つ道具の中で唯一、数値ではなく言葉を扱う手法です。

いつ使うか：パレート図で重点課題を絞り込んだ後、その課題がなぜ起きるのかをチームで洗い出す段階です。複数人のブレインストーミングと組み合わせることで、威力を発揮します。

作り方の手順

1. 紙の右端に解決したい「特性（結果）」を書き、背骨となる矢印を引く
2. 背骨に対して大骨を斜めに引き、大分類を記入する
3. 大骨ごとに「なぜそうなるのか」を問い、中骨・小骨に展開する
4. 展開が止まるまで（おおむね3〜4階層）掘り下げる
5. 影響が大きそうな要因に印を付け、検証対象を決める

製造業では大骨に「4M（Man／Machine／Material／Method）」を使うのが定番ですが、ソフトウェア開発ではそのままでは当てはまりません。次のように読み替えると使いやすくなります。

製造業の4M	ソフトウェア開発での読み替え	具体的な要因の例
Man（人）	要員・スキル	担当者の経験不足、レビュー実施者の偏り
Machine（機械）	環境・ツール	テスト環境と本番環境の差異、CI設定の不備
Material（材料）	仕様・入力情報	要件定義の曖昧さ、テストデータの不足
Method（方法）	プロセス・技法	テスト設計技法の未適用、レビュー基準の未整備

ソフトウェア品質での具体例：特性は「本番リリース後に境界値の不具合が繰り返し流出する」です。「仕様・入力情報」の大骨からは「上限値の記載が仕様書にない」が挙がります。「プロセス・技法」の大骨からは「境界値分析を設計に組み込んでいない」が浮かび上がります。

挙がった要因のうち、レビュー体制に関わるものは、レビューとインスペクションによる品質作り込みの観点から対策を検討します。これが上流での欠陥除去につながります。

3. グラフ｜数値を誰にでも伝わる形にする

何を見る道具か：棒グラフ・折れ線グラフ・円グラフ・帯グラフ・レーダーチャートなど、数値を視覚化する表現全般です。地味ですが、QC7つ道具の中でもっとも使用頻度が高いのがグラフです。

いつ使うか：現状を関係者に共有するとき、対策前後を比較するとき、進捗を報告するときなど、あらゆる場面で使います。

作り方の手順：手順というより「目的に応じた種類の選択」が重要です。伝えたい内容とグラフ種類の対応は次のとおりです。

• 大小を比較したい：棒グラフ
• 時間による変化を見たい：折れ線グラフ
• 構成比を見たい：円グラフ・帯グラフ
• 複数の評価軸のバランスを見たい：レーダーチャート
• 累積の進み具合を見たい：積み上げ面グラフ

ソフトウェア品質での具体例：テスト進捗管理で使う「消化件数と不具合検出数の推移グラフ」が代表例です。テストケースの消化本数（計画線と実績線）と検出欠陥数を、同じ時間軸に重ねます。

すると「消化は進んでいるのに欠陥が出ていない」という状態が見えます。これはテストの深さが足りない可能性を示すサインです。

4. チェックシート｜事実を漏れなく記録する

何を見る道具か：確認項目や記録項目をあらかじめ用意し、チェックを付けるだけでデータが集まる帳票です。用途によって点検用チェックシート（やるべきことの実施漏れを防ぐ）と記録用チェックシート（発生した事象の件数や分布を集める）に分かれます。

いつ使うか：分析のいちばん手前、データを集める段階です。ここが雑だと、後続のパレート図もヒストグラムも意味をなさないため、実は7つの中でもっとも重要と言えます。

作り方の手順

1. 何を明らかにしたいのか（目的）を先に決める
2. 目的に必要な記録項目だけを列挙する（多すぎると記入されなくなる）
3. 選択肢を用意し、記入者の判断が入らない形にする
4. 記入者・日時・対象を必ず残す欄を設ける
5. 数件試験運用し、記入のばらつきを見て様式を直す

ソフトウェア品質での具体例：不具合管理システム（BTS）の起票フォームは、まさに記録用チェックシートです。「検出工程」「原因工程」「不具合分類」「重要度」を選択式にしておけば、後からパレート図をワンクリックで作れます。

自由記述にしていると、集計時に表記ゆれの名寄せから始めることになります。分析コストが跳ね上がる原因です。点検用としては、リリース前チェックリストやテストの種類ごとの観点リストが該当します。

5. ヒストグラム｜ばらつきの形を掴む

何を見る道具か：測定値をいくつかの区間（級）に分け、その区間に入るデータの個数を柱状に描いた図です。平均値だけではわからない「データがどう散らばっているか」という分布の形を明らかにします。

いつ使うか：測定値の集団が規格や目標を満たしているか、分布に異常な癖がないかを確認したいときです。

作り方の手順

1. データを集める（おおむね50〜100個以上が目安）
2. 最大値と最小値から範囲を求める
3. 区間の数を決める（データ数の平方根が目安）
4. 区間の幅を決め、区間ごとの度数を数える
5. 柱状に描き、規格値の線を引いて分布と比較する

分布の形からは原因を推測できます。代表的な読み方は次の3つです。

• 釣鐘型（左右対称）：安定した状態
• ふた山型（山が2つ）：性質の異なる2集団が混在している。層別が必要
• 絶壁型（端が切れている）：選別や除外がおこなわれている疑いがある

ソフトウェア品質での具体例：API応答時間のヒストグラムが典型です。平均が300msでも、描いてみると、250ms付近の山と1,200ms付近の小さな山に分かれることがあります。これは特定条件でキャッシュが効かない経路があるサインで、平均値だけを見ていたら気づけません。

6. 散布図｜2つの数値の関係を確かめる

何を見る道具か：対になる2種類の数値データを縦軸・横軸に取り、点をプロットした図です。2つの変数に相関関係があるかを視覚的に判断します。

いつ使うか：特性要因図で「これが原因ではないか」と仮説を立てた要因について、本当に結果と関係しているのかを検証する段階です。

作り方の手順

1. 原因と考えられる値を横軸、結果の値を縦軸に決める
2. 対応するデータの組を30組以上集める
3. 点をプロットする
4. 点の散らばり方から相関の有無と強さを読む
5. 必要なら層別して描き直し、見かけの相関を排除する

注意すべきは、相関があることと因果関係があることは別だという点です。第三の要因で両方が動いているだけの「疑似相関」の可能性は常に残ります。散布図は仮説を否定する材料としては強力ですが、肯定する材料としては慎重に扱うべきです。

ソフトウェア品質での具体例：「モジュールの循環的複雑度」と「そのモジュールで検出された欠陥数」で散布図を描きます。複雑度が一定の閾値を超えたあたりから、欠陥数が跳ね上がる傾向が見えることがあります。これはリファクタリング対象の選定根拠になります。

ほかにも「レビュー指摘件数と後工程での欠陥数」「テストカバレッジと流出欠陥数」の関係を見るのに有効です。カバレッジを指標に使う場合は、C0・C1・C2カバレッジの違いを踏まえます。どの網羅基準の数値を使うのかを揃えておく必要があります。

7. 管理図｜工程が安定しているかを監視する

何を見る道具か：時系列に並べた測定値の折れ線に、中心線（CL）と上下の管理限界線（UCL・LCL）を引いた図です。「いつもどおりのばらつき」と「見逃してはいけない異常」を区別するための道具です。

いつ使うか：改善後の状態を維持できているかを継続的に監視する段階です。QC7つ道具の中では唯一、「問題が起きてから使う」のではなく「問題を起こさないために使い続ける」性格を持ちます。

作り方の手順

1. 管理したい特性と、データを取る単位（日次・スプリント単位など）を決める
2. 安定していた期間のデータから平均を求め、中心線とする
3. 標準偏差から上方管理限界と下方管理限界（一般に±3σ）を計算する
4. 以降のデータを継続的にプロットする
5. 限界線を外れた点や、異常なパターンが出たら原因を調べる

管理限界を外れていなくても、異常と判断すべきパターンがあります。次の動きは、工程に何らかの変化が起きているサインとされます。

• 連続7点が中心線の同じ側にある
• 連続7点が一方向に上昇または下降する
• 点が周期的に上下する

ソフトウェア品質での具体例：スプリントごとの「欠陥密度（欠陥件数 ÷ 開発規模）」をプロットする使い方が代表的です。ある回だけ上方管理限界を突き抜けていたとします。そのスプリントで何が違ったのか（新メンバーの参画、仕様変更の集中、レビュー省略など）を掘り下げる根拠になります。

逆に「7スプリント連続で中心線より下」なら、品質がよくなったとは限りません。テストが甘くなっている可能性も疑うべきです。

---

新QC7つ道具（N7）とは？言語データを整理する7つの手法

新QC7つ道具（N7：New seven tools）は、数値化しにくい「言語データ」を整理・構造化するための7つの手法です。1970年代後半に、日本科学技術連盟の研究会によって体系化されました。

従来のQC七つ道具は、すでに起きた不具合のデータを分析するのが得意でした。品質管理の対象が企画・設計・サービスへ広がると、状況は変わります。顧客の要望、関係者の意見、これから起こりうるリスクなど、数値がまだ存在しない段階の問題を扱う必要が出てきます。

それに応える手法として生まれたのが新QC7つ道具です。

手法	何をする道具か	主な使いどころ
親和図法	混沌とした意見をグループ化して問題を定義	問題が曖昧な最初期
連関図法	絡み合う原因の因果関係を矢印で構造化	要因が複雑に絡む問題
系統図法	目的を手段へ樹形図で段階展開	対策立案・目標の展開
マトリックス図法	2軸の交点で対応関係と重みを評価	優先順位付け・割り当て
アローダイアグラム法	作業の順序と日程を矢印でネットワーク化	計画立案・進捗管理
PDPC法	不測の事態を想定した代替ルートを設計	リスク対応の事前設計
マトリックスデータ解析法	多変量データを主成分に集約して数値評価	大量データの位置づけ把握

7つのうち、マトリックスデータ解析法だけは数値データを扱います。多変量解析（主成分分析）を用いるため、新QC7つ道具の中では例外的な位置づけです。

1. 親和図法｜バラバラな意見から問題を定義する

関係者から集めた意見や事実を1件ずつカードに書き出し、似たもの同士をグループにまとめて見出しを付けていく手法です。KJ法を品質管理向けに整理したものとして知られています。

「何が問題なのかすら共有できていない」状況で威力を発揮します。ポイントは先に分類の枠を決めないこと。あらかじめカテゴリを用意して振り分けると、既存の思い込みをなぞるだけになります。

ソフトウェア開発での例：リリース後の振り返りで、参加者全員に「うまくいかなかったこと」を付箋に書いてもらいグルーピングする。「仕様変更の伝達」に関する付箋が突出して多いと分かれば、次の改善テーマが定まります。

2. 連関図法｜絡み合った原因の構造を解く

問題を中央に置き、原因同士を矢印でつなぎ、因果関係のネットワークを描く手法です。特性要因図と似ていますが、特性要因図が「一方向の階層」であるのに対し、連関図は「要因同士が相互に影響し合う関係」を表現できる点が決定的に違います。

矢印を引き終えたら、出ていく矢印が多い要因（＝多くの問題の元凶）と、入ってくる矢印が多い要因（＝結果として現れる症状）を見分けます。対策を打つべきは前者です。

ソフトウェア開発での例：「リリースが遅延する」を中央に置くと「テスト工数不足」「仕様変更の頻発」「環境構築の遅れ」などが挙がります。矢印を引くと「仕様変更の頻発」から多数の矢印が出ていることが判明し、手を打つべきは要件管理プロセスだとわかります。

3. 系統図法｜目的を手段へ展開する

達成したい目的を左に置き、「そのためには何をするか」を問いながら右へ樹形図状に手段を展開する手法です。展開された手段は1つ下の階層から見れば新たな目的になり、この連鎖を3〜4階層繰り返すと、すぐ実行できる具体的なアクションにたどり着きます。

ソフトウェア開発での例：「本番障害を半減させる」から「上流で欠陥を除去する」「テストの網羅性を高める」へ展開します。そこから「設計レビューのチェックリストを整備する」「境界値分析を設計標準に組み込む」という実行可能な施策まで落とし込みます。

抽象的な目標が具体的なタスクに変換され、改善計画の作成に直結します。

4. マトリックス図法｜2軸の交点で関係を評価する

行と列に異なる要素群を配置し、交点に対応関係の有無や強さを記号（◎○△など）で記入する手法です。L型・T型・Y型などの形があり、もっとも使われるのは2要素を対応させるL型マトリックスです。系統図法で出した施策を評価軸（効果・コスト・実現性）で採点し、優先順位を決める使い方が定番です。

ソフトウェア開発での例：要件とテストケースのトレーサビリティマトリックスが、まさにこれです。行に要件、列にテストケースを並べて交点に対応を記入すれば、テストされていない要件がひと目でわかります。「機能 × リスク」でテストの重点配分を決める使い方も有効です。

5. アローダイアグラム法｜作業の順序と日程を設計する

作業を矢印、作業の区切りを結合点（丸）として、実施順序をネットワーク図で表す手法です。PERT図とも呼ばれ、全体日程を決定づけるクリティカルパス（余裕がゼロの経路）を特定できます。ガントチャートが「いつ何をやるか」を示すのに対し、アローダイアグラムは「どの作業がどの作業に依存しているか」という構造を示します。

ソフトウェア開発での例：テスト計画で「環境構築 → テストデータ準備 → 結合テスト → システムテスト → 受入テスト」の依存関係を描きます。すると、環境構築の1日の遅れが、そのままリリース日の遅れになることが可視化されます。並行実施できる作業を見つけ、日程を圧縮する検討にも使えます。

6. PDPC法｜想定外に備えたルートを用意する

PDPCは Process Decision Program Chart（過程決定計画図）の略です。目標に至る過程で「うまくいかなかった場合はどうするか」という分岐をあらかじめ書き込んでおく手法です。リスクマネジメントの色合いが濃いのが特徴です。

まず楽観的な本流ルートを1本描きます。各ステップに「ここで失敗するとしたら何が起きるか」を問いながら、代替ルートを枝として追加していきます。

ソフトウェア開発での例：リリース当日の作業計画が典型的な適用先です。本流は「デプロイ → 疎通確認 → 本番データ移行 → 監視」です。ここに「疎通確認でエラーが出たら旧バージョンへロールバック」「移行が規定時間内に終わらなければ翌日へ延期」という分岐を加えます。

分岐を事前に決めておけば、当日に判断を迫られる場面が減ります。対応の質も安定します。

7. マトリックスデータ解析法｜多変量データを要約する

多数の項目からなる数値データを主成分分析で少数の軸に集約し、対象の位置関係を平面上に表現する手法です。評価項目が多すぎて全体像が掴めないとき、2次元に圧縮して「似ているもの同士」を可視化するのが主な役割です。

ソフトウェア開発での例：複数プロジェクトの品質指標（欠陥密度、レビュー実施率、テスト密度、工期遵守率など）を分析します。「品質も納期も良好な群」「テストは厚いが工期が守れない群」という類型を見つける使い方が考えられます。

実務での使用頻度は低い手法です。まずは残り6つを使いこなすことをおすすめします。

---

QC7つ道具と新QC7つ道具の違い

両者の違いを一言で言えば、QC7つ道具は「数値データを分析する道具」、新QC7つ道具は「言語データを整理する道具」です。この軸を押さえておけば、細かい手法名を忘れても選択を誤りません。

比較の観点	QC7つ道具	新QC7つ道具（N7）
扱うデータ	定量データ（数値）	定性データ（言語・意見）
基本的な役割	事実を分析して問題を特定する	思考を整理して方針を立てる
主な対象工程	製造・検査・運用など下流	企画・設計・計画など上流
時間軸	過去に起きたことの分析	これから起きることの計画
前提条件	データが既に存在すること	データがなくても着手できる
作業形態	個人でも作成可能	複数人での討議が前提
アウトプット	グラフ・図表（数値の可視化）	図解（関係性の構造化）
成立時期	1950年代〜	1970年代後半〜
手法の例	パレート図、ヒストグラム、管理図	親和図法、系統図法、PDPC法

重要なのは、両者が対立するものではなく補完し合う関係だという点です。新QC7つ道具はQC七つ道具を置き換えるものではなく、QC七つ道具では扱えなかった領域を埋めるために作られました。「新」という字から、新QC7つ道具のほうが優れていると誤解されがちですが、それは正しくありません。

数値があるなら QC7つ道具で分析する。数値がないなら 新QC7つ道具で言葉を構造化する。そして構造化した結果を検証するために、また QC7つ道具に戻る。

この往復こそが品質改善サイクルの実態です。改善活動は、次の順序で進むのが基本です。

1. 親和図法で問題を定義する
2. パレート図で重点化する
3. 特性要因図と連関図法で原因を探る
4. 散布図で仮説を検証する
5. 系統図法で対策を展開する
6. 管理図で効果を維持する

---

使い分けの判断フロー｜どの道具を選ぶべきか

手法を覚えても、実際の場面でどれを使うべきか迷うのが最大の壁です。次の4つの問いに順に答えると、使うべき道具が絞り込めます。

4つの問いで道具を選ぶ

1. 数値データはあるか？ ない → 新QC7つ道具へ／ある → 次へ
2. 問題は特定できているか？ できていない → パレート図・グラフ／できている → 次へ
3. 原因の仮説はあるか？ ない → 特性要因図・連関図法／ある → 散布図・層別で検証
4. 対策は打ち終えたか？ 終えた → 管理図で維持／これから → 系統図法で展開

この判断を、よくある状況別にまとめたのが次の表です。

いま直面している状況	使うべき道具	期待できる成果
何が問題なのか関係者で認識がずれている	親和図法	問題の定義と共通認識
問題が多すぎて着手順を決められない	パレート図	重点課題の絞り込み
データのばらつきが大きく傾向が読めない	ヒストグラム＋層別	分布の異常と混在の発見
原因の候補が思いつかない	特性要因図	要因の網羅的な洗い出し
原因が複雑に絡み合っている	連関図法	真因（元凶）の特定
原因の仮説が正しいか確かめたい	散布図	相関の有無の客観的判断
対策案が抽象的で実行に移せない	系統図法	具体的アクションへの分解
対策案が多く優先順位が決まらない	マトリックス図法	効果とコストによる序列化
作業の依存関係と納期が読めない	アローダイアグラム法	クリティカルパスの把握
計画どおりに進まないリスクが高い	PDPC法	代替ルートの事前準備
対策後に元に戻っていないか不安	管理図	異常の早期検知と維持
そもそもデータが取れていない	チェックシート	分析可能なデータの蓄積

迷ったときはチェックシートから始めるのが鉄則です。「まず1か月、不具合の分類を選択式で記録する」ところから始めれば、翌月にはパレート図が描けます。

---

ソフトウェアテスト・品質保証でのQC7つ道具の活用例

QC七つ道具は製造業の文脈で語られがちですが、「欠陥」というデータを扱う以上、ソフトウェア開発でも適用できる場面は非常に多いのが実情です。代表的な3つの活用パターンを紹介します。

欠陥分析にパレート図を使う

テスト工程で検出した欠陥を分類してパレート図を描くのは、もっとも導入しやすく効果が大きい使い方です。実務では次の3つの切り口で描き分けます。

• 機能別：品質リスクを抱えたモジュールが分かり、追加テストの投入先を決められる
• 原因工程別：要件定義・設計・実装のどこで欠陥が作り込まれたかが分かり、プロセス改善の的が定まる
• 検出工程別：どの工程で見つかったかが分かり、上流の検出力（レビューの効き具合）を評価できる

特に「原因工程別」と「検出工程別」を突き合わせると、欠陥が作り込まれてから発見されるまでの距離が見えます。要件定義で作り込まれた欠陥が、受入テストで初めて見つかっているなら、修正コストは最大に膨らんでいます。この距離を縮めることがテスト戦略の中核テーマです。

原因分析に特性要因図を使う

重大な障害の振り返り（ポストモーテム）で、特性要因図は強力に機能します。障害報告書に「担当者の確認不足」とだけ書かれて終わるケースがあります。それでは同じ障害が繰り返されます。

フィッシュボーンで「要員・スキル」「環境・ツール」「仕様・入力情報」「プロセス・技法」の4方向から要因を出し切ります。すると、個人の注意力ではなく仕組みで防げる要因が見つかります。

「レビュー観点にこの項目がなかった」「テスト環境に本番相当のデータ量がなかった」といった要因です。対策を打てば、再発を減らせます。

欠陥密度・検出数の推移に管理図を使う

継続的に開発しているプロダクトでは、品質指標を管理図で監視することで異常を早期に察知できます。管理図に載せやすいソフトウェア品質指標の例は次のとおりです。

指標	計算方法	異常時に疑うこと
欠陥密度	検出欠陥数 ÷ 開発規模	設計品質の低下、レビュー不足
テスト密度	テストケース数 ÷ 開発規模	テスト設計の網羅性不足
リグレッション失敗率	失敗件数 ÷ 実行件数	既存機能への影響、環境不安定
ビルド失敗率	失敗ビルド数 ÷ 総ビルド数	マージ運用の乱れ、テスト不安定
平均修正時間	起票から解決までの平均日数	要員逼迫、原因特定の困難化

特にリグレッションテストの失敗率は有効です。急上昇したときは実装の問題だけでなく、テストケース自体の劣化や、環境の不安定さが原因のこともあります。どこまでを自動リグレッションの対象にするかは、リグレッションテスト戦略の考え方もあわせて参考にしてください。

QCストーリーをテストプロセスに重ねる

QC7つ道具は単体で使うより、改善活動の型であるQCストーリーに沿って使うと、効果が安定します。QCストーリーの各段階と、対応する道具は次のように整理できます。

QCストーリーの段階	主に使う道具	ソフトウェア開発での活動
1. テーマの選定	パレート図、親和図法	改善対象の欠陥カテゴリを決める
2. 現状の把握	チェックシート、グラフ、ヒストグラム	欠陥データの収集と傾向整理
3. 目標の設定	グラフ	欠陥密度の目標値を数値で置く
4. 要因の解析	特性要因図、散布図、連関図法	原因の洗い出しと検証
5. 対策の立案・実施	系統図法、マトリックス図法、PDPC法	施策の具体化と優先順位付け
6. 効果の確認	パレート図、グラフ	対策前後の欠陥件数比較
7. 標準化と維持	管理図、チェックシート	テスト観点への反映と継続監視

この流れで進めれば、QC七つ道具と新QC七つ道具が自然に組み合わさります。個々の手法を覚えるより、この流れを1周やり切る経験のほうが習得は速いはずです。

---

QC7つ道具を使うときの注意点

図を作ること自体が目的化しないようにする

もっとも多い失敗が、きれいな図を報告資料に貼った時点で満足してしまうケースです。QC7つ道具は意思決定のための道具であり、図から「次に何をするか」が出てこなければ意味がありません。パレート図を描いたら「上位3項目に工数の6割を投じる」といった決定まで進めましょう。

層別を忘れない

データをひとかたまりで見ていると、重要な傾向が打ち消し合って見えなくなります。プロジェクト別、チーム別、環境別、期間別で分けて描き直すと、全体では見えなかった偏りが浮かび上がります。

分析で行き詰まったら層別を疑う。実務でもっとも再現性の高いコツです。

データの質を軽視しない

分類基準が曖昧なまま集めたデータをいくら分析しても、結論は信用できません。「重要度：高」の判断が人によって違えば、重要度別のパレート図は意味を持ちません。分析を始める前に分類の定義を文書化し、チームで合意しておきましょう。

数字で人を評価しない

欠陥データを個人の評価に結びつけると、その瞬間からデータは歪みはじめます。欠陥が起票されない、軽微に分類されるといった行動が起き、分析基盤そのものが壊れます。品質データはプロセスを直すために使うという原則を、運用開始時に明示すべきです。

---

よくある質問（FAQ）

Q1. 「QC7つ道具」と「QC七つ道具」はどちらが正しい表記ですか？

どちらも正しく、指している内容は同じです。品質管理の公式文献では「QC七つ道具」、Webや社内資料では「QC7つ道具」が使われる傾向があります。「QCの七つ道具」も同義です。

QC検定でも、表記の違いが問われることはありません。

Q2. QC7つ道具と新QC7つ道具、どちらから学ぶべきですか？

QC7つ道具からです。数値の分析は結果が客観的に示せるため、成功体験を得やすく周囲の理解も得られます。パレート図と特性要因図の2つだけでも、改善活動の質は変わります。

新QC7つ道具は、扱う問題が上流や組織的な課題へ広がってから学べば十分です。

Q3. 7つのうち「グラフ」ではなく「層別」が入っている資料を見ました

文献によって「グラフ」を入れるか「層別」を入れるかが分かれており、どちらも一般的です。層別は独立した図法というより、すべての手法に共通する分析の考え方であるため、「グラフ＋層別（考え方）」として両方押さえておけば問題ありません。

Q4. ソフトウェア開発でも本当にQC7つ道具は使えますか？

使えます。特に次の4つは、そのまま実務に組み込めます。

• パレート図：欠陥の重点化
• 特性要因図：障害の原因分析
• 管理図：品質指標の監視
• チェックシート：不具合起票フォームの設計

ヒストグラムや散布図は連続値が必要です。応答時間やコードメトリクスなど、数値が取れる対象に限って使うのが現実的です。

Q5. Excelだけで作れますか？専用ツールは必要ですか？

グラフ・ヒストグラム・散布図・パレート図・管理図は、表計算ソフトで作成できます。パレート図はExcelの標準グラフにあり、管理図も、平均値と標準偏差から限界線を計算して折れ線に追加すれば作れます。特性要因図と新QC7つ道具は、作図ツールやホワイトボードツールが向いています。

Q6. データが少なくても使えますか？

手法によります。パレート図やチェックシートは少数でも役に立ちますが、ヒストグラムは50件以上、散布図は30組以上、管理図は20点以上を目安にしないと判断を誤ります。データが足りないうちは、新QC7つ道具で関係者の知見を構造化するほうが有効です。

---

品質データを分析できる状態を作るなら『テスター10』へ

QC七つ道具を機能させる前提は「分析できる形で品質データが蓄積されていること」です。現実には、テストの実行だけで手一杯というチームがあります。欠陥の分類も記録も後回しです。

分析以前に、テストそのものの人手が足りていないのです。

ソフトウェアテスト代行サービス『テスター10』では、テスト実行の代行にとどまらず、次のような品質改善の土台づくりまでご支援しています。

• テスト設計・テスト実行の代行による、開発チームの工数確保
• 欠陥分類の基準づくりと、分析可能な形での不具合起票運用
• 欠陥密度・検出工程などの品質指標の可視化とレポーティング
• リグレッションテストの整備と自動化による、継続的な品質監視

「不具合は起票しているが分析に使えていない」「どのテストにどれだけ工数を割くべきか判断できない」。こうした課題をお持ちでしたら、現状のデータを拝見したうえで改善の進め方をご提案します。フェーズを問わずご相談いただけます。

---

まとめ

QC7つ道具（QCの七つ道具）と新QC7つ道具について、それぞれの手法と使い分けを解説しました。要点を整理します。

• QC7つ道具はパレート図・特性要因図・グラフ・チェックシート・ヒストグラム・散布図・管理図の7手法で、数値データから問題を発見・分析する道具
• 新QC7つ道具は親和図法・連関図法・系統図法・マトリックス図法・アローダイアグラム法・PDPC法・マトリックスデータ解析法の7手法で、言語データを整理して方針を立てる道具
• 両者の違いは定量データか定性データか。優劣ではなく補完関係にあり、改善活動では往復して使う
• 「QC7つ道具」「QCの七つ道具」「QC七つ道具」は表記が違うだけで同じもの
• ソフトウェア品質では、欠陥分析にパレート図、原因分析に特性要因図、欠陥密度の推移に管理図が特に有効
• 始めるならチェックシート（不具合起票フォームの整備）から。データがなければ何も分析できない

14の手法をすべて使いこなす必要はありません。まずはパレート図を1枚描くことから始めてください。自分たちの不具合がどこに集中しているのかを数字で見た瞬間、次に何をすべきかは自ずと見えてきます。

次に読むならこの記事

• Vモデルで見る品質保証の流れ
• テスト観点の洗い出し手順｜観点表と抜け漏れ防止
• 負荷テストとは？目的・種類・やり方を全体像で解説

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する