これは Engineering Manager Advent Calendar 2021 2日目のエントリです。
簡単に自己紹介すると、今年の3月までメルカリでEM(Engineering Manager)をやっていて、今はメルカリのグループ会社であるソウゾウでIC(Indivisual Contributer)として働いています。バックエンドをメインにフロントエンドも書いており、採用周りもちょっと顔を出したりしています。
さて、このエントリではかつて「EMなんて絶対やりたくない！」と思っていた若かりし自分が抱いていたEMに対するもやもやに対して、IC→EM→ICというキャリアを経たいまの自分が答える、という形式で書いていこうと思います。
EMはやりたくないと思っている方の参考になれば幸いです。
EMって何する人なのかわからない
組織によってEMに求められる役割に違いはありますが、マネージャー経験者の多くが読んでいるであろう『High Output Management』では、マネージャーのアウトプットを以下のように定義しています。
マネージャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット
簡単にいうと、組織の成果を最大化させるということです。
…とここまで書きましたが、全然ピンときてないですよね。わかります。
あなたのEMが普段どんな仕事をしていて、それが自分や自分の属するチームにどんないい影響を与えてくれているかが理解できていないのかもしれません。
もしそうなら、シンプルにEMとのコミュニケーションが足りていません。まずは月に1回ペースでお互いの仕事のことなんかをカジュアルに話す場をセットしてみてはどうでしょうか。そうするとEMがどんなことを考えていて（もしくは考えていなくて）、どんな仕事をしているのかわかってくるはずです。
本来EMからICに対してコミュニケーションをとるのが理想的ですが、EMが忙しすぎたりマネジメントスキルが低く何をしたらいいかわかっていない場合もあるので、ICからもコミュニケーションを取りに行ってみるのをおすすめします。ちょっとハードルが高いかもしれませんが、EMからすると案外ありがたかったりするものです。
EMって何が楽しいの
これは人によるところが大きいと思いますが、自分の場合には楽しいと感じるポイントは3つありました。
- やったことがなく、かつ頑張ればできそうなことにチャレンジしている感覚
- 「チームを成長させる」ために必要な裁量が与えられていること
- 採用にがっつり関わることができる
（1つ目は割愛して）2つ目について説明します。Tech Leadやリードエンジニアと言われるような役割がつくと、思考の高さが自分1人からチーム全体に上がります。そうなると、開発のボトルネックをなくしたり、生産性を上げたり、プロダクト全体の安定性を上げたりといったことを求められるようになるでしょう。
そういったことを続けていると、自身の裁量では対応できないような問題についてEMの判断を仰ぐ場面が出てきます。例えば他チームとの業務分掌や業務フローの適正化であったり、チームへのメンバー受け入れであったり、技術的負債の返済と新規機能開発のバランスであったりします。それらを自分で判断できる裁量がもらえるのはEMとしてやりがいを感じる部分です。
3つ目について詳しい説明は不要かもしれませんが、EMになると多くの場合がっつりエンジニア採用にかかわることになります。書類選考や面接を担当するだけでなく、選考フローや選考基準を作ったりアプローチする人材を選んだりもします。
採用というのはEMにとって最もレバレッジがきく業務の1つであることはもちろん、自分と一緒に働くメンバーを自分で決められるのはエキサイティングです*1。
経営と現場の板挟みになって辛そう
板挟みになることはあります。
組織が大きくなるにつれて経営と現場のコミュニケーションコストが大きくなり、直接的な相互理解が難しくなってきます。そのため、EMの業務の1つとして経営のメッセージを適切に現場に伝え、現場のメッセージを経営に伝えることが求められます。
EMとして辛いというかもどかしさを感じることはありますが、誰かがやらないといけない仕事ですし、現場のメンバーが納得感を持って日々仕事ができるようにするために必要な業務です。ただし、EMのような中間管理職のプロキシを介さずとも、経営と現場で直接的にメッセージをやりとりできる仕組みを会社として設けることは非常に大事だと思っています。
エンジニアとしてのスキルが落ちそう
コードを書く速度は確実に落ちます（キッパリ）。なぜならコードを書く機会が減るからです。
新しい技術トピックを調べたり業務の中でそれを試したりする機会も減るでしょう。
ただ、EMも業務としてメンバーの評価をしたり技術的な意思決定をする場面があるため、ICのときほど技術にdeep diveする時間はなかったとしてもトピックを抑えておく程度の技術的なインプットは必要です。
私がEMになりたての頃はコーディングから離れるのが怖くて毎日コードを書くための時間を確保していましたが、EMとして経験を積んでできることが増えていくにつれて徐々にコードを書く時間は減っていきました。プライベートでコツコツ技術の勉強をするのがあまり得意でないので、チーム内の勉強会に参加したり1on1で詳しいメンバーに知識を教えてもらったりしてなんとかキャッチアップしていました。もちろん、プライベートの時間でコードを書いているEMもいました。
一方で、エンジニアのスキルは最新の技術トピックを知っていたり良い設計ができたりコードを速く書けたりすることだけではありません。
もちろん、そういったスキルを職人的に磨き続け技術的難易度の高い課題を解くことを専門にするキャリアもあります。しかし、ビジネス観点を持ってPMやBizDevと相談しながら開発計画を立てたり、開発プロセスを改善してチームの生産性を上げたりすることもエンジニアのスキルです。
その意味では、EMになったからといってエンジニアとしてのスキルが落ちるわけではなくスキルの幅が広がるという考え方もできます。
…とここまで書きましたがやっぱりコードを書く機会が減るのは自分としてはとても悲しかったです。それもあって今はICに戻りました。
一度EMになったらもうICには戻れなさそう
戻れます。というか戻れました。
1年半のブランクがあったため、開発初期にはLinuxコマンドやらGo言語の仕様やらを思い出すのが大変だったり、さらには今まで触ったことのない技術へのチャレンジやタイトなスケジュールもあいまって頭がパンクしそうでしたし自分のあまりのできなさに落ち込んだりもしました。
しかし、そんな時期も1ヶ月くらいすると慣れて以前と同様にコードを書けるようになっていました。
正直に言うとブランクのある自分がどの程度コードが書けるのか非常に不安だったのですが、思っていたほどのコーディングスキルの衰えは感じませんでした。加えて、PMやCSとのコミュニケーションがスムーズに行えたり、自分から開発仕様を決めるように周りを巻き込みながら推進できたりと、EMをやっていたことによる自身の成長を感じることもできました。
ブランク期間が3年、5年などもっと長かったらこうはいかなかったかもしれませんが、少なくとも1年半程度であれば自分のようなコーディングスキルが決して高くないエンジニアでもICに戻ることはできました。
さいごに
IC→EM→ICというキャリアを経たいまですが、もう一度EMに戻るのも全然アリだなと思っています。
冒頭で書いたとおりEMの役割は組織によって違うので、1度EMをやった組織とまた別の組織でEMをやるのは面白そうだと思うからです。担当するチームやメンバーの成長に少しでも貢献できたり、それによってよいプロダクトがリリースされるのを見るのはICとはまた別のやりがいがあります。
散々ポエムを書きなぐってしまいましたが、ざっくばらんにこのあたりを話してみてもいいよ！という方はぜひmeetyからご連絡ください。
meety.net
12/3追記：
時期を同じくして弊社のオウンドメディアでも近いことを話しているのでご興味あればこちらもご覧ください。
mercan.mercari.com
