信頼性に関しては、たいていは新人の時期に研修があり、それぞれの手法について詳しく学ぶと思うので、それを逐一解説する必要はないだろう。また、筆者は信頼性の専門家ではないので、その資格もない。ただ、エンジンに求められる最大の機能は信頼性の確保だと思っていて、上司の役員と言い合いになったほど筆者の信念になっている。
　最大トルクが1N大きくても、燃費が1%良くても、ユーザーには全く感じられない。けれど、エンジンがストールしたり、一部が破損して異音が発生したりすると、それが故障率0.001%の事象であっても、ユーザーにとっては100%。2度とそのメーカーの車を買うことはないだろう。
　性能や燃費の向上を軽く考えている、ということではなく、あくまでそれは信頼性確保の上に立っていないといけないと思うのだ。
　チャレンジはしないと競争に負ける。だからこそ、しっかりと信頼性を見極める努力をしないといけない。それを最初に言っておきたい。

　前置きはこれくらいにして、WEB上に公開されている図などを基に、筆者が実務を通して学んだことを、実践的な知識としてご紹介する。

１．故障の型



　このグラフは、故障率曲線で、故障には3つのタイプがある。

�@初期故障型
　設計不具合は、このタイプが多い。つまり設計ミスをした時は、すぐに不具合として顕在化する。迅速に対策すれば短期間で不具合は解消し、時間軸で見ると初期故障型となる。工場での作業不慣れによる不具合もこのタイプが多いが、作業者が代わった時に再発することもあって、一概には言えない。
　開発中に顕在化しない（見逃す）設計不具合には、どんなものがあるか。
　例えば異音。出ることはわかっていた。評価部署や品質保証部門とも、その情報は共有していた。対策は可能だがコストがかかり、会社として許容範囲と判断した。発売後ユーザーから（販社から）の強いコンプレインがあり、結果、余計な費用をかけて対策することになった、など。
　年々、品質に対するユーザーの要求レベルは上がってきている。他社がよりよいものを出してくれば、それと比較される。この場合は、会社としての判断だから、担当者が悪いという訳ではないが、もし誰も気づかない不具合に気がついたら、それが量産間際であっても、妙な忖度はせず上司なり関係部署に報告することだ。不具合のレベルにもよるが、量産を遅らせてでも対策しなければならない場合もある。その判断は、担当者が勝手にしてはいけない。みんなが困るから、と自分で抱え込むのは、結局会社を裏切ることになる。

�A偶発故障型
　慢性的に、ランダムに発生する不具合のこと。
　このタイプの不具合が、最も対策が難しいが、実は多い。原因も特定できず、考えられる対策をいろいろ講じても、なかなか不具合が解消しない。
　原因がわかりにくい不具合の原因を探る手法については、後で詳しく解説する。

�B摩耗故障型
　このタイプが一番恐ろしい。原因がわかった頃には、対象車が大量に世の中に出回っているからだ。生命の危険や路上故障につながるような不具合は、例え発生率が低くてもリコールすることになる。場合によっては、会社の経営を揺るがす事態にもなるので、だからこそ耐久信頼性の確認は、念には念をいれて実施しないといけない。


２．アポロとスペースシャトルの違い

　アポロ計画では、いわば金に糸目を付けず、とにかくソ連より先に月に宇宙飛行士を送り込むことが絶対的な使命だった。そのため、部品の精度を究極まで高め、成功の可能性を数値で示せるほどだったという。
　けれど、スペースシャトルは、商業ベースの開発を意図していた。つまり、ジャンボジェットなどと同じように、採算性を考慮する必要があった。結果的にそうはならなかったのは、そもそもブースターが機体を背負うコンセプトが、リスクが高すぎたと言われている。それはさておき、そのために考案されたのが、FMEAという考え方だ。これは後で詳しく述べるが、カーメーカーでもこの考え方は広く浸透している。というのも、カーメーカーこそ、採算性なしでは成り立たない営利企業だからだ。
　ここまでは、開発段階（設計段階）での考え方、つまり不具合の未然防止手法だ。
　不幸にして不具合が発生してしまった場合は、その原因を見つけないといけない。その場合に使われるのが、特性要因図、FTAなどの手法だ。
　更に、原因の特定が非常に難しい事象について、ケプナー・トリゴー両氏が考案したKT法がある。その中のPAという手法について、後で解説する。


３．特性要因図とFTA

　特性要因図とFTAの事例を示す。






　特に解説は不要と思うが、簡単におさらいすると、特性要因図は、性能向上や原価低減など、よい方向へ志向する検討時にも活用するが、FTA（fault tree analysis）は不具合対策が対象だ。FTAの場合は、原因系に対してどう対応するかを書き出して、開発時や市場対応時の各段階での実施内容もその表の中でフォローして行くことが可能だ。なので、事例とは異なり基本横書きがよいと思う。
　オイル消費を例にとると、開発段階では特性要因図を使って、どの要因を対象に改善して行くかを考える。市場対応では、FATを使って、なぜ悪化してしまったかを考える。項目を網羅することが目的ではなく、効果的な改善方法、対策案を考えることが目的だから、事務的に無理やり項目を増やす必要はないが、重要なポイントが抜ける事がないように、大勢の専門家の目でチェックすることは必要だ。


４．FMEA



　筆者は、FMEAの信奉者だ。FMEAは、不具合の未然防止を目的に開発段階で実施する。まだカーメーカーにFMEAが浸透していなかった頃から活用していて、恐らく社内では一番早くこの手法を取り入れたと自負している。
　特に、経験のない新技術にチャレンジする時や、システム全体を扱う時は、絶大な力を発揮する。ただ、その使い方を誤ると、ただのイベントになってしまう。
　筆者が思うFMEAの神髄は、多くの専門家のノウハウを集約出来るところにある。エンジニアひとりの力なんて、スゴ技の人がいたとしても知れている。特に未経験の技術に対して、すべての分野に関して思いをめぐらすことは、一担当者には不可能に近い。そこで、一旦設計図が出来た段階でDR（デザイン・レビュー）を行い、知見者の意見を頂戴するが、その時このFMEAが威力を発揮する。
　FMEAの心は、製品の不具合（故障）が生じたときに、それがユーザー（生産部門も含む）にどんな影響があるか、重み付けをする点にある。平たく言えば、費用対効果や開発日程なども考えて、まず起こらないこと、どうでもいいような不具合は後回しにする、という考え方だ。これが徹底出来ていないと、重箱の隅をつつく様な議論になり、設計者の工数は膨大になって、結果重大な欠陥が見過ごされる。要は、重点志向が出来ないと意味がないということ。実際の現場でそれが出来ているかと言うと、やや疑問な感もあるので、もしそうであれば、設計者は抵抗してください。趣旨が違うと。
　ただし、その重み付けが最も重要で、担当者の独断は許されない。分野の専門家や経験者の意見を素直に聞き、合意が得られるまで説明したり、設計変更で対応したりしないといけない。これがFMEAを実施するに当たって、最も重要な心構えだ。
　もし後になって思わぬ不具合が生じた時は、勿論設計者本人の責任は逃れられないが、FMEAは、なぜ見逃したかを考えるベースにもなるし、再発防止にも役立つ。
　FMEAは、何でもかんでも実施する必要はなく、専門家や経験者のノウハウが必要な部品に絞って行う方が、工数も低減できるし（この頃、残業時間が問題視される時代でもある）、焦点ボケしないのでよいと思う。ただし、やるやらないの判断は、担当者の独断ではしないこと。また、FMEAの対象外の簡単な部品でも、頭の中でFMEAを実施して、ミスのないような設計を心がけてください。


５．KT法



　お勧めは、KT法の中のPAという手法。
　もしかすると、KT法はカーメーカーではあまり活用されていないかも知れないが、筆者は何度かこの手法を、社内合意が難しい事案に活用したことがある。
　ひとことで言うと、議論が堂々めぐりするような事案について、意思決定が容易になるようにものごとを整理する手法だ。勿論、自分が頭を整理するのにも役立つ。それが形で表せるので、関係者に納得が得られるという訳だ。
　不具合の犯人捜しをする前に、まず不具合が起きている事象を、時間、場所、時期、傾向（拡大・縮小など）で整理する。この時に重要なのは、先入観を捨て、正確な情報なりデータを手に入れることだ。現地現物とよく言うが、それが問題解決のスタート。
　次に、不具合が起きていないケースも同様に、時間、場所などで整理する。これがキーポイント。KT法以外ではあまりやらない手法だと思うが、この時点で、もう何となく犯人が見えてくる。
　次に、不具合が起きていない場合に対して、起きている場合の相違点（何が違うのか）を書きだす。更に、その時間的変化（いつから、いつまで）も書く。
　最後に、犯人（不具合原因）と思われる要因を列挙して、整理した事実と合致するかどうかを検証する。もしどれも当てはまらない場合は、要因の組合せも考えてみる。

　KT法は、いわゆる信頼性手法ではなく、問題解決のための思考方法だ。シンクタンクのケプナー・トリゴー両氏が、米国の空軍関係者にリサーチして、頭のいい人はこの方法を頭の中でやっていることを発見したという。それを表に整理することで周囲も理解できるので、自分だけがわかっていて周りの理解が得られず、議論が空回りする時に使ってみるとよい。例えば、筆者の場合は、品質保証部門との調整に利用した。相手は技術者ではないので、なかなかこちらの言い分を理解してもらえない。それでKT法で説明し、納得してもらったという訳だ。
　勿論、自分が犯人を見つけられない時に使ってみてもよいが、犯人捜しはFTAなどでも可能なので、考え方として活用し、表の作成は説明用として位置づけた方がよいかも知れない。


６．信頼性試験のパターンと考え方

　具体的な数値は企業ノウハウになるので、代表的な試験について、一般的な考え方だけ紹介する。

　まだまだあると思うが、こうやって書き出すと、若いエンジン設計者に伝えたいことが湧き出して来てムズムズしてしまう。あまり深入りすると企業秘密に触れてしまうので、残念ながらこれくらいに留めておく。


７．不具合対策のフローチャート

　最後に、筆者のオリジナルの図で、不具合対策の流れを解説する。




　あまりに基本的なことなので、多分先輩たちはあえて説明はしてくれないだろう。だから、このフローチャートを逸脱して対策案を考える設計者がいるかも知れない。けれど、大変重要な考え方の基本なので、このチャートをいつも意識して業務に当たってもらうことをお勧めする。
　まず、不具合現象をどれだけ正確に把握しているかで、正しい対策方法にたどり着けるかが決まる。何度も言うが、先入観を持ってはいけない。データが間違っていることもない訳ではないが、思い込みで想定外のデータを故意に排除したり、自分の考えに合ったデータだけを採用するということがあってはならない。現地現物も、必ず徹底する。そのためには、普段から良品の姿を見ていないといけない。そうでないと、不具合品が不具合と気付かないからだ。筆者がイメージしているのは、ピストンリングやクランクメタルなどの摩耗故障型の部品だが。原因の推定は、予断を排し、事実に基づいて行う。その時に、特性要因図やFTA、KT法が役に立つ。
　対策案は誰でも考えるが、その前に再現試験をしないといけない。対策効果の確認のために、必ず必要だからだ。再現試験と効果確認試験はセットで考える。これがなかなかやっかいで、市場では起きても実験室内ではなかなか起きない事象がある。また、経年不具合を短時間（加速試験）で再現しようとすると、別の症状が起きてしまうこともある。なので、再現試験後の状態と実際の不具合状態とに差異がない（同じ顔つきをしている）ことをよく確認しないといけない。
　対策案は、当たり前だが、推定原因に対して立案しないといけない。これもセットで考えるべきものなのに、結構ルール破りが多い。市場から対策を迫られ、原因がなかなか判明しない時、仕方なく良かれと思う対策をさみだれ的に打つ。筆者はそのやり方には反対だ。というのも、原因が不明だと対策効果がないばかりか、コストもかかり、慌てて対応すると他の不具合が発生することすらある。それこそ、藪蛇だし、それは、やっていますというパフォーマンスに過ぎない。だからこそ、原因の特定を必死の思いで進めなければならない。これはきれい事ではなく、遅いと責められても耐えて、原因究明に心血を注ぐのがエンジニアのあるべき姿だと思っている。
　対策効果は、再現試験と同じ条件で確認する。再現試験が確立されていない時は、自ら考案する。考案した再現試験は、社内規格などに登録して、ノウハウとして残す。それも含めて設計の履歴を記録として残すと、会社の貴重な財産になる。
　設計変更の前には、当然ながら変更内容に対して背反がないことを確認する。その時に、FMEAが役に立つ。全く背反がなければそれでよいが、悪化が予想される項目については、それが実用上問題ないことを検証しなければならない。対策を急ぎ過ぎると、この部分が疎かになり失敗する。


　まだまだ書きたいことはたくさんあるが、キリがないのでこれくらいにしておこう。
　若い設計者が苦労して解決方法を考えている姿が目に浮かぶが、「みんな悩んで大きくなる」ものだ。
　「エンジン設計者のためのヒント集」シリーズは、これで完結するが、これらは本当にほんのヒントに過ぎない。エンジン設計（開発と言ってもいいが）の世界は途方もなく奥が深く、やればやるほどむしろわからない事が増えて、それをひとつひとつクリアして行くのが醍醐味だ。時には目からウロコが落ちる体験をしたり、逃げたくなるような辛い思いをしたり。その経験が将来に生きてくるので、逃げずに何事にも正面から向かって行ってください。そうすればきっと仕事が面白いと感じる時が来ます。それまでみなさん、がんばってください。応援しています。