採用するなら｢会議で板書するエンジニア｣にすべき理由…JAXA開発｢だいち4号｣のプロジェクトマネージャが指摘

このFTA解析を行うことにより、正常性バイアスを取り払い、「もし〇〇が原因であると仮定するならば、この事象を説明できそうか」ということを一つずつ考えて、要因を潰していく作業が網羅的にできるようになります。逆側からの発想です。

ただ、FTAを作るのは、なかなか技量が必要です。最初の段階で考えられる要因候補をMECEに（モレなく、ダブりなく）書き出し、一つずつ要因を排除していくのですが、調査を進めた結果、要因候補が全て消えてしまった、なんてことも時々あります。

メーカーの特性や、開発部署の担当者がどれだけ慣れているかにもよるのですが、不具合原因究明を進めていく途中で、新しい要因候補が増えていく（FTAが育っていく）のは、よくない兆候と捉えるべきでしょう。

一つのコツは、FMEAの考えが頭に入っているかだと思います。部品レベルなのか、機能レベルなのか、分析の着眼点は別としても、FMEAでは「ある部品（またはある機能）が故障したとしたら、どのような現象が表れるか」を分析する作業なので、その逆を行うわけです。

つまり「この現象が表れるためには、この部品・機能が故障している可能性がある」という整理を行います。まさしく、センスが問われる作業です。

その上で「この部品・機能が故障していると仮定すると、他のこの部分にも影響が出ているはずだが、それが確認されないので、この部品・機能は故障しておらず、正常であるはずだ」という形で、調査を進めていきます。

不具合が出た時こそ、技術者の本領発揮

また、あらかじめ資料に整理されたFTAに基づいて議論すると、その分析が正しいという前提で議論を進めてしまうため、思考に枠がはめられた状態になります。初動調査の段階においては、ホワイトボードに要因を一つずつ書き出して、みんなで議論しながら調査を進める方が、より充実したものになるように思います。

このような調査作業において、主体的に前に立ち、マーカーを手にホワイトボードに書き込んでいくエンジニアの姿を見ると、将来の活躍が楽しみで目を細めてしまいます。