米国シリコンバレーで気がついた「組織のための技術」の可能性
――メルカリは「グローバルテックカンパニー」を目指すと宣言し、2018年7月にはマイクロサービスの導入を発表しました。メルカリのエンジニア組織の改革において、名村さんが重要な役割を担われたと伺います。なぜ名村さん自身がその役割を担うようになられたのか、まずはその経緯についてお聞かせいただけますか。
もともとは日本企業でソフトウェア開発に携わり、日本人向けのサービスをつくっていました。でも、どこか日本でしか通用しなくなるのではないかという焦りもありましたね。もともと米国・シリコンバレーで働くことに憧れがあり、グローバルに事業を展開できる場所で働きたいと思っていました。そこで、2016年7月にメルカリに入社し、米国に出向してUS版サービス開発の担当となりました。ソフトウェアエンジニアとしての採用だったのですが、まだ人数も少なかったこともあり、バックエンドのアーキテクチャに課題があれば改善したり、US版メルカリをスクラッチから書き直す際にクライアントも含めてプロジェクト化したり、アーキテクトとして携わっていたところが多かったですね。
以前は、ソフトウェアでも「テック的なもの」だけに興味があったのですが、米国に来てアーキテクトも含めて「組織に同調した技術」の重要性に気づき、関心を持つようになりました。シリコンバレーにはテックジャイアントと呼ばれるグローバル企業の中枢部がありますが、世界中に何万人ものエンジニアが散らばっていて、それぞれがバリューを発揮し、次々とイノベーションを起こしているわけです。展開スピードも凄まじく速い。
そんな時、CPOの濱田優貴とプロダクト責任者の富島寛から「技術的な課題が山積みだから、アグレッシブに改善していきたい。CTOとしてそれらの課題に取り組まないか」と声をかけられました。当時は現場を離れるイメージがなかったのですが、「組織のための技術」を考えつつ組織づくりにも取り組むというのは、チャレンジングで面白そうだなと。それで2017年4月にCTOになり、前年からマイクロサービス化が始まっていたのを引き継ぐ形でさらに推進するようになったわけです。
――エンジニア組織やマイクロサービスについては、どのように知見を収集されたのですか。
人の話を聞いたり、勉強会やミートアップに参加したり、いろいろですね。その中で一番印象的だったのが、Uberの開発環境やエンジニア組織の話です。Uberではモバイルチームが世界中に散らばって、国ごとに必要な機能をそれぞれ開発していますが、アプリケーションはひとつです。各自が良いと思った機能を共有するプラットフォームがあり、みんなにいいと判断されると一部のユーザーに実験的に提供されるというのです。さらに問題がなければ国全体に、世界にと反映範囲が広くなる。逆にクラッシュ率が高くなった、乗車エラーが多くなったというような黄色シグナルが増えたら、自動的にオフになるのだそうです。
ここで面白いのが、データドリブンで動いているということです。トップダウンだけでなく、一人ひとりの意思が積み重なって総意になり、ボトムアップの意思決定が最終的に大規模なアプリケーションの品質を高め、改善にもつながっている。メルカリだったらそういう環境を作れるかもしれない、ポテンシャルがあると思いました。
モノリシックの限界と、その課題解決のために目指した組織のあり方
――名村さんの気づきもありつつ、メルカリそのものに対して組織としての変革による可能性を感じられていたわけですね。
そうですね。メルカリ自体がまずエンジニア主体の会社になろうとしていることは強く感じていました。ボードメンバーが技術に対して知識があり、「理由あって必要なものであり、それが組織の強みになる」と捉えている。「技術はよくわからないけど任せた」というのではなく、技術とその価値を理解した上で投資しようという意気込みが感じられるんですよね。「技術がわからないから、安易にコスト削減」という話を時々耳にしますが、メルカリについてはそういうことにはならないだろうと。
とはいえ、当時のメルカリは、モノリシックな構造とその肥大化が大きな問題になっていました。同じコードベースをみんなで触って変更し続け、それをずっと繰り返してきた結果です。成長が著しい時期で、基本的にはプロダクトファーストでやってきたので、「こうあるべき」を考えて実践する余裕がなかった、仕方がなかったとは思いますが、そろそろ限界に来ていました。
実際、入社したばかりの頃にひとつ変更を加えようとしたら、調査すべき影響範囲があまりに広いことに戸惑いました。以前からいる人ならなんとなく分かっていることでも、入ったばかりの人にとっては、どういう悪影響があるか、調査しなければ分からないわけです。だから変更が怖いし、臆病になるわけですね。かといって、サービスをよくするには避けられないので調査するのですが、一つひとつの変更作業が重いものになり、確認に時間がかかったり、予期せぬところで障害になったりと、問題が表面化してきたのです。
組織課題として、日本語が母語ではないメンバーが増えたこともありますね。同様の不安を抱えながら、日本語のドキュメントを参照しつつ変更を加えるのは、日本人以上に負担が大きいでしょう。新しい人が活躍できるまでに時間がかかり、変更に対するコストもかかっていたので、その意味でも早々の解決が求められていたのです。
――そうした課題に対して、CTOとしてどのように解決を図ろうとされたのでしょうか。まずは考え方というか、構想について聞かせてください。
まず、最初に考えたのは、「どういうエンジニア組織にすべきなのか」そして「そのためには、どういう技術に取り組んでいくべきなのか」ということです。それで考えたのが「スケーラブルなエンジニア組織」です。普通の組織では、人数が増えれば増えるほど一人あたりの生産性が下がる傾向にあります。当時のメルカリはそうした状況に陥っていたので、むしろ1千人、1万人と人が増えるほど一人あたりの効率が上がるような組織にしたいと思いました。
そういうと作業効率性みたいな捉え方をされますが、そうではなくて、「みんなが生み出すものにちゃんと価値があるか」こそが評価基準です。価値の高いものを生み出していくには、第一段階として、一人ひとりのエンジニアが「こうしたい」と思ったことがブロックされないことが重要だと思っています。もちろんサービスに悪影響を及ぼすものは排除されるべきですが、それぞれがいいと信じるものを、まずは実現できるようにしたかったのです。
その結果、思いもよらなかったものが登場して実現するようになれば、多様な価値観や感性が育まれるでしょうし、同時にオープンに見えているわけですから「メルカリによっていいもの」が何かがつかめて、上からの指示がなくても、より良い判断ができるようになるのではないかと。そうなれば、一人ひとりのチャレンジの回数も増えるし、他者のチャレンジも自分の糧になる。その結果、一人ひとりが受け合う刺激をもって発想力が洗練されていく。そうなったらもう手放しでもいい方向に進んでいくんじゃないかと期待しています。
