リーンシックスシグマとDMAIC：データに基づくリーンプロセス改善

リーンプロセス改善では、業務の時間や品質が損なわれている箇所を特定し、根拠に基づいて改善策を検証します。このガイドでは、リーンシックスシグマとDMAICが改善をどう支えるのか、各段階で必要なデータ、受注から入金までのプロセスへの適用方法を解説します。根拠を示せるベースライン、仮説を検証する分析、改善を定着させる管理に焦点を当てます。

リーンによるプロセス改善は、ツールを集めることだけではありません。DMAICを使うと、プロセスを調査し、変更内容を決めるための実践的な枠組みを得られます。

リーンシックスシグマとは何か、何ではないか

リーン、シックスシグマ、リーンシックスシグマには関連がありますが、それぞれ異なる課題に取り組みます。

リーンは、待ち時間、不要な引き継ぎ、手戻りなど、価値を生まない業務を減らすことを目指します。シックスシグマは、ばらつきや不良を減らすことを目指します。リーンシックスシグマは、構造化された改善活動の中で両方の目標に取り組みます。

バリューストリームマッピングを含むリーンマッピングは、業務がどのように進むべきかを図で表すのに役立ちます。プロセスデータを加えると、ケースがシステム上で実際にどのように進んでいるかも確認できます。マップとデータを組み合わせることで、期待と実際のプロセスにどのような違いがあるか、チームで話し合うための土台ができます。

リーンシックスシグマではないものを明確にしておくことも大切です。

• **認証プログラムではありません。**ベルトは研修の形式です。資格を取得しても、測定済みのベースラインや実際の改善プロジェクトに代わるものではありません。
• **プロセスに関する知識の代わりにはなりません。**DMAICは調査の進め方を整理しますが、チームが業務の内容や制約を理解している必要があります。
• **一度きりのプロジェクトではありません。**コントロールフェーズでは、プロジェクトチームが離れた後もプロセスを監視する方法を定めます。
• **製造業に限られません。**オフィス業務にも、待ち時間、手戻り、引き継ぎ、不要な手順があります。

DMAICに必要なのは意見ではなくデータ

DMAICに測定フェーズがあるのは、プロセスが改善したかどうかを判断する前に、ベースラインが必要だからです。ベースラインがなければ、分析が誰の記憶が正しいかをめぐる議論になりかねません。

手作業での観察やサンプリングは、プロセスの理解に役立ちます。ただし、対象となるのは観察したケースや手順に限られます。オフィス業務では、ERP、CRM、チケット管理システム、スプレッドシートなど、複数のシステムにまたがって業務が進むことがあります。1人の観察者が、すべてのケースを最初から最後まで確認するのは困難です。

システムにケース参照情報、アクティビティ、タイムスタンプが記録されていれば、そのイベント記録から、ケースがプロセスをどのように進んだかを再構成できます。観察内容を手作業で集める代わりに、データの確認と結果の解釈に取り組めます。プロセスマイニングは、プロセス全体にわたるこうした記録を調べる方法の1つです。

文書に記載された業務と実際の業務を比べると、次の2種類のずれが見つかることがあります。

• **図にはあるものの、実際には行われていない手順。**管理上の確認が行われなくなっていたり、承認が不要になっていたりする場合があります。
• **実際には行われているものの、図には記載されていない手順。**明確な責任者や確認手順がないまま、回避策が日常業務になっている場合があります。

リーンプロセス改善におけるDMAICの5つのフェーズ

DMAICは、定義、測定、分析、改善、コントロールの5つの標準フェーズで進めます。各フェーズでは異なる問いに答え、それぞれ異なる成果物を作成します。これらのリーンプロセス改善の手順に沿って、問題を明確にするところから、変更後の状況を監視するところまで進められます。

定義：問題、対象範囲、CTQを設定する

**データで置き換えるもの：**対象となるケースやアクティビティに関する推測。

解決したい問題、プロセスの境界、顧客や事業にとって重要な品質特性（CTQ）を定めます。まず、1つのケースを何とするかを合意しましょう。注文、チケット、請求書、請求案件などがケースにあたります。この定義によって、どのイベントをまとめるかが決まり、その後のすべての測定に影響します。

プロセスデータを使って、チームの当初の見方が現在の業務の実態と一致しているか確認します。分析によって、ワークショップでは挙がらなかったばらつきや測定項目が見つかることもあります。チームが同じ全体像を確認できるよう、プロセスマップやBPMN図に対象範囲を記録します。

**目指す成果：**1つのチームが責任を持てる対象範囲、全員が理解できるケース定義、利用可能なデータで測定できるCTQ。

測定：サイクルタイム、コスト、手戻りのベースラインを設定する

**データで置き換えるもの：**現在のパフォーマンスを表す代わりに使われる推定値や少数のサンプル。

定義フェーズで合意したCTQに照らして、プロセスを測定します。利用できるデータやプロジェクトの対象範囲に応じて、ケースごとのサイクルタイム、コスト、手戻りなどをベースラインに含めます。

プロセスが複数のシステムにまたがる場合は、それぞれの記録をどのように結び付けるか確認します。合意したケースIDを使ってログを結合すれば、システムをまたいでケースを追跡できます。結果を判断に使う前に、結合方法と元のタイムスタンプを検証してください。不完全または誤った結合によって、実際より確かなベースラインに見えることがあります。

目標を設定する前に、ベースラインを使って現在のパフォーマンスを把握します。抽出しやすいという理由だけで指標を選ぶのではなく、問題の定義に沿った測定項目を選びましょう。

**目指す成果：**プロセス責任者が確認でき、前提条件やデータの制約も明らかなベースライン。

実際のプロセスデータからベースラインを設定する方法をご紹介します。

分析：ボトルネック、バリアント、適合性のずれを見つける

**データで置き換えるもの：**実際のプロセスの動きと照らし合わせていない、ワークショップでの仮説。

パフォーマンスにばらつきが生じる理由を理解するため、根拠を分析します。遅延がどこに集中しているか、どのようなプロセスのバリアントがあるか、一般的でない経路をたどるケースがどれほどあるか、ケースが意図したプロセスとどこで異なるかを確認します。

プロセスのバリアントとは、ケースがプロセス内を進む経路の違いです。バリアントを比較すると、遅延が広く発生しているのか、特定の経路に集中しているのかを把握できます。適合性分析では、実際の動きと意図したプロセスを比較し、両者の違いを特定します。

影響度に基づいて原因の候補に優先順位を付け、データと照らし合わせて検証します。分析の結果、チームの当初の仮説が裏付けられることもあれば、主な制約が別の場所にあると分かることもあります。実際の手順については、プロセスを分析してボトルネックを見つける方法をご覧ください。

**目指す成果：**根拠に裏付けられ、検証の余地もある、優先順位付きの根本原因候補。

改善：展開前に変更の優先順位を決め、検証する

**データで置き換えるもの：**慣れている、または発表しやすいという理由で変更を選ぶこと。

分析結果をもとに、見つかった原因に対処する変更を検討します。期待される効果と、必要な労力やリスクを比較します。可能であれば、提案するプロセスをモデル化し、展開前にシナリオをシミュレーションします。シミュレーションを将来の結果の保証とみなすことなく、変更がプロセスに与える影響を検討できます。

業務を担当する人が新しい流れを理解できるよう、目標とするプロセスを文書化します。変更を実施した後は、ベースラインと同じ指標を測定します。比較することで、変更によってパフォーマンスが改善したか、別の場所に新たな制約が生じたかを評価できます。

**目指す成果：**ベースラインと照らして検証した変更と、展開後の実際のパフォーマンスを確認する計画。

コントロール：パフォーマンス、ダッシュボード、責任者を監視する

**データで置き換えるもの：**パフォーマンスの変化に気付くため、時折の監査や記憶に頼ること。

コントロールは、改善を維持するためのフェーズです。監視する測定項目を選び、確認が必要になるしきい値を設定し、対応する責任者を決めます。ダッシュボードを使うと、プロセス責任者がパフォーマンスの変化や、調査が必要な箇所を確認できます。

確認の頻度と、測定値が想定範囲から外れた場合の対応を決めます。処理量やケースの構成が変化したときは、プロセスや目標が今も適切か見直します。

**目指す成果は、**担当者が明確で、レビューの基準が定まり、後戻りの兆候を捉えて次の対応を判断できる指標がある状態です。継続的な測定については、プロセスを継続的にモニタリングする方法をご覧ください。

具体例：受注から入金まで

受注から入金までのプロセスに、5つのフェーズをどのように適用できるか見てみましょう。以下の数値は一例であり、成果を保証するものではありません。

**定義。**対象は、1つの製品群における受注から入金までのプロセスです。注文が受け付けられた時点をケースの開始、請求書の支払い完了を終了とします。CTQは請求書の正確性と入金までの期間です。課題が入金の遅れであるため、出荷ではなく支払いを終了点とします。

**測定。**チームは注文番号を使い、ERPと請求システムのイベントデータを結合します。ベースラインでは、注文の受け付けから支払いまでの中央値は34日です。そのうち11日は、請求書の作成から送付までにかかっています。

**分析。**遅延は特定の経路に集中しています。この例では、注文の22％が手動の与信確認を経て9日余計にかかり、請求書の6件に1件が再発行されて支払いまでの期間がリセットされています。どちらの経路も、文書化されたプロセスモデルには記載されていません。

**改善。**チームは、手動確認の対象を例外的なケースに絞るため、与信限度額を引き上げる案を検討します。過去のデータを使ったシミュレーションでは、そのデータ上で不良債権を増やすことなく、注文の18％で9日短縮できる可能性が示されました。実施後には、実際のパフォーマンスを確認する必要があります。

**コントロール。**チームは手動の経路をたどる注文の割合を追跡し、確認が必要となるしきい値を設定します。測定項目の責任者は受注担当部門で、プロセスを担当するチームがそのダッシュボードを確認できます。

リーンプロセス改善でよくある失敗

DMAICプロジェクトは、手順を正しく踏んでいても、有効な変化につながらないことがあります。次のような状況に注意してください。

• **ベルト主導の官僚的な運営。**プロセスやデータを確認する前に、プロジェクト文書の作成に時間をかけてしまいます。計画書やステークホルダーマップは役立ちますが、それだけで進捗を示す根拠にはなりません。
• **根拠のあるベースラインがない。**測定を省略したり、アンケートだけを根拠にしたりすると、分析で検証できることがほとんどありません。開始時点が分からなければ、後から妥当な比較を行えません。
• **プログラム全体のレベルで対象範囲を設定する。**対象が広すぎると、責任者やケース定義、1つのチームが改善できる測定項目が定まらないことがあります。境界と責任が明確なプロセスに対象を絞りましょう。
• **分析前に改善策を決めてしまう。**自動化や再設計をすでに決めていると、その選択を裏付ける根拠だけを探すおそれがあります。あらかじめ決めた解決策を正当化するのではなく、分析を使って原因の仮説を検証しましょう。
• **コントロールフェーズがない。**プロジェクト終了後に測定項目の責任者がいなければ、パフォーマンスの変化を見逃す可能性があります。プロジェクトを終える前に、責任者、しきい値、確認頻度を決めましょう。

ProcessMindがDMAICの各フェーズを支援する方法

ProcessMindを使うと、プロセスデータの確認、プロセスフローの文書化、パフォーマンスの分析、変更案のシミュレーションを行えます。調査を支援するものであり、どの変更を選んで実施するかはチームが判断します。これらのリーンプロセス改善ツールは、プロセスに関する専門知識や責任者の役割に代わるものではなく、DMAICの各フェーズに根拠を加えます。

各フェーズでは、共通のプロセス定義を使います。フェーズごとに異なるデータやプロセスの見方を使うと、改善を評価する代わりに、それらの違いをすり合わせる作業に時間を取られることがあります。

分析の進め方については、プロセスデータの分析方法をご覧ください。プロセスモデリングとプロセスマイニングがどのように補完し合うかについては、プロセスモデリングとプロセスマイニングの連携をご覧ください。

DMAICプロジェクトの始め方

次の手順に沿って、幅広い改善目標を、チームが測定できるプロジェクトに落とし込みます。このリーンプロセス改善モデルでは、チームが定義、測定、確認できるプロセスに最初のサイクルを絞ります。

1. **責任者が明確なプロセスを選ぶ。**プロセスの責任者がいなければ、コントロールフェーズの担当を決めるのが難しくなります。
2. **ケースの定義に合意する。**ケースの開始点と終了点を記録し、これらのイベントを記録するシステムを特定します。
3. **改善の前に測定する。**ワークショップや再設計によって目標の状態を決める前に、ベースラインを設定します。
4. **最初のサイクルの対象を絞る。**チームが調査し、確認できる範囲から始め、得られた知見をもとに次に調べる対象を決めます。

変更を検証したら、改善策を実施に移します。

次に取り組むこと

測定したベースラインをもとにDMAICプロジェクトを始めましょう。

測定したベースラインをもとにDMAICプロジェクトを始める