日本語

FMEA:故障モードと影響分析の解説

FMEAの故障モードと影響分析ワークシートの概要

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

FMEAとは故障モードと影響分析(failure mode and effects analysis)の略で、エンジニアリングとオペレーションチームが問題が顧客に届く前に防ぐための手法です。チームが「何が問題になりうるか、そしてどれほど深刻か?」と問うことがあれば、FMEAはその問いに体系的に答える方法です。

FMEAとは

FMEAは製品、プロセス、またはシステムの潜在的な障害を特定し、その原因と影響を判断し、チームが最も優先度の高い項目に最初に対応できるようリスクで優先順位付けするための体系的な手法です。

成果物はスコアリングされたワークシートです。各故障モードは3つの要因に基づいて**Risk Priority Number(RPN)**を得ます。障害がどれほど深刻か、どのくらいの頻度で発生する可能性があるか、そして現在の管理策がそれが被害を引き起こす前に検出できるかどうかです。チームは最も高いRPNを持つ故障モードに改善努力を集中させます。

FMEAは単に何が問題になりうるかを文書化するだけではありません。部門横断チームが生産開始前またはプロセス変更が本稼働する前に、体系的に障害を考え抜くことを強制します。

主要事実

FMEAは1949年に公表されたMIL-P-1629で米軍によって最初に体系化され、当初はミッションの安全と成功のために兵器と装備システムの障害を評価するために開発されました。

NASAは1960年代のアポロ計画でFMEAを採用し、信頼性エンジニアリングの実践の一部として、その後航空宇宙産業と自動車産業に広がりました。

Automotive Industry Action Group(AIAG)とVDAは2019年にFMEAの共同ハンドブックを公表し、現在は両組織の以前の版に代わる自動車のDFMEAとPFMEAのグローバル参照標準となっています。

FMEAの種類

FMEAは一律ではありません。スコープによって必要な種類が決まります。

FMEA種類 正式名称 対象 使用場面
DFMEA Design FMEA 製品設計とコンポーネント 製品開発中、設計確定前
PFMEA Process FMEA 製造またはサービスのプロセスステップ 生産プロセスの開始または変更前
SFMEA System FMEA サブシステム間の相互作用 インターフェースでの障害が最も重要な複雑なシステム

**Design FMEA(DFMEA)**は製品設計自体が障害を起こしうるかどうかを検討します。プラスチックコンポーネントが熱応力で割れたり、ソフトウェアモジュールが高負荷でクラッシュしたりすれば、それは設計上の故障モードです。DFMEAはエンジニアリングチームがまだ図面や仕様を変更できる早い段階で実施します。

**Process FMEA(PFMEA)**は製品を製造または提供するプロセスで何が問題になりうるかを検討します。完璧な設計でも、組立ステップに欠陥があれば欠陥品を生産します。PFMEAは製造とサービスオペレーションでより一般的な種類であり、Six Sigma改善プロジェクトに最も直接的に関連します。

System FMEAはさらに視野を広げてサブシステムがどのように相互作用するかを見ます。障害ポイントが単一のコンポーネントではなく、それらの間のインターフェースにある航空宇宙・防衛で一般的です。

ほとんどのオペレーションおよび品質チームにとって、PFMEAが出発点です。製品開発に携わる場合はDFMEA、高度に規制された業界では主にシステムFMEAに遭遇します。

RPN:重大度、発生頻度、検出性

重大度×発生頻度×検出性のFMEAリスク優先数の公式

**Risk Priority Number(RPN)**はFMEAの中核的なスコアリングメカニズムです。シンプルな公式です。

RPN = 重大度(S)× 発生頻度(O)× 検出性(D)

各要因は1から10のスケールでスコアリングされ、RPNは1(無視できるリスク)から1000(最大リスク)の範囲となります。各次元の意味とスコアリング方法を示します。

重大度(S):この障害が発生した場合の影響はどの程度深刻か?

スコア 説明
1 製品またはプロセスへの影響なし
2から3 軽微な影響、顧客が気づかない可能性
4から6 中程度の影響、顧客が気づき不満を感じる
7から8 高い影響、製品が部分的に動作不能、顧客が非常に不満
9 非常に高い重大度、警告ありの安全または規制上の問題
10 警告なしの危険、潜在的な傷害または安全機能の失敗

発生頻度(O):この障害が発生する可能性の頻度は?

スコア 説明 おおよその発生率
1 極めてまれ 150万回に1件未満
2から3 低い確率 15万回に1件から1万5千回に1件
4から6 中程度の確率 2千回に1件から400回に1件
7から8 高い確率 80回に1件から20回に1件
9から10 非常に高い、ほぼ確実 8回に1件以上の頻度

検出性(D):現在の管理策が障害を顧客に届く前に検出できる可能性は?

スコア 説明
1 ほぼ確実な検出。管理策が常に検出する
2から3 検出の可能性が高い
4から6 検出の可能性が中程度
7から8 検出の可能性が低い。管理策が検出できない可能性
9から10 既知の管理策なし。障害がほぼ確実に顧客に届く

検出性は直感に反することに注意してください。スコア1は良い(検出がほぼ確実)であり、スコア10は悪い(管理策が存在しない)です。チームはこれを混同することが多いため、スコアリング前にチームと方向性を確認する価値があります。

FMEAの実施方法

適切に実施されたFMEAは一貫した手順に従います。特にチームレビューとアクションのトラッキングのステップを省略すると、FMEAは本物のリスク削減ツールではなく事務的な手続きになってしまいます。

ステップ1:適切なチームを編成する

FMEAは部門横断の演習として最もうまく機能します。PFMEAには工程エンジニア、オペレーター、品質スタッフ、プロセスに日常的に携わる人全員を参加させます。オペレーターは文書には現れない故障モードを知っていることが多いです。4から7人を目指してください。それ以上になると精度を向上させずにスコアリングが遅くなります。

ステップ2:スコープを定義する

FMEAがカバーするプロセスまたはシステムについて合意します。SIPOCダイアグラムはプロセスの境界をマッピングするのに役立ちます。明確なスコープがないと、チームは広すぎる(FMEAが管理不能になる)か、狭すぎる(重要な故障モードが境界外に落ちて見逃される)かどちらかになります。

ステップ3:すべての機能と故障モードをリストアップする

各プロセスステップまたはコンポーネントについて、「このステップはどのような方法で意図された機能を果たせないか?」と問います。一つのステップに複数の故障モードが存在しえます。適切な詳細レベルで書きます。「機械が故障する」は漠然としすぎます。「トルクレンチがボルト締め付け中に不十分なトルクを適用する」は実行可能です。

ステップ4:影響と原因を特定する

各故障モードについて2つのことを判断します。この障害が発生した場合に下流で何が起こるか(影響)と、そもそも障害を引き起こすものは何か(原因)です。フィッシュボーン図は設備、材料、方法、人員などのカテゴリー別に体系的に原因をブレーンストーミングする実用的なツールです。

ステップ5:重大度、発生頻度、検出性をスコアリングする

上記の1から10のスケールを使用します。個人ではなくチームとしてスコアリングします。スコアが大幅に異なる場合(一人が3、別の人が8と言う)、その不一致はプロセスについての異なる前提を明らかにします。それらの会話は価値があります。

ステップ6:RPNを計算し優先順位付けする

S × O × Dを掛けて各故障モードのRPNを求めます。RPN降順でソートします。多くのチームはRPNの閾値(一般的に100または125)を設定し、その上では是正処置が必要とされますが、RPNランキングだけですべてを語ることはできません。S=10でRPN=80の故障モードは閾値を下回っていても重大度のために注意が必要です。

ステップ7:是正処置を定義する

高優先度の故障モードに対して、特定の是正処置、担当オーナー、目標完了日を割り当てます。処置は発生頻度を減らす(根本原因を修正する)か検出性を改善する(管理策を追加する)ものであるべきです。重大度を下げるには設計変更が必要なことが多く、PFMEAでは難しいですがDFMEAでは可能です。

このステップを広範なDMAICまたはPDCAサイクルに結びつけてください。FMEAが問題を特定し、改善プロセスが修正を実施します。

ステップ8:処置後にRPNを再計算する

是正処置が実施されたら、発生頻度と検出性を再スコアリングします(設計変更なしでは重大度はめったに変わりません)。新しいRPNは達成されたリスク削減を文書化し、処置が機能したかどうかを確認します。このクロージングステップが、生きているFMEAと一度きりの文書を区別するものです。

FMEAの例

FMEAワークシートの例

以下は製薬施設の錠剤包装ラインにおけるPFMEAの実例です。

プロセスステップ/機能 故障モード 影響 S 潜在的原因 O 現在の管理策 D RPN 推奨処置
錠剤のブリスターへの充填 未充填(錠剤欠如) 患者が不完全な投与量を受け取る 9 ビジョンシステムの誤校正 3 2時間ごとのカメラ検査 5 135 検査頻度を30分ごとに増加。リアルタイムアラームを追加
ブリスターフィルムのシール 弱いシール 水分浸入、棚寿命の短縮 7 ヒータープラテン温度が規格以下 4 シフト開始時の手動温度確認 7 196 自動シャットオフ付きの連続温度モニタリングを設置
ロット番号の印刷 判読不能な印刷 トレーサビリティの障害、回収リスク 8 インクカートリッジの残量低下 5 オペレーターによる目視確認 6 240 閾値前にアラート付きインクレベルセンサーを追加
最終カートンへの梱包 カートン内に誤製品 取り違え、患者安全リスク 9 製品確認ステップなし 2 100ユニットごとのラベル監査 5 90 梱包ステーションにバーコードスキャン検証を追加
カートンのラベル貼り ラベルの貼り付け不良 不適合品の出荷 6 ラベルフィーダーのテンション不安定 3 シフト終了時の監査 7 126 ラベルフィーダーを週次で校正。オンライン検査カメラを追加

この例では「判読不能な印刷」のRPNが最も高く240です。是正処置はダウンストリームの検査を追加するのではなく根本原因(インク残量低下が未検出のまま)を対象としています。

FMEAと他のリスクツールの比較

FMEAは障害と原因を分析するためのいくつかのツールの一つです。チームがよく併用するものとの比較を示します。

ツール 主な問い 成果物 最適用途
FMEA 何が障害を起こし、どれほど深刻で、検出できるか? RPNの優先順位付きスコアリングワークシート プロセス変更前後の事前リスク優先順位付け
フィッシュボーン図 この問題の考えられる原因は何か? カテゴリー別に整理された視覚的な原因マップ 欠陥発生後の根本原因のブレーンストーミング
5 Whys この特定の問題の根本原因は何か? 根本原因への原因の連鎖 既知の問題に対する迅速な根本原因分析
HAZOP このプロセス変数が設計から逸脱した場合はどうなるか? 逸脱ベースのリスクテーブル 化学、プロセス、プラント安全分析

FMEAとフィッシュボーン図は自然な補完関係にあります。フィッシュボーンを使って故障モードのすべての潜在的な原因をブレーンストーミングし(上記のステップ4)、次にFMEAでそれらの原因をスコアリングして優先順位付けします。同じセッションで実施することも多いです。

Total Quality Managementプログラムは通常、FMEAを品質計画ツールキットの標準ツールとして組み込んでいます。特にプロセス設計レビュー中に使われます。

よくある間違いとベストプラクティス

避けるべき間違い:

  • 個人でスコアリングする。 個人で行うFMEAは楽観的なスコアを生成します。チームでのスコアリングはプロセスについての実際の知識のギャップを明らかにする不一致を浮かび上がらせます。
  • 再計算をスキップする。 処置を実施した後に再スコアリングしなければ、何かが改善されたという証拠がありません。事前事後のRPN比較が証拠です。
  • FMEAをチェックボックスとして使う。 誰も読まない完成したFMEAバインダーは無価値です。文書はそれが推進するアクションとしてのみ価値があります。
  • すべての高RPNを同じように扱う。 S=10、O=2、D=10のRPN=200はS=5、O=8、D=5とは異なるリスクプロファイルです。合計だけでなく個々のスコアを見てください。
  • 高重大度の低RPN項目を無視する。 現在まれなS=10の障害(O=1)は、量、材料、オペレーターが変わった場合に一般的になる可能性があります。RPNが低くても高重大度の項目はモニタリングのためにフラグを立ててください。

ベストプラクティス:

  • FMEAセッションの前にバリューストリームマップまたはプロセスマップから始めてください。チームはプロセスを視覚的に確認できると精度が上がります。
  • 初期起動時だけでなく、プロセスが変わるたびにFMEAを見直してください。
  • 時点スナップショットではなく生きている文書として維持してください。管理策が追加されるにつれて発生頻度と検出性のスコアを更新します。
  • 各是正処置を標準作業手順書にリンクし、修正が通常のオペレーションの一部になるようにします。
  • Lean方式のプロセスレビューとFMEAを組み合わせて、一度でムダとリスクの両方を捉えます。

よくある質問

FMEAは何の略ですか? FMEAはfailure mode and effects analysis(故障モードと影響分析)の略です。この名称はツールが何をするかを正確に説明しています。故障モード(プロセスまたは製品が障害を起こしうる方法)を特定し、その影響(障害が発生した場合に何が起こるか)を分析し、スコアリングすることでチームが最も重要なリスクを優先できるようにします。

FMEAのRPNとは何ですか? RPNはRisk Priority Number(リスク優先数)の略です。それぞれ1から10のスケールで3つのスコアを掛け合わせることで計算されます。重大度(障害の影響がどれほど深刻か)、発生頻度(障害が起こる可能性の頻度)、検出性(現在の管理策がそれを検出できない可能性)です。公式はRPN = S × O × Dです。結果は1から1000の範囲です。高いRPNは是正処置を要する高優先度の故障モードを示します。

DFMEAとPFMEAの違いは何ですか? Design FMEA(DFMEA)は設計が確定する前に製品設計の潜在的な障害を分析します。製品開発とエンジニアリングチームが使用します。Process FMEA(PFMEA)は製品を製造または提供する製造またはサービスプロセスの潜在的な障害を分析します。PFMEAはオペレーションと品質チームが使用し、日常のプロセス改善業務でより一般的な種類です。

FMEAはいつ使うべきですか? FMEAは問題が発生した後ではなく前に最も価値があります。新しいプロセスや製品を立ち上げるとき、重要なプロセス変更を行う前、Six Sigma DMAICプロジェクトのImproveフェーズ中、または規制上の品質計画レビュー中(医療機器、自動車、航空宇宙で一般的)に使用します。これは事前対応型のツールであり、事後対応型ではありません。問題が発生した後は、フィッシュボーン図または5 Whys分析がより速くより的を絞っています。

どのRPN閾値が是正処置を引き起こすべきですか? 普遍的なルールはありませんが、一般的な出発点はRPNが100から125を超えることです。しかしRPNだけが唯一のトリガーであるべきではありません。重大度が9または10の故障モードはRPNに関わらず注意が必要です。その障害の結果が深刻すぎて対応しないままにできないからです。多くのチームは組み合わせを使います。RPN 100以上の必須対応に加え、Sが9以上の場合の必須レビューです。

FMEAは、すべてのオペレーションチームがすでに問いかけていること(「何が問題になりうるか?」)を受け取り、オーナーと期限を持つスコアリングされた優先順位付きリストに変えることで機能します。厳密さが違いを生みます。FMEAを生きている文書として扱い、是正処置をクローズするチームは、ワークシートを完成させてファイルするチームを一貫して上回ります。

About the author

Tara Minh

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.