2026年5月28日
QC7つ道具について(基礎編)【1/3】
システムテスト 2026年6月4日
#システムテスト#テスト手法#テスト観点
はじめに
ソフトウェア開発の現場では、アジャイル開発やDevOpsの普及、リリースサイクルの短縮、システムの複雑化などにより、テスト工程に求められる役割は年々大きく、かつ難しくなっています。「早くリリースしたい」「品質は落とせない」という相反する要求の中で、テストに関わる現場では、日々さまざまな問題や判断に直面しています。
その一方で、テスト現場では次のような状況が繰り返し見られます。
- 不具合が多いことは分かっているが、「何が問題なのかを言葉で説明できない」
- 改善活動を行っても、「なぜそれをやっているのかが共有されず、形骸化してしまう」
- 作業者と管理者の間で、「問題の捉え方や優先度が噛み合わない」
- 振り返りをしても、「感覚的な意見や個人の経験にとどまってしまう」
こうした課題は単にテスト技術やツールの不足によって生じているのではありません。
むしろ多くの場合、「問題をどう理解し、どう整理し、どう共有するか」という品質管理（QC）の視点が欠けていることに原因があります。
QCの本来の目的は、単に数値を管理したり、結果を評価したりすることではありません。
- 問題の状況を「客観的に把握する」
- 問題の構造や原因を「分かりやすく整理する」
- チーム内で「同じ問題を同じ見方で理解できる状態をつくる」
つまりQCとは、問題について「話せる状態」「合意できる状態」をつくるための考え方と道具だと言えます。
QC7つ道具・新QC7つ道具は、そのための具体的な手段です。チェックシートやグラフは現状を事実として示し、親和図や特性要因図は、複雑な問題を構造として可視化します。これらの図やデータがあることで、作業者は「自分の感覚」ではなく「事実」をもとに考えることができ、管理者は現場の状況を具体的に理解し、判断や意思決定につなげることができます。
このようにQCは、作業者と管理者のどちらか一方のためのものではありません。
現場で手を動かす作業者にとっては、
- 「問題を整理し、改善の方向性を考えるための助け」
となり、管理者にとっては、
- 「現場の状況を正しく理解し、優先順位や方針を決めるための共通言語」
となります。
本記事では、こうしたQCの目的を踏まえ、QCストーリーに沿って話を進めていきます。
QCストーリーとは、問題の認識から始まり、現状把握、原因分析、対策立案、効果確認、標準化へと至る一連の流れです。
この流れの中で、 QC7つ道具・新QC7つ道具が
- どの場面で
- 何のために使われ
- どのように問題理解や共通認識づくりに役立つのか
を、ソフトウェアテストの具体例とともに説明していきます。
QC7つ道具・新QC7つ道具は、特別な専門家だけが使うものではありません。
むしろ、問題はあるが、うまく説明できない、認識が人によってバラバラになっていると感じたときにこそ、力を発揮します。
この記事を通して、QCを「品質を管理するための難しい理論」ではなく、「問題を理解し、チームで同じ方向を向くための実践的な道具」として捉えてもらい、問題解決に対しての頼れる味方だ、と感じてもらえれば幸いです。
QCストーリーとは？
主題であるQC7つ道具・新QC7つ道具を理解するうえで、まず押さえておきたいのがQCストーリーという考え方です。QCストーリーをより実践的に説明するなら、
問題を「気づき」から「定着した改善」まで導くための道筋
と言えます。具体的にいえば、品質に関する問題を場当たり的に解決するのではなく、一定の順序と論理に沿って解決へ導くための進め方を示したものです。
一般的なQCストーリーは、次の7つのステップで構成されます。
- 問題の明確化
- 現状把握
- 目標設定
- 要因解析
- 対策立案・実施
- 効果確認
- 標準化・定着
この流れは一見すると当たり前に見えるかもしれませんが、実際のソフトウェアテストの現場では、この順序が崩れたまま改善活動が行われているケースが少なくありません。
たとえば、
- 現状を十分に把握しないまま対策を考えてしまう
- 原因を深掘りせず、「とりあえずテストを増やす」
- 効果確認をしないまま次の案件に進んでしまう
といった経験がある方も多いのではないでしょうか。
QCストーリーの価値は、こうした「飛ばしがち」「省略しがち」な部分を、あえて順番どおりに進めることにあります。
QCストーリーは「管理のため」ではなく「理解のため」のもの
QCという言葉から、「管理者向け」「報告資料向け」という印象を持つ方もいるかもしれません。しかし、QCストーリーの本質は管理そのものではなく、問題を正しく理解することにあります。
QCストーリーの各ステップは、次の問いに対応しています。
| そもそも、何が問題なのか | ⇔ | 問題の明確化 |
| 今、実際にどうなっているのか | ⇔ | 現状把握 |
| どこまで改善したいのか | ⇔ | 目標設定 |
| なぜその問題が起きているのか | ⇔ | 要因解析 |
| 何をすればよさそうか | ⇔ | 対策立案・実施 |
| 本当に良くなったのか | ⇔ | 効果確認 |
| どうすれば同じ問題を繰り返さないか | ⇔ | 標準化・定着 |
これらの問いは、作業者が日々感じている疑問そのものであり、同時に管理者が判断に必要とする情報でもあります。
QCストーリーに沿って考えることで、作業者は
- 感覚や経験を「説明できる形」に整理できる
管理者は
- 現場の状況を具体的に理解し、納得感をもって判断できる
という関係が生まれます。
ソフトウェアテストとQCストーリーの相性
QCストーリーはもともと製造業で発展してきた考え方ですが、ソフトウェアテストの現場とは非常に相性がよい特徴を持っています。
その理由のひとつは、テスト工程が
- 不具合件数
- 不具合種別
- 発生工程・検出工程
- 作業時間
といったデータを比較的取りやすい工程であることです。
QCストーリーでは、「なんとなく多い」「減った気がする」といった曖昧な表現ではなく、事実としてのデータをもとに現状を捉えることが重視されます。これは、不具合管理ツールやテスト管理ツールを日常的に使っているテスト現場にとって、大きなハードルにはなりません。
もうひとつの理由は、テスト工程がしばしば、要件、設計、実装といった上流工程の影響を強く受ける点にあります。不具合の原因は、必ずしも「テストが悪い」ことにあるとは限りません。QCストーリーに沿って要因を整理することで、問題を個人や工程に押し付けるのではなく、全体の構造として捉えることができます。
QCストーリーとQC7つ道具・新QC7つ道具の関係
QCストーリーは「進め方」を示すものですが、それだけでは具体的な作業には落とし込めません。そこで使われるのが、QC7つ道具・新QC7つ道具です。
QC7つ道具・新QC7つ道具は、それぞれ
- 現状を数値や分布として示す
- 問題や原因を構造として整理する
- 対策の妥当性や効果を確認する
といった役割を持っています。
重要なのは、どの道具を使うかよりも、「QCストーリーのどの段階で使うか」です。
同じパレート図や特性要因図でも、
- 何を明らかにしたいのか
- どの段階の議論なのか
が曖昧なまま使ってしまうと、単なる図表作成で終わってしまいます。
本記事では、この後の章で、QCストーリーの各ステップごとに
- どのQC7つ道具・新QC7つ道具が活躍するのか
- それが作業者・管理者それぞれにとって何を助けるのか
を、ソフトウェアテストの具体例と図解を用いて説明していきます。
次の章では、まず全体像を把握するために、QC7つ道具・新QC7つ道具の一覧と、それぞれがどのような役割を持つのかを整理していきます。
QC７つ道具と新QC７つ道具
ここでは、QCストーリーを実現していくための道具である、QC7つ道具と新QC7つ道具について紹介していきます。この部分では、QC7つ道具と新QC7つ道具の定義や意味、そして、それぞれの道具について簡単な表にまとめられています。次章のQCストーリーの実現をステップごとに紹介する部分を読むための、ある程度の前提として確認してみてください。
【表1】QC7つ道具vs新QC7つ道具
| 比較項目 | QC7つ道具 | 新QC7つ道具 |
|---|---|---|
| データの種類 | 数値データ（定量） | 言語データ（定性） |
| アプローチ | 分析（過去・現状を見る） | 設計・計画（未来・構造を見る） |
| 主な目的 | 問題の分析、品質管理 | 問題の整理、課題解決、計画策定 |
| 活用イメージ | データから事実を読み取る | アイデアをまとめて形にする |
【表2】QC7つ道具
| 道具名 | 簡単な説明 | ソフトウェアテストで役立つ場面 |
|---|---|---|
| グラフ | データを図示して、全体の傾向を一目で分かるようにする。 | ・バグの発生推移を見る ・モジュールごとのバグ数を比べる |
| パレート図 | 頻度の高い順に並べて、「どこを優先すべきか」を見つける。 | ・最も多いバグの原因を特定する ・修正の優先順位を決める |
| ヒストグラム | データの「ばらつき」の分布を見る。 | ・レスポンスタイムの分布を見る ・データの偏りを確認する |
| 散布図 | 2つのデータの関係性（相関）を見る。 | ・複雑度とバグ数の関係を調べる ・テスト工数と品質の関係を見る |
| 管理図 | 時系列データに境界線を入れ、工程が安定しているか見る。 | ・ビルド失敗率の異常検知 ・システム稼働率の監視 |
| 特性要因図 | 結果に対して、どのような原因が影響しているかを、魚の骨のような形で体系的に整理した図。 | ・バグの根本原因を洗い出す ・品質低下の要因を深掘りする |
| チェックシート | 点検項目の確認や、データの記録を行う。 | ・リリース前の最終確認 ・テスト実施結果の簡易記録 |
【表3】新QC7つ道具
| 道具名 | 簡単な説明 | ソフトウェアテストで役立つ場面 |
|---|---|---|
| 親和図法 | バラバラの意見やアイデアを、グループにまとめて整理する。 | ・テスト方針のアイデア出し ・現場の課題を整理する |
| 連関図法 | 原因と結果を矢印で結び、複雑な因果関係を明らかにする。 | ・「なぜバグが減らないか」の構造分析 ・複合的なトラブルの原因特定 |
| 系統図法 | 目的を手段へ、さらに細かい手段へとツリー状に展開する。 | ・品質目標を具体的なタスクに落とし込む ・テスト観点の漏れを防ぐ |
| マトリックス図法 | 行と列の交点で、要素間の関係の有無を表示する。 | ・要求とテストケースの対応付け（網羅性確認） ・担当者とスキルの管理 |
| アローダイアグラム法 | 作業の流れを矢印で結び、日程計画や最短経路を明確にする。 | ・大規模テストのスケジュール作成 ・タスクの順序関係の整理 |
| PDPC法 | 事前に様々なリスクを想定し、代替案を準備しておく。 | ・リリーストラブル時の対応フロー作成 ・不測の事態への備え |
| マトリックスデータ解析法 | 多くの数値データを解析図にし、位置付けを視覚化する。（唯一の定量的手法） | ・テストツールの選定・比較 ・製品のポジショニング分析 |
次に
今回の記事では、なぜソフトウェアテストにQCが必要なのか、そして、QC7つ道具と新QC7つ道具についての簡単な説明を取り上げました。
記事内でも触れたように、QCとは、問題について「話せる状態」「合意できる状態」をつくるための考え方です。
これらについて理解できれば、テスト工程でチーム一丸となってプロジェクトに取り組むことができるようになりますし、ソフトウェア開発全体の問題点にも気がつけるようになります。
次回の記事では、QCストーリー上で、問題を分析し、その原因を突き止めていくステップを取り上げ、そこで活躍するQC7つ道具と新QC7つ道具について紹介していきます。
この記事を書いた人
GENZ マーケティンググループ MB
ソフトウェアテスト・品質保証の専門集団「GENZ」のマーケティングチームのTMです。
企業文化や最新トピック、システムテストのノウハウ、品質改善の事例など、開発・テスト現場に役立つ情報を発信中。
「品質×マーケティング」で、読者とGENZの架け橋となるコンテンツをお届けします。
