シックスシグマProjectの「Measure」でやること ２ 「Cause and effect (原因と結果)マトリックス」
Cause and effect (原因と結果)マトリックス
皆さんこんにちは！ 今日もどこかで改善サポートKusunoko-CIです。
以前も何回かにわたり、シックスシグマプロジェクトで、「プロセスごとにやること」をご説明してきました。
今回は、Cause and effect (原因と結果)マトリックスの書き方のご紹介です。
こちらは、全体的なビジネスの方向性や、製品・サービスの改善ポイントを、定量的に探り出す際に行うフレームワークになります。
モノの本の中では、シックスシグマプロジェクトの「Measure」段階で使われる、とも書かれています。
日本語で「C & E マトリックス」を説明したサイトはほぼ皆無なんで、皆さんのお役に立てるはず。ぜひマスターしてあなたの改善Projectに役立ててください！
Cause and effectマトリックスって？
Cause and effect (原因と結果)マトリックスは、 シックスシグマのプロジェクトにおいて、チームが、優先すべき問題点を順位付けするためのツール、と言われています。
まずは前提として、シックスシグマでは、「Y=f（ｘ）」という考え方でビジネスを捉える、あるいは問題解決に当たります
この「ｘ」というのは、プロセスのさまざまなインプット（作業内容や機械の設定条件などなど）です。
また「Y」というのは、製造やサービスなどにおける、企業活動の成果物（パフォーマンス）を表します。
Y=f(ｘ)とは、プロセスのインプットや、プロセスにおけるこうした「変数」が、最終的なパフォーマンスである「Y」に、影響を及ぼすことを数式で表わしたものです。
「色んな要因「ｘ」達で、結果である「Y」が変わってくるから、「ｘ」には最新の注意払って、改善していきましょう」、という感じですね。
こうした考え方に基づいて、お客様にとって大事な要件（Y）と、プロセスのすべてのインプットである「ｘ」を表にして、かつ「Yに最も効きそうなものに優先順印をつける」のが、Cause and effect （C＆E）マトリックスを書く目的になります。
ちなみにこの入力変数（ｘ）を「Key process input valuable (KPIV）」と呼び、出力変数（Y）を「Key process output valuable (KPIV）」と呼んだりします。
利点としましては
- チームの皆さんで、プロジェクトの優先順位に対する同意が得られる
- 結果として見える優先順位が、「お客様の重要度」に主導されている
という点が挙げられます。
C＆Eマトリックスの書き方
Photo by Wesual Click on Unsplash
ではさっそく、このC＆Eマトリックスの書き方をステップごとに見ていきましょう。
今回は例として、ピザ屋さんのオペレーションを取り上げてみました。
お客様要件（アウトプット「Y」）の入力
求められている要件は？
これらの「Y」要素は、お客様がその商品やサービスに対して、求めるものです。
今回は、ピザ屋さんに、私（お役さん）が求めそうなものを考えてみました。
- 味
- 見た目
- 時間通りにお届け
- 安全面
- 値段
いかがでしょう？
これは皆さんが業務を行っている中で洗い出した、「お客様が製品・サービスに求めている要件」です。
あるいは、お客様に直接聞いて、「何が求められているのか」はっきりさせなくてはなりませんね。
マーケティングや、その「セグメント」という考え方に通じるものがあります。
お客様の重要性評価
Photo by Ameer Basheer on Unsplash
そしてさらに、それらの要素一つ一つに「重みづけ」を行っていきます。
1〜10のランキングを使用し、1が最も重要度が低く、10が最も重要度が高くなります。
私的には今回は、
- 味 ９
- 見た目 ６
- 時間通りにお届け ６
- 安全面 ８
- 値段 ４
こんな風に「重みづけ」を考えてみました。
味はやっぱり譲れない。あとは子供も連れて行ってるので、安全面というのは気にしたいな、と。値段に関しては、そんなに頻繁に食べに行くものでもないので、少し低めにしました。
これは先ほどの「要件洗い出し」にもかかわってきますが、「何がどういう重要度で求められているのか」、それをこの「重み」ではっきりさせるのです。
ここがしっかりしていれば、あなたの製品・サービスが目指すべき「ターゲット」や優先度も明確になってきますね。
伸ばすべきところ、改善すべきところが分かる、ということです。
プロセス・ステップを書きだす
プロセス・ステップ
以前ご紹介した、「プロセスマッピング」で表現された、その製品・サービスを完成させるまでの大まかな「工程」です。
ピザ屋さんで言えば、注文を受けるところから、生地を用意して（下地）、トッピングして、焼いて、また後乗せトッピングか何かがあって、カットして、盛りつけて、お客様にサーブする、というような流れになるでしょうか。
それらを順次書き出していきます。
すべてのプロセス・ステップのインプットを書きだす
プロセス・インプット
プロセス・ステップが書き終わったら、次はそのステップごとに行われているインプットを書きいれます。
- 人・機械の動き
- 機械への入力
- 機械のパラメータ
などなど、そのステップの成果物を完成させるために行われているすべての行為・行動を網羅するよう書き出します。
作業者さんと、実際の動きや要素を確認しながら記入するといいでしょう。
以前ご紹介したディテイルドマップ（Detailed map）に書かれた要素が、これに当たります。
漏れなく書きだすことがポイントです。
それぞれのスコアを決定する
「０，１，３，９」でスコア
それぞれのマス目に、「ｘ」要素が与えそうなスコアを書きいれていきます。
例えば、「注文受付」の3段階目「サイズ確認」が、お客様の求める特性に与える影響を考えて、数値を書きいれていくわけです。
おすすめは、入れる数値は、「0、1、3、および9」にしておくこと。
ここで1〜10の評価を使用すると、まず間違いなく、評価が細かくなりすぎて議論が紛糾します。だいたいは、これらのプロセスのエキスパートなんかも含まれた「混成チーム（Cross functional Team）」でProjectを進めていますが、「意見が出すぎる」。
で、段々みなさんめんどくさくなって、「5」のスコアで妥協し始めます。もうよくわかんないから、「真ん中くらいの数字入れておこう」となるのですね。
当然ながら、これが進むと、C＆Eマトリックスを書いている意味が全くなくなります。なにせすべて平均的な値になってしまい、差異化できない＝優先順位もつけられないわけですからね。
この辺がこういうフレームワークの「妙味」といいますか。
論理的に物事を決めるに当たり、おおざっぱにしなくてはならない、という点、私は人間臭くて好きですけどね。
計算して、「原因と結果」の関係性を数字で表す
下と上の数字で掛け算して、全部足す
前項で、「0、1、3、および9」の数値を入れました。
これにより、プロセスをよくわかっている作り手（会社側）からの、要素の重要性を今、数値化したことになります。
そうしましたら今度は、ステップの２でご説明しました「お客様の重要性評価」で書きいれた数値と、この「0、1、3、および9」の数値をかけ算します。
かけ合わせ、かつ全て足し算することで、プロセス・インプットの重要性と、お客様重要度が関連付けられ、スコアとして算出することができる、というのがこのCause and effectマトリックスの醍醐味になります。
ピザ屋さんの例で言えば、下地のところの「生地選択」はそれぞれのお客様要件に対して今、「1、 9、9、1、9」と評価付けを行いました。
これらの数値を、お客様要件に割りふった「重み」の数値
- 味 ９
- 見た目 ６
- 時間通りにお届け ６
- 安全面 ８
- 値段 ４
とそれぞれかけ合わせ、さらに「生地選択」すべての数値を足し合わせます。右の欄に「161」という全体スコアが出ているのが見えると思います。
それが、お客様要件と、作り手側の判断する要因、つまり「原因と結果」の関係性を数字で表したものになります。
(1×9)+(9×6)+(9×6)+(1×8)+(9×4)=161
優先化ツール
Photo by Edi Libedinsky on Unsplash
このように、一連の手順を踏むことで、漠然としていた「原因と結果」の関係性が、数値で表すことができるようになりました。
「見える化」されたわけです。
時間も人も潤沢にあるのなら、すべて解決ないしは向上させることも可能でしょう。
ですが現実はそうはいきませんよね。
何度も言っています通り、「優先化」して最も効きそうなところから解決していかなくてはいけない。
全ての「X」にスコアが出たら、「80 20 ルール」を適用しましょう。
まずは最優先のモノから解決し、残りは2度目3度目…の改善PDCAを回して解決していくことになります。継続的カイゼン（Continuous improvement）です。
まとめ
いかがでしたでしょうか？
今回は、作り手側のインプット「ｘ」と、お客様要件「Y」を数値で見える化する、「C＆Eマトリックス」の書き方についてご説明でした。
ところで勘のいい方はもうお気づきかもしれませんが、この「C＆Eマトリックス」、私は個別の品質Projectなどでは、あまり使い勝手が良くないと感じています。
それはProjectの場合、だいたいは直行率とか歩留りとか、具体的な数値がすでに出ていますよね。そういう場合はあまり、ここでメインに取り上げた、「お客様要件の特性をはっきりさせる」という行為はいらないと思うのです。
なぜならプロセス・アウトプットにおいて、サイズが合わないとか、傷が出た、と不良問題がはっきりしているわけですからね。
なので、この「C＆Eマトリックス」、個別のProjectよりは、もっと上流工程の、デザインやProjectそのものの方向性をはっきりさせることに使った方が、威力を発揮する、と私は個人的に思っています。
いずれにせよ、
- はっきりさせたいお客様要件があり
- その重要度の違いがまだあいまいで
- そのお客様要件と、プロセス・インプットの関連性が定量化できていない
- そしてそれらを優先化したい
という場面においては結構な力を発揮します。是非皆さんの改善活動にお役立てください。
ちなみにこの「C＆Eマトリックス」、「X-Y Diagram」とか「Correlation Matrix」なんて呼ばれたりもします。そしてあの有名な、特性要因図 (Fishbone diagram) は、別名「cause-and-effect diagram」なので、英語だと非常に紛らわしかったりします。豆知識。
今日も読んでいただきましてありがとうございました。
ではまた！
![](<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=B07117MKBK&linkId=2d162aaa41b0039376d92ed0a30fa4c7&bc1=000000<1=_blank&fc1=333333&lc1=0066c0&bg1=ffffff&f=ifr"><br />
</iframe>)