『シックスシグマ』の問題解決サイクルDMAICは、一番最初に問題を定義するDefineフェイズから始めます。改善対象を出来るだけ具現化し、目的を明確にする為です。問題の中には、問題なのはわかるが、抽象的且つ曖昧で、取扱に困るものも少なく無いと思います。そのような場合は問題の構造を理解し、出来るだけ具体的因子に分解していくことで、真に改善すべき要因へ近づきます。 この作業を行わないまま改善活動を開始しても、活動の序盤は真に改善すべき点を見つけ出す作業が主となります。上手く真の課題に辿り着いてゴールが明瞭になればそれでも良いのですが、辿り着かず別方向へ向かってしまう場合も少なくありません。
例えば「新製品Aの歩留りが非常に悪く、早々に改善せよ」とトップダウンで指示があったとします。この場合問題を『低歩留り』に設定しても良いでしょうか。この場合、「歩留りが悪い」意味を確認しておく必要があります。
•どの程度の数値の低さを｢悪い｣思っているのか
•具体的には何が問題でそうなって(低歩留り)いるのか
•どうなれば問題が解決したと見なすのか
•具体的には何が問題でそうなって(低歩留り)いるのか
•どうなれば問題が解決したと見なすのか
これを曖昧にしたまま始めると、トップの意向と違っていたと言う事態も生じ得ます。これらがクリアになったら、次に歩留りを低くしている理由を探ります。
不適合・不良原因を抽出し、対策を打つべき項目を絞り込みます。 B型欠陥数起因でリジェクトされていれば、B型欠陥の削減がメインのテーマになりますし、達成すべき数値目標も自ずと明確になります。恐らくここで、｢開始してから明確にしても良いんじゃないか？｣と思う方もいらっしゃると思います。確かに改善活動の前か後かの問題で、『やるならば』変わりないかもしれません。私も準備に時間をかけ過ぎるよりは開始した方が良いと思います。
しかし、ここで注目しているのは問題が取り組みやすい形に具現化されていない事です。具現化を意識せず漫然と開始したが故に具現化に至らない、もしくは至っても時間がかなりかかって効率が悪いと言う点です。それに、やるべきことを明確にしてから始めるのと、開始して明確になるのでは、始めた後の進捗度や成果も差が生じます。問題が具体的な方が行動を取りやすい為です。
｢晩御飯の材料を適当に買ってきて｣と言われるのと、カレーを作るための素材と量を具体的に頼まれるのでは買い物作業の効率が全然違...
