DRBFMとは？不具合の未然防止を仕組み化する｜FMEAとの使い分けと実務のポイント

製品開発において、実績のあるベース設計が存在するにも関わらず、すべての機能をゼロから検証し直すのは非効率であり、焦点がぼやけてしまいます。
かといって「少しの変更だから大丈夫だろう」という勘に頼るのは危険です。

今回ご紹介するDRBFM（Design Review Based on Failure Mode）は、技術者の「ここを変えたから、あそこに影響が出るかもしれない」という心配点や気づきに的を絞り、限られたリソースでも的確に不具合を未然防止できる手法です。

DRBFMとは（基本概念）

DRBFMとは、トヨタ自動車が提唱した未然防止の手法であり、「GD³（ジーディーキューブ）」という考え方からきています。GD³とは、

• Good Design（良い設計）：過去の知見を盛り込んだロバストな設計
• Good Discussion（良い議論）：設計者の心配点や気づきを関係者全員で検討
• Good Dissection（良い評価/観察/解剖）：試験後の現物を評価・観察し、不具合の予兆を解剖

の3つを指します。

この中でもDRBFMが重視するのは、Good Discussion（良い議論）です。

多くの不具合は、意図して変えた箇所（変更点）や、環境などの条件が変わった箇所（変化点）から発生します。DRBFMでは、これらの変化に起因する故障モードを設計者が事前に洗い出し、専門家や関係者が集まって議論します。

従来のFMEAが、決められた項目をすべて埋めることに追われがちなのに対し、DRBFMはあえて変更点や変化点に絞ることで、設計者が直感的に抱く心配点を引き出します。
形式的な審査ではなく、設計者の思考を刺激して不具合の予兆を見逃さないための活動と言えます。

FMEAとDRBFMの関係

「FMEAがあるのに、なぜDRBFMも必要なのか？」

このように疑問に思った方もいらっしゃるかと思いますが、FMEAとDRBFMは別々に存在する手法ではなく、互いに関連を持たせて運用するものです。

FMEAは製品全体の故障モードを網羅的に洗い出すために有効ですが、項目数が非常に多くなるため、すべての箇所で詳細な議論を尽くすのは現実的ではありません。

そこで、網羅的なFMEAをベースにしながら、今回の変更点や変化点に伴うリスクを集中的に深掘りするためにDRBFMを用います。

「トヨタ式 未然防止手法 GD³ 吉村達彦[著]」によると、DRBFMを創造的FMEAとも呼んでいます。
FMEAで整理された情報の中から、特に設計者が不安を感じる箇所（心配点）に議論を集中させることで、効率的かつ確実な未然防止を図ります。

全体像を定義するFMEAと、個別の変化に対応するDRBFMを組み合わせて活用することで、漏れのない検証と深い議論を両立させることができます。

関連コラム：FMEA（故障モード影響解析）とは？

FMEAとDRBFMの違い

「FMEAとDRBFMのどちらを実施すべきか？」

結論から言えば、これらは対立するものではなく、全体を網羅するFMEAと変更点や変化点に的を絞るDRBFMは補完関係にあります。
ここでは、両手法の違いを明らかにし、実践的な使い分けについて解説します。

両手法の違い

FMEAとDRBFMの主な違いは、解析の範囲と着眼点にあります。

FMEAは、製品全体の構造や機能、故障を網羅的に解析する手法です。すべての可能性をボトムアップで洗い出すことで、抜け漏れのない設計品質の確保を目指します。製品全体の設計の基準を整理する役割も担います。

一方、DRBFMは変更点・変化点に特化した手法です。実績のある設計の基準に対し、今回新しく変えた箇所や、使用環境が変化した箇所が、既存の部品や機能にどのような影響を及ぼすかを深掘りします。

実施の目的についても違いがあります。
FMEAは設計の基準を明確にし、手順通り進める品質マネジメントの管理とナレッジの蓄積としての側面が大きいのに対し、DRBFMは、設計者が図面を描く過程で感じた心配点をもとに関係者で知恵を出し合うアプローチとなります。

同著によると、共通の要件を守るためのものをチェックリスト、その設計に固有の要件を見つけ出すものをDRBFMと定義しています。
網羅的なFMEAで全体をカバーしつつ、リスクの高い変更点や変化点についてはDRBFMで重点的に議論するという使い分けが有効です。

目的・タイミング・役割の違い

FMEAとDRBFMは、実施するタイミングや役割が異なります。

FMEAは主に開発の初期段階で実施します。製品全体の構造や機能を定義し、網羅的なリスクの基準を整理することが目的です。

対してDRBFMは、設計の構想段階から試作図面を作成するまでの間に実施するのが最も効果的です。
図面が確定する前に専門家や関係者の知見を集めて設計の質を上げることで、後工程での手戻りを防ぎます。

ここで強調したいのは、試験や市場で不具合が見つかってから修正するのではなく、設計段階で不具合を出す前に頭の中で故障させてみることに、このタイミングで議論する価値があるという点です。

もし設計者自身が、変更した箇所にどのような負荷がかかり、故障にいたるのかというメカニズムを具体的に検討したい場合には、「e1ns（アインス）」のようなシステムがあれば、FMEA作成時にモデル化された構造や機能、故障の関係性から、その筋道を一目で把握できるようになります。

さらに、図面を見て議論するだけでなく、試験を終えた現物を観察して摩耗や変色などの予兆から新たな懸念を見つける DRBTR（Design Review Based on Test Results） までをサイクルとして回すことが、未然防止の精度を高めます。

手法の面では、FMEAが故障モードを系統的に抽出するのに対し、DRBFMは抽出された心配点に対して、設計、製造、品質保証などの専門家や関係者が意見を出し合う議論のプロセスを重視します。

この議論の場は、設計者を審査し、不備を指摘する場ではなく、専門家や関係者がそれぞれの技術で設計者を助け、ともに解決策を見つけ出すためのプロセスとなります。

例えば、従来品の金属部品を樹脂に変更する場合、FMEAで製品全体の機能を再確認しつつ、DRBFMを用いて樹脂化という変更点に伴うリスクを集中的に洗い出し、対策案を検討するといった使い分けが有効になるでしょう。

FMEAとDRBFMの使い分け

実務における使い分けのポイントは、過去の知見に基づいた既知の事象の網羅（FMEA）と、今回の設計固有の心配点の検討（DRBFM）を切り分けることにあります。

まずはFMEAを用い、様々な製品に共通する設計標準や、過去のトラブル事例から得られた知見を整理します。これは、設計の基本となる事項において失敗を繰り返さないための網羅的な確認作業です。

その上で、新しく採用した技術や、従来とは異なる使用環境（温度、振動、負荷など）に起因する固有のリスクについては、DRBFMを用いて議論を集中させます。設計者が図面を検討する過程で抱く心配点に的を絞り、関係者の知見を集めることで、未知の不具合を未然に防ぎます。

網羅的な確認はFMEAで行い、変更点や変化点に対する詳細な技術検討はDRBFMで行うといった役割を使い分けることで、限られた時間の中でも精度の高い未然防止が可能になるでしょう。

【現地レポート】FMEAを再利用可能な知的資産へ｜Eissmann社の挑戦

「巨大なFMEAファイルは、やがて誰もメンテナンスできない文書になる」

この問題は多くの設計現場で起きています。
自動車内装メーカーのEissmann社も、かつてはExcelでの運用に限界を感じていました。

過去の巨大なファイルをコピーして再利用する方法では、最新の知見が反映されず、版管理が煩雑になっていたのです。
同社はこの問題に対し、20年以上の歳月をかけて、精度とスピードを両立させるための構造改革に取り組んできました。

巨大なデータ構造の見直しとモジュール化

まず着手したのは、全工程を一箇所の要素に詰め込む巨大なデータ構造を見直すことでした。

工程を小さな単位（モジュール）に分割し、再利用性を高める仕組みを構築しました。
このモジュール化により、ソフトウェアへの負荷を最小限に抑えつつ、必要な要素を組み合わせてベースとなるFMEAを短時間で作成することが可能になりました。

独自のFMEA文法による効率化の追求

さらに同社は、独自のFMEA文法（述語・オブジェクト分離）を定義し、Excelマクロなどを活用して多言語展開を数分で完了させるといった効率化を推進しました。

こうした進化の積み重ねを経て、現在はこれら構造化された知見を品質マネジメントシステム「e1ns（アインス）」へと統合し、さらなる高度化を図っています。

デジタル資産としての運用と成熟度監視（Maturity Monitoring）

網羅的な確認はシステム上のモジュール（知的資産）に任せ、設計者は「今回の変更が既存の部位にどう影響するか」という、本来時間を割くべき技術的な検討に注力できる環境を作っています。

FMEAを表や書類として放置するのではなく、常にデータが更新されるデジタル資産として運用し、客観的な基準でその進捗や品質を監視（成熟度監視）することが、形骸化を防ぐためのベースとなります。

こうしたEissmann社のような運用は、日々の開発におけるDRBFMの精度向上にも直結します。

ベース部分の信頼性がシステムによって担保されることで、技術者は「この変更が製品全体にどのような影響を及ぼすか」という技術的な気づきの洗い出しと良い議論（Good Discussion）を行い、創造的な作業に専念できます。

この明確な使い分けが、品質保証の網羅性と開発スピードの両立を支えることになります。

FMEAとDRBFMの比較表

比較項目	FMEA (AIAG-VDA統合版など)	DRBFM (トヨタ式)
対象範囲	製品・工程のすべての構造と機能	意図的な変更点・環境などの変化点
主な役割	設計基準の整理と網羅的な管理	未知の問題を見つけ出す創造的議論
着眼点	共通の要件や基準の遵守	その設計に固有の心配点
実施のタイミング	新規開発時、基準の構築・見直し時	構想段階から試作図面作成まで
評価の指標	リスク評価指標（AP、RPNなど）	関係者による議論の深さと納得感
留意点	工数が膨大になりがち	変更点・変化点以外のリスクを見落とす可能性あり ベースとなる網羅的なFMEAの存在が必要

DRBFMの進め方とワークシート

DRBFMは、気を付けるべき点を箇条書きにする作業ではありません。ここでは、専門家や関係者が集まって議論するための具体的な進め方の例を示します。

同著にある吉村氏の本来のメソッドは、より多岐にわたる緻密な手順を含みますが、実務の全体像を捉えやすくするため、要点を絞ってご紹介します。詳細な運用については、ぜひ同氏の著書を読んでみてください。

DRBFMの実施のステップ

DRBFMは、事前の準備と、複数人による議論の2段階に分かれます。

1. 事前段階（設計者による起票）
   設計者はまず、今回の設計で変えたところ（変更点）と、使用環境などの条件が変わってしまうところ（変化点）を明確にします。
   次に、これらによって懸念される心配点（故障モード）を洗い出し、それを防ぐために設計上でどのような工夫をしたかをワークシートにまとめます。
   
2. 議論の段階（デザインレビュー）
   設計者が用意したシートをもとに、生産技術、品質保証、テスト担当などの専門家や関係者が集まります。
   設計の対策で十分か、別の懸念はないかといった観点で議論を行い、新たな気づきをシートに追記していきます。

ワークシート記入について：単語ではなく文章で書く

議論の質を左右するのが、ワークシートの記述内容です。

故障モードの欄を「…不良」「破損」「摩耗」といった単語だけで済ませてはいけません。「どのような時に、どの部位が、どうなるのか」を具体的な文章で記述することが必要です。

例えば、「摩耗」という単語だけでは、摩耗した結果「隙間が空く」のが問題なのか、「粉末が飛散する」のが問題なのか、議論の焦点が定まりません。

文章化することで、不具合の現象が関係者の頭の中に具体的に浮かび、真の原因（メカニズム）に迫る議論ができるようになります。単語だけの記述では、人によって解釈が異なり、的外れな対策に繋がる恐れがあるため、十分にご留意ください。

DRBFMワークシートの基本項目

議論を深めるためには、論理の流れを可視化するフォーマットが必要となります。

各社によって求められる内容は異なりますが、標準的なワークシートには、主に以下の項目が含まれます。順を追って整理することで、論理の飛躍を防ぎます。

• 変更点・変化点：どこを、なぜ変えたのか。議論の出発点となります。
• 部品の機能：その部品が本来果たすべき役割を明確にします。
• 故障モード（心配点）：変更や変化によって、機能がどう損なわれるか。
• お客様への影響：故障が起きた際、ユーザーにどのような不利益があるか。
• 原因（要因）：不具合が起きる物理的なメカニズムを特定します。
• 設計による対策：懸念に対して、図面や基準にどのように反映したか。
• DRでの指摘事項：専門家や関係者の視点から見て、不足している点や新たな懸念を追記します。
• 最終的な評価：指摘を受けて実施したテストの結果など、安全性の確認内容を記述します。

このように各項目を埋めていく過程で、設計者は自分の考えを客観的に見直すことができます。

また、関係者はこのシートを共通言語として活用することで、表面的な確認ではなく、技術的な根拠に基づいた深い議論を進めることが可能になります。

DRBFMの記入例

具体的な書き方のイメージを持つために、既存のモーター製品において、ギアの材質を金属から樹脂へ変更した場合の記入例を以下に示します。

単語ではなく「どのような状況で、何が起きるのか」を文章で記述することがポイントです。

変更点・変化点	故障モード （心配点）	お客様への影響	原因（発生メカニズム）	設計による 対策	DRでの 指摘事項	最終評価
軽量化・コスト低減のため、ギアの材質を金属から樹脂（PA66）へ変更する。	低温環境下（-20℃）での起動時に、ギアの歯が根元から破損し、回転が伝わらなくなる。	モーターが空回りし、製品が全く動作しなくなる。	樹脂は低温で脆化する特性があり、起動時の最大トルクによる応力集中に耐えられないため。	歯の根元のR（丸み）を従来より大きく設計し、応力集中を緩和させた。	常温での強度計算だけでなく、-20℃環境下での脆化リスクを実機で検証したか？	-20℃での起動耐久テストを1000サイクル追加実施。破損がないことを確認済み。

なぜDRBFMは形骸化するのか？

DRBFMは本来、設計者の気づきを深めるための創造的な場ですが、実務では「資料作成が目的になってしまっている」という声が少なくありません。
この形骸化を招く主な要因は、運用ツールであるExcelの限界と情報の更新漏れにあります。

Excel管理による転記と事務作業の負担

最も大きな問題は、情報の再利用に伴う事務作業の負担です。

新しいワークシートを作る際、過去のファイルから類似の箇所を探し出し、手作業でコピー＆ペーストを繰り返すことになります。
派生開発のたびにファイルが複製されるため、最新の知見がどれなのか判別しにくくなり、情報の整合性を保つだけで多大な時間が費やされます。

さらに、DRBFMのシートに記入した変更点や変化点、そしてその対策については、後から別の管理表へ手作業で転記する手間も発生する場合があります。

このように、本来、議論に使うべき貴重な時間が事務作業や体裁の調整に消費されている状態では、技術者のモチベーションが下がり、形骸化に向かうのは自然な流れです。

情報の二重管理による更新漏れ

DRBFMとFMEAを個別のExcelファイルで管理していると、情報の更新が漏れる原因となります。

例えば、DRBFMでの議論を通じて見つかった新しい心配点や有効な対策は、ベースとなるFMEAにも反映されるべきです。
しかし、ファイルが分かれていると転記の手間が発生するため、大元のFMEAが古いまま放置される可能性が常にあり、設計の現場と管理している書類の間に齟齬が生まれます。

結果として設計や工程、品質管理等でデータに齟齬が生まれ、監査の直前になって辻褄合わせの書類作成に追われることになります。

ナレッジの埋没と属人化の進行

ファイルサーバーに蓄積された無数のExcelデータから、今回の変更に役立つ過去の不具合事例（過去トラ）を特定するのは容易ではありません。

検索が十分に機能しない環境では、結局はベテラン技術者の記憶に頼ることになります。担当者の異動や退職によって、組織としての知見が失われ、同じ設計ミスを繰り返してしまう状況が生じやすくなります。

過去のDRBFMで一度指摘されていたにも関わらず、情報が引き継がれていなかったがために、別の担当者がまた同じところで行き詰まったり、設計ミスを繰り返したりしてしまいます。このような状況は、過去のナレッジが属人化した環境で起きる弊害です。

品質マネジメントを知的資産として活用するために

手法を形骸化させず、持続的な品質向上につなげるためには、以下の3つのアプローチがあります。

変更点・変化点と影響範囲の見える化

設計の変更点や環境の変化点が、製品全体のどこに、どのような影響を及ぼすかを客観的に特定する仕組みを整えます。

影響範囲が明確になることで、関係者は「その変更であれば、この部位にも負荷がかかるのではないか」と的確な指摘を行えるようになります。

理想的には、変更点や変化点をオープンに共有する仕組みを作っておくことで、効果的な未然防止が可能になります。

FMEAとDRBFMを同一データベースで一元管理

手法ごとに独立したExcelファイルで運用していると、ナレッジの共有が難しくなります。

DRBFMの議論で新たに見つかった故障モードや有効な対策がベースとなるFMEAに反映されず、せっかくの知見がその場限りで終わってしまうのです。

この問題を解決するのが、両者を同一のデータベース上で一元管理するアプローチです。

例えば、FMEAの共通モデル（構造ツリー）を直接参照しながらDRBFMを実施することで、どの部品のどの機能に対する変更かというリンクを維持したまま管理できます。
Excelのように別々のファイルでデータが迷子になることがなく、DRBFMで得られた知見をベースラインのFMEAへ反映させる際の判断や作業がスムーズになります。

議論のプロセスを資産化し、若手育成やAIに活用

ナレッジの蓄積は、品質マネジメントの枠を超え、組織力の向上に直結します。

なぜなら、ベテラン技術者が「なぜその設計変更を懸念したのか」「どのような論理で対策を打ったのか」というDRBFMでの議論のプロセスも活用することで、価値の高い教材になるからです。

過去のトラブル事例や、それに対するベテランの思考プロセスがデータベースから瞬時に検索できれば、経験の浅い若手エンジニアでも過去の知見を擬似体験し、設計の勘所を効率的に学ぶことができます。属人化しがちな技術の伝承をシステムが仕組みとしてサポートされることで、組織全体のエンジニアリング能力が底上げされます。

さらに、システム上で構造化されたデータとしてナレッジが蓄積されることは、将来のAI活用にも役立ちます。

過去の設計意図やトラブルの文脈を学習したAIに対し、若手エンジニアが直接AIに質問してヒントや類似事例を引き出せるようになれば、必要な知見へのアクセスはより直感的になり、技術伝承のスピードはさらに上がるでしょう。

ただし、現時点でのAIは過去の品質情報の検索や解説には便利でも、中身はブラックボックスのため、本来実施すべき故障のメカニズムや連鎖を論理的に検証することができないことに留意が必要です。

品質マネジメントのDXを実現する「e1ns」

ここまで解説してきた変更点・変化点の見える化や品質ナレッジのデータベース化を個人の努力やExcelだけで継続することは、情報の増大とともに困難になります。

これらを実現し、知的資産として活用し続けるためには、エンジニアリング情報を統合的に扱う仕組みが求められます。

その手段の一つが、品質マネジメントシステム「e1ns（アインス）」です。

共通のシステムモデルによる情報の紐付け

e1nsの特徴の一つは、製品の構造を共通のシステムモデルとして構築する点にあります。

ExcelのようにDRBFMとFMEAを個別のファイルとして切り離すのではなく、同じ製品構造をベースにして両方の解析を行うことができるようになります。

これにより、DRBFMを実施する際の「どの部品の、どの機能に対する変更か」について、ベースとなるFMEAの情報と常に紐付いた状態で管理できます。

空いた時間を創造的な検討へ

e1nsを活用することで、FMEAの過去の解析をモジュールとして再利用し、過去の知見を持ったFMEAを短時間で準備できます。

DRBFMの検討においても、この情報を参照しながら進めることができるため、手作業による転記ミスやデータの放置を防げます。

DRBFMでの議論の結果をFMEAへ反映させる際も、同じモデル上で情報を管理しているため、どの項目を更新すべきかの判断が容易になります。
これにより、データの整合性の確認に費やされていた時間は、本来の目的である心配点の洗い出しや関係者との深い議論に充てられるようになります。

技術者が創造的な検討に専念できる環境をどう構築するのか、具体的な機能やメリットについては以下のページをご覧ください。

グローバルレベルの品質マネジメントシステム「e1ns（アインス）」の詳細を見る

まとめ

DRBFMは、不具合を未然防止するための実務的な手法です。

しかし、その価値はワークシートの表や書類を完成させることではなく、設計者が抱く心配点を起点とした良い議論（Good Discussion）の深さにあります。

未然防止を実現するためには、以下の2点が重要となります。

• 役割の分担：網羅的な確認はベースとなるFMEAで行い、変更点や変化点に伴う固有のリスクはDRBFMで深掘りする。
  
• 情報の管理：FMEAとDRBFMを個別のファイルでバラバラに管理せず、同一のシステムモデル（製品構造）に紐付けて管理することで、ナレッジの埋没を防ぐ。

事務作業に追われる環境から、技術者が本来の役割である創造的な検討に専念できる環境を整えることが必要です。

e1nsのようなシステムを上手く活用することで、帳票の作成を目的とせず、過去の知見を整理し、変更や変化の影響範囲を特定するための仕組みとして、FMEAやDRBFMを活用することが形骸化を防ぐための現実的なアプローチとなります。

よくある質問

ここでは、技術者からよく寄せられる疑問にお答えします。

Q. DRBFMとFMEAはどちらを使うべきですか？

A. どちらか一方を選ぶものではなく、目的に応じて使い分けましょう。

まったく新しい製品をゼロから開発する場合や、製品全体の網羅的なリスク評価を行いたい場合はFMEAを使用します。

一方、変更、あるいは変化によって発生する影響を設計者が論理的に把握できているかを議論するのがDRBFMです。実績のあるベース設計を一部改良・コストダウンするような派生開発の場合には、DRBFMによって変更点と変化点に絞って検証を行うことができます。

網羅的なFMEAをベースに持つことで、DRBFMでの変更点や変化点に対する議論の精度がより高まります。

Q. DRBFMはどのタイミングで実施しますか？

A. 設計変更の構想が固まり、詳細な図面が確定する前（出図前）のタイミングで実施するのが最も効果的です。

この図面が確定する前のことを、専門用語で構想設計段階やDR1（デザインレビュー1）と呼んでいます。

DRBFMは、どこをどう変えるか（変更点）、環境がどう変わるか（変化点）が見えた段階で、関係者を集めて議論（デザインレビュー）を行います。
図面が完成した後に実施すると、対策を盛り込むための手戻りコストが膨大になってしまうため、早期の実施が望ましいです。

不具合が見つかってから修正するのではなく、不具合を出す前に頭の中で故障させてみるのが、このタイミングでの議論の価値です。

また、試験が終わった後に、現物を観察して結果を検証するDRBTR（試験終了品レビュー）までを一連のサイクルとして回すことで、未然防止をさらに高めることができます。

Q. DRBFMは必須ですか？

A. 法律や国際規格（IATF 16949など）で「DRBFMという特定の手法を使わなければならない」と名指しで義務付けられているわけではありません。

しかし、設計変更や派生開発におけるリスク分析は規格上も必須であり、特に日本の自動車メーカーの多くが、その手段としてDRBFMを推奨しています。
「少しの変更だから大丈夫」という経験や勘に頼った設計変更は予期せぬ不具合を招くため、事実上の標準プロセスとして定着しています。

DRBFMを通じて行われた深い議論や、そこで抽出された「なぜこの設計にしたのか、何を懸念したのか」という記録は、個人の経験に留まらない組織の知的資産となります。

DRBFMを標準プロセスとして定着させ、システム化してその知見を積み上げていくことは、ベテランのノウハウを次世代へ引き継ぎ、組織全体の設計力や品質マネジメント力を底上げするための重要な投資と言えるでしょう。

参考文献

「トヨタ式 未然防止手法 GD³ いかに問題を未然に防ぐか」
吉村達彦[著]
日科技連

FMEAを組織の品質ナレッジへ

構造計画研究所は、設計・製造の情報連携を基盤とした品質のデジタルアセット形成、FMEAや統計的品質管理などをトータルに、最適なソフトウェア・ツールとともにご支援。

IATF 16949 をはじめとした様々な国際規格で要求されるグローバル基準の不具合未然防止と継続的改善を目指すお客様をサポートしております。

グローバルレベルの品質マネジメントシステム「e1ns（アインス）」の詳細を見る

著者紹介

[S.Y]

株式会社構造計画研究所 品質安全デザイン室
　著書：『IATF 16949のための統計的品質管理』（日科学技連出版社）他。
　IATF 16949認証取得のための運用支援や、FMEA、統計的品質管理のコンサルティング・教育に従事。
　現場のデータ活用とQMS（品質マネジメントシステム）のDX化を専門とする。