FTA とは？
FTAとは、Fault Tree Analysisの頭文字で、
障害とか欠点、問題点を起点に論理的に原因を探っていく手法です。
障害とか欠点、問題点に対して「なぜ？」という疑問を問いかけて、
答えがでたら、またその答えに対して「なぜ？」と問いかけ、
その問答を繰り返す…と言った感じで原因を探っていきます。
５回ぐらい「なぜ？なぜ？」繰り返せば、確実に原因にたどり着くと言われています。（問題提起が見当違いだと、たどり着く先は真の原因ではないです。）
この繰り返しを図示すると、ツリー状線図とかフィッシュボーン（魚の骨）線図とか言われる図ができてきます。
この図が、FTAの結果（成果物）です。
FTAは、トップダウン的解析と言われています。障害とか欠点、問題点から始まって、下位の原因へと向かうからです。
FTAとは…
・障害 欠点 問題点を起点に、論理的に原因を探っていく手法のこと。
・トップダウン的解析と言われている。
FTA はいつ使うか？
FTAはいつ使うのでしょうか？ Web検索すると、製品の故障という 重大な事象に対して使う…なんてことが語られています。
実際のところ、大それた事象のときだけ使うのではなく、開発設計者の仕事の中で起きる小さい問題・課題で、原因を探るために日常的にこの手法を使います。
（すぐに原因が特定できるものには使ってないですが..。）
課題管理表のページの書き方説明に、問題点 → 対策案 と書いている部分で、「→」の部分に使うことが多いです。
（マインドマップを使う場合もあります）
FTAを使うのは…
・事象の大小に関わらず、日常的に使う。
FTA をなぜ使うか？どんな効果があるか？
FTAをなぜ使うのでしょうか？
それは、障害とか欠点、問題点・課題の原因を絞り込んで特定するためです。
どの部分が原因か？もしかしたら複数の不具合箇所が複合した原因となっていないか？場所がわかったなら、その原因は構造的なものか？部品形状か？材料か？
など、段階的に真の原因を絞り込んでいきます。
FTAには どんな効果があるでしょうか？
問題箇所と問題でない箇所を 切り分けることができます。
複数の箇所が複合して原因になっていないかを確認することもできます。
原因と思われる箇所の候補が複数挙がって一つに絞り込めなくなるときは、検証を行うことになります。そのときの順番付けやウエイトを考え易くなります。
FTAを行わないと、どんなことが起こるでしょうか？
原因を探るための検証に直ぐに着手したり、闇雲に手あたり次第に対策を実行すると、やらなくてもいい検証や、見当違いな検証や対策をしてしまいます。先にFTAを行えば、無駄なことはしなくなります。
それで、 FTAには全体的に見て時間短縮・コスト圧縮・高い成果に繋がるという効果が あります。(最高の効率を発揮できます。)
FTAを行なう理由は…
・原因を絞り込んで特定するため。
・問題箇所を切り分けるため。問題箇所の複合がないか見極めるため。
・無駄な検証や対策、見当違いな検証や対策をしないようにするため。
FTA はどう書けばいい？
FTAはどう書けばいいのでしょうか？
まず、障害とか欠点、問題点・課題の総称を１つ書きます。
次に、詳細な障害・欠点・問題点・課題を書きます。包み隠さず列挙します。（複数出てくるはずです）
次に、「詳細な障害・欠点・問題点・課題」の横に、すぐに思いつく原因を１つ書きます。（「なぜ」の１回目）
そして、その横にその原因の原因を書きます。（「なぜ」の２回目）
「なぜ」の答えが出なくなるまで繰り返します。
最後に、「なぜ」で得た答えに対する対策方法を書く というのが一般的な方法です。
FTAの書き方は…
・障害 欠点 問題点 課題の 総称を１つ書く。
・障害 欠点 問題点 課題の 詳細を できるだけ多く書く。
・すぐに思いつく原因を１つ書く。
・原因の原因が尽きるまで書いていく。
・最後に対策方法を書く。
しかし..、
このままだと、机上の空論で終わっています。
というのは、最後に導いた対策が本当に良いか検証していないからです。
開発設計では、二次障害がない ベストな対策を求められます。
「なぜ？・なぜ？」で原因を探る方法は、検証を念頭に置いてないので
不完全な感じがあります。
それで…、
開発設計でお薦めするFTAのやり方
開発設計でお薦めするFTAのやり方は、一般にFTAとして紹介されているやり方（上記）と少し違います。
それは…
原因の仮説を立てて → 仮説を実験で検証する やり方です。
起きた事象に対して、起きた原因の仮説を複数立て、それらの仮説を実験でひとつひとつ検証し、仮説を潰しながら 原因を絞り込んでいくやり方をしています。
検証した結果、原因でなかった仮説には、FTA上に 「×」 を書いておきます。
もし、抽出した複数の仮説を検証して原因にたどり着かなかったら、さらに新たな仮説を立てて検証…といった感じで進めています。
（経験上、難解な事象に遭遇することが多かったこともあり、この方法のほうが効率的と思っています。）
開発設計でFTAをするときは…
・原因の仮説を立て、仮説を実験検証するスタンスで進める。
FTAｻﾝﾌﾟﾙ ﾃﾝﾌﾟﾚｰﾄ（仮説・検証版）（エクセル版）
参考までに、エクセル版のサンプルのテンプレートをアップしましたので、
活用してみてください。
おすすめの本
以下の本がとても素晴らしい内容の本なので、そちらを見ていただきたいと思います。
FTAは、事例があった方が理解しやすいと思います。
でも、わたしが実際に行った実例を このweb上にアップすることは、守秘義務の関係上難しいので、以下の本を購入して事例を見ていただければと考えています。
（web上にアップされている事例は、ホンモノかどうか怪しいと思ったほうが良いと思います。本に事例を書く場合は、事例元に了承を取らないと載せられないので、安心できると思います。というわけで、有料本から事例を知ることをオススメします。）
設計の超々プロが書いてくださったノウハウ本で、とても秀逸です。
本の著者は、FTAは匠の道具で 場数を踏まないとうまくいかない..と言われています。私もそう思います。
わたしもこの本を購入しました。さすが有料本だけあって、事例が多く書かれています。
ホントに設計現場で実践してきた方のノウハウが詰まっている感じです。
理論理解と実践活用のどちらでも使える本です。
FTAとFMEAをうまく使いこなせるようになれます。
（ネット上に本の内容が公開されることは、今後もないと思いますので、購入がオススメです。）
このリンク先では、ロジックツリーとMECE展開をミックスした手法が良い と指摘・提案してくださっています。
私も、FTAでANDツリー ORツリーを気にせず書いていたり、ダブリに気づいていなかったりしていたかもしれません。
今後は、この手法を取り入れることも考えたいと思います。
FTA を使って、どうだったか？ 気を付けることは？
このFTAを行うと、思ってもみなかったことが原因であることがわかったりします。
これまで正しいと思い込んでいたことや、先輩たちが築いたものを打ち壊すことになるときもあります。
開発設計した自分の考えが間違いだったことが赤裸々に明らかになることもあます。とても恥ずかしい思いや、犯人捜しされて居場所がなくなるかもしれないという怖れに駆られるかもしれません。
しかし、それらを乗り越えないと、真の原因にたどり着くことも、真の対策も打つことはできません。
（ここで隠蔽できても、モノは真実を語ります。どんなに隠しても、後で明らかになります。発覚したときは、腹をくくるしかありません。）
FTAを使って原因分析したとき、ある経験をしました。
FTAの仮説から実験の順番を決めて検証していきました。まさかの結果が出ました。先輩たちの築いた理論が間違っていて、皆がその理論が正しいと思い込んでいました。
長い期間そのまま運用して解決することに着手せず、顧客に迷惑をかけ、自社に損失をもたらし続けていたことが明白になりました。
（それを正すのは勇気がいりましたが、確実な対策方法を提示できたので、事なきを得ました。）
開発・設計者のみなさん、どうか、自分の思考を隠蔽や自分の立場を守るために使わないようにしてください。いつか、明らかになります。
物理現象を素直に受け止めて、愚直に対策検討されることを願っています。
FTAをしたら…
・それまで正しいと思っていたことが、打ち砕かれる時がある。
・出た結果を素直に受け入れ、隠蔽せず、対策に移行する。
・FTAで明らかになった内容について、自分や組織を擁護する言動・行動をしない。