シックスシグマDMAICの進め方｜各フェーズの成果物とゲート管理

品質改善プロジェクトを立ち上げたものの、「現状把握をしないまま対策に飛びついてしまう」「途中でゴールが曖昧になり、いつのまにか自然消滅する」——そんな経験はないでしょうか。シックスシグマのDMAICは、こうした失敗を防ぐために設計された、5つのフェーズからなる構造化された改善プロセスです。

DMAICの強みは、各フェーズに「何を作るべきか（成果物）」と「次に進んでよいか（ゲート審査）」が明確に定義されている点にあります。思いつきの対策ではなく、データに基づいて段階的に意思決定する規律が、プロジェクトの成功率を大きく左右します。本記事では、DMAICの各フェーズの進め方、フェーズごとの成果物、そしてトールゲート（ゲート審査）による進捗管理の方法を、品質改善担当者が現場で運用できる形で解説します。

DMAICのAnalyze（分析）フェーズで、根本原因の特定に手こずっていませんか？

WhyTrace Plus は、なぜなぜ分析とFTAをAIが支援する根本原因分析プラットフォームです。DMAICの分析フェーズで洗い出した要因を、AIが対話形式で深掘りし、因果関係をツリー図で可視化します。

---

1. シックスシグマとDMAICとは

シックスシグマとは、プロセスのばらつきを統計的に低減し、欠陥の発生率を100万機会あたり3.4個（3.4 DPMO）以下に抑えることを目指す品質管理・経営改革の方法論である。DMAICは、そのシックスシグマを実践するための中核となる5段階の改善プロセスを指す。

シックスシグマの「6σ（シグマ）」は、品質のばらつきを表す統計用語に由来します。年間100万個を生産する工程を想定すると、3σレベルでは約2,700個の不良が発生するのに対し、6σレベルではわずか3〜4個にまで抑えられるとされます（2026年時点。出典：現場改善ラボ シックスシグマとは、Koto Online シックスシグマとは）。この圧倒的な品質水準を、勘や経験ではなくデータドリブンで達成するための手順がDMAICです。

DMAICは、以下の5フェーズの頭文字をとった略語です。

フェーズ	英語	日本語	主な目的
D	Define	定義	問題・目標・スコープを明確にする
M	Measure	測定	現状をデータで把握する
A	Analyze	分析	根本原因を特定する
I	Improve	改善	対策を立案・実施する
C	Control	管理	改善を定着させる

DMAICが「定義」から始まる点が、思いつきの改善活動との決定的な違いです。「何が問題で、どこまで改善するのか」を最初に固めることで、プロジェクトが途中で迷走するのを防ぎます。

QCストーリーとの違い

日本の製造現場で馴染みのあるQCストーリーと、DMAICは構造がよく似ています。どちらも「テーマ選定→現状把握→要因解析→対策→効果確認→標準化」という流れを持ちます。

大きな違いは2点あります。第一に、DMAICは統計的手法（工程能力指数、仮説検定、回帰分析など）の活用を前提とし、データによる客観的判断を重視します。第二に、各フェーズの区切りに「トールゲート」と呼ばれるゲート審査を設け、スポンサーが続行可否を正式に判断する点です。QCストーリーが現場の自主的な改善活動として運用されることが多いのに対し、DMAICはプロジェクトとしての管理が組み込まれています。

なお、複数の改善手法のなかからどれを選ぶべきかで迷う場合は、問題解決手法の選び方もあわせて参照してください。本記事はDMAICを単独で運用する際の進め方に絞って解説します。

---

2. Define（定義）フェーズの進め方と成果物

Define（定義）フェーズとは、改善プロジェクトで取り組む問題・目標・対象範囲を明確に定義し、関係者の合意を得る最初の段階である。ここでの定義の質が、プロジェクト全体の方向性を決定づける。

このフェーズで陥りやすいのが、問題が漠然としたまま測定に進んでしまうことです。「不良を減らす」ではなく、「A工程の○○不良を現状の月50件から月10件以下に、6ヶ月で削減する」というレベルまで具体化する必要があります。

主な成果物

成果物	内容
プロジェクト憲章	問題記述・目標・スコープ・期間・体制・期待効果を1枚にまとめた文書
SIPOC図	供給者・入力・プロセス・出力・顧客の全体像を整理した図
VOC（顧客の声）	顧客が品質に対して何を求めているかの整理
CTQ（重要品質特性）	VOCを測定可能な品質指標に変換したもの

プロジェクト憲章は、Define フェーズの中心的な成果物です。問題記述では「いつ・どこで・何が・どの程度起きているか」を数値で示し、感情的・主観的な表現を排除します。目標は「SMART（具体的・測定可能・達成可能・関連性・期限）」の原則で設定します。

Define フェーズのゲート審査ポイント

トールゲートでは、スポンサーが以下を確認します。

• 問題が事実とデータに基づいて記述されているか
• 目標がCTQ（重要品質特性）と結びついているか
• スコープが現実的で、解決可能な範囲に絞られているか
• プロジェクト体制とリソースが確保されているか

ここで「問題の定義が曖昧」と判断されれば、Measure には進めません。

---

3. Measure（測定）フェーズの進め方と成果物

Measure（測定）フェーズとは、定義した問題の現状を信頼できるデータで定量的に把握し、ベースライン（基準値）を確立する段階である。「測れないものは改善できない」というシックスシグマの基本姿勢が、最も色濃く表れるフェーズだ。

ここで重要なのは、データそのものの信頼性を確認することです。測定方法がばらついていれば、その後の分析はすべて砂上の楼閣になります。

主な成果物

成果物	内容
データ収集計画	何を・どこで・どう測るかの計画
測定システム分析（MSA）	測定器・測定方法のばらつきを評価（Gage R&R等）
プロセスマップ（詳細）	工程の各ステップと入出力を詳細化
ベースライン工程能力	現状の工程能力指数（Cp・Cpk）やDPMO・シグマレベル

ベースラインの工程能力を数値化することが、このフェーズのゴールです。改善前のシグマレベルやDPMO（100万機会あたりの欠陥数）を記録しておくことで、改善後にどれだけ効果があったかを定量的に示せます。

Measure フェーズのゲート審査ポイント

• データが計画どおりに、十分な量・期間で収集されているか
• 測定システムが信頼できる（測定のばらつきが許容範囲内）か
• 現状のベースライン（シグマレベル・Cpk等）が確立されているか
• データから「どこに問題が集中しているか」の初期的な絞り込みができているか

測定システム分析を省略すると、後で「そもそも測り方が間違っていた」という致命的な手戻りが発生します。Measure フェーズのゲートは、この落とし穴を防ぐ関門です。

---

4. Analyze（分析）フェーズの進め方と成果物

Analyze（分析）フェーズとは、測定で得たデータをもとに、問題を引き起こしている根本原因を統計的・論理的に特定する段階である。表面的な要因ではなく、真の原因（root cause）にたどり着くことがこのフェーズの使命だ。

このフェーズでは「思い込みで原因を決めつけない」ことが何より重要です。「たぶんこれが原因だろう」という仮説を立て、データで検証するというサイクルを回します。

主な成果物

成果物	内容
要因リスト	考えられる要因を洗い出したもの（特性要因図・4M等）
根本原因分析	なぜなぜ分析・FTA等による深掘り結果
仮説検定の結果	統計的手法（t検定・分散分析・回帰分析等）による検証
検証済み根本原因	データで裏付けられた真の原因

Analyze フェーズの典型的な流れは、(1) 特性要因図（フィッシュボーン図）や4M（人・機械・材料・方法）で要因を網羅的に洗い出し、(2) なぜなぜ分析で各要因を深掘りして根本原因の候補を絞り、(3) 統計的手法でその因果関係をデータで検証する、という3段階です。

ここでのつまずきは、「要因の洗い出しが浅い」ことと「検証せずに対策へ飛ぶ」ことの2つに集約されます。前者は特性要因図やなぜなぜ分析の使い方の問題、後者はゲート審査で歯止めをかけるべきポイントです。

なぜなぜ分析をAIで体験してみよう

DMAICのAnalyzeフェーズで核心となるのが、要因をデータで検証する前段階の「根本原因の深掘り」です。ここでAIによるなぜなぜ分析を体験してみましょう。事象を入力するだけで、AIが自動的に「なぜ？」を掘り下げ、原因の候補を構造化します。

Analyze フェーズのゲート審査ポイント

• 要因が網羅的に洗い出されているか（特定の人の経験だけに偏っていないか）
• 根本原因がデータ・統計で裏付けられているか（思い込みではないか）
• 検証された根本原因が、Improve フェーズで対策可能なものか
• 根本原因とCTQ（重要品質特性）の関係が論理的に説明できるか

「データで裏付けられていない原因」を根本原因として認めないことが、このゲートの役割です。ここを甘くすると、Improve フェーズで的外れな対策に時間を浪費します。

---

5. Improve（改善）フェーズの進め方と成果物

Improve（改善）フェーズとは、特定した根本原因を取り除く、または影響を最小化するための具体的な対策を立案・検証・実施する段階である。アイデアを出すだけでなく、その効果を小規模に検証してから本格展開する点が特徴だ。

このフェーズでありがちなのが、複数の対策を一度に投入してしまい、「結局どれが効いたのか分からない」という事態です。可能な限り、対策の効果を切り分けて検証します。

主な成果物

成果物	内容
対策案リスト	根本原因に対応する複数の改善案
対策の優先順位付け	効果・コスト・実現性での評価（PICKチャート等）
パイロット検証結果	小規模試行での効果データ
改善後の工程能力	対策実施後のシグマレベル・Cpk・DPMO

対策は「発生防止」を優先します。検出を強化するだけの対策（検査の追加など）は、根本的な改善にはなりにくいためです。立案した対策はいきなり全面展開せず、パイロット（小規模試行）で効果を確認してから本格導入するのがシックスシグマの定石です。

Improve フェーズのゲート審査ポイント

• 対策が根本原因に直接対応しているか
• パイロット検証で、目標とする効果がデータで確認できたか
• 対策実施後の工程能力が、Define で設定した目標を満たしているか
• 副作用やリスク（他工程への悪影響等）が評価されているか

「効果がデータで証明されているか」が、このゲートの核心です。

---

6. Control（管理）フェーズの進め方と成果物

Control（管理）フェーズとは、改善で得た成果が時間とともに元に戻らないよう、標準化・監視の仕組みを整え、改善を定着させる最終段階である。多くの改善活動が「やった直後は良かったが半年後に元通り」になるのを防ぐのが、このフェーズの存在意義だ。

改善は実施して終わりではありません。新しいやり方が現場に根づき、継続的に維持される状態を作って初めてプロジェクトは完了します。

主な成果物

成果物	内容
管理計画（コントロールプラン）	何を・どう監視し、異常時に誰がどう対応するか
標準作業手順書（SOP）	改善後の作業を標準化した文書
管理図	工程を継続監視する統計的管理図（SPC）
効果の最終報告	財務効果を含むプロジェクト成果のまとめ
プロジェクト完了報告・引き継ぎ	現場オーナーへの移管

管理図（SPC：統計的工程管理）で工程を継続監視し、ばらつきが管理限界を超えたらすぐに対応する仕組みを組み込みます。また、改善内容を標準作業手順書に落とし込み、担当者が変わっても維持できる状態にします。

Control フェーズのゲート審査ポイント

• 改善効果が一定期間、安定して維持されているか
• 管理図・監視の仕組みが稼働しているか
• 標準作業手順書が整備され、現場に周知されているか
• プロジェクトが現場オーナーに正式に引き継がれたか
• 得られた知見が他工程・他部門に展開可能な形で記録されているか

Control フェーズのゲートを通過して、ようやくDMAICプロジェクトは完了します。

---

7. トールゲート（ゲート審査）の運用ポイント

トールゲートとは、DMAICの各フェーズの区切りで、スポンサーや関係者がプロジェクトの進捗と成果物を確認し、次フェーズへ進むかどうかを正式に判断するゲート審査である。「料金所（tollgate）」になぞらえ、基準を満たさなければ先に進めない関門として機能する。

トールゲートは通常、各フェーズの終わりに実施され、1回あたり30分〜1時間程度で行われます。推進者（ブラックベルト等）が成果物と達成状況を提示し、スポンサーやチャンピオンが続行（Go）・中止（No-Go）・追加対応の判断を下します（2026年時点。出典：Six Sigma Study Guide DMAIC Tollgate Reviews、GoLeanSixSigma Tollgate Review）。

トールゲートを機能させる3つのポイント

1. 判断基準を事前に明文化する

「何が達成できていれば次に進めるのか」をフェーズごとに明文化しておきます。基準が曖昧だと、審査が形骸化し「とりあえず次へ」となりがちです。

2. No-Go（中止・差し戻し）を正当な選択肢として扱う

トールゲートの価値は、見込みのないプロジェクトを早期に止められる点にあります。「ここまで進めたから」という理由で続行する判断（サンクコストの罠）を避けるためにも、No-Goを恥ずかしいことだと捉えない文化が必要です。

3. データに基づいて議論する

トールゲートは報告会ではなく意思決定の場です。「がんばりました」ではなく「ベースラインが○○から○○に改善した」というデータで議論します。

フェーズ	ゲートで問う核心的な質問
Define	問題と目標は具体的に定義されているか
Measure	現状はデータで正確に把握できているか
Analyze	根本原因はデータで裏付けられているか
Improve	対策の効果はデータで証明されたか
Control	改善は安定して維持される仕組みがあるか

---

よくある質問（FAQ）

Q. DMAICとPDCAは何が違いますか？

PDCAは「計画・実行・評価・改善」を回す汎用的な改善サイクルで、適用範囲が広く軽量です。DMAICは品質改善プロジェクトに特化し、各フェーズで統計的手法の活用とゲート審査を前提とする、より厳密で構造化された手法です。日常的な小さな改善はPDCA、原因が複雑でデータ分析が必要な問題はDMAICが適しています。

Q. 中小企業でもDMAICは導入できますか？

導入できます。専門資格（ブラックベルト等）を持つ人材がいなくても、DMAICの「定義→測定→分析→改善→管理」という思考の型と、各フェーズで成果物を作りゲートで確認する規律は、規模を問わず有効です。最初はスコープの小さいテーマで、統計手法も基本的なもの（パレート図、工程能力指数など）から始めるとよいでしょう。

Q. トールゲートは必ず5回行う必要がありますか？

各フェーズの区切りに1回ずつ、計5回が基本です。ただしプロジェクトの規模や複雑さに応じて、フェーズ内で複数回の中間レビューを設けることもあります。重要なのは回数ではなく、「次フェーズに進む前に、成果物と判断基準を関係者で確認する」という規律を維持することです。

Q. Analyzeフェーズで統計手法が難しい場合はどうすればよいですか？

まずは特性要因図やなぜなぜ分析といった定性的な手法で根本原因の候補を絞り込み、その上で検証可能なものをデータで確認するアプローチが現実的です。高度な仮説検定が難しい場合でも、パレート図や層別、相関の確認といった基本的なデータ分析だけでも、根本原因の特定精度は大きく向上します。

---

まとめ

本記事では、シックスシグマDMAICの5フェーズの進め方、各フェーズの成果物、そしてトールゲートによる進捗管理を解説しました。

1. Define（定義）: プロジェクト憲章・CTQで問題と目標を具体化する。
2. Measure（測定）: 測定システムを検証し、ベースラインの工程能力を確立する。
3. Analyze（分析）: 要因を洗い出し、根本原因をデータで裏付ける。
4. Improve（改善）: 対策をパイロット検証してから本格展開する。
5. Control（管理）: 管理図・標準化で改善を定着させる。

DMAICの本質は、「各フェーズに明確な成果物がある」ことと「トールゲートでデータに基づき続行可否を判断する」という2つの規律にあります。思いつきの対策で迷走するプロジェクトを、データドリブンの構造化された改善へと変える——それがDMAICの価値です。

なかでもAnalyze（分析）フェーズの根本原因特定は、プロジェクトの成否を分ける最重要工程です。要因の深掘りをExcelの横並び表ではなくAIとツリー図で可視化したい場合は、WhyTrace Plusをぜひお試しください。なぜなぜ分析・FTA・対策管理を一体で運用でき、分析ナレッジを組織全体で蓄積できます。

WhyTrace Plusを無料で試してみる → whytrace.com

---

Sources:

• シックスシグマ（6σ）とは？ – 現場改善ラボ
• シックスシグマ（6σ）とは？統計分析を用いた経営・品質管理手法 – Koto Online
• DMAIC Tollgate Reviews – Six Sigma Study Guide
• Tollgate Review Definition: Lean Six Sigma – GoLeanSixSigma

---

関連サービス

原因分析・品質改善の知見を広げるために、姉妹サービスの関連記事もご活用ください。

• なぜなぜ分析の完全ガイド（GenbaCompass）
• QC7つ道具とナレッジ管理（know-howAI）
• なぜなぜ分析の知見をナレッジベースに蓄積（know-howAI）