- おすすめ
プロセス技術の問題解決の基礎《問題解決型QCストーリー・なぜなぜ分析等による問題解決ワーク》
【LIVE配信】2024/9/6(金)10:00~16:00
お問い合わせ
03-6206-4966
FTA(Fault Tree Analysis:故障の木解析)をご存知でしょうか?
FTAは、不具合(Fault)がどのような原因・要因で発生してしまうのか深堀り分析をする手法となります。
不具合に結びつく潜在的な危険性をFTA用いて解析を行うことで、製品の安全性を担保したり、高い品質の製品を生み出すことができます。
主に製品の設計・開発段階で行われる手法で、顧客とFTAレビューを行う場合もありますが、設計・開発段階に限らず量産後に原因がわからない不具合を分析する際にも使われる場合が多いです。
目次
FTAに指定のフォーマットは存在しませんが、ORゲートやANDゲートを使用して、問題が起きる要因を可視化します。
このように、ORゲート(論理和)や ANDゲート(論理積)を用いて問題を発生させる要因を抽出していきます。定量化できる事象がある場合は、発生率などの数字も挿入する場合もあります。この発生率は、基本的に、材料のデータシートや仕様書に記載している数字を記入します。主観的なデータにならないようにすることがポイントです。
FTAは、設計・開発段階で使用するのではなく、量産後に4M(Man:人、Machine:機械、Method:方法、Material:材料の頭文字をとった言葉)観点で、不具合が発生してしまった要因を分析するためにも使われるケースがあります。
このような場合は、考えられる原因(要因)に対して、三現主義(現場、現実、現物のこと)観点で確認を行います。そして、その確認結果から、それぞれの要因に対して『問題を引き起こした可能性はあるのか』判定を行います。
可能性がある場合は、それぞれに対策を行うことで、より精度の高い不具合対策へとなります。
前述の通り、設計・開発段階で行うFTAもあれば、量産後に行うFTAもあります。どちらも、不具合に繋がる要因を分析し、明確にするためのツールでした。
設計・開発段階で行うFTAの場合、論理回路(ORゲートやANDゲート)を用いることで、要因同士の関係性を意識して分析を行います。また、最終的に分析された要因には、ソフトウェアの動作や電圧値、設計値などの専門的な内容まで落とし込まれるケースが多いです。これは、設計者がレビューを行ったり、より不具合の出にくい設計にするために役立てられます。そのため、社外用と社内用で分ける企業もあります。
量産後のFTAは、4Mの観点で原因を模索するために使われることが多く、要因分析を論理的に行うことができるため、顧客の報告書にも記載されるケースがあります。生産現場観点で原因(例えば、作業者のミスなど)を探すために活用されるのです。
FTAは1人の分析者が、1人で考えて作るのではなく、複数の知見者を集め分析を進めていきます。
様々な知見をもった人が集まれば、様々な要因を抽出することができ、より良いFTAへ仕上がります。
様々な部門から知見者を集め、FTA作成チームを形成します。作成チームには、品質保証のみではなく、設計・生産技術・製造・出荷・アフターサービスなど、不具合に関わる部門を全員集めてブレインストーミングをしながらFTAを作成することが望ましいです。
勤続年数やスキルが高いプロフェッショナルのみで分析を行ってしまうと『こんな要因は考えられない!』と思い込んでしまい、実はその要因が悪さをしていたというケースもあったりします。そのため、年齢や勤続年数を問わず様々な視点で分析を行うことがポイントです。
『この要因は〇〇検査をしているから大丈夫』と頭の中で完結するのではなく、要因の大小に限らず挙げられる要因は全て出し切るのが理想的です。例えばホワイトボードなどに、少しでも考えられる要因を、みんなで書いてみたりしながらブレインストーミングを進めることが重要となります。
思い込みは捨てて、前向きに取り組むことが大切となります。その際は、他人の発言を尊重することがポイントです。新入社員や素人の人が的を得る発言をしたり、経験則で判断してしまいがちな玄人では考え付かないアイディアを挙げることがあります。世代問わず、集まった全員の知見を活かせるように進めることで、より良いFTAを作成することができます。
上記の段階で、ある程度FTAの形は仕上がったかと思います。
次のステップでは、実際に要因それぞれに対して『その要因が問題に繋がる可能性はあるのか?』調査を行います。
この調査は主観的に行うのではなく、データや事実を根拠に行います。例えば、出荷履歴や検査データなどのエビデンスを照合したり、測定結果などのデータを確認したりします。
この調査結果を用いて、次は “判定” のステップへと進みます。
調査結果から、それぞれの要因が問題に繋がるのかどうかを判定します。事象の原因ではないと判断できる客観的事実が見つかった場合は、判定欄に『〇』を入れましょう。証拠が不十分であったり、調査においてNGと判定できる事実が見つかった場合は『×』を入れ、必要な対策を検討します。
設計段階では全てを対策しきることも難しいため、対策の実施可否を入れたり、対策する場合は、どのようにリカバリーするのかを記載する企業もあります。
FTAは作成して終わりではありません。
しっかりと、どの従業員も確認できるように文書管理を行う必要があります。関係者へドキュメントのファイナライズが終わったら、共有を行ったり、サーバーへ保存したりします。作成者の手元に置きっぱなしは、しないようにしましょう。
また、FTAが終わったらFMEA(Failure Mode and Effects Analysis:故障モード影響解析)のレビューを行うことも大切になります。FMEAは、故障モード(要因)がどのくらい製品品質へインパクトを持っているのか定量的に分析するツールです。
作成したFTAの要因が、FMEAでも分析されているのか(要因がFMEAにも書かれているのか)レビューを行うことが大切です。
折角、FTAで抽出した要因がFMEAで転記されておらず、リスク分析が不十分だったというケースも多々あります。
『FTAが終わったらFMEAレビュー』を忘れずに、最後まで活動を進めることで、より高い品質の製品を生み出すことができます。
今回は、FTAの作成方法を中心にご説明しました。
不具合が何で発生してしまったのか要因を洗いざらいにすることで、論理的かつ漏れなく事象に繋がる要因を特定することができます。
また、FMEAなどのツールと組み合わせることで、より高い品質の製品を生み出すことが可能です。
次回は、FMEAの活用メリットと実施方法などについて解説します。
(アイアール技術者教育研究所 Y・S)