--.--
--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

06.17
Tue
前回は、原因追及によって生み出される説明(仮説)=「原因仮説」について
ご説明しました。
「原因仮説」はトヨタ方式で有名な「なぜなぜ分析」のように、「Why?」
(なぜ?)を何度も繰り返すことで、根本となる原因に近づいていきます。
「Why」を繰り返すことで、深く問題を検討できるだけでなく、万一仮説に誤
りがっても一つ一つのステップごとに仮説に間違いがないか検証できるという
メリットがあります。
一つの参考例として、

「設備起因のトラブルによる操業(営業)停止時間が長い」

という問題に対して、

「トラブルの対応法や復旧に対する情報や教育が現場に不足しているため、
設備トラブルの復旧が遅れてしまうことがあり、停止時間が長くなってしまう」

このような原因仮説を立てるところまで、前回ご説明しました。

それでは、「原因仮説」を立てれば仮説構築は完了なのでしょうか?
原因を探すだけでは問題は完全に解決しているとはいえません。
対処の方法を考えて、行動しなければなりません。

ですから、今度はその原因仮説に対して「So What?」(=だから何?
だからどうするの?)を繰り返すことにより、原因を取り除く方法を仮説
として考える「方法仮説」が必要になってくるのです。

「原因を見つければ、問題は解決したも同然」

ということを、時々耳にしますが、一方で

「ここが悪いのはわかっているんだけれど、直せないんだよなあ。」

ということも、かなりありますよね。
問題の原因が分かることは非常に重要ですが、やはり分かる分かるだけで問題
解決ができる、と考えるには無理があります。
何か具体的な行動(方法)が必要です。
ただ、その行動が問題の原因を取り除くことができるかどうかは、
やってみなければわからない、つまり「仮説」ということになります。
そこで、今度は原因を取り除くために

「So What?」=「だから、どうするの?」

という問いを何度も発することで、行動するための仮説を作り上げていくのです。
これが、

「方法仮説」

です。

もちろん「So What?」に対する答えは一つだけでなく、枝分かれしていくと
思いますが、それぞれについてできるだけ「So What?」を繰り返します。
最終的には、具体的な行動が取れそうなレベルまで「So What?」落とし込み
ます。
これが「方法仮説」になります。

複数の仮説ができたら、どれが「原因仮説」解消を実現しやすいのか、
また実行しやすいのかを比較検討して、「方法仮説」を確定します。

逆に具体的な行動に結びつかないものは、「方法仮説」として不適切です。

先ほどの例で考えてみます。
(実際にはこの各プロセスの間に色々な選択肢が想定されますが、
今回それを無視して結果として結果として最適な仮説に行きついている、
という前提にしています。)

「トラブルの対応法や復旧に対する情報や教育が現場に不足しているため、
設備トラブルの復旧が遅れてしまうことがあり、停止時間が長くなってしまう」
→(だからどうする?)
「現場に、トラブル対処や普及法の情報・教育を十分に与える。」
→(だからどうする?)
「現場の人が、簡単にすぐに情報をとりだせるような環境を作る。」
→(だからどうする?)
「トラブル対処のノウハウや、過去の履歴を整備したデータベースシステムを
導入して、現場の人がすぐに情報を取り出せるようにする。」

この最後の内容で、具体的に何を行動すべきかが示されています。つまり、

・トラブル対処のノウハウや履歴を整備したデータベースシステムを導入し
現場の人が使っていけば、原因が取り除かれるのではないか

ということです。
このように実施できるレベルまで仮説を落とし込むことがポイントです。

あとはその仮説に基づいて、実施計画を決めていきます。

最初と結論だけを見れば、

「設備起因のトラブルによる操業(営業)停止時間が長い」(問題)

「トラブル対処のノウハウや、過去の履歴を整備したデータベースシステムを
準備して、現場の人がすぐに情報を取り出せるようにする。」
(解決のための仮説)

このようになっています。
この二つを並べれば、シンプルですが、これまで見たようにここに至るまでに、
かなり面倒なプロセスを経ていますよね。

「一足飛びに、もともとの問題点から、直接解決方法を考えればいいのでは?」

と考える方もおられるかもしれません。

しかし、

「設備起因のトラブルによる操業(営業)停止時間が長い」

という問題に対して、何のプロセスも経ずに解決策を考えるのは実はなかなか
大変です。おかしな方向に行ってしまい可能性も大です。
上の事例で言えば、直感的に、

「設備起因のトラブルを減らせばよいはずだから、点検や整備間隔を短くしよう」

例えばこんな結論に至ってしまうかもしれません。
一見正しそうに見えますが、今回示したようなケースではコスト高になってし
まう割には、問題も十分に解消できないかもしれません。

それだけでなく、もしうまくいかなかったの場合、どこにうまくいかない要因
があったのかを確かめるのが非常に大変です。

仮説を立てていくということは、むしろプロセスが大切です。
プロセスを積み重ねることによって、説得力のある対策に結び付きます。
そして、なにより後でその仮説を検証するときにも大きな力を発揮します。

仮説はあくまでも、「仮の」説明なのでそれが本当に有効なのかはわかりません。
ですから、仮説が本当に正しかったのか、誤っていたらどこだったのか、
という検証とセットになっていることが大前提です。
プロセスが明確であれば、プロセスを辿っていくことで、
軌道修正ができやすくなるのです。

今回ご紹介した方法が、皆様にとって本当に適切かはわからないのですが、
いずれにしても仮説を立てるときに「プロセスを構築する」ということを意識
することが重要だと思います。

ということで、仮説のご説明はここまでとします。
次回は設備情報管理の手順として「範囲を決める」
ということをご説明したいと思います。
スポンサーサイト

comment 0 trackback 0
トラックバックURL
http://setsubitakumi.blog.fc2.com/tb.php/67-e9d37bd9
トラックバック
コメント
管理者にだけ表示を許可する
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。