不具合が出た時こそ、技術者の本領発揮、と考えるべきでしょう。トラブルが人を成長させる、ということもできます。担当者が原因究明に燃える姿を、プロジェクトマネージャは辛抱強く、見守りましょう。
また、少し論理的ではなく、感性的な話になりますが、複数の不具合調査の場を経験すると、ある程度のアタリを付けることができるようになる気がしています。遠回りをせず、原因究明が最短距離で進められるような感じです。
言い換えると、右脳で直感的に考えたことを、左脳でロジカル的にチェックし論理付ける、という作業を同時に進めているイメージでしょうか。
ただし、早々と原因を特定して問題解決に至ったと思う時でも、FTAに基づき、そのほかの考えられる要因を全て潰し込む作業は実施しておいた方がよいと思います。特定したと思った原因が実は副次的な、あるいは表層的な現象であり、真の原因がほかにあった、ということも過去に経験したことがあります。
技術は正直です。後々になって、真の原因が顔を出し、思いもしなかった悪影響を及ぼすことも否定できません。
面倒な文書作業が必要な理由
原因究明を終えて処置を決定する前に一度、時系列を振り返って、すべての因果関係や前後関係の辻褄が合っていて、論理的に説明できるか、文書で整理しておくことも大切です。
プロジェクトマネージャは、上層部へのレポートも必要でしょう。そのような文書作業は面倒だと思われがちですが、実はプロジェクトマネージャの頭の整理のために必要なのかもしれません。
私も、月に一度のリスク管理会議に向けて、厳しい質問にもロジカルに答えられるよう根を詰めて資料作成を行っていました。ただ、大きな不具合を抱えた会議の前日は、胃が痛かった思い出があります。
そして、徹底的に不具合の原因を追究し、バグ出しを終えた製品は、それまでの誤動作がウソのように、完璧な動作を始めます。正しく設計を行えば、何事もなかったかのように、粛々と動作し続けるのも、技術の真理であるといえるでしょう。
