DRBFMとは？ FMEAとの違いや進め方を解説

設計変更や部品の新規採用がきっかけで起きる不具合は、製造業で後を絶ちません。多くの開発は既存の設計をベースに「一部を変える」形で進み、市場に流出したのち発見される不具合の多くは、その「変えたところ」とその変更が周囲に及ぼした影響から生まれます。

「変えたところ」に潜むリスクを、設計の早い段階で関係者が集まって議論し、図面が固まる前に手を打つ、という考え方を体系化した手法がDRBFMです。
この記事では、DRBFMの基本と、似たような考え方であるFMEAとの違い、実際の進め方、そして「シートを埋めるだけ」に陥らないための運用のポイントまでを整理します。

FMEAについては、過去記事で紹介しておりますのでこちらも併せてご確認ください。

FMEA（故障モード影響解析）とは？ 製造業の品質を守る未然防止について

DRBFMとは

DRBFMは「Design Review Based on Failure Mode」の略で、故障モードに基づくデザインレビューを意味します。
設計の「変更点・相違点」に着目し、そこに潜む心配点（故障モード）を洗い出して、関係者によるデザインレビュー（DR）で議論し、対策につなげる手法です。トヨタ自動車で体系化され、自動車業界を中心に広まった手法として知られており、現在では自動車以外の機械・電機・部品メーカーでも活用されています。

DRBFMの出発点にあるのは、「変化のないところには、新しい不具合は生まれにくい」という考え方です。従来から量産している設計・工程は、すでに市場や工程で検証を重ねており、それでも洗い出せなかった潜在的な問題の多くはすでに表面化して対策済みになっています。
逆に、変えた部分とその変更が波及する部分にこそ、まだ誰も経験していないリスクが集中します。
だからこそ、限られたレビュー時間を「変えたところ」に集中投下する、というのがDRBFMの発想です。

ここで実務上のポイントになるのが、「変更点」と「相違点」を分けて考えることです。変更点は、自社が意図して変えたところ（形状、材質、寸法、公差、制御ロジックなど）を指します。一方の相違点は、自社の意図とは関係なく変わってしまったところ、たとえばサプライヤの変更、生産拠点の移管、使用環境や搭載条件の違い、法規や規格の改定などが該当します。不具合の原因をたどると、意図した変更よりも、この「気づかないうちに変わっていた条件」に起因するケースが少なくありません。DRBFMでは、この両方を意識的に洗い出します。

実施のきっかけとして典型的なのは、既存機種をベースにした派生開発、部品の形状・材質・仕様の変更、製造工程や設備の変更、材料や購入品のサプライヤ切り替え、生産拠点の移管、そして搭載条件や使用環境が変わるケースです。いずれも「製品としては従来品と同じはずなのに、条件が変わっている」場面であり、変更そのものは小さくても、影響が思わぬところに現れることがあります。逆にいえば、変更点が明確に特定できる場面ほど、DRBFMは効果を発揮しやすい手法だといえます。

また、DRBFMは「良い設計(Good Design)・良い議論(Good Discussion)・良い分解、検証（Good Dissection）」を重視するGD3という考え方を土台にしています。
良い設計をベースに、変更点を起点として議論の的を絞り、関係者の多様な視点で解析することで見落としを防ぐ。
この三つがそろって初めて機能する、という前提に立っている点が特徴です。

FMEAとの違い

DRBFMはFMEAをベースに発展した手法ですが、目的も進め方も異なります。
主な違いを整理すると、次のようになります。

つまり、製品全体を網羅的に見るのがFMEA、変えたところを深く掘り下げて議論するのがDRBFM、と整理できます。

重要なのは、どちらか一方だけを導入する関係ではないという点です。実務では、製品や工程の全体像をFMEAで押さえておき、設計変更や流用開発が発生したタイミングでDRBFMを実施する、という組み合わせが現実的です。既存のFMEAが整備されていれば、「その故障モードは以前どう評価したか」を参照しながらDRBFMの議論を進められるため、心配点の洗い出しの質そのものが上がります。
逆にFMEAがない状態でDRBFMだけを実施すると、議論の土台となる情報が担当者の記憶頼みになってしまい有益な議論を行うことが難しくなります。

DRBFMの進め方

DRBFMは、一般に次のような流れで進めます。

1. 変更点・相違点を明確にする

今回の設計で「何を変えたか」「従来と何が違うか」を洗い出します。図面の差分だけでなく、材料、公差、製造方法、検査条件、搭載環境、サプライヤ、生産拠点まで含めて確認するのがポイントです。ここで挙げた項目の粒度と網羅性が、その後の議論の質をほぼ決めてしまいます。
旧図面や旧仕様書との比較、変更履歴の突き合わせなど、事実にもとづいて洗い出す工程を省略しないことが重要です。
変更の申請・承認・通知を管理するECR・ECO・ECNの流れは『設計変更でミスを防ぐためには？』で解説しています。

2. 心配点（故障モード）を洗い出す

変更点から起こりうる不具合や懸念を挙げます。「この変更によって、どの機能が損なわれる可能性があるか」を軸に考えると、抜けを減らせます。
変更した部品そのものだけでなく、隣接部品との干渉、組付け時の作業性、熱・振動・経時変化といった周辺への波及も検討対象です。
この段階では、実現性や重大性を判断せず、まず幅広く出すことを優先します。

3. デザインレビューで議論する

設計・品質・製造・生産技術など、立場の異なる関係者が集まり、心配点とその影響・原因を議論します。DRBFMがFMEAと最も異なるのがこの工程で、シートは議論の材料であって、目的は議論そのものにあります。「なぜそう言えるのか」「どういう条件なら問題になるのか」と問いを重ねることで、設計者一人では気づけないリスクを拾い上げます。

4. 対策を決め、実施・確認する

議論をもとに、設計での対応、評価・試験での対応、製造・検査での対応を切り分けて決めます。
担当者と期限を明記し、実施後に効果を確認するところまでを一つのサイクルとして完結させます。
ここが曖昧なまま次の工程に進むと、せっかくの議論が記録だけで終わってしまいます。

議論の内容は、一般に次のような項目を持つワークシートに整理します。

ポイントは、3の「議論」を形だけにしないことです。多様な視点で問いを重ねることで、一人では気づけないリスクを拾えます。

旧図面や変更履歴をすぐに突き合わせられる状態にしておくと、この工程の負荷は大きく下がります。
弊社の提供する製品ナレッジ活用基盤PRISMには、これらのデータをいつでも参照・比較できるように管理する機能がございます。

図面・文書管理

また、ワークシートの様式管理そのものを仕組みに載せたい場合は、PRISMのワークシート機能もあわせてご覧ください。

ワークシート

形骸化させないコツ

FMEAと同様DRBFMも、運用を誤ると「シートを埋めるだけ」になりがちです。

実際、「様式は決まっているが議論の場が短時間で終わる」「毎回同じ心配点しか出てこない」「対策欄が『注意する』で埋まっている」といった状態は、多くの現場で見られます。形骸化を防ぐには、次の点が重要です。

• 変更点の洗い出しを丁寧に行う：この部分が浅いと議論も浅くなります。「一部変更」「軽微な変更」といった粗い括りにせず、変えた項目を具体的に分解して書き出すことが出発点です。
• 立場の異なるメンバーで議論し、率直に懸念を出せる場をつくる：設計者だけで完結させると、設計上の前提そのものが疑われないまま通過してしまいます。製造・品質・生産技術・保全など、異なる痛みを知る人が参加してこそ、心配点は広がります。同時に、懸念を口にした人が責められない場づくりも欠かせません。
• 過去の不具合事例やDRBFMの記録を参照し、同じ失敗を繰り返さない：類似部位で過去に何が起きたかを議論の前に共有できるかどうかで、洗い出しの深さは大きく変わります。
• 対策を「行動」で書く：「注意する」「確認を徹底する」といった表現は、実質的に対策になっていません。誰が、どの図面・条件・工程を、どう変えるのかまで落とし込みます。
• 実施タイミングを早める：図面が固まってからでは、出てきた心配点に対して打てる手が限られます。構想段階から仕様が固まるまでの間に実施することで、対策の選択肢が広がります。
• すべての変更に同じ重さで実施しない：影響範囲の小さい変更まで一律にフルセットで運用すると、負荷ばかりが増えて中身が薄くなります。変更の影響度に応じて実施範囲や参加者を変えるなど、メリハリをつけた運用ルールを決めておくことが、継続の条件になります。

また、FMEAを形骸化させないためのポイントについては、以下の記事で解説しているのでぜひこちらもご一読ください。

FMEAの形骸化はなぜ起きるのか｜原因とFMEAを仕組み化する方法

過去の知見を活かす仕組み

DRBFMの質は、過去の変更や不具合の知見をどれだけ参照できるかにも左右されます。
「似た構造で過去に何が起きたか」「そのとき、どんな対策を打って、効果はどうだったか」を議論の場に持ち込めるかどうかが、心配点の洗い出しの深さを決めるからです。前章で触れた「毎回同じ心配点しか出てこない」という形骸化も、その多くは過去の議論や不具合が手元で見えないことに端を発しています。参照できる知見がなければ、心配点はどうしても、目の前の変更から直接連想できる範囲にとどまってしまいます。

しかし実際には、過去のDRBFMシートや不具合情報が個人のPCや紙・Excelに散らばっていて、必要なときに引き出せないという課題を抱える現場が少なくありません。ベテラン設計者の記憶に頼っている状態では、担当者が変わった瞬間に、同じ議論をゼロからやり直すことになります。さらに、図面、試験報告書、不具合報告書、変更履歴といった情報が別々の場所に保管されていると、一つの心配点を裏付けるだけでも相当な手間がかかります。

やっかいなのは、「探しても見つからない」だけでなく、「そもそも似た事例が過去にあることに気づけない」という点です。
関連する事例を知っている人がその場にいなければ、参照すべき知見があること自体に誰も気づかないまま議論が進んでしまいます。この状態では、DRBFMの成否がベテランの記憶や属人的な勘に強く依存し、組織としての再現性が生まれません。

また、せっかく実施したDRBFMそのものも、シートを埋めて終わりにしてしまうと、次の開発で活用されずに死蔵されがちです。
本来、DRBFMの記録は「この部位でどんな心配点が挙がり、どの対策が効いたか」という組織の資産であり、次に似た変更を行うときの出発点になり得ます。ところが、記録が検索も再利用もできない形で眠っていると、同じ論点を毎回ゼロから洗い出すことになり、議論の質は担当者や体制が変わるたびに振り出しに戻ってしまいます。
理想は、変更点を起点に、関連する過去のDRBFM記録・不具合事例・対策履歴・試験結果を、その場ですぐに引き出せる状態です。
裏付け情報の収集にかかる手間が減れば、その分の時間を、本来価値のある「議論そのもの」に振り向けられます。
過去の知見を活かす仕組みを整えることは、単なる情報整理ではなく、DRBFMの中身の濃さを底上げする投資だといえます。

まとめ

DRBFMは、設計の変更点・相違点に着目し、心配点をデザインレビューで議論して未然防止につなげる手法です。製品全体を網羅するFMEAに対し、変えたところを深く掘り下げる点が特徴であり、両者は対立するものではなく、組み合わせて運用することで効果を発揮します。

成否を分けるのは、様式の完成度ではなく、変更点の洗い出しの丁寧さと、立場を超えた率直な議論です。そしてその議論を支えるのが、過去の不具合やDRBFMの記録といった組織の知見です。変更点の洗い出しと率直な議論を丁寧に行い、過去の知見を活かす仕組みを整えることが、形骸化を防ぐ鍵になります。

ここまで見てきたように、DRBFMやFMEAで成果を出せるかどうかは、様式の完成度ではなく、変更点をどれだけ丁寧に洗い出せるか、過去の知見をどれだけ議論に持ち込めるか、そしてその土台の上で率直な議論ができるか、にかかっています。

逆にいえば、シートの作成や情報集めといった「準備作業」に時間を取られるほど、肝心の議論に割ける時間は削られていきます。
PRISMの機能の一つである「PRISM未然防止」は、この準備作業を軽くし、人が本質的な議論に集中できる状態をつくることを狙いとしています。

• DRBFM・FMEAのドラフトを自動生成：変更点や対象部位の情報をもとに、心配な故障モード・影響・原因・対策案のたたき台を作成します。白紙のシートをゼロから埋める負担が減り、レビューは「たたき台を叩く」ところから始められます。
• 過去のDRBFM／FMEA記録・不具合情報を一元管理し、その場で参照：図面・試験報告書・不具合報告書・変更履歴とひも付けて蓄積するため、「似た構造で過去に何が起きたか」を議論の場ですぐに引き出せます。属人的な記憶に頼らず、組織の知見を再利用できます。
• 変更点を起点に関連情報をひも付け：どの部位を変えると、過去のどの事例・対策・評価結果に関連するのかをたどりやすくし、洗い出しの抜け漏れを減らします。

※実際のPRISM画面上でのDRBFMドラフト作成の様子

ポイントは、AIがドラフトを用意することで人を議論から遠ざけるのではなく、むしろ議論に集中させるという発想です。準備や情報集めをPRISMが引き受けることで、設計・品質・製造・生産技術のメンバーは、「なぜそう言えるのか」「どういう条件なら問題になるのか」という、人にしかできない問いのやり取りに時間を使えます。
これは、シートを埋めること自体が目的化しがちな品質リスク分析を、「本質的な議論の場」へと引き戻す取り組みであり、いわば品質リスク分析の進め方そのものの改革だといえます。

DRBFMやFMEAの形骸化に課題を感じている方、過去の知見が活かしきれていないと感じている方は、
ぜひ一度下記フォームよりPRISMの紹介資料をご覧ください。