2013年のサービス開始から8年が経ち、月間利用者数が2,000万人を突破したメルカリ。しかし今、表向きの成長の裏側で大規模な開発基盤の見直しが全社をあげて進められています。

そのプロジェクト名は「Robust Foundation for Speed（以下、RFS）」。メルカリグループ全体の非連続的な成長を支えるために、ビジネス共通基盤の複雑な技術的課題の解決と抜本的な強化を図るプロジェクトです。

今回のメルカンでは、「RFS」と名付けられたこの大規模プロジェクトに関わるキーパーソン4名を取材。それぞれのキャリアにフォーカスしながら、なぜ開発基盤の大幅な見直しを“今”行うのか。どのような形でプロジェクトに携わっているのかを語ってもらいました。メルカリCTO若狭、RFSのプロジェクトオーナーである塚に続き、登場するのはメルカリの「トランザクション（取引）」領域を担当するBackend teamのエンジニアリングマネージャー、後藤秀宣（以下、@hidenorigoto）です。

※撮影時のみ、マスクを外しています

子ども時代の「マイコン」がプログラマーのルーツに

ー@hidenorigotoさんは、なぜエンジニアの道を選んだのでしょうか？

エンジニアの道を「選んだ」という感覚はなく、子どもの頃からなんとなく「自分はプログラマーとして仕事をするんだ」と思っていました。僕が小学生の頃にパソコンの先駆けとなる「マイコン」が流行っていて、僕の父親もそれを買ってきておもちゃとして使っているところを、僕も使わせてもらっていたんですよ。

当時は今のパソコンとは違い、画面にベーシック言語を自分で入力することで、音を鳴らしたり簡単なグラフィックを描いたりするものでした。でも、僕にとって自分が入力したプログラム通りにマイコンが動くことが当時めちゃくちゃ面白かったんですよね。なので、小学生時代はゲームで遊びつつ、一方でマイコンにプログラムを入力して何かを作ることにも熱中していました。

ー子どもの頃からすでにプログラミングに触れていて、仕事にしたいと考えていたんですね。それでは、社会に出てからはすぐエンジニアの道に？

実は、そこは少し紆余曲折がありまして。高校時代は受験勉強に専念し、パソコンのことは一度忘れていました。入学した大学も情報系ではなく理学部で、その道をしばらく進んでいました。でも、「どうもこの道はアカデミックすぎて自分には合わない」と気がつきました。

改めて自分のやりたいことを考えたときに「そういえばプログラミングが好きだったな」と思い出しました。そしてパソコンを買ってプログラミングしてみたら、「やっぱりこれで仕事をしたい！」となったんです。そこからは、改めてコンピューターサイエンスを独学で学び、就職の準備をしていきましたね。

ーそこから、どのような経歴を？

最初はアルバイトとして小さなソフトウェアハウス（ソフトウェアを開発・販売などを行う会社の総称）に入社し、プログラムを作る仕事をしながら腕を磨き、そのままその会社に就職しました。それからは自分で小さな会社をやってみたり、どちらかというとソフトウェアのエンジニア、いちプレイヤーとしてソフトウェアを作ったりデザインする方が多かったです。

ー子ども時代に感じた「コードを書いてパソコンを動かすのが楽しい」という感覚は、就職してからもずっと変わらなかった？

そうですね。コードを書いて人の役に立つという経験も持っていたので。コードを書くことの楽しさと、人の役に立ちたいという気持ちは変わっていません。

後藤秀宣（Hidenori Goto、@hidenorigoto）

ある問題意識から、エンジニアリングマネージャーへ転身

ーそれからエンジニアとしての経験を積み、メルカリではマネージャーという役割も担っていますよね？

キャリアとして本格的にマネージャーとなったのはメルカリからですね。メルカリに来た時点ではプレイヤー寄りの視点だったので、「ソフトウェアそのものの問題を解決すれば全て上手くいく」と思っていたところがありました。でもメルカリに入って3年経った今、開発組織や、人の動き方のようなところも上手く整理していかないと、ソフトウェア側の問題は再生産されてしまうという課題が見えてきた気がします。

ー具体的にどういうことですか？

もちろんメルカリはサービスとしてきちんと成長していて、ビジネスとしてもここまでの規模に拡大している。その背景には、どちらかというと「成長」や「新しいこと」に気持ちが向けてきたところがあるんです。会社の成長にすごく貢献してきたから良いことなんですが、同時にネガティブな側面もありました。それが「いらなくなったものをきちんと捨てていこう」ということに対して、あまり積極的じゃなかったところでした。

ー新しいものを作っていくところに比重があって、捨てるところにはあまりなかったということですね。今もその感覚はある？

「捨てる」ための組織的な仕組みがもっとあっても良いんじゃないかと思っています。例えば、プロダクトマネージャーや開発チームがある程度作りきった機能があります。しかし次のクオーターからは全く新しいことをやり始めていて、以前作った機能が不要となったとき「削除していいかどうか」を直ぐに判断できないことが起きているんです。

これは誰も悪くないことなんです。とはいえ、ソフトウェアは人間がメンテナンスをしていかなきゃいけないし、一人だけが把握できるサイズには限界があるんですよね。そういった意味でも、普段から「いかに小さくしていくか」という意識を、エンジニアとしてはもちろん、組織として持つことが必要なんだろうと感じています。

ーその辺りの課題に対して、@hidenorigotoさんご自身、もしくはチーム内で新しく取り組んだことはありますか？

これまでの実例を言うと、定期的にリファクタリングをOKRに入れて「コードを削除すること」にフォーカスしてきました。でも、エンジニアの反応は人によって異なります。経験があるエンジニアたちはリファクタリングの重要さをわかっているので、OKRに入れてアクションすることには賛成してくれます。しかし、僕もエンジニアたちも、ずっとそれをやり続けることが正しいとは思っていないんですよね。リファクタリングがビジネス貢献しているか・会社が評価するかというと、それは少し違うと思うので。

ーやはり新しいものを作ったり、グロースに寄与するところにどうしても目が行きがちなので、なかなか難しいところですよね。

なので、「ビジネスグロースのためにやる」「ソフトウェアをシンプルに小さく保つ」の両輪を常にやり続けることが、特に開発基盤を担うチームにおいては必要だと思っています。それを今取り組んでいる「Robust Foundation for Speed」のCamp4（メルカリの「取引」領域を担当するファンクション）のミッションで言うと、「ビジネスグロースに貢献するのと、サービスとチームをヘルシーに保つ」ですね。

ーちなみに、メルカリに来て感じたギャップはありますか？

いろいろありました。入社前までは、メルカリAPIという基盤PHPのコードはもっと整っているんだろうなと思っていたんです。ところが、実際にコードを見て、これはけっこう腰を据えてやらないとダメだろうなと（笑）。

ー外から見たらもう少し整理されていた印象があったんですね

ありましたね。メルカリのバックエンドシステムは、機能はちゃんと作られているんです。しかしながら機能群、つまりアーキテクチャがどうあるべきかについてはあまり積極的に議論されていませんでした。例えば現状だとメルカリの配送機能に新しい配送方法を一つ追加するだけでも、けっこう大変なんですよ。

なぜなら、配送系を扱っているチームだけでは終わらず、それに関連する出品や決済のチームと連携しながら決めていかないといけないから。こういったことは配送だけでなく色んな機能に対して起こっています。これが、開発スピードを遅くしている要因にもなっているんです。

ーそういった課題への対策はあるんでしょうか？

僕が考えているのは、メルカリUS（メルカリの米国事業）で導入されている「抽象概念」をメルカリJPでも取り入れることです。

メルカリUSでは取引のところに「注文（order）」という概念が入っている。ところがメルカリJPではアイテム・お客さま・取引だけが個別にある。取引では、ただ一個のアイテムしか扱えないんですね。メルカリUSは取引とアイテムの間に「注文」の概念を入れたので、そこを少しいじるだけで複数のアイテムを取引の括りで扱えたり、ひとつの注文の中で寄付したいところにお金を回したりといったやりくりができるんです。メルカリJPにもこの概念を入れることで、色んな可能性が広がると思います。

「RFS」ではメルカリAPIの取引機能にアクションを起こす

ー今後メルカリが注力していくRFSについても聞かせてください。@hidenorigotoさんはトランザクションの部分でプロジェクトにどう関わっていくんでしょうか？

まず、このプロジェクトには委員会があり、各Campの活動を後押しするような構成になっています。基本的には、各Campが担う領域でRFSが掲げる方向性に沿ってプランニングし、アクションを起こします。僕はCamp4のエンジニアリングヘッドなので、その中でRFSに合致するビジョンや問題をきちんと見出して定義し、進めていくのがおおまかな仕事です。

直近では、一番大変なプライマリーフォーカスエリアに選ばれている取引機能の領域で、問題設定をしてプロジェクトを立ち上げ、メンバーが動くまでのアクションプランの設計までを進めました。現在はチームにプランが落とし込まれているので、メンバーが実際に動いているところです。こういった戦略設計を事前に行ったことで、次のクオーターからはチーム全員がある程度しっかりとしたゴールに対する共通理解を持ち、最初から一定のスピードで動けるようになると期待しています。

ー他社目線を含めて、最初にメルカリの基盤を見てどう思いましたか？

最初は「ソースコード的に大変そうだな」と思いました。それがソースコードだけの問題じゃなく、組織的なアーキテクチャの概念をきちんと作っていくことが必要となりそうで、そこに対しても大変そうだなと。

前職はメルカリよりもずっと小規模な会社だったので、エンジニアリングについては全体を見渡してさまざまな意思決定ができていました。モジュール化の成功体験もあったので、先程話した「抽象概念」の必要性をメルカリで改めて感じました。

ーCamp4では、具体的にどういうことに取り組むのか教えてください

メルカリAPIというモノリスなレポジトリーの中には取引の機能とそれ以外の機能がありますが、現在は取引の機能が周りのさまざまな機能と密結合しています。そのため、取引の機能だけを変更しづらい状態なんです。そこでCamp4では、まず取引の機能を疎結合な状態にしようとしています。

疎結合化をするにあたっては、一体どれくらい・どんな種類の密結合があるかの数値的な全量調査や中身の定性的な理解が必要。この四半期では中身の理解に対する分析アクティビティと、密結合になっているところを自動的に検出できるスクリプトなどを作って調査を進めようとしています。次の四半期からは、実際にコードをリファクタリングしていく予定です。

問題の根本解決ができずに、がっかりしたくない

ー今回のRFSのプロジェクトへ取り組むにあたり、どのようなところが一番のモチベーションになっていますか？

僕には、プログラマーとして以前から強く持っている根源的なモチベーションがあるんです。それが「問題をきちんと根本から解決したい」ということ。今まで、それができずにガッカリした経験も多々あります。今回のRFSはおそらく、今見えている問題を根本から解決できるプロジェクトだろうと思っています。そこにモチベーションを感じていますね。

ー「根本的な解決」をすることは、メルカリの歴史に残るような大きな取り組みだと感じます。その辺りもモチベーションにつながっている？

そうですね。今回僕が関わるのは、これまでメルカリが事業を伸ばすためにさまざまな施策を積み重ねてきた領域の1つなので、変更が特に難しいところなんです。正直なことを言うと、今のまま放っておいてもメルカリ自体は動くわけです。だけど、さらにメルカリがグローバル展開などを含めて成長していくためには、まだまだ変わっていかなければいけない。これはエンジニアリングだけの話ではないからこそ、ますます難しい課題なんです。

だからこそ、僕がマネージャーという立場でこのプロジェクトに臨めるのは非常に大きなチャレンジだと思います。そして、同じ経験を他社でもできるかはどうかはわからない。もしかしたら「一生に一度しかないかチャンスかもしれない」とさえ思っているので、どうしても中途半端にはしておけない僕がいます（笑）。このチャンスをぜひモノにして、きちんと「やり切った」と言いたいですね。

ーでは、候補者の方にRFSに取り組む魅力を伝えるとしたら？

今回のRFSの取り組みは、エンジニアの技術的にもかなり難易度が高いです。その分、これからメルカリや、もちろん他社でもさまざまなサービスを作ってスケールしていくときには確実に役立つスキルと経験になると思います。

さらに言うと、PHPでこれだけ大きいプロダクトがあり、かつビジネスの中の一番大事な部分を支えている領域に関わることになるので…。PHPエンジニアにとって、そのような対象に出会う確率はなかなかない。そういった珍しさもこのタイミングでRFSに取り組むメリットつながる気がしていますね。

ーエンジニアがこういった大胆な改修に取り組みやすい環境があるというのも、会社としてのひとつの魅力なんですね。

本当にその通りだと思います。こういったプロジェクトは往々にしてエンジニアが「やりたい」と思っていても、会社としては「できない」ことが多い。それがメルカリではOKRに入っていて、むしろどんどんやってくれと後押しをしてくれる環境がある。

エンジニアの人たちにとって「鬱憤を晴らす」じゃないですが（笑）。エンジニア界隈には「怒り駆動開発」という言葉もあるくらいなので、そういったモヤモヤをもし抱えている人がいれば、存分に取り組める良いチャンスだと思います。

おわりに

この記事を通して、メルカリが取り組む「Robust Foundation for Speed」プロジェクトに携わるキーパーソンの思いが伝われば幸いです。そして現在、この大規模な取り組みを一緒に成功させるための仲間を募集しています。

少しでも興味を持っていただけたら、ぜひ以下の特設サイトをチェックしてみてください。より技術的な話をプロジェクトメンバーが語る「mercari engineering」の記事や、採用イベント情報がまとまっています。

応募はこちらから！ぜひお気軽に！