シックスシグマProjectの「Measure」でやること １ 「プロセスマッピング」
皆さんこんにちは！ 今日もどこかで改善サポート、Kusunoko-CIです。
前回まで3回にわたり、シックスシグマProjectのプロセス、いわゆる「DMAIC」の「Define」でやることをお伝えしました。
そこで今回からは、次のフェーズ「M＝Measure」でやることことをご紹介していきたいと思います。
シックスシグマという手法でProjectをやる際、「DMAIC」の流れだけでもざっくりつかんでおくと、各段階で何をしなくてはいけないのか、どういうツールが必要になるのかが分かってきます。
シックスシグマとか、「DMAIC」って何？ という方に、今回は「プロセスマッピング」です。
プロセスマッピング
Photo by Bonneval Sebastien on Unsplash
この「プロセスマッピング」というのは、読んで字のごとく、ターゲットにしたプロセスをマッピング＝描いてみようということですね。
この辺の目的も、いわゆるLeanみたいな「改善」活動と一緒でして、「見えるようにしていこう」というのが主眼になります。
皆さんが今行おうとしているProjectの範囲は、チーム全体でしっかりコンセンサスが取れていますか？
どこが始まりで、どこが終わりですか？
ここをはっきりさせないと、意外と後々齟齬（そご）が生まれてきたりします。「プロセスの、ここからここまで」、それ以外のところは、今回手を付けないという了解を得ておくことは、とても重要です。
これをそのProjectの「スコープ（Scope）」といいます。
またそのターゲットとなるプロセスも、わかっているようで、案外抜けていたり知らないところがあったりもするものです。
抜け・もれというのは、思考の大敵でしたね。
ましてCross functional＝各セクションにまたがる形でチームを作ったら、なおのことここは気にしないといけないです。
「Hidden factory」なんて言い方をして、公式（？）には存在しないのに、業務上そういうことをやっていたなんてこともあったりします。
いや、意外と多かったりします。
このように、シックスシグマに限定せずとも、ムダの多い工程なことが多いものです。例えば作業書にないのに、そもそもなぜこれをやっているのかという。
いつの頃からか、ある種の必要性で、一時的に作られた工程が、なぜか必要性がなくなってもいまだ存在していたりするのですね。
まずは何より「見える化」です。
3種類のマッピング
一口に「プロセスマッピング」といっても、3段階くらいありまして。
まずは、本当にざっくりした「マクロマップ（Macro map）」です。
マクロマップ（Macro map）
最初にもお伝えした、頭とお尻、スコープの取り決めなんかに効きます。「まずはここにフォーカスします、それより先とあとは今回対象外なんで、ご注意ください」とチームで確認できます。
プロセスフローダイアグラム（Process flow diagram）
そうしましたら今度は、「プロセスフローダイアグラム（Process flow diagram）」。
これは、かなり詳細なプロセス、工程ごとにしっかり書きます。
そしてこの時往々にして、先ほどの「Hidden factory」が見つかりますね。
全員でプロセスを把握するために、一度書いたものと一緒に現場を歩いてみるなんて言うのもお勧めです。
これは、特に先ほどもお話ししたCross functional teamである場合、「自分のところはよくわかっているけれど、後とか先、特に後の工程が何をやっているのか、いまいちよくわからん」、ということが多々あるからなのですね。
工程工程で「何をして、なぜしている？」という部分がクリアになっていきます。
この辺は以前もご紹介した、「後工程はお客様」のところでも何度か説明いたしました。
チームの合意、プロセスに対するアクションの基礎作り。
ここでは、「SIPOC」分析という手法が使われることが多いです。こちらも以前ご紹介してみましたので、ご参照ください。
ディテイルドマップ（Detailed map）
Detailed Mapの例
このディテイルドマップ（Detailed map）は、マッピングというよりは、「表」に近い感じです。
プロセスの名前、SOPなどのドキュメント、プロセスのOutput, そしてInputをすべて網羅。使う機器や道具があれば、それも書きだす。これをすべての工程に対して行います。
これにはきちんとした理由があって、シックスシグマでは、「Y＝F（ｘ）」という考え方に基づいて、問題解決を行っていきます。。
このYというのがいわゆる製品・サービス、つまりお客様に届く「結果」になるわけですが、これを成し遂げるために様々な要因「ｘ」があると考えるわけです。
「ｘ」すなわち、その製品やサービスを完成させるのに必要な「Input」、これをすべて明らかにします。
ｘは例えば、ある工程の部品や素材、作業者の動き、機械の速度や温度などなど。
こうした、Yという結果物に対して、影響を与える（あるいは与えそうな）「ｘ」要因を出来る限り上げて、「Y」に最も効いてきそうな「ｘ」を探し当てて、そこに絞って「カイゼン」する。
それがシックスシグマの考え方です
これは後に、様々なツールで「最も効いてきそうな『ｘ』」に優先順位をつけていく際の、要因探り出し作業でもあります。
まとめ
いかがでしたか？ 今回は、「M＝Measure」の段階でやることこと、「プロセスマッピング」という考え方をご紹介いたしました。
ちなみにこの「プロセスマッピング」は、最初の「Define」に入れられていることも多いです。
いろんな会社がいろんな教え方をしていますんで、あまりその辺は厳密に考えなくていいと思います。
ただ、問題解決の際に、全体を見通せるようにして、アタックすべき要因を探り出していく、という意味で、Project初期段階で行われるべきもの、としておくのが妥当でしょう。
ちなみにこうした手順は、Lean（改善）の問題解決でも必ず行います。
「見える化」の重要性というのは、問題解決の手法が変わっても同じですね。プロセスを全員で「見える」ようにしてから、取り組んでみてください。
今日も読んでいただきまして、ありがとうございました。
ではまた！
![](<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="https://rcm-fe.amazon-adsystem.com/e/cm?ref=tf_til&t=kusunokocid06-22&m=amazon&o=9&p=8&l=as1&IS2=1&offerlisting=1&asins=B07RXYYMHB&linkId=d74a35c07975be5baac0f3d31a100cfb&bc1=000000<1=_blank&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr"><br />
</iframe>)