ー この記事の要旨 ー
- DMAICとは、シックスシグマに基づく5段階のプロセス改善フレームワークで、データに裏づけられた課題解決を実現する手法です。
- 本記事では、Define・Measure・Analyze・Improve・Controlの各フェーズの目的と代表的なツールを整理し、PDCAとの使い分けやよくある失敗パターンまで網羅的に解説します。
- 業務のばらつきや不良率に悩むビジネスパーソンが、自社の改善プロジェクトを具体的に動かすための知識と実践ヒントが得られます。
DMAICとは｜シックスシグマが生んだプロセス改善の基本
DMAICとは、Define（定義）・Measure（測定）・Analyze（分析）・Improve（改善）・Control（管理）の5フェーズで構成されるプロセス改善フレームワークです。
品質管理の手法として知られるシックスシグマ（Six Sigma）の中核をなすアプローチであり、「勘や経験」ではなくデータと統計的手法に基づいて業務課題を解決する点に特徴があります。業務プロセスの再構築についてはBPR（ビジネスプロセス・リエンジニアリング）という手法もありますが、DMAICは既存プロセスの改善に焦点を当てている点が異なります。業務プロセス再構築の全体像については、関連記事『BPRとは？』で詳しく解説しています。
DMAICの5文字が意味するもの
DMAICは、改善プロジェクトを5つの段階に分けて進めるロードマップです。各フェーズには明確な目的とアウトプットが設定されており、「次に何をすべきか」が常にはっきりしている点が実務で使いやすい理由のひとつ。
注目すべきは、5つのフェーズが直線的に並んでいるだけではないことです。Controlフェーズで維持が難しいと判明すれば、Analyzeに戻って原因を再検証するケースもあります。実務では、この「行きつ戻りつ」の柔軟さがプロジェクトの精度を高めます。
シックスシグマとDMAICの関係
シックスシグマは、1980年代にモトローラで開発された品質管理の方法論です。「100万回の作業機会あたり欠陥を3.4件以下に抑える」というシグマ水準の考え方に基づき、プロセスのばらつきを徹底的に減らすことを目指します。
DMAICは、このシックスシグマを現場で実践するための具体的な進め方にあたります。シックスシグマが「何を目指すか」という哲学なら、DMAICは「どう進めるか」という手順書です。そのため、シックスシグマの導入を検討する企業の多くは、まずDMAICの理解からスタートします。
DMAICの5つのフェーズ｜各段階の目的とアウトプット
前のフェーズの成果物が、次のフェーズのインプットになる。この連鎖構造を理解すると、各段階で「何をして、何を出すか」が見えてきます。
Define（定義）：改善対象と目標を明確にする
改善したい課題があるのに、プロジェクトが始まると「そもそも何を直すんだっけ？」と迷走する。この事態を防ぐのがDefineフェーズであり、スコープと目標の確定が最初の仕事です。
具体的には、プロジェクトチャーター（目的・範囲・期限・メンバーを記載した計画書）を作成し、VOC（Voice of Customer：顧客の声）を収集してCTQ（Critical to Quality：品質に直結する要因）を特定します。SIPOC（Supplier・Input・Process・Output・Customer）を使ってプロセスの全体像を可視化するのも、このフェーズの代表的な作業です。
Measure（測定）：現状をデータで把握する
改善対象プロセスの現状をデータで「見える化」する。これがMeasureフェーズの目的です。
ここがポイントですが、測定の前に「何を、どう測るか」の計画を立てる必要があります。KPIの設定、サンプリング方法の決定、MSA（Measurement System Analysis：測定システム分析）による測定精度の検証が含まれます。ベースライン（改善前の基準値）を正確に記録しておくことで、Improveフェーズ後の改善効果を客観的に比較できるようになるでしょう。
Analyze（分析）：根本原因を特定する
データは集まった。では、なぜその問題が起きているのか。Measureの成果物をもとに根本原因を突き止めるのがAnalyzeフェーズです。
実務では、まず特性要因図（フィッシュボーン図）で原因候補を洗い出し、パレート図で影響度の大きい要因を絞り込むアプローチが一般的です。さらに、散布図や回帰分析、ヒストグラムを用いて仮説を検証します。見落としがちですが、「原因らしきもの」を見つけた段階で飛びつかず、データで裏づけを取るプロセスが、DMAICの信頼性を支えている点。仮説を立てて検証するという思考プロセス自体は、関連記事『仮説思考とは？』でも詳しく取り上げています。
Improve（改善）：解決策を立案・実行する
Improveフェーズでは、Analyzeで特定した根本原因に対する解決策を設計し、実行に移します。
ここで大切なのは、いきなり全面展開するのではなく、パイロットテスト（小規模な試験運用）で効果とリスクを検証することです。FMEA（Failure Mode and Effects Analysis：故障モード影響分析）を使って改善策のリスクを事前に評価し、期待する改善効果と実際の結果を比較します。改善前後の数値を明確に記録しておくことが、次のControlフェーズへのスムーズな移行を後押しするでしょう。
Control（管理）：改善効果を維持する仕組みをつくる
改善効果を「一時的な成果」で終わらせず組織に定着させる。ここにControlフェーズの存在意義があります。
管理図（コントロールチャート）やSPC（Statistical Process Control：統計的工程管理）を活用し、プロセスの安定性を継続的にモニタリングします。作業標準書の整備、担当者への教育、異常発生時の対応手順の策定も含まれます。正直なところ、多くの改善プロジェクトが「やって終わり」になるのは、このControlフェーズの設計が甘いケースが大半です。
DMAICのビジネスケース｜受注処理の遅延改善を例に
DMAICの流れを、ある企業の受注処理チームを例にたどってみます。
受注処理の平均リードタイムが5営業日を超え、顧客からの納期クレームが月に10件以上発生していました（Define：スコープ定義）。チームはまず過去3か月の処理データを収集し、平均リードタイム5.3日、標準偏差1.8日というベースラインを確認しました（Measure：現状測定）。特性要因図で原因候補を洗い出したところ、在庫確認の手動照合と承認フローの属人化が主因であると判明しました（Analyze：根本原因特定）。そこで、在庫管理システムとの自動連携と承認ルールの標準化をパイロットテストで導入し、2週間後にリードタイムが3.1日まで短縮されました（Improve：改善実行）。最後に管理図による週次モニタリングと作業標準書を整備し、改善効果の維持体制を構築しました（Control：定着化）。
※本事例はDMAICの活用イメージを示すための想定シナリオです。
IT部門での活用例： システム障害の平均復旧時間（MTTR）を短縮するプロジェクトでITILのインシデント管理プロセスと組み合わせ、障害対応フローのボトルネックを可視化・改善する活用法があります。
経理部門での活用例： 月次決算の締め作業を対象に、仕訳入力のエラー率をDMAICで分析し、RPAツールによる自動仕訳と簿記2級レベルのチェックリスト導入で処理精度を向上させた例も広がっています。
DMAICで使う代表的なツール・手法
特性要因図、パレート図、FMEA。ツール名は聞いたことがあっても、どのフェーズで何の目的に使うかが曖昧なケースは少なくありません。すべてを使いこなす必要はありませんが、各フェーズの定番ツールを押さえておくと、プロジェクトの進行が格段にスムーズになります。
フェーズ別の主要ツール一覧
| フェーズ | 代表的なツール | 用途 |
| Define | プロジェクトチャーター、SIPOC、VOC | スコープ定義、顧客要求の把握 |
| Measure | データ収集計画、MSA、工程能力分析（Cp/Cpk） | 現状の数値化、測定精度の確認 |
| Analyze | 特性要因図、パレート図、散布図、回帰分析 | 根本原因の特定と検証 |
| Improve | FMEA、パイロットテスト、DOE（実験計画法） | 解決策の設計とリスク評価 |
| Control | 管理図（SPC）、作業標準書、ダッシュボード | 改善効果の維持と監視 |
実は、ツールの種類よりも「どのフェーズで何の目的で使うか」の判断が成果を左右します。同じパレート図でも、Measureで使えば「どこに問題が集中しているか」の把握に、Analyzeで使えば「どの原因が影響度が大きいか」の絞り込みに役立つという具合です。
ツール選定で押さえておきたい判断基準
すべてのツールを毎回使う必要はありません。判断基準として意識したいのは3点です。
1つ目は「データの種類に合っているか」。計量データ（連続値）にはヒストグラムや散布図、計数データ（件数・割合）にはパレート図やp管理図が向いています。2つ目は「チームのスキルレベル」。統計ソフトの操作経験がないメンバーが多い場合、Excelで作成できるツールから着手するのが現実的でしょう。3つ目は「意思決定者に伝わるか」。分析結果を上司や経営層に報告する場面では、複雑な統計手法よりも視覚的にわかりやすい図表のほうが合意形成を加速させます。
DMAICとPDCAの違い｜使い分けの判断基準
DMAICとPDCAは、どちらもプロセス改善のフレームワークですが、アプローチの深さと適用場面に明確な違いがあります。
目的とアプローチの違い
PDCAサイクル（Plan・Do・Check・Act）は、日常業務の中で小さな改善を素早く回すことに適したフレームワークです。計画して実行し、結果を確認して次のアクションにつなげるという流れは、現場レベルの継続的改善と相性がよいといえるでしょう。
一方、DMAICはデータ収集・統計分析を伴う本格的なプロジェクト型の改善手法です。根本原因の特定にMeasure・Analyzeの2フェーズを充て、改善後の定着までControlフェーズで管理する設計になっています。率直に言えば、PDCAが「素早く試して改善するサイクル」なら、DMAICは「徹底的に原因を突き止めてから動くプロジェクト」という位置づけです。
実務での使い分けポイント
使い分けの基準はシンプルで、「問題の複雑さ」と「データによる裏づけの必要性」で判断できます。
日常的な業務の微調整や、原因がある程度見えている課題にはPDCAが向いています。例えば、会議時間の短縮や報告書フォーマットの改善といったテーマです。対して、原因が複数絡み合っている、ばらつきの低減が求められる、改善効果を数値で証明する必要がある場面ではDMAICの出番。問題解決の基本的な考え方やスキルについては、関連記事『問題解決能力が高い人の特徴とは？』で詳しく解説しています。
なお、両者は排他的な関係ではありません。DMAICプロジェクト完了後のControlフェーズで、日常的なPDCAサイクルに落とし込むという組み合わせは、多くの現場で採用されています。
DMAICプロジェクトでよくある失敗と対策
体系的なフレームワークを導入したのに、なぜかプロジェクトが頓挫する。その原因は、いくつかの典型的なパターンに集約されます。
失敗しやすい3つのパターン
Defineフェーズでのスコープ肥大化。 改善したい課題をあれもこれもと盛り込んだ結果、プロジェクトの焦点がぼやけてしまうパターンです。「受注処理のリードタイム短縮」のはずが「受注から出荷までの全工程改善」にスコープが膨らむと、データ収集だけで数か月かかることも。
Measureフェーズでのデータ不備。 現場に蓄積されたデータの形式がバラバラだったり、そもそもデータが取れていなかったりするケースは珍しくありません。この段階で測定基準を曖昧にしたまま進むと、Analyzeの精度が大きく落ちます。
Controlフェーズの形骸化。 ここが落とし穴で、改善直後は成果が出ていたのに、モニタリングの仕組みが定着せず数か月後に元の状態に戻ってしまう。再発防止の仕組みづくりが不十分なまま「プロジェクト完了」と宣言してしまうのは、実務で最も多い失敗パターンです。
成功に近づけるための実践的な工夫
失敗パターンを踏まえると、押さえておきたいポイントは3つあります。
Defineでは、改善対象を「1つのプロセス × 1つのKPI」に絞ることを意識してみてください。スコープが狭いほどデータ収集も分析も速く進み、チームのモチベーション維持にもつながるでしょう。Measureでは、本格的なデータ収集に入る前に、1週間分のサンプルデータで測定手順をテストするのがおすすめです。想定と実際のギャップを早期に発見できます。
Controlでは、管理図の確認頻度と異常時の対応フローを「誰が・いつ・何を見るか」まで具体化した作業標準書を残すことが、定着の分かれ目になります。ムダの排除や業務効率化の基本的な考え方は、関連記事『ECRSとは？』も参考になるでしょう。
よくある質問（FAQ）
DMAICは製造業以外でも使えるのか？
DMAICは業種を問わず適用できるプロセス改善手法です。
もともとは製造業の品質管理で発展しましたが、サービス業、医療、金融、IT分野でも活用が広がっています。「繰り返し発生するプロセス」と「測定可能なデータ」があれば、業界に関係なく適用可能です。
コールセンターの応答時間短縮や、病院の患者待ち時間改善などが代表的な非製造業での活用例です。
DMAICとPDCAはどちらを選べばよいのか？
課題の複雑さとデータに基づく分析の必要性をもとに判断します。
原因が明確で素早く改善したい場面にはPDCAが適しています。一方、原因が複雑に絡み合い、統計的なデータ分析で根本原因を突き止める必要がある場面ではDMAICが力を発揮します。
両者を組み合わせ、DMAICで根本改善した後の維持管理をPDCAで回す方法も実践的です。
シックスシグマのベルト制度とは何か？
プロジェクト推進者の役割と習熟度を示す階層制度です。
イエローベルト（基礎知識）、グリーンベルト（プロジェクト実行者）、ブラックベルト（専任リーダー）、マスターブラックベルト（指導者・戦略推進）という段階があります。加えて、経営層との橋渡し役を担うチャンピオンという役割も設定されています。
中小企業では厳密なベルト制度を導入しなくても、役割分担を明確にすることで同様の効果が期待できます。
DMAICプロジェクトにはどのくらいの期間がかかるのか？
一般的なDMAICプロジェクトは3〜6か月が目安です。
スコープの広さ、データの入手しやすさ、チームのスキルレベルによって大きく変動します。Defineに2〜3週間、Measure・Analyzeにそれぞれ3〜4週間、Improveに4〜6週間、Controlに2〜3週間という配分が多く見られます。
初めてのプロジェクトでは、小さなテーマで3か月以内の完了を目標にすると、成功体験を得やすくなります。
統計の知識がなくてもDMAICを実践できるのか？
基本的な統計知識があれば、実務レベルでは十分対応できます。
高度な多変量解析やDOE（実験計画法）はブラックベルト級の専門性が必要ですが、グリーンベルトレベルの実践ではExcelで作成できるパレート図やヒストグラム、管理図が中心です。
リーンシックスシグマのように、統計手法を最小限に抑えつつムダ取りと組み合わせるアプローチから始めるのも一案です。
まとめ
DMAICで成果を出すカギは、Defineでスコープを1つのプロセスとKPIに絞り、MeasureとAnalyzeでデータに基づく根本原因の特定を徹底し、Controlで維持の仕組みまで設計しきることにあります。
まずは自分の業務で「繰り返し発生している課題」を1つ選び、1週間かけて関連データを集めてみてください。ベースラインの数値が見えるだけで、改善の方向性が具体的になります。
小さなテーマで1サイクル回す経験が、データドリブンな改善感覚を身につける最短ルートです。その積み重ねが、チーム全体のプロセス改善力を底上げし、次の大きなテーマに取り組む土台となっていきます。
