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