オライリーの「エンジニアリングマネージャーのしごと」という本を読んだので、重要だと思った部分を章ごとにメモしておきます。
要約
1章 最初の仕事
- 最初の章はマネージャーとして仕事を始める時にやることについて書かれていた
- 1on1 を通してメンバー・上司を知ろう、というのが主な内容
- それによって上司・メンバーとしか共有できていない、または自分しか気付けていない考えや認識を整理し、何に取り組むべきを明確化できる
2章 情報・仕事の整理
- 前半は情報の整理に関して書かれていた
- 具体的なテクニックとして、カレンダーは MTG や私用、作業時間のブロックのためだけに使う
- 周期的に発生するタスクはカレンダーに入れず、TODO 管理のアプリを使う ( Asana など)
- 後半はマネージャーの仕事に関する重要な話が書かれていた
- マネージャーのアウトプット = 自チームのアウトプット + 影響を与えた他チームのアウトプット
- マネージャーの仕事は情報収集・意思決定・ナッジング (議論に自身の観点を共有すること)・ロールモデルに分類される
3章 コミニュケーションについて
- 前半は相手に合わせるとか、感情に左右されないとか、マネジメントに限らず一般的な話
- マネージャーは求められる品質でタスクを完了させる責任 (説明責任) は負うが、実際の作業 (実行責任) は負わない
- 上司と自身のパフォーマンスが何で、それがどう計測されるか決めておく
- 上司に 1on1 の中で色々と質問をすることは、1つ上のレイヤーの視点が得られるし、影響の範囲を広げられてキャリアアップにもつながる
- 逆にチームの状況を毎週知らせることも大事
4章 1on1
- 初回1on1では、両者が互いに期待することを明確化する
- どういうサポートが必要か、一緒に働く上でどういう問題があるか、などを話し合う
- 基本的には質問から相手の話を引き出して、問題を発見する
- 自分のタスクの共有などもアリ
5章 割り振るタスクについて
- 人に合った仕事を提供することが大事
- ちょうど良い難易度のタスクを提供する
- 「発達の最近接領域」について触れられていた
- 最終的な目標からの逆算でタスクを与える
- 「伽藍とバザール」について言及しつつ、安定した環境がいいかカオスな環境の方が良いかの話が書かれていた。どちらを望むかは人によって異なるし、割り振るタスクも変わってくる
6章 評価面談
- 評価面談は両者がパフォーマンスについて考える場で、それまでにも定期的にパフォーマンスについて話すことが大事
- 先に面談用の資料を埋めておく
- 昇給に関しては別の機会に伝えて、不満があるなら将来の話に繋げるのが良い
7章 採用に関して
- 採用は、どういう人員が必要か考え直す良い機会
- シニアを雇えば良いというものではない。衝突を生むことも
- 一次面接で技術課題を解いてもらう、ただし試験のような雰囲気にしない
- 一次面接であらかた決める。微妙なら通さない
8章 離職に関して
- 残ってほしいが、出て行ってしまう人の話がメイン
- チーム内での問題やキャリアアップに関する認識のズレなど、1on1などで信頼関係を構築できれば、ある程度は防げる
- 辞めさせたい場合はPIP (業務改善計画) を使う
- これは日本の場合は関係ない話かも
9章 社内での人間関係について
- 社内でネットワークを構築することで、効果的な仕事ができたりキャリアップにつながったりする
- 後半はメンタリングとコーチングについての話。コーチングでは指導だけでなく、相手に質問したりして聞き役になる
- GROWモデルが紹介されていた
10章 社内での衝突について
- 部下からは詮索・批判にさらされるもの。全てを掘り下げる必要はない
- 上層部の混乱を吸収して下に伝えるのはマネージャーの仕事
- チームのアウトプットが少ないのは、期待が非現実的だったり運の問題だったりがほとんどで、チームに問題がないことが多い。
- アウトプットを出させたいなら、自律的に働かせること、スキルアップにつながると感じさせること、仕事の意義 (社会への影響) を感じさせることが大事。もっと働けと言ったところでモチベーションは上がらない
- ダニング=クルーガー効果 (自分が実際より有能に感じること)・インポスター症候群 (前者の逆)はよく発生する
- ペア作業や議論を通して気づかせることが大事。
11章 重要で締切がタイトなプロジェクトの話
- 進捗を共有してフィードバックを求める。細かくリリースすることも大事
- プロジェクト後に時間的ゆとりを与えて、技術負債の解消や学習に充てる
- その時間を取れるようにマネージャーが戦わないと、離職などにつながるだけ
- 会社が大きくなると生産性が下がるのは仕方ないが、原因 (単純なタスクでも、それによって難度が上がる理由など) は説明できるようにすべき
- 2割程度を技術負債の解消に充てる、というのも解決策
- 締切が迫ってスコープを落とさないといけないことがある。事前にタスクを分解して優先度をつけておくと良い
- 作業の並列性を確認しておくことで、人員の追加により早くできるか判断しやすくなる
12章 社内の情報などに関して
- 情報は存在自体を知られてはいけない、存在は知られても良い、中身も公開で良い、に分けて扱うことが大事
- 後半は社内政治の話。個別最適的に動く個々を利用して全体最適を目指そう、という話
13章 タスク管理に関して
- コントロールできるもの、できないもの、ある程度できるものの3つに分ける
- 最後がマネージャーにとって重要。内部ゴールを設定するのが良い
- 内部ゴール = 置かれている環境で現時点のベストを尽くすためのもの
- 例 : 転職を思い止まらせたいと考えているなら、これは外部ゴール。そのために居心地の良い環境を作ることが内部ゴール
- 何もしない時間を作る。このとき思いついたことは書きとめるだけにし、あとで考える。
- マネージャーは緊急時に急にリソースを奪われることもあるので、できると思う仕事量の85%程度を引き受けるのが吉
14章 情報の共有について
- 必要な知見がチーム間、メンバー間で共有されていない、というのはよくある問題。車輪の再発明のような事態も発生する
- チームが機能ごとなら、チーム横断の、技術的に同じ関心を持つグループ (ギルド) を作る
- コーディングやUIの統一性を持たせる、などの効果が期待される
- マネジメント側への意見を誰でも匿名で書けるような場所が必要
- チーム状況 (コードの健全さ・開発プロセス・楽しさや学び・サポートが得られているか等) を定期チェックする。他のチームとも比較してみる。
15章 キャリアアップの話
- マネジメントとインディビジュアルコントリビューター (IC) の2つの方向がある
- ICは開発者。高い質のコードを書くことに加え、メンターとしてもスキルが高かったり、周囲に受け入れられるような提案をしたりする。
- また再利用可能なコードの開発によって開発速度を上げたり、速度改善やアーキテクチャの作り直しなどの大規模な開発により、ビジネスの損益に直接的に影響を与える。
- キャリアアップ表の例の紹介があった (p.280)
- これだけで昇進の判断をするものではなく、キャリアアップに関する会話を行うための手引きであるため、項目は主観的なもので良い
16章 ダイバーシティー・リモートワークの話
- 特に面白い話はなかった
17章 スタートアップでのマネージャーの仕事
- スタートアップでの最初のマネージャー (VPoE) の仕事は、エンジニアの評価や採用。リソース配分に加えてコードを書くことも
- 小規模な組織でも、どんどん開発をするだけだと将来的に破綻するので、スピードのバランスを取ることが大事
- そのためマネジメントのスキル (この本に書かれていたような知識) は小規模な組織でも重宝される
18章 キャリアに関して
- 10年後の理想を考えて、そこから逆算でやることを決める、といった内容
- 仕事に関して、何を楽しいと思ったが、何が嫌だと思ったか考えるのはヒントになる。また仕事のことに限らず、色々な視点で想像する
感想
自分は今はマネージャーではありません (リーダー業務をやるという話はある) が、マネージャーが実際にどういう仕事をすれば良いのかを中心に書かれていたので、マネージャーの仕事に対する解像度が高くなって良かったです。
マネージャーって実際何をしているんだという疑問が正直あったのですが、これは2章にあった仕事の分類を読んで理解ができたと同時に、これを意識して動けるかでパフォーマンスは相当変わってくるだろうなと思いました。
また10章の「アウトプットを出させたいなら、自律的に働かせること、スキルアップにつながると感じさせること、仕事の意義 (社会への影響) を感じさせることが大事」という内容は強く印象に残りました。なぜなら、今の会社が実際にそうはなっていないからです。
マネージャーになる前からでも、彼らに働きかけてそういう組織へと変えていくことはできます。そういう動きはしていきたいなと思いました。
また最後の章、これは仕事に関する話というより人生そのものに関する話かもしれないですが、将来からの逆算で動く、という考えは自分には足りていないなと思いました。もっと将来の理想の解像度を上げていきたいと思いました。
