はじめに

以前のエンジニアマネージャーが退職されるのに合わせて、私がエンジニアリーダーとして開発のリードを任されることになりました。

リーダーを務めるのは今回が初めてだったので、何かしらの参考文献を読んでおこうと思い、手に取ったのが

『エンジニアリングマネージャーのしごと』

という本です。

思いの外この本に助けられる場面が多かったので、参考になった部分を備忘録としてまとめておきます。なお、この本では主に「マネージャー」を主語に書かれていますが、リーダークラスにもかなりの部分が適用可能であると感じています。

私のような新人エンジニアリーダーの方の参考になれば幸いです。

本書の概要

本書は、

マネージャーに興味がある人
マネージャーになったばかりの人
既にしばらくマネージャーをしている人

にとっての実践的なガイドを目指して書かれています。

各章の導入はストーリー仕立てになっており、マネージャーとしてしばしば直面する問題が描かれています。その後、その問題に対してどのように対処するかが解説されています。

この本の著者自身も、マネージャーになった当初、さまざまな文献にあたったそうです。しかし、「明日自分は何をすべきなのか」を提示してくれるものが見つからなかったために、そういった文献へのアンチテーゼとして、本書が執筆されたそうです。

実際に読んでみると、理論的な用語は登場しつつも、あくまで実践としてそれをどう活かすかに軸足が置かれており、具体的なアクションに結びつけやすいと感じます。

全体的なノリとしては、オライリーから出版されていることもあり、英語原著の技術書に近い文体です。海外の大学の教科書にも近いものを感じます。そういった文献に馴染みのある方であれば、読みやすいと感じるのではないでしょうか。

内容の備忘録

ここでは、私が実際に読み返している箇所をピックアップして取り上げます。

目次や細かい章立ては省略するので、オライリーのサイト等で確認していただければと思います。

第I部オリエンテーション

この部は主に、マネージャーに就任した直後にやるべきことが書かれています。

認識の相違 (1.2.4 自分のスナップショットを作成しよう)

このベン図は、「自分」「上司」「チーム」の三者の認識の差異を表したものです。

マネージャーというポジションは、チームを率いる存在であると同時に、上司との橋渡し役でもあります。

上司に何を伝えるべきか・上司と何を議論すべきか
チームに何を伝えるべきか・チームと何を議論すべきか

リーダーとしてこれらを決める上で、それぞれの立場の認識の相違を整理するこのベン図は有用でした。

タスク管理（2章自分を管理しよう）

いわゆる「タスク管理」だけに1つの節が割かれています。初めて読んだ時は少し意外でしたが、リーダーとして仕事をしていく上で、この重要性をすぐに認識しました。

リーダーという仕事は、マルチタスクを求められます。単に抜け漏れをなくすメモというだけでなく、優先順位を検討する上での重要な判断材料になります。

本書で取り上げられるのは、

カレンダー: 時間を管理する
ToDoリスト: タスクを管理する
メール: 受信したメッセージを管理する
情報を記録する場所: 上記3つの補完

の3 + 1つのツールです。

詳細については本書を読んでもらうとして、以下に重要・面白いと感じたものをいくつか抜粋します。

抜粋

カレンダーをTodoリストとして使うな
集中する時間もカレンダーの予定に入れろ
タスクは全てToDoリストに書き出せ
ToDoリストにないタスクはやるな
メールは絶対に削除するな
メールはまとめて確認しろ（非同期で利用しろ）

活動を分類する (2.2 活動を分類して生産性を高めるには)

プログラマーであれば、「このコードを書いた」と自分の活動を明確にすることができます。しかし、マネージャーとなると、その活動を測りにくいと感じがちです。

そこで、本書ではマネージャーの活動を以下のように分類することを勧めています。

情報収集
意思決定
ナッジング
ロールモデル

1つ目の情報収集とは、社内外あらゆることに関する情報を蓄積することです。この情報をもとに、2つ目の意思決定を行います。
3つ目のナッジングとは、議論に対して自分の観点を提供し、意思決定に影響することです。重要なのは、マネージャーの意見には権威が伴うということです。スタッフや上司を誤った意思決定に導かないよう、このことを念頭におく必要があります。
4つ目のロールモデルとは、チーム像を体現する存在になるということです。スタッフに対して「こうしてほしい」という基準を示すには、マネージャー自身がそれを実例で示すのが最も効果的です。

自分の1日の活動をこれらに分類することで、マネージャーとしての活動を明確にし、改善に繋げることができます。

マネージャーとしてのアウトプット (2.3 マネージャーとしてのアウトプットを測るには)

マネージャーとしてのアウトプット =
あなたのチームのアウトプット + あなたが影響を与えたチームのアウトプット

この定義は、私自身の認識を大きく変えました。

マネージャーとしてのアウトプットは、自分自身で何を成したかではなく、チームとして何を成したかだということです。メンタルモデルとして、このシンプルな式は常に私の頭の中心にあります。

第II部個人と働く

この部では、マネージャーが担う基本的な役割について取り上げられています。

委譲とは何か (3.2.3 委譲の物差し)

完全な委譲（相手がやる）
終わったら相手が知らせてくる
相手が行い、自分がときどきチェックする
相手が行い、自分が頻繁にチェックする
相手が行い、自分がガイドする
自分がやり方を示す
委譲なし（自分でやる）

上に行くほど委譲の割合が増え、下に行くほどコントロールの割合が増えます。

このように、委譲には段階があります。相手の能力やタスクの難易度に応じて、適切な委譲の段階を選択することが重要です。

マネージャー自身で全てを巻き取ってしまったり、あるいはスタッフに丸投げしてしまうのは、どちらも委譲のアンチパターンです。

説明責任と実行責任 (3.2.2 説明責任は委譲できない)

うまく以上するためには、説明責任と実行責任の差を理解することが重要です。

タスクに説明責任があるとは、タスクを求められる品質で完了させる責任を持つということ
タスクに実行責任があるとは、タスクを実際に自分で行うということ

マネージャーは、実行責任をスタッフに委譲します。しかし、説明責任は委譲できません。例えば、サービスのシステムに障害が発生した際は、その対処の陣頭指揮は、マネージャーが責任を持って行う必要がある、ということです。

1on1の重要性 (4章 1on1)

1on1の重要性は、本書でも強調されています。スタッフと関係性を構築し、そしてモチベーションを上げるための活用法・注意点が述べられています。

1on1は、スタッフのために行うものである
スタッフの頭の上に思考のフキダシを浮かべておく必要がある
会話を誘導したり、意見を述べるのではなく、スタッフの話を理解する
時には沈黙も重要
- スタッフが自分の考えを整理する時間を与える
セラピストではないことを忘れない
- 必要な場合は、適切な専門家に繋げる

第III部全体像

この部では、組織全体から見た時のマネージャーの役割について取り上げられています。また、マネージャーとしてのキャリアパスなどの細かい話題もこの部で取り上げられています。

詮索されたり、審判されたり (10.1 詮索と審判)

この章では、マネージャーとして詮索されたり、審判されたりすることについて取り上げられています。

内容の要約については、私自身が噛み砕ききれていないために省略します。折に触れて読んでいる最中です。

個人的には、こういった内容がエンジニア向けの書籍で章を割いて取り上げられていることに少し驚きました。一方で、マネージャーやリーダーとして働く上で、このようなことに直面することは避けられないと感じています。

感情的にではなく、冷静に対処するためのメソッドとして、この章は今後も読み返すと思います。

ダニング=クルーガー効果とインポスター症候群 (10.4 馬鹿の山)

ダニング=クルーガー効果: 人が自分の能力を過大評価する傾向
インポスター症候群: 人が自分の能力を過小評価する傾向

それぞれ、人間が陥りやすい認知的なバイアスです。この章では、この2つのバイアスに陥っているスタッフに対してどう接するかが取り上げられています。

85%ルール (13.2.3 自分のキャパシティを賢く使う)

仕事は、キャパシティの85%くらいにコミットする
- 追加の仕事や、上司からの依頼、スタッフのサポートに対応するためのバッファを確保する
キャパシティぎりぎりで働いているマネージャーは、チームの弱点になる

おわりに

『エンジニアリングマネージャーのしごと』という本の内容を備忘録としてまとめました。

リーダーという仕事は、さまざまな苦労があります。一方で、自分の意思決定によってプロジェクトが前に進んだり、スタッフの成長を見ることができるのは、とてもやりがいを感じます。

この本は、そんなリーダーとしての仕事を、より良く行うためのヒントを提供してくれるものです。今後もこの本を読み返して、リーダーとしての自分の仕事を改善していく所存です。