メルカリの事業とエコシステムをいかにサステナブルなものにするか?かつてない大型プロジェクト「GroundUp App」の道程

メルカリグループにとってかつてないほど大きな取り組み、フロントエンドを刷新するプロジェクトとしてはじまった「GroundUp App(*開発コード名)」。多くの人の手と知恵、そして時間をかけることとなった、このプロジェクトはなぜスタートしたのか、そしてこれからメルカリがなにを目指すのか。2年半にわたった長期プロジェクトの道のりから、「GroundUp App」のキーマンであるメルカリCTO・若狭建(@kwakasa)と、Business FoundationのDirectorである宮坂雅輝(@mmiy)が振り返ります。

この記事に登場する人


  • 若狹建(Ken Wakasa)

    東京大学大学院工学系研究科情報工学専攻修了。Sun Microsystems、Sonyでハードウェア(携帯電話・AV機器)関連のソフトウェア開発を担当。GoogleにてGoogle Mapsの開発に従事した後、2010年以降、Android OS開発チームでフレームワーク開発に携わる。Appleでのシステムソフトウェア開発、LINEでのLINEメッセンジャークライアント開発統括を経て、2019年8月、Director of Client Engineeringとしてメルカリに参画。2021年7月、執行役員 メルカリジャパンCTOに就任。


  • 宮坂雅輝(Masateru Miyasaka)

    マイクロソフト、株式会社楽天、株式会社ファーストリテイリングでさまざまな国内及び、グローバル向けの製品のプロダクトマネージメントを行うとともに、開発組織強化のためにAgile開発の導入、オフショア開発拠点の立ち上げなどに従事。2018年9月、株式会社メルカリに参画。現在はProducts FoundationのDirectorを務める。

ある意味、メルカリのエンジニアリングは敗北を味わった

──まず、「GroundUp App」が始まったきっかけから教えてください。

@kwakasa:新しいメルカリのWeb版のプロジェクトが始動した3〜4ヶ月後の2020年半ばぐらいですね。プロダクトマネージャーとデザイナーから「Webだけではなくアプリもアップデートしたらどうか」という話が出たことがきっかけです。

ただ、僕は基本的には「ソフトウェアは書き換えるべきではない」と思っています。ソフトウェアの改善活動は基本的にリファクタリング(外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること)していくやり方が王道で、書き換えはある意味エンジニアリングの敗北です。

Webの場合はアプリほど大きな投資をしてきたわけではなかったこともあり、「もう一度つくりなおそう」というコンセンサスを得やすかったのですが、アプリはかなり投資してきていましたからね。アップデートの提案を受けたときも「やりたくないし、やるべきではない」が本音でした。

若狭建(@kwakasa)

@mmiy:それにも関わらず書き換える意思決定をしたのにはいくつか理由があります。

ひとつは、当時アプリはそれぞれ個別対応しながら機能ごとに必死に書き直そうとしているタイミングだったのですが、途中で止まっている状態がいくつか見られ、かつ実装のパターンもUIごとに複数検討されている状態で、非常に見通しが悪かったこと。

もうひとつは、プロダクト視点で考えたときに全体感を見ながらUIをチューニングしていくことが難しかったこと。象徴的なトピックがダークモードの実装です。UIごとに実装が異なっていたので、ダークモードを導入しようにも時間もコストもかかる状況でした。部分的に進めていくことはかなり難易度が高く、「もしかしたら全部書き直す方法もあるのかも…」という考えが頭をよぎりました。

@kwakasa:日本国内で主流のプラットフォームとしてスマホが使われるようになって2022年で10年ぐらい経ちますが、「メルカリ」のアプリがローンチしたのが2013年ですからね。スマホの世界は10年も経てば、ハードウェアもアプリの作り方もかなり変わります。2018〜2019年ぐらいにネイティブアプリ開発もWebの影響を大きく受けて、iOSもAndroidも、FlutterとかReact Nativeのようなモダンなフレームワークを取り入れ始めました。

メルカリでも業界の流れにキャッチアップするために、いくつか部分的にプロジェクトを走らせたのですが、どうしても優先順位が上がらない状況が続いてしまって…。

@mmiy:メルカリは意思決定がスピーディーに変わるので、この手の時間が長くかかるプロジェクトを部分部分で進めていると、優先順位が上がらず途中で終わってしまうことがあるんですよね。

@kwakasa:技術的にもっとよくないのが、途中までやりかけた状態のものが残っていることです。本来であれば未完成のものは捨ててしまうべきなのですが、リソースをかけてきているし、まだ途中だから残してしまっている。「兵どもが夢の跡」みたいな状態です…(笑)。

@mmiy:事業の成長スピードと組織の成長スピードがちょっとマッチしなかった結果ですよね。もちろん、エンジニアがものすごく頑張ってきた成果であることは間違いないのですが。

宮坂雅輝(@mmiy)

メルカリが真のテックカンパニーになるために

──プロジェクトがスタートした背景がすごく複雑に絡み合っていることはよく理解できました。

@kwakasa:こうした事情もあったので、「GroundUp App」は限られたメンバーでステルスに近い形でスタートしました。

@mmiy:「2013年のメルカリ」を小さなチームでつくるようなイメージですね。フェーズとしては、まずPoCでの技術的な検証フェーズ、必要最低限のコア機能の開発フェーズ、最後がレガシーなアプリの機能に追いつくフェーズの3段階。最初の2つのフェーズは小さいチームでやりましたが、3つ目のフェーズは全チームを巻き込んでやりました。

@kwakasa:特に3つ目が大変なんですよ…。正直反省点も多い。メルカリというテックカンパニーの成熟度に関わってくる部分ですから。エンジニアリングやビジネスの捉え方が問われるので、メルカリが真の意味でのテックカンパニーになるには乗り越えられなければいけない大きな壁です。

──どのように乗り越えようとしているのでしょう?

@kwakasa:GoogleとAppleが発表した宣言的UIのライブラリが「今後のクライアントアプリの基準になっていくだろう」という方向性に賭けました。そこに対して「やりたい」という気持ちの強いエンジニアを集めました。採用だけでなく、内部の異動も含めて。事業が重要であれば「完全に枯れた技術のみでやる」という意思決定がなされてもおかしくはないのですが、「グローバルなエンジニアリングの流れに乗っていこう」というコンセンサスが取れた点は、バリューで掲げる「Go Bold」だったと思います。実際に、世界の有名なテックカンパニーと近い意思決定ができたわけですから。

@mmiy:バリューに関連する話だと、ヘルプが必要なときに「All for One」的にサポートしてくれる人の存在は非常に大きかったですね。プロジェクトは必ず苦しいタイミングに直面するものです。でも、それぞれ必要な人が集まって、最終的に問題解決するまでやり遂げてくれた。みんなでやり抜くカルチャーがあることを実感しました。

@kwakasa:たとえばメルペイもローンチのために社内の戦力が結集してやり遂げました。当然調整は大変ですが、All for One連携で動けるところはメルカリらしさです。技術に対するリスペクトがあるからエンジニアも自分の知識をしっかり発揮する。だから、ちゃんと任せられる。お互いにリスペクトがある点もメルカリの強さでしょうね。

@mmiy:新しいチャレンジに対して非常に前向きなカルチャーですよね。「失敗するかもしれないけれど、それでもやっていくんだ」という気持ちの強さは、国内では類を見ない気がします。新たなバーが設定されたら、ちゃんとチャレンジしますからね。今回のプロジェクトにおいても、アクセシビリティの強化や国際化対応といった、周辺領域のチャレンジにもプロダクトマネージャーとエンジニアが一丸となって取り組んでくれました。

失われた知識を取り戻す

──今回のプロジェクトには「失われた知識を取り戻す」という目的があるという話を聞きました。

@kwakasa:そうですね。実は私の中では、今回のプロジェクトにおいて実装の話は半分ぐらいで、残りの半分はプロダクト仕様のドキュメント化も大きな目的なんですよ。

@mmiy:単純なボリュームだけで言うと、実装の方が割合は大きいですが、重要度で言うと確かに半分ぐらいですね。

@kwakasa:周りに「コレ何でこうなってるの?」と聞いてもわからない状態で、「仕様の背景などをSlackで一生懸命検索したら、5年前のメッセージのなかにようやく見つかった」みたいなことがいまだにあったので。結果として、私の感覚では8〜9割はやれた気がしています。少なくとも仕様書を見ながらコミュニケーションができる状態にはなったので。「これなんですか?」「僕もよくわからないんです…」みたいなコミュニケーションは大幅に減らせるのではないでしょうか。

何よりプロダクト開発に関連するすべてのコンテクストが文書化されている方が、メルカリというプロダクトにおいては重要だと思っています。将来的にAIがプログラミングするようになったときも、仕様書がなければ開発はできませんからね。アセットとしての重要度は、実装よりも仕様のドキュメント化の方が大きいとすらいえるかもしれません。

@mmiy:だから、新たにルールをつくってはいないんですよね。もともと存在していたルールを現実的にして運用しやすくなったイメージです。

@kwakasa:とはいえ、共通言語を持てた部分は大きいですよね。デザイナーとプロダクトマネージャーのコミュニケーションコストも下げられるはずですし、ひいてはエンジニアの実装コストも下げられるはずです。

@mmiy:「GroundUp App」による変化という意味だと、お客さまの体験は少し変わったと思います。全体をデザインシステムという大きな枠組みの中でつくっているので、ユーザー体験は一貫したものになるし、以前と比べて使い勝手は上がっているのではないでしょうか。

@kwakasa:ただ、お客さまに対して「書き直しました」みたいな案内は特にしていません。たとえば、Facebookメッセンジャーとかは数回書き直されているわけですけど、一般のエンドユーザーに対して「書き直しました」発信をしているわけではないですし、まったく新しい機能を導入したわけではなく、お客さまにとっては「何が変わったの?」というレベルなので。

@mmiy:今回の目的は、プレゼンテーションレイヤーの技術的な区分や、複雑になった仕様を刷新するところにありました。実は新しい機能をほとんど入れていない。そうしないとなにかトラブルが起きたときに、新しい機能のせいなのか、それとも既存の機能によるものなのかわからなくなってしまう。順序としては機能改善と刷新を行ってから、そこから新しい機能を入れていくのが通常の手法です。

@kwakasa:「今まで軽トラで運んでいたけど、4tトラックに変わりました。今後積めるもの(機能)が増えていきます」みたいなイメージです。体験自体に大きな変化はありません。でも、「GroundUp App」のおかげで新たな機能も迅速に追加していけるわけです。

@mmiy:なので、今回は新しい機能よりも、むしろ減らしている機能のほうが多いくらいなんです。「GroundUp App」が終わると早く開発できるようになりますし、やりたいことがやれる状況をつくるために、捨てるべきところは捨てるのは、将来のために見えない大規模な投資をしたわけです。

@kwakasa:メルカリというサービスのコアは実はバックエンドです。バックエンドは、データベースがあるため今あるものを単純に置き換える形で書き直すことはできず、一つひとつ改善を重ねていくしかありません。だから、僕らの戦いはまだ始まったばかりなんですよ。

──「GroundUp App」が完了すると、やりたいことがやれる状況になっていくということですが、目下どんなことが進められようとしているのでしょうか?

@kwakasa:そうですね。今後マーケットプレイス、フィンテック横断でのUXの向上と、お客さまがよりメルカリアプリを便利に使っていただくために、既存機能の磨き込みと新機能追加のための仮説検証のサイクルを加速していきます。これからまた大きな変化が起こっていくことになると思います。

私たちの旅は終わらない

──大きな変化の時期にあるメルカリで、改めてエンジニアとして働くことの醍醐味とは?

@kwakasa:僕は多様性があるところだと思います。「どんどん新しいことをやりたい」という人にはオポチュニティがあるし、CtoCマーケットプレイスの代表格ともいえるようなプロダクトを維持管理し、発展させていくことは、ほかの国内企業ではなかなかできませんからね。もちろん、まだ技術的に高い次元でできているとは言い難い。これだけの規模になったプロダクトを扱いながら、新しいチャレンジをして、イテレーションを回しているわけですから難易度は高いです。

ただ、個人的には本当に難しいことに挑むことこそがエンジニアリングだと思っています。真の意味でのエンジニアリングに向き合える場所だといえるのではないでしょうか。

@mmiy:プロダクトマネージャー視点で考えると、メルカリの強さ=エンジニアリングの強さです。当然、プロダクトマネージャーもテクニカルな部分を理解していないと一緒に走っていくことはできない。メルカリがより大きなサービスへ成長していくにあたり、ビジネスもエンジニアリングもお客さまの目線も理解した上で、プロダクトマネジメントできる環境は貴重だと思います。より高次元での成長を志す方にはこの上ないのではないでしょうか。

──最後に、今後メルカリが向き合うべき課題はなんでしょうか?

@kwakasa:ひと言で言うと“終わりなき旅”です。プロダクトを運用し続けている以上、機能を追加して、事業のKPIを伸ばさなければいけないし、開発効率も上げなければいけない。そのためには、開発をスムーズに進めるプロダクトマネジメントと開発を延々とやっていかなくてはいけないので(笑)。「今回やったから、しばらくは考えなくていい」という話ではぜんぜんないんですよね。冒頭でお伝えした通り、リファクタリングをやり続けることもエンジニアリングの重要な側面なので。今回の書き直しもいずれまた同じような状況になるはずです。

だから、今回をきっかけにエンジニアだけではなくメルカリに関わる全てのロールの人が「大規模プロダクトを運営するってこういうことなんだ」というマインドセットを持つことが大切だと思います。もしかしたら、「つまらない」と感じる人もいるかもしれません。でも「メルカリ」は確実にインフラ、ライフラインになってきているお客さまもいます。電気、ガス、水道と同じ生活に欠かせないプロダクトの開発に携わっている自覚を持って、プロダクトと向き合っていきたいですね。

@mmiy:今回のプロジェクトは、メルカリの事業とエコシステムをいかにサステナブルに運営するかという第一歩だったと思います。今回は書き直しという策を打ちましたが、いずれにしてもお金も人も時間もかかります。でも、お金と人と時間をかけて、ピースバイピースでやり直していくのがテックカンパニーですから。今後はもう少しスマートに実行したいですね(笑)。

@kwakasa:これからもまだまだチャレンジはあります。オンタイムで壁にぶつかっているし、各方面に負担をかけていることも事実ですが、必要最低限のネガティブサイドを受け入れるだけの度量がメルカリにはあります。いいことばかりではないけれど、ちゃんと受け入れてテックカンパニーとして前進していきたいですね。

関連記事 サクッと読める!✨

「Mercari Summer Internship 2022」の募集を開始しました! #メルカリな日々

メルペイ初!QAエンジニア育成&インターンシッププログラム「Merpay QA Summer Training Camp 2022」の募集を開始します! #メルカリな日々

「Mercari Summer Internship 2021」の募集を開始しました! #メルカリな日々

関連記事 読み応えアリ✨