2021/11/04

メルカリCTOが今、一番頭を抱える課題とは？技術と組織、その両方から振り返る

Author:: braitom

はじめに

メルカリのエンジニアリング組織は、事業規模やサービスのステージに応じてダイナミックに変化してきました。トレンドの開発スタイルを取り入れたり、それをオリジナルな形にアレンジして開発体制を作ったりと、試行錯誤を繰り返しています。

それは開発や組織体制だけでなく、取り入れる技術やコミットする開発領域もしかり。本記事では、メルカリCTOの @kwakasa が、これまでのメルカリのエンジニアリング組織を振り返りつつ、今まさに頭を悩ませながら課題解決にコミットしているプロジェクトを紹介。課題解決の向こう側に見える、理想のエンジニア組織についてまで話していただきました。

インタビューを通じて見えてきたのは、メルカリのミッションを達成するために必要な覚悟と矜持でした。

これまでのメルカリのエンジニアリング組織を振り返る

— wakasaさんがメルカリに入社したのが2019年なので、それから約2年が経ちました。入社前ではあるものの、2019年以前のエンジニア組織はどのような状態だったのか教えていただけますか？

わかりました。あまり昔からの振り返りは難しいので、2017年からいきましょう。メルカリという企業、そしてサービスはプロダクトの強さと、多くのお客さまに支えられて順調に成長を続けてきていました。プロダクトを強化し、さらにレベルを引き上げるために、世界基準のエンジニアリング組織を作り上げるという目標を打ち出したのが、2017年のこと。

世界基準のエンジニアリング組織というのは、世界中から優秀なエンジニアが集まるのはもちろんのこと、世界に通用するプロダクトを作れる開発組織や環境を意味します。これはメルカリのミッションである「新たな価値を生みだす世界的なマーケットプレイスを創る」を達成するために必要なことと言えます。

これが実現できれば、開発からデリバリーまでを高速化したり、お客さまに安全に使ってもらえるプロダクトが提供できる。もちろん、それを支える基盤技術も重要です。この組織作りは2017年から4年経った現在でも、変わらず行っています。

— 2017年からは、より世界を意識した体制作りに一歩踏み込んだというわけですね。では、続いて2018年はどうでしょう？

2018年の大きな変化としては3点あります。

EMを導入する以前は、プロダクトオーナーがエンジニアやデザイナーをマネジメントしていました。それを、EMがエンジニアを評価する仕組みへ変更。私自身、「エンジニアはエンジニアが評価すべき」だと思っているので、これは世界基準のエンジニアリング組織を目指す上でも大事なことだったと感じています。

続いてマイクロサービス・マイグレーションですね。それまでのメルカリのシステムはいわゆるモノリスでした。モノリスは1つのバックエンドにビジネスロジック、データベースが収まっている状態です。決してモノリスが悪い訳ではありませんが、モノリスはあらゆるビジネスロジックやデータが密結合になりがちです。密結合だとシステムの小さな変更があらゆる箇所に及ぶので、開発に時間を要します。それを改善するために、マイクロサービス化を推進しました。
※ メルカリのマイクロサービス移行の進捗 (2019年冬)

外国籍エンジニアの採用についても着実に成果が出ています。現在メルカリのエンジニアリング組織では東京オフィスに在席する約半数が外国籍エンジニアです。

— 今のメルカリでは当たり前とされている方法は、この2018年の整備によるものだったのですね。では2019年についてはいかがでしょう？

2019年の大きな変化は3点あります。

メルペイは2019年2月13日にリリースしています。この時、社内の多くの開発リソースを投入してリリースしています。外国籍のエンジニアが増えていたり、マイクロサービス・マイグレーションも進めていたこともあり、EMの負担は相当大きかったはずです。

また、アジャイル開発フレームワークとしてスクラムを導入したのも2019年です。現在は、ほぼ全てのチームがアジャイル開発を行っています。

最後にフロントエンド・バックエンド体制の確立ですね。これはマイクロサービス・マイグレーションに関係しますが、バックエンドチームを新機能開発から距離を置いて、アーキテクチャ移行に集中するために体制を分けました。そのため、機能開発はフロントエンド側に委譲する形をとりました。

— そして去年、2020年ですね。

そうですね。2020年は主に2点あります。

まず、Camp Systemの導入が大きかったです。2019年からフロントエンド・バックエンド体制で進めていたのですが、コミュニケーションコストの大きさが顕在化しました。フロントエンドで新機能を作る場合、バックエンドが無関係で済むことは多くありません。また、1つの機能だけを変更して終わることも多くはありません。ある機能を改善すると、関連して別な機能も影響を受けます。そうなると他チームとのコミュニケーションコストが大きくなります。

それを改善するために導入したのがCamp Systemです。これはSpotifyのSpotifyモデルを参考に、メルカリ流にカスタマイズしたものです。よりクロスファンクショナルなチームにしようということをキーワードに、1つのCampの中にEMとPMはもちろんのこと、フロントエンド、バックエンドさらに機械学習エンジニアなどあらゆる役割の人が所属します。そしてCamp内でコミュニケーションして、お客さまに価値を届けるという体制に変更しました。

そしてフロントエンドを刷新するプロジェクトがはじまったのも2020年です。まずWeb版からですが、スクラッチから開発して先日リリースしました。

— ついに2021年、今年ですね。

2021年は、まさに今取組んでいる、ビジネス共通基盤における複雑な技術的問題の解決ですね。大規模にリファクタリングしていく取り組みで、社内ではRobust Foundation for Speed、通称「RFfS」と呼んでいます。

— RFfSについて詳しく教えていただけますか？

はい。RFfSを行う要因はいくつかあるのですが、まず大事なのはお客さまに安全に使ってもらえるプロダクトを作るためには、基盤強化が欠かせないということです。もちろんこれまでも基盤への投資は行っているのですがさらなる投資が必要と考えました。

一方で、C2Cマーケットプレイスを超えてビジネスを拡大していく上では今以上にスピード感を持って新たなチャレンジにもしていかなければなりません。これを行うためにも堅牢な基盤(=Robust Foundation)はかかせない。堅牢な基盤とスピード感のある開発、この2つを両立させて実行できるようにと打ち出した方針がRFfSとなります。
これまでの技術的な取り組みを階層構造で見ると、次のようになります。

モバイルアプリやWebアプリなど、お客さまが実際に触れる部分の改善に取り組んでいるのがフロントエンド刷新プロジェクトです。そして下層に当たるインフラ部分の改善がマイクロサービス・マイグレーションです。RFfSはその中間に当たるビジネス共通基盤を強化するプロジェクトになります。

RFfSとして最初に取り組んでいく領域はいくつかあります。まず、メルカリでトランザクションと呼んでいる商品売買に関わる部分です。2つ目が認証認可に関わるIDプラットフォーム、そして3つ目としてお客さまのサポートに関するCSツール（カスタマーサポートツール）になります。他にもセキュリティ強化も行います。

RFfSに期待すること

–これまで2017年から2021年までを振り返っていただきましたが、やはり気になるのが「RFfS」の取り組みですね。このプロジェクトを実行、そして成功させるうえで必要となるポイントは何でしょうか？

RFfSが立ち上がったきっかけの1つに、基盤部分の複雑さによる開発スピードの低下があります。これは体感や主観に依るところが大きいですが、ちょっとした変更であっても、それなりに時間を要するようになってきていると全員が感じていました。そのため、まず現状を可視化することで、RFfSによる改善を見たいと考えています。そのために、開発状況や、開発の生産性を可視化するためのプロジェクトも並行して進めています。

また、「開発スピードを2倍に」のような絶対値的なゴールは設けていません。大事なのはお客さまに安全に使ってもらえるプロダクトを迅速に提供することです。そのためには、必要な機能やサービスを素早く実装して、デリバリーしなければいけません。RFfSによって、見積もっていた時間と実際に要した時間の差が小さくなっていく、改善していくのがゴールになります。

メルカリのエンジニアに求められるマインドセット

— では次に現在の組織的課題について教えていただけますか？

一言でいうと、マインドセットとして「Accountable Autonomy」を浸透させたいです。Accountable Autonomyの意味としては「自立性を持って主体的に仕事にあたる」になります。

前述の通り、メルカリではCamp Systemやマイクロサービス化を進めたことで、各チームでシステムを改善し、リリースできるようになっています。これは自律的に意思決定ができるチームが、より自主的に開発を進める「Microdecision（前CTOである @suguru が提唱）」そのものです。私はそれをさらにアップグレードしたいと考えています。

もちろん、Microdecisionは大事です。しかし、忘れてはいけないのが、自分たちがどんな課題を解決するのかという視点です。個々のチームに最適化されていくと、全体像が見えづらくなります。注意すべきことは、独りよがりにならないことです。メルカリはいわゆるテクノロジープロバイダーではなく、お客さまにプロダクトを提供する企業です。お客さまに価値を提供するという視点を、常に持っておかなければなりません。

さらに受け身ではなく、エンジニア自身が能動的に課題を見つけて、それを積極的に解決していく姿勢が大事です。私はエンジニアは「課題解決者」であるべきと考えています。

こうした考えを示したのがAccountable Autonomyになります。Accountable Autonomyのマインドセットをエンジニアリング組織に根付かせることができれば、メルカリのエンジニアリング組織は世界基準にたどり着けると信じています。

— 課題そのものの難易度が高くなっているからこそ、より「課題解決者」としてのマインドが求められるということでもありますよね。

そうですね。メルカリには、まだまだ多くの難しい課題が残されています。そうした課題を自主的に解決できるエンジニアが必要です。

メルカリではD&I（ダイバーシティ&インクルージョン）を重視した採用活動を行っています。これは主に性別や年齢、価値観などの多様性という意味です。私はエンジニア領域においてもダイバーシティが大事だと考えています。

新機能開発が好きだったり、インフラをしっかりやりたかったり、DX（開発者体験）改善をやりたいなど、様々なエンジニアがいると思います。これは興味ある技術スタック、事業ドメイン、サービス規模によって異なるでしょう。そうした幅広いエンジニアリング領域で活躍できる場がメルカリにはあることを知って欲しいです。

大事なのは、特定の手段にとらわれず、やるべきことをきちんとやること。課題を解決できるエンジニアと一緒に世界基準のエンジニアリング組織を作っていきたいですね。

— ありがとうございました！