DFMEAとは? 書き方は？開発初期用フォーマットを公開中！

このページで扱うのは、「DFMEA」です。

DFMEAとは何で、何ができて、どうすればいいか？を扱います。

わたしたちがモノを購入したとき、日本製品のほとんどは、保証期間内に故障するということが少ないと思います。故障したとしても、簡単な交換で直ることが多いと思います。

意外と保証期間が過ぎたら、すぐ壊れた..という経験があるんですけどね..。
 

このようになっているのは、メーカーがある検討を行っているからです。

それが、「DFMEA」です。
 

開発設計したモノを顧客が使うとき、保証の期間内に故障してしまわないように、開発設計者は、開発設計段階で考慮・検討を重ねているのです。

どうしても故障しそうな部分は、あらかじめ交換しやすいようにしておいしたり、保守部品に設定して一定期間内に交換するようにするなど、たゆみない検討を行っているのです。

こういったリスクを洗い出すために、「DFMEA」という手法が用いられています。

DFMEAとは?

DFMEAとは何でしょうか?　Design Failure Mode and Effect Analysis　の略で、設計故障モード影響解析のことです。Designは設計のことです。

設計したモノが故障しやすいところや弱いところがどこかを探し、 それに対して対策を打つために、開発設計者の側で分析することを指しています。

設計の不具合が起因となってモノが壊れるとき、完全に壊れてしまう前になんとか踏みとどまらせる..といった検討をやっておきましょう　といった感じと思っています。

つまり、リスク軽減策を施しているか分析しましょうね..というものと受け止めています。

DFMEAはモノの開発設計にのみに使用します。

類似でPFMEAというのもあります。PはProcess（工程）のことで、製品製作等のプロセスやサービスの分析に使用されます。

DFMEAで不可能なことがあります。それは、DFMEAを実施していたとしても、必ず不具合が起こるということです。
要因が複雑に絡み合って発生した不具合は、DFMEAで予期しきれないことが多いです。そういった場合はFTAで原因を探っていきます。

　

なぜDFMEAが必要か?

DFMEAを行うことにより、開発設計段階でモノに潜んでいる不具合を特定していきます。

そして、特定した不具合が引き起こすリスクを想定し、それに対して対策・防止策を検討していきます。
モノを作るとき、組み立てるとき、運ぶとき、保管するとき、顧客が使うとき、といったシュチュエーションごとに開発設計に起因した不具合が出ないか検討したり、あるユニットの部品が壊れたらどんなリスクが起きるかを分析していきます。

それから、リスクを下げる対策を行なうための期日を明確にし、実行する計画を立てます。

この一連のDFMEAの作業を行うことで、モノの信頼性が向上していくことになります。

つまり、DFMEAはモノの信頼性を向上させるために必要で、
それによって、モノを作っているブランド・メーカーの信頼度を向上させ、信頼度を維持していくのに必要なのです。

DFMEAはいつ行なうか?

DFMEAの資料は、開発設計がほぼ完了する段階で行われるデザインレビューで必要な資料になりますから、それまでにDFMEAを実施することが必要です。

開発設計の終盤になればなるほど、モノの実態がハッキリしてくるので、DFMEAがやり易くなります。
でも、終盤でDFMEAを実施して修正が発生すると、開発設計の手戻りが起きて作業が大変なことになるので、開発設計の中盤ぐらいから始めていくのが良いと思います。

過去に設計したユニットの流用とか装置のスペックで各箇所の重要度が変わるというのは、開発設計のだいたい中盤までには判明しているので、そういった流用や変更がある箇所の周囲からDFMEAを進めておくことができると思います。
（ユニットを流用した箇所は、既にDFMEA実施済のはずなので、資料を持ってくるだけです。）

新技術や新手法を採用した部分や全くの新規開発の部分は、開発設計の終盤にDFMEAを実施することになると思います。

開発設計の最初からDFMEAを実施する方法があります。このページの最後に、開発設計初期用のフォーマットをアップしていますので、参考にしてみてください。

　

DFMEAの書き方は?

DFMEAはどう書けばいいのでしょうか？

開発設計した機能に対し、どんな故障が起きるか（故障モード）を考え得る限り書きます。

そして、その隣の欄に、その故障が及ぼす影響を書きます。

そして、その隣の欄に、それらの原因を書きます。

次に、重大度・発生度・検出度の欄に点数を付けます。

そして、原因に対する対策を書きます。

そして、その隣の欄に、対策後の重大度・発生度・検出度の欄に点数を付けます。

重大度・発生度・検出度を掛け合わせた点数の　対策前・対策後の差が大きい項目から、対策を開始します。

　

おすすめの本

以下の本がとても素晴らしい内容の本なので、そちらを見ていただきたいと思います。
FMEA・DFMEAは、事例があった方が理解しやすいと思います。
でも、わたしが実際に行った実例を このweb上にアップすることは、守秘義務の関係上難しいので、以下の本から事例を見ていただければと考えています。

（web上にアップされている事例は、ホンモノかどうか怪しいと思ったほうが良いと思います。本に事例を書く場合は、事例元に了承を取らないと載せられないので、安心できると思います。というわけで、有料本から事例を知ることをオススメします。）

　

DFMEAを使うと どんな効果があるか?

DFMEAを行うとき、いつも悩まされることがあります。それは、個々の部品や組み立てた状態の「寿命」をどう算出するか？です。
設計している最中の段階で、それを予測するわけです。 だけど、まだ世に無い物の寿命なんてだれもわからない..検証するしかないね..となってしまいます。
どちらかというと、余裕がある・ない・やばいを見分けて対策しておく..というような使い方です。

例えば、仕様に対してベアリングの寿命は数値上大丈夫で余裕があるけど、経験的・感覚的に余裕が ない”かも”..という感じなんですよね..。
ここで重要なのが、誰が言っているかです。その道30年の人だと、かなりの信憑性があるので、 信じたほうがいいです。先人・経験者の意見を尊重することは、設計者が持つべき思考と思います。

過去に先人・経験者の意見を聞き入れず、大変な事態が起きたことがあります。
DFMEAをやっている時ではなかったのですが、DRで詳細構造を見せない設計者がいました。
モノが出来上がって、組んでみるとあちこちに部品同士のスキマ設定ミスが発覚しました。
組み立てても思った動きにならないしグチャグチャです。顧客にサンプルを送る期日が迫っていた ので、組み立て確認後に予定していた仕上げ工程も修正に取られ、修正もままならずサンプルを顧客に 送ることになってしまいました。その後は大事件発生です..。

DFMEAが習慣になると、何か勘のようなものが働く感じがします。
設計検討中に「これだと、 こうなるかも」といった感じです。それで、いくつかの案を検討しておくことをしています。 もしかしたら、DFMEAをやることは、技術レベルをあげていく助けになっているのかもしれません。

あとは、重大度・発生度・検出度を掛け合わせた点数で、重要度や優先度が決まり、対策の順序が決まるのですが、 点数を付けようとすると、人によって意見がまちまちになるということが非常に多いです。
こういった理由もあり、評価点を少し良い方向に見せておけば、自分が少し楽になる..なんていう心理に 駆られるときがあります。でも、そんな考えは毅然と はねつけて欲しいです。 そんなことをしてしまうと、あとあと開発設計者である自分に戻ってきます。

DFMEAをやると、ほんと疲れます。だけど、これは自分を守る・会社を守る・顧客を守る・世界を守る もの(自分が知らない誰かのため)だという考えをもてば、やる気がでてきます。

開発・設計者の方々には、自分の仕事は「誰かに喜んでもらうためだ、誰かの役に立つためだ。」 という思考を、いつも持っていてもらいたいと思っています。

DFMEAを応用した 開発設計初期用フォーマット

開発設計の構想段階～詳細設計初期の段階は、モノの実態がはっきりしないと思います。
その段階でDFMEAをするのは、かなりの経験が必要です。みなさん、困っていると思います。

そこで、私が活用している、DFMEAを応用した仕様実現検討用のサンプルフォーマットをアップしておきます。　参考にしてみてください。

（開発設計の中盤以降で使うフォーマットは、現在準備中です。）

　　DFMEA応用 仕様実現検討表－ｻﾝﾌﾟﾙﾌｫｰﾏｯﾄ

1 ファイル 11.90 KB

ダウンロード

リダイレクトを修正中です。(2022/11/14)