前回のその1に続いて解説します。
前回、FMEA自身の故障モードについて書いた後、他にどのようなFMEAの故障モードがあるのか、改めて考えてみました。ここではASQ（American Society for Quality）の情報を参考にしつつ、いくつかのFMEA自身の故障モードを取り上げながら、対応策を考えたいと思います。
1. 品質やプロセスの向上に結びつかない
FMEAの目的は、FMEAの表を作ることではなく、リスクに対して何らかの行動（対策）を起こすことです。FMEAでは、それぞれのリスクに対して対策案を検討しますが、その対策を実施しないとしたら、FMEAの意味がありません。
洗い出したリスク対策は、設計の変更などを通して、製品やプロセスの品質向上に結びつかなくてはなりません。時々、リスク対策とテスト項目との混同が見られ、FMEAで洗い出したリスク対応策をテストのみで使っていることがありますが、テスト段階でリスクが顕在化しても意味がありません。リスクが顕在化する前に対策を行うことがFMEAの目的となります。FMEAで洗い出した対応策は、品質や信頼性の向上に結びつけるためにも、製品やプロセスの設計見直しに用いられるべきです。
2. プロジェクトの進行に合わせて更新されない
RPN（Risk Priority Number 危険優先指数）や対応策は、プロジェクトの進行や、設計の変更、対策の施行などによって随時変わってきます。しかし一度作られたFMEAは、なかなか更新されません。現状を正しく反映させるためにも、定期的にFMEAの見直しと更新を行うべきです。
実施した対策と未実施の対策を管理し、またそれに応じてリスクの優先順序の変更を行います。古い内容は、誤った判断につながる可能性があるからです。
3. 危険度の高いリスクに対応できていない
FMEAでは危険優先指数（RPN）でリスクの優先順位を把握し、一般的にはこの数字が大きいほど危険度が高いと判断します。しかし注意しなければならないことは、危険優先指数（RPN）を構成する要素の一つである、Severrity（影響の厳しさ）です。もし影響の厳しさ（Severrity）が異常に高ければ、仮に危険優先指数（RPN）が低くても、真っ先に対応しなくてはなりません。
危険優先指数（RPN）を構成する他の要素である occurrence（頻度）も重要です。もし頻度（occurrence）が異常に高ければ、仮に危険優先指数が低くても、対応する必要があるでしょう。
危険優先指数（RPN）だけに頼っていると、本当にリスクの高い項目を見逃す恐れがあります。危険優先指数（RPN）、影響の厳しさ（Severrity）、そして頻度（occurrence）などをどのように判断するかを、社内で標準化する必要があります。
危険優先指数（RPN）だけに頼っていると、本当にリスクの高い項目を見逃す恐れがあります。危険優先指数（RPN）、影響の厳しさ（Severrity）、そして頻度（occurrence）などをどのように判断するかを、社内で標準化する必要があります。
4. プロジェクト管理やテスト計画に反映されない
FMEAで洗い出したリスク対策は、プロジェクト管理やテスト計画にも反映されるべきです。リスク対応には時間もコストも掛かるため、もし対応策がプロジェクト管理に反映されていないとすると、プロジェクトが計画とかけ離れたものになります。リスク対策をプロジェクトに組み込むためにも、FMEAはプロジェクト管理とのコミュニケーションの道具として使います。
またFMEAで見つけた故障モードの原因は、テスト計画にも反映されるべきです。発見された故障モードの原因をテストで再現することによって、その故障モードの回避や低減、検出が正しくできているかどうかを確認できるからです。
5. 外部インターフェースが十分考慮されていない
多くの異常（50％を越える）は、外部とのインターフェースが問題で起きていることが、過去のデータからも分かっています。FMEAで故障モードの原因を探る際は、外部インターフェースを十分に考慮する必要があります。
時々、対象とするシステム内のリスクだけに注目し、外部インターフェースを考慮していないFMEAを見かけます。外部インターフェースを十分考慮するために、ブロック図やプロセス・チャートなどを併用すると良いかもしれません。
6. 現場の声が反映されていない
リスク（故障モード）は客先で健在化します。そのため現場の生の声、生のデータをFMEAに取り込む必要があります。現場からのフィードバックが反映されていないFMEAでは、正しい判断ができません。
FMEAを実施する際は、客先でのデータを十分考慮したり、現場の担当者をチームに加えて議論することも大切です。
7. 範囲やレベルが混在している
FMEAを実施するときは、対象となるシステムの範囲とレベルを明確化し、厳密にその範囲とレベルを守る必要があります。範囲やレベルが混在すると、FMEAが管理不可能になるだけではなく、リスク対策も実施不可能になります。
例えばハイレベルのFMEAを実施したにも関わらず、サブシステムレベルの故障モードが入ったりすると、リスク項目の数が増えるだけではなく、相対的な危険優先指数の評価ができなくなったり、故障モードの原因が複雑化したり、またリスク対応の責任所在もあやふやになります。
厳密にFMEAの範囲とレベルを守るためにも、会議での議論を上手にコントロールする必要があります。また外部インターフェースを考えたときのように、ブロック図やプロセス・チャートなどを併用すると、混在化が防げます。
8. FMEAを実施するのが遅すぎる
FMEAは、まだプロジェクトに対策を行う時間と余裕がある時に実施します。すべてが終わってからFMEAを実施しても、リスク対応が取れないからです。繰り返しになりますが、FMEAの目的は、リスク対策を実施し、製品やプロセスの品質を向上させるのが目的です。
しかし早ければ早いほど良いというものでもありません。まだ製品やプロセスのコンセプトが決まっていない段階でFMEAを行っても（コンセプトFMEAは別ですが）、あまり効果がないばかりでなく、後に改めてFMEAをやり直すことになり、効率が悪いからです。
9. チーム編成が適切でない
FMEAはチームで議論するため、チームの中に各分野の専門家が必要となります。もし専門家が欠けていたり、専門家が十分な議論に参加しなかったりすると、FMEAの分析が不十分になります。FMEA実施の際は、各分野の専門家をチームに集めると共に、専門家の積極的な議論への参加が不可欠です。
10. FMEA実施の手順が適切でない
正しくFMEAを行うには技術と知識、そして経験が必要です。正確かつ効率的にFMEAを実施するためにも、事前のトレーニングが不可欠です。また、Parameter Diagram や Boundary Diagram、ブ...
