『エンジニアのためのマネジメントキャリアパス』を読んだ

更新が滞っていました。リハビリとして今日読んだ本の感想を書きます。

www.oreilly.co.jp

本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT業界の管理職に求められるスキルを解説する書籍です。テックリードからCTOになった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。

特段昇進を熱望しているわけではないですが、プロジェクト単位でマネジメントしたりメンター的なことをしたりする日々の中で、マネージャの視点を体系的に読めそう、読みやすそう、評判が良さそうな本書に手を出しました。テックリードから始まり、章が進むに連れて徐々に広い範囲の役職について言及され、最後にはCTO、そして組織文化のマネジメントまでと、マネジメントキャリアのラダーにそって書かれています。

原著者のCamille Fournierさんは、Rent The Runwayというアメリカのベンチャー企業のCTOです。今年春に大型の資金調達をしていました

感想

「いいマネジメントとはどんなものか」や「上位のマネージャが何を考えているか(考えるべきか)」の一例をみることができました。著者の過去の失敗を開示していて、理想論に閉じず、かといって個別の事象にもよりすぎず、一般論を現実的にわかりやすく説明されていました。訳も自然で読みやすかったです。

また、実際にマネージメントをする人に限らず、マネジメントされる側の視点においても、「なんとなくやりにくい」と感じてモヤっている人や、逆に「いまのマネジメントにまったく不満がない」という人こそ一読の勝ちがあるかもしれません。課題が言語化され、自分がパフォーマンスを最大化する環境について考えるきっかけにもなりそうです。

自分はまず技術をがんばりますという気持ちになりました。

技術だいじ

マネージャの職位があがるにつれ、勤務時間に占めるコーディング時間は減っていきます。それでもなお、あくまでエンジニアのマネージャであるかぎりは小さくともコードを書き続けるべきだとし、また技術力不足でキャリアが頭打ちになるケースを実体験として挙げています。「まだ早いと思うなら引き受けるな、技術に専念せよ」という旨まで書いてあります。

職位が上がる、つまりマネジメントする対象が広がるに連れて、課題に対する抽象度が上がり、意識すべき責任範囲が広がるということです。技術に関する知識・理解の深さと対立するものではなく、(自分の体感としても)正の相関に近いのかもしれません。

オープンドアより1on1

メンバーとマネージャの間で、プロジェクトあるいはその他の相談、質問、議論のインターフェイスとして、オープンドアと1on1を対比して後者を推しています。オープンドアというのは、「いつでもなんでも聞いてOK」と門戸を開いておくスタイルで、1on1は、定期的にミーティングを設けるスタイルです。

オープンドアは一見なんとなく良さそうですが、エンジニアも人間なので、上司にネガティブな話をするのは心理的負担が少なからずあります。プロとして必要ならやるべきという考え方もあるかもしれません。でも、心理的負担は小さいに越したことないです。

三大美徳

エンジニアならだれもが知る、Larry Wall大先生が唱えた三大美徳「怠惰」「短気」「傲慢」についてです。これらがマネジメントにおいても有効だと説明されています。もちろん「短気=すぐに怒る」みたいなことではないです。プロジェクトに対して、「なるべく楽に、速く終わらせるにはどうすればいいか?」という視点を持つべきです。

行動規範として皆さんに今すぐ実践してほしいのが「今すぐ重要なことを見極める」と「帰宅する」なのです。(p.160)

パワープレイで問題を解決しようとしたり、考える前に行動して時間を無駄にすることは、当人にとってもマネージャにとっても会社にとっても望ましくないです。勤務時間という制約の中で最大の成果を出すことを目指し、そのために考え抜くのが知的労働におけるプロフェッショナリズムといえます。

好奇心を大切に

本書では一貫して、「好奇心を持て」と説かれています。「本書を通じて」というところが重要で、メンター、テックリードからCTOに至るまで、(少なくともエンジニアに対する)マネジメントのあらゆるフェーズで、好奇心が価値を持つとのことです。

メンターは、メンティーをサポートする立場ですが、逆にメンティーの視点を通して世界をみることで好奇心を刺激してもらう機会でもあります。メンティーの悩みをとおして組織の課題に気づいたり、質問をとおして自身の理解不足に気づくかもしれません。また、テックリード以上の職位においては、ある技術領域において自身よりもメンバーのほうが深い知識を持っていることが往々にしてあります。その場合に理解を諦めるのではなく、メンバーに時間をとってもらって教えてもらうなどでプロジェクトの計画精度を高めると同時に、エンジニアとしての成長機会にもなります。

参考

ググるといい書評がいっぱいでてきたので貼っておきます。このへんをみるとだいたい内容はわかります。さらに気になったら本を読んでみるといいと思います。