エンジニアリングマネージャーのしごとを読んだ

2022-10-21

自分は、エンジニアリングマネージャー（以下EM）ではないし目指しているわけではないけど、年齢的にも読んでおいた方が良いかなと思ったので読みました。

一言でいうとこれからEMになる人に取っては、心構えができるというか準備ができるいい本でした。自分もリードエンジニアっぽいポジションにはいるので共感する部分もありました。

特に印象に残ったものを紹介します。

委譲の難しさ

EMになれば、タスクをエンジニアにお願いすることになりますが、それ例外にもEMはハードワークになりがちで割り込みも多いです。可能な限りタスクを他の誰かにお願いするべきですが、この委譲の仕方がめちゃくちゃ難しいです。丸投げにしない程度にいい感じで、タスクを渡す方法を迷ったりすることもあります。

本書では、委譲の物差しが掲載されており、委譲した後に自分がどう関わるかを段階によって分けていました。「このタスクは、サポートが必要だから時々自分がチェックするか」「このタスクは、この人だったら前やったしアウトカムもいいから自分のサポートはいらないか」と言った具合です。結局の所メンバーの状況やスキルなどを把握した上で整理して委譲するということです。

またやってはいけないこととして、「一度お願いしたタスクを取り返すこと」が書かれており、学習の機会を与えるのもEMの仕事というのは確かにと思いました。

自分のコントロールではないものへの不安

コントロールの三分法というのがあり

コントロールできるもの。自分たちの願望やゴール
まったくコントロールできないもの。天候など
ある程度コントロールできるもの。テニスの試合に勝ちたいのような願望

というのがありEMに取って大事なのは、ある程度コントロールできるものということです。コントロールできないものについては結果について心配しないという整理にすることで平静を保ち、「ある程度コントロールできるもの」については、「内部ゴールを設定してベストを尽くす」ことでコントロールを分類するのが大事ということが、書かれておりなるほどと共感しました。

自分は、結果については全体的に振り返りしたいタイプだったのですが、コントロール自体を先に分類しておくことで心配しないようにすれば、本当に振り返りが必要なものが見えてくると本書を読んで感じました。

自己管理

EMは全体のキャパいっぱいまで仕事を埋めてはいけないという話で、これは納得というか共感する部分でした。

自分も仕事する時に、稼働を100%以上にしてしまう癖というか業務時間に仕事がないのはあまり好きではない人間なのでキャパを埋めたがる傾向にあります。しかし、最近やっと「非効率だ！」ということに気づき次から少し余裕を持って何か緊急対応や突発的な仕事に身体を空けておくことに決めたので本書には完全に同感です。精神的にもいいはずですし…

そもそも複数のプロジェクトのリードするのってかなり高度なことだと思うので、うまくバランスを取らないとメンバーにも迷惑をかけることにもなりますからね…

アウトプットをどう見せるか

EMのアウトプットってエンジニアみたいに成果物が見えにくいとずっと思っていたのですが、言語化というか方程式が書かれていました。

マネージャのアウトプット = あなたのチームのアウトプット＋あなたが影響を与えた他のチームのアウトプット

まさにそうだなと思いました。エンジニア個人個人の頑張りも当然ありますが、チームで開発しないといいプロダクトは作れないと思っているので、この方程式は頭に刻んでおきたいです。

他にも、以下のように色々いいなと思うことがあったので、箇条書きで紹介します。

マネジメントバグを解消するために目安箱を用意する。この目安箱はすべての人が閲覧、書き込みができるので透明性を保つことができる
コーチングは答えではなくその人の方向を誘導するものである
1on1などで、相手がしんどそうな時は決してセラピー的なことはしていけない（EMはセラピストではないので適切な産業医などに相談を促す）

ギルドを作ったりすることで関係性を構築したり、採用についてもフレームワークを使って効率化するなど今の業務に関連する内容もあったので実践できる箇所は、実践してみたいと思いました。