FMEAとシックスシグマ 「Measure」でやること3-2

皆さんこんにちは! 今日もどこかで改善サポート、Kusunoko-CIです。

シックスシグマの各段階でやることを、自分の理解の確認も含めて説明していくシリーズ。

前回、「FMEAとシックスシグマ」と題しまして、FMEAの成り立ちや目的、シックスシグマProjectでどう使われるのかを確認しました。

シックスシグマ「DMAIC」の、Measure(測定)で使われることも多い、とご説明いたしましたね。デザインなどの上流工程から、実際の工程改善やそのコントロールなど、幅広く活用されているのでした。

そこで今回は、そのFMEAの具体的な書き方です。実際のFMEAテンプレートを見ながら、ステップごとに確認していきましょう。

基本的な書き方を理解して、皆さんの工程改善やコントロールに活用してみてください!

FMEAの書き方

FMEAは、様々な分野・産業(ものづくりやサービスなど)で幅広く使われている、改善や問題予防のツール。まずはさっそく、具体的な書き方を見てまいりましょう。

今回は、シックスシグマのProjectでこのFMEAを書く、という場面を想定しながら進めてみたいと思います。

FMEAの作成前に

Photo by Pascal Swier on Unsplash

一番最初にしなければならないのは、いつものように「チームメンバーの確認」です。

当たり前のことですが、前もって決めたスコープの、「範囲」に関わる全ての部署の参加者がいなくては、精度の高いFMEAを作ることはできません。

せっかくやるなら、意味のあることにしたいですよね。

シックスシグマやカイゼンのProject において、このFMEAは、

  • 現在発生している問題(障害)の要因に「あたりをつける」
  • 将来発生するかもしれない問題を未然に防ぐため、可能な限りの可能性を挙げて対策を取る

という目的があります。

こうしたProjectを遂行するに当たり、必要な方々との参加合意は取れていると思いますので、このFMEAも各工程をよく知るみなさんで、書き進めてください。

FMEAステップ

ステップごとに、進め方・書き方を確認します。今回もまたピザ工程です(笑)

1.テンプレ・フォーマット

FMEA サンプル

以下のアイテムを含む、空白のテーブルをExcelなどで作成します。テンプレを用意してくれているサイトもあるので、手始めにそういうところでダウンロードすると良いでしょう。

そうしましたら、

  • その製造プロセスに関わる情報記入欄(ヘッダー)
  • プロセスステップ
  • 作業内容
  • 故障による影響
  • 故障モード
  • 故障の要因(メカニズム)
  • 現在の工程管理の手法
  • 重大度
  • 発生度
  • 検出度
  • RPN

など、だいたいこのくらいの情報記入欄は基本として設けてください。

工程・作成に関する基本情報

 

プロセスと故障関連情報

ただ作っているモノやサービスの違い、会社方針等で、記入情報にいろいろアレンジは必要になると思います。いずれは皆さんの実情に合った、最適なフォーマットを考えてみてください。

2.各プロセスステップと作業内容を確認

プロセスステップ・作業内容

前回もお話ししましたが、Projectを始めるに当たり、すでに「プロセスマップ」や「ディテイルドマップ(Detailed map)」というものを書いているはずですね。

隠れた工程(Hidden factory)や、作業ごとのインプットとアウトプットは、すでに明らかになっていると思います。

これらの文書が、このFMEA作成に大変役立ちます。

3.故障をブレインストーミング

チームの皆さんで、プロセスや製品、サービスで発生してる問題の要因や、発生する可能性のある問題のポイントについて、ブレインストーミングします。

いわゆる「Y=f(x)」の、全部のインプット(x)に対してやる必要はないですが、可能な限りアイデアを出しましょう。

4.故障とその影響

影響と故障モード

考えられる障害ごとに、問題がもたらす可能性のある影響と、故障モード(不具合)を書き入れていきます。

最終的なお客様はもちろんのこと、自工程や後工程に対しても、どのような影響があるのか書きいれてみましょう。

5.問題発生のメカニズムと現在の工程管理の手法

発生のメカニズム

なぜそのような故障が起きてしまうのか、原因(発生のメカニズム)を書きいれます。

実際に起きている問題であれば、当然「なぜなぜ5回」のような、真因追及が必要になるでしょう。

デザインやコントロールで、将来の不具合に対して予測を立てているのであれば、考えられる原因になりそうなものを、ブレインストーミングでアイデア出しです。

また現在すでに、品質に関する管理手法があるはずですから、それを書き込んでください。

ちなみに、こうした作業の繰り返しが、文書となり、皆さんの思考回路として蓄積されていくからこそ、FMEAが「カイゼンの財産」になっていくのですね。

6.点数付け・優先順位(RPN)

RPN=重大度x発生率x検出率

そしていよいよ点数付けです。

上記の流れで、故障モードや、発生のメカニズムなど、起こってほしくない事柄というのが列挙されました。

点数付け

次に、FMEA特有の3つの側面から、スコアを考える必要があります。

以下3つのスコアの種類です。

  • 重大度(Severity : S):障害モードの結果がどの程度大きくなるか。

いくつかの影響は製品やサービスにとって、壊滅的になる可能性があります(例:原子力発電所のメルトダウン)。

あるいは穏やかな場合もあるでしょう(例:製品の重量のわずかな変動)。

  • 発生率(Occurrence : O):故障・問題が発生する可能性の高さ。

発生する可能性が非常に高いものもあるでしょう(例:真夏の屋外で、ラップトップコンピュータが過熱)。

あるいは、かなりありそうもないかもしれませんね。例えば、前項の原子力発電所のメルトダウンなどは、そう頻繁にはないはずです。あってほしくない(笑)。

  • 検出率(Detection:D):現在のプロセスで故障・問題を検出できる度合い。

この障害モードが発生した場合、責任者はすぐにそれを知ることができるでしょうか?

これも検出が難しいものから、簡単に見つかるものまでさまざまあるでしょう。これらはすべて、1から10までのスケールを使用します。

ここが少し注意点なのですが、FMEAは、ある程度主観的であることは否めません。

このスコアリングについてコンセンサスを得るのが難しい場合は、チームの皆さんの個々のスコアから、平均スコアを計算するというのも一つのやり方です。

優先順位出力

こうして、それぞれの故障・問題にスコアを入れたら、優先順位を考えます。

先ほどの3つの数字をかけ算します。

式は

重大度x発生率x検出率

です。

これをRisk Priority Number=リスク優先度、RPNと呼びます。

何度も書きますが、全ての問題に対処するというのは、基本的には不可能です。ほぼ間違いなく、「すべてに手をつけようとして、結局何も達成できない」、という状況を生みます。

ですので、優先化のところでもお話しましたが、何が問題なのかを探って、そこから手を付けていくというのが、最も実践的な考え方になります。

当然、RPNのスコアの高い項目からになりますね。

割けるリソース、それから起こる問題の重要度から、今回はどこまで手を付けるのか、チームの皆さんで話し合ってください。

Projectを手掛けているときであれば、いわゆる「最も効きそうな要因(x)」を探すことになるはずです。

ちなみにこちらのサイトでは、スコア10段階の考え方が載っていますので、点数付けに迷ったら参照されるといいでしょう。

改善対策 立案と実行

Photo by Jakob Owens on Unsplash

ここまで来たら、あとは改善するのみ。

右側の

  • 改善案
  • 対策者(部門)
  • 期限(いつまで)
  • 実際の改善内容・状況
  • 改善策施行後RPN

を書きいれていきます。

改善案とアクション

Projectを手掛けているのであれば、取るべき改善策というのが、そのままProjectを始めるに当たって問題となっていたものを解決する策になりますよね。

シックスシグマで言えば、分析(Analyze)段階を経て、改善(Improve)のところまで来ていることになります。

特性要因図(Firstborn)や、「なぜなぜ5回」、「アイデア7 ways」などを駆使して、ソリューションを考え実行してください。

こちらアクションプランと同じく、誰がいつまでに実行するのかも忘れずに記入してください。

また、実行後は、新たにRPNを計算しなおします。

その変化により、第2、第3ラウンドのPDCAでも手掛けるのか、当面他の項目を優先するのかが見えてくると思います。

FMEA 注意点

Photo by Markus Spiske on Unsplash

勘のいい方はお気づきかもしれませんが、このFMEAも、かなり主観に左右される可能性を秘めています。

特に気をつけたいのが、チームの中で「声の大きな人」が活動を引っ張り始めた時です。その人の思うように、「有無を言わさず」な感じでスコアリングをしてしまうことの無いよう、気を付けてください。

チームワークとは何かを、メンバーの皆さんが学んでおく必要があります。またリーダーになる方は、そうした力関係にも配慮しなくてはいけません。

こういう部分は、シックスシグマの「Project champion」と呼ばれる、基本的には組織で最も高位にある方と、事前に話し合っておくと、いざという時に役に立ちますよ。

また、先ほども述べましたが、「一回Project使用して終わり」という使い方になってしまっては、このFMEA、とてももったいないです。

工程であれ、デザインであれ、活動をした証であり、社内でノウハウを蓄積していく大切な記録になります。

ぜひ、定期的に改定され、やったことが次へと活かされるようなものにしていきましょう。一度書いて終わりではない、「生きた書類(living document)」になるよう、全体のカイゼン活動の一部に組み込んで、定期的に更新してください。

まとめ

いかがでしたでしょうか?

2回にわたりまして、「FMEAとシックスシグマ」のご説明でした。

ISO9001」で定められているため、製造業ではかなり広範囲に使われておりますね。Kusunoko-CIの勤めているEMSでも、「マストアイテム」になっています。

もちろん他の、製造業以外の産業で使用している会社も多いでしょう。

再確認ですが

  • 潜在的に発生可能な問題を洗い出し、対策を打つことで、不良品を造らないプロセスを構築する
  • 万が一問題が発生した場合にも、いかに発生した不良を後工程・お客様に流さない工程管理を行うか

これらが工程FMEA作成の目的になります。

必要情報やスコアリングなどは、会社の方針、製品・サービスなどで様々です。皆さんの会社の実情にあったものを作り、実践していくようにしてください。

品質は一日にしてならず」です。ぜひ皆さんの改善活動・シックスシグマProjectでご活用ください。

今回も読んでいただきまして、ありがとうございました。

では!

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA