@1000ch です、今回は新しいメルカリ Web について書きます。この大きなプロジェクトのリリースは、多くの人の多大なる貢献によって成されたものです。そのプロジェクトの立ち上がりから今日まで、リードする役割でプロジェクトを見てきた一部始終を記録するべく書きます。
メルカリにおけるレガシーなソフトウェア
ソフトウェアは生モノとよく言われますが、古くなったソフトウェアとどう付き合っていくかは、どの開発組織も抱えている、あるいはいつかはぶつかる課題なのではないかと思います。多くの方々に利用して頂くためには大規模なソフトウェア群を開発し運用する必要があります。しかし、はじめから全てを見越して完璧なアーキテクチャを構築するのは不可能であり、それをビジネスの成長に耐えうるものにソフトウェアを成長させていくのがエンジニアリングの責務です。
2013 年にスタートしたメルカリに於いても例外はなく、急速なプロダクトの成長に伴い抱えてきたレガシーな部分は多く存在します。例えば、既に取り組んできた改善として Backend のマイクロサービス化があります。メルカリ Web も数ある技術負債の1つでした。
メルカリ事業とプラットフォームとしての Web
昨今のアプリケーションプラットフォームとして、iOS、Android、そして Web があります。モバイルデバイスをターゲットにしたときに iOS と Android のネイティブアプリケーションとしてプロダクト開発を進めるのは自然な判断です。メルカリのユーザーベースは iOS と Android にあり、事業開発もこの2つを中心にリソースを注いできました。
そんな中でも少なくない数字を築いていたのが Web です。モバイルデバイスの場合にネイティブアプリケーションが中心になる理由の1つに端末の実行性能があると思いますが、デスクトップデバイスをターゲットにしたときにはブラウザで十分にパフォーマンスが出る Web が中心になるでしょう（以前、インタビューで同じような話をしました）。
メルカリとしても、長期的にはモバイルデバイス体験との差別化を図ったり、モバイルかデスクトップを問わず流入などのメルカリ外部との親和性を活かすなど、様々なビジネスポテンシャルを Web で引き出していくために、Web 版メルカリを再始動させる経営の意思決定が行われました。
メルカリ Web 再始動プロジェクトの再発足
レガシーな Web を刷新する取り組みは既に行われていました。しかし、既存 Web との互換性を維持して部分的なリプレイスを繰り返しながら機能開発も並行していたためスピードを出すことが難しく、プロジェクトが長期化するなどの問題も抱えていました。
そこで、これからのメルカリ Web で達成したいことは何なのかを問い直しました。
- スピード感を以て負債を捨て切り、中長期的なプロダクトの成長に耐えうるソフトウェアになっていること
- アクセシブルで多言語に対応し、モバイルかデスクトップかを問わず iOS や Android 版と等しい機能性が提供されていること
- リリースまでだけではなくリリース後も、組織として Web に対して継続的にコミットする体制になっていること
この共通認識を持ち直した上で、動いていたレガシー Web の刷新を仕切り直し、プロジェクトを再始動することになりました。もちろん今回のリリースのタイミングで、機能等価性と負債返却の全てを達成できているわけではありませんが、多くは達成されているとともに、残された課題の解消もようやく先が見えてきています。
また、今回のリニューアルリリースに際して、何か新しい機能が含まれているわけではなく、あくまで「お客さま体験を大きく変えずソフトウェアを置き換えること」にフォーカスしています。
アプリケーションのアーキテクチャ
メルカリのエンジニアリングチームには React と TypeScript の知識と経験が充分にあったので、これらをベースにしつつ、Node.js に依存せずスケールさせることを目的に SSG を採用しつつ、ビルドシステムとして Gatsby を選びました（後に Next.js の Incremental Static Regeneration が登場して心が揺らぎましたが）。
現在提供されている機能を実装するために必要な API は既に存在しているためそれを使いつつ、マイクロサービスへのマイグレーションが済んでいる部分については proto ファイルを使って TypeScript の型定義を出力しています。
あとはサーチエンジンのクローラーボット用に、GoogleChrome/rendertron を使って完成版の HTML を返すようにしています。このように、アプリケーションの全体アーキテクチャとして、設計に関してそこまで特殊な点はありません。
トランクベース開発とテスト
トランクベース開発を採用しており、それに応じて git の運用もトランクとなるメインブランチから新しいブランチを作成し、開発が完了次第メインブランチにマージします。
継続的インテグレーションとして、ビルドパイプラインの中に各種テストが組み込まれています。ユニットテストと E2E テストはすべての開発において前提となっており、特に E2E テストは機能開発を担うエンジニアが、テストケースの定義と実装までを QA チームのレビューや協力を得ながら責任を持って実施しており、十分にテストされていないブランチはメインブランチに合流できません。そしてこれによって、メインブランチを常にリリースできる状態に保っています。
国際化対応 (i18n)
今後より多くのお客さまに使ってもらうために、多言語化のための基盤も前提に入れて開発を進めてきました。その最初のステップとして、日本語と英語のサポートを視野に入れて実装してきました。ただこれに向けては Web アプリケーション部分だけでなく、Backend 側の実装であったり、商品詳細画面や取引画面などで行われるお客さま同士のコミュニケーションをどのようにサポートするのかを十分に検討する必要があります。そのため、現時点では日本語サポートのみが開放されています。
国際化やこの次に説明するアクセシビリティは、メルカリが多様性のあるプロダクトになっていくためにも重要な要素として捉えています。
デザインシステムとアクセシビリティ (a11y)
このプロジェクトと並行してデザインシステムのアップデートも実施されてきました。それまで取り組んできたデザインシステムを見直し、アクセシビリティの向上と、特定の UI ライブラリに依存しない機能性の提供の2点を掲げて改善に取り組んできました。デザインシステムは UI を構築するときの基本となるようにデザインされるため、デザインシステムのレイヤでアクセシビリティが担保されていることで、構築された UI のアクセシビリティも実装レベルでの問題は起きにくいはずです。
デザインシステムの基本方針として、特定のプラットフォームやライブラリに依存した作りであるべきではなく、これを踏まえて Web ではデザインシステムのコンポーネントの実装技術に Web Components を使うという判断をしました。例えばコンポーネントを React で実装することもできますが、Vue.js で構成しているプロジェクトやプレーンな HTML ページで利用できなかったり、Vue.js などの他のライブラリでも実装するとなるとメンテナンスコストが多重化していきます。コンポーネントとしてのポータビリティという点で Web 標準技術で構成される Web Components は良いのですが、Web 開発現場で求められるユースケースとの親和性という点では未成熟な部分も多く、様々な難しさにもぶつかってきました。
デザインシステムについては、新しいメルカリDesign System Web で詳しく解説されています。
プロジェクトの進行と組織構造
工夫が必要だったのはテクニカルな部分というより、プロジェクトの推進であったり、チームの立て付けといったような、どちらかといえば組織的な部分だったように思います。このプロジェクトを遂行し新しいメルカリ Web をリリースすることだけがゴールではなく、持続的にコミットする体制を組織にインストールする必要があります。
メルカリの開発組織では Camp という構造を取り入れています。各 Camp にはミッションが設定されており、例えば「Camp-X では商品を検索して購入するまでのお客さまの購入体験に責任を持つ」といったようなものです（これはあくまで例え話で、実際に設定されているミッションとは異なります。また、ミッションもビジネスや組織の状況に応じて日々変化します）。それぞれの目的を持った Camp が集合してメルカリが提供している機能群を改善しています。
理想的には各 Camp が担当するミッションに応じた機能を作り上げていくことですが、それをプロジェクトの初期段階から実践するのは難しいため、まずはタスクフォースとして「メルカリ Web をゼロベースで作り直す」という目的を持った Camp が組成されました。
といっても、プロジェクト初期ではソフトウェアエンジニアが2人（私を除く）、プロダクトマネージャーが1人、デザイナーが1人という小規模なチームに始まっています。ここから、HR チームの協力のもと採用活動が実ってたくさんのソフトウェアエンジニアがジョインしてくれたり、既存の Camp も徐々に新しいメルカリ Web にコミットする体制にシフトするなどを経て、ようやくリリースまで漕ぎ着けています（発足が 2020 年2月なので、かれこれ1年半程かかりました）。プロジェクトにご尽力頂いたすべての皆さんに感謝致します、ありがとうございます。
メルカリ Web のこれから
今後は、アプリケーションの基礎の部分をメンテナンスしていくチームと、各 Camp のミッションのもと機能を拡充・改善していくチームに役割を分けて組織体制を整理し、中長期的にメルカリ Web を育てていくことが重要です。そして、iOS や Android 同様に Web でも優れた機能性を提供することで、メルカリがさらに包括的なプラットフォームとして成長していけることを信じています。
「メルペイを Web でも使いたい！」や「メルコインはどうなるの！」や「Web 版メルカリShops は！？」など、様々な質問もあるかと思いますが、ここで書けることと書けないことがあるのでご容赦ください。ひとつ書けるとすれば Web でも様々な可能性を模索しておりエンジニアが足りませんということなので、Job Description を参照のうえ、是非ご応募ください。
