とてもうれしいことに、以前投稿した記事「事例：空冷システムへの変換」が役に立ったという感想を読者の方に頂きました。また「製造分野や製品開発分野ではないところの、リーンシックスシグマを使ったプロジェクトの事例が知りたい」とのご希望も一緒に頂きましたので、今回は事務部門での DMAIC を使ったプロジェクトの事例を紹介したいと思います。
グリーンベルト認定プロジェクトとなると、リーンシックスシグマの代表的なツールを一通り理解して、それをプロジェクトの中で｢適材適所」、個々の問題解決のために使用したことを証明する必要があります。またリーンシックスシグマはデータ指向であるため、グリーンベルトの認定を受けるためにはもちろん統計分析も行わなければなりません。リーンシックスシグマそのものはどんな事務処理の改善にも役に立ちますが、認定プロジェクトとなるとデータ量の少ない非定型的な事務業務を扱うのは、実のところ苦手な側面があります（統計的処理ができないため）。しかし今回は（たまたま？）定型的な事務処理の能力向上が目的だったため、認定プロジェクトだったにも関わらず、DMAIC のフレームワークが簡単に収まりました。
プロジェクトの背景
この文書管理課では、製品開発部から CAD 図面や部品表などを受け取り、データベースに必要な情報を附加しデータ整合性を整え、最終的に製造や部品発注に必要な情報をデータベースに登録しています。これまではデータベース化に平均 46 日、設計書類が多い複雑で大きな製品になるとデータベース化に 120 日以上かかることもありました。それを最長でも 2 週間、つまり平均 14 日まで短縮するのが今回の DMAIC を使ったグリーンベルト認定プロジェクトの目標でした。
D（Define／定義）フェーズ
Define フェーズでは以下のツールを使いました。
- プロジェクト・チャーター
- SIPOC
- RASCI マトリックス
- VOC
プロジェクトの最初はいつも、プロジェクト・チャーターで始まります。今回もまずはチャーターを使って、プロジェクトのスポンサーやリーダー、リーンシックスシグマのコーチ（僕のこと）、コスト、期間などを明確にしておきました。そして一番重要なことである「プロジェクトの範囲」をしっかりと定義しておきました。この定義が曖昧だと、良くあることですが、プロジェクトがあらぬ方向へ逸れていってしまうからです。また後の揉め事を減らすため、プロジェクトの成功の合否基準を予め決めておきました（平均 14 日まで短縮）。
SIPOC はいつもの様に、プロジェクトの概要を上層部のマネージャーや外部の関係者に伝えるためのコミュニケーションの道具として使いました。例えばチャーターと合わせて、プロジェクトの予算を獲得するために、経理部門にプロジェクトの概要を説明する時などです。
RASCI マトリックスはプロジェクトの関係者とその役割を前もって把握するために使いました。よく RASCI マトリックスを作るときに担当者の氏名を書くことがあります。しかし僕は氏名ではなく、むしろ担当部門や役職を書くように勧めています。期間の長いプロジェクトになると、その期間中に担当者が異動してしまうことがあるので、氏名ではなく担当部門や役職を書く方が、RASCI マトリックスを作り直さなくて済むからです。
VOC は色々なツール（アンケートや KJ など）から成り立っていますが、全てを使うことはグリーンベルトには荷が重た過ぎますし、またプロジェクトの範囲から考えても無駄だと思ったので、ここでは簡単に以下のようなステップを取りました。
- インタビュー
- ビジネス分析（ビジネス要求、顧客要求、技術要求、移行要求）
- ドライビング・フォース分析
- プロジェクトの成果（Outcomes）の抽出
M（Measure／要求仕様の評価）フェーズ
Measure フェーズでは以下のツールを使いました。
- 現在の VSM
- C & E マトリックス
- Time Study
- Statistical Process Control
- Process Capability Analysis
まず現在の文書処理プロセスを理解するために、VSM（Value Stream Map）を使って、文書の流れとプロセスの個々のステップを図に表しました。
次にプロセス・ステップを表（Cause & Effect マトリックス)に置き換え、Define フェーズで抽出したプロジェクトの成果を効率良く達成するためには、どのステップが一番重要なのかをチームで検討しました。つまり Cause & Effect Matrix を使って、どのステップから改善を始めれば良いのか、個々のステップに優先順位を付けていきました。これは今回のように時間と予算に制約があるときには有効でした。つまり優先順位に従ってプロジェクトを進めることで、少ない時間と予算の中で最大の効果が得られるからです。
そして優先順位の高いステップに絞り、文書処理のサイクルタイム（Time Study）やプロセスの安定性（Statistical Process Control）を調べました。さらに集めたデータを使って、許容分析（Process Capability Analysis）を行い、目標の平均 14 日に対してどれだけ許容量があるのか、Z 値を使って示しました。（最大値は 21 日）
A（Analyze／分析）フェーズ
Analyze フェーズでは以下のツールを使いました。
- C ＆ E ダイヤグラム
- 現在の Process FMEA
- Improvement (Kaizen) Plan
Measure フェーズで示した Z 値はマイナス値、分かっていたこととはいえ、ひどいものでした。そこで Cause & Effect ダイヤグラム （Fish-bone ダイヤグラム）をチームで作り、問題の原因を探りました。
また Cause & Effect ダイヤグラム で洗い出した問題の原因を使って、Process FMEA を行いました。Process FMEA によって現在のプロセスが抱えるリスクと、それを解決するための改善案を優先順位と共に洗い出しました。
I（Improve／改善）フェーズ
Improve フェーズでは以下のツールを使いました。
- 新しい VSM
- 新しい Process FMEA
- 新しいプロセスの実施
- Time Study
- Statistical (Hypothesis) Tests
Analyze フェースで洗い出した改善案を基に、新しい文書処理プロセスをチームで設計し、VSM （Valuse Stream Map）にまとめました。そして再び新しいプロセスの Process FMEA を行い、新しいプロセスが抱えるリストとその防止策を検討しました。
後は新しいプロセスを実施し、リスクを防止するだけです。
新しいプロセスが落ち着いてからは、再びデータ（サイクルタイム）を集めました。集めたデータを基に統計分析（Two Sample t-Test や F-Test など）を行い、統計的に文書処理時間が短縮されており、かつ統計的に文書処理時間のバラツキが減っていることを証明しました。
別に統計分析などしなくてもグラフに表しただけで結論ははっきりしていたのですが、ここはグリーンベルト認定プロジェクト、しっかりと統計分析をしてもらいました。
Control（コントロール）フェーズ
Control フェーズでは以下のツールを使いました。
- Statistical Process Control
- Process Capability
- Control Plan
Control フェースではさらに、新しいプロセスが安定しているのかどうかを検証（Statistical Process Control）しました。そして集めたデータを基に許容分析を行い、Z 値がプラスになったことを確認しました。
最後にこのプロセスが安定するように、マニュアル類を用意したり、気付いた改善点などをまとめたりして、後の計画（Control Plan）としました。Process FMEA も最後に見直し、すべてのリスク対策が完了しているかどうかも確認しました。
結論：結果として、文書処理のサイクルタイム（平均値）を 14 日にするという目標を達成することはできましたが、Z 値はかろうじてプラスに転じただけで、値的にはあまり良くありませんでした。つまりまだ文書処理プロセスにはバラツキが多く、半分近くの処理が 14 日以上かかっていたからです。それでも平均 46 日だった文書処理を 平均 14 日にまで短縮できたため、プロジェクトは成功したと言えます。またチームリーダーもグリーンベルトの認証が得られ大変満足しているようでした。