題名の本が気になっていたが、中々入手する機会がなく、先日、ようやく入手し、読み終えた。
感想としては、納得する部分半分、納得できない部分半分、といった所だ。
まず、納得できる部分としては、個人としてのエンジニアの振る舞いにある。
物事を注意深く、納得して理解すること（説明可能、実行可能、応用可能）や、必要以上に作り込まず、怠惰であることを求めることは、個人として納得できる部分である。
人によっては、てにをは の間違いを指摘したり、必要以上に書面を拡充することに心血を注ぐ場合もあるが、個人的には、第三者が見て、必要十分の情報があれは、書面としては問題ないと思う。
この点は、私も通常業務で取り入れている内容であるし、今後も継続したいと思う。
納得できない部分としては、チームとしての書面の管理だ。
著書の中では、エンジニアの仕事に書面の管理は含まれておらず、日本のように、エンジニアが自ら執筆し、大量の書面を残す必要はない、と記載されていた。
確かに、作成した製品（ハードウェア、ソフトウェア）に関して、作成したエンジニアが、自ら別枠の時間を設けて、書面を作成することは、仕事量として、非常に負荷がかかる。
しかし、何十年も維持、保守することが想定される、社会インフラ（発電所、水道）の場合、同じ担当者がそのまま同じ製品を対応していることは少なく、新たに担当になった者は、書面を読み込み、製品の全体像を把握することになる。
その書面が無いとなったとき、新たな担当者は、どこからその製品を理解したらいいのだろうか。
この本を読んでいて、背筋が凍る思いがした。
個人的な解決策として想定できるのは、社会インフラの場合、エンジニアの他に、技術文書を記載する専門部署を設けて、書面に関しては、その専門部署で一括することかと思う。
批判的な事を書いたが、本書で書かれていることは、一読の価値はあると考えている。
コメント