エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

著者 : James Stanier 吉羽龍太郎 永瀬美穂 原田騎郎 竹葉美沙

• オライリージャパン (2022年8月26日発売)

感想・レビュー・書評

[funkybearさんの感想 · 2023年1月21日]

具体的で非常に良い。マネージャーとしての基本動作に加え、1on1や評価、採用といったピープルマネジメントの具体論を紹介。3部では、やや抽象度を上げてチームやPJのマネジメントやキャリア論にも言及。マネージャーになった時の教科書として使えそう。

EMの4要素として捉えているマネジメント領域

1 テクノロジー
2 プロジェクト
3 ピープル
4 プロダクト

のうち、3のピープルマネジメントと、EMとしての基本動作に重きを置いている。それ以外は当然ある程度IC時代にやってるっしょ、という事と理解

[ponta027さんの感想 · 2023年1月7日]

感覚的に実践していた内容が明文化されているため、読みながらそうそうって思える部分はあった。

マネージメント自体はマネージャーだけが実践するものではなく、日々の作業の中で必ず出てくるものなので、エンジニアであれば読んでおいて損はないのかなと思う。

[masterkaさんの感想 · 2023年1月3日]

感想は以下
https://blog.masterka.net/archives/3850
https://blog.masterka.net/archives/3856

[Yamamoto Yuichiroさんの感想 · 2022年12月21日]

エンジニアリングマネージャーに特化してるが、エンジニアリングに限らず適応できる。ただ、文脈はエンジニア経験者でないと分からないことも多い。
本文でターゲットにしているような新任のマネージャーではピンと来ないかもしれない。何周かマネジメントしてみて、自身の振りかえりと次の次元に進むヒントを得るのに有効ではないか

[bob-taniさんの感想 · 2022年12月13日]

これ一冊でいいと思える内容。
実践的なので試しやすい。
特に1on1の言語化はそのまま使えるのでまずは対話しようとなる。

[hiro8maさんの感想 · 2022年11月10日]

自身もマネージャーとして意思決定や責務を果たすために四苦八苦していたが
例えば委譲に関する記述でメンバーに自分の責任の範囲を委譲したいとする時、委ねた範囲の責任はいったい誰のもので何なのかと考えあぐねていたがマネージャーの責務として「タスクの実行責任を他の人に託しつつ、説明責任を持ち続けること」といつ記述がありもやっとしていた気持ちがスッキリした気がする。
実践方式で読み進めることができ大変参考になった。

[kyosawaさんの感想 · 2022年10月24日]

・P10：作り手のスケジュール、マネージャーのスケジュール
http://www.paulgraham.com/makersschedule.html
典型的には、マネージャーのカレンダーではスケジュールが1時間単位で組まれるのに対して、作り手は半日単位でスケジュールを組むのが一番生産的になります。作り手の仕事というのは難しいもので、生産性を上げるには時間がかかるからです。
〜中略〜
ミーティングを組むときは、それ以外の時間でスタッフが集中し生産的になれるような時間帯にしましょう。

・P27：2.2 活動を分類して生産性を高めるには
この問題に取り組む彼(Intel創業者 アンディ・グローヴ)のアドバイスは、日々取り組んでいるマネジメントの活動を4つのバケツに分類することでした。
https://www.amazon.co.jp/dp/B01MU055XH
　1. 情報収集
　2. 意思決定
　3. ナッジング(議論に対して自身の観点を提供することで、決定に影響を与えること)
　4. ロールモデル

1日の活動をこれらの分類に当てはめると、あなたがもともと思っているよりも、仕事には意味があると気づくはずです。

・P31：2.3 マネージャーとしてのアウトプットを測るには
マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット

・P43：3.1.1.3 2回測って、1回切る
「2回測って、1回切る」という大工のことわざがあります。木材は切ったらやり直せないので、切る前に正しいことを確認したいと考えます。失敗したら、目的を果たせなので、最初からやり直しになってしまいます。

コミュニケーションも同じです。マネージャーの言葉には重みがあります。フィードバックと受け取られることもあれば、命令と受け取られることもあります。そのため、情報を発信する前に2回考える必要があるのです。

・P50：3.2.2 説明責任は委譲できない
うまく委譲するために必要なのは、説明責任と実行責任の差を理解することです。
説明責任：タスクを求められる品質で完了させる責任を持つということ
実行責任：タスクを実際に自分で行うということ
〜中略〜
CEOは会社の技術についての説明責任は負いますが、実行責任はCTOに委譲しています。組織図を見ていくと、CTOは組織のさまざまな部門をバイスプレジデント(VP)に委譲し、VPはエンジニアリングマネージャー(EM)に、EMはエンジニアにそれぞれ委譲しています。

・P52：3.2.4 委譲でやるべきこと、やってはいけないこと
やるべきこと
- 委譲すること
- スタッフにとってチャレンジになるくらい委譲すること
- タスクの重要性に応じて適切なコントロールを保持すること

やってはいけないこと
- 丸投げ
- 他の人のやり方が自分と同じであることを期待すること
- 渡したタスクを取り返すこと

・P65： 4.3 コントラクティング：最初の1on1
スタッフとの新しい関係が間違った方向に進んでしまうリスクを回避するのに便利なエクササイズがあります。これを使えば、両者がお互いに期待していることを率直に話試合、この関係性に求めるものや必要なものを明確にできるようになります。このエクササイズはコントラクティングと呼ばれます。

・P65： 4.3.1 コントラクティングとは何か？
コントラクティングとは最初の1on1で扱う単純な質問一式で、あなたと部下が期待することについての会話を誘発するものです。両者から期待することを出します。このエクササイズにより、お互いのニーズを構造化された安全な方法で話せるようになり、率直で透明性の高い会話ができるようになります。
　1. 一番サポートが必要な分野はどこか？
　2. どんな形でフィードバックやサポートを受けたいか？
　3. 一緒に働く上での問題は何か？
　4. 私のサポートが上手くいってないことはどうすればわかるか？
　5. ミーティングの内容の機密性はどれくらいか？

・P71：4.4.4 (1on1の)会話の話題のアイデア
- アーキテクチャの深掘り
- プロセスの深掘り
- 自分が読んだ関係しそうな記事
- ティーチング
- 部門や会社の方向性
- フィードバックの収集
- 自分が取り組んでいるタスクの共有

・P77：5.1何が人を動かすのか
・P78：5.1.2 仕事の役割
マズローのモデルに立ち返り、あなたが働く日々に照らし合わせてみましょう。
生理的欲求
　自分がしたことに対する適正な額の給与をもらい、妥当な手当が欲しい。
安全欲求
　安定した仕事と安全な労働環境が欲しい。
愛と所属の欲求
　好きな同僚や刺激を与えてくれる同僚と働きたい。チームや上司と良い関係を築きたい。
承認欲求
　フィードバックを通じて非公式にも、職位と昇進を通じて公式にも、両方で自分がしたことを評価してもらいたい。
自己実現欲求
　成長と自分のスキルを継続的に広げていくために挑戦していきたい。キャリアにおいて常に次に進めるところがあると感じていたい。

・P95：6章 1年でいちばん輝かしい季節
評価面談が好きな人なんてほとんどいません。欠かすことはできないけれど嫌なものです。とはいえ、嫌かどうかはさておき、パフォーマンスを上げている人をさらに成長させ、パフォーマンスの上がらない人を軌道修正するには、絶好の機会なのです。
　1. 迷信退治
　2. 準備
　 - 面談用ドキュメント
　 - ピアフィードバック
　3. 当日やること
　4. お金の話

・P274：15章 デュアルラダー
本章では、あなたとチームに役立つキャリアアップのフレームワークを作ることで、この危機に取り組むことが狙いです。以下のことを学びます。
　・P275：15.1 インディビジュアルコントリビューター(IC)トラック
　・P277：15.2 マネジメントトラック