シックスシグマとは?DMAICの実践ガイド
シックスシグマとは?ばらつきを抑えて不良を減らす手法です。シグマ水準やDMAICの進め方、データを改善サイクルに役立てる方法を解説します。
シックスシグマとは、目標であり、手法でもあります。不良を定義し、発生頻度を測定し、ばらつきの原因を特定して取り除き、改善効果が続いているかを確認します。DMAICは、Define(定義)、Measure(測定)、Analyse(分析)、Improve(改善)、Control(管理)の頭文字を取ったものです。問題の特定から、安定したプロセスの実現までを導く改善サイクルです。
シックスシグマは高く評価されており、実践する人の多くは、手法が有効かどうかを議論したいわけではありません。改善を証明できるようにしたい、そして証明に1年ではなく数週間で済ませたいと考えています。このガイドでは、シックスシグマとは何か、DMAICの各段階で何をするのか、プロセスインテリジェンスによって手法の厳密さを保ちながら改善サイクルを速める方法を解説します。
シックスシグマとは
シックスシグマは、ばらつきを抑えて不良の発生頻度を減らし、結果を予測しやすくする手法です。プロセスが常に同じ方法で同じ結果を生み出せれば、品質を維持しやすくなります。似たケースの結果が異なる場合、その差を減らすことがシックスシグマの目的です。
この手法は1986年にモトローラが開発し、1990年代にゼネラル・エレクトリックが導入しました。品質を数値で測れるようにしたことから、製造、医療、金融サービス、シェアードサービスなどに広がりました。
名称は、標準偏差を表す統計記号に由来します。シックスシグマの水準は、プロセスのパフォーマンス目標です。プロセスの自然なばらつきが規格限界の内側に標準偏差6つ分収まると、不良の発生頻度は低くなります。
| シグマ水準 | 機会100万回あたりの不良数 | 数値が示す内容 |
|---|---|---|
| 3シグマ | 66,800 | シックスシグマの目標に比べて不良率が高い状態 |
| 4シグマ | 6,200 | 不良が減っているものの、ばらつきを抑える余地がある状態 |
| 5シグマ | 230 | 不良率が低い状態 |
| 6シグマ | 3.4 | 不良率が非常に低い状態 |
これらは手法で標準的に使われる数値ですが、注意点もあります。不良率の精度は、機会の定義と、その根拠となるデータの網羅性に左右されます。そのため、DMAICの最初の段階では統計分析よりも、明確な定義と認識合わせを重視します。
DMAICのプロセスとは
DMAICは、既存のプロセスを改善するための5段階のサイクルです。各段階で異なる問いに答え、その結果を次の段階で使います。この流れによって、シックスシグマによるプロセス改善を一度限りの取り組みではなく、繰り返し実施できるようになります。
Scope the problem
Establish the baseline
Find the causes
Test the change
Sustain the gain
一方通行の工程ではなく、繰り返すサイクルとして捉えると、5つの段階は多くの改善活動に共通する流れを示しています。プロセスを理解し、測定し、結果の理由を分析し、変更を加え、その変更を維持します。不都合だからといって段階を省かないことが、名称以上に大切です。
データより先に文書化が必要な理由
DMAICプロジェクトの成否を左右するのがDefine(定義)です。統計分析よりも、明確な認識をそろえることが大切です。不良を測定する前に、プロセスの内容、開始点と終了点、担当者、目指す状態を定める必要があります。
この段階は、実際には多くのプロジェクトで省かれています。チームはワークショップで問題に合意すると、すぐにデータを抽出します。その後、ボトルネックだと思っていたステップがシステムに記録されていない、あるいは同じ名前のプロセスを3つの部門がそれぞれ異なるものとして説明している、といった事実が分かります。誰も合意していないプロセスは、測定しても改善できません。
文書化を行うことで、以降の改善サイクルを進められるようになります。
- チームが現状をどう理解しているかを、ステップ、判断、引き継ぎとともに示すプロセスモデル。スライドではなく、BPMN 2.0で作成します。
- そのモデルにひも付いた不良の定義 。これにより、Measure(測定)でDefine(定義)時に合意した内容を数えられます。- 各アクティビティのロールと担当者 。Improve(改善)で変更を承認できる人が明確になります。- 作業で実際に使う文書:手順、ポリシー、テンプレート、画面操作の説明などを、該当するアクティビティに添付します。
ProcessMindでは、文書を古くなりやすいフォルダーに置くのではなく、モデルと並べて管理し、常に最新の状態に保てます。チームはAIによるプロセスモデルの作成で初稿を作り、モデリングキャンバスで調整し、関連する手順や画面操作を成果物として添付できます。さらに、バージョン履歴を使ってレビューを進められます。公開したバージョンは、作業を担当する人がProcess Portalで確認できます。そのため、プロジェクトで測定するプロセスを、関係者全員が参照できます。プロセスの文書化とモデルを1つのワークスペースで管理することで、両者の内容が食い違うのを防げます。
DMAICの各段階で行うこと
各段階には明確な成果物があります。また、実際の作業で時間がかかりやすい箇所も表に示しています。プロセスインテリジェンスによって変わるのは、主にこの部分です。
| 段階 | 問い | 成果物 | 主な作業 |
|---|---|---|---|
| Define(定義) | どのような問題を、誰のために解決するのか | 対象範囲を定めた問題の説明、文書化されたプロセス、不良の定義 | ワークショップ、プロセスモデル、作業で使う文書 |
| Measure(測定) | 現在のプロセスはどのように機能しているか | サイクルタイム、不良、ばらつきのベースライン | 手作業によるサンプリングとレビュー、またはイベントログ1つ |
| Analyse(分析) | ばらつきの原因は何か | 問題の要因を示す根拠 | グラフや仮説を実際のケースと照合して検証 |
| Improve(改善) | 原因に対処する変更はどれか | 検証と測定を行った変更 | 試験導入、または展開前のシミュレーション |
| Control(管理) | 改善効果をどう維持するか | 標準的な作業方法と継続的なモニタリング | ダッシュボード、しきい値、明確な担当者 |
多くの取り組みでボトルネックになるのはMeasure(測定)です。ベースラインを手作業で作ると数週間かかり、確認する時間があったケースだけが対象になります。Analyse(分析)を始める頃には、データが古くなっていることもあります。プロセスマイニングは、DMAICのこの部分を変えます。
プロセスマイニングでDMAICを支援する方法
プロセスマイニングは、システムに記録されたイベントデータから、ケースが実際にプロセスをどう進んだかを再構成します。ケースID、アクティビティ、タイムスタンプが記録されたログがあれば、実際の経路やバリアント、待ち時間、手戻りを確認できます。
説明ではなく測定に基づく根拠を使うことで、改善サイクルを具体的に支援できます。
- **Measure(測定):**確認する時間があったケースのサンプルではなく、記録されたすべてのケースからベースラインを作成します。
- **Analyse(分析):**バリアントを比較して遅延や手戻りが集中する箇所を特定し、最も声の大きい人の意見ではなく、データに照らして原因の仮説を検証します。
- **Control(管理):**プロジェクト終了後も同じ測定を続け、以前の作業方法に戻り始めたら早期に把握できるようにします。
プロセスマイニングはシックスシグマに取って代わるものではなく、Define(定義)やImprove(改善)で必要な検討の代わりにもなりません。Measure(測定)を遅らせ、Control(管理)を不安定にする手作業でのデータ収集や確認を置き換えます。機能の詳細はプロセスマイニングのページで、プロセスの流れを再構成する方法はプロセスマイニングの文書でご覧いただけます。分析では、DMAICチームがまずプロセスバリアントと適合性チェックを確認します。
プロセス分析とダッシュボードで改善効果を維持する方法
Control(管理)では、改善が気付かれないまま失われることがあります。プロジェクト終了後に測定されない変更は、その妥当性を説明できません。誰も開かないダッシュボードも、管理の仕組みとは言えません。
プロセス分析を使えば、プロセスオーナーが測定結果に基づいて対応できます。サイクルタイムや不良の傾向をベースラインと比較し、文書化されたモデルへの適合性を確認し、数値を報告するだけでなく対応が必要なタイミングをしきい値で示します。ProcessMindでは、ブックマークにレビューで使うフィルターと測定値を保存できます。プロセスヘルスでは各指標の基準範囲を設定し、ダッシュボードと重要業績評価指標(KPI)で担当者が確認しやすい場所に結果を表示します。表示の作成方法はカスタムダッシュボードの文書をご覧ください。
管理図を確認する際と同じ基準で評価できます。担当者は、この表示としきい値から、先月に比べてプロセスが変化したか判断できるでしょうか。判断できない場合、Control(管理)は管理の仕組みではなく、単なる文書になっています。
シックスシグマのベルト資格とロール
ベルトの名称はシックスシグマの取り組みにおけるロールを示し、どのプロジェクトを誰が主導できるかを把握する目安になります。組織によって役割は異なりますが、一般的には次のように分かれます。
- **チャンピオンまたはスポンサー:**リソースを確保し、障害を取り除く管理者です。
- **マスターブラックベルト:**プロジェクトチームを指導し、手法に沿った取り組みを支える経験豊富な実践者です。
- **ブラックベルト:**DMAICの取り組みを進めるプロジェクトリーダーです。
- **グリーンベルト:**通常業務と並行してプロジェクトを主導する実践者で、多くの場合、1つの部門内で活動します。
- **イエローベルトまたはホワイトベルト:**プロセスの知識やデータを提供するチームメンバーです。
データに基づくDMAICの改善サイクルは、ベルトの色に左右されません。プロジェクトには、変更を承認できるプロセスオーナー、根拠を読み取れる人、測定結果を率直に確認するチームが必要です。資格名はその目安にすぎず、大切なのは実際の取り組みです。
リーンとシックスシグマの違い
リーンとシックスシグマは、それぞれ異なる問いに答える手法です。両者の混同は、主に名称の分かりにくさから生じています。
- リーンはムダを減らし、作業の流れを改善します。作業の流れにおける待ち時間、引き継ぎ、過剰な処理、在庫、移動、不良に着目します。
- シックスシグマはばらつきや不良を減らします。測定と分析を通じて、似たケースの結果が異なる理由を明らかにします。
リーンシックスシグマはリーン6シグマとも表記され、両者を組み合わせた手法です。リーンで作業の流れを整え、シックスシグマで結果のばらつきを抑えます。「リーンとシックスシグマ」や「シックスシグマとリーンシックスシグマ」は別々の手法のように語られることがありますが、実際には同じ組み合わせを指しており、どちらから取り組むかは問題によって異なります。遅くても安定しているプロセスでは、まずリーンの考え方が役立ちます。速くても一貫性がないプロセスでは、まずばらつきに対処します。バリューストリームマッピングのガイドではリーンの側面を、プロセス改善手法の一覧では両者をプロセスマイニングやシミュレーションと比較しています。
DMAICを改善の軸にする理由
繰り返し使えるのが改善サイクルだからです。ベルト資格、統計分析、プロジェクト憲章は、どのチームでもあらゆるプロセスで実行できるサイクルを支えるものです。サイクルを重ねるごとに、次の改善にかかるコストを抑えられます。
シックスシグマだけがプロセス改善の方法だと考えているわけではありません。また、この手法を擁護する必要があるとも考えていません。DMAICが改善の軸であり、ツールを使ってそのサイクルを速めることが大切です。
私たちはDMAICを改善の軸と捉えています。モデリングでプロセスを明確にし、プロセスマイニングで実際に起きたことを把握し、シミュレーションで変更を事前に検証し、プロジェクト終了後もモニタリングで改善効果を維持します。シックスシグマはこのサイクルに統計分析を加えるもので、業界やデータの状況に応じて必要な場合に取り入れます。DMAIC自体はあらゆる場面で使えるため、シックスシグマが適するところで取り入れ、改善サイクルは幅広く実行できます。
この考え方がプラットフォームの設計にも反映されています。シックスシグマに対抗するのではなく、チームに必要なのは改善サイクルであり、その測定には組織がすでに持っているデータを使うべきだと考えています。そのため、リーンシックスシグマとDMAICのガイドでは、各段階にデータを使った成果物を示しています。
シックスシグマが適さない場合
不良を定義し、信頼性の高い測定を行い、減らす価値のあるばらつきを見つけられる場合、シックスシグマが力を発揮します。大量の反復作業があるプロセスや、規制によって品質基準が定められている業界で特に適しています。一方、主な問題がばらつきではなく作業の流れにある場合、プロセスが新しい場合、または必要なデータがまだない場合は、適さないことがあります。
だからといってDMAICを使わない理由にはなりません。問題を定義し、測定できるものを測り、原因を探り、変更を加えて、その変更を維持するというサイクルは変わりません。変わるのは、どこまで統計分析を行うかです。オンボーディング、営業パイプライン、サービスデスクを改善するチームでは、実験計画法が必要ない場合もあります。一方、生産ラインの不良を減らすチームでは、必要になる可能性が高いでしょう。プロセスが新しく、問題が起きていない場合は、Design for Six Sigma(DMADV)を検討します。問題がばらつきではなく待ち時間にある場合は、リーンの手法が役立ちます。
シックスシグマのプロジェクトを始める方法
最短で始めるには、数か月ではなく数週間で根拠を得られる方法を選びます。
-
プロセスの内容を書き出す
プロセスの開始点と終了点、担当者、対象とする不良を明確にします。会議よりもモデルのほうが、プロセスについて意見を交わしやすくなります。 -
サンプルを取る前にデータを確認する
対象のプロセスについて、システムにケースID、アクティビティ、タイムスタンプが記録されているか確認します。記録があれば、Measure(測定)はログから始められます。 -
バリアントを含め、実際の流れを測定する
想定外の経路をたどるケースを数えます。ここで見るのはばらつきです。平均値だけでは、その原因を見落とします。 -
変更は1つずつ試す
展開前にシミュレーションで選択肢を比較します。その後、根拠に基づいて選んだ変更を試験導入し、何が変わったか測定します。 -
担当者に管理を引き継ぐ
ベースライン、測定値、しきい値をプロセスオーナーが確認できる場所に置き、レビューで改善効果が維持されていると確認できたら完了します。
シックスシグマの最初のプロジェクトから変わらない原則は、改善方法を決める前にプロセスを測定することです。変わったのは、測定を手作業で行う必要がなくなったことです。手法の全体像はデータに基づくDMAICガイドをご覧ください。モニタリングについては、プロセスを継続的にモニタリングする方法をご覧ください。
1つのプロセスで改善サイクルを始める
You have the method and the phases. The next move is to run one turn of the loop on a process you own, starting from data you already have.