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

むしろ、技術的な観点を正しく整理した上で、問題点をロジカルに追究し、全員が一丸となってトラブルを克服することにベクトルを揃えることが重要です。相手も人間。技術的に足りない点や改善すべき点が腹落ちすれば、前向きに対処することができます。

私が社会人になって最初に配属されたチームでのことです。

ある不具合が発生し、大きな開発スケジュールの遅延が免れないだろう、という事態が発生した最初の対策会議で、当時のプロジェクトマネージャは「はっはっはっ、これは困ったねー」と笑っていました。

おそらく、重苦しい雰囲気を打破して、メーカーも含め緊張をほぐすためのテクニックだったのではないかと思います。その後、みんなの協力のもとトラブルを克服し、大事には至りませんでした。

私はといえば、プロジェクトマネージャとしてそこまで達観した対応はなかなかできませんでしたが、不具合の一報が知らされた時には「連絡ありがとうございます。まずは落ち着いて原因分析を進めましょう」と伝えることを心がけていました。

ひとたび不具合の原因が特定された後は、その背後に潜む要因を分析することも重要です。設計的になぜそのような誤りを混入させてしまったのか、また、点検レビューの場でもなぜそのような誤りに気付かず流出させてしまったのか。

人を責めることは慎むべきですが、このように制度的に未熟な部分は、徹底的に追究することが必要です。これにより、類似の不具合が再発することを防ぐことができます。人を憎まず、仕組みを憎む、でしょうか。

原因追究のために宇宙開発の現場でされていること

物理現象に基づく技術製品の開発を行っている以上、何か想定外の動きをする原因は必ずあります。もしも原因がないとすれば、それは設計の原理や思想が間違っているか、偶然うまくいっていたということなので、原点から立ち返るべき話でしょう。

さて、その原因を追究するために宇宙開発の現場で通常採用されている手法として、FTA：Fault Tree Analysis （故障の木解析）というものがあります。