社員数18倍を経験したエンジニアのキャリア

高山征大氏:高山といいます。よろしくお願いします。「18xと振り子」というタイトルにしているんですが、「なんで18倍なんだ?」というのがまず出てくると思います。そもそもこの話はキャリアの話がメインで、あまりテクニカルな感じではありません。

僕の社員番号は122なんです。2016年に入社したんですが、最近入ってきた人に聞くと、だいたい社員番号が2,000番を超えているという話なんですよね。となると、こんな感じになります。

これは決算報告書に出てくる従業員数で数えているんですが、基本的にこんな感じで、2017年から2019年にかけて4倍ぐらいになって、2倍・2倍みたいな規模で進んでいます。今日は、僕がこの3年半の間に経験してきたチャレンジや変化の話をできればなと思います。

この、一見正弦波のように見えるなにかがあります。

最近読んだブログがあって。@mipsytipsyさんかな。この人はFacebookとかLinkedInでマネージャーをしている人で、振り子と言っています。

英語で書いているので要約すると、優れた最前線のエンジニアリングマネージャーは、現場のエンジニアリングから2〜3年以上離れていない、という話です。逆に現場のエンジニアとしては、1、2回マネジメントの経験者のほうがベストであると書いています。

一方で、テクニカルなリーダーシップを発揮していく人というのは、両方行ったり来たりしている人がいいテクニカルリーダーだよと言っていって、なるほどなと思いました。

これはWikipediaから取ってきた振り子の例です。「pendulum」というんですが、振り子の話をしています。というわけで、「18xと振り子」というタイトルはそこから取ってきました。

今の話を絵にするとこうなります。

マネージャーになったりエンジニアになったりする感じですね。(振り子のように腕を振りながら)こういう感じです。

マネージャーになってからもう一度エンジニアに戻ってくる話は聞くと思いますが、メルカリでそうなったのは僕が最初だったと思います。最近は増えてきているようなんですが、逆にエンジニアからマネージャーに戻ってきた人は、弊社の中でも少ないと思います。そのあたりのレアな話ができればいいのかなと思っています。

エンジニアからマネージャー見習いに

この話のテーマは、その振り子のキャリアが「できるの?」という話と、実際にメルカリにおいてやってみた例という話です。

ここからちょっと歴史っぽくなります。

自分はエンジニアで入ってきました。そもそもiOSの人だったんですが、Androidが足りなかったからやっていたり、いろいろなプロジェクトをやっていました。そうしていると、ある日マネージャーから呼ばれて、「あなたは明日からマネージャーです」みたいなことを言われたんですね。「はぁ、なるほど」と思うわけです。

振り子があるとして、一番大きな力がかかるのは揺り戻しの瞬間です。その揺り戻しのタイミングがけっこうおもしろいんじゃないかなと思って、星をつけています。

それでマネージャーになったのですが、なにもわからないわけです。メルカリに入るまでやったことありませんでしたし、「何をやるんだっけな?」と。その頃は、マネージャーになるにあたって何をすべきかはほとんどなくて、とりあえずやってみるしかありませんでした。

その時に「なんでマネージャーになったんですかね?」と聞いたら「いや、君は人の話が聞ける」と。「人の話が聞ける……人間じゃなかったっけ?」とか思うんですけど、エンジニアはそうでもない人がいるなかで、人の話が聞けるというのはその時はレアだったという話です。

小さいフェーズの頃のマネジメントを振り返って思うのは、けっこうなんでもやらされるし、ある意味なんでもできるし、カオスである。だけど、その分自分の出せるインパクトは大きいなと思います。いきなり振られたりして、自走力が問われたりします。

もう1つ加えることができるとすれば、もしこのようにマネジメントを経験した人がこのフェーズにもう一度入ると、このあたりのことはもうわかっているから、けっこうパフォーマンスを出せるのではないかと思います。

500人規模になり、プレイングマネージャーからマネージャーに

その後、500人ぐらいの規模になっていくんですが、またエンジニアをやったりして、プレイングマネージャーをしていました。

それから、だんだんマネージャーっぽくなっていきました。プロジェクトマネージャーをやってみたり、プロダクトマネージャーになってみたり、そもそもAndroidの人の面倒を見ていたので、エンジニアリングマネージャーのようなことをやったりしました。

やはりもともとエンジニアなので、プロダクトマネージャーをやろうとしても、なにもわかりません。だけど、その時たしかメルカリは「プロダクトマネージャーとかエンジニアリングマネージャーとかじゃなくて『みんなマネージャーです』」という感じで、マネージャーになりました。つまり、なんでもやるという感じ。

それまではプレイングマネージャーだったこともあり、シングルスレッドで自分のパフォーマンスでやっていましたが、マネージャになったことで、マルチスレッドで並列で考えないことが増えました。この時はスイッチが頭の中にめっちゃある感じになっていて、そういうトレーニングをしていました。

あと、採用をバリバリしてたんですが、インドに行って英語で面接するということもやっていました。もちろんそういう経験もなくて、なかなか大変でした。

その時はまだ日本人がたくさんいる会社でレベル感も均質で、まだ顔の見えるチームがありました。その時のマネジメントやることは、軽いわけではありませんが、任せられるという感じですね。階層も少なかったので、とにかく速く動ける感じでした。

マネジメント対象が10名ほどになりチームも多様化、しかし…

2018年に転機があり、マネージャーになりました。

社員数が1,000人ぐらいになったとき、EM/PM制が敷かれ、その時にエンジニアリングマネージャーという名前に変わりました。主にAndroidメンバーを見ることになりました。

何が起こったかというと、ダイバーシティがすごく増加していて、かつメルペイの開発が始まったりして、そちらにプライオリティをどーんと寄せるということもありました。

自分の見てる人たちが3人ぐらいだったところから、10人ぐらいに増えたりして、かつ、日本語を話す人たちが多かったところから、英語をしゃべる人が増えてきていきました。いろんな国籍から来ているので、けっこうマルチカルチャーになりました。

かつ、その時は気づかなかったんですが、スキルレベルもグラデーションがある感じになっていました。

ほかにもソウゾウという会社があり、そこからメルカリにジョインされた人もいました。ソウゾウの人たちは0→1とかを指向する人たちですが、メルカリはメルカリという固いプロダクトをコツコツと作っていく感じなので、その音楽性みたいなものが違ったりしました。そんなことがいっぺんに発生して、えらいことになりました。

学びとしては、いっぺんにやると死にます。いっぺんにはやれません。

大変なことになりすぎて「もう疲れました」って感じになったので、ちょっとマネージャーから離れました。

そうして何やってたかというと、全体の組織を良くしていこうみたいな話をしました。

Design Docという技術仕様書みたいなものがあり、それを全エンジニアに導入していくであったり、EM/PM制になった時に、「テックリードの役割が曖昧やな」という話があったりしたので「じゃあテックリードに求められることって何ですか?」みたいな議論を起こして収束させる仕事をしようという話になりました。

こんな感じでdocsの中にコメントがダーッとつく感じで議論をしていて、これはこれで大変なことがたくさんありましたが、その時の学びとしてはDisagree & Commitです。

議論をたくさんするのは大事なんですが、一方で我々は物事を進めないといけないというときに、「わかった。これで1回おしまいにして、とりあえずこの第1版でやってみよう。それで問題があったら改善しよう」みたいなことをもっとやっていければよかったなと感じています。議論が長引いてしまったので。

2年ぶりに現場に戻って感じたこと

そして今年になると、マネジメントからドーンと離れて、先ほど定義したテックリードをやってみたり、普通のいちAndroidエンジニアに戻って「機能開発どうする?」みたいなことをしています。

その時に思ったのは、マネージャー→マネージャー→マネージャーみたいなかたちで2年ぐらい現場のコードから離れていたんですが、学びとしては、実はまだ書ける。そんなに勘は鈍ってなかったので良かったです。

あと、マネージャーをやったことで何がよかったかと考えると、普通にコードを書くエンジニアだとしても、テックリードとかそうなんですが、「そのコードを書くことで何が起こるのか?」みたいなこととか、「チーム全体で何をどう調整したら前に進むのか?」みたいなところは、やはりマネジメントを経験したからかなと思います。

あとは、不確実性を減らしていくのがエンジニアリングである、ということが『エンジニアリング組織論への招待』の広木(大地)さん本に書いてありますが、身をもって実感しながらコードを書くということはできたかなという気がしています。

そして、エンジニアリングマネージャーに戻っています。会社の規模感としてはだいたい2,000人弱ですね。

マネージャーに戻った理由

今、この規模感になったメルカリの組織の課題を解こうとしています。

先ほどからから出てきたマイクロサービスもそうですし、マイクロディシジョン化に向かってやっているんですが、そういうこともチャレンジとしておもしろいなと思います。

そもそもなぜマネージャーに戻ったのかというと、できるチャレンジがけっこう大きいと思ったからです。アーキテクチャを作るチームなので、組織とアーキテクチャって表裏一体だなと思っています。そういうことをチームでやるのはけっこうおもしろいチャレンジかなと思っています。

あと、1回離れていたので、ワンクッション置いたことによってできることもあるんじゃないかという気がしています。

これを図に並べるとこんな感じになりました。

大切なのは、振り子を大きくすること

2分でサックリまとめると、とにかく変化に適応していくのが大事であって、そういう人が生き残っていくと思うんですよね。適度な変化があることが大事だと思っていて、いきなりハードなことがたくさん来ると肉離れして死んでしまうので、ちゃんと考えながらやっていかなければいけません。

あとは、フルスタックエンジニアという言葉があります。それはそれとしていいのですが、フルスタックってスタックだから1次元なんですよね。そうじゃなくて、例えばマネジメントに振ってみたり、Android・iOSをやってみたりとか、いろんな方向に伸縮できると、人生が楽しくなるのではないかなという気がしています。

振り子の話に戻ります。自分そうやってやってきましたが、行き来できる環境というのはけっこうレアかもしれないなと思っています。弊社ではマネージャーもテックリードも役割だと言っています。

その現実として、僕はマネージャーからエンジニアに戻ってきました。いろいろ行き来することができると思います。

大事なのは、私は振り子をしてるんですが、このボールを大きくしていくことが大事かなと思っています。今、エンジニアでもマネージャーでも、「どうやってそのボールをでかくしていくか?」が大事なのではないかと思います。

という感じで、チェンジして、チャレンジして、いろんなことをやって振り子を振っていきましょうという話でした。   (会場拍手)