DMAICプロセス

英語名 DMAIC Process
読み方 ディーマイク プロセス
難易度
所要時間 プロジェクト1件あたり1〜6ヶ月
提唱者 モトローラ(シックスシグマ手法)
目次

ひとことで言うと
#

Define(定義)→ Measure(測定)→ Analyze(分析)→ Improve(改善)→ Control(管理)の5段階でプロセスの問題を体系的に解決するフレームワーク。モトローラが開発したシックスシグマの中核手法であり、データに基づく改善を徹底する。

押さえておきたい用語
#

押さえておきたい用語
DMAIC
Define・Measure・Analyze・Improve・Controlの頭文字を取ったデータ駆動のプロセス改善手法を指す。
シックスシグマ
プロセスのバラつきを統計的に管理し、100万回に3.4回以下の不良率を目指す品質管理手法。
CTQ(Critical to Quality)
顧客が重視する品質要素のうち、プロセス改善で直接影響を与えられる測定可能な指標を指す。
プロセスマップ
業務の流れを入力→活動→出力で可視化した図。問題箇所の特定に使う。
管理図(Control Chart)
プロセスの変動を時系列でプロットし、異常を統計的に検出するツール。

DMAICプロセスの全体像
#

5つのフェーズでデータに基づく改善を進める
DMAICの5フェーズDDefine問題を定義するMMeasure現状を測定するAAnalyze根本原因を分析IImprove改善策を実施するCControl維持・管理する各フェーズの主要アウトプットDプロジェクト憲章・CTQMベースラインデータ・工程能力A根本原因特定・検証I改善策・パイロット結果C管理図・標準作業手順データに基づく持続的改善勘と経験ではなくデータで改善し改善後の状態を管理図で維持する
DMAICプロジェクトの進め方
D
Define
何が問題か・誰の・どの指標を改善するか定義
M
Measure
現状のプロセスをデータで把握する
A
Analyze
データから根本原因を統計的に特定する
I→C
改善と管理
対策を実施し管理図で効果を維持する

こんな悩みに効く
#

  • 不良率を下げたいが、どこから手をつければいいか分からない
  • 改善活動をしても効果が一時的で、すぐ元に戻ってしまう
  • 「勘と経験」で改善しているが、本当に効果があったのか証明できない

基本の使い方
#

Define:問題をCTQで定義する
「品質を改善したい」という漠然とした目標を、顧客にとって重要な品質要素(CTQ)に落とし込む。「納品リードタイムを14日から7日以下にする」のように、測定可能な指標と目標値を明確にする。この段階でプロジェクト憲章(目的・範囲・メンバー・期限)も作成する。
Measure & Analyze:データで現状を把握し根本原因を特定する
現在のプロセスを測定し、ベースラインデータを収集。次に、なぜ問題が起きているかをデータで分析する。パレート図で問題の優先順位をつけ、フィッシュボーンダイアグラムで原因候補を洗い出し、統計的手法(回帰分析・仮説検定)で根本原因を絞り込む。
Improve & Control:対策を実施し効果を維持する
根本原因に対する改善策を設計し、パイロットテストで効果を確認してから全面展開。展開後は管理図を設置し、プロセスが改善された状態を維持しているか継続的にモニタリングする。標準作業手順書も更新し、改善を組織に定着させる。

具体例
#

例1:自動車部品メーカーが不良率を85%削減

従業員 350名 の自動車部品メーカー。ブレーキパッドの不良率が 2.3% で、顧客からクレームが月 15件 発生していた。

DMAICを適用。(D) CTQを「ブレーキパッドの厚み精度 ±0.05mm」と定義。(M) 過去6ヶ月の 5,000個 のデータを収集し、不良の 68% が特定の2工程に集中していることを確認。(A) 統計分析で「金型の温度管理の振れ幅」と「原材料ロットの含水率」が根本原因と特定。(I) 金型の温度センサーを追加し、原材料の受入検査基準を厳格化。(C) 管理図で毎日の工程能力を監視。

6ヶ月 後、不良率は 2.3% → 0.35% に低下。顧客クレームは月 15件 → 2件 に減少し、年間の廃棄コスト削減額は 約1,800万円 に達した。

例2:コールセンターが平均通話時間を30%短縮

通信会社のコールセンター(オペレーター 200名)。平均通話時間(AHT)が 12分 で業界平均 8分 を大幅に上回り、人件費が膨らんでいた。

(D) CTQを「AHTを8分以下にする」と定義。(M) 1,000件 の通話を録音・分類し、通話時間の分布を可視化。(A) パレート分析で「システムの検索に時間がかかる」が全体の 42%、「説明のやり直し」が 28% を占めると判明。(I) 検索システムのUIを改善し、よくある質問のスクリプトを標準化。(C) 週次で管理図を更新し、AHTが 9分 を超えたらアラート。

3ヶ月 後、AHTは 12分 → 8.2分 に短縮。年間人件費の削減効果は 約4,500万円。オペレーターの満足度も上がり、離職率が 18% → 12% に改善。

例3:病院が入退院手続きの待ち時間を半減

地方の総合病院(病床 400床)。入退院手続きの平均待ち時間が 45分 で、患者アンケートの不満項目の 1位 を占めていた。

(D) CTQを「入退院手続きの待ち時間を20分以下にする」と定義。(M) 2ヶ月 間のタイムスタンプデータを収集。(A) 分析の結果、待ち時間の 55% が「書類の手書き記入と確認」に費やされていることが判明。残りは「保険確認の電話待ち」25% と「窓口の人員不足」20%。(I) 書類を事前にWebで電子入力できるシステムを導入し、保険確認を事前処理に変更。(C) 毎週の待ち時間データを管理図でモニタリング。

4ヶ月 後、平均待ち時間は 45分 → 18分 に短縮。患者満足度スコアは 3.2 → 4.1(5段階)に向上し、「手続きが不満」の回答率は 38% → 11% に低下した。

やりがちな失敗パターン
#

  1. Defineを曖昧にしたまま進める — 「品質を上げたい」では測定も分析もできない。CTQを数値で定義し、達成基準を明確にしてからMeasureに進む。
  2. データなしで原因を決めつける — 「たぶんこれが原因」で改善策に飛びつくと、的外れな対策になる。Analyze段階でデータによる検証を徹底する。
  3. Controlフェーズを省略する — 改善して終わりにすると、3ヶ月で元に戻る。管理図の設置と標準作業手順の更新が改善を定着させる。
  4. 全工程を同時に改善しようとする — パレート分析で影響の大きい上位 2〜3個 の原因に集中する。80/20の原則で効率的に成果を出す。

まとめ
#

DMAICは「データで語る改善」の王道。定義→測定→分析→改善→管理の5段階を順に踏むことで、勘と経験に頼らない再現性のある改善が実現する。特にControlフェーズで管理図を設置し、改善状態を維持する仕組みを作ることが、一時的な改善で終わらせないための鍵になる。