DMAIC(定義、測定、分析、改善、制御)[1](発音はdə-MAY-ick)は、ビジネスプロセスと設計を最適化および安定化するために使用されるデータ駆動型の改善サイクルを指します。DMAIC改善サイクルは、シックスシグマプロジェクトを推進するために使用される中核ツールです。ただし、DMAICはシックスシグマ専用ではなく、他の改善アプリケーションのフレームワークとして使用できます。[2]

手順
DMAIC は、定義、測定、分析、改善、制御という 5 つの改善ステップの略称です。DMAIC プロセス ステップはすべて必須であり、常に指定された順序で進行します。
定義する
このステップの目的は、ビジネス上の問題、目標、潜在的なリソース、プロジェクトの範囲、およびプロジェクトのタイムラインの概要を明確にすることです。この情報は通常、プロジェクト憲章文書に記録されます。この段階では、現在わかっていることを書き留め、事実を明らかにし、目標を設定し、プロジェクト チームを編成します。次の項目を定義する必要があります。
- 問題
- 顧客、SIPOC
- 顧客の声(VOC) と 品質に対する重要事項(CTQ) — 重要なプロセス出力とは何ですか?
測定
このステップの目的は、問題/目標の仕様を測定することです。これはデータ収集ステップであり、その目的はプロセス パフォーマンス ベースラインを確立することです。測定フェーズのパフォーマンス メトリック ベースラインは、プロジェクト終了時のパフォーマンス メトリックと比較され、大幅な改善が行われたかどうかを客観的に判断します。チームは、測定対象と測定方法を決定します。チームが提案された測定システムの適合性を評価するために多大な労力を費やすことはよくあります。DMAIC プロセスの中心にあるのは、適切なデータです。
分析する
このステップの目的は、排除すべき根本原因を特定、検証、選択することです。プロジェクトの問題の多数の潜在的な根本原因 (プロセス入力、X) は、根本原因分析 (たとえば、フィッシュボーン ダイアグラム) によって特定されます。上位 3 ~ 4 つの潜在的な根本原因は、さらに検証するために、マルチ投票またはその他のコンセンサス ツールを使用して選択されます。データ収集計画が作成され、データが収集されて、各根本原因のプロジェクト メトリック (Y) に対する相対的な寄与が確立されます。このプロセスは、「有効な」根本原因が特定されるまで繰り返されます。シックス シグマでは、複雑な分析ツールが使用されることがよくあります。ただし、適切な場合は、基本的なツールを使用することもできます。「検証された」根本原因のすべてまたは一部は、検証済みである可能性があります。[説明が必要]
- 問題の潜在的な原因をリストアップし、優先順位を付ける
- 改善ステップで追求する根本原因(主要なプロセス入力)を優先順位付けする
- プロセス入力 (X) がプロセス出力 (Y) にどのように影響するかを特定します。データは、プロジェクト メトリック (Y) に対する各根本原因 (X) の寄与度を理解するために分析されます。このために、ヒストグラム、パレート図、折れ線グラフを伴う p 値を使用した統計テストがよく使用されます。
- 詳細なプロセス マップを作成すると、プロセスのどこに根本原因が存在するか、何がその発生に寄与しているかを正確に特定するのに役立ちます。
改善する
このステップの目的は、状況に応じて、部分的または全体的に、問題の解決策を特定、テスト、実装することです。プロセスの問題を修正および防止するために、主要な根本原因を排除する創造的な解決策を特定します。ブレーンストーミングや、6 つの思考ハットやランダム ワードなどの手法を使用できます。一部のプロジェクトでは、実験計画法(DOE)などの複雑な分析ツールを利用できますが、明らかな解決策がある場合は、それに焦点を当てるようにしてください。ただし、このステップの目的は、実装せずに解決策を見つけることである場合もあります。
- 作成する
- 最もシンプルで簡単な解決策に焦点を当てる
- 計画・実行・確認・改善(PDCA)サイクルを使用してソリューションをテストする
- PDCAの結果に基づいて、故障モード影響解析(FMEA)を使用して「改善」に関連する回避可能なリスクを予測します。
- 詳細な実装計画を作成する
- 改善を展開する
コントロール
このステップの目的は、変更を定着させ、持続可能性を確保することです。これは、変更を「定着させる」とも呼ばれます。制御は、DMAIC改善方法の最終段階です。このステップでは、作業方法の修正、メリットの定量化と承認、改善の追跡、プロジェクトの正式な終了、リソースのリリースの承認の取得などのプロセスが実行されます。[3]
- 管理図は、1. プロセスを継続的に監視するためのガイドとして機能し、2. プロセスが不安定になった場合に監視対象の各対策に対する対応計画を提供することで、管理段階で時間の経過に伴う改善の安定性を評価するのに役立ちます。
- 標準操作手順(SOP)と標準作業
- プロセスの確認
- 開発計画
- 移行計画
- 管理計画
- 給付金の支給
批判
DMAIC に対するよくある批判の 1 つは、コミュニケーション フレームワークとしては効果がないというものです。多くの改善実践者は、問題解決に効果的な DMAIC プロセスをコミュニケーションのフレームワークとして使用しようとしますが、その結果、聴衆は混乱し、不満を募らせるだけです。この問題に対する 1 つの解決策として提案されているのは、ミント ピラミッド原則の SCQA および MECE ツールを使用して DMAIC 情報を再編成することです。その結果、わかりやすいロジックでサポートされたフレームワーク ソリューションが生まれます。[1]
追加手順
いくつかの組織では、最初に認識ステップを追加し、RDMAIC方法論を生み出しています。[ 4 ]
繰り返してチームに感謝する
これは、標準的な DMAIC 手順に追加されるものですが、検討する必要があります。他のプロセスでの変更の再現を検討してください。組織内外で新しい知識を共有してください。DMAIC の効果を最大限に高めるには、チーム メンバーに常に前向きな士気サポートを提供することが非常に重要です。
改善を再現し、成功を共有し、チーム メンバーに感謝することで、将来の DMAIC または改善イニシアチブへの賛同を得ることができます。
参照
参考文献
- ^ ab Pruitt, W. Frazier (2020年5月). 「Some Assembly Required」. asq.org . 2020年8月12日時点のオリジナルよりアーカイブ。2020年9月25日閲覧。
- ^ Borror, Connie M. 編 (2009)。認定品質エンジニア ハンドブック(第 3 版)。ASQ Quality Press、ウィスコンシン州ミルウォーキー。ISBN 978-0-87389-745-7。
- ^ 「DMAIC | コントロールステージ - InvisibileConsultant.co.uk」。InvisibileConsultant.co.uk 。2018年9月29日閲覧。[永久リンク切れ ]
- ^ ウェバー、ラリー、ウォレス、マイケル(2006年12月15日)。『品質管理 for Dummies』。42~43ページ。ISBN 978-0-470-06909-7. 2012年5月16日閲覧。
