「この1年、組織の変化に立ち会い続けてきた」マイクロサービス化に向き合うメルカリEMの試行錯誤 #eof2019

2019年10月31日、「エンジニアリング組織をもっとオープンに」をビジョンに、エンジニアリングマネージャー（EM）やエンジニアを対象としたイベント「Engineering Organization Festival 2019（EOF2019）」が開催されました。

メルカリではイベントスポンサーを務めたほか、メルカリ・メルペイメンバーも登壇。特に後藤秀宣（メルカリBackend、EM）と石川直樹（メルペイiOS、EM）は、「メルカリ・メルペイのエンジニアリング組織の変化〜Engineering Managerの視点から〜」と題して、今まさに開発現場でのマネジメントでぶつかっている壁と、その乗り越え方、理想の体制を語りました。

そこでメルカンでは、後藤と石川による登壇レポート記事を公開。前編となる本記事では、後藤のパートをお送りします。冒頭から「メルカリ・メルペイの詳細より、苦労話をみなさんに共有したいというのが本日の目的です」のひと言で始まった後藤のパート。2018年11月にメルカリへ入社し、約1年経った後藤。そんな彼がメルカリ開発現場で直面したマネジメントでの壁とは何か？

「マイクロサービス化による組織の変化に立ち会い続けてきた1年だった」

後藤：メルカリとメルペイの違いは「最初からマイクロサービスで開発が進められていたかどうか」です。メルカリは、サービス開始からモノリスで開発が行われていました。一般的にモノリスは、どれだけうまく設計していても、大人数で開発を同時並行しようとすると生産性が落ちてしまう問題があります。メルカリでも、同様の問題が起こり始めていたのです。そこで、2年ほど前からマイクロサービスに取り組んできました。

後藤秀宣（メルカリBackend、エンジニアリングマネージャー）

後藤：マイクロサービス化については、すでにいろいろ勉強されている方も多いのでご存知かもしれませんが、モノリスをPHPからGoに書き換えたり、システムを置き換えたりするだけでは、十分ではありません。開発を行うエンジニアの考え方や、それをまとめあげるための組織の再構築にも同時に挑戦していかなければならないのです。

ーそこで、後藤が例に上げたのが「コンウェイの法則」でした。「コンウェイの法則」とは、メルヴィン・コンウェイが提唱した「アーキテクチャは、組織の構造を反映させたものになる」という法則。この法則と向き合い続けてきたという後藤は、メルカリでのマイクロサービス化を体験しながら、あることに気づいたと話します。

後藤：コンウェイの法則の記事には「組織構造は、組織がつくるもののデザインに影響や制限を与えたりする」だけでなく、「デザインという仕事を行う組織では、コミュニケーションの必要性に応じて組織を設計すべきだ」と書かれています。つまり、コンウェイの法則を提唱しつつ、その逆もあることをメルヴィン・コンウェイさんはすでに見抜いていたのです。

後藤：僕としても最近、コンウェイの法則は人間の社会的行動と本能的行動を法則として表現しているんだなと感じています。例えば、物理的に近い距離にいるメンバーやチーム同士のほうがノウハウを共有しやすく、仕事もうまく進みます。一般的にも成功する組織のかたちですが、これは単に人間の本能に従っているから仕事がしやすいとも言えるのではないか。そうなると、逆らいがたい気がしますよね。僕自身、メルカリでの1年は、「マイクロサービス化によって組織が変化していく瞬間に、メンバーと立ち会い続けてきた」と言っても過言ではない。同時に、コンウェイの法則と戦いながら組織をどうしたらいいのかを考え続けていたと言ってもいいかもしれません。

ドメインチーム誕生、その矢先に知見を持つエンジニアたちが…

ー「組織の変化に立ち会い続けてきた」「コンウェイの法則と戦い続けてきた」。そんな後藤は、この1年でどのような試行錯誤を続けてきたのでしょうか？

後藤：1年くらい前までは、メルカリの開発組織はマトリクス型構造でした。エンジニアはプロダクトマネージャー（PM）が率いるプロジェクトにアサインされ、開発が進められていたのです。それと並行して、マイクロサービス化は専任のプロジェクトチームで進められていました。そんななか、2019年1月ごろに、専任チームによるマイクロサービス化の成果が出たことをきっかけに、Backendチーム全体で本腰を入れて開発を推し進めていくことになったのです。そこで誕生したのが「ドメインチーム」でした。さらに約9ヶ月ほど経ち、なんとなく成熟し始めているのが今のフェーズです。

ーここで、後藤が強調したのは「マトリクス型組織からドメインチームへ変わった背景」「マイクロサービス化を行うチームとそれ以外のチームの分断化」。

後藤：まず「マトリクス型組織からドメインチームへ変わった背景」について。先ほどお話ししたように、1年ほど前のメルカリでは、基本的にはプロジェクトにエンジニアがアサインされ、開発が進められていました。ここでの問題は、エンジニア同士でチームをつくりづらく、育成が進まないこと。また、四半期ごとにアサインされるプロジェクトが変わることも多く、ドメインごとのナレッジが蓄積されない問題もありました。

そしてもう1つが「マイクロサービス化を行うチームとそれ以外のチームとの分断化」。マイクロサービス化は独立したチームが進めていたので、それ以外の開発を行うチームとの分断化がわりと深刻でした。そういった問題を解決するためにもドメインチームを誕生させ、出品や配送、会員登録などプロダクト機能ごとにドメインを分けて開発を進めていたのですが…。

ードメインチームが誕生し、いよいよマイクロサービス化を加速できると意気込んだところ、状況が一変。なんと、マイクロサービス化の知見を持つエンジニアたちが、別のプロジェクトへコミットしなければならない事態に陥ったのです。

後藤：早い話が、マイクロサービス開発に知見のある有力なエンジニアたちがほぼ全員抜けてしまったわけです。その結果、ドメインチームは誕生したものの、技術や知識がぜんぜんない状態からスタートすることになりました。そのため、2019年1〜3月までは、ひたすらみんなでノウハウを溜める修行のような辛い日々が続いていたのです。4月ごろになると、チームごとにノウハウのキャッチアップができるようになり、徐々にマイクロサービスをリリース。それ以降も、チームやメンバー間でマイクロサービスをつくるための技術が成熟していくような手応えを感じました。

マイクロサービス開発とフィーチャー開発のバランスをとる難しさ

ーようやく軌道に乗り始めた、マイクロサービス開発。ところが、しばらくして後藤は「全体的に生産性が下がり始めているのではないか？」と感じ始めます。現場メンバーにヒアリングしてみたところ、わかったのはマイクロサービス開発とフィーチャー開発（新機能や施策のための開発）のバランスをとるために起きていた、2つの問題でした。

後藤：そもそも、あらゆる開発がチーム内で完結することは少なく、ほとんどが複数のチームを横断しながら進められていました。マイクロサービスの開発も、さまざまなチームやメンバーとのコミュニケーションをとらなければ進められませんでした。このようなコミュニケーションにエンジニアの負荷がかかりやすい問題があったのです。

もう1つは、仕様や開発のアウトプットを出す議論より「この開発をどのチームでやるべきか」を議論する時間が多くなりすぎていたということ。本来は結論を出すための話し合いのはずが、平行線のまま終わることも多く、生産的ではない時間を使いすぎている問題も起こっていました。これは、そもそもチームの切り分けが曖昧だったり、ゆがんでいたりしたために起きたアーキテクチャの問題でもありました。

ー現在起きている問題を把握し、その分析もできている。では、メルカリ開発組織は解決に向けて、どのようなステップに進めればいいのか？後藤は個人として考えたビジョンを明かします。

後藤：メルカリは、事業会社です。どんどん成長していかなければならない。そのなかで、継続的なイノベーションを加速度的に生み出す必要がありますし、それを支えるシステムにしていかなければならないと考えています。では、継続的なイノベーションを支えるにはどうすればいいのか？キーワードは「マイクロディシジョン」です。これは、自律的に意思決定ができるチームがより自主的に開発を進めるために、メルカリのエンジニア組織内で掲げているキーワードでもあります。

そしてもう1つ大事なことは、プラットフォームとしてお客さまに安心安全を提供する状態をキープすること。メルカリは、多くのお客さまに使っていただいているサービスです。そのサービスを壊したり、不安定にしたりするようなことはあってはならない。継続的なイノベーションを支えつつ、常にお客さまにとって安心安全な状態がキープされている。この2つの考えがチームごとに浸透している状態をつくることこそ、今現在起きている問題を解決する糸口になると考えています。

組織として大事なところを守りつつ、壊していくような柔軟性

ー「とは言え、正解はわからない」と、後藤は続けます。

後藤：理想はあれど、はっきりとした正解があると僕は思っていません。組織は、人でできています。そして人は組織内で活動し、成長し、変化します。組織も、人の属性や数によって常に変化します。そうすると、その変化に合わせた最適なチーム構造を常に考えなければならない。組織として大事にすべきことを守りつつ、常に壊していくような柔軟性も持ち合わせたほうがいい思っています。

「柔軟性」と、言うだけなら簡単です。変化には、メンバーのモチベーションや生産性が下がってしまうなど、リスクはつきもの。そういったネガティブインパクトを最小限にするため、メンバー全員に理解を示してもらえるようなカルチャーをチューニングしていく。そういったゴールを目指しながらいい方法を模索し、PDCAを回し続けていれば、いつか理想的なチーム構造を導き出せるのではないかと考えています。

ーこの言葉で、自身の発表を一区切りさせた後藤。続いて発表を行うメルペイiOSチームのEM・石川直樹へと登壇のバトンを渡したのでした。

後藤秀宣（Hidenori Goto）

PHPメンターズでソフトウェア設計を中心に活動していた。2018年11月に株式会社メルカリに入社後はマネージャー職に。メルカリJP BackendチームのEngineering Managerとして、メルカリ本体をモノリスからマイクロサービスへ移行するプロジェクトにも関わっている。システムと組織の両面での変革に奮闘中。

後藤による当日の登壇資料はこちら