エンジニアを増やしていけば、うまくいくと思っていた––メルカリCTO名村卓氏が語る、開発組織の今とこれから

CTO名村氏が語るメルカリのエンジニア組織の今

名村卓氏：こんにちは。CTOの名村です。僕からは、メルカリのエンジニア組織の話をさせていただきます。「今とこれから」ということで、これまでのことと、今抱えている課題と、（これから）どうしていこうかという話をシェアさせていただきます。

おそらく（この会場には）いろんな規模のエンジニア組織の方がいらっしゃっていると思いますが、メルカリの今の規模の話と、このあと懇親会もあるので、そこでいろいろ話ができたらと思って、シェアな話が多いです。

2004年にサイバーエージェントに入ってから、ずっとソフトウェアエンジニアをやっていて、2016年にメルカリに入って、2年ほどUSに行き、2018年にメルカリJPに戻ってきました。CTOに就任したのは2017年ぐらいからですが、実際（業務を）やっているのは2018年に（日本に）戻ってきてからなので、新参者のCTOです。

今日はメルカリの現状と、これからどういうことをやっていくかというお話です。

外から見たメルカリと、中から見たメルカリ

まず、現状について。外から見たメルカリのイメージと、中から見たメルカリのイメージはだいぶ乖離していると思います。

メルカリのイメージを周りの人に聞くと、エンジニアじゃない方にもだいたい言われがちなことが、まず「メルカリはうまくいっていてビジネスも確立しているから、（CTOは）あんまりやることないでしょ」ということ。

一番よく言われるのは、例えば転職で「メルカリに入ってやってほしいことがあるんです」と話しても「僕が入っても、なにもやることないでしょ」ということです。あと「上場したので、ここから手堅い感じになるんじゃないか」とか「優秀な人がいっぱい集まっていますよね」とも、よく言われます。

「最先端の技術が揃っていてスキルを高められそう」「技術的なところでいろいろがんばっていますよね」と言われることも多いです。実際にはそんなこともないんですが。

もうちょっと内情的な話をしていくと、実際サービスはYear on Yearで成長を続けています。

MAUも、2019年6月期に1,357万MAUを達成しているので、安定してきたというよりは引き続き伸びていて、より多くの人に機能の提供が必要になってくる状況です。

ここまで大きくなってきたのは優秀なエンジニアがいたから、といえばそのとおりですが、人数的な推移を出させていただくと、従業員数はここ3年で3倍になっています。

2倍3倍と堅調に人数が増えてきて、数百人だった規模から1,000人ぐらいを超えたあたりから、よく知らない人がいっぱい増えたというか「この人誰だろう？」みたいなことが増えてきました。

さっき挙げた数字は全社員の数ですが、エンジニア組織も、詳しい数字は公表していませんが、2017年から2018年で3倍近くになりまして、グラフでも一気に伸びています。

今2019年で、もうちょっとで（2018年の）1.5倍になるぐらいの勢いで、エンジニアの数もすごく増えています。

エンジニアを増やしていけば、うまくいくと思っていた

3年前、優秀なエンジニアをたくさん採って数を増やせばいろんなものが作れるようになるだろうと計画して、採用とかをがんばってきたんですが、人が増えた結果、エンジニア組織の空気が変わってきました。

例えば、メルカリは外からたくさん人を採って、適切な場所に配置してやっていくかたちが多かったんですが、そのぶん、中で若手を育成する文化があんまり定着していなかった。例えば、トレーニングにはすごく手間がかかりますけど、そのプログラムとかプロセスをちゃんと作ってなかったんですね。

入ったら「がんばれ」「なんとかしてくれ」とほっぽり出されるので、みんな最初は「おお？」って戸惑うんですけど、いい人を採っているので、そこでなんとか立ち上がってくれることが多かった。でもさすがに人数が増えてきて、立ち上がるところのプロセスが現場の負担になってきました。

育成するカルチャーとか、人を育てなければというマインドが中で醸成されていない。育成に対しての弱さが、最近は出てきています。

一方で開発プロセスも、少人数だと、阿吽の呼吸というんですか、優秀な人同士はわかる呼吸みたいなものに依存したプロセスが多かったので、たくさん人が入ってくると、みんながみんなは同じプロセスに乗っかれないので。

それで大きな組織に対するプロセスに変えていかなきゃいけないんですが、属人化されたプロセスって、効率が良かったり、変えるための負担が大きかったりする。なかなか変化に弱い組織になっていたという実態が、メルカリの開発の現場にはあります。

急成長の中で生まれた歪み

一方で、成長を力強く続けているということを裏返すと、プロダクトの成長に対するコミットメントが非常に強い時期が続いたんですね。

それによって、例えば短期的に数値を達成するための機能を実装したりというところが比較的続いたり、リリースのデッドラインを死守（しなければいけなかった）ものがいくつかあったりして技術的な負債もたまってきて、なかなか開発が重くなってきたという状況です。このあたりはほかの会社も経験されているかもしれません。

あと、これはメルカリ特有かもしれませんが、もともとは海外メンバーがたくさんいた会社ではなかったんですけど、海外メンバーを積極的に採用するようになって、2〜3年で急速にグローバル化が進みました。

なので、ほとんどの開発者が日本人だった会社が、急に半分ぐらいのエンジニアが海外メンバーになって、日本語をしゃべれない人のほうが多いというぐらいの急速な変化があった。

これによって、例えば言語のコミュニケーションの壁や、エンジニア同士でのコミュニケーションなどで、ストレスフルなところが出てきました。

あとは、カルチャーの違い。例えばエンジニアの評価に関しても、国によってまったく考え方が違うんです。メルカリは良くも悪くも日本風の評価システムだったんですが、それが通用しないことが出てきて、変化が必要となってきています。

スタートアップのときはうまくいっていた仕組みが、変化に伴って通用しなくなった。過去うまくいっていたものを捨てて、スケールに対応するものを導入する必要が出てきたと感じています。

「最高の体験を届ける」ためには何をすべきか

今メルカリが目指している姿としては、CtoCのサービスなので、お客様の体験が最大化されればビジネスとしては成功するということが、基本的には1つの目的です。

まず、ここを目的とした組織を目指して、みんなで同じ方向に向かっていかなければいけないと考えています。

じゃあエンジニアという組織が、最高の体験を届けるためにどうあるべきなのかと逆算すると、そんなに難しくはない。エンジニア自身が、プロダクト開発が楽しくてしょうがない、お客様に新しい体験や良い体験を提供することが楽しくてしょうがないというふうに、モチベートされるような組織にしていく必要があると考えています。

今だと、プロダクトマネージャー。わりと機能的な面ではトップダウンのところも多くて、組織で「こういうものを作りたい」というプランニングから、実際にプロダクトに導入されるまでのプロセスが長いので、エンジニアが「こういうことをやりたい」というものを簡単に試せないところには課題を感じています。

エンジニアが心の底からプロダクト開発を楽しむことは、エンジニアがどんどん成長していくこととイコールだと思います。よりいいものを作りたいと願うエンジニアはどんどん新しいものにも挑戦するし、どんどん改善していくのでより成長していくでしょうということで、成長できる組織ってなんだろうと一生懸命考えています。

統率の取れた有機的な組織を目指して

今、出ている答えというか、僕が描いているビジョンでいうと、こういうところに向かいたいというプロダクトのビジョンがあって、それに対して組織全体が同じ方向を向いて進んでいる。

（そのとき）エンジニアはなにをしているかというと、同じ方向に向かうためのプラットフォームを作るチームや、そのプラットフォームに乗っかって同じ方向に、diverseというか、多様なチームがいろんな価値観でそれぞれ向かっている。

それぞれがそれぞれの、自分たちが使いたいツールや自分たちが作りたい機能を作ることで、どんどんいい組織に向かっていくよう目指していくのがいいんじゃないかと考えて、これをベースに組織を作っていこうと思っています。そんな組織を「統率の取れた有機的な組織」と言っています。

有機的なるそれぞれが自分たちの意思で動いているという状況を作っていくために、まずカルチャーとか制度・仕組みを作っていく必要がある。そこの仕組みがあった上で、意思決定して実際のプロダクトに実装できる裁量をエンジニアにちゃんと与える。仕組みがあるので属人性もないので、そういった裁量をふんだんに発揮してもらっていくと。

みんなが同じ方向に向いていれば、それぞれがバラバラに動いても力が結集していい結果になっていくでしょうというところが、人数が増えてきたエンジニア組織で必要な動きなのかなと思っています。

目指す組織に向けて取り組んできたこと

今まで取り組んできたことをおさらいさせていただくと、そういった目指す方向の共有に対して、メルカリはずっとミッションとかビジョンとかあるんですが、そこに対してプロダクトビジョンというものを作ったり、OKR、目標管理設定を使ってうまくやっていこうとしています。

アジャイル・スクラム開発は、遅いようですがメルカリではやっと導入がほぼ行き渡り、各チームで使っています。成長を支えるカルチャーとしては、Onboardingとか、組織制度をエンジニアリングマネージャーやプロダクトマネージャーの制度に変えたりしました。

今やっていることは、アーキテクチャーの刷新です。

マイクロサービス化を長いことやっているんですけど、要は意思決定を各エンジニアができるようにするために、マイクロサービスやフロントエンドのコンポーネントや、諸々を整備しています。

あとは、エンジニアの評価制度が（国ごとの）カルチャーによって変わってくるので、そういったところのprincipleを作ったり、Career Ladderという、どれぐらいどういう期待値で仕事をすると「あなたの評価はこうなります」ということをちゃんと明文化するようにしたり。

あとは、グローバル人材を育成するには英語を主体にしていく必要があるので、言語面での研修のサポートなどを積極的に進めています。

今後はマイクロディシジョンというか、意思決定をどんどんエンジニアのほうでしていくために、属人性の排除もそうですし、意思決定をデータドリブンにしなければいけないので、そういったところを支えるFeature Flagとか。あとはエンジニアがデザイナーの力を得なくても機能実装ができるようにするためのDesign Systemとか。

あとは、Microcomponentsと言っていますが、フロントエンドサイドの細分化を進めたり、データディシジョン、データドリブンという、意思決定をするためのプラットフォームを整備したり、基盤整備部分を一生懸命進めています。

メルカリが、プロダクトが成長して、かつ、エンジニア組織が数百人規模になって、そのうち4割ぐらいが外国人で構成されるような特異な組織になってきたんですけど、そういった中でいいプロダクトを作るための組織とか技術に関して、今は道半ばで課題がすごく多いけれど、進んでいるという共有をさせていただきました。

（会場にも）いろんなエンジニアの組織課題とか技術課題を感じている方がいらっしゃると思うので、懇親会でもうちょっと話ができたらと思います。

僕からは以上です。ありがとうございます。

（会場拍手）