DMADV：Design for Six Sigmaの5フェーズ

DMADV（Define、Measure、Analyze、Design、Verify）は、既存のものを修正するのではなく、ゼロから何かをほぼ完璧な品質で作り上げるためのSix Sigmaフレームワークです。多くの改善ツールが壊れたプロセスから出発し、それを直そうとするのに対し、DMADVは白紙の状態から出発し、最初から品質を設計に組み込みます。チームは、新しい製品ラインを立ち上げるとき、新しいサービス提供プロセスを構築するとき、あるいは段階的な修正では対応できないほど根本的に欠陥のあるプロセスを置き換えるときに、これを使います。

この手法は、Design for Six Sigma（DFSS）というより大きなファミリーに属します。DMAICを使ったことがあれば、ロジック自体には馴染みがあるはずですが、方向性が異なります。DMAICは改善します。DMADVは設計します。

DMADVとは何か

DMADVとは、Six Sigma品質水準で顧客要件を満たす新しいプロセスや製品を設計するための、データドリブンで構造化された方法論です。この名称は、5つの連続したフェーズ、すなわちDefine、Measure、Analyze、Design、Verifyの頭文字を取ったものです。

核となる考え方はシンプルです。ローンチ後に不良を発見して慌てて修正するのではなく、何かを作る前に顧客が本当に必要としているものを正確に理解します。そのニーズを軸にプロセスや製品を設計し、厳密にテストし、それが完了して初めて実際の世界にリリースします。

**Design for Six Sigma（DFSS）**は、DMADVを含む方法論群の総称です。他のDFSSバリエーション（IDOV、DMADOV、ICOV）も存在しますが、DMADVが最も広く採用されています。その理由の一部は、5文字構造がほとんどのSix Sigma実践者が既に知っているおなじみのDMAICフレームワークを反映しているためです。

重要なポイント

• Six Sigmaは、100万回の機会あたりわずか3.4件の不良（DPMO）、すなわち99.99966%の精度という不良率を目標としています（出典：American Society for Quality）。
• Six Sigmaは1986年、モトローラのエンジニアBill Smithによって開発され、Mikel Harryによって正式に命名されました。1990年代半ばにGeneral Electricが全社的に採用したことで業界標準となりました（出典：Motorola Solutions／ASQ）。
• DFSSファミリー（DMADVを含む）はDMAICファミリーとは異なります。DFSSは、製品やプロセスがまだ存在しない場合、あるいは既存のものが目標からあまりにかけ離れており再設計しか現実的な選択肢がない場合に適用されます（出典：iSixSigma）。

DMADV対DMAIC

これはチームが最も頻繁に尋ねる質問であり、正確に理解しておく価値があります。どちらもSix Sigmaの方法論です。どちらもデータドリブンです。どちらも5フェーズ構造に従います。しかし、両者が解決する問題は根本的に異なります。

シンプルな見分け方があります。既に存在し、おおむね機能しているプロセスを目の前にしているならDMAICを使ってください。白紙のホワイトボードを目の前にしているならDMADVを使ってください。

もう1つ、有用な中間ケースがあります。プロセスは存在するものの、どれだけ改善してもSix Sigma品質に到達できないほど壊れている場合があります。そのようなときにチームはDMAICからDMADVに切り替えます。この分岐点は通常、DMAICプロジェクトのAnalyzeフェーズの終盤に訪れ、データが再設計こそが唯一の現実的な道であることを示したタイミングです。

DMADVの5フェーズ

1. Define（定義）

Defineフェーズは、プロジェクト全体のスコープ、目的、成功基準を設定します。チームはこのフェーズで3つの問いに答えます。何を作るのか。誰のためのものか。そして、成功したとどうやってわかるのか。

Defineにおける主要な活動には、プロジェクト憲章（スコープ、タイムライン、チーム、ビジネスケースを捉える1ページの文書）の作成、ステークホルダーの特定、そして高いレベルでのクリティカル・トゥ・クオリティ（CTQ）要件のマッピングが含まれます。CTQツリーは、ここで特に有用なツールです。広範なビジネス目標（顧客からの苦情を減らす）を、具体的で測定可能な要件（応答時間4時間未満、初回対応解決率99%）に結び付けます。

うまく実施されたDefineフェーズは、後で膨大な時間を節約します。チームが設計前に「成功」の意味に合意していなければ、製品が構築された後にそれについて議論することになります。

使用するツール：プロジェクト憲章、ステークホルダー分析、Voice of the Customer（VOC）インタビュー、CTQツリー。

2. Measure（測定）

Measureでは、チームは顧客が正確に何を必要としているかを定量化します。目標は、顧客の言葉（「速くしてほしい」）を測定可能な仕様（「注文処理時間は99.7%の注文で24時間を超えないこと」）に変換することです。

このフェーズには、アンケート、インタビュー、フォーカスグループ、クレームデータの分析といった構造化された顧客調査が含まれます。チームはしばしば、Quality Function Deployment（QFD、House of Qualityとも呼ばれる）を使って、顧客要件を潜在的な設計要素にマッピングし、重要度でランク付けします。

Measureフェーズでは、ベースライン、すなわち比較可能なものが存在する場合、現状がどのようなものかも確立します。これにより、チームは後で設計オプションを評価する際の参照点を得られます。

使用するツール：Voice of the Customer（VOC）、Quality Function Deployment（QFD）、ベンチマーキング、測定システム解析（MSA）。

3. Analyze（分析）

Analyzeは、単一の設計にコミットする前にチームが解決策の可能性を探るフェーズです。顧客要件から一気に設計へ飛ぶのではなく、チームは複数の潜在的なアプローチを検討し、トレードオフを評価し、最善の道筋を選択します。

このフェーズでは、異なる設計変数がどう相互作用するかをモデル化するDesign of Experiments（DOE）のような技法や、設計が構築される前にどこで失敗しうるかを特定するFMEA（故障モード影響解析）などのリスク分析ツールを使用します。チームはまた、比較可能な文脈における「優れた」がどのようなものかを理解するために、競合他社や類似プロセスをベンチマークします。

Analyzeフェーズは、文書化された意思決定で終わります。「これが今後進める設計コンセプトであり、これがその選択を裏付けるデータである」という形です。

使用するツール：FMEA、Design of Experiments（DOE）、ベンチマーキング、設計コンセプト評価、リスクアセスメント。

4. Design（設計）

Designは実際に手を動かして構築するフェーズです。チームは選ばれたコンセプトを取り上げ、ワークフロー、システムアーキテクチャ、人員配置モデル、トレーニング要件、技術仕様、管理メカニズムといった細部を詰めていきます。

Designにおける重要な規律は、早期かつ頻繁にプロトタイプを作ることです。パイロットテスト、シミュレーション、小規模な試行により、変更が安価なうちに問題を発見できます。例えば、新しい顧客オンボーディングプロセスは、数千人にロールアウトする前に、まず20人の顧客の単一コホートでテストされるかもしれません。

このフェーズには、標準作業手順、管理計画、トレーニング資料、そしてローンチ後にパフォーマンスを追跡する測定システムといった詳細な文書化も含まれます。

使用するツール：詳細プロセスマップ、バリューストリームマッピング、シミュレーション、パイロットテスト、プロトタイプ開発、管理計画の設計。

5. Verify（検証）

Verifyは、本格展開の前の最終ゲートです。チームは、新しい設計がDefineとMeasureで確立された顧客要件を実際に満たしているかを検証します。これは一度きりのテストではなく、現実的な条件下での体系的な検証です。

検証には通常、パイロットローンチ（実際の、ただし限定された顧客や業務に対する制御されたロールアウト）、プロセスがSix Sigma目標に近い水準で稼働していることの統計的な妥当性検証、そして日々このプロセスを運用する現場チームへの移行計画が含まれます。

Verifyで設計の実際のパフォーマンスと要件との間にギャップが見つかった場合、チームはDesign（場合によってはAnalyze）に戻ってそれに対処します。Verifyは、データが設計が準備できていることを確認して初めて完了します。

使用するツール：パイロットスタディ、能力分析、受け入れテスト、移行計画、管理計画の引き継ぎ。

DMADVを使うべきとき

DMADVは、次の4つの状況で正しい選択となります。

1. まったく新しいものを構築している場合。 新製品ライン、新サービス、新市場への参入。プロセスがまだ存在しないため、改善すべき既存プロセスがありません。

2. 既存プロセスが手遅れの場合。 DMAIC分析によって、既存プロセスが構造的に欠陥を抱えており、修正するコストが置き換えるコストを上回ることが明らかになる場合があります。データがこれを示したら、DMADVへの切り替えが合理的な選択です。

3. 顧客要件が根本的に変化した場合。 異なる顧客基盤、異なる技術環境、異なる規模のために設計されたプロセスは、単純に維持できないことがあります。要件が40%以上変化している場合、再設計が段階的な改善に勝ることがよくあります。

4. 新しい規制や品質基準を満たすためにプロセスを置き換える場合。 新しいコンプライアンス要件が既存プロセスでは実現できない能力を義務付けている場合、DMADVは準拠版をゼロから構築するための明確な道筋を与えてくれます。

DMADVが適さないのは、おおむね機能しているが特定の識別可能な不良を持つプロセスの修正です。それはDMAICの領域、あるいは場合によってはTotal Quality Managementの継続的改善サイクルの領域です。

DMADVのメリット

検査で見つけるのではなく、品質を設計に組み込む。 従来の製品開発は、ローンチ後に不良を発見します。DMADVは、設計開始前に要件を検証するため、最初の顧客がそれを目にする前に不良を発見します。

総コストの低減。 不良を修正するコストは、開発ライフサイクルを通じて急激にエスカレートします。Analyzeフェーズで発見された欠陥は、完全な展開後に発見された欠陥のごく一部のコストで済みます。DMADVが要件とプロトタイピングに投じる初期投資は、ほぼ常に回収されます。

顧客との整合性。 Measureフェーズが（チームの想定ではなく）顧客が実際に必要としているものを体系的に捉えるため、DMADVによって生み出される設計は実際のユーザーにより良く受け入れられる傾向があります。

明確な説明責任。 構造化された5フェーズのゲートシステムにより、チームメンバー全員がどの意思決定がどのフェーズに属するかを把握できます。これにより、多くの新製品ローンチを頓挫させる「委員会による設計」の漂流が減ります。

スケーラブル。 DMADVは、単一の社内ワークフローの設計からグローバル製品ラインのローンチまで、あらゆる規模で機能します。

よくある間違い

Designから始めてしまう。 DefineとMeasureを飛ばしていきなり設計に取り掛かるチームは、顧客が何を必要としているかを推測しているにすぎません。推測は手戻りを生みます。

Verifyをチェックボックスとして扱ってしまう。 Verifyは承認会議ではありません。実際の条件下での統計的な妥当性検証です。Verifyを急ぐチームは、設計がテストではうまくいっていても、規模を拡大すると破綻することをローンチ後に発見することがよくあります。

DMADVとDMAICを混同してしまう。 再設計すべきプロセスに対してDMAICプロジェクトを始めると、何か月も無駄にします。分岐点は早い段階にあります。既存プロセスが修復不能なほど壊れているなら、改善作業に投資する前にフレームワークを切り替えてください。

管理計画を軽視してしまう。 DMADVは設計を生み出しますが、その設計を何年にもわたって運用するのは誰かです。運用への引き継ぎが弱いと、新しいプロセスは、それが避けるために設計された不良へと逆戻りしてしまいます。管理計画とトレーニング資料は、設計そのものと同じくらい重要です。

Analyzeで FMEAを省略してしまう。 Analyzeフェーズにおけるリスク分析は、製品が構築される前に破滅的な故障モードを見つける場です。FMEAを省略したり、表面的にしか扱わなかったりするチームは、その故障モードを本番環境で発見することになります。

DMADVの実例：新しいクライアントオンボーディングプロセスの設計

あるB2Bソフトウェア企業が、大型パートナーシップ契約によって通常の3倍の新規顧客を獲得しました。既存のオンボーディングプロセスは、月間20社の新規顧客向けに構築されていました。今では月間60社に対応する必要があり、直近のオンボード顧客の満足度スコアは既に22ポイント低下しています。チームは、既存プロセスが根本的な再設計なしにはスケールできないと判断し、DMADVプロジェクトを開始しました。

再設計されたプロセスは、増加した量に対応し、すべてのCTQ目標を達成しました。決定的だったのは、Analyzeで実施したFMEAで特定された3つの重大な故障モードのいずれも、パイロット中に発生しなかったことです。設計段階で既にそれらに対処していたからです。

よくある質問

DMADVは何の略ですか

DMADVは、Define、Measure、Analyze、Design、Verifyの略です。それぞれの単語が、この方法論の5つの連続したフェーズの1つを表しています。

DMADVはSix Sigmaの一部ですか、それともLeanの一部ですか

DMADVはSix Sigmaの方法論であり、具体的にはDesign for Six Sigma（DFSS）ファミリーの一部です。Leanとは別のものですが、チームがプロセスを設計する際にLeanの原則とDMADVを組み合わせることもあります。またDMADVは、両者が最初の3フェーズの名前を共有しているものの、Leanを主軸としたDMAIC方法論とも区別されます。

小規模チームでもDMADVを使えますか、それとも大企業専用ですか

DMADVは規模を縮小してもうまく機能します。3〜4人のチームであれば、新しい社内ワークフローに対する簡易版DMADVプロジェクトを6〜8週間で実行できます。各フェーズの厳密さは、プロジェクトの複雑さに応じて調整されます。縮小できないのはデータの規律です。小規模なプロジェクトであっても、顧客要件を測定し、それに対して設計を検証する必要があることに変わりはありません。

DMADVプロジェクトにはどのくらい時間がかかりますか

スコープによってタイムラインは変わりますが、ほとんどのDMADVプロジェクトは3〜9か月で実施されます。DefineとMeasureを合わせると通常4〜8週間かかります。AnalyzeとDesignが最も時間を要し（合計8〜16週間）、Verifyはパイロットを含めて4〜8週間かかります。複雑な製品設計や大規模なプロセス再設計は、さらに長くかかることもあります。

DMADVに関連する認定資格は何ですか

DMADVは標準的なSix Sigma認定トラックの中でカバーされています。グリーンベルト認定でこのフレームワークが紹介され、ブラックベルト認定ではDMADVプロジェクトを主導するための実践者育成が行われます。一部の組織は、DFSS専用の認定資格を提供しています。American Society for Quality（ASQ）とIASSCが、最も認知されている認定団体です。

---

まだ存在しないものを設計する場合、あるいは修正するには壊れすぎたものを置き換える場合、DMADVは顧客ニーズから検証済みの設計までの構造化された道筋を提供します。5つのフェーズは、適切なタイミングで適切な議論を強制します。顧客が実際に何を必要としているか（DefineとMeasure）、そのニーズを満たす最善の方法は何か（Analyze）、それをどう構築するか（Design）、そして実際にうまく機能するか（Verify）です。

既にDMAIC改善サイクルを運用しているチームにとって、DMADVは自然な補完となります。一方は既存のものを改善するためのフレームワーク、もう一方は存在しないものを設計するためのフレームワークです。これらのプロジェクトを主導する実践者は、Six Sigmaベルト制度を通じて資格を取得し、DPMOとシグマレベルのような品質目標に対して完成した設計を検証します。バリューストリームマッピング、FMEA、Total Quality Managementの実践といったツールと合わせて、DMADVは「最初から正しく作る」ことを志向する完全な品質管理システムに組み込まれています。