問題解決あるあるコラム#33：Failure modeの“mode”ってなんだ？
こんにちは。いちおか＠問題解決サポーターKAIOS代表です。
問題解決あるあるコラム第33回のテーマは、「Failure modeの“mode”ってなんだ？」です。ご存知、FMEA（Failure Mode and Effect Analysis）のFailure modeです。皆さん、この「モード」、どう理解していますか？ ちょっと分かり難いですよね。今回はこの「モード」について考えてみたいと思います。
なぜカタカナで「モード」なんだ？
自動車業界に籍を置き、製品開発に携われば避けては通れないのが「FMEA」です。日本語にすると「故障モード影響解析」です。和訳しても「モード」と、カタカナで書かれています。多くの外来語が日本語に翻訳されていますが、日本語にピッタリの言葉がない場合、外来語は誤解を避けるためカタカナで表記されます。品質マネジメントシステムなどもそうですね。「マネジメント」をピッタリ表す日本語がないので、そのままカタカナで表現されています。じゃあ、一体全体この「モード」ってなんなのでしょう？
「モード」ってなんだ？
「『故障モード』は『故障モード』だよ」そう言うしかない環境で過ごしてきた技術者の方も多いのではないでしょうか？ このなんとも表現し切れない「モード」のおかげで、FMEAが上手くできていない組織がたくさん生まれている気がしてなりません。この「モード」を、意味ある日本語に変換しないことには、FMEA自体が本来の意味を失い、多大な労力を消費するただのコピペ文書になってしまいます。
7 step FMEAの登場
FMEAは、ワークシートで構成されています。そして、記入する欄がたくさんあり、それだけで技術者をゲンナリさせてしまいます。初めてFMEAのワークシートと向き合った技術者は絶望しか感じないでしょう。私も長年苦しんできました。そして、そんな状況が続く中、数年前にFMEAに大改革が起きました。そう、「7 step FMEA」の登場です。分厚いガイドブックが発行され、皆さんますますゲンナリされたことでしょう。しかし、この「７ step」の登場が「モード」の謎を解き明かしてくれました。
ポイントはFailure mode and effect analysisの「and」だった
それは、この「7 step」の中で、分析する対象の「Failure＝故障」を「cause-mode-effect」の３つの領域に定義した事によります。なんと、「原因」と「影響」の間に「モード」が挟まれたのです。これにより、今まで思っていたFMEAが「『Failure mode』and『effect analysis』」ではなくて、「Failure『mode and effect』analysis」だったのだ、ということがわかりました。名称が日本語にされるときに「and」が消えてしまったので、「モード影響解析」ってなんだ？ と、意味不明になってしまっていたのですね。なので、正確にはFMEAは「故障モード」と「故障影響」の解析をしたかったのです。
「モード」は「条件」
こうして、改めて「Failure cause」「Failure mode」「Failure effect」と定義しなおしてくれたおかげで、「故障の原因」と「故障モード」と「故障の影響」と、時系列で考えることができるようになりました。するとそれよって、ずっと正体が分からず悩んでいた「モード」が「条件」と読み替えることができたのです。そう、「モード」は「条件」だったのです。確かに、「原因」があってもそれによって100％事故が起きる訳でもないし、「条件」によっては小さい事故で済むこともあるし、大事故になってしまうこともあります。このように「条件」を場合分けし、それぞれの「影響」を想定することで、どのような「条件」を発生させなければ良いのか？ はたまたその「条件」に合致しても、被害を最小限にするにはどうしたら良いのか？ と論理的に考えることができるようになります。
「条件」がみつかれば、リスクを過小評価せずに済む
このように「モード」を「条件」に読み替え、「原因」と「影響」を解析すれば、リスク低減策も考えやすくなります。今までは「モード」がよく分からないために、ワークシート上でリスクが正しく見積もられず、「影響なし」や「検査で確認」などの、リスクの「過小評価」や問題解決の「先送り」といった、ワークシートを埋めるためのコメントが生まれてしまっていましたが、「原因」に対する「条件」の場合分けをすることで、「影響」を最小化するための「対策」を絞り込むことができ、限られたリソースの「選択と集中」ができるようになります。そうして考えられた「リスク回避対策」はワークシートのAction欄に自信を持って記載することができ、安全設計が実施された証拠となります。
FMEAはワークシートではなくプロセス
このように、改めてFMEAを見つめなおしてみると、故障の「原因」「条件」「影響」を洗い出していくことで、必要な対策の場合分けを行い「どこにリソースを集中させるのか」という、設計計画の重要なインプットになることが分かります。そうして、設計の優先順位づけを行い、「計画した対策」と「実行した対策の結果」を比較し、想定通りの安全設計ができていることが確認され結果がワークシートに記録されれば、この記録が安全設計の証拠となり、次の設計のベースラインとなります。そう、FMEAはただのワークシートではなく、設計の入口から出口をデザインする「プロセス」なのです。
まとめ
いかがでしたでしょうか？ 正体不明の「モード」が、「条件」という意味をまとった言葉に置き換わることで、今まで機能不全を起こしていたFMEAが、設計プロセスのど真ん中に降りてくることが可能となりました。マンホールの蓋が開いているだけでは直ちに事故にはなりません、事故が発生するためにはさまざまな「条件」が必要です。その「条件」毎に被害の「影響」を考え、許容できる程度まで被害を軽減することが設計者には求められています。「蓋が開いていてもまず人が落ちる心配はない」というのはFMEAではありません。今一度、お手元にあるFMEAを見なおしてみてください。「原因」「条件」「影響」の組み合わせが、あなたの見える世界を一新してくれるかもしれません。
今回も最後までお読み頂きありがとうございました。
次回のテーマは「本当に困ってたらとっくに解決してる」です。
次回もお楽しみに！
注）「モード＝条件」は私、市岡が主張しているだけで、AIAGなどの公式機関が使用している日本語訳ではありません。