ICのままか、EMになるべきか…　ソフトウェアエンジニアの僕が悩み抜いて出した答え

IC→EMへキャリア選択をした大野氏

大野晋氏：メルカリの大野晋と申します。今日はこんな機会をいただいたので、私がEMをしている中で大変な思いをしたことや、ずっとエンジニアで来たのでその違いみたいなところ、成長したところを共有できたらなと思います。

先ほどちょっと話がありましたが、IC（Individual Contributor）ってもう普通に言いますかね？　いわゆるエンジニアでマネジメントロールをしない人ですが、ICからEMへキャリア選択をした人の話で、これは私のことですね。

ソフトウェアエンジニアを20年近くやって、実際にEMにキャリアチェンジしてから、約1年半が経ちました。今日の話には出てきませんが、私はずっとフリーランスでもありました。

最初は思いもよらなかったのですが、フリーランスから社員になって、さらにマネージャーのロールになった経緯や葛藤や失敗などを共有できたらいいなと思います。

というわけで、また自分のことですが、メルカリにはICのバックエンドエンジニアとして、2年前に入社しました。1年ほどICのバックエンドエンジニアをして、その後テックリードになったのですが、「人」にだいぶ興味があるということを他のマネージャーの方にも考慮してもらえて、「EMにならないか？」という話をいただき、それから約1年半ほどEMをしています。

EMとして日々考えていること

（スライドを示して）今日のお話です。あえて「EMとは？」みたいなことはあまり言わなくてもいいと思うのですが、ちょっとだけおさらいをします。そのあとに私のメルカリでの役割変遷や、メルカリ内のEM事情もある程度話せたらいいかなと思っています。そして最後に、私の個人的な失敗とそれをどう乗り越えていったのかという話を共有できたらなと思います。

（スライドを示して）3ヶ月、4ヶ月前（※登壇当時）に『エンジニアリングマネージャーのしごと』という書籍が出ていて、これにだいたい書いてあります。すごくおすすめです。もしくはYouTubeにForkwellさんが主催した会があって、私は5回ぐらい見たのですが、とても良い回なので、最初はそちらでもいいと思います。エンジニアリングマネージャーの仕事として情報収集、意思決定、ナッジング、ロールモデルってのがあるよねみたいな話がYouTubeでも話されています。

その中でも私自身が実際に何をやっているのか、何を考えているかをもうちょっと共有したいと思います。EMは実際はいわゆる中間管理職です。なので自分が「会社のやりたいことをこう持っていくんだ！」というのとはちょっと違って、チームが現場で戦っているところで、メンバーがどうアウトプットを出せるかに注目をしています。

アンドリュー・S・グローブの『HIGH OUTPUT MANAGEMENT』という書籍がありますが、マネージャーの価値というか「（マネージャーは）何をやるんだ？」という時にチームのアウトプットとそのチームの連携する役割だと思っています。

チームのアウトプットと影響を与えた他のチームのアウトプットの総和なので、自分自身でよりもチームのアウトプットに注力するというのにけっこう葛藤がありましたが、これをふだんは考えています。

あともう1つあって、やはり短期的な個々のプロジェクトではないんですよね。「プロジェクトの終わりがある程度見えてきたら解散」というわけじゃなく、そこから次のプロジェクトが始まるかもしれないし、プロジェクトをやっていく中で「あ、ここが問題だな」と思うことが次のプロジェクトにつながるかもしれません。

なので、チームがそれを長期的、継続的にコミットできる場を作ることが、エンジニアリングマネージャーには求められているのではないかなと私は思いながらふだん仕事をしています。なので（スライドを示して）ここはピープルやチームのマネジメントを主にやっているわけですね。

よく言われていることですが、1on1は情報収集の1つですね。実際に現場にいるので、「その現場の中で何が問題なの？」とか「どういうことがボトルネックになっているの？」とか、もしくは「今やることとはちょっとズレているけれども、将来的にこれをやったほうがいいよな」みたいなことを次のチームの目標にしようじゃないかと、今は考えています。

チームとしてはキャリアの相談や、ピープルマネジメントをしています。チームにどんな人を入れたらいいのかなとか、今増やしたいのか、それともちょうどいいのかとか話をしています。あとは、今が6ヶ月に1回のパフォーマンス評価の時期なので、けっこう大変です。先ほど言ったように長期的なチーム成長を考えています。

メルカリにおける役割の変遷

（スライドを示して）これは私の変遷です。先ほどお話ししたとおり2020年に入社しました。最初はitemチームというマイクロサービス側のチームでエンジニアとして働いていました。最初は3人しかおらず、その後その中でテックリードとなりました。半年くらい経った時にメンバーが2人になってしまい、もう本当に少なくなってきて、2人で「テックリードとは？」みたいな話をしていました。

この時期から、もっと自分たちのチームを大きくしていきたいという気持ちを持ち始めました。当時のマネージャーと話して、当時はちょうどコロナの時期でしたが、チームメンバーを増やしました。

メルカリは海外の方もけっこう採用しているのですが、4月に海外入社の方のオンボーディングとメンターをしました。その方は半年以上、1年かな？　1年日本に来られなくてなかなか大変でした。その人がどうやったらチームに溶け込めて、バリューを出していけるかなと（考えました）。このメンターの経験が、EMにつながったのかなと思います。その後「EMに（なるのは）どうですか？」という話をもらってitemチームのEMになりました。

itemチームなのに、モノリス基盤のKubernetes移行を開始しました。itemのマイクロサービス（チーム）に行ったはずなのに「なぜモノリスの基盤なんですか？」という話なんですけども。itemサービスは私が入った時にすでにけっこう完成されていたんですね。なのでそんなに積極的な開発がないという状況でした。

そんな中でもいろいろ開発がしたい。itemは、メルカリで重要な場所の1つにあるので、マイクロサービスにもモノリスにも両方にあるわけです。そういった時に両方の知見が必要で、モノリス基盤のKubernetes移行は、GCEで動いているサービスをGKEでコンテナ化していくという作業だったので、そのitemのマイクロサービスの知見がだいぶ役に立つんじゃないのかなという話で「ぜひやろうじゃないか」と始まりました。

実際に前回のPHPカンファレンスで話した内容がまさにこの話です。約1年かけて一応移行はできました。そしてまた、どんどん人を増やしていこうとしています。人をまた増やしてまたリモート面談ですね。

人が増えてきて、チームのケーパビリティというか、できることが増えてきたので、より面倒見るサービスをどんどん増やしていこうという話になっています。ちょっと近くのサービスで、よりここを知ったほうが改善できるであろうサービスを自分たちのチームに持ってきて、さらに影響度を広げていきました。

そうこうしてモノリスもけっこうがんばっていたので、チームが変わりました。itemチームだったのが「モノリスのほうに行ったらどうですか？」という話になって……「行け」というのはなかなかアレですけど（笑）。

私のバックグラウンドはPHPなのですが、モノリスはPHPで、マイクロサービスはGolangで書かれているので、両方わかって、さらにKubernetesがわかる人という話になった時に、たまたま良い人がいるじゃないかと、ここのモノリスのチームに変更しました。ちょうど今は7人のメンバーになっています。インフラの移行がだいぶ見えてきたので、アプリケーションの改善をやろうとしている状態です。

マネジメントパスとICパスがある、メルカリEMのキャリアラダー

メルカリにはキャリアラダーがあって、マネジメントパスとICパスの両方があります。これはGitHubで公開されています。MG1からグレードが1、2、3、4、5、6、7、8まであります。6まではGitHubで公開されているので、参考にしてもらえたらと思います。

MG1、2まではICしかありません。そこからラダーが分かれてICのキャリアとマネジメントのキャリアになります。EMのラダーだと、2人から8人のエンジニアを見たり、さらに上に行きたかったらマネージャーオブマネージャー、ディレクター、VPなど、いろいろあります。ラダーが上に行けばいくほど、チーム内、複数のチーム間、各カンパニー、全社へのインパクトが求められていきます。

EMは技術をどこまで知るべきか？

私はエンジニア上がりのマネージャーですが、メルカリの開発事情にあまり詳しくないEMもけっこういます。そこでよくあるのが、「EMは技術をどこまで知るべきなのか」なのですが、これには回答はないんですね。これはあとで共有しますが、知りすぎると逆にどうなんだというのが私の失敗でもありました。ただ、技術や課題はある程度知っていてほしいですね。

そもそも唯一解がなくて、「これをやったら正解」というのはないんですよね。なので、決定するためには何が問題で、何が解決されると、何がうれしいかで判断する必要があります。そこの見極めが大事で、これも唯一解はありません。メンバーがすごく成熟していれば任せたほうがいいのかもしれませんが、新しいメンバーだったら介入したほうがいいのかもしれないという難しさがありますね。

ICよりもEMのほうがより大きなインパクトを作れる

「EMになるべきか」というところですが、ここも先ほどの話で、ICよりもEMのほうがインパクトが作れるんですよね。先ほどのラダーにあったように、インパクトが自分のチームだけ、もしくは自分だけでこれだけできるようになった、チームでこれだけできるようになった、チームでのインパクトがあった。今度はチーム間の問題にインパクトがあった、さらに部門で問題となっていることをできるようになったというインパクトを出すのは、ICだと難易度が高いんですよね。

EMのアウトプットはチームのアウトプットなので、ICだけだとそこでラダーを上げるインパクトを出すのはメチャクチャ大変だなと思います。これは私が思っているだけで、それでも（インパクトを）出せる人はもちろんいて、ICでもグレードが高い人はいますが、EMのほうがより（インパクトを）出しやすいイメージがあります。

あとは人や組織に興味がない人だと、EMはちょっとつらいかなと思っています。人生のフェーズもあるのかな？　私も昔はソフトウェアの問題解決のほうに興味があって、人はまぁいいかなと思っていました（笑）。人に興味があれば、EMとは合っているのかなと思っています。

より上のラダーにインパクトを与えて上に行くのであれば、マネージャーオブマネージャーやディレクターなどの役職がいろいろあります。

EM→ICへキャリアを選択するパターンもけっこうある

一方で、EMからICというキャリアもけっこうあるんですよね。メルカリじゃなくても普通にあるのかな？　私が知っている範囲でも、メルカリの社内だけで4人ぐらいいます。またEMになることもできるので、（キャリアを）行ったり来たりできるんですよね。

実はEMの経験は、ICですごく活きることがよくあります。不安は確かにありますね。私も純粋によーいドンで「コーディングをしろ」と言われたら、腕は鈍っているんだろうなという気持ちはだいぶあります。そういう不安はやはりあります。

あとよくあるのが、ICのほうが持ち運べる技術が獲得できるんじゃないかということです。例えばフレームワークで「Laravelできます」と言えれば、別にこの会社じゃなくて他の会社でもたぶん役に立つだろうし、それなりに楽しいとは思います。

ただ、ソフトウェアエンジニアの仕事は、いわゆるコーディングだけじゃないんですよね。私も昔はプログラミングばかりをしたかったのですが、あまりインパクトがない仕事ばかりをしてもしょうがないので、他のタスクの優先順位の見極めだったり、もしくはいろいろな人を説得しないといけません。

Design Docを書いたり、利害関係者を説得する必要があります。他にもICのほうが報酬が少ない？　どうなんだ？　という話もありますが、同じグレードであれば変わりません。EMよりも高い給料をもらうICの方もいっぱいいます。マネージャーのほうが給料が高いんじゃないかという話がありますが、実はそうではありません。ただ、マネージャーのほうがラダーが上がりやすくて、インパクトが起こしやすいというイメージで考えたらいいと思います。

あとはitemチームにおいてもかつてEMだった人がいたのですが、仕事の勘所をすごく理解してくれるんですよね。とてもやりやすかったという覚えがあります。非常にありがたいですね。

（次回へつづく）