製造現場で発生するトラブル対応で発生しがちなことを図にしてみました
以前書いた「江崎グリコさんのシステム障害が大変そうです・・・」の記事が、私にとっては驚愕のビュー数になりました。そのせいか最近、どうも筆が鈍っています。
・何がそんなにウケたか分からない・・・
・もしかして、ディスりすぎたかも・・・
（ディスり傾向の記事の方がビューが増える気がしています・・・）
・ディスっている訳では無く、素直に本心なので（それはそれで問題！）
・でも、反応があるのは面白いので、その方向に行こうか・・・
・それはそれで、自分のカラーではないし・・・
最近はかなり迷走しながら記事を書いていましたし、記事も投稿しにくくなっていました。
やっと、ビューが落ち着いて、以前の正常運転に戻ってきました。
今回は、製造現場で発生するトラブル対応で発生しがちなことを図にまとめてみました。
「江崎グリコさんのシステム障害が大変そうです・・・」の記事も、「こんなトラブル対応になっていそうだなー」と言うのが頭の中にありました。
私は、研究開発→試験ライン立ち上げ→量産ライン立ち上げ→品質保証といった一連の業務を若いころ経験しました。その際の苦い経験をもとに作成しています。（はい、年寄りの昔話です・・・）
製造現場で発生するトラブル対応で陥りがちなこと
いつものように、図にしてみました。
希望的観測によるトラブルの拡大
トラブルの芽の段階で対応できれば良いのですが、大体は放置してしまいます。
これは、自分に都合の良いように「希望的観測」に流されてしまうためだと感じます。
特に「他の仕事で忙しい」「休みの前で時間が割けない（休みたい！！）」といった時に、この希望的観測によるトラブルの芽の放置が起きる気がします。大概、「トラブル発生で余計忙しくなる」「休みに現場からの呼び出し電話が来る」と言う目に合いました。
視野狭窄による間違った対策
トラブルが顕在化すると、大騒ぎになります。通常は丁寧に考える時間もありませんので、過去の経験や知識で対策を実施します。そう、決め打ちです。
ところが、対策を実施しても解決できないことが時々あります。そんな場合はトラブルの火が延焼してしまい、かなり大事（工場長まで乗り出すとか、客先が騒ぎ出すとか）になっていたりします。
こうなると、担当は地獄の日々を過ごすことになります。
他責で問題の先送り
立場の強い企業だったり、部門だったりすると、自分の所に問題があっても、他の企業や他部門に責任を押し付ける場合があります。
これは、担当ベースでは責任回避できますが、問題の元を解決したわけでは無いので、結局先送りにしかなりません。未来永劫、この問題が付いて回り、最終的には自分の首を絞めることになります。
同一部門でも、責任者が担当に無理難題を押し付けることがあったりします。たとえば、責任者が「この現象は理論的に発生しない！」「発生しているのは、担当が間違っている（製造条件とか製造方法とか）からだ！」と担当のせいにしたりします。実際には責任者の想定外の事象が起きているだけだったりします（単に頭が固いだけ）。
パワハラや下請けいじめ（最近話題になっているN社さんはG社長のあたりから続いている・・・）の遠因のような気がします。
発散した対策でさらなる混乱へ
他責できない弱いセクションの場合、なんとか問題解決する必要があります。
ところが、視野狭窄の後ですので、今度は無法図に因子を広げて手あたり次第に対策することが多いです。
それも、思いつくままに五月雨的に対策を実施することが多く、どの因子が効いているか解らなくなることも多いです。
それでも、対策書は品質管理や客先に出す必要がありますので、「相関の高そうな因子をとりあえずの原因として」対策書を作成して、余計な管理項目を増やす羽目になります。その因子は問題の原因で無いので、トラブルを繰り返すことになり、どんどん管理項目が増えていきます。
どうすれば良い？
では、「どうすれば良い？」かです。
一応、私なりの対策案を示しました。
これは、長年の失敗の上に成り立っている経験則なので汎用的では無いと思いますが、参考になれば・・・。
希望的観測を排除して「データドリブン」で
原因が分かった後からデータを眺めると「トラブルの兆候」が明確に表れていることがほとんどです。
なので、「希望的観測」では無く、「客観的事実に基づいた」「データドリブン的な考え方」が良いと思います。
最近は、簡単に機械学習が使えますので、多量のデータでも昔よりも容易に兆候をつかむことが可能です。（私が現場担当だった頃に、この手法が欲しかったです・・・）
視野狭窄に陥らないように「MECE」で因子を把握
「データドリブン」するには、データ化されている必要があります。
ところが、データを取っている因子は、あらかじめ主要因子として抽出している物だけのことがあります。ここで、視野狭窄になっていると、主因となりうる因子をデータ化しない場合があります。
そこで、事前にMECE（Mutually Exclusive and Collectively Exhaustive：漏れなくダブりなく）で因子を洗い出すことが有効です。
すべての因子をデータ化するのは難しい（コスト的に許されない場合が多い）ですが、「こんな因子もある」「この因子はデータ化されていない」と言うことを把握していれば、想定していた因子が原因では無い時に、「残っているのは、この因子」「データでチェックできていないのは、この因子」と素早く考えることができます。
他責する前に「自分の責任範囲の課題を整理」
どうしても、誰かのせいにするのが楽です。「前工程が悪い」「部品が悪い」「現場が悪い」「上司が悪い」「客が悪い」「政府が悪い」「政治家が悪い」「世間が悪い」等々です。
ところが、自分の責任範囲で出来ることをやらずに他責をしてしまうと、思考停止に陥り、課題が放置されます。結局自分に跳ね返ってきます。
まずは、自分の責任範囲の因子をMECE等で整理して把握することが必要だと思います。
また、他責する場合も客観データに基づいた分析の上に「このデータが悪い」「このロットのばらつきは何か」と言うような、できるだけ具体的な課題に落とし込んだうえで他者と折衝する方が、相手も対応がしやすいです。
発散しそうになったら「データ」で客観視
追い込まれると、「思いつくことを」「手当たり次第に」対策を実施しがちです。
そんな時こそ、「一息いれて」「客観的に引いた視点から」再整理するのが良いです。「急がば回れ」「道を間違えたら、道を戻った方が結局早道」です。昔の上司で「まあまあ、座れ」「茶でもどうだ」と落ち着かせてくれる方が居ました。今考えると、良い上司だったと思います。
具体的には今まで、対策実施してきたことを以下のように整理してみます。
・実施した対策がどんな因子を想定しているのか
・それは、データで表現できているか
・他に因子（外乱因子が重要だったりします）はあるのか
・他の因子はどんなデータで表現できるか（記述すると言ったりします）
これを、図示しながら頭を整理すると、見落としていた因子に気が付くことがあります。
ただ、図示する前に「死ぬほど悩んでおく」必要があります。どうも、悩むと人間の脳内でディープラーニングしているようで、おぼろげながら解が出るみたいです。これを図示と組み合わせることで、論理的に明確化できるようです。
まとめ
「生産現場でのトラブル対応でおちいりがちなこと」をまとめました。
多分、生産現場に限らず、色々な場面で似たようなことが起きている気がします。
対策としては、「データで客観的に」「図示を組み合わせて、問題を把握する」ことが有効な気がします。
この記事が気に入ったらサポートをしてみませんか？