- この記事を読んでほしい人
- ・社内でFMEA運用の形骸化に苦慮しているエンジニア管理者
・これからFMEAを運用して製品の品質を上げたい管理者
・品証部門なのにFMEAしろと言われて困っている品質保証部員
・社内、市場で不良が多すぎて対応に疲れ切っている品質保証部員
今回の記事では、
工程設計のFMEAである「工程FMEA」について、製造業を主な事例として正しい理解と役割分担について述べたいと思います。
僕の経験上と職業柄から、製造・サービス販売業に従事している管理者で以下のような悩みを持つ方は多いと思っています。
・現場任せでの不十分な工程設計による製造不具合の多発、流出
・不具合多発、流出による対応コストがかさんでいる
メーカー勤務のエンジニアは聞いたこと、もしくは実際に運用している方もいるでしょう。
FMEA(Failure Mode and Effects Analysis 故障モードと影響度解析)
自動車産業の国際品質マネジメント規格であるISO/TS16949の要求事項として、不具合の未然防止のためFMEAなどを用いてリスクマネジメントすることが記載されています。
FMEAとは製品構造や製造・サービスを作りこむ工程を設計する際に、品質を作りこむ手法の一つです。
読んで字のごとく、作りこむ製品または工程を「故障モード」を起点に、不具合発生時の影響度を評価し、対策の要否を検討・レビューするものです。
これまでの僕の経験上、開発部門で運用しているFMEAは「効率の良し悪し」は別として設計の妥当性を検証する方法としては、ある程度機能していると思います。
しかし、工程設計におけるFMEA(以降「工程FMEA」と呼ぶ)が正しく運用されていないもしくはFMEAをやっていないメーカーや工場が多くみられます。
その理由は、以下のような事が組織内で意思統一されていないからです。
・工程FMEAそのものの理解
・どの部門が主体的に品質管理を行うのか
・コストや実現性の面で現実的な対策の基準
・不具合予防へのリソースシフトによる事後対応コスト削減の共通認識
上記を組織内で正しく理解・意思疎通し、製品やサービスの量産までに検討することで、立ち上げから品質を確保でき、不具合にかかる事後コストを低減することができると考えます。
■この記事を基に考えてほしい事
・社内での品質管理体制見直しへのキッカケづくり
・予防コストにリソースをかけ、量産立ち上げ後の不具合対応コストを減らすことで利益をあげやすい企業体質
なぜこのような記事を書こうとしたかと言うと、僕(品質保証部員)が上司に提出した製造工程内不具合の傾向分析資料について、上司から
「ありがとう。よくまとまってますね。あとはFMEAでまとめてくれるとさらに良いですね。」
と言われたときに、違和感を感じたからです。
当然上司は悪いことは言ってないのですが、品証部員がFMEAを行うのは間違っていると僕は思います。
メーカーで開発を10年以上経験し、転職を機に初めて品質保証部へ配属された僕の経験から来ている考え方です。
これを説明するのには順を追って説明する必要があります。
まずはこの企業がQCDの何を重視するのかです。
QCD(品質、コスト、納期)何が最優先か明確にさせること
ビジネスマンであれば聞いたことがあるとおもいますが、ビジネスで重要なQCDと呼ばれる3要素(Quality、Cost、Delivery)があります。
あなたの会社はこの3つのうち1つを優先させなければならない場合は何を優先しますか?
このような質問をすると、おおよそ企業の幹部は「そりゃあ、品質(Quality)ですよ!」と言います。
しかし、実際の現場ではコスト、納期が優先されていることが多いのです。
そうなってしまう現場の気持ちもよく分かります。
なぜならコストと納期は失敗が顕在化されやすく、短期的にダメージも大きいからです。
このような状況だからこそ、トップや幹部が方針を明確にして末端まで浸透させる必要があります。
究極の選択を迫られたときに優先するものが
品質なら品質。
コストならコスト。
納期なら納期。
だと。
「QCD全てを高いレベルにする!」という方針は当然あるべき姿としてはいいですし、それが理想的ですが、不測の事態で何を優先すべきかは今一度明確にしておくべきです。
そうでないと、各部門の利害により主張が平行線をたどってしまいます。
極限状態や判断に迷ったときに組織が一つの方向に進んでいくためには、唯一無二の方針が必要なのです。
僕個人としては、「品質」です。
品質で信用を失うと挽回するのに相当な苦労があるからです。「築城三年 落城一日」です。
下手すると人命にかかわる場合もあります
その品質重視の意識が浸透していないとFMEAは形骸化し、工数のムダになるだけです。
製品品質管理における間違った役割認識【品証部門は嫌われ者になろう】
まずは組織の各部門の役割を、製造部門が工程設計を行う会社を例に定義します。
設計開発部門:設計品質管理(ルール順守監視、記録)
設計の妥当性検証
製品信頼性評価
設計標準の作成・改定
製造部門:製造品質管理(ルール順守監視、記録)
製造工程設計
製造工程信頼性評価
品証部門:全体品質管理(ルール順守監視、記録、あらゆる品質データの蓄積と分析)
これまでの経験上、数多くの企業で
「品質問題の対応や責任元は品質保証部でしょ」
というような風潮を感じます(すべてというわけではありません)。
少なくともお客様に対してはそれでも問題ありませんが、社内において基本的な品質を作りこむのは設計開発部門であり、製造部門です。
それぞれの分野でプロフェッショナルなのですから。
想像してみてください。
他の部門が付け焼刃の知識でとやかく言ってきたら嫌ですよね?
さらに、素人が入り込むとムダに検証しなければならないことが増えて非効率です。
品質保証部は、各部門の品質管理が「妥当である」ということにお墨付きを与える部門です。
そして、そのお墨付きが正しかったかどうかの確認のため社内のデータを蓄積、分析して問題があれば社内の仕組み変更や関係部門にフィードバックして是正させます。
品質確保、品質保証部門の仕事が増えすぎないように「嫌われ者」に徹して、各部門にしっかり品質管理させるのが役割です。
工程FMEAの考え方
ここまでの内容で、社内での品質管理体制の意識を統一し、工程設計部門が工程FMEAを実施すべきということは分かっていただけると思います。
以降で工程FMEAを効果的、効率的に行うための重要事項を記します。
工程FMEAにおける故障モードの考え方
たとえば「ネジを締める」という工程があったとします。
この工程での「故障モード」はなんでしょうか?
冒頭にも書きましたが、故障モードとは「設計ルールや製造条件、保全ルールを遵守しないこと」になります。
ネジを締める行為は「物と物を結合させる機能」を作りこむ工程です。
この「ネジを締める」工程の故障モードは「ネジの締め忘れ(ポカミス)」になります。
よく勘違いするのが、「ネジの締め忘れ」によって発生する機能不具合「物と物が外れる」というのは「機能不具合」であって「故障モードとは異なる」ことに注意してください。
客観的な評価方法の定義
対策が必要かどうかは以下の項目の度合いから検討します。
・不具合の影響度
・不具合の発生頻度
・不具合が事故につながるまでの検出しやすさ
それぞれに4~5段階の点数を定義します。この時の点数は適当に決めるのではなく、過去のデータや、製品の重要度(人命にかかわるなど)によって決めなければいけません。
これらの総合点(RI:Risk Index)が低くなるように設計していきます。
航空機や電車などは1年に1回の不具合で大事故を起こしても頻度が少ないとは言えないでしょう。
検出しやすさが高い(ほぼ工程内で検出できる)ものは、高コストな対策は不要でしょう。
というように、扱う製品やサービスによって評価の度合いは異なるのです。
よって、評価点を管理の都合で相対的に決めれるものではありません。
有識者が技術的な観点から評価し、対策の要否や対策のレベルを決めていきます。
先ほどの例の「ネジの締め忘れ」は対策として、電動ドライバーでの締め付け回数カウンターを設置し、ネジ締め回数が規定数に一致しないと次の工程に進めないような仕組みにするという対策で大幅に「ネジ締め忘れ」を防止することができます。
工程での故障モードの大半はヒューマンエラー(ルールを守らない、守れない)によるものです。
ポカヨケを盛り込むことで、工程の信頼性が大幅にアップします。
こういったポカヨケの手法は、長年の経験と知識をもった部門でないと現実的な対策は打てません。
よって、FMEAは設計部門主導で行うべきものと主張します。
工程FMEAのフォーマットと事例
■注意事項
・対策が十分かどうかは、その分野の技術的判断、個別の製品の故障影響度によるのでFMEA自体が評価結果または定義を導くものではない。=評価結果は有識者で決める
・設計部門の中でレビューし、設計部門としての設計意図を数値化し他部門と妥当性を議論できるようにすることが目的である。
・「十分」で合格とするか、「不十分」で合格とするかは対策にかかるコストと故障モードの影響によって判断する。
・品質保証部門は、リスクが高い項目を残留リスクとして管理するか、さらなる対策をさせるかを市場の影響を考慮に入れて承認を検討する。
・影響度の高い項目を重点的にチェックして精査する。
ここで評価結果をシンプルに4段階としているのは、細かく定義してもどれがどの点数になるかが採点者によってばらつく可能性が大きいからです。
選択をシンプルにして、どの点数をつけるか議論して意図を明確にすることに意義があります。
例えば、発生頻度を1~10段階にして「1点」を「5年に1回程度」と定義したとしましょう。
5年に1回の不具合発生でも、人命にかかわる場合は「1点」としていいのでしょうか?
また、
検出度を1~10段階にした時に「5点」をどのように定義するのでしょうか?
定義できる根拠はなんでしょうか?
ここでは故障モードの影響への対策が十分といえるかどうかを4段階に分け、議論をして近いと思われる点数をつけます。
これが設計者の意図になります。
品証部門も交えてレビューすれば、会社としての意図になります。
「この故障モードに対しては影響は小さいから、この程度の対策で妥当でしょう」という合意をとるのです。
もちろん運用実績がない状態だと、リスク指標の精度は落ちますが、まずは継続しやすさを優先して実績を重ねながら定義を微調整していけば良いのです。
これさえやっておけば誰でも完璧な設計ができる汎用ツールなどないのですから。
イレギュラー対応時のプロセス設計とリスク評価
一点だけ留意してほしいことがあります。
定常運転(レギュラー作業)であれば、そう簡単には不具合は発生しません。
不具合の発生や流出はイレギュラー作業時に最も起きやすいということです。
設備が故障した時やシステム障害、部品が足りないなどの突発のトラブルが発生し、製造やサービスの停止を余儀なくされた時に
・いつもと違う人が作業する
・暫定的な方法で製造やサービスを再開する
・設備や工具を入れ替える
・製造途中の製品を一気にまとめて加工などの処理をする
などの非定常運転(イレギュラー作業)が最も工程の信頼性が低くなるのは言うまでもないでしょう。
せっかく手間をかけてFMEAを行うなら、
トラブル発生時作業の復旧プロセスも設計し、信頼性評価するべき
です。
ただ、突発的なトラブルは無数に考えられるので、いちいちそのトラブルに対する具体的な対応策を考えていては時間がいくらあっても足りません。
このような場合に設計し評価した方が良いのは、トラブル発生~定常運転に戻すまでの大枠のステップです。
例えば、
製造やサービスを停止する基準(影響がどの程度でストップさせるか)
↓
意思決定の方法(責任者に連絡など)
↓
復旧までの作業者の対応(勝手な作業をしないなど)
↓
製造やサービス再開後の製品やサービスの品質チェック手順
といった一連の大枠の流れとそれぞれの中身を設計し、故障モード(決まったルールや手順から外れる事象)から解析を行い、リスク評価するのです。
経験上、このイレギュラー時の復旧プロセスの信頼性が高ければ、製品やサービスの品質は大きく改善すると考えます。
あわせて、実際に作業する人の「ルール順守意識の向上」も見込まれます。
なので、完璧とはいかないまでも留意して工程設計しておくことを推奨します。
工程FMEAの社内運用例
製品設計・開発部門は設計FMEAを行い、製品構造の観点から故障モード起点で設計対策を盛り込みます。
これをレビューする際には、工程設計部門との連携も必要です。
【設計FMEAで製品設計部門と工程設計部門が共有すること】
設計やコストの制約でリスクが残っている項目に対して、製造工程での作りこみで品質を確保する必要があるかないか
設計FMEAが終われば、続いて工程の設計を詰めていきます。
製造ラインの工程設計ができた段階で、工程設計管理者は工程FMEAを行わせて工程の信頼性を評価させます。
このときは有識者数人でレビューして現実的なリスクに対して適切な対策を盛り込んでいきます。
この結果を品質保証部は承認し、設計部門がただしく設計を行ったことにお墨付きを与えます。
【工程FMEAで品質保証部と工程設計部門が共有すること】
製造方法やコストの制約でリスクが残っている項目に対して、投資してでも製造工程での作りこみで品質を確保する必要があるかないか(残留リスクとして管理するかどうか)
その後は、ただしく決めた通りに作業しているかどうか、対策が盛り込まれているかどうかのパトロールを第三者部門として行います。(作業手順、記録簿など)
対策に完璧を求めるところと、妥協するところのメリハリをつける
工程のリスクに対して対策を盛り込む際には、無理に高価な設備を入れる必要はありません。
若干信頼度は落ちますが、日常点検や管理者による2重チェックなどアナログ的な対応でも管理がしっかりしていれば問題ありません。
事象に対して、どれだけの影響や検出しやすさを考慮して現実的な対策を盛り込むこともコストを抑えた設計としては、そういう意図があるということが説明できればいいと考えます。
そこで議論が産まれるようだと、経営層で判断してもらいましょう。
これから工程FMEAを実践する場合
FMEAを社内のルールとし、実践していくにはステップを踏んで関連部門の意識を合わせる必要があります。
ある特定の部門からの発案では、会社としてFMEAを行うことの目的が浸透せずに形骸化する恐れがあるからです。
そうなると工数をかけた割に成果が出せない状態が続いたままとなって、尻すぼみになってしまう可能性が高いです。
以降では、品質保証部門から工程FMEAを社内のルールとすることを進める場合を例にして説明します。
ステップ1:FMEAの本質を理解する
ステップ2:社内運用の骨子を作成する
ステップ3:役員、関連部門の幹部にFMEAを行う目的を理解してもらう
ステップ4:各部門の幹部からそれぞれの部門の内部にトップダウンする
ステップ5:品証部門で社内の仕組み、FMEAを行う際のルールを作成する
ステップ6:各部門担当向けに説明会を開催し、実践を開始する
ステップ1:FMEAの本質を理解する
まずは完ぺきとはいえないまでもFMEAに精通した人がいなければ話になりません。
目的は何なのか、メリットは何なのかを誰が聞いても納得できなければいけません。
■目的
製品やサービスの量産までに製造工程起因の不具合発生リスクを潰しこみ、量産後の不具合による損失を最小化することを図る
■メリット
・事後対応コストの削減
・設計部門の設計品質レベルアップにつながる
・成果物(FMEA結果)自体が「設計の要点」がまとまった設計ガイドラインになるので、他の人のレベルの底上げやノウハウ継承になる
・設計の意図が数値化されるので、他の部門が見ても「どの工程がリスクが高いか」、「設計者が品質に対してどのように考えたか」が直感的に分かりやすい
などが挙げられます。
■工程FMEAの本質を理解する
運用にあたっては、各部門からの問いに的確に答えられなければいけません。
本質は設計部門がFMEAを活用して思考を凝らして工程設計をすることで工程の信頼性を上げて、そのレビュー結果を他部門がみてもわかるように数値化して残すことです。
※これにより、第三者による品質パトロールで重点チェック工程と対象の作業を絞りやすくなります。やみくもに全てのプロセスをチェックするよりも効果的で効率的な監視体制をしくことができるのです。
理解を深めるにあたって特に重要なポイントは以下。
・故障モードの理解
設計した工程に対して、「設計した手順や作業方法、製造条件」が、ある要因(ヒューマンエラーや怠慢など)によって逸脱することで発生する現象
例)部品付け忘れ、設備設定条件間違い、消耗品交換周期忘れなど
設計者が、5M(人、材料、設備、加工方法、測定)の観点で設計した指示の通りに遵守されない場合を想定し、その対策を評価結果に応じて盛り込む。
なお、ここでは製造に使用する「部品自体の不良」は含まない。
これは工程設計が行う範疇ではなく、サプライヤーに保証させるべきであり、購買部門やサプライヤ品質管理部門の役割となる。
加えて、「消耗品交換ルールがない」というようなものも故障モードではない。
このようなルールは本来設計時に必要不可欠なものなので、これは「設計の怠慢」である。
ルールが設計されていれば、「ルールを守らなかったこと」が故障モードである。
ちなみに現実的に起こり得ないような故障モードまで列挙すると時間がいくらあっても足りないので、起こり得る故障モードを列挙させるようにする必要があります。
・成果物(FMEA完了結果)の扱い
工程設計部門が技術的観点で評価を行い、設計部門なりにリスクを数値化したものであることを理解し、品証部門は数値的にリスクが高いものへの対策が十分といえるかどうかを精査する。
(市場への影響の観点で対策の妥当性、対策に抜けがないかを精査)
このためには、すでに述べたように評価の尺度はシンプルでなければならない。
また、品証部門は過去の障害情報(故障原因、その対策)の蓄積をしておく必要がある。
最初のうちは議論が産まれるでしょうが、その議論を通して評価の精度が上がっていくものと考えましょう。
未然防止にリソースを割くということは、量産前の準備工数が大幅に増大します。
当然各部門、ヘタすりゃ自部門からも工数増に対する批判が飛んでくるでしょう。
今以上に品質を良くしようとしているのに工数が減らせるなんて甘い考えをもつな
と言ってやってください。
非効率的に未然防止を考えることによる工数増を、少しでも抑制するためのFMEAという手法なのです。
未然防止への工数増を毛嫌いする前に、今まで惰性でやってる非効率な仕事をやめる努力をするべきです。
ステップ2:社内運用の骨子を作成する
FMEAの理解を深めたら、各部門の幹部に説明するためのプレゼンを行う。
この時に、以下のことを理解してもらうことに重点をおきましょう。
・目的、メリット
・どの部門が何を責任もってやるか
・FMEA様式例、評価の尺度
・レビュー、承認の仕組み
ステップ3:役員、関連部門の幹部にFMEAを行う目的を理解してもらう
これがないと、円滑な運用や各部門の自主的な品質向上は望めません。
大きな投資が必要なわけではないので、常識的な幹部なら拒否されることはないでしょうが、
「みんな同意したよね?」という証拠づくりですね。
それでも
量産前でバタバタしてる時に、今以上に工数かけれるわけない!
もっと簡素化しないと形骸化して定着しない!
他に効率的でコストのかからない案は無いのか!
というようなセリフが飛んでくるのは容易に想像できます。
そりゃ気持ちは分かりますよ。
間違いなく手間暇かける必要がありますし、工数も増えます。
でも、よく考えてみてください。
そんなことを言う幹部ってどう思いますか?
手間がかかるからと言って、工程設計で手を抜いていいんですか?
定着しないなんて、実際やってみる前から諦めですか?
(そもそも未然防止が定着してないのは誰のせいですか…?)
他にいい案がないなら一緒に考えてくださいよ
今以上に品質を上げるつもりはないんですか?
今以上に品質を上げたいという会社としてのゆるぎない方針はトップから宣言しないと、末端では同じベクトルを向いて動けません。
形だけの「品質第一主義」なら品質保証部は不要です。
「クレーム処理兼ISO監査対応部」という部門名にしてほしいくらいです。
このステップで、その会社の品質に対するホンネが見えてくるでしょう。
「よし!やろう」となれば品質保証部の権限が増します。
「やらない」や「骨抜きの仕組み」になるようなら、クレーム処理に専念することになるでしょう。そうではないことを祈りたいですが。
ステップ4:各部門の幹部からそれぞれの部門の内部にトップダウンする
自部門からのトップダウンですら末端まで想いが響くとは言えないことは、組織人なら分かってもらえると思います。
よって他部門から強制されてもなおさら末端まで響きません。
他部門への意識付けは、その責任元部門のトップダウンでなければ機能しません。
今回の場合であれば、工程設計部門のトップからトップダウンで指示をしてもらいましょう。
ステップ5:品証部門で社内の仕組み、FMEAを行う際のルールを作成する
FMEA実施~承認までの詳細ルールの作成、設計の評価の定義を行います。
特に重要なのは「設計の評価の定義」です。
たとえば、下記のような具合で評価点の決め方のルールを定める。
評価点1の「完全」は、人の判断に頼らずに確実に設計通りの機能が作りこまれる対策あり(ポカヨケあり)。
例)ある作業を間違えたら組立ができないなどでラインが止まる
評価点2の「十分」は、ポカヨケは無いが安定した作業が行えるもの。
例)治具使用による作業の安定化、後工程で検出するための検査があるなど
評価点3の「不十分」は、作業者の目視確認のみなど人の判断に頼るもの
評価点4の「無策」は、設計時に考慮がされておらず、作業者の気づきでないと作業の不備が検出できない
ここが曖昧で推測で判断するようになると、評価結果に個人差が生じやすくなります。
ステップ6:各部門担当向けに説明会を開催し、実践を開始する
ステップ5までが実施されていれば、比較的容易にスタートは切れるでしょう。
細かいディテールを関連部門に事前に説明して意識を合わせておきます。
当然FMEAを深く理解した人は、曖昧部分の問いかけに対して的確に答えを出せるようにしておく必要があります。
問いかけに対するやり取りを繰り返して評価結果の再現性を高めれるようになります。
まとめ
ここまで読んでいただいた方にはご理解いただけると思いますが、FMEAのやり方と様式だけ持ってきて形だけ実践しても、それで設計品質が良くなるわけではありません。
そんな便利なものがあれば苦労はないです。
あくまで設計者自身が、どこまで設計時に品質の観点で一つ一つ考え抜き、記録して有識者で議論し、最適設計として組織内で承認するためのツールのひとつにすぎないのです。
最終的にはエンジニアの技量と品質保証部のリスクマネジメントによる部分が大きいと考えます。
このことをしっかりと認識してもらえれば、各分野それぞれで最適な運用方法を確立できるでしょう。
まだ言いたいことや、ポイントの整理、図解などが十分記載できていないので、別途書き足したいと思います。
とにかく、予防コストにリソースシフトしていかないと高品質で高い利益を産めません。
昨今はトライアンドエラーで、不具合を出しつつスピーディに市場投入しながら品質を向上させる企業も多いです。
どちらがいいとは言えませんが、事前の設計が良いものであるに越したことはありません。
効果的で効率的な日本の物づくり力が発展していくことを祈ります。
【参考にした資料】
僕が開発部門時代から10年以上熟読して勉強させてもらった下記サイト。
もっと深く品質管理を学びたい方は是非見てみてください!
これ以上に納得できる解説をされているサイトを僕はまだ見たことがありません。
客観説TQM研究所
FMEA 故障モード影響解析(TS16949)| 客観説TQM
おわり
コメント