「DRBFMって、何の目的でやるの？」
「どのような様式なの？」
「とにかく記入例を教えて！」
こんな疑問や悩みをお持ちの方に向けた記事です。
DRBFM（Design Review Based on Failure Mode）は、トヨタ自動車が開発した品質不具合を未然に防止するフレームワークの手法です。
英語がずらずらと並んで難しそうですが、いわゆるDR（デザインレビュー、設計審査）の一部として取り入れると、品質不具合に対する感度を高められます。
この記事では、DRBFMとは何か、活用するメリット、記入例を含めた作り方の手順について、初心者の方でも分かるよう基礎から解説しています。
設計や生産技術の部門の方は、必ずと言っていいほど実務で活用する機会が出てくると思いますので、皆さんの参考になればうれしいです。
DRBFMとは？
でぃあーるびーえふえむ？
DRBFMとは、「Design Review Based on Failure Mode」の略で、日本語に訳すと「故障モードに基づいた設計審査」と表されます。
新製品の開発や、既存製品の改良にあたっては、設計や製造プロセスの変更は付きものです。
「変化なくして進化なし」という言葉の通り、意識的に何かを変えていかなければ、良い製品は生まれません。
製品設計や工程設計も革新が必要ですが、「従来から何かが変わる」ところに品質面での落とし穴があるのです。
DRBFMでは、設計や工程の従来からの変更点を挙げ、変更に伴う想定不具合と回避策を見つけ出して、設計段階でリスクを排除することで、品質不具合を未然に防ぐことができます。
FMEAとの違い
不具合を未然に防止するフレームワークにFMEAがあります。
FMEA（Failure Mode and Effects Analysis：故障モード影響解析）とは、想定される製品の故障モードをランク付けし、点数の高い項目を見える化して対策の方針や優先順位を決めるための解析手法です。
故障モードを事前に想定する観点ではDRBFMと同じですが、変更点に特化しているかという点で異なり、DRBFMは「変更点に着目したFMEA」と言ってもよいでしょう。
どちらも、未然防止に重要な解析手法ですので、目的に応じて使い分けられることが望ましいです。
DRBFMの構成
こちらは、DRBFMの様式の一例です。
項目の色分けごとに構成を見ていきましょう。
①：あらかじめ設計部門で記入する項目（黄緑）
シートの左半分は、最初に設計部門で記入する項目です。
変更対象の部品名（または工程名）、変更点、変更に関わる心配点、原因、設計での対応策を記載します。
また、故障発生の頻度、影響度、対応の優先度をランク付けします。
②：レビューの際に関係者で議論する項目（黄色）
黄色の項目は、レビューの際に関係者で議論して埋める内容です。
設計側で抽出した心配点や原因に対して、漏れがある場合は追記します。
シートの右半分では、関係者からの指摘を受けて、設計・評価・工程に反映すべき項目を記載します。
このように、あらかじめ設計者が①を記入し、レビューの場で②を議論します。
すると、DRBFMの結果として、追加で検討すべき要処置事項が明確になるのです。
③：対応の結果を記入する項目（橙色）
要処置事項に対して、対応の結果や進捗をシートの右端の欄に記入します。
目的・用途・メリット
１．不具合の未然防止
「故障モードに基づいた設計審査」という名の通り、品質保証の観点から製品設計や工程設計の妥当性を審査することがDRBFMの目的です。
あらかじめリスクを想定して、設計段階で摘み取ることで不具合の未然防止に繋がります。
２．変更点の一元管理
通常のデザインレビュー（DR）でも、従来製品や工程に対する違いを比較すると思いますが、DRBFMは変更点に特化して整理するフレームワークです。
DRBFMの様式で一元的に管理することで、影響の大小にかかわらず、変更点を漏れなく把握することができます。
３．関係者との情報共有
デザインレビューと言っても、設計者だけが指摘を受けて改善を図る訳ではなく、現場部門も協力して工程を作り上げていくことが必要です。
製造部門では日常点検や作業者教育、品管部門では流出防止策など、検討すべき項目をDRBFMで明確にできるので、関係者全体で改善事項を整理することに有効です。
作り方の手順
DRBFMの作り方の手順を説明します。
今回は、セラミック基材に配線電極を成膜する部品を題材として、設計と製造プロセスの変更点の記入例を挙げて解説していきます。
どこに何を書けば良いのか順番に教えて・・
シートの左半分を設計部門で記入する
１．部品名（または工程名）
まず、変更対象の部品名、工程名を記載します。
製品設計の変更が主な場合は、構成部品の単位に分類して記載すると分かりやすいです。
あるいは、工程設計の変更が主な場合は、工程ごとに分類すると分かりやすく、今回はこちらを例にしてみました。
なお、ひとつの工程でも複数の変更点がある場合は、無理に集約しようとせず、きちんと変更点の項目ごとに分類しましょう。
２．変更点、変更の目的、機能
次に、変更点とその目的、 及び部品や工程が有する機能を記載します。
変更点は単に「材料」とか「温度」のような表現だけではなく、できるだけ具体的に記載するようにしましょう。
というのも、同じ「温度」の変更でも、高くするのか、低くするのかによって、想定されるリスクが変わってくるので、より明確なイメージを掴めるようにするためです。
また、変更の目的も合わせて記載するようにしましょう。
そうすることで、変更の必要性が明確になり、万が一、リスクを懸念して適用を見送る場合でも、必要性（メリット）とのトレードオフをしやすくなります。
３．変更に関わる心配点
変更により想定される故障モード（リスク）を抽出します。
ここでも具体性が重要で、単に「破損」とか「外観不良」といった表現ではなく、具体的な不良モードとして挙げることで、その後の要因の分析に結び付けやすくなります。
４．心配点はどんな場合に生じるか
故障モードがどのような場合に生じるか、推定される原因・要因を記載します。
先に挙げた変更点と心配点を結び付ける根拠となります。
５．お客様への影響
故障が生じた場合に、お客様にどのような影響があるのか、さらに影響度の大きさを「大・中・小」などにランク分けして記載します。
お客様というのは、基本的には顧客そのものを表しますが、自社の後工程への影響も含めて厳密に管理したい場合は、「お客様＝後工程」と解釈して記載することもあります。
まさに、「後工程はお客様」という品質管理の基本的な考え方で、組織全体の品質意識の向上に繋がりますので、ぜひおススメします。
６．心配点を除くためにどんな設計をしたか
リスクを回避するために設計側で工夫した項目と、その優先度を記載します。
設計ルールや規格類の制定、あるいは理論計算などが該当します。
この段階でしっかりと設計側で歯止めがかけられていれば、追加での設計検討や評価は必要なくなります。
関係者でブラッシュアップする
ここからは、レビューの場にて関係者で議論するフェーズです。
７．心配点と原因（DRBFM）
あらかじめ設計側で抽出した心配点と原因に対し、他に漏れがないか関係者で議論します。
検査や生産技術など、それぞれの立場で気になるポイントは異なると思いますので、多角的な視点で項目を抽出することができます。
８．推奨する対応（DRBFMの結果）
心配点と原因のブラッシュアップが終わったら、DRBFMの結果として、要処置事項を整理していきます。
設計・評価・工程管理に反映が必要な項目を挙げ、担当と期限を明確にします。
心配点を除くために設計に盛り込んだ項目だけで対処が十分であればよいですが、不足の場合は追加の設計検討や評価の必要な項目を挙げます。
また、設計保証が困難な場合は、工程管理と合わせて品質保証することも考えられ、その場合は、工程での検討事項も必要になってきます。
対応の結果を記入する
最後に、対応の結果や進捗を記載します。
要処置事項のすべての対応が完了すれば、結論として「変更に対する品質への影響は低い」と判断され、変更内容が適用されることになります。
最後にまとめの判定会議をやった方が良さそうだね
DRBFM作成のポイント
１．「DRBFMの結果」を軽視しない
よく見受けられる悪い例として、心配点や原因を挙げることに意識が集中して、DRBFMで示された要処置事項の抽出に漏れが出ることです。
設計側で記入する項目はビッシリと埋められているのですが、その他がスカスカというケースも少なくありません。
様式に心配点と原因を埋めて終わりではなく、設計側の検討漏れや設計保証できない項目への対応策を明確にして対処を完遂する一連の流れが重要です。
DRBFMを実施してから変更の適用までの期間に余裕がないスケジュール設定は、そもそもDRBFMの結果を軽視した考え方で、これでは実施する意味がありません。
本来の目的である不具合の未然防止を果たすためにも、きちんと要処置事項を対応する時間的な余裕のある状態で臨むようにしましょう。
２．必ず全部門で実施する
これも悪い例ですが、設計部門で全てを記入して、他の部門はただ見ているだけという状態です。
どうしても、設計寄りの視点になりがちですので、やはり各部門で異なる視点を入れることが大切です。
実際に変更を適用してから何か問題が出て、「こんな設計じゃ製造できない」とか「そもそも設計検討が足りない」とか、後出しでのクレームはNGです。
３．変更点と変化点に注意
突然ですが、「変更点」と「変化点」の違いを普段から意識して使い分けているでしょうか？
変更：決められた物事などを変えること
引用元：デジタル大辞泉（小学館）
変化：ある状態や性質などが他の状態や性質に変わること
「変える」と「変わる」の違いがポイントで、変更は「意図的に変えること」を意味します。
DRBFMで最初に挙げるのは「変更点」で、つまり、設計者が意図的に変更した項目を記載します。
これに対し、心配点で登場するのは「変化点」で、設計変更によって「意図しない変化」が生じることを想定して、あらかじめ故障に繋がる心配点の可能性を洗い出すのです。
変更と変化がごちゃ混ぜに使われているケースがたまにありますので、きちんと意味を理解して使い分けるようにしましょう。
まとめ
- DRBFM（Design Review Based on Failure Mode：故障モードに基づいた設計審査）
⇒設計や工程の従来からの変更点を挙げ、変更に伴う想定不具合と回避策を見つけ出して、設計段階でリスクを排除するための解析手法 - 目的・用途
⇒不具合の未然防止、変更点の一元管理、関係者との情報共有 - 作り方の手順
⇒①：変更点、心配点、原因、対応策を設計部門で記入
②：関係者でブラッシュアップ
③：対応の結果を記入 - DRBFM作成のポイント
⇒①：「DRBFMの結果」を軽視しない
②：必ず全部門で実施する
③：変更点と変化点に注意
変更点管理は、自社内でのDR（設計審査）に必要なだけでなく、お客様への変更申請の際に提出を求められることも多くあります。
顧客からの信頼を得るためには、日頃から設計部門だけでなく、関係する全部門で品質保証に対する感度を高めておく必要があります。
ぜひ、記入例を参考に実践してみてください。
最後まで読んでいただき、ありがとうございました。
基本からコンパクトにまとめられた一冊。
デザインレビューの重要性からDRBFMの実施要領まで、考え方が為になる一冊。
コメント