2.6.6項 FMEA

更新　Z　
小中高生に、エンジニアの魅力を伝えたい｢エンジニアの教科書｣ 2.6.6項。

開発はスピード重視で、8割(80%)完成でOK という話をしました。
しかし、世の中に(ユーザに)製品やサービスを届ける 段階では、それだけでは足りません。
ほぼ 100%完璧に近い完成度 でなければ、クレームにつながるなど、困る人が増えてしまいます。
では、どうやったらいいの？・・です。
今回は、そんな完成度の高いモノづくり、について説明します。

1. 改善とFMEA

「うまく動いている」「正常に動く」状態を保つためには、
設計の段階で、緻密で繊細な検討が必要になります。
考慮漏れや小さなミスがあると、品質は少しずつ下がってしまいます。

ある程度、完成度が高まった製品を、さらに良くするために使われるツールの一つが、FMEA（エフエム・イーエー）です。
不具合を減らすための活動ですが、出発点は ｢失敗｣ ではありません。

FMEAとは、フェイラーモード・エフェクト・アナリシス
（Failure Mode and Effects Analysis）の略です。
日本語では「不具合の影響分析」と呼ばれることがあります。

進め方を、FTA(2.5.4項)と同じように考えてしまう人もいますが、FMEAは少し視点が異なります。

 - FTAが「起きてほしくない不具合」を起点に考えるのに対し、
 - FMEAでは、まず「正常な機能」を明確にします。

一番左端のスタート (DRBFMの例を参照) は、必ず部品に対応する
 ｢正常な機能｣｢本来、この製品は、どう動くものなのか？｣
をはっきりさせる、言葉にする ことから始まります。

2. FMEAの基本的な流れ

FMEAの流れの例です。

例：ホッチキス

① 「正常な機能」を列記する
　例：針が、真っすぐに紙を突き破る。

② ①と対になる「異常」を記載する
 例：針が、真っすぐに紙を突き破らない。
 　ここでは、難しいことを書かないのがコツです。
 　最初は、単純に「反対の状態」を書きます。

会議中に「こういう心配もあるよね」という意見が出た場合は、
レビュー欄を使って いったんメモしておきます。
その指摘は｢ 正常な機能が抜けているよ｣ という合図です。
レビュー後に、何の機能が足りていなかったのかを考え、
内容を整理したうえで、①の「正常な機能」に追加します。

③ なぜ②が発生するのか、を考える
　例：紙が固い、針が弱い、ガイドが不足している
　※ DRBFMでは、これらを「原因」「要因」と呼ぶこともあります。

社内の事例が増えてきた時点で、AIに食わせて、自動で作成させると良いと思います。

3. 派生形のFMEA

FMEAは、とても有効なツールです。
一方で、丁寧にやろうとすると、かなり時間が掛かります。
「時間が掛かりすぎる」「全部は無理だ」と敬遠されることもありるため、目的を絞った派生形が生まれました。

・DRBFM

DRBFMは、Design Review Based on FMEA の略です。
「変わったところ」だけに注目するFMEAです。

前のモデル・既存のサービスなど、比較する対象から｢どこが変わったのか｣を、まず共有します。これを 変化点リスト と言います。
変化点について「ここが変わると、どこに影響が出る？」というレビューを行い、抜け・漏れがないことの確認を行います。

・システムFMEA／ブロックFMEA

1点1点の部品ではなく、仕様書や設計ブロック単位 で考えるFMEAです。
事前に システム構成図 が作られていることが前提になります。

例： 3枚の基板で構成された装置の場合、
・基板1が壊れたら、何が起きるか？
・基板1の機能は何か？
・ユーザーに重大な影響はないか？
・どんなアラームで気付けるのか？

｢重大な設計ミスは無い｣ と 思える ところが、
どのツールを使った場合でも、ゴール になります。

4. やる気Upポイント

✅ 自分を守りながら、進めよう♪
 いろんな立場の人が参加するレビュー(打合せ・会議)になるので、
 本当にいろいろ、ざっくばらんに、時に厳しい言葉が飛んできます。
 余り真に受けすぎると、精神衛生上よろしくありません(笑)
 丁寧に聞くことも大切ですが、時には逃げましょう～。

✅ AIをうまく使おう
 最終的に、抜け・漏れが無ければ OK なのです。
 私の個人的な進め方ですが、
 何が書いてあっても、正解！ くらいに考えて、FMEAを書いています。
 逆に言うと、何を書いても、文句を言う人は  言います。
 大規模データが集まってきたら、AIに処理してもらい、80%完成くらいでレビューしましょう。

✅ フォーマットを信用しよう
 このフォーマットのすごい点は、フォーマットの完成度が70点くらいでも、
 製品の完成度はUpする、という点です。(あくまで、個人の感想)。
 フォーマットの完璧主義 になりそうな時は、
 製品の完璧度(品質)に視点 を置きましょう。

5. 参考図書/Webサイト

① トヨタ式未然防止手法GD3

著者の 吉田達彦 さんは、とても思慮深く、素晴らしい先生です。

99_履歴

( 読者様にお願い：　誤記・間違い・改善点など、指摘ください。)
改定日　　　記号　変更点
2026/01/16　Z　　初版

9A_全体像

この文章を読んでくださった皆さまへ。
私はセミナー・講演の ご依頼を承って おります。
次世代を担う若手エンジニアの育成に役立つ、現場で本当に使える知見をお届けできます。
ご要望・講演テーマ・日時など、お気軽にご相談 ください。
ご連絡は、この noteメール にご返信いただければ幸いです。

.