「メルカリ史上類を見ないほどGo Boldだった」と語られる、2年半にわたる長期プロジェクト「GroundUp App（＊開発コード名）」。多くの人の手と知恵、そして時間をかけて、フロントエンドをすべて刷新したこのプロジェクトはどのような思想に基づき開発が進められたのか？

iOSエンジニアチームのテックリード・青山遼（@ryo-aoyama）とAndroidエンジニアチームのテックリード・Conda Anthony Allan（@allan.conda）が「GroundUP App」を振り返りました。

急速な発展の裏で溜まり続けた負債を解消する

──まずは「GroundUp App」に取り組んだ経緯から教えてください。

Aoyama：メルカリはいままでに日本になかったくらい急速に発展した組織で、それに伴うコード量も膨大です。その間にある種の「負債」も溜まり続けていました。ソフトウェア用語で「Big ball of mud＝大きな泥団子」と表現するのですが、その状態に陥りつつあったんですね。もちろん、負債を解消する努力は続けてきましたが、少しずつリファクタリングを進めようにも「こちらを立てればあちらが立たず」という状態で、物事はなかなか進捗しない。とはいえ、テックカンパニーとしてやりたいことはどんどん増えていくので、完全な形でモノにするために一からつくり直すという大きな決断をしました。

青山遼（@ryo-aoyama）

──別のインタビューでWakasa（メルカリ・CTO）さんは「できればソフトウェアの書き換えはやりたくなかった」と口にしていましたが？

Aoyama：エンジニアリングの観点からは異なった考えもあったと思います。当然ソフトウェアの書き換えは「最終手段」であることは間違いないのですが、バックエンドのマイクロサービスと異なり、モバイルアプリは全てのソースコードを最終的に一つの成果物として世に出しますから、リファクタリングの影響範囲が予測しづらいんです。私たちがテックカンパニーとして次のレベルに挑戦していくためには、今の段階で一から作り直して土壌を整える必要があると考えました。

Allan：私が入ったタイミングですでに進行しているプロジェクトでしたが、それでもまだまだ初期段階でした。やりたいこと、やらなければいけないことが山積み。レガシーなコードがたくさん残っていて、メンテナンスや新機能追加がしづらい状況でした。Aoyamaさんが話すようにリファクタリングをするのもひとつの方法ですが、それにもメリット・デメリットがある。総合的に判断して、つくり直すことにしました。

Aoyama：将来的に「段階的な作り直し」ができるように、GroundUp Appを通じて「この範囲だったら完全につくり直しても1〜2週間で済む」というように“つくり直す単位”を明確化する目的もありました。

難易度は通常の20倍…？ スクラッチを推進することの難しさ

──改めて、それぞれのチームの開発体制を教えてください。

Aoyama：私はまだ入社していなかったですし、Allanさんもプロジェクトには携わってはいなかったのですが、プロジェクト自体の発足は2019年の後半です。開発自体は、Androidが2020年1月頃から、iOSが2020年4月にスタートしました。

組織としては「キャンプ」という単位で開発に取り組んでおり、たとえば出品機能のドメインに対して専門性の高いエンジニアがコミットしていました。「この機能に関して相談したければ、このエンジニアに聞けばいい」というのがわかりやすい体制だと思います。

Allan：そうですね。各キャンプにはiOSエンジニア、Androidエンジニア、Webエンジニア、バックエンドエンジニア以外にもQA、デザイナー、PMもアサインされていて、各チームがオーナーシップを持ってプロジェクトを動かしています。「2週間ごとにスクラムを回しつつ、翌週分のタスクを見積もる」ようなスタイルで開発を進めていました。ほとんどのキャンプではそうですが、各キャンプは自主運営で、働き方も自由に選ぶことができます。

Conda Anthony Allan（@allan.conda）

──プロジェクトを進めるにあたり、「大きな泥団子」となっていた課題をどのように整理していったのでしょうか。

Aoyama：課題を洗い出すためのサーベイは、私が入社する前に実施されていたため、すでにまとまったものがありました。しかし、内容自体は「ビルドが遅い」とか「テストが書きにくい」といった、わりと一般的なものだったので、その改善を前提として、さらに持続可能性のある品質を担保できる仕組みを導入しました。

そもそも、スクラッチは一から新しいサービスをつくることと比べて、難易度は体感でいうと10〜20倍に跳ね上がるので、特定の課題にフォーカスするというよりも「全体的によくしよう！」という感覚でした。お客さまに提供している機能もUXも変わりませんでしたからね。

ただ、メルカリのような規模のサービスをスクラッチする機会はまずないので、できる限り多くの可能性を想定しながら進めていました。

──では、スクラッチにおけるボトルネックはありましたか。

Allan：当時はかなり古いツールを使用していたので生産性を落とさないように、安定性のある最新の技術を導入しました。オンボーディングに多少時間はかかったのですが、最終的に導入できたので、スムーズにプロジェクトに取り組めたと思います。

Aoyama：同意見です。iOSもAndroidもプロダクションレディとはいえないような技術スタックだったので、サポートされていない機能を完全に再現しなければいけない要件などがたくさんあり、それは本当に難しかったですね…。

さらにiOSは、ビルドツールやインフラストラクチャーなどで新しい技術をどんどん採用したのですが、それも前例が少ないケースだったので、自分たちで正解へと導かなければいけない点に苦労しました。

──少し話が変わるのですが、開発における「ルール」のようなものがあれば教えてください。

Aoyama：スクラッチするにあたって開発スタイルも一から見直して、組織に最適なルールを策定しました。同時に、UXやエラーハンドリングのように「開発とは少し外れるけどエンジニアが留意すべき機能」については、初期段階からガイドラインを用意しました。基本的に「このガイドラインをもとに開発してください」と推奨しています。

コーディングに関しては、厳密なルールは設けないようにしているのですが、ひとつだけ守ってもらっているのは「機械的なチェックができること」。ルールにそぐわないコーディングスタイルをとった場合は、リンターやフォーマッターといったツールで自動的に指摘される仕組みを構築しました。

Allan：Androidに関しては、フィードバックのサイクルを設けるようにしています。具体的には週1回のミーティングを通じて、オンボーディングしているエンジニアから意見や提案を募るようにしました。初期段階では、私もコーディングやエラーハンドリングなどに関するガイドラインをつくったので、それに対しても「いくらでもフィードバックをください」と共有しました。

スタートして1年ぐらい経ちますが、徐々に改善できてきていますし、かなりいいサイクルがつくれている感覚です。

お客さまの体験を「何も変えず」に進化させる。iOSとAndroid、それぞれの成果

──GroundUp Appにおける、代表的な取り組みを教えてください。

Aoyama：iOS / Android共通の部分でいうと、大きく分けて4つあります。1つ目は新しいデザインシステムの採用です。高度化しているUIに求められる要件をより適切にサポートするために、GroundUp向けにデザインシステムもゼロから全て作り直しました。

2つ目はダークモードへの対応です。アクセシビリティの向上もそうですが、お客さまの好みや環境に最適化するために導入するべきでないかと長く議論されてきたテーマだったので、GroundUp Appを通して、デザインシステムを全画面に完全に導入できたことでようやく達成できました。メルペイなどの一部の機能が未対応なので、このタイミングではお客さまに提供できていませんが、近々使っていただけるようになるはずです。

3つ目はインターナショナライゼーション。つまり英語対応です。社内のエンジニアが半分以上英語スピーカーなので、開発者が正しくドッグフーディングするためにも導入しました。もちろん、ゆくゆくはお客さまが使えるようにしていきます。

4つ目はアクセシビリティの改善です。既存のアプリにも対応できていたのですが、商品を探して、値段をチェックして、ログインして、購入して……という一連のフローが完璧にできる状態ではなかった。お客さまの特性に関わらず使ってもらえるように、一から設計し直した部分です。

特に4つ目のアクセシビリティに関しては「今まではWebばかり使っていたけど、アップデートしてからはアプリを使うようになった」という声をいただく機会が増えました。特にモバイルではまだアクセシビリティの機械的な検証する手段に乏しいので、GroundUpの発足に応じて検証をサポートするツールを作成したり、エンジニアとQAチームが意識を割いた成果だったので、嬉しかったですね。

Allan：今の話に補足すると、これまでのUXを崩さずにすべて改善すべく取り組みました。特にUIは宣言的UIに変更し、エラーハンドリングを改善したり、共通のAPIを整えたりしたのですが、エッジケースの対応については、今までできていなかったため特に注力した部分です。

Aoyama：iOSスペシフィックな話だと、GroundUp AppではアプリのライフサイクルレベルからSwiftUIという新しいフレームワーク（AndroidはJetpack Compose）でつくり直しました。将来的にはスタンダードになっていくであろう技術なので、投資の意味も込めて採用したフレームワークです。

また「ビルドが遅い」と言う全モバイルエンジニアが口にする課題に対しては、Bazelというツールを採用し、「誰かがビルドした結果をクラウドに保存し、別の誰かがビルドする際には再利用する」という仕組みを構築しました。

スタンダードな技術だと限界があるのですが、Bazelは包括的なツールで汎用性が高く、開発者の人数が多ければ多いほど利点が多い。「自分のPCでは動いたけど、自分以外のPCでは動かない」みたいな、ありがちな問題が起こりづらいように設計されています。

特にBazelの最大の魅力が、機能をモジュールという「単位」に分割する方法に富んでいる点です。うまく設計できれば、冒頭でもお話しした機能を作り直す単位にもなりますからね。以前は20〜30個のモジュールでしたが、GroundUp Appでは800以上に分割できました。これからさらに細分化を進めて行けると思っています。

Allan：Androidでは、JetpackのライブラリのJetpack Composeというツールキットを使うことによって、コードの量を半分くらいまで減らせて、ダークモード、インターナショナライゼーション、アクセシビリティの向上にも貢献できました。

──では、GroundUpによって、お客さまの体験はどのように変わりますか。

Aoyama：基本的には「何も体験を変えない」ことがGroundUpの目的です。もちろんアクセシビリティを必要とするお客さまが快適に使えるようになるとは思いますが、基本的には今までのアプリと同じような体験を提供することが理想です。

Allan：デザインシステム3.0を通して、デザインの一貫性などは改善してきましたが、基本的にはAoyamaさんが言うように、お客さまに「今までと変わらない同じ体験」を自然に提供できることが大事ですね。

2年半かけてやりきった。「Go Bold」なプロジェクトの先にあるもの

──今回のプロジェクトは、かなり「Go Bold」なものだったと感じます。

Aoyama：そうですね。もうすべてが「Go Bold」だったように思います（笑）。一からつくり直す行為自体リスクが伴う中で、2年半もかけてやりきったことは「Go Bold」そのもの。

関わったエンジニアだけでなく、PM、EMすべてのメンバーが「既存の仕組みに倣って……」という考えではなく「よりよくしていこう」というベクトルで最大限の努力をして団結できたわけですから、「Go Bold」すぎるプロジェクトといっても過言ではないと思います。

Allan：おっしゃる通りですね。これ以上「Go Bold」な取り組みはないと思います（笑）。元々のUXを変えないままつくり直すことは非常に難易度とリスクが高かったのですが、キャンプ内はもちろんキャンプ横断で連携することで乗り越えられたのではないでしょうか。

──GroundUpという大きなプロジェクトを終えて、これからメルカリではどんな挑戦ができますか？そこでどんな仲間が必要になりますか？

Aoyama：冒頭に「Big ball of mud」の話をしましたが、メルカリは類を見ない早さで成長を遂げてきたので、どうしても負債は蓄積してしまいます。GroundUp Appは新しい技術を採用するプロジェクトというよりは、その負債を解きほぐして、かつ今後スタンダードになるであろう技術を採用しました。

旧アプリの開発が抱えていた、もしくはモバイルアプリ開発が一般的に抱えると言っていいかもしれませんが、開発生産性のあらゆる問題を尖った技術によって解決することに苦労した反面、個人としてもチームとしても成長を感じられました。

GroundUp Appを経たことで、より先進的なチャレンジができる環境はできたと思います。機能開発の場面を見ても、これまでは誰かが何年も前に書いたコードを読み解いていたものが、かなりストレートフォワードにつくれる状態になりました。機能の提供はもちろん、チャレンジングな技術採用なども実践できているので、今後は高い技術力の上でメルカリをグロースさせていけるもっとおもしろいフェーズになるんじゃないかなと。

先進的な技術を使ったプロダクティビティの改善に興味があるエンジニアや、デザインシステムに貢献してUI/UXと開発の改善を加速させてくれるようなエンジニアにとって、チャンスが多いと思います。やっぱり、技術的な挑戦がエンジニアにとっては成長の近道なので、今が一番いい開発を経験できるはずです。

Allan：間違いなく難易度が高いチャレンジができる体制になりましたね！それはつまり開発を通じて楽しめるようになってきたということ。今後も開発体制をよりよくしていくためのフィードバックは受け入れていきたいですし、アーキテクチャについても柔軟性を維持し続けたいと思います。

Androidに特化した話で言えば、Androidの端末の幅が広いので、TVとかスマートウォッチとか、最終的にそれらに対応できる画面づくりをしていけるようにしたいですね。

──最後に、お二人が仕事で大事にしていることを教えてください。

Aoyama：あまり矜持のないタイプのエンジニアなのですが、あえて挙げるなら「物事を長い時間軸で見ること」と「一番ネガティブに物事を考えること」ですね。今流行りの技術は1〜2年はうまくいきますが、長く続かないことが多いので、長期的視点で物事を考えるようにしています。そして、リーダーとしてはポジティブでなければいけないと思うのですが、エンジニアは最悪のケースも想定できなければいけませんからね。意外と最悪なケースは起こるものなので（笑）。

Allan：私の場合は「チームワーク」です。課題は多いですが、優秀なエンジニアが揃っているので、彼らの意見に耳を傾けることで、いくらでも現状をより良く変えていける。自分のチームだけではなく会社全体を見渡しながら、意見を受け入れていきたいと思います。