エンジニアの組織開発⑯ 原因論

自分が学んだコーチングスクールは、アドラー心理学をベースにしていて、「目的論」と「原因論」のコミュニケーションについて学びました。この２つを簡単に説明すると、

　・原因論　：　事象が起こった原因を徹底的に追及する。原因追求型

　・目的論　：　どうなっていたらいいか？　目的志向型

になります。エンジニアの世界では、ある事象が発生したとき、「なぜ？」を５回繰り返して真因を探ることは常識となっています。これは、物理や化学現象、ソフトウェアなどのエンジニアの業界では非常に有効です。これをしなければ、日常の業務を行うことはできません。市場で問題が発生したら、しっかり真因を探って直して安全を確保することは当然ですからね。また、自分たちは機能展開/要因展開ということも日常で行っており、エンジニアであれば、ある事象を展開/分解しながら考えることは得意です。因数分解する感覚ですよね。

でも、これが、変な展開/分解をしてしまうと、とんでもないことになります。例えば、「チームで取り組んでいるロケット発射の実験が、途中で燃料漏れが発生して延期になった。」という事象が発生したとします。この時、燃料漏れの要因を探ることは必須ですので、可能性のある要因を複数上げていきます。

　・「高温時の燃料の粘度変化の可能性」

　・「高温時のエンジン内面の熱膨張」

等の物理現象や化学現象が要因として列挙されるのは大切です。が、事実として、

　・「設計者間の連携ミス」

のような人的な要因が上がることは多々あります。この時、物理/化学現象の場合は、更に追求し、高温時の粘度や熱膨張を測定します。一方で、設計者間の連携ミスを追究しても、「〇〇さんのチェックが甘い。」のような人格否定に繋がったり、「〇〇さんと××さんのコミュニケーション不足」のような分かったような分からない要因が出てくるんです。こうなると、チーム内の人間関係はギクシャクしてきます。

実際、自分のチームでは、同じことが起こりました。管理職なりたての頃は、自分が率先して要因展開し、「〇〇さんと××さんのコミュニケーション不足」を改善しよう！なんてことを思ってました。そして、〇〇さんと××さんの打ち合わせを毎朝やることに設定し、自分もそこに参加するようなことをしてました。これは、部下のことを信頼してないってことの裏返しなんだってことに気付いてなかったですからね。毎朝の打ち合わせには欠かさず参加して、全力でやればやるほど、〇〇さんと××さんのコミュニケーションは悪くなっていきました。本当に皮肉なものです。

「原因論」が悪いわけではないんです。エンジニアの世界で原因追求は必須です。じゃ、「目的論」だったら・・・　　これは、これでいろいろあるんですよ。