2021年10月から、サービス・機能開発の基盤を強化するRFSプロジェクトを始動したメルカリ。

RFSとは「Robust Foundation for Speed」の略で、メルカリグループ全体の非連続的な成長を支えるため、ビジネスの共通基盤に潜む複雑な技術的課題の解決と抜本的な強化を図るのが、RFSの目的だ。

プロジェクトスタートから1年以上が経ち、いまプロジェクトはどのように進捗しているか。RFSにおいて3つを注力する領域、「C2Cトランザクション」「IDプラットフォーム」「CSツール」をそれぞれ担当するチームのキーパーソンたちに、プロジェクトにおける課題とそれにどのように向き合ってきたのか、3回にわたってうかがっていきます。まずは「C2Cトランザクション」の領域を担うTransaction Teamのエンジニアリングマネージャー・高田祐一（@takady）とテックリード・Eric Jelliffe（@eric.j）にプロジェクトの現在地を聞きました。

Transactionドメインに100％注力するためのチームとして組成された

──Transaction Teamは、RFSがスタートするタイミングで設立されたチームですが、どのようなミッションを担っているのでしょうか？

@takady：RFSで注力する領域のひとつとして、「C2Cトランザクション」が挙げられました。

C2Cトランザクションというのは、メルカリの商取引を担っている、創業当時から存在するビジネスのコアとなる部分です。取引を管理する箇所なので、メルカリのあらゆる機能と関連している部分でもあります。ここのシステムが複雑で密結合な状態になっていることで、開発スピードの低下が課題となっていました。上手くドメイン分割することで、必要な機能やサービスを素早く実装してデリバリーできるようにする事が目標として掲げられました。

また、技術的な側面だけでなく、今後の開発体制やプロダクトとしての拡張性も考慮した上でドメイン分割を行い、マイクロサービスもしくはモジュラーモノリスにしていかなければなりません。エンジニア、EM、プロダクトマネージャーが協力して、どのように分割するとより最適なのか、それを考えて構築することが必要でした。RFSがスタートするタイミングで、この課題にチャレンジするためのチームとして、Transaction Teamが組織されました。

──それまで、Transaction Teamがなかったのはなぜでしょうか？

@takady：それまでもC2Cトランザクションの領域を担当しているチームはあったんですけど、どちらかというとメルカリAPIというモノリスの管理が中心で、同時にTransactionドメインも担当しているメンバーがいるという状況でした。しかし、RFSというプロジェクトの規模感から考えた時に、Transactionドメインに100％注力するチームの必要性があり、私とEricさんがいたチームを母体に新たなメンバーが加わるカタチでTransaction Teamがつくられました。

高田祐一（@takady）

──なるほど。では、昨年の10月以降チームをどのように構築してきたのでしょうか？

@takady：状況としては、取引ドメインの深い知識がメンバー全員にあったわけではありません。また、新しいチームということもあり、メンバー同士の相互理解を深めるところからはじめました。

まず、チームとしてはじめたのは「コード輪読会」です。コード輪読会を通してみんなでドメイン知識を深めることを目的としていました。最初の1Qで、30endpoint、週2回くらいのペースで行いました。改めて振り返ると、コード輪読会を実施したことによるいろいろな利点があったなと思います。知識の習得だけでなく、コミュニケーションの場としても機能しました。それぞれのメンバーがどういうコミュニケーションのスタイルなのか、どういう働き方を目指しているのか、そういうことも知ることができました。

──コード輪読会はエンジニア組織においてポピュラーなものなのですか？

@takady：たとえば、勉強会のようなカタチで技術書をセクションごとに輪読することはよくあると思うのですが、コード輪読会は聞いたことないかもしれないですね。

@eric.j：ドメインの担当になった背景も少し変わっているから、こうした珍しい方法で知識を習得していきました。この輪読会を通してチームとしての一体感を形成できたと思います。

@takady：とはいえ、コード輪読会の初回では課題というか難しさもありました。初回はEricさんが担当してくれたのですが、英語メインで進めたこともあり、それほど英語が得意ではないメンバーがいたので議論が深まりづらいところがありました。「日本語でOKですよ」とフォローはしていたのですが、新しいチームになったばかりだったから遠慮があったと思います。そこで次回からの運営に向けた振り返りをして、より輪読会の活動が意味のあるものにする軌道修正をしていきました。

──ちなみに、チームにはどのようなメンバーがそろっているのでしょうか？

@takady：リーダーやマネジャーの経験者が多いです。とはいえ、メルカリでの社歴はそこまで長くない方が多いため、C2Cトランザクションの「全貌がわからない」状態でした。なので、プロジェクトひいてはチームを推進していくにあたり、ドキュメンテーションが非常に重要だと感じています。コード輪読会もひとつひとつドキュメントしていますし、Google Meetのレコーディング機能も活用しています。今後、新しいメンバーが加わった時にも、さまざまな経緯や仕組みを理解できる状態にしていきました。

@eric.j：いままでのモノリス内のドキュメントはコメントで書かれていました。そのコメントをパースして、ドキュメントを吐き出す機能があるにはあるのですが、そもそもそのコメントが果たして正しい内容なのかどうかチェックする機能や仕組みがありませんでした。なので、この運用を引き継ぐことはせず、OpenAPI の仕様に則って API ドキュメントを書くカタチに整備しました。

ここで整備したドキュメントは、QA Teamでも活用してもらっているので、がんばってつくりなおした甲斐がありました（笑）。

Eric Jelliffe（@eric.j）

立ち向かった課題は「大きくて複雑なブラックボックス」

──では、チームとして向き合うべき課題とはなんだったんでしょう？

@takady：輪読会を通して確信したのですが、いちばんの課題はTransactionドメインが「大きくて複雑なブラックボックス」だったということ。ブラックボックスなので全貌がわかる人はいないし、下手に触ると壊れそうな脆さがあり…そこを安全で素早く開発できるものにしていかなければならない。そこがはっきりしたので、チームとしてその課題に取り組んでいこうと決めました。

──この複雑な課題をどのように分解したのでしょうか？

@takady：「システムの単位」と「チームの単位」は異なるのですが、まずシステムの単位でいうとTransactionドメインという1つのまとまりを9つのコンポーネントにわける定義をしました。

一方、チームは2つに分けようとしているところです。具体的に言うと「チェックアウト」と「トランザクション」です。チェックアウトは、買い物するタイミングのペイメントにまつわる部分なので、ここだけでかなりのボリュームがあることがドメイン知識が深まることでわかり、専門のチームとして集中して取り組むことにしました。一方のトランザクションは、取引がつくられてから終わるまでの部分を担っています。

今年のはじめにTransactionドメインを9つに分けていくことを決めた後、どのコンポーネントから優先して着手していくかPMたちと議論しました。そこから優先して進めてきたことがいくつか終わり「疎結合」となりました。その上に新しい機能開発をできる土台をつくれたのは大きな進捗です。

──「疎結合」が意味することについて、もう少し詳しく教えていただけますか？

@takady：コンポーネントを新たに定義していったときに、いまお互いがお互いに依存し合っていたり、強く関係し合っている状態であることがわかりました。その状態のなにが問題かというと、ひとつのコンポーネントになにか変更を加えた際、他の依存しているコンポーネントに大きな影響が及ぶだけでなく、その影響範囲が大きすぎて予測することができないということです。そこを適切に境界を引いたうえで、適切なインターフェースを提供して、ほかのコンポーネントから公式なインターフェースを通してアクセスできるようにすることが、私たちが取り組んできた「疎結合」です。これによって、安全で素早い機能開発が実現できるようになります。

とはいえ、ゴールから見たときに4〜５割ぐらいの到達なので、ようやく半分近くまで終わった状況です。調査設計も並行して進めているので、プロジェクトスタート時のような全貌がわからないという状態ではないのですが、まだ深く見られていないところもあるから、そこはブラックボックスなところはあるかもしれないですね。

──ここまでの進捗の実感はいかがでしょうか？

@takady：あっという間の1年でしたね…。最初はチームビルディングに時間を使い、ここ半年ぐらいの成果で言えば順調と言えます。RFSのために組織されたチームでしたが、RFSに関することだけをやっているわけではありません。この1年で進めてきたことによって、いまは新機能の開発が可能になったので、そうしたことにも時間を使える状況になってきました。Ericさんはどうですか？

@eric.j：チーム発足当初と比べて、メンバー全員のドメインに関する知識が増えました。そこに関しては自信があります。他チームからなにか問い合わせがあった時に、どこを調べてればいいかわかってきました。新しい機能についてPMからリクワイアメント（要件）が来た時にも、どうやって進めていけば良いかの実現可能性がわかってきました。それだけでも自分としてはかなり嬉しいんですよね。

利益に直結する部分を大胆に再設計。その先に目指すのは機能開発とシステム改善の両立

──Transaction Teamはこれからどんなことに取り組んでいくのでしょうか？

@takady：RFSに関していえば、すべてのコンポーネントを疎結合にする必要は必ずしも無さそうということがわかってきたので、ビジネスインパクトが大きいコンポーネントを優先して疎結合化していく方針です。チームの営みはその先も続いていくものなので、それだけではなく新機能の開発にエンジニアやPMと一緒に取り組んでいきたいし、そこがこれから個人的にも楽しみにしているところです。

Transactionドメインは複雑な領域であることは間違いなく、メルカリというサービスにおいて重要度も高いです。そういう重要なところをどんどん作り変えていけるし、その土台の上に新しい機能の開発をしていきたい人にとっては、まだまだやれることが多いタイミングだと思います。

@eric.j：いままでは、大きなスケールのリクワイアメントが来たとしても、素早く対応できないことにもどかしさを感じていました。それが、モジュールをひとつひとつを疎結合にすることで、新しい機能をつくっていける。つまり、お客さまに新しい機能を届けられるようになるということです。それをすごく楽しみにしています。

@takady：お客さまのための機能追加を優先してきた歴史があるので、どうしてもシステムの再設計や整備の優先順位が上がらず、徐々に新しい機能に答えられない複雑なつくりになっていたのは確かです。もちろん、そこを整備しようとする努力はこれまでも個々の動きとしてはあったのですが、ここに対して経営として投資するという判断をしたことによって大きく変化しました。

@eric.j：再設計によるインパクトの大きさも実感しています。既存のシステムを捨てずに、動かしながら再設計するのは本当に難しいこと。これは他の会社ではなかなか味わえないことだと思います。

──いまTransaction teamで働くことのおもしろさはなんでしょうか？

@takady：色んな会社で年数が経つと、大なり小なりリファクタリングや再設計は必要になります。それでもこの規模のサービスで、会社からのサポートを得られて、コアな部分のリファクタリングをやれるのは珍しい。ビジネスニーズを理解して過去の失われた知識を解くことは非常に刺激的ですし、利益に直結する部分を大胆に作り替えることにもおもしろさを感じています。これはチームにとって大きな経験になると感じています。

@eric.j：いま私たちが取り組んでいるのは、「中身は壊さず、ブラックボックスを壊していく」ことです。メルカリの開発者たちは、Transactionドメインというブラックボックスを触るのが怖いから、お客さんに使ってもらう新しい機能を追加するのに躊躇してしまう状況があります。再設計の運用として、開発者が怖がらずにちゃんと使えるインターフェースをつくることで、お客さまにより使ってもらえる新機能がより追加しやすくなるはずです

@takady：RFSはTransaction teamにとってゴールではありません。その先の新しい機能開発を継続して行うことが、自分たちがやるべきこと。今回のRFSのように基盤構築をしても、継続的に機能開発を行っていくと、またリファクタリングが必要になるかも知れません。だから、機能開発とシステム改善を両立していけるようにしたい。それができれば新しい開発をしやすい状態がキープできるし、それがチームとして目指すべき姿だと思います。