指摘をするとエンジニアって素直に聞くふりして聞き流したり、ムキになっちゃたりするところがカワイイ生き物だよね

少し前の頃の話なんですが、割とスケジュール的に他所のプロジェクトのレビューしてほしいとお声掛けされることが立て続けにあって、事前に配布されるレビュー対象のドキュメントを査読していたり、そそくさとレビューアとして出席したときに考えさせられたことは、「エンジニアって、自分たちがやっていることや、やろうとしていることを分かっているつもりでいるけれど、その実は全てをわかってやっていないものだなぁ。」と言うことです。

エンジニアだからと限られるわけではないけれど、自分はわかっているつもりでもその考えたことすべてをわかっているわけじゃないな、と。

プロジェクト計画書のレビューで
エンジニアとしては十分な経験を持っているのでプロジェクトマネージャを担うことになったらしいし、それまで十分、いくつもプロジェクトのサブリーダもやってきた人がプロジェクト計画書を書いたのでレビューして欲しいと依頼があったので応じることにしたんです。

レビューは、フォーマルにやろうと思うならレビューの対象を、ドキュメントレビューならドキュメントを事前に配布し、レビューアが査読をして質問をまとめて置き、レビューの会合の場ではその質問の回答を持って、レビュー結果、つまり、合格なのか、条件付き合格なのか、若しくは否認なのかを判定するのです。

彼のプロジェクトマネージャが書いたプロジェクト計画書を見ていて、どうも違和感を覚えて仕方がなかったんです。書かなければいけない項目はテンプレートとして用意されているのでそれを解釈して書いてもらうんです。で、当のプロジェクト計画書を読み進めてみれば、文書の構成の各章節項の標題に沿って書かれているところもあるし、そうでないところもある。違和感を覚えたのは標題で書いて欲しいことを掛けているところもあるのに、片や、標題に対する本文にあたるコンテンツが明後日の内容を書いているところもある、と言うちぐはぐな差異があるところ、なのです。

まぁ、人が書いたものですからね。その人の思考から選択された言葉の積み重ねがドキュメントですからその思いを上手に表現できる人もいれば、自分の想いを思考を表現しきれない人もいるし、表現することしない人も少なくないわけで。さて、このプロジェクトマネージャはどのタイプか、と。

全てをわかって行動することはない
ところで、エンジニアは設計書を書くにしてもプログラムを組むにしてもパラメータを設計するにしても、すべてをわかってそれを成すことはない、です。そのつもりだった、わかっていたつもりだったけれど、実際、文字に、文章に、図表にしてみたら全然わかっていなかった、書けない部分が出てきた、そこ抜けてた、なんて日常です。

実際、思考を目に見える形に置き換えて初めてわかるんですね。「それわかってなかったわー。」って。

仕事で求める、プロジェクトをやるにはプロジェクト計画書を書かさせる、そうしたことの背景にある意図は、実際に書いてみたり、作ったりするときに、それをするなり手がそこまで意識していない、ということを事象としてあぶりだしているのではないか、と。

その背景にある意図は、実際に頭を働かせて、手を動かして、形に見える形に変換することの経験を得ることでインタフェースを持つ他人に晒すことができ、意図を理解している他人が指摘することで初めて当の本人が認知し、学習する場を得られることで意識することが出来るのではないかと思いに至ったりしたんです。

こうした背景を認知させるためには、それなりの経験を経ないと背景を理解できないし、それを教えてあげられる側の人がそれなりにいないと誤解されたままで広まる危うさを持っていて、そうしたことを防止させるにはそれが出来る人を組織の中で継続的に育成するほかないのだけれど周りを見るとそれほどいない気がして少し途方に暮れるのです。

で、背景を説明するのだけれど、エンジニアって素直に聞くふりして聞き流して理解していなかったり、ムキになっちゃたりするところが面白い生き物だな、だなんて思っていませんから。