PDCA

シックスシグマとDMAICの関連性 - シックスシグマという言葉は一旦忘れろ DMAICとは、Define（定義）、Measure（測定）、Analyze（分析）、Improve（改善）、Control（管理）の5段階で構成される、問題解決のためのフレームワークである。 もともとシックスシグマの中で生まれた手法だが、現在では品質管理だけにとどまらず、幅広い業務改善に応用可能な“思考の枠組み”として注目されている。 本記事の対象読者は、以下のような方々だ： PDCAに限界を感じているが、次に学ぶべきフレームワークが分からない方 DMAICに関心はあるが、「シックスシグマ＝DMAIC」という説明に違和感を持っている技術者 統計学に苦手意識があり、DMAICの導入をためらっている現場リーダーや改善担当者 本記事では、DMAICが本来持っている“汎用的な問題解決力”に光を当て、「シックスシグマという言葉は忘れろ」という視点から、その独立した価値を見つめ直す。 DMAICは、シックスシグマを達成するためのフレームワークである。――この説明を聞いて、「じゃあDMAICって、統計の知識が必須なの？」「シックスシグマをやる気がないなら関係ないのか」と感じた人はいないだろうか？ 実はこの“セット販売”のような説明こそ、DMAICという強力な手法の普及を妨げている。 ※PDCAの限界については、以下記事を参照のこと。 PDCAではなぜ不十分か？ PDCAの先を考える DMAICとの出会い、そして違和感 筆者自身、PDCAの限界を感じていた。現場で改善活動を行う中で、PDCAでは根本的な原因を見誤ったり、改善が一過性で終わってしまったりする場面に多く出くわしてきた。そんなとき、「DMAIC」という新しい改善フレームワークの存在を知った。 しかし、そこに立ちはだかったのが“シックスシグマ”という言葉だった。 DMAICを調べれば調べるほど、どの解説も「シックスシグマの一部」として紹介してくる。まるで、「シックスシグマを理解しないとDMAICは使えない」とでも言わんばかりだった。さらに、「DMAICは統計的手法を活用し、工程能力を改善するものである」といった説明が重ねられると、こう思ってしまう。 「それなら、データが豊富な工程じゃないと使えないのか？」 「そもそも工程能力なんて、何十年も前からやってるし、今さら“6σ”なんて騒ぐ話か？」 こうして、「DMAICって結局シックスシグマの道具でしょ？」という誤解が生まれ、学習や導入を断念してしまう人も多い。 DMAICの本質は“問題解決のフレームワーク” だが、これは大きな誤解だ。 DMAICは、確かにシックスシグマと共に広まったが、その構造自体は非常に汎用的で、どんな業種・現場にも応用できる。筆者はこう考えている： 「DMAICは、単なる品質管理手法ではなく、“問題解決の思考手順”である」 その構成を見てみよう。 D（Define）：問題を定義する M（Measure）：現状を測定する A（Analyze）：原因を分析する I（Improve）：改善策を立てて実行する C（Control）：改善を維持・管理する これは、データが豊富にある製造現場でなくても使える。たとえ数値データが少なくても、観察記録や現場ヒアリング、タイムスタディなどをMeasureとAnalyzeに置き換えることで、DMAICの筋道は保てるのだ。 なぜ「シックスシグマという言葉は一旦忘れろ」と言いたいのか 筆者は、DMAICの価値を「シックスシグマ文脈の中だけで語るな」と言いたいのではない。むしろ逆で、「シックスシグマという名前がDMAICの導入を妨げている」という構造的な問題を指摘している。 DMAICは、シックスシグマの文脈でも使えるし、使うべきだ。ただし、それだけではない。 DMAICは独立した問題解決のフレームワークとして、PDCAに代わる新しい改善活動の礎になり得る。にもかかわらず、「シックスシグマ＝DMAIC」という硬直的な教え方をしてしまうと、 統計知識にアレルギーを持つ人は距離を置いてしまい、 統計に慣れた技術者は「こんなの昔からやってる」と軽視し、 どちらの層にも受け入れられない、という逆効果が生まれる。 おわりに：PDCAの“先”を見たい人へ もしあなたが、 「PDCAはやっているつもりなのに現場が良くならない」 「もっと構造的に改善を進めたい」 「再発しない改善を目指したい」 と感じているなら、DMAICは一度きちんと学んでみる価値がある。 そしてその際は、どうか「シックスシグマという言葉」は一度脇に置いてほしい。DMAICはそれ単体で、極めて強力な思考のフレームワークなのだから。

PDCAではなぜ不十分か？ PDCAの先を考える 製造業の現場にいれば、一度は聞いたことがあるはずの言葉――PDCAサイクル。計画（Plan）を立て、実行（Do）し、評価（Check）し、改善（Action）する。まさに仕事の基本中の基本とも言える手順だ。だが最近、ふと思ったことがある。 「いや、今さらPDCAなんて言うまでもなく、みんな普通にやってるだろ」 例えば、出社して何の計画も立てずにデタラメにキーボードを打ち始める奴がいるか？「今日は昨日の出張報告書を書こう」「リーダーに言われた○○製品を作ろう」そういった最低限のPlanくらい、誰でも自然にやっている。 Do？　立てた計画に対し、全く実行しない奴なんているか？　例えば、仕事が明確に割り振られているのにも関わらず、勤務時間中ボーっと何もせず立って or 座っているだけの従業員とか。 Check？　成果物を自分なりに確認する人も多いし、品質検査もある。ただ、CheckとActionが形式だけで終わっている場合はあるかもしれない。とはいえ、PDCA的な動きは、現場の誰もがすでに自然にやっているのだ。 それなのに、なぜ現場は良くならないのか？ ここに大きな違和感がある。「PDCAはやってる」「報告書にも書いてある」「手順書にもPDCAが載ってる」――それでも、製造不良は減らないし、改善も一向に進まない。 なぜか。 それは、PDCAサイクルそのものに限界があるからだ。 PDCAの構造的な欠陥 いきなりPlanに着手してしまう 現場でよくある「とりあえず計画しよう」という動き。でも、その計画はどんなデータに基づいている？　本当に問題点を定義できている？ Actionのあとの標準化が弱い せっかく改善しても、それを標準化・共有せず、また元に戻る。つまり、改善が一回限りで終わる。 「回す」だけになっている サイクルを回すことが目的化。中身がないままPDCAを唱えているケースがある。 具体例：教育して終わりでは再発する 例えば、不良が生じたとして、「作業者教育」を対策として選び、実施まで完了したとしよう。PDCAでいえば、Plan→Do→Check→Actionまでは一通り実行していることになる。 だが、対策が終わったからといって本当にそれで良いのか？　教育を受けた本人は理解していても、手順書が古いままだったり、他の作業者に伝わっていなかったりすれば、同じ不良は数か月後に再発することになる。 これはまさに製造現場でよくある話だ。 PDCAを実施していたはずなのに、なぜ再発したのか？ それは、PDCAのフレームワークには「標準化（Standardize）」や「横展開（Deployment）」といった考えが含まれていないからである。Actionで終わってしまうと、対策が場当たり的になり、他ラインや他工程への伝播も起きない。 改良フレームワークの登場 こうした限界を補うために、PDCAを改良したフレームワークがいくつか提案されている。 PDCAS：Actionの後にStandardize（標準化）を追加 PDCAD：Actionの後にDeployment（他工程や他ラインへの横展開）を追加 しかし、これらもPlanの不十分さを補えているわけではない。 DMAICという視点 そこで登場するのが、DMAICというフレームワークだ。 これはもともとシックスシグマの手法だが、問題解決の筋道として非常に理にかなっている。 D（Define）：問題を定義する M（Measure）：現状を測定する A（Analyze）：原因を分析する I（Improve）：改善策を立てて実行する C（Control）：改善を維持・管理する 最初にいきなりPlanせず、問題の定義やデータに基づいた分析を重視するのが大きな特徴だ。また、Controlの段階には、「改善を維持・管理する」の説明の通り、標準化や横展開といった考えも含まれている。まさにPDCAサイクルの改良版と言っていいだろう。 DMAICについてさらに深く掘り下げた記事として、以下も参照のこと。 シックスシグマとDMAICの関連性 - シックスシグマという言葉は一旦忘れろ PDCAの“中身”を見直すことが第一歩 もちろん、PDCAがすべて悪いわけではない。むしろ、本当に意味のあるPDCAを行っているかどうかが問題なのだ。 Planを「思いつき」で立てていないか？ Doで「やったフリ」になっていないか？ Checkが「報告書の作成」で終わっていないか？ Actionが「対策を打ったつもり」になっていないか？ もし心当たりがあるなら、PDCAを疑うところから始めてみよう。 そして次の一歩として、DMAICのような構造的に強い手法を知ることは、あなたの仕事や職場改善に大きなヒントを与えてくれるはずだ。 PDCAは、誰でもやっている“つもり”になりやすい。 だからこそ、その“中身”を問い直す視点が必要だ。そして「やってるはずなのにうまくいかない」現場こそ、PDCAのその先を考えるべきだ。