すっかり買ったまま仕舞い込んでいた『エンジニアリング統括責任者の手引き』を読んだ。
まず、”エンジニアリング統括責任者”ってなんだ？と思ったのだけど、CTOやVPoEなどの組織においてエンジニアリング領域に責任を負う立場、ということらしい。
とはいえ「自分はCTO、VPoEじゃないし...」と思う人の方が圧倒的に多いだろうけど、「ある日突然組織の外からマネジメントの立場で参画する」くらいの理解で読むほうが適切だし、マネジメント側に対する期待値コントロールとして、「このくらいの前提は持って参加してきてほしい」という時の参考書にもなる、そんな本です。
とにかく「2章 最初の90日間」がめちゃめちゃ良くて、これをしっかり読み込んで実践できれば、あとはやるべきことは自然と見えてくるはず。
中でも「2.3.3 組織の健全性とプロセスを理解する」は更に重要で、「既存のプロセスを文書化する」「実施する変更はせいぜい１つか２つにする」「次年度の組織の成長を計画する」「コミュニケーション経路を設定する」「組織内のプロダクト開発の役割以外にも注意を払う」「組織のインクルージョンを抜き打ちでチェックする」は、自発的にできる人も居ると思うけど、なかなか思い至らない人が多いのではないかと思う。
逆に、「2.3.1 学習と信頼関係の構築」の方は、そのポジションに就くほどの経験があれば上手くやっている人を周りで見かけてきていて、十分に参考にできるほどの知見が有るのではないか、とも思った（より上手くやる、というのはあるかもしれないけど）。
上手くマネジメントする人は驚くほど人の発言と、行動を観察しているものですよね。
マネジメント論の本は、技術書と違って「本に書かれている通りにやれば結果が出る」わけではないですが、プラクティスとして頭の中に入れておいた方がいいことが書かれています。それがどこまで上手くできるかは、マネジメント対象と、その関係性によって大きく変わるものなので、その見極めが大事ですね。あと、そもそもマネジメント本がいかに成功事例だったとしても、膨大な「書いていないこと」に真の成功の要因が有ったりしますしね。
