DMEDIプロセス

DMEDIは、Define、Measure、Explore、Develop、Implementの段階を通じて、新しい製品やプロセスを設計する進め方です。
シックスシグマ設計で使われるロードマップの一つとして、ASQの教材でも紹介されています。

既存の仕組みを測って不具合を減らすだけでは、必要な性能やサービスを実現できないことがあります。
DMEDIでは、最初から一つの解決策を前提にせず、要求の把握と代替案の探索を経て、設計を具体化し、実際の運用に導入します。

要求を決めてから解決策を探す

仮に、修理品の受付サービスを新しく作るとします。
Defineでは、顧客が困っていること、事業として実現したいこと、対象とする製品や地域を明確にします。
受付画面を作ることが、直ちにプロジェクトの目的になるわけではありません。
顧客が求めているのは、修理の可否や費用、完了時期を早く知ることかもしれません。

Measureでは、こうした要求を判断可能な条件にします。
見積もり回答までの時間、必要な再問い合わせの回数、対応可能な製品の範囲などを定めます。
新しいサービスでも、既存の問い合わせ記録や顧客への調査から基礎データを集められます。

Exploreでは、要求を満たす複数の仕組みを比較します。
写真による事前診断、店舗での受付、集荷後の診断では、顧客の負担も費用も異なります。
評価基準を決め、重大な不確実性がある案は試作や小規模な実験で確かめます。

設計を運用へつなげる

Developでは、選んだ案を詳細な手順やシステムに落とし込みます。
受付から診断、見積もり、顧客への連絡までをつなぎ、混雑時や情報不足の場合も検討します。
個別の画面が使いやすくても、担当者間の引き継ぎで止まるなら、サービス全体としては要求を満たしません。

Implementでは、担当者の教育、導入範囲、品質を確認する方法を整えて運用を始めます。
限定した地域や製品から導入すれば、想定と実態の違いを把握しやすくなります。
目標を満たした条件と、未確認の条件を分けて記録し、拡大の判断に使います。

各段階の成果を明確にする

DMEDIという名称だけでは、必要な成果物や審査条件は決まりません。
組織で採用する場合は、各段階で何を判断し、誰が責任を持ち、どの証拠をそろえるかを定めます。

IDOVなどの別のロードマップとも、段階名だけで優劣はつけられません。
既存の開発手順と重ねて会議や文書を増やすより、要求から導入後の品質まで、確認が抜けている箇所を補う使い方が有効です。

参考資料