無数の挑戦と失敗を繰り返しながら進化する　メルカリが考える、エンジニアにとって最適な組織づくり

メルカリがこの1年に起こした「3つの大きな変化」

名村卓氏（名村氏）：おはようございます。メルカリのCTOの名村です。濱田が話した通り、メルカリは今、テックカンパニーを目指しています。私からは、メルカリがテックカンパニーになるために、どんな組織を目指し、その組織のためにどんな技術を使おうとしているかのお話をさせていただきます。

まず、メルカリがこの1年に起こした大きな変化についてですが、大きく３つありました。１つは、メルカリの拡大です。この1年でメルカリは、大きく成長し、さまざまな機能を追加してきました。お客さまにより便利で安心なメルカリを提供できるように尽力してきました。

２つ目は、メルペイの設立です。金融関連の事業を行うために新たに設立され、決済をはじめ、あらゆる金融サービスの未来を描いて前進していきます。

３つ目は、メルカリUSの成長です。この1年、メルカリUSは、新しいCEOのもと成長を続け、組織も拡大を続けています。US専用のCTOにMokを迎え、素晴らしいエンジニア組織もできつつあります。

こうしたメルカリの変化とともに、メルカリのビジネス組織も大きく変化をしています。まずエンジニアの人数ですが、1年前に120名だったエンジニアの数は、2018年10月現時点で、350人まで拡大しました。実に3分の2のエンジニアがこの1年に新しく入ってきたことになります。100人規模の組織が300人を超えるようになって、人数が増えるにつれて、チームという考え方から、組織という考え方をしていく必要があります。

組織というとちょっと堅苦しいイメージかもしれませんが、300人を超える規模になってくると、みんなで力を合わせてなんとかしようとか、個人の力量でうまく気を遣いあってカバーするといったことが通用しなくなってきました。

できるだけ小さいチームで開発したいと希望するエンジニアは少なくありません。でも、たくさんのエンジニアの力を結集して発揮するためには、どういったビジネス組織を作っていったら良いかというのは、通らなければならないポイントだと思っています。

チームから組織へ成長する過程の問題点

ここで、チームから大きな組織に変わっていく中で、よく起きる問題をいくつか挙げさせていただきます。

まず1つが、スピードの低下です。人が増えると、ちょっと聞けばわかったことや、ちょっと気軽にできることが減ってきて、確認の数だけが増えていったり、返答に時間がかかったり、過去の経緯を調べたり、すべてに時間がかかることになります。

それに伴って、裁量も減っていきます。自分が良いと思ったことが、なかなか採用できなくなり、問題を根本的に改善したいと思っても、いろんな人を説得して回らなければならなくなり、自分が責任を持って、決断して進められることが明らかに減ります。

一方で、思想の衝突というのも起こります。多くの人が入ってくると、今までは空気をなんとなく合わせながらやってきたというようなことは通用しなくなってきます。

こんな問題が想定される中で、メルカリが組織になっていくにつれて、どういった形、どういった組織を目指して、こういった問題にアプローチしているかというのを紹介させていただきます。

初めにメルカリは、同じ思想で開発するといった考え方ではなく、多様な思想を巻き込んで開発していくといった考え方にシフトしていくことを目指しています。小さなチームであれば似たような価値観や、似たような方たちを集めて、同じ方向を向くというのはすごく簡単なんですけれども、組織になると、多様な思想が駆け巡ることになります。

メルカリでは、この多様な思想をもつエンジニアをいかに同じ方向へ向けて開発するかといったことを組織でうまく解決していきたいと考えています。なのでメルカリでは、開発思想のダイバーシティも目指しています。

次に、組織になるんですけれども、個人の能力に依存することも大きなリスクだと考えています。優秀な才能があるエンジニアに依存するというのは、非常に効果の高いやり方ですが、一方で、個人の技量そのものが組織の限界になってしまうという問題も孕んでいます。

多様な能力のエンジニアがお互いにシナジーを生むことで、エンジニア全員の才能が化学反応のようなものを起こし、メルカリ全体の限界を引き上げる。そんな組織のほうが可能性があると考えています。

メルカリの考える技術力は、生産性よりも「創造性」

技術力の考え方についてですが、技術力とひと言で言ってもいろんな捉え方があります。メルカリが考える技術力は、生産性といったものではなく、創造性という新しいものを創る力を重視したいと考えています。

例えば、生産性といったものだけに着目してしまうと、メルカリに1,000人集まったとしても、すでに10,000人いるような会社には太刀打ちができないので、メルカリでは、新しい技術もしくは新しい方法を創造できるような力を伸ばしていく方向で考えています。

最後に、人に関する考え方です。メルカリには今、優秀な人材がたくさん集まっています。この状況で即戦力しか採用しないんですよということにして、組織を作るというのは、そんなに難しくないかもしれません。

ですが、たとえ今、即戦力ではなかったとしても、メルカリで仕事をすることでエンジニアが成長して、優秀な人材になっていくことができるという、成長できる組織というのをメルカリのエンジニア組織は考えています。優秀な人材がただ集まるのではなくて、そこにいる人材が育って優秀になっていくという組織を目指しています。

ここからは、そういった目指している組織について、メルカリがどういった戦略で組織のスケールを考えているのかを紹介します。

まず、組織の体制の話をさせていただきます。メルカリでは、EM/PM体制という形で、Engineering ManagerとProduct Managerという役割を分離することでProduct組織を今作っています。

EM/PM体制にするにあたって、Engineering Managerとは別にTech Leadという役割を今、採用しています。Engineering Managerは主に、採用や育成、あとは配属などを決断するとともに、エンジニア組織がどのようにあるべきかという意思決定も行います。

一方でTech Leadは、組織開発においてどういった技術を用いて開発するのか、どういった設計をするのか、そしてどういった形で品質を守っていくのか、といった部分の意思決定を行っていきます。

いずれも、エンジニアのポテンシャルが最大限に発揮されるように、組織的なアプローチと技術的なアプローチ両方を行っていくことになります。メルカリのEngineering Managerはもちろん、エンジニアをバックグラウンドにしている方がほとんどで、エンジニア自身がどういった組織を作っていくかを考えることで、エンジニアに最適な組織を作っていきます。

決断を最小化する

ここからは、組織ではなくて、技術戦略の話をします。ただ組織の形を考えるだけでは、エンジニア組織はスケールしないと考えていて、メルカリでは、組織戦略といったものと共に、組織のための技術戦略を持ってエンジニア組織を作っています。

その一つの代表的な考え方に、今Micro Decisionという考え方を取り入れています。これは、決断のグループを可能な限り小さくして、決断をしやすくし、一つひとつの決断が起こす悪影響を最小限に落としながら、あらゆる場所で決断が生まれるようにしようといった考え方です。

決断というものは本来、責任が重くて大きな結果を残すといったイメージがあるんですが、そういったイメージを払拭して、決断というものがどこでも、いついかなるときでも起きている状態を作りだそうとしています。もちろん大きな決断をする必要は常にあるんですけれども、日常的にさまざまな決断を繰り返すことで、最終的には大きな決断ができるようになるといった形で考えています。

その決断の最小化を目指すひとつのアプローチが、1年前からやっているMicroservices（マイクロサービス化）というアーキテクチャです。Microservicesはコンポーネントを細かな単位で分解し、独立性を持つ複数のサービスの相互連携することで全体を構成するアプローチのアーキテクチャ（構造）です。

なぜMicroservicesを導入すると決断の最小化が行われるかというと、Microservicesに取り組むことによって、独立したシステムをそれぞれのエンジニアが責任を持って開発・運用することになります。

それによって、オーナーシップが分離し、裁量もそれぞれのコンポーネントに移譲されることになります。

こうして無数の決断が各所で行われるようになって、他のMicroservicesに対しての変更をリクエストするのか、どういった変更のリクエストを受け入れるのかといった決断も生まれるようになります。

Microservicesは今まで、バックエンドのアーキテクチャだと言われていましたが、メルカリでは、フロントエンドのエンジニアもたくさんいますので、フロントエンド、つまりクライアントサイトに関わる部分にもMicroservesのようなアーキテクチャを導入しようとしています。

ここは代表的なものですが、Web では Micro Frontends iOS は Micro ViewController, Android は Layered Architecture といった具合に、それぞれの所で、Micro Decision が可能なアーキテクチャを選択し、推し進めています。どういった技術アプローチで実現していくかというのを考えて、Microservesの方にそれぞれ細かな決断ができるようなアーキテクチャを導入しています。

要所要所で決断が行われる仕組みづくり

それから、マイクロデプロイについても考えています。エンジニアが自ら選択したものを自ら進められるようにデプロイについても細かな粒度で安全に行えるように変わっていく必要があります。

その一つが、Feature Flaggingのシステムです。機能の公開のコントロールや、いつでも機能をオフにできる Kill Switch をまず用意します。クラッシュ率や、コンバージョン、商品の閲覧回数など、いくつかの指標データを集め、これらをシグナルとして受け取ります。

シグナルに1つでも問題があると、その機能のリリースはロールバックされます。問題がなければ、社内から始まり、1パーセントのお客さま、50パーセントのお客さまといった形で、安全であると判断されれば、リリースが行われるといったかたちで、ロールアウトされていきます。

こうすることで、いろんなところでそういった決断が行われるようにしていく仕組みになっています。

それから、Micronize、最小化をどんどん進めていくことによって、もう一つ狙えるメリットがあります。それが、Resilientなシステムです。Micronizeしていくと、急な変更や予測しないような事態が起きたときに、強い耐性を持つシステムを作ることができるようになると考えています。

テックカンパニーは進化する組織でなくてはならない

これはResilientにならないシステムの一例です。Micronizeすると一見システムが複雑化して問題が起きやすくなるんじゃないかと考える方もいらっしゃるんじゃないかと思います。

こちらの絵は船の断面図です。船は通常、バルクヘッドというかたちで敷居が設けられていまして、一部が浸水しても全体が浸水しないような作りになっているんですけれども、実はこの船はタイタニックの断面図で、沈没してしまった船なんですね。

なぜタイタニックは、こうした堅牢に見える構造を持ちながら沈没してしまったのかというと、タイタニックは、タイタニックはもともと4つのコンパートメントまでは浸水しても大丈夫なように設計されていました。

ですが、氷山にぶつかることによって、6つのコンパートメントが浸水してしまったんです。これで何が起きたかというと、水の重さで船の全体が傾いてしまって、他のコンパートメントも浸水してしまって、バルクヘッドが機能しない状態になってしまった。それで、全体が浸水してしまいました。一つの不具合が、他の部分に悪影響を及ぼして、想定しない事態が起きて、全体が沈んでしまったという状況です。

こんなシステムは他にもいろいろあると思います。メルカリももちろん、このタイタニックのようなシステムに、お客さまを乗せるわけにはいかないので、Micronizeしてより高い分離性を保って、それぞれの悪影響がそれぞれを侵害しないようなかたちを目指しています。Micronizeすることでそれぞれの独立性を保って不安定な連鎖反応を防ぐことを目指しています。

このように無数な決断を行えるような環境を作って、あらゆる場所で挑戦と失敗を繰り返すことを可能にすることで、生き物のような進化をしていくプロダクト的な組織を目指しています。

テックカンパニーは進化する組織でなくてはならないという考え方で、メルカリは組織と技術の戦略を考えています。

ここからはメルカリUSのCTOであるMokにバトンタッチしてデータまたはマシンラーニングの技術についてくわしく話していただいて、ちょっとUSの紹介もさせていただきます。ありがとうございます。

（会場拍手）