QC7つ道具について（総集編）

はじめに

　ソフトウェア開発の現場では、アジャイル開発や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つ道具の一覧と、それぞれがどのような役割を持つのかを整理していきます。

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ストーリーの7つのステップに沿って、各段階でどの道具がどのように役立つのかを、ソフトウェアテストの現場を想定しながら丁寧に説明していきます。

1. 問題の明確化

活躍する道具：親和図法（新QC7つ道具）

このステップで何をするのか

　QCストーリーの出発点は、「問題がある」という漠然とした認識を、扱える形の問題に変えることです。
ソフトウェアテストの現場では、

といった声が上がることは珍しくありません。しかし、これらはまだ「問題の兆候」にすぎず、そのままでは改善活動のテーマとしては曖昧です。
このステップでは、まず現場で感じていること・起きていることを制限なく出し切ることが重要になります。

親和図法が活躍する理由

親和図法は、こうしたバラバラな情報を「意味の近さ」でまとめる手法です。
因果関係や正しさを考える前に、

を整理することに集中します。 この作業を通じて、「不具合が多い」という一言の裏に

といった異なる性質の問題が混在していることが見えてきます。

作業者の視点

管理者の視点

2. 現状把握

活躍する道具：チェックシート／グラフ／ヒストグラム（QC7つ道具）

このステップで何をするのか

問題の方向性が見えてきたら、次に行うのが現状把握です。ここでは、「本当にその問題は起きているのか」「どの程度なのか」を、事実と数字で確認します。
現状把握が不十分なまま次に進むと、「思い込み」や「一部の印象」に引きずられた改善になりがちです。

チェックシートの役割

チェックシートは、後で分析できる形でデータを集めるための土台です。
不具合を記録する際に、

といった項目をあらかじめ決めておくことで、集計や分析が可能になります。

グラフ・ヒストグラムの役割

グラフは変化や差を直感的に捉えるために、ヒストグラムは分布やばらつきを捉えるために使います。

といった点を、誰が見ても同じ解釈ができる形で示すことができます。

例えば、このグラフでは、テストが本格化した日付から検出数(青線)が急激に増加していますが、時間がたってバグが出尽くすと、件数が収束していきます。一方で、修正完了数は、検出数に少し遅れますが、しっかりと検出されたバグを修正できており、グラフの後半では、こちらも収束していっていることが読み取れます。

上のヒストグラムは、APIレスポンスタイムの分布図を表しています。このヒストグラムをみると、ほとんどが速い応答（左側）だが、一部だけ極端に遅い（右側に長く伸びるロングテール）様子が読み取れます。

■ 作業者の視点

■ 管理者の視点

3. 目標設定

活躍する道具：パレート図（QC7つ道具）

このステップで何をするのか

現状を把握すると、改善したい点が多数見えてきます。しかし、すべてに同時に取り組むことはできません。
このステップでは、改善の焦点を定めることが目的です。

パレート図が果たす役割

パレート図は、「重要な少数」に注目するための道具です。
不具合種別や原因別に件数を並べることで、

が明確になります。
目標設定の段階でパレート図を使うことで、「何となく重要そう」ではなく、データに基づいた目標を設定できます。

上のパレート図は不具合原因別に件数を表したものです。このパレート図をみると、累積比率が80％を超える、2つの項目、コーディングミスと仕様考慮漏れに対策をとるべきだということがわかります。

■ 作業者の視点

■ 管理者の視点

4. 要因解析

活躍する道具：特性要因図／散布図／連関図法

このステップで何をするのか

目標が定まったら、次はなぜその問題が起きているのかを考えます。
ここで重要なのは、安易に結論を出さないことです。

特性要因図

特性要因図は、問題を「人・プロセス・成果物・環境」などの切り口で分解し、考えられる要因を網羅的に洗い出します。
　例えば、以下のような背景ストーリーを考えてみましょう。リリース直後に、決済画面でエラーが発生しました。担当者は「確認したはず」と言っていますが、責めるだけでは再発します。一見すると「テストケースの不足」という問題に思えますが、本当にテストケースの不足だけが問題なのでしょうか。
　このようなときには、特性要因図が役立ちます。特定のバグがなぜ発生し、なぜ検出されなかったのかを、「個人のミス」で終わらせず、プロセスや環境を含めた「構造的な弱点」として洗い出すのに最適だからです。今回は特性要因図を作るにあたって、要因を「人・プロセス・技術・環境」の4つの視点で洗い出すことにしました。

このようにして、問題を「人・プロセス・成果物・環境」などの切り口で分解し、考えられる要因を網羅的に洗い出していくと、「テストケースの不足」という問題だけではなく、「有識者の不在」や、「仕様書の更新漏れ」といった問題があることも確認することができるようになります。

散布図

散布図は、2つの要素の関係性を確認するために使います。相関が見られれば、有力な要因候補になります。
例えば、次のような背景ストーリーを考えてみましょう。開発チームとテストチームの間で、「どの機能を重点的にテストするか」の議論になりました。テストチームは「複雑なスパゲッティコードになっている機能こそ危ない」と主張し、それを裏付けるために過去のデータを分析しました。過去のデータから、以下のような散布図を作成できたとします。

この散布図をみると、コードの複雑さを表すサイクロマティック複雑度と検出バグ数が正の相関をもっていることがわかります。このことから、コードが複雑な部分には今後検出されるバグが多く潜んでいる、と考えることができ、重点的に検証するべき機能の選定に役立てることができます。

連関図法

連関図法は、要因同士の影響関係を整理し、より根本に近い要因を見つける助けになります。
例えば、
バグの原因を掘り下げてみたとき、「時間がなかったから」に行き着きがちですが、そもそも「なぜ時間がないのか」を探ると、「仕様変更が多い」「決定が遅い」など、複数の要因が絡み合っています。この「悪循環」を可視化するには連関図法が役立ちます。

上のように、連関図法で原因をかきだしていくと、多くの問題が、「要件定義の詰めが甘い」という問題から発生していることがわかります。また、「テスト実行期間の圧迫」「テスト設計・レビューの省略」「テスト中の手戻り多発」という悪循環から抜け出すには、やはり、「要件定義の詰めが甘い」という問題を解決しなければならなくなるということがわかります。

■ 作業者の視点

■ 管理者の視点

5. 対策立案・実施

活躍する道具：系統図／マトリックス図／PDPC法／アロー・ダイアグラム

このステップで何をするのか

要因解析で「真の原因」を突き止めたら、次はいよいよ「どう解決するか」を具体化し、実行に移すフェーズです。
アイデアレベルの対策を、明日から誰が何をすべきか迷わないレベルの「行動計画」にまで落とし込むために、新QC7つ道具の設計・計画力が役立ちます。
これらを活用することで、「会議で良い案は出たが、結局誰も動かず立ち消えになった」という”改善活動あるある”を防ぐことができます。

系統図：方針を具体的な行動に分解

漠然とした改善目標を、段階的に「目的」から「手段」へと展開し、具体的なアクションプラン（ToDo）まで落とし込みます。最終的に、「誰がいつ実行できるか」というレベルのタスクになるまで掘り下げるのがポイントです。

マトリックス図：対策の効果範囲を整理

　2つの要素を行と列に配置し、その交点に記号（◎、○、△など）を入れて、関係の有無や強さを一目で分かるようにします。
　対策案がたくさん出たとき、すべての対策を全力で行うリソースはありません。
「対策案 ×
効果・コスト」のマトリックスを作れば、「コストは低いのに効果が高い（＝コスパが良い）」対策がどれか一目瞭然になり、優先順位を論理的に決定できます。
また、「タスク ×
担当者」のマトリックスにすれば、誰がメイン担当で、誰がサポートなのかという役割分担（RACIチャートのようなもの）を明確にできます。

対策案	効果の大きさ	即効性	コストの低さ	実現のしやすさ	合計点	優先順位
自動テストの導入（E2E）	◎	△	△	△	6	4
オフショア開発の活用	◎	〇	〇	△	8	3
ペアテストの実施	〇	◎	△	◎	9	2
チェックリストの刷新	〇	◎	◎	◎	11	1
単体テストの強化	◎	△	〇	〇	8	3

この表では、◎＝3点、〇＝2点、△＝1点としている

PDPC法：想定される問題と対応策を検討

　PDPC法(Process Decision Program
Chart)は、計画通りに進まない事態（トラブル）を事前に予測し、その時の対応策（プランB）をあらかじめフローチャートに組み込んでおく手法です。日本語では、プロセス決定計画図と言います。
　
大規模なリリース作業やデータ移行など、「失敗が許されない」場面で絶大な効果を発揮します。
「もし本番環境で予期せぬエラーが出たら？」「もし予定時刻を過ぎても完了しなかったら？」という最悪の事態をシミュレーションし、そこからの復旧手順や切り戻し（ロールバック）判断基準を事前に地図のように描いておくことで、当日のパニックを防ぐことができます。

アロー・ダイアグラム：作業計画を明確化

　アローダイアグラムでは、作業の順序関係と所要時間を矢印で結び、プロジェクト全体のスケジュールをネットワーク図にします。アローダイアグラムはPERT図とも呼ばれます。
　ガントチャートでは見えにくい「タスク同士の依存関係」を明確にします。
例えば、「A機能のテストが終わらないと、B機能のテストは始められない」といった前後関係をつなぐことで、「どの作業が遅れると、リリース日全体が遅れるのか（クリティカルパス）」を特定できます。
これにより、管理者はどのタスクを重点的に管理すべきかが明確になります。
次の図は結合テストを例にしたアローダイアグラムです。

■ 作業者の視点

系統図

マトリックス図

PDPC法

アロー・ダイアグラム

■ 管理者の視点

系統図

マトリックス図

PDPC法

アロー・ダイアグラム

6. 効果確認

活躍する道具：グラフ／ヒストグラム／散布図／マトリックスデータ解析法（新QC7つ道具）

このステップで何をするのか

効果確認のステップでは、立案・実施した対策が本当に狙いどおりの効果を生んだのかを、客観的に評価します。ここで重要なのは、「改善したはず」「現場の感触は良い」といった主観的な判断に留まらず、事実とデータで確認することです。
また、単に数値が改善したかどうかだけでなく、

を整理して把握することが、次の標準化・定着につながります。

グラフ・ヒストグラムによる変化の可視化

　まず基本となるのが、改善前後のデータを同じ条件で比較することです。グラフを用いることで、不具合件数や再発率がどう変化したか、工程ごとの負荷や作業時間がどう推移したか、といった時系列の変化を直感的に確認できます。
　一方、ヒストグラムは、不具合のばらつきが小さくなったか、特定のケースに偏りが残っていないか、といった分布の変化を捉えるのに有効です。単に平均値が改善しただけでなく、「安定してきたかどうか」を確認できる点が重要です。

散布図による関係性の再確認

　要因解析の段階で使用した散布図は、効果確認の場面でも役立ちます。対策実施後にあらためて散布図を作成することで、

を確認できます。
　これにより、対策が「結果として効いた」のか、それとも「一時的に数値が動いただけ」なのかを見極めることができます。

マトリックスデータ解析法で対策と効果を整理する

　効果確認の段階で特に有効なのが、マトリックスデータ解析法です。この手法は、複数の対策と複数の評価指標が存在する場合に、それぞれの関係性を整理し、全体像を把握するために用いられます。
　たとえば、行に「実施した対策」、列に「不具合件数」「レビュー指摘数」「手戻り工数」などの指標を配置し、各セルに数値や評価結果を整理します。
　これにより、

　といった点を、一覧性をもって確認できます。
例えば、以下のようにテスト改善のための施策を複数行い、以下のような指標を得られたとします。これらは単位がバラバラで一見すると、その効果をあわせて比較することは難しいように思えますが、このようなとき、マトリックスデータ解析法が役立ちます。

施策名	欠陥除去率向上(%)	テスト工数削減(%)	リリース後不具合減少(%)	手戻り削減効果(1-10点)
A. コードレビュー強化	20	-10	15	8
B. 単体テスト自動化	10	30	5	4
C. 結合テスト自動化	5	50	5	3
D. 仕様書インスペクション	30	-5	25	9
E. 探索的テスト導入	25	10	20	6

※テスト工数削減のマイナスはテスト工数が増えたことを表します

マトリックスデータ解析法を使うと、多くの指標を「2つの軸」に要約して、施策の特徴を一目で把握できます。

■ 横軸（Axis 1）：品質向上への寄与度

■ 縦軸（Axis 2）：効率化（時短）への寄与度

この図から、 「自動化（B,
C）は効率化には効くが、品質向上（欠陥除去）への直接的な寄与はレビュー系に劣る」
「インスペクション（D）は効率は下がるが、品質向上効果は最強である」
といった特徴が客観的に分かります。これにより、「次は品質を上げたいからDをやろう」といった意思決定が可能になります。

■ 作業者の視点

■管理者の視点

マトリックスデータ解析法を用いることで、効果確認が単なる「結果報告」ではなく、次の改善につながる分析の場になります。

効果確認でありがちな失敗と注意点

　効果確認のステップでは

といった失敗が起こりがちです。
QC7つ道具・新QC7つ道具を用いて整理することで、こうした偏りを防ぎ、誰が見ても納得できる評価につなげることができます。

7. 標準化・定着

活躍する道具：管理図

このステップで何をするのか

効果確認によって対策の有効性が確認できたら、そのやり方を一時的な改善で終わらせず、安定して続けられる形にすることが重要です。このステップでは、改善後の状態を「標準」として定着させ、再び問題が起きていないかを継続的に監視します。ここで活躍するのが管理図です。管理図は、工程や作業の状態を時系列で可視化し、異常と通常のばらつきを区別するための道具です。

管理図とは何か

管理図は、単なる折れ線グラフではありません。あらかじめ設定した管理限界線（上限・下限）をもとに、データが「安定した範囲内に収まっているか」「異常な変化が起きていないか」を判断します。
これにより、

といった、冷静な品質管理が可能になります。

ソフトウェアテストにおける管理図の具体例

たとえば、以下のような指標が管理図の対象になります。

次の管理図は「レビュー1件あたりの指摘数」を用いた管理図の例です。

　この管理図を読み解くと、多くの期間は赤線の中で不規則に動いており、「工程は安定している（対策が定着している）」と判断できます。
　しかし、第8週に上限（UCL）を超えた点があります。これは「何か異常が起きた（レビュー対象の品質が極端に悪い、あるいはレビュー基準が厳しすぎるなど）」というサインであり、すぐに原因調査が必要であることを示しています。

■ 作業者の視点

■ 管理者の視点

おわりに

　ソフトウェアの品質問題は複雑怪奇に見えますが、QCストーリーという道筋と、QC7つ道具・新QC7つ道具という武器があれば、必ず解決の糸口は見つかります。本記事では、問題の明確化から対策の定着まで、どのフェーズでどの道具を使えばよいかを具体的に解説してきました。
　重要なのは、これらの道具が「問題を可視化する（QC7つ道具）」力と、「思考を構造化する（新QC7つ道具）」力の両方を備えていることです。これにより、「不具合を減らす」という結果だけでなく、「なぜ起きたのか」「どう防ぐのか」というプロセス自体を論理的にデザインできるようになります。
　使い方は実践の中でこそ身につきます。まずは手元のデータをグラフにしたり、アイデアを親和図でまとめたりすることから始めてみてください。その一本の線、一つの図が、**迷いなく正しい判断を下すための「心強い味方」**となり、あなたのテスト活動を一段上のレベルへと引き上げてくれるはずです。

付録　迷ったときの「QC7つ道具」選び方チャート

「今の自分の状況」に当てはまるものを選んでみてください。それが、今のあなたを助けてくれる「最強の味方」です。

1. 「何が問題か」モヤモヤしているとき（入口）

心の声（困っていること）	おすすめの道具	期待できる効果
「不満や意見はたくさんあるけど、まとまらない…」	親和図法	バラバラな意見がグループ化され、 問題の全体像が見えてくる
「事実や数値を集めたいが、記録が面倒…」	チェックシート	誰でも簡単に記録でき、後で集計・分析しやすいデータが集まる

2. 「事実」をはっきりさせたいとき（現状把握・目標設定）

心の声（困っていること）	おすすめの道具	期待できる効果
「結局、不具合は増えているの？減っているの？」	グラフ	推移や変化が一目で分かり、チームで共通認識を持てる 3
「データのばらつきや、偏りを見たい」	ヒストグラム	平均値だけでは見えない、データの分布（異常な偏りなど）が見える
「あれもこれも問題だ…。どこから手を付けるべき？」	パレート図	「重要な少数」の問題が分かり、優先して取り組むべき対象が決まる

3. 「原因」を突き止めたいとき（要因解析）

心の声（困っていること）	おすすめの道具	期待できる効果
「思いつきではなく、漏れなく原因を洗い出したい」	特性要因図	「人・プロセス・環境」などの視点で、原因を構造的に整理できる
「この2つの事柄に、関係があるか確かめたい」	散布図	「コードが複雑だとバグが多い」などの相関関係を視覚的に証明できる
「原因が複雑に絡み合って、根本が見えない…」	連関図法	「原因と結果」を矢印でつなぐことで、悪循環の根本原因を発見できる

4. 「対策」を計画・実行するとき（対策立案）

心の声（困っていること）	おすすめの道具	期待できる効果
「目標はあるが、具体的なToDoまで落ちていない」	系統図法	目的を手段へ分解し、「誰がいつやるか」という行動計画まで落とせる
「対策案が多すぎる。どれが一番コスパが良い？」	マトリックス図法	「効果×コスト」などで比較し、優先順位や役割分担を決定できる
「絶対に失敗できない。もしものトラブルが怖い」	PDPC法	事前にリスクを予測し、プランB（代替案）を準備してパニックを防げる
「タスクの依存関係が複雑で、遅れが怖い」	アローダイアグラム	作業の順序と「クリティカルパス（遅延できない作業）」が明確になる

5. 「結果」を確かめ、維持したいとき（効果確認・定着）

心の声（困っていること）	おすすめの道具	期待できる効果
「複数の対策をやったが、どれが効いたか比較したい」	マトリックスデータ解析法	複数の指標を整理し、対策ごとの特徴（品質寄り・効率寄りなど）を分析できる
「改善した状態をキープしたい。異常をすぐ検知したい」	管理図	データの推移に境界線を引き、プロセスが安定しているかを常時監視できる

この記事をシェアする