「品質保証部は言うだけ」
とよく言われる。
確かに、開発部や製造部にお願いばかりをする。
「対策よろしくね！」と。
なんせ、品質保証部は情報提供くらいしかできない。
故障の原因解明はできるが、部品改良は無理。
ひたすらお願いするしかないのだ。
ここに開発部は不満たらたらになる。
優先順位を決めてくれ
品証がお願いばかりしすぎて、処理しきれない。
「不具合発生→対策」という流れになるので、
設計ミスがあればあるほどに開発に仕事が溜まっていく。
品証としては開発に渡せばほぼ仕事完了。
とにかく開発側に仕事を渡し、自分の仕事を終わらせる。
品証としても次から次へと仕事が発生するので、
一つの案件にこだわっているわけにはいかない。
調査結果の報告もしないといけないので、早く渡す。
だから、誰もが自分の仕事を優先させたがる。
取引先がご立腹です！
経済産業省への報告が！
声が大きい人が「早くやってくれ！」と言う。
このあたりのルールが特になく、個人プレーな感じだった。
課長が言った案件が優先、と。
そして、ある程度は開発の判断。
数が少ないとそれでも問題ありませんでしたが、
ある時に急増して限界になる。
開発「優先順位を決めてくれ」
ここで品証内でも紛争勃発です。
何を優先するのか？
設計ミスの改良の場合、どの製品からやるべきか？
・新商品の不具合
・多発不具合
・被害を与える不具合
・取引先ご立腹不具合
なかなか悩ましい問題ですが、ある程度は決まります。
火傷や怪我などに繋がる不具合は間違いなく最優先。
怪我させる設計ミスなど論外。
リコールダメ、絶対。
となると、その次です。
会社により判断が違うと思いますが、重要なのは新商品。
新商品で悪い評判が付くと、大きな売り上げ減になる。
会社の存続に関わるので、最優先で対策をしました。
次に「取引先ご立腹不具合」の優先順位が高かった。
対応に落胆させると今後の採用に関わってくる。
大きな売り上げ減に響くので重要です。
この３つを優先させて、それからようやく「普通の不具合」へ着手です。
「多発不具合」でも、出荷数の問題がある。
いくら多発していても、生産中止品の優先度は低い。
「今後の出荷量」と「迷惑具合」が判断材料になる
ここの判断は品証の役割。
個人が判断するのではなく、会議でしっかり決めます。
定期的に新規不具合が発生するので、定期的な会議が必要になる。
ただのアピール会場になるのは想像につくだろう。
しかし、上手くいかない
開発の不満が爆発してくる。
優先順位を付けても、当然ながら仕事はどんどんと溜まる。
処理してもしても追いつかず、ブラック企業並の残業。
品証も品証で現場対応に追われて残業。
不具合が多発した時、品証・開発は地獄である。
出張に行って帰ってこない人もいる。
そんなところなので、開発は品証に要望してくる。
開発「原因究明までやってくれ」
これは自分としてもそう思う。
自分は原因究明までしっかりやる派でしたが、実際にはそこまでやる義務はない。
だから、ほとんどの人は「不具合だよ。よろしくね。」と丸投げ。
品証としても余裕が無く、開発も余裕が無い。
こうなると正論のぶつかり合いです。
品証「設計者がやるべきだろ！」
開発「早く対策するためには品証も手伝うべき」
もう愚痴の言い合い。
人間、余裕が無いとこうなります。
傍から見たら「ルール決めろよ…」と思ってしまうだろうが、
この仕事は応用が大事なので、あまり決まりを作らない。
状況に合わせて最適な行動を考えています。
こうしてやっぱり、
「品証は言うだけ」
となって落ち着くのであった。
