こんにちは。メルカリMarketplace, Foundation EngineeringのDirector, @mtsukaです。日々新しい技術を追い求め、挑戦を続けるMercari Engineeringですが、そんな部門にしては少し毛色の違った部類のチームです。どちらかというと、中長期の視点から、より良いビジネス貢献であったり、より良い開発体験を支える基盤開発を中心に、じっくり腰を据えた仕事をしています。
この記事は、Mercari Advent Calendar 2023 の23日目の記事です。
メルカリは2021年10月から既存のシステムの解析、改善を大規模かつスピーディに行うという、難易度の高い全社的なリファクタリングプロジェクトRobust Foundation for Speed (RFS) に中期的に取り組んできました。本取り組みは、2023年7月末に各ドメインの改善が無事一段落し、プロジェクトという形は一旦解散としました。こういった取り組みの主要な結果は、具体的な成果として認知されるまでに、数ヶ月数年を要することもままあります。幸運なことに、すでにいくつか具体的に成果として示せることがありますので、昨年に引き続き、うまくいったところ、うまくいかなかったところ、今後の方針など、RFS全体をプロジェクトのオーナーの視点で振り返っていきたいと思います。また、各ドメインについては、ドメイン知識・疎結合化・文化醸成の観点からプロジェクトの成果を解説しています。
プロジェクト発足の背景
改めて、RFSプロジェクトは2021年10月に正式な中期プロジェクトとして発足しました。詳細な説明は 連載：技術基盤強化プロジェクト「RFS」の現在と未来 | メルカリエンジニアリングに譲りますが、事業に関わる共通基盤をうまく抽象化していく、保守性を良くしていくことで、機能実装のリードタイムを一定以下に維持し、これによって間接的に事業貢献をしていこうという取り組みです。このプロジェクトへ参画したいという意思表明が多くのドメインからありましたが、結果的にビジネスインパクトなどを鑑み、Transactions & Checkout(以降Transactionsと呼称)、CSTool, Logistics, ID Platform(以降IDPと呼称)の4ドメインでこの取り組みを行うことにしました。
プロジェクトスコープの設定
リファクタリングなどの改善プロジェクトを発足するときに、改めて気付かされるのはあらゆる資源は有限であるということです。こういったプロジェクトは、ともすれば全てを作り替えてしまいたい衝動に駆られるのが人の性でしょう。特にエンジニアであればそういう気持ちになる方は多いのではないでしょうか。もちろん気持ちとしてはとてもよくわかるのですが、やはりこの取り組みも事業の一環ですから、あれもこれも全てに資源投下というわけには参りません。また、人月の神話で言われているセカンドシステム症候群のようなことも避けねばなりません。これらのポイントを考慮して、最終的にはシステムの変更頻度や他システムとの結合度合いを考慮してスコープを決めました。この点については、人によっては不満もあったと思いますし、実際に一部ドメインの調査・分析や関連する議論が収束するまでには半年位の期間がかかってしまいました。個人的には、現場のメンバーが一番知見をお持ちなので、それを尊重しつつ納得感をある程度持ってもらいたかったのですが、正直少し時間をかけすぎてしまったので、明確なしきい値や基準など、もう少し具体的に事前に提示したほうが良かったと感じています。
プロジェクトの定点観測
スコープが決まればロードマップを引いて、OKRを設定し、あとは手を動かしていくだけですが、ビジネスグロースの案件などとバランスをとりながら、うまく説明責任を果たしていく必要がありました。このため、あまり好まれるやり方ではないにせよ、週に一度の定期チェックインミーティングを用意し、CTO/VP同席のもとプロジェクトの進捗を管理しました。原則としてOKRとその進捗をDivision全体で共有し、トラッキングすることでプロジェクトの透明性担保や早期のブロッカー除去に務めました。また、最初期にはカンパニーのOKRとして経営層への定期的な進捗インプットも行いました。 担当チームが解散してしまっていたり、メイン開発者が退職していてドキュメントも存在しないようなコンポーネントを含むドメインでの作業なので、透明性を担保しながら情報を共有し続けることは極めて重要であったと思います。一方で、忘れられた仕様が発見されたりするなど、スケジュールを遵守するという観点では苦労も多かったです。スケジュールマネジメントの観点ではThe Six Week CycleのTracking Work on the Hill Chartの考え方を大いに参考にしました。
プロジェクト全体の振り返り
さて、このようなプロジェクトでは成果を既存事業への貢献として評価することはとても難しいです。定量的に計測したものは、リードタイムの増減、データベース分離数、マイグレーション数、削除したコードや廃止したAPI, それぞれの費用対効果などを計測しました。その他、定性的にはリファクタリングのマイルストーン達成状況や実際のチームの体感等などを集計しました。このような取り組みを経て、RFSが会社の期待にどのように答えたのか、振り返りを実施しました。かんたんなプロジェクトの総括としては、今後の事業計画・成長を見据えた基盤そのものと基盤維持の仕組みがある程度構築されたので、この取り組み自体は将来へ繋がる意味のある投資であったと確信しています。その旨をMercari Engineering Boardへ報告する形で説明責任を果たしました。個別の詳細については、後述の「各ドメインの振り返り」を参照ください。
各ドメインの振り返り
以下に、各ドメインでの取り組みと振り返りをまとめていますので、ご覧ください。
Transactions
Transactionsはお客様が商品を購入してから手元に届くまでの各ステップを司るメルカリのビジネスを構成するAPI郡(以降mercari-apiと呼称)のいちコンポーネントです。複雑化したモノリシックなmercari-apiからこれら関連するコンポーネントを切り離し、保守性を担保しながら抽象化、単純化していくことでプロダクト開発の後押しをするために、チームの組成から着手しました。チームの成り立ちがRFS起因のため、スコープの決定や抽象化のプランの検討は比較的スムースでした。
Transactionsドメインとして mercari-apiから切り離された機能は以下のとおりです:
チェックアウト (モジュール化完了)
購入履歴 (モジュール化完了)
チェックアウト料金計算機能 (Golangの独立したマイクロサービスとして実装)
配送 (モジュール化完了)
これらのモジュール化やリファクタリングを通じて下記のような成果を得ました。
ドメイン知識
綿密なコード解析とリバースエンジニアリングを行い、アプリケーション全体の中で最もビジネス上複雑で重要なドメインに関する知識を、組織として得ることができました。
疎結合化
TransactionsドメインはC2C Marketplaceシステムの中心的なコンポーネントなので、多くの新機能が恒常的にTransactionsドメインの連携を必要とします。このMonolithicな実装のサブコンポーネント郡をモジュラーモノリスとしてリファクタリングすることで、その後の開発に多くの良い影響をもたらしました。例えば機能境界が明確になったので、不具合の発見やリスクのコントロールがしやすくなり、Transactionsドメインに変更を加える成果物の品質が向上しました。また、本取り組みにおける調査の結果が知見として蓄積されたことに加え、認知的負荷の軽減により、オンボーディングも比較的簡単になりました。
上記から派生した効果として、新しい機能や要件実装のリードタイムを大幅に短縮できるようになりました。実例をあげると、チェックアウト料金計算機能によって料金管理が一本化されたため、料率の変更や新しい決済方法の導入などの実装工数が最大3ヶ月から1週間未満に短縮されました。また、CSToolやLogisticsなどの他のドメインとの依存関係を切り離すことができたので、より独立してシステムを維持していくことができるようになりました。
文化醸成
リバースエンジニアリングとリファクタリングと並行して、チームには "reading parties" という独創的で魅力的なコード分析の文化が生まれました。ここから生まれたドキュメントはオンボーディングへ応用されるだけでなく、他のチームとドメイン知識を共有するためにも活用されています。また、今後もTransactionsドメインの変更には多くのチームが関与し続けていくことになるため、将来に渡って意味のある成果になるでしょう。
参考記事
- Understanding and Modernizing a Legacy Codebase
- メルカリの取引ドメインにおけるモジュラーモノリス化の取り組み
- クライアント・サーバサイドに分散する計算ロジックのマイクロサービス化
Logistics
メルカリは多様な配送手段をサポートしています。Logisticsは言葉通りこれらの配送方法を司るコンポーネントです。ご存知の通り、配送方法はメルカリというサービスの成長とともに時間をかけて増えていったものなので、Logisticsコンポーネントも時間の経過とともに複雑さが増してきました。そのため、スコープの確定は早かったものの、他ドメインと比較してゴールの設定難易度が非常に高かったです。最終的にLogisticsドメインでは、重複しているクラスを排除してシンプルにするなど、主にシステムの再設計を行いました。具体的には、メルカリの歴史とともに育ってきた22のコンポーネントの疎結合化を目指したかったのですが、これらすべてを疎結合化するには現実的な時間が足りませんでした。そのため、将来につながるメンテナンスの一環としてインターフェースやデザインを極力共通化することにしました。すでに動いており、しかもビジネスの根幹を担うシステムを改善するわけなので、そういう観点でも難易度は相当なものです。成果自体は次に繋がる良いものでありつつも、残念ながら、この取り組みの見た目的な成果はドメインの中では一番物足りないものでもありました。このあたりは、より良いアプローチを模索していきたいです。
取り組みを通じて下記を達成しました。
ドメイン知識
重複排除などの作業を通じて新しい配送方法の追加、配送料金の変更方法などが統一され、結果としてチームのドメイン知識が増しました。配送手段の仕様はパートナー企業の仕様に依存するものの、社内で扱うインターフェースをある程度共通化することで、全体の把握がしやすくなりました。また、共通化の恩恵として学習コストも格段に下がりました。
疎結合化
Logisticsドメインはパートナー企業との関係もあるので、利用料金の変更や提供プランの変更などが発生した場合、直ちに対応を行わなければなりません。このため、システムの複雑さを解消することは極めて重要な取り組みでした。結果として、疎結合化自体は進みませんでしたが、デザインパターンの適用と再設計を通じて、機能追加や変更が簡単になりました。実際に、配送サービス利用料改定に関わるリードタイムは、チェックアウト機能との連携も完了し、期間も約3ヶ月から1/3の約1ヶ月に短縮されました。今後も新しい配送方法の追加、料金改定、その他将来発生するであろうユースケースについても同じような対応ができることでしょう。
文化醸成
チームがリファクタリング用のバックログを持つようになりました。このバックログは定期的に内容の確認と改善の検討が行われ、必要に応じてメンバーがアサインされるようになりました。
CSTools
CSToolsはいわゆる顧客対応ツールです。お客さま対応のためのツールですから、その機能やサポート範囲は多岐にわたり、システムは年々複雑化していく一方でした。このため、スコープの策定議論は一番紛糾したのではないでしょうか。そもそもお客さま対応のためのデータベース数が膨大なため、これをどこまで疎結合化するのかなどが論点になってしまい、スケジュール的にもマイルストーン的にも難しい展開が発生していましたが、最終的に他3ドメインの改善に関わるブロッカー除去を優先するという前提でスコープを設定することで、議論を収束しました。
ドメイン知識
重複排除などの作業を通じて新しい配送方法の追加、配送料金の変更方法などが統一され、結果としてチームのドメイン知識が増しました。配送手段の仕様はパートナー企業の仕様に依存するものの、社内で扱うインターフェースをある程度共通化することで、全体の把握がしやすくなりました。また、共通化の恩恵として学習コストも格段に下がりました。
疎結合化
詳細は後述のブログポストに譲りますが、注力ドメインとの関係性と変更頻度を軸にDBの疎結合化を行いました。これによりCSTools開発に関わる調整相手が減って、クイックに改善活動ができるようになりました。また、追加で古くから一部のQA業務が依存していたシステムのGKEマイグレーションとサービスアウトを実施できました。これにより、QAやテスト環境の統合が進み、システムのコスト面でも貢献することができました。
文化醸成
Post RFSの一環としてCSToolsドメインにFoundationチームが組成されました。このチームはCSToolsドメインの共通基盤やフレームワークをパッケージとして各エンティティに提供することで、個別のエンティティに個別のツールを作らなくても良い状況をもたらすことに責任を負っています。正式にこういった組織を持つことを認められたのも成果の一つと言って良いかもしれません。
参考記事
ID Platform
ID Platform(以降: IDP)は、メルペイ創業前後にmercari-apiから認証認可の機能を中心にスピンオフしてPlatform化したものです。チームの組成当初からビジネスプランを後押しすべく、然るべきタイミングで然るべきことをやっていくという方針でチームが運営されていたと記憶しています。一方で、どうしても急ぎの実装や設計が先行しがちなことは変わりません。内外各ステークホルダーとのアカウント連携など、常に現状のビジネスを改善する業務に追われている状況で、後々に判明した考慮漏れの修正、リファクタリングなどの時間を確保することが簡単ではない状況でした。RFSでの注力対象にピックアップされたタイミングのIDPチームは、当時メルコインサービスの開発をサポートしていました。もともとチームの思想がRFSに近く、ある程度成熟していたチームなので、RFSとして直接何かの機能改善やリファクタリングをお願いするようなことはせず、メルカリグループ全体の方針などをシェアしながら、現在の設計や実装が今後の抽象化にうまく繋がるように支援しました。
ドメイン知識
IDと認証認可の領域は比較的専門家が少ないため、知見が偏る傾向があります。現在チームはTLの育成と知見の共有などを行いやすい構造になりました。RFSの取り組みと考え方は、この文化醸成の一助になったと信じています。
疎結合化
IDPはもともとはメルカリとメルペイというサービスだけが存在する世界線で実装されたものですから、比較的明確に密結合な場所がありました。日々メルカリを利用してくれるお客さまに新しい価値を提供するためには、この密結合が段々と足かせになりつつあります。今後の取組次第でどうなるかはわかりませんが、この結合度合いをある程度疎に維持できるようになりました。
文化醸成
元来IDPでは、一部の専門家が特定のユースケースを基に知恵を絞って将来を視野に入れたデザインを行う傾向が強いのですが、外部の専門家も交えたドメイン知識の共有や議論などを行えるようになりました。直接は関係ないですがFIDO AllianceのAuthenticate 2023 Conferenceにてメルカリの取り組みを紹介するなどの機会にも恵まれました。
参考記事
- Applying OAuth 2.0 and OIDC to first-party services
- Using the OAuth 2 token exchange standard for managing the identity platform resources
まとめ
さて、ここまで日々進化するメルカリのアプリケーションを支える基盤開発のエピソードを、長期プロジェクトの振り返りを通じてお伝えしました。
メルカリのFoundation Engineeringチームは、これからもRFSで得られた知見やユースケースを参考に、重要な共通基盤技術の保守性を維持ながらし、プロダクト開発エンジニアがサービス開発を行っていく上で不可欠なコンポーネントを提供し続けます。
明日の記事はQAチームのjyeさんです。引き続きお楽しみください。
