【品質管理プロへの道】敵は社内にあり！工程FMEA導入実践記

■この記事のターゲット
・社内でFMEAを新たに導入しようとしている管理職
・量産品質を上げるためにFMEAを導入したい品質保証部員
・FMEAを導入しようとしているが、社内にうまく浸透しなくて困ってるエンジニア

この記事は、かつて開発部門でFMEA導入を目論んだが道半ばで転職してしまい、新たな職場で品証部員として数年過ごしたのち、検討を重ねていたFMEA導入を起案することになった僕の記録です。

僕のFMEAの考え方については過去記事を参照ください。

工程FMEA（故障モード影響度解析）の正しい運用のしかた【品質保証部門の立場から考察】

現実には、社内導入に向けて様々な課題や問題が出てきます。
それらを突破するには、以下のようなことを念頭に置きながら進めたほうが良いです。

FMEAの社内展開へのポイント

・FMEAの本質とメリットを理解してもらう

・関連部門の役割分担を明確にし、合意を得る

・リスク評価を複雑にしないでなるべくシンプルに

・考えに共感してくれる味方と共にガンガン進める

・起案者自らが汗をかき、既存製品や工程でFMEAを実践して例を示す

これ以降、実体験とともに詳細を述べていきたいと思います。

☆Contents☆好きなところから読めます

工程FMEA導入推進を決めた経緯
FMEAの本質とメリットを理解してもらう
関連部門の役割を明確にする
リスク評価は複雑にせずにシンプルに
考えに共感してくれる味方とともにガンガン進める
起案者自らが汗をかき、既存製品や工程でFMEAを実践して例を示す
工程FMEA導入実践まとめ

工程FMEA導入推進を決めた経緯

僕の会社は情報機器の製造を行う、そこそこ大きなメーカーの工場です。

ここ最近は市場クレームが増加傾向にあり、品質保証部門としても品質改善に向けた新たな取り組みの必要性を感じていたところでした。

この会社の問題点は以下。
・少量多品種、混流生産により自働化がしにくく、人に頼った製造プロセスが多い

・目先の生産効率を重視しすぎる体質のため、製造部門の品質マインドが低め＝品証が弱い

・製造工程設計の段階で品質を作りこむという意識、仕組に乏しい

・不具合発生時は目先の対処のみで終わることが多い

これらの問題を放置してきた我々「品証部門」の責任も大きいです。

上司がこの状況を打破しようとFMEAの導入を挙げ始めましたが、周りのメンバーは知らんぷりというか、どうしていいか分からない状況・・・。

かつて、僕が関わっていない時期にFMEAを実践しようとしたことがあったようですが、FMEAの理解や浸透ができずに立ち消えになっていたようです。

一方、僕は前職の開発部門でFMEAを推進しようとしていましたが、道半ばで転職した負い目を持っていました。

それでも自分なりに独学で「根付きやすい、効果的なFMEA」を研究し続けていました。

ちょうどいい時期にその話を聞いたので、これまで練り上げてきたものを実践してみたい旨を進言したのが発端です。

FMEAは関連部門が正しく活用すれば、品質向上はもちろん、人材育成にも一役買う効果的なツールと確信しています。

あくまでビジネスツールの一つですが、思考力を養うにはかなり使えると思ってます。

FMEAの本質とメリットを理解してもらう

FMEA（故障モード影響度解析）は言葉としては広く知られていますが、実践したことのない組織ではFMEAの目的を間違った形で認識していることが多いように感じています。

■FMEAを行う目的
製品やサービスの量産までに製品設計や製造工程起因の不具合発生リスクを潰しこみ、量産後の不具合発生による損失を最小化することを図るため

■FMEAを行うことのメリット
・事後対応コストの削減

・設計部門の設計品質レベルアップにつながる

・成果物（FMEA結果）自体が「設計の要点」がまとまった設計ガイドラインになるので、他の人のレベルの底上げやノウハウ継承になる

・設計の意図が数値化されるので、他の部門が見ても「どの工程がリスクが高いか」が直感的に分かりやすい

僕が現時点で考えるFMEAの本質は、

設計部門がFMEAを活用して製品や工程を設計をすることで信頼性を上げるとともに、そのレビュー結果から組織のリスクに対する考え方や設計の意図が数値化されることで、今後に向けての改善要否の判断材料にもできるツール

という理解です。

これを理解してもらうのに一苦労します。

よく言われるのは、
・設計が終わってからみんなでリスク抽出して追加対策して潰しこむんでしょ
・故障モードの影響度×発生頻度×検出度の点数が高いところは対策うたなきゃいけないんでしょ

というような、一見まともに聞こえるが表面的なところしか見ていないセリフです。

実際FMEAは設計部門が設計をしながら行って、専門的知見で現実的な故障モードを想定し、現実的な対策を要否も含めて設計に盛り込んでいき、設計の意図を明確にしなければいけません。

設計が終わってからFMEAをしているようでは、設計担当者は品質を考えずに設計したと思われても不思議ではありません。

リスクは上流（担当者の初期設計）から挙げて潰しこまないと、後ろに行くほど漏れが多くなります。

また、FMEAの結果リスクが高いと評価されたところを対策するというのは間違ってもないですが、コストや実現性を考えて残留リスクとして残さざるを得ないところは残してよいのです。

数値として高リスクと判断された要素は、コスト度外視で対策するか、残留リスクとして残して以降の工程（製造工程や品質管理）で別の方法でリスクを緩和させるなどを議論すべきということを数値で見せることが本質です。

ここの意識を合わせるのに何度も質問や疑問に答えながら説明を繰り返しました。

まずは設計部門として、故障モードに対する設計意図を事実に基づいて明確にしてくれと。

リスク評価は複雑にせずにシンプルに

リスク評価は以下の3要素で行います。

影響度：故障モードの影響（＝機能不具合）が起きた時のユーザー影響

頻度：故障モードの発生頻度

検出度：故障モードが発生したときに大事に至る前に十分検出できるか否か

多くのセミナーや解説書では3要素を10段階にしているのをよく見ます。

そのせいか、

頻度は「〇日に1回」、「〇か月に1回」、「〇年に1回」のように数字で示せ

という声も聞きました。

やってもいいけど、すべての担当者がきっちり正確に10段階で点数付けできる？

過去データからの頻度の集計めんどくさいよ？ちゃんと精度よくできる？

そんなばらつきの多い数値を3回掛け算したらリスク指標がすごくばらつくよ？

「〇年に1回」の頻度なら人身事故が起きても点数低くていいの？

という反論と合わせて、シンプルな方法を説明し理解を得ました。
詳細は過去記事参照ください。

工程FMEA（故障モード影響度解析）の正しい運用のしかた【品質保証部門の立場から考察】

ただ、ここは各企業や組織にあった形でモディファイすれば良いかと思いますので、これが正解というわけではないことは承知しておいてください。

考えに共感してくれる味方とともにガンガン進める

さすがに一人で説明していくのは、しんどいです。
できなくもないですが、僕だけが理屈っぽく話をしても僕だけの考えと思われたら他の部門からの協力は得にくいです。

まずは同じ部門の人（幹部含む）に僕の考えを分かってもらい、共感してもらったメンバーと一緒に進めています。

これによって説得力が増しますし、組織として新たな仕組みを作ろうとしていることを理解してもらうことができます。

基本的にこの考えを拒否する人の方が少ないとは思いますが、社内の仕組みづくりとなると及び腰になる場合も多いので・・・。

今のところ、他部門の理解もおおよそ得られていますので、まずは意識を共有できている部門からスモールスタートを切ります。

起案者自らが汗をかき、既存製品や工程でFMEAを実践して例を示す

想いは理解してもらい、FMEAシート様式もこちらで作りました。

さあ、開発・設計部門にやってください！と言っても進みません・・・。

そうなることは想定していたので、既存品の製造工程で品証部員のみで工程FMEAを実施しました。
やはり実際の事例に触れてもらうとイメージも湧きやすいので、理解を得られるのも速かったです。
リスク工程の点数が、みんなが実際の工程でイメージしているリスクとおおよそ一致しているからです。

これを品証部でいくつかの製品・工程で実施して実績を溜めてから本格運用と行く予定ですが、あまりやり過ぎると品証部員まかせになってしまって当初の目的を果たせなくなります。

開発・設計部門の担当者ともレビューしながら、自分たちがやる時のことをイメージしてもらっているところです。

その中で、イレギュラー作業時のリスクを抽出してくれと言われました。

それには想定されるイレギュラー時の対処が手順化されていないと故障モードを挙げることはできないのでFMEAの範疇ではないと反論しましたが、それを言っても進まないので、こちらでイレギュラー対応の手順を元々あったかのように作成し、その手順での故障モードからリスクを評価することにしました。

何にせよ「まずは言い出しっぺがやってみる」、「問われたことには毅然と的確に答える」ができないといけないと思っているので、僕も相手部門の立場も考えながらやっているところです。