オフィスやサービス業でも 特性要因図の意外な使い方(QC7つ道具)
皆さんこんにちは! 今日もどこかで改善サポート、Kusunoko-CIです。
今回はQC7つ道具から、特性要因図を取り上げてみたいと思います。工程管理や教育にも効果を発揮するこの特性要因図ですが、意外と知られていないコツもあります。
そうしたノウハウや、オフィス系での改善に役立つ使い方も含めてご説明したいと思います。
これを読めば、あなたの特性要因図がより効果的なものになること間違いなしです。
特性要因図
こちら特性要因図の英語名ですが、
- Ishikawa diagram
- Cause and Effect diagram
- Fishbone (diagram)
など海外ではいろいろな呼ばれ方をしております。
東京大学の石川馨教授によって開発されました。なので”Ishikawa diagram”ですね。
1952年、石川教授が川崎製鉄の葺合工場で品質管理の指導していたとき、ある技術者が「問題の原因が多すぎて、整理できない」と言ったのがきっかけで生まれたのだそうです。
描いた絵が、魚の骨のような姿に見えたことから”Fishbone”と呼ばれたりもします。
石川教授は、一部の専門家だけではなく、全員参加で行う品質管理の重要性を説き、日本的品質管理(今日のTQM)の基礎作りに大きく貢献された方。
日本の品質管理の第一人者ですね。
「巨人の肩に乗る」(standing on the shoulders of Giants)ということで、偉大な先人たちの開発した知恵の集積、ありがたく使わせていただきます。
特性要因図の使い方
特性要因図、基本的には品質管理の道具として生まれました。
「魚の頭」に当たる部分に品質問題を書きいれ、その要因になりそうなものを、出来る限り挙げていきます。
製造現場


6M
まずは製造現場での、一番基本的な使い方です
「魚の頭」から背骨に当たるまっすぐな線を一本引きます。次にいわゆる中骨を、先ほどの背骨から斜めに引きます。
この中骨の属性(Attribute)いわゆる人・機械・方法・資材(Man・Machine・Method・Material)の4Mとか言われるものです。
より抜け漏れをなくし網羅的にするためには、測定方法・環境(Measurement・Mother Nature)の2Mを足して6Mとしてください。
この測定方法に関しては、以前もご紹介した測定システム解析(MSA)とGage R&Rに関わる部分ですね。
それぞれの属性に対して、可能な限り要因を挙げていきましょう。
こういう時は数が大事です。質は後から判定会することを覚えておいてください。
ちなみに、「悪意を持って」要因を挙げると、作業がスムーズに進みます。「こういうことが要因なのではないか」ではなく、「こうやると問題を起こせる」という気持ちで考えてみるわけです。
ほどほどにしないといけないとは思いますが。
またこの特性要因図は、要因と結果の関係が成り立ちそうな、いわゆるY=F(x)のxに当たるものを探り出すためのものです。
したがって、品質特性だけでなく、例えば作業に関わるムダ(8つのムダ)や、長いリードタイムなどを問題として魚の頭に持っていき、それを起こしている(かもしれない)要因を考えることだってできます。
ブレインストーミングですし、これといった決まりはない。結果が出せる使い方をしましょう。
オフィスでの使用


6P
次にご紹介するのが、オフィス系改善を進める際に使いたいときの属性展開です。
「魚の骨」を描いてから始めるのは、先ほどと当然変わりません。
オフィス系の活動では、6Pと呼ばれる属性展開があります。以下6Pのそれぞれを見てみましょう。
- Policy(規定):ここでのポリシーは規定やルールという意味です。たとえば、顧客への対応の柔軟性の程度は、多くの場合、ルールによって決まりますね。要因として規定上そうなっていることが分かったとすれば、その見直しもできるかもしれません。
- Process(プロセス):プロセスは、公式または非公式の場合があります。非公式のプロセスは、「隠された工場」または「隠されたオフィス」(Hidden Factory/Hidden Office)と呼ばれることもあります。なんとなく前任者がやっていたので引き継いだなど、なぜやるのか理由がはっきりしないまま行われている作業というのは、オフィスだけでなく製造現場などでも起こり得ます。
- People(ひと):チームの構成、サイズ、スキルはすべて、結果に影響を与えます。が、人を責める前に、そうなってしまっている仕組みを改善するのが先です。プロセス、ポリシー、またはプログラムの原因を人に割り当てないように。ここは最後の手段として使用してください。
- Plant(プラント):建物の物理的なレイアウトや他の場所への近さなど。移動距離が長い、アクセスしづらいなど改善の余地があるかもしれません。
- Program(プログラム):ここでは、プログラムはソフトウェアのプログラムなどを指します。これには、会社・組織全体のシステム、またはコンピューターにインストールされた個々のソフトウェアパッケージが含まれる場合もあります。全体最適を考えずに、部署ごとにシステムを入れてしまっているような場合、結構根深い問題に発展することもあります。そうなると長期戦ですね。
- Product(製品):この最後の「P」は、情報やサービス製品を指します。製品やサービスそのものが内包する問題というのもあり得ますね。今回の問題解決だけでなく、次の製品・サービス開発にも役立つ分析が得られるかもしれません。
Pの割り振りに、ちょっと無理やり感もありますが、網羅的ではありますね。
属性の考え方
上記のように、それぞれのエリアで異なった属性が用意されています。
他にもマーケティング業界であれば、
- 製品/サービス
- 価格
- 場所
- プロモーション
- 人々/人事
- プロセス
- 物的証拠
- 宣伝
など、いわゆるマーケティングの4Pなどから派生したっぽいカテゴリー展開で、ブレインストーミングを行えば、抜け漏れなく進められそうです。
またサービス業であれば、
- 環境・地域
- ベンダー
- システム
- スキル
などを使用してもいいかもしれません。
私が指導する際は、こうした用意されたものを基本に、特有の属性があるのであれば、書き足して行うように言っています
例えば製造の6Mに、6Pからのポリシー(規定)に関わるものを加えて置くような感じです。
重ね合わせて、より効果的な結果が出るように使用されるのがいいでしょう。職場環境というのは、ところ変わればいろいろ変わってくるものだと思います。
「こういうカテゴリー(属性)があった方がいい」、というのがあれば付足して柔軟に使い倒してください。
特性要因図となぜなぜ分析


最も効きそうな要因を選んでなぜなぜ分析
そんなわけで特性要因図を使用し、要因と結果の関係Y=F(x)のxに当たる要素を、徹底的に洗い出したとします。
フィルタリング
ただし、今あげた要因が真因ではないかもしれません。
ここ少し注意が必要なのですが、特性要因図を使用して出てきたのは、ブレインストーミングですから、思いつく限りのものです。
それが役割ですから何ら問題ないのですが、ここで終わらせてはいけません。
出てきた要因たちを吟味して、本当に要因になっていそうなものを選択します。
他のデータ、現地現物、経験則など、上げた要因のフィルタリングを、チームの皆さんで行ってください。
ビジネスの問題解決ですから、すべてを吟味していくことはできない。ですから、いわゆるY=F(x)の「これだ」と言えるものを、リソースと相談して抽出するわけです。
パレートのところでご説明した、「80 20の法則」の考え方ですね。
なぜなぜ分析で真因
そうしましたら次に、真因発見のための「なぜなぜ分析」です。
現場で現象を追えるものなら必ず現地現物を行いながら、「なぜなぜ」と深堀していきます。
この「なぜなぜ分析」、英語では「5 Whys」とか、「Why-Why analysis」とか呼ばれていますが、真因にたどり着くまで行ってください。
2回かもしれないし、10回「なぜ」と聞かなくてはいけないかもしれませんが、必ず「真因」に行き着くまでです。
真因にたどり着く前に考え出された改善策というのは、たいがいの場合失敗します。「解決策ありき」になっていないか。英語だと「Jump to the solution」と言ったりします。
短期的には問題が解決されたように見えるのですが、長い時間たつと必ず同じか、あるいは似たような症状がまた現れてくるのです。
せっかく皆さんの貴重な時間やリソースを割いて行っている問題解決ですから、こうなってしまってはもったいないですよね。
「真因を発見して、それに対して解決策を打つ」ということを絶対に忘れないようにしましょう。
よくあるのが、明らかに「その解決策を試したいから」解決策を打った、というケース。典型的な「Jump to the solution」で、たいがいあとから問題が再発してます。
頭抱えちゃうんですけども。
必ずなぜなぜを行ってみる、と覚えておいた方がいいでしょう。
なぜなぜの「バランス」
最後に、なぜなぜ分析に対してのコツをお話ししておきます。
ひとを責めてはいけない
まずは、人(自分含む)を責めないことです。
たまに起こるのが、誰かがおっちょこちょいだからとか、「私の不徳の致すところ」というふうに人を真因にしてしまうケースです。
これは建設的ではない。
人はミスをする生き物です。まずそのことを念頭において、仕組みや方法をどうすればいいのかを考えなくてはいけない。
それがポカヨケの思想であったり、カイゼン活動の極意になります。
ミス・問題になる原因というのは、そもそもそこに存在しているのです。ミスや問題は、ラッキーなことにそれを顕在化させてくれたわけですから、今後それが起きないような方法を考えていきましょう。
問題が見えれば解決できる(見える化)、というやつですね。
他責に走る
それともう一つありがちなのが、自分たちの手の届かないところへ真因をもとめてしまうケース。
確かに元をただせば、例えば政府が消費税率を上げたことが原因であるかもしれません。ただそれを言って、目の前にある問題を解決できるでしょうか?
そういう外的要因は、どこの会社も平等に影響を受けているわけで、条件は一緒です。
であれば、その置かれた環境の中でどう最善を尽くし、競合から一歩抜きんでていくのか、それを考えるのが正しい方向性になっていきますよね。
あまりにも大きな要因を追い求めないことです。
こうしたケースは、オフィス系の改善で起こりがちです。製造現場と違って、現場で現物を見ながらではない場合に起こることが多いですね。指導者は適切な舵取りをしなくてはいけません。
まとめ
いかがでしたでしょうか?
今回は、QC7つ道具から、特性要因図を取り上げてみました。
特性要因図の説明は、ネットに山ほど落ちていますが、詳細な使用例が説明されていないことが多いです。
実際にプロジェクトの進行の際に使っていると、うまく使いきれないケースもよく見られます。
今回ご説明したのは、いろいろと問題解決をお手伝いした中で得られた知見になります。皆さんがこの特性要因図を使用する際にぜひ心に止めておいていただければと思います。
本文でも述べましたが、解決策ありきで活動を進めると、後々とん挫する可能性が高いです。この特性要因図からの、真因発見が再発防止の要になりますので、正しく行われているか、ぜひ確認してプロジェクトを進めてほしいと思います。
今日も読んでいただきまして、ありがとうございました。
ではまた!
基本的なことは網羅されています。