「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」を読んだ
「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」を読みました。
厳密には原著の "Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs" を読みました。
英語 & 厚めの専門書ということで少し読むの時間かかりましたが、良書でした！
個人用のノートはガッツリ Notion で取っていて公開予定はないのですが、
- エンジニアリングマネージャーの主な責任 (Accountability & Responsibilities) は何か
- エンジニアリングマネージャーとして働き始めたけど IC*1 時代と違って成果を出してる実感がない
- エンジニアリングマネージャーとして必要になるスキル
について一通り知りたい人は目を通してみると良いと思います。チームにエンジニアリングマネージャーが居らず採用を検討している人もオススメです。
内容はソフトウェアエンジニアリングに限定した話だけではないので、どなたでも読み進めることができます。
本に直接書かれているわけではありませんが、EM の強めの定義や弱めの定義という言葉に対する、統一的な定義を個人的に言語化できたが良かったです。
このあたりの情報の、点と点が全てスッキリつながった、というとわかっていただけるかと思います。
これについては別のブログでまとめたいと思うのでここでは深くは言及しませんが、鍵はオーナシップ、アカウンタビリティ、レスポンシビリティ、そして権限移譲です。 マネージャーはチームがオーナシップを持つもの全てにアカウンタビリティを持ち、どのレスポンシビリティを移譲するかによってチーム構成と自分に残るレスポンシビリティが残る、という感じです。そしてこのチームがオーナシップを持つものと、移譲できるレスポンシビリティは組織やチームによって異なるので、必要なスキルセットは組織によるため、同じエンジニアリングマネージャーでもレスポンシビリティが様々、ということです。
これを軸にすると、なぜ 1on1*2がマネージャーとして最も大切な日々の活動の一つなのか、チームのビジョンやゴールを設定することの重要性など、様々なことが線でつながると思います。
もう一つ抜粋しておきたい内容としては、マネージャーの日々の活動のカテゴリです。
IC 時代と違って成果を出せてる実感がないときは、チームのアウトプットが自分の主なアウトプットだと理解したうえで、日々の行動を以下に分類すると、自分がマネージャーとして仕事をしている（もしくはしていない）か客観視することができます。
- 情報収集
- 意思決定
- 他者の意思決定への貢献
- ロールモデルとしての行動
最後に付け加えておきたいことは「マネージャーの真価は悪い状況でほど問われる」ということでしょうか。
簡単な状況や良い状況では誰しも比較的うまくやれるものですが、難しい状況や悪い状況では如実に差がでる、というのはその通りだと思います。
良い本だったので、ぜひご一読ください！
