DMAIC：Six Sigmaの5フェーズ改善法（ツールと実例付き）

ほとんどのプロセス問題は同じ方法で解決されます。誰かが欠陥に気づき、ミーティングが開かれ、修正が実施されます。数週間後に欠陥が戻ります。これは運が悪いわけではなく、実際に何が壊れているかを測定したり原因を確認したりする前に解決策に飛びついたときに起こることです。DMAICはあなたがプロセスに触れることが許可される前に、すべてのステップで厳密さを強制することでそのサイクルを断ち切ります。

DMAIC（「ドゥメイック」と発音）はSix Sigmaの中核をなす体系的な改善手法です。各文字は通過しなければならないゲートです。問題をDefine（定義）し、現状をMeasure（測定）し、根本原因をAnalyze（分析）し、検証済みの解決策でImprove（改善）し、成果が失われないようにControl（管理）する。フェーズを省略すれば、プロジェクト全体が危険にさらされます。

DMAICとは

DMAICはSix Sigmaの運用上の骨格をなす5フェーズの改善サイクルです。頭字語はDefine（定義）、Measure（測定）、Analyze（分析）、Improve（改善）、Control（管理）を表します。欠陥を減らし、サイクルタイムを短縮し、品質向上を定着させるための再現可能なデータ駆動のロードマップをチームに提供します。

この手法は1980年代半ばにモトローラの信頼性エンジニアビル・スミスと統計学者マイケル・ハリーによってオリジナルのSix Sigmaフレームワークの一部として体系化されました。モトローラは製造ライン全体で品質を100万機会あたり3.4欠陥（DPMO）に押し上げるための体系的な方法を必要としていました。DMAICはその手段でした。ジャック・ウェルチが1995年にGE全体でSix Sigmaを採用したとき、DMAICは大企業向けの標準的な改善プレイブックとなり、製造業からヘルスケア、金融、物流、ソフトウェアへと広がりました。

DMAICをよりシンプルなフレームワークから区別するのは、行動前の測定への徹底したこだわりです。データなしには根本原因を定義しません。根本原因を統計的に確認するまでは解決策を試験しません。管理システムが整うまでは成功を宣言しません。そのシーケンスがその強みであり、チームがショートカットを試みたときにプロジェクトが停滞する理由でもあります。

主要事実

• Six SigmaとDMAICを1986年に創始したモトローラは、米国品質学会（ASQ）が引用する数字によると、2006年までに170億ドル超の累積節約を同手法に帰しています。
• GEは1996年から2001年の年次報告書で100億ドルの累積Six Sigmaメリットを報告しており、大規模なDMAICの最も引用される企業事例研究となっています。
• Six SigmaとLean Six Sigmaは製造業とオペレーション分野で最も求められるプロセス資格のひとつとして一貫してランクインしており、International Association for Six Sigma Certification（IASSC）が追跡する数十万件のアクティブなベルト認定があります。

DMAICの5フェーズ詳説

DMAICは設計上、順序に従います。各フェーズは次のフェーズへの参加を制限する成果物を生み出します。フェーズを並行して実施したり測定フェーズをスキップしたりするチームは、ほぼ必ず間違った問題を解決することになります。各フェーズで何が起こるかを説明します。

D - Define（定義）

Defineフェーズは一つの問いに答えます。私たちは実際にどの問題を解決しているのか、そしてそれは解決する価値があるのか？チームはプロジェクト憲章を作成します。問題、目標、スコープ、ビジネスケース、チームメンバーを記載した1ページの文書です。これがなければ、プロジェクトのスコープが拡大し、スポンサーの関与が薄れます。

Defineの他の2つの中心的なツールはSIPOCダイアグラム（Suppliers、Inputs、Process、Outputs、Customers）と**Voice of the Customer（VOC）**リサーチです。SIPOCは誰もが詳細に入り込む前にプロセスの全体像を把握できます。VOCは顧客のクレーム、アンケート、サポートチケットを測定可能な品質要件に変換します。顧客が実際に何を気にしているかがわからなければ「欠陥」を定義できません。Defineは、チームが問題定義と成功指標について合意し、スポンサーが憲章に署名したときに終わります。

M - Measure（測定）

Measureはベースラインを確立します。何かを改善する前に、現状がどれほど悪いかを知る必要があります。また、改善を追跡するのに十分な信頼性があるかどうかも確認が必要です。主要な成果物は工程能力指数（CpとCpk）で、現在のプロセスが顧客の規格限界内にどれほどうまく収まっているかを示します。

データ収集計画は何を、どのように、どこから収集するかを正確に文書化します。これがないと、チームは一貫性のないデータセットを作成し、分析を不可能にします。多くのチームは**Measurement System Analysis（MSA）**も実施します。データ収集に使用するゲージ、ソフトウェア、または人間の評価者が信頼できるかどうかを確認します。変動の大きい測定システムは、能力のあるプロセスを欠陥があるように見せてしまいます。Measureはベースライン（欠陥率、サイクルタイム、エラー率、チャーターが改善を約束したもの）を確認したときに終わります。

A - Analyze（分析）

Analyzeはチームが「これがデータだ」から「これが理由だ」に移行する段階です。目標は、もっともらしい理論をブレーンストーミングするだけでなく、証拠によって根本原因を確認することです。最もよく使われる出発点の2つのツールはフィッシュボーン図（Ishikawa図または特性要因図とも呼ばれる）と、「なぜ」を繰り返し問うことで症状からシステム的な原因を掘り下げる5 Whys手法です。

しかしAnalyzeは定性的ツールにとどまりません。チームは仮説検定（t検定、カイ二乗検定、回帰分析）を使って、疑われる原因が統計的に有意かどうかを確認します。これがDMAICを勘に頼った問題解決から区別するものです。特定された根本原因を除去することが現在のベースラインと目標のギャップを埋めることを、データで示すまではImproveに進めません。Analyzeは、検証済みの根本原因と問題のどれほどを説明できるかの明確な記述で終わります。

I - Improve（改善）

Improveは解決策を設計、テスト、選択します。チームは確認された根本原因に対する複数の解決策オプションを生成し、優先度マトリックスまたは**Failure Mode and Effects Analysis（FMEA）**を使ってパイロットにコミットする前にリスク、コスト、影響を評価します。**Design of Experiments（DOE）**は、すべての組み合わせをテストせずに最適な設定の組み合わせを見つける必要があるとき、複数の要因が相互作用する場合に選ばれる統計ツールです。

パイロットは必須です。小規模な管理されたテストにより、チームが本格的な展開に投資する前に提案された解決策が指標を実際に動かすことを検証します。パイロット結果はMeasureフェーズのベースラインに照らして評価されます。エラー率は下がったか？サイクルタイムは縮小したか？改善が確認された場合、チームは新しいプロセスを文書化し、引き継ぎの準備をします。Improveは、パイロットデータが解決策の有効性を証明したときに終わります。

C - Control（管理）

Controlはパイロットの成功を恒久的なプロセス変更に変えます。主要な成果物はコントロールプランです。何を、どのくらいの頻度でモニタリングするか、誰がオーナーか、指標が許容限界を超えた場合に何をするかを定義した文書です。コントロールプランがなければ、改善プロジェクトは衰退します。スタッフが入れ替わり、回避策が戻り、欠陥率が上昇します。

統計的工程管理（SPC）チャートは標準的なモニタリングツールです。指標を管理限界とともに時系列でプロットし、プロセスが漂流しているのか正常なばらつきを示しているのかを視覚的に明確にします。教育訓練資料と更新された標準作業手順書（SOP）（標準作業手順書参照）は新しい仕事の仕方を公式なものにします。プロジェクトはプロセスオーナーが成果維持の責任を受け入れ、スポンサーが最終結果に署名したときに正式にクローズします。Controlはほとんどのチームが投資不足になるフェーズであり、2年後も成果が残っているかどうかの理由でもあります。

各DMAICフェーズで使用するツール

各フェーズには定番ツールのリストがあります。すべてのプロジェクトですべてを使うわけではありませんが、メニューを知ることで必要な証拠に適したツールを選べます。

CTQはCritical to Quality（品質に重要）の略で、顧客要件を測定可能な内部プロセス仕様に変換するものです。MSAはMeasurement System Analysis（測定システム分析）。FMEAはFailure Mode and Effects Analysis（故障モードと影響分析）。DOEはDesign of Experiments（実験計画法）。SPCはStatistical Process Control（統計的工程管理）。RACIはResponsible、Accountable、Consulted、Informedの略です。

実例：B2B企業における請求書処理エラーの削減

中堅物流会社（ここではFreightCoと呼ぶ）が、送付請求書で8%のエラー率を抱えていました。財務部門は毎月約40時間を修正作業に費やしており、2社の顧客が正式な異議申し立てをエスカレーションしていました。CFOは1四半期以内にエラー率を1%未満にするという目標でDMAICプロジェクトをスポンサーしました。

Define。 プロジェクト憲章はERP（Enterprise Resource Planning）システムで処理されたB2B（Business-to-Business）の送付請求書に問題をスコープしました。SIPOCは発注書の受領から請求書の承認と発送までのフローをマッピングしました。2社の異議申し立て顧客とのVOCインタビューで、エラーの種類が特定されました。明細項目に誤った単価が適用されていました。

Measure。 チームは3ヶ月間の請求書データを引き出し、エラー率8.1%（5,087件の請求書のうち412件のエラー）を確認しました。手動審査プロセスに対して実施したMSAにより、審査者が価格差異を「エラー」か「四捨五入」かについて18%の割合で見解が異なることがわかりました。これ自体が測定システムの問題であり、チームは継続前にエラーの定義を厳格化することで解決しました。工程能力は請求書プロセスがおよそ2.8シグマで稼働していることを示しました。

Analyze。 フィッシュボーン図により、人、プロセス、システム、データのカテゴリーで11件の根本原因候補が生成されました。上位3件の候補に対する5 Whys分析が常に一箇所に行き着きました。ERPのベンダーマスタデータテーブルに自動検証がありませんでした。サプライヤーからの価格変更は手動で適用されており、更新レートが実際の変更日から2から5日遅れて実行されていました。仮説検定により、価格エラー請求書の73%がサプライヤー価格変更後の遅延ウインドウ中に生成されていたことが確認されました。

Improve。 チームは2つの解決策のスコープを決めました。（1）明細項目の価格がベンダー固有の許容範囲外に落ちた場合に請求書の生成をブロックする自動検証ルール、（2）サプライヤーの価格変更を24時間以内に入力することを要求するSLA（Service Level Agreement）です。一顧客セグメントで検証ルールをアクティブにした4週間のパイロットを実施しました。そのセグメントのエラー率は0.9%、目標の1%以内まで低下しました。FMEAにより、ルールが許容範囲を超えた誤検知を生成しないことが確認されました。

Control。 検証ルールがすべてのアカウントにわたって本稼働に移行されました。請求書エラー率を追跡する月次SPCチャートが買掛金（AP）チームマネージャーに割り当てられました。コントロールプランは2%でのアクションのトリガーを定義しました。率がその線を超えた場合、ベンダーマスタ監査プロトコルが自動的に発動します。プロジェクトクローズ後6ヶ月で、エラー率は0.8%を維持しています。

プロジェクトは修正作業を毎月40時間から5時間未満に削減し、2件の顧客異議申し立ては解決されました。プロジェクトの総実行時間は11週間でした。

DMAIC対PDCA対DMADV

DMAICはいくつかの反復的な改善フレームワークの一つです。最もよく並べて見られる2つはPDCAとDMADVです。より広範な比較についてはプロセス最適化のガイドも参照してください。

核心的な区別は、DMAICは現存するものを修正するということです。DMADV（DFSS=Design for Six Sigmaとも呼ばれる）は新しいものを設計します。PDCAは軽量で反復が速く、統計的仮説検定を必要としないため、Black Beltのいないチームでも利用しやすいです。ただしPDCAの速さは、根本原因が明らかでない複雑な問題では不利にもなります。PDCAの詳細についてはPDCAの記事を参照してください。

DMAICとLean方式はしばしばLean Six Sigmaとして組み合わせられ、AnalyzeおよびImproveフェーズでDMAICの統計ツールキットと並行してLeanツール（バリューストリームマッピング、5S、Kanban）を使用します。その結果、ムダ（Leanの領域）と変動（Six Sigmaの領域）を同時に攻略するフレームワークになります。

DMAICを使うべき時（および避けるべき時）

DMAICは精密ツールであり、万能ツールではありません。間違った問題に使うと何ヶ月も無駄にします。

Kaizenイベント（集中した3から5日間のワークショップ）は、チームがすでに根本原因を疑っており、行動するだけでよい問題には多くの場合より速いです。DMAICは問題が慢性的で、根本原因が本当に曖昧で、6から12週間の体系的な作業を正当化するほど賭けが高い場合に、そのオーバーヘッドを正当化します。

DMAICプロジェクトを失敗させる一般的なミス

• 時間を節約するためにMeasureをスキップする。 DefineからAnalyzeに勘で飛ぶチームは、ベースラインなし、確認された欠陥定義なし、解決策が機能したことを証明する手段なしのAnalyzeに行き着きます。Measureは最もスキップされるフェーズであり、最も重大なスキップです。
• 問題を解決策として定義する。 「システムXを実装する必要がある」と言うプロジェクト憲章は問題を定義しているのではなく、修正を事前に選択しています。Defineは現在と望ましいパフォーマンスのギャップを説明すべきであり、答えを規定すべきではありません。
• 相関関係を根本原因と混同する。 フィッシュボーンと5 Whysは候補を浮かび上がらせます。仮説検定がそれらを確認します。フィッシュボーンのブレーンストーミングだけを根拠にImproveに進むチームは、修正が指標を動かさないことに気づくことが多いです。
• Controlフェーズへの投資不足。 Controlは最も注目されず、プロジェクト後に最も非難されるフェーズです。コントロールプランがなければプロセスオーナーがいません。プロセスオーナーがいなければ、成果は6ヶ月以内に失われます。
• 憲章への署名後のスコープ拡大。 DMAICプロジェクトは、一つの問題を解決することで別の3つの問題が明らかになるために拡大します。憲章のスコープを守り、隣接する問題には別のプロジェクトを開始します。
• Black Beltや経験豊富なファシリテーターなしでDMAICを実施する。 AnalyzeとImproveの統計ツール（仮説検定、DOE、SPC）はトレーニングを必要とします。分析を正しく実施できる人がいないチームは、チームがすでに信じていたことを確認するチャートを生成する傾向があります。

ビジネスプロセス管理の広範な視点と全体的な改善ツールキットにおけるDMAICの位置づけについては、その記事を参照してください。DMAICプロジェクトを実施する前に基礎的なプロセス管理の概念を理解するには、その概要が最初に読む価値があります。

よくある質問

DMAICはSix Sigmaと同じですか？

いいえ、しかし両者は切り離せません。Six Sigmaは全体的な品質理念と手法であり、100万機会あたり3.4欠陥を目標とします。DMAICは既存のプロセスにおけるSix Sigmaの改善を達成するために使われる特定のプロジェクトロードマップです。Six Sigmaを目的地、DMAICをルートと考えるとわかりやすいでしょう。Six SigmaにはDMADVも含まれており、新しいプロセスを設計するためのものと、異なる複雑さのレベルでDMAICプロジェクトをリードできる人を定義するベルト認定システム（ホワイト、イエロー、グリーン、ブラック、マスターブラックベルト）があります。

DMAICプロジェクトはどのくらいの期間がかかりますか？

ほとんどのDMAICプロジェクトは憲章署名からControlの引き継ぎまで3から6ヶ月かかります。シンプルでよくスコープされた単一チームのプロジェクトは8から10週間でクローズできます。複雑な部門横断プロジェクト（特にDOEや大規模なデータ収集を必要とするもの）は9から12ヶ月かかる場合があります。MeasureとAnalyzeフェーズは通常最も時間がかかります。データ収集には時間がかかり、仮説検定には統計的に意味のある大きなサンプルサイズが必要だからです。どちらのフェーズも急いだ場合、それがDMAICプロジェクトが成果を持続できない最も一般的な理由です。

Six Sigma認定なしにDMAICを使えますか？

はい、ただし注意点があります。DefineとControlフェーズはプロジェクト管理に精通している人なら誰でもアクセスできます。Measureフェーズは基本的な統計と測定システム分析への慣れが必要です。Analyze（特に仮説検定と回帰）は、正しく実施するためにグリーンベルトまたはブラックベルトのトレーニングが必要です。多くのチームは認定ファシリテーターがリード役として参加し、認定を持たないメンバーがDefineとImproveに貢献するという形でDMAICを実施します。Analyzeの統計的厳密さなしにDMAIC構造を使用するのは、構造なしよりはましですが、実際に欠陥を引き起こしていない根本原因を確認するリスクがあります。

DMAICとDMADVの違いは何ですか？

両者はSix Sigmaファミリーに属し、最初の3フェーズ（Define、Measure、Analyze）を共有します。フェーズ4で分岐します。DMAICの4番目のフェーズはImproveです。既存のプロセスを修正します。DMADVの4番目のフェーズはDesignです。新しいものを構築します。DMADVは確立されたプロセスで成果を持続させるのではなく、要件に対して新しい設計を検証するため、ControlではなくVerifyで終わります。プロセスが壊れているが修正可能な場合はDMAICを使用します。プロセスを最初から作成する必要がある場合、またはDMAICをすでに適用したが要件を満たすことができない場合はDMADVを使用します。

---

DMAICはプロセス問題を修正する最速のルートではありません。しかし根本原因が明らかでない慢性的で高リスクの欠陥に対しては、最も信頼できるものです。問題を測定する前に定義してください。分析する前に測定してください。改善する前に分析してください。改善が維持されるよう管理してください。このシーケンスは地味で、規律を要し、そして機能します。

品質の旅を始めるチームには、正式なDMAICプロジェクトの前に5S方式が有用な出発点になることが多いです。作業環境を安定させ、測定をより信頼できるものにします。