品質月間に思う：設計変更は悪か？

設計変更は極力しないようにすべきである。今や日本の製造業では定説となっているこの考え方は、設計変更に伴なって発生する不具合要因への対処が、いかに広範囲で大変かということに起因します。余計な心配事は生み出すべきではない。確かにそうで、メーカーにおける変更点管理業務は相当な労力を要します。故に、不具合ポテンシャルの見逃しがあっても不思議ではなく、自ずと設計変更は避けるべき対象となってしまいます。特に日本の技術者は、そのように考える傾向にあります。それはそうですよね、そう教わってきましたから。

一方、商品性UP、すなわち顧客の立場や、技術レベルの向上、ひいては品質レベルの向上を考えると、実施に踏み切らねばならないタイミングもあります。私は常々、不幸にも品質問題が発生したタイミングこそ設計変更を断行するときと考えていました。表現は悪いですが、この機会に（どさくさに紛れて？）今までやりたくても実施できていなかった事もやってしまおうという考え方です。もちろん、問題と関係のないことはしませんけどね。

確かに変更点管理は多岐に及びますが、前回話題にしたチームワークを発揮することで乗り切れないものは無いのです。というか、チームワークを発揮できるタイミングというのは、そうそう無いのです。結果として品質問題が解決できるばかりか、今まで以上の利得も得られ、チームのモチベーション維持にもつながります。つまり、設計変更は大変ですが、決して悪ではないんです。まずは誰に対してどんな悪なのかを冷静に考えてみて、何をすべきか判断したいですよね。 " 面倒だから変更しない " と安直に考えていないか、自問してみると何かが見えてきますよ。

合わせ技の新技術を持ち合わせていなくても、折角、設計変更に踏み切るのであれば、品質問題を解決するだけで満足していてはいけません。技術者であれば、この機会に、より多くの利得を獲得するように考えましょう。品質問題のために失った分は取り返さなければなりませんからね。そう、転んでもタダでは起きない技術者でありたいですよね。品質月間最後の日のつぶやきでした。。。

追伸：タダでは起きないために、ぜひTRIZを使って問題解決の理想解を考えてみましょう。あなたの求める理想解は、あなた自身の中にあります。実は、気が付いていないだけなんです。

（TRIZを90秒で説明するとこうなる。無料動画はこちら。）