「システムや製品の問題が発生する前に、リスクを見つけたい」
「どこで故障が起こる可能性があるのか整理したい」
「発生する可能性のある問題に、優先順位をつけたい」
このようなときに活用される代表的な手法がFMEAです。
FMEAは、Failure Mode and Effects Analysisの略で、日本語では故障モード影響解析と呼ばれます。
製品やシステム、プロセスなどについて、どのような故障や問題が発生する可能性があるのか、その原因や影響は何かを事前に分析する手法です。
FMEAを使うことで、問題が実際に発生してから対応するのではなく、問題が発生する前にリスクを洗い出し、対策を検討することができます。
一言でいうと
FMEAとは、起こり得る故障や問題を事前に洗い出し、その影響や原因を分析して、優先的に対策すべきリスクを明確にする手法です。
ポイントは、「問題が起きてから分析する」のではなく、「問題が起きる前に分析する」ことです。
例えば、システム開発であれば、
- データが登録されない
- 誤ったデータが登録される
- 処理が途中で停止する
- 通知が送信されない
といった故障モードを想定します。
そして、それぞれについて、
- どのような影響があるのか
- なぜ発生するのか
- 現在の対策で防げるのか
- 追加対策が必要なのか
を整理します。
FMEAとは
FMEAは、製品やシステム、プロセスなどに存在する潜在的な故障モードを分析する手法です。
「故障モード」とは、故障や不具合がどのような形で現れるのかを表したものです。
例えば、
- 電源が入らない
- データが登録されない
- 通信が切断される
- 必要な情報が表示されない
などが故障モードに該当します。
FMEAでは、故障モードだけを見るのではありません。
それによってどのような影響が発生するのか、そしてなぜその故障が発生するのかまで整理します。
さらに、リスクの大きさなどを評価し、どの問題から対策すべきかを検討します。
FMEAの基本的な考え方
FMEAでは、基本的に次のような流れで分析します。
故障モード → 影響 → 原因 → 現在の対策 → リスク評価 → 対策
例えば、システムのデータ登録機能を考えてみます。
| 項目 | 例 |
|---|---|
| 故障モード | データが登録されない |
| 影響 | 業務処理が完了しない |
| 原因 | データベース接続エラー |
| 現在の対策 | 接続エラーを検知してログを出力する |
| 追加対策 | 自動リトライ機能を追加する |
このように整理することで、問題が発生する可能性のある箇所と、その影響や対策を体系的に確認できます。
FMEAで整理する主な項目
FMEAでは、分析対象に応じてさまざまな項目を設定します。
故障モード
どのような故障や不具合が発生する可能性があるのかを記載します。
FMEAの中心となる項目です。
影響
その故障モードが発生した場合、どのような影響があるのかを整理します。
例えば、
- 処理が停止する
- 顧客に誤った情報が提供される
- 業務が遅延する
- データが失われる
などです。
原因
なぜその故障モードが発生するのかを整理します。
原因を明確にすることで、どのような予防策が必要なのかを検討できます。
現在の管理・対策
現在、どのような予防策や検出策が存在するのかを整理します。
例えば、
- レビュー
- テスト
- 自動チェック
- 監視
- 承認プロセス
などがあります。
リスク評価
故障モードについて、影響の大きさや発生可能性、検出可能性などを評価します。
評価方法はFMEAの種類や組織によって異なります。
推奨対策
分析結果をもとに、追加で実施すべき対策を整理します。
例えば、
- 設計を変更する
- チェックを追加する
- テストを強化する
- 監視機能を追加する
- 作業手順を変更する
などです。
FMEAの進め方
ステップ1:分析対象を決める
最初に、何についてFMEAを行うのかを明確にします。
例えば、
- 製品
- システム
- 機能
- 業務プロセス
- 製造工程
などです。
対象範囲が広すぎると分析が複雑になるため、目的に応じて適切な範囲を設定します。
ステップ2:機能やプロセスを整理する
次に、分析対象がどのような機能やプロセスで構成されているのかを整理します。
システムであれば、
- 入力
- 処理
- データ保存
- 出力
- 通知
などに分解します。
ステップ3:故障モードを洗い出す
それぞれの機能やプロセスについて、「何がうまくいかない可能性があるか」を考えます。
例えば、データ保存機能であれば、
- 保存されない
- 誤ったデータが保存される
- 重複して保存される
- 一部のデータが欠落する
などを洗い出します。
ステップ4:影響を分析する
各故障モードについて、発生した場合の影響を整理します。
「その問題が発生したら、誰にどのような影響があるのか?」という視点で考えます。
ステップ5:原因を分析する
次に、「なぜその故障モードが発生するのか」を整理します。
例えば、
「データが保存されない」
という故障モードに対して、
- データベース接続が切断された
- 入力値が不正だった
- プログラムに不具合がある
- データベース容量が不足している
などの原因を洗い出します。
ステップ6:現在の対策を確認する
現在どのような予防策や検出策があるのかを確認します。
ここでは、単に「対策がある」とするのではなく、本当に故障を防止・検出できるのかを確認することが重要です。
ステップ7:リスクを評価する
洗い出した故障モードについて、リスクの大きさを評価します。
代表的な評価項目として、
- 重大度
- 発生頻度
- 検出可能性
などがあります。
評価方法や尺度は、組織やFMEAの種類によって異なります。
ステップ8:対策の優先順位を決める
評価結果をもとに、どの故障モードから対策するのかを決定します。
すべての問題に同じレベルの対策を行うのではなく、リスクの大きいものを優先することが基本です。
ステップ9:対策を実施し、再評価する
対策を実施したら、再度リスクを評価します。
対策によってリスクがどの程度低減したのかを確認し、必要であれば追加対策を検討します。
FMEAで使われるリスク評価
FMEAでは、故障モードごとにリスクを評価することがあります。
代表的な評価項目が、
- Severity(重大度)
- Occurrence(発生頻度)
- Detection(検出可能性)
です。
これらを数値化し、リスクの優先順位付けに利用する方法があります。
ただし、評価方法や計算方法はFMEAの種類や組織によって異なります。
そのため、「FMEAでは必ずこの計算方法を使う」と考えるのではなく、採用しているFMEAのルールを確認することが重要です。
FMEAの種類
FMEAには、分析する対象によっていくつかの種類があります。
設計FMEA
製品やシステムの設計に潜む故障モードを分析するFMEAです。
設計段階で問題を発見し、製品が完成する前に設計を改善することを目的とします。
工程FMEA
製造工程や業務プロセスなどに潜む問題を分析するFMEAです。
工程の中で発生する可能性のある問題を事前に洗い出し、品質問題を防止します。
システムFMEA
システム全体を対象として、構成要素間の関係やシステム上の故障モードを分析します。
複数の機能や部品が連携するシステムでは、個々の要素だけでなく、要素間の相互作用も考える必要があります。
FMEAとリスクマネジメント
FMEAは、プロジェクトや製品に潜むリスクを問題が発生する前に洗い出すという点で、リスクマネジメントと深く関係しています。
例えば、システム開発プロジェクトであれば、
「本番環境でデータ登録ができなくなる可能性がある」
という問題を想定します。
そのうえで、
- どのような影響があるか
- 何が原因になるか
- 現在の対策は何か
- 追加対策が必要か
を整理します。
これは、プロジェクトにおけるリスクの特定・分析・対応につながります。
FMEAとリスク登録簿
FMEAの分析結果は、プロジェクトのリスク登録簿に反映することもできます。
例えば、FMEAによって、
「特定の処理でデータが失われる可能性がある」
というリスクが見つかったとします。
その場合、リスク登録簿に、
- リスクの内容
- 発生原因
- 影響
- 発生可能性
- 影響度
- 対応策
- 担当者
などを登録し、継続的に管理することができます。
つまり、FMEAはリスクを発見するための分析手法として利用し、その結果をリスク登録簿などで継続的に管理することができます。
FMEAのメリット
問題が発生する前に対策できる
FMEAの最大のメリットは、問題が発生してから対応するのではなく、事前に問題を想定できることです。
早い段階で問題を発見できれば、設計変更やプロセス改善などによって、問題そのものを防止できる可能性があります。
リスクの優先順位をつけられる
すべての故障モードに対して同じ対策を行う必要はありません。
リスクを評価することで、優先的に対策すべき問題を明確にできます。
関係者の知識を共有できる
FMEAは、複数の関係者が参加して分析することで効果を発揮します。
設計担当者、開発担当者、テスト担当者、運用担当者などが参加することで、それぞれの視点から故障モードや原因を洗い出せます。
FMEAの注意点
評価の数値だけに頼らない
FMEAではリスクを数値化する場合がありますが、数値だけを見て判断すると危険です。
例えば、発生頻度が低くても、発生した場合の影響が非常に大きい問題があります。
そのため、数値だけではなく、故障モードの内容や影響を理解したうえで判断することが重要です。
分析を細かくしすぎない
すべての可能性を細かく分析しようとすると、FMEA自体が非常に大きな作業になってしまいます。
分析の目的と対象範囲を明確にし、必要な粒度で分析することが重要です。
一度作って終わりにしない
FMEAは一度作成したら終わりではありません。
設計変更や環境変更、新しい問題の発生などによって、リスクの状況は変化します。
そのため、必要に応じてFMEAを更新し、継続的に改善することが重要です。
関係者を巻き込む
FMEAを一人だけで作成すると、故障モードや原因の見落としが発生する可能性があります。
可能であれば、複数の専門家や関係者の知識を集めて分析することが効果的です。
プロジェクトマネジメントでの活用例
FMEAは製造業だけの手法ではありません。
プロジェクトマネジメントにおいても、将来発生する可能性のある問題を事前に分析するために活用できます。
| 場面 | 活用例 |
|---|---|
| システム開発 | システム障害や処理エラーを事前に分析する |
| 要件定義 | 要件漏れや誤解が発生する可能性を分析する |
| 設計 | 設計上の故障モードを洗い出す |
| テスト | 想定される問題をテスト項目に反映する |
| 移行 | データ移行時に発生する可能性のある問題を分析する |
| 運用 | 障害や業務停止につながる可能性を分析する |
プロジェクトマネージャ試験ではここが重要
FMEAについては、単に「故障モード影響解析」という名称を覚えるだけではなく、どのような目的で利用するのかを理解しておきましょう。
重要なのは、
- 問題が発生する前に分析する
- 潜在的な故障モードを洗い出す
- 故障による影響を分析する
- 故障の原因を分析する
- リスクを評価する
- 優先的に対策する対象を決める
という流れです。
特に、「問題が発生してから原因を分析する手法」ではなく、「問題が発生する前に潜在的な故障を分析する手法」である点が重要です。
PM道場のワンポイント
FMEAは「未来のトラブルを先に経験するための分析」と考えると分かりやすいです。
プロジェクトでは、問題が発生してから対応すると、スケジュールやコスト、品質に大きな影響が出ることがあります。
そこで、まだ問題が発生していない段階で、
「もしここが壊れたら、何が起きるだろう?」
と考えます。
そして、
「なぜ壊れるのか?」
「壊れたら誰にどんな影響があるのか?」
「今の仕組みで防げるのか?」
を整理します。
このように考えることで、実際に問題が発生する前に、設計やプロセスを改善できます。
つまりFMEAは、「問題が起きた後の対応」ではなく、「問題を起こさないための仕組み」を考えるための手法です。
関連用語
- リスク
- リスクマネジメント
- リスク分析
- リスク対応
- リスク登録簿
- 品質管理
- 品質保証
- 品質メトリクス
- 不具合
- 根本原因分析
- パレート図
- インスペクション
- レビュー
- テスト
- 継続的改善
まとめ
FMEAとは、故障モード影響解析(Failure Mode and Effects Analysis)のことで、製品やシステム、プロセスなどに潜む問題を事前に分析する手法です。
FMEAでは、
- どのような故障が発生する可能性があるか
- その故障によってどのような影響があるか
- なぜその故障が発生するのか
- 現在どのような対策があるのか
- 追加でどのような対策が必要なのか
を整理します。
そして、リスクを評価することで、どの問題から優先的に対策すべきなのかを判断します。
FMEAの重要なポイントは、「問題が発生してから対応する」のではなく、「問題が発生する前に対策する」ことです。
そのため、品質管理だけでなく、システム開発や業務プロセス、リスクマネジメントなど、さまざまなプロジェクトで活用できます。
また、FMEAで洗い出したリスクをリスク登録簿などで管理することで、分析結果を実際のプロジェクトマネジメントにつなげることもできます。
「もし問題が起きるとしたら、どこで、なぜ起きて、どんな影響があるのか?」
この問いをプロジェクトの早い段階で考えることが、FMEAの基本的な考え方です。
関連記事
- リスクとは?
- リスクマネジメントとは?
- リスク分析とは?
- リスク対応とは?
- リスク登録簿とは?
- 品質管理とは?
- 品質保証とは?
- 品質メトリクスとは?
- 不具合とは?
- 根本原因分析とは?
- パレート図とは?
- レビューとは?
- インスペクションとは?
- テストとは?
- 継続的改善とは?
よくある質問(FAQ)
Q. FMEAとは何ですか?
A. FMEAとは「Failure Mode and Effects Analysis」の略で、日本語では故障モード影響解析といいます。製品やシステム、プロセスなどに潜む故障や問題を事前に洗い出し、その影響や原因を分析する手法です。
Q. FMEAは何のために使いますか?
A. 問題が発生する前に潜在的な故障モードを洗い出し、リスクを評価して、優先的に対策すべき問題を明確にするために使います。
Q. FMEAとリスク分析は同じですか?
A. FMEAはリスク分析に活用できる具体的な分析手法の一つです。故障モード、影響、原因などを整理し、リスクを評価することで、対応すべき問題の優先順位を検討します。
Q. FMEAは問題が発生した後にも使えますか?
A. FMEAの主な目的は、問題が発生する前に潜在的な故障を分析することです。ただし、実際に発生した不具合や障害から得られた知見をFMEAに反映し、将来の同様の問題を防止するために活用することはできます。
Q. FMEAでは何を分析しますか?
A. 主に、故障モード、故障による影響、故障の原因、現在の対策、リスク評価、追加対策などを分析します。
Q. FMEAと根本原因分析の違いは何ですか?
A. FMEAは、まだ発生していない潜在的な故障や問題を事前に分析することを主な目的とします。一方、根本原因分析は、実際に発生した問題について「なぜ発生したのか」を掘り下げ、根本的な原因を特定することを目的とします。
Q. FMEAはプロジェクトマネジメントでも使えますか?
A. はい。システム開発、要件定義、設計、テスト、移行、運用など、将来発生する可能性のある問題を事前に検討する場面で活用できます。
私は令和5年度 IPAプロジェクトマネージャ試験に合格しました。
実際に合格した経験をもとに、勉強方法やおすすめ参考書、最難関といわれる午後Ⅱ論文の対策方法を詳しく解説しています。
「これから勉強を始めたい」「効率よく合格したい」という方は、ぜひこちらの記事もご覧ください。














