エンジニアリングマネージャー（以降、EM）になって2年目。振り返ると、マネージャーを目指していた2年前の自分は、この役割について多くの誤解をしていた。特に
- マネージャーもコードを書くべきだ
- マネージャーはチームの全てを知る必要がある
- 改善する施策は自分1人でリードしていく
という3つは少なくとも僕の経験では誤解で、自分のマネジメントスキル成長を阻害する大きな誤解だったと感じる。この記事ではこれらの誤解について振り返り、自分が実施してきた施策について2年前の自分に伝えるように書いてみようと思う。
「コードを書き続ければ成果が出る」と思っていた
誤解
あなたはマネージャーになったら上司にこう言われる。
「EMにはエンジニアリングという言葉がついている。だからコードを書くのをやめてはいけない」
これを「これまでと同じようにコードを書くと良いんだ！」と誤解してはいけない。コードを書くのは楽しく、修正するとすぐその結果がわかる。問題を解消してきた実績や経験がある。
一方、組織の問題は解消方法が明確ではなく、成果が出るまで時間がかかる。そのため、マネージャーになってすぐ「成果が出せていない...どうにかしないと...」と焦る期間があった。「とりあえず今の自分にできることは何か？」と焦り始め、機能開発や改善のPRをたくさん出しスプリントゴールを達成することで「今週も頑張った」と自分を納得させようとしていた。
その結果、最初の評価で「あなたが成果としてあげたことはは自分がやったことで、チームで達成したことでは無い」というフィードバックをもらうことになる。
気づいたこと
中々成果が出ない問題から目を背けて短期的な成果を出すためにコードを書くことに逃げるのではなく、未来の問題に正面から向き合ってみる時間を作ってみることも必要だと思う。
施策
例えば、上司との1on1の時間を週1回など、頻度高く設定する。そうすると強制的にチームのことを思考して、アウトプットする機会が得られる。
「忙しくて思考する時間がない」ということであれば、1週間に1時間で良いので、思い切って「チームのことを考える時間」をカレンダーに登録する。
そのように視点を組織に向けさせるような時間を強制的に作ることはコードを書くことに逃げることを回避する施策としては効果的だった。
マネージャーは「全てを知らなくて良い」
誤解
あなたはマネージャーとして「チームを適切にリードするためにはチームに関連することは全て知っておく必要がある」と思い、Slackを常に監視し続けるなど、情報収集を常におこなってきた。
しかし、全ての情報を把握しようとすると幾ら時間があっても捉えきれず、更に情報が自分に集約されることで自分とのミーティングやコミュニケーションが多くなることで、自分が稼働していない場合に自分がボトルネックになり、自分も業務が進まず、メンバーも業務が進まないという悪循環を経験した。
気づいたこと
そもそもチームは短い時間で状況が大きく変わる。昨日得た情報が今日には古くなっていることも普通である。そのため全てを把握しようとするのではなく、誰が最新の情報を持っているのか？どれくらいの解像度で持っているか？を把握しておき、必要な時にその人に質問する、言い換えれば適切なAPIを呼び出せるような状況を維持する方がチームの生産性が向上する。
誰かに何か質問された時、「自分よりAさんの方が知っていますよ」というコミュニケーションをとった方がメンバー間の関係性を良くすることもでき、自分の負荷も軽減できる。
施策
大事なことは、チームメンバーの中で最も解像度が高いチームの中のコミュニケーションAPIドキュメントを頭の中に作っておくことが重要である。大事なのは「誰が」「どの情報を」「どのレベルで持っているか」を把握することだった。最新の情報を持ち続けるために「チームの人が何をやってきたか」「今何をやっているか」については注意深く追い、メモを残していくことが有効的だった。
何かを変えたい時は1人でやるな、「腹心を作れ」
誤解
チームを俯瞰して観察した結果、改善の施策をたくさん思いつき、それをすぐ実践しようとするだろう。1人で施策を推進しようとしても「自分の思った以上にメンバーは理解してくれない」し「時間や頭などかなりのリソースを消費する」。その結果、自分自身が消耗して本来取り組むべき業務に集中できないこともあった。
気づいたこと
すぐに実践するのではなく、まずはその施策を理解してくれ、一緒に推進してくれる「腹心」の人を作ることを検討するべきである。
腹心とは「深く信頼すること。そういう相手」のような意味がある。
腹心を作ることで自分がいない場所でも施策を推進してくれたり、フィードバックをもらい改善していくことでリソースを抑えながら大きな効果が得られる。
施策
腹心を作るために、「その人は何ができるか」「何に関心があるか」「何に挑戦したいか」という各メンバーの取り扱い説明書を作っておくことが大切だと思う。自分が思いついた施策に対して、「この人だったら協力してくれそうだな」という解像度を上げることができる。
説明書を作るために日々のコミュニケーションや1on1を有効に活用していきたい。得られた情報はNotionに"得意なこと/苦手なこと/挑戦したいこと/最近の関心事"の4項目をまとめていき、いつでも更新 + 見返せるような状態を維持しておく。
終わりに
ここまで2年前の自分に向けて、マネジメントを目指していた僕の誤解について手紙を残すように書いてみた。ここに記載したことは僕のいるチームや会社ではの前提があり、かつ時間が経つと状況が変わっていくので全ての人や組織に当てはまるのものではない。ただこの2年間でこれらの誤解に気づけたことは着実に自分の成長に繋がった。2年後にこの誤解を解いた僕が「あの時はこういう誤解をしていて大変だったな、今は成長しているよ」という風に思えるように日々努力していきたい。
Discussion