コンセプトは ”どうしたら面白くなるか?” 改善 セミナー どうしたら易しく面白くなるか
 もっと楽にならないか
改善ぷちセミナー
なぜなぜなぜなぜなぜ
工数削減の話
工程分析について
稼働状況の捉え方
モーションマインド
標準化の4つのC
生産保全の話
なぜなぜなぜなぜなぜ
問題解決アプローチ
 
1.なぜなぜができない

 不具合やトラブルの再発を防止するためには、その原因をつかんで解消しなければなりません。
 よく、問題が起きたら「なぜを5回くり返せ」と言います。なぜ5回なのかというと、5回くらいくり返せば、本当の原因が見えてくるとされているからです。
 なるほど、そんなものかなと納得しますが、いざやろうとすると、これが一筋縄にはいかない。
 そこで、少しでもやりやすくしようと、なぜなぜ用のフォームが作られて、「さあ、これを使ってやってみろ」と渡されます。欄外には親切になぜなぜの注意点も書いてあります。

  <なぜなぜの注意点>
 @現象の記述の中に原因を含めない・・・「〜で」とか「〜によって」という表現をしないこと
 A現象の中に複数の内容を書かない
 Bなぜを出したら、論理的に間違っていないか確認する・・・「〜だからこうだ」とさかのぼってみる
 Cなぜができなくなるまでくり返す
 D考えられるなぜは全て出す
 E曖昧な表現は避けること・・・「大体」とか「不十分」という表現は使わない
  ・・・・・・etc.

 なるほどと思う一方、守らなければいけないルールみたいで、かえってやりにくい。結局、中途半端な内容になって「ああ、頭が悪いからオレにはムリだ」と自信喪失してしまいました。

 ・・・と、こういう経験をお持ちの人が少なくないようです。でも、なぜなぜって、そんなに難しいことなのでしょうか?
おすすめの
出し物
品質でもうけなさい…品質問題解決をイラストとエッセー風に解説
Dの問題…デリバリー/生産管理の問題について考えてみましょう システムからの発想…システム概念からのヒントなど
改善提案名人に挑戦! 備忘録めもらんだむ・・・用語とか時事などのメモ帳。改善ぷちセミナーも開講しています。(常時工事中ですが、歯抜けでも差し支えなければどうぞご覧くださいませ)


2.なぜなぜって手法なの?

 QC手法に詳しい品質保証スタッフでも、なぜなぜに悩まされる人は珍しくありません。

 お客様で不良が発生し、再発防止を強く求めて来ました。
 お客様としては、取引先に対する品質教育も兼ねて、なぜなぜをくり返すよう指示しました。が、そこは、日頃から品質管理の専門誌や参考書で勉強している担当者のA君。なぜなぜぐらいは心得ています。
 しかし、お客様から送られてきた分析フォームを前に頭を抱えてしまいました。



 はっきり言えば、こんな場合になぜなぜなんて悠長にやる必要はありません。
 なぜなぜをやる目的は、原因をつかんで再発防止することで、分析フォームを埋めることではありません。原因がわかりきっているのですから、やるだけ時間のムダです。(お客様の要求じゃ仕方ないですが)
 やらなくても済むならやらない・・・これ、なぜなぜの内緒のコツ1

 あるエライ人が「なぜを5回くり返せ」なんてチラッと口にしたのを、なにかと手法がお好きなエライ先生が聞いて、特別な分析手法みたいにしちゃったんです。
 手法だから、いろいろなテクニックやルールみたいなものをペタペタくっつけて、おまけに立派な分析フォームまで作ってしまう。これにまとめなければ、ちゃんと検討したとは認めないぞ、な〜んて言う頭の固いお客様や上司も出てくる。

 しかし・・・


3.だれもが普通にやっている

 なぜなぜなんて、言葉がちゃんと話せればだれでもできるんです。
 難しい手法でも高度なテクニックでもないし、慣れの問題でもありません。だれもが普通にやっていることです。もし本当にできないというなら、呆けたかもしれないと自分を心配した方がよろしい。

 お客様の分析フォームに悪戦苦闘するA君。このところ遅い帰宅で、いつも疲れた顔で帰ってきます。
 それを心配する彼の細君・・・



 ま、だれもがこんな風に、あーでもないこーでもない、やっています。
 とはいえ、この例で気付く重要なポイントをいくつか。

 まず、最初の現象は日常のありきたりなことですが、ふと「変だなあ」「おかしいなあ」「どうしてだろう」と感じるところから始まっています。このささいな気付きがなければ、なぜなぜは始まりません。
 小さな子供は、空の青さに気付き、なぜ青いんだろうといった素朴な疑問をいつも持っています。その好奇心があるから、変に悩むことなく「なぜだろう」と探究していきます。テクニックじゃありません。
 現象に興味と好奇心を持ってみる・・・なぜなぜの内緒のコツ2

 次に、「なぜ」で出てくる答は、常に仮説だということ。
 その仮説が明らかならばすぐに次の「なぜ」に進めますが、そうでなければ検証をしなければなりません。つまり、普段みなさんがやっているなぜなぜは、仮説と検証を不規則にくり返しているんです。それなのに、仮説を立てつづけに5回くり返せというのは、ちとムリがあると思いませんか?
 「なぜ」を続けられなければ検証してみる・・・なぜなぜの内緒のコツ3

 実を言うと、仮説は仮の説ですからそんなに硬くならずに自由に考えて良いんです。本当に難しいのは検証の方で、上の例はいい加減ですけれど、仮説が正しいか間違っているかを確認するのは結構大変なんですよ。
 「なぜ」はむしろ自由な発想が良い・・・なぜなぜの内緒のコツ4

 次に、一つの「なぜ」に対する仮説は、一つではないということ。
 なぜなぜの結果は、人によって異なります。これは観点の違いということもありますが、様々な要因が絡み合っているからです。つまり、関係する要因は多岐にわたり、初めから真の原因を絞り込むことは難しいということです。
 初めから要因を一つに絞り込まない・・・なぜなぜの内緒のコツ5

 さりとて、一人で洗い出す要因には偏りがありますから、やれる範囲でやるしかありません。考えられるなぜを全て出すなんてムリですから、できれば何人かで協力して行った方が良いのです。
 完全列挙にこだわらない・・・なぜなぜの内緒のコツ6
 数人で協力してやった方が良い・・・なぜなぜの内緒のコツ7

 内緒のコツはなぜなぜの注意点とかルールではありませんから、意識しなくても結構です。要するに、もっと気楽にやった方がうまく展開できますよってことです。
 どうしても苦手でなんとかしたいというなら、堅苦しい分析テクニックより、本をたくさん読むのが一番の上達法だと思います。それから、単純になぜをくり返すなら、特性要因図などを使って問題の構造が見えるようにしておくのも良いでしょう。


4.特性要因図

 特性要因図は、形が魚の骨のようになるので魚骨図(fish bone)とも呼ばれます。
 この手法は代表的なQC手法の一つですが、最近は利用している例をあまり見なくなりました。
 確かに、関係する要因を洗い出す手間の割に、求める答がその一部に過ぎない物足りなさがあります。また、掘り下げられるのがせいぜい3〜4レベルなので、特性要因図だけではなかなか真の原因にたどりつけないもどかしさもあります。

 しかし、上で述べたように、単純になぜなぜをくり返しても洗い出した要因には偏りがあり、問題が持つ因果関係の全体像が見えてきません。その点、特性要因図は要因全体が見わたせるので、きわめて有用な手法と言えます。
 特性要因図は横に展開して問題解決の地図を描くようなもので、そこからねらいを絞ってなぜなぜで掘り下げるという具合に、上手に使いこなしたいものです。

  <特性要因図の作り方>

 私の経験上、模造紙やホワイトボードを用意して、みんなでそれに書いていった方が良い分析ができます。

 まず、元の現象を右に書きます。これが調べようとする特性です。これに、太い矢印を中央に引いて背骨を書きます。

 この背骨に要因をくっつけていくわけですが、最初の枝にはどういう属性が関係しているのかを考えます。
 この例では、右のようにしましたが、品質の問題ならば、品質を左右する5つのM(Man・Machine・Material・Method・Measurement)としても良いでしょう。

 次に、それぞれの大枝について、その属性の種類を挙げていきます。
 初めは、関係ありそうだなと思うものを出していけば良いでしょう。調査を進めて新たな展開を見出したら、そのときに書き加えれば良いのです。

 それぞれの中枝について関係する要因を、さらに細かく書き加えていきます。
 ここでも、こんなことが影響ありそうだなと思う程度で構いません。あまり厳密なことは考えないでください。とにかく、洗い出してみて大まかな全体像を眺めたいのです。


 この小枝にさらに詳細の要因を書き加えていくことも可能です。
 しかし、このくらいまで洗い出せば、どこが怪しいか見極めやすくなっているでしょう。そこを深掘りしていくのです。周辺の枝を切り出して展開したり、そこでなぜなぜを進めたりします。
 いずれにしても、これならA君の細君が泥沼に迷い込む前に、もっと調査すべき要因が見えますよね。


5.FTA

 FTAは故障の木解析(Fault Tree Analysis)と呼ばれる手法です。
 FTAは、故障が起きる原因を論理的に分析していきます。その結果、たくさんの枝が伸びた木を逆さまにしたような形になるので、この名前があります。
 もともとは製品や機械の信頼性を設計する際に行うデザインレビュー(Design Review)で、FMEA(Failure Mode and Effect Analysis:故障モードと影響解析)と共によく用いられている手法です。

 単純ななぜなぜよりも論理が明快で、同じく枝分かれする特性要因図よりも深く掘り下げることができます。
 ただし、要因の全体像は見えないので、特性要因図は作っておいた方がベターでしょう。

 実際のデザインレビューでは、右のような記号を使って分析しますが、ANDとORという2つのゲートを使いこなすだけでも、かなり論理的な分析ができるようになります。

 改善活動に使うには、少しレベルが高く感じられるかもしれません。しかし、慣れてしまえば、とても使いやすくてわかりやすい手法です。

 左はANDゲートの例です。ゲートの形はANDのDを横にした形と覚えてください。

 ANDゲートは、ゲートの下に示す事象がすべて同時に起こるときに、上の事象が発生する場合に使用します。
 例えば、十分に病気に打ち勝つ体力があれば、ウイルスに感染しても風邪の症状は出て来ません。しかし、疲れていたり、寒い場所にいて体力が奪われていたりすると、ウイルスに冒されてくしゃみ鼻水鼻づまり、熱も出てきて今日はもう店じまいとなるわけです。


 次の例はORゲートです。ゲートの形はOの丸みがついていると覚えてください。

 ORゲートは、ゲートの下に示す事象のどれか一つが起きれば、上の事象が発生する場合に使用します。
 例えば、何も食べていなければお腹が空くでしょうし、激しい運動をしてエネルギーを消耗してもお腹がペコペコになるでしょう。もちろん、この他にも考えられる事象があれば、ORゲートの下に示していきます。


 ANDゲートとORゲートを利用して、A君の細君の心配事を分析してみました。この例は途中までの分析ですが、基本事象が現れるまで可能な限り掘り下げていきます。



 違う枝なのに同じ基本事象(これ以上展開できない最後の事象)が現れることがありますが、間違いではありません。むしろ、それが真の原因として怪しい場合が少なくありません。
 基本事象が構造的因子ならば、設計に反映します。また、人的な因子ならばポカヨケを対策に考えます。


6.仮説と検証

 上でも説明したように、「なぜ」で出てくる答は全て仮説です。仮説は正しいかどうか必ず検証しなければなりません。単純ななぜなぜのくり返しにせよ、FTAを利用するにせよ、これは同じです。
 そこで、分析をしたら下のような仮説一覧表を作成して、一つ一つ検証していきます。


 さてさて、このごろ妙に帰りが遅いA君に不信感一杯の細君。
 もしかしたら浮気しているのかもしれないと悩んでいましたが、仮説を検証しようと、ある日退社後のA君をつけていくと、入っていったビルは・・・。
 今度のアニバーサリーに、ダンスパーティに誘うつもりの優しい旦那さんなのでした。

 いや、よかったよかった。

(この項終わり)
ページ先頭に戻る

おもしろがりホームページへ Copyright (C) omoshirogari. All Rights Reserved. 筆者のプロファイル紹介