TPMとロードマップを一緒に作ったから、エンジニアは自信を持って進められる。RFSから見えたコラボレーションのあるべき形

2021年10月よりサービス・機能開発の基盤を強化する目的で始動したRFSプロジェクト。RFSとは「Robust Foundation for Speed」の略で、メルカリグループ全体の非連続的な成長を支えるため、ビジネスの共通基盤に潜む複雑な技術的課題の解決と抜本的な強化を図るのが目的です。

プロジェクトスタートから1年半が過ぎ、RFSというプロジェクトは組織にどのような変化をもたらしたのでしょうか。この記事ではTransaction領域でのエンジニアとTPMのコラボレーションにフォーカスし、両者が協働することでもたらした変化と影響を、それぞれの観点から振り返っていきたいと思います。

最初期のフェーズでディスカッションし、ロードマップを策定したことが奏功

——まずはプロジェクト初期のフェーズについて、エンジニアとTPMの間でどのようなディスカッションを行い、優先順位を決めていったのか教えてください。

@takady：最初期の3ヵ月ほどはドメインの理解やコード輪読会に取り組み、知識を取得していき、2022年1月から本格的にRFSの活動を始めました。まずは、全体設計としてトランザクションドメインを細かいサブコンポーネントに分ける定義を行っていきました。それから、それぞれのサブコンポーネントに取り組む優先度を決め、RFSのリファクタリングのロードマップを作る必要がありました。そこで SuwenさんをはじめとしたTPMのメンバーと一緒に、将来に予想される機能開発の計画を考慮し、RFSの活動がプロダクトに貢献できるようロードマップを一緒に作りました。

@eric.j：いま、takadyさんが話したことと似ているのですが、私にとってはプロダクトロードマップに基づいて、どのサブコンポーネントを優先させるべきかを検討していけたことが、今回のコラボレーションの最も価値ある部分だったと考えています。また、今後リリースされる機能を聞くことで、どのようにデカップリングを行うか、サブコンポーネントはどこにあるのか、より予測的に考えることができるようになりました。その点で非常に楽しいコラボレーションだったと思います。

Eric Jelliffe（@eric.j）

@Suwen：では、私はTPMの立場からお話ししますね。私がトランザクションチームに加わったのは、takadyさんとericさんよりも数ヵ月前で、それまではトランザクション領域を担当するTPMは存在しませんでした。Transaction チームと一緒に仕事をするようになってからは、チェックアウトやトランザクションの体験を改善するために、たくさんのアイデアを出しあいました。VOC（Voice of Customer）や潜在的な成長分野に基き、いくつかのリサーチも行い、TPMがアイデアのリストを作成していました。

しかし、takadyさんとericさんがTransaction チームに加わるまでは、作業の規模を見積もるのが難しかったのが実情です。長いこと、どのチームもトランザクションの機能やコードを積極的に改善していない状況でしたので、トランザクションの設計もかなり複雑に結合していましたし、システムへの影響を十分に調査することなく新機能を追加するのもリスクが高く、機能追加には非常に時間を要していました。

そこで、エンジニアリング側から、「保守性と生産性を向上させるために、コンポーネントベースの設計によってトランザクションコードをリファクタリングする」提案がありました。それが、トランザクションエリアのRFSについての議論の出発点です。

先ほどお話したように、私たちはいくつかのリサーチから、すでに大まかなアイデアを得ていました。例えば、チェックアウト領域や、メルカリShopsとメルカリでの購入履歴の統合では、リアルカードのポイント表示等の新しい機能を導入したいと考えていました。また「手数料タイプに応じた柔軟な設定」や「取引メッセージ等のコミュニケーション体験の向上」といったアイデアもありました。

アイデアや優先順位をまとめたリストをtakadyさんとericさん共有したところ、そのアイデア実現のためのコンポーネントをすでに考えてくれていました。このように、私たちの間の協力関係は、第一にビジネスの優先順位、第二にデカップリングのためのコスト、第三にある種の依存関係に基づいていたのです。これらの情報をもとに、どのコンポーネントを優先させるかを決めていきました。

——エンジニアとTPMがコラボレーションすることで、プロジェクトがどう加速したと考えていますか？

@takady：システムの改善をどう優先して進めればいいかは、エンジニアリングだけだとなかなか判断できないところがあります。それは、エンジニアリングだけで判断して進めても、目に見えてプロダクトの改善につながらないからです。

そこで、TPMが機能開発の中長期的な計画を示してくれたことで、みんながビジョンを共有できるようになりましたし、それに基づいてRFSプロジェクトで「ここのコンポーネントを優先した方がいい」と決めていくことができました。結果的にみんながRFSで取り組んできたものの上に新しい機能を追加できましたし、現在もいくつかの新たな機能開発のプロジェクトに取り組むことができています。TPMとエンジニアリングでロードマップを共有して優先度を一緒に考えたことで、自信を持ってプロジェクトを進められましたね。

高田祐一（@takady）

@eric.j：Checkout Fee Calculator microserviceのようなマイクロサービスの開発は、RFSの成果の一つだと思います。RFSというムーブメントがないと、多分マイクロサービスを作ろうという勢いはなかったでしょう。マイクロサービスの開発に関わったことで、チームメンバーはいままでの担当領域を超えて、触ったことのない言語に触る機会にも恵まれたのも良かったと思います。

RFSはビジネスイネーブラーとして機能した

——では、具体的にプロジェクトをどのように進めたのでしょうか？

@Manesh：私がトランザクションエリアにTPMとして参加したのは、2022年の8月末頃でした。その時にロードマップに掲げられていた、メルカリShopsとメルカリの顧客情報をひとつにしようという話が動き出してしました。その一環としてBtoC（メルカリShops）だけでなく、CtoCの商品のお客さまの購入履歴を1つにまとめる、Purchase History Consolidationの取り組みがありました。そのためには、既存システムの購買履歴の部分をキャッチアップする必要があり、まずはそこからはじめていきました。

Manesh PATIL（@Manesh）

@adachang：このプロジェクトが動き出す前に、私たちが最初に定義したサブコンポーネントの中に、Purchase Historyを提供するサブコンポーネントが概念上は存在していたのですが、まだそれはコードで表現してない状態でした。

事前にTPMからPurchase History Consolidationのプロジェクトをはじめるという情報と、ラフな要件を聞いていたので、エンジニア側でPurchase Historyのサブコンポーネントのリファクタリング実装を先んじて行いました。その中で、サブコンポーネントの境界やインターフェースを定義したり、それらをコードで表現したり、さらにテストコードをいくつも追加したり…と、Purchase History Consolidationがスタートするときに、手を加えやすい状態にしていったんですね。

結果的には、Purchase History Consolidationのために必要な修正は多くなかったのですが、既存実装にバグを見つけたり、全体的なパフォーマンスの改善もできたり、取り組んで良かった活動となりました。

安達勇太（@adachang）

@Manesh：TPMの立場から言うと、RFSはまさにビジネスイネーブラーとして機能したと思います。購入履歴のコンポーネントをデカップリングすることは、その上に拡張性の高いソリューションを構築するために不可欠でした。

以前は、モノリシックなアーキテクチャだったため、既存のアーキテクチャの上に特定の機能を構築するためにどれだけの労力が必要かを見積もることが困難でした。そのため、購入履歴コンポーネントのデカップリングアーキテクチャは、メンテナンスが容易なソリューションを構築することに非常に役立ちました。つまり、RFSがソリューションの保守性とアクセシビリティの向上に貢献したと言えます。

@adachang：Purchase History Consolidationのプロジェクトは、RFSそのものに直結したプロジェクトではないのですが、コラボレーションとしてはとても大きな成果だったと思います。

最近は、Maneshさんとあまりコラボレーションしていないのですが、チームとしては取引メッセージに絵文字でリアクションできる機能を作っていたり、取引メッセージのテンプレート機能などを開発しています。また、出品者向けのToDoリストのリニューアルも担当していたり、取引の完了画面にメルカードのプロモーションや、メルコインのプロモーションを表示させたり、メルカードの還元率が上がったら、それをお祝いするような機能をこの半期で取り組みました。

TPMとエンジニアの双方からアイデアと知見を共有し、メルカリのシステムを次のステージに導く

——最後にTPMのおふたりにうかがいます。TPMとエンジニアがコラボレーションによって、得られた成果や、これから加速させていべきことはなんでしょうか？

@Suwen：トランザクション領域のRFS活動を振り返ると、以前はビジネスチームやPMは「トランザクションは非常に複雑で、変えない方が良い」という印象を持っていました。でもRFSの活動後、その印象は変わりました。トランザクション領域にも多くの新しい取り組みが生まれ、今ではトランザクションがメルカリの成長に貢献できるまでになりました。これはかなりポジティブな変化と言えます。

次のステップとしては、外からの指示や依頼を待っているのではなく、チェックアウトやトランザクションの観点から、会社の成長にどう貢献できるか、チームからもっと提案できるようになることだと思います。今後の目標は、エンジニアチームと仕事を続けながら、私たちからもアイデアや取り組みを共有し、成長スピードを最大化していくことですね。

Suwen Weng（@Suwen）

@Manesh：takadyさんとericさん、そしてadachangのおかげで、迷いがなくなったように思います。いま、マーケットプレイスでもFintechでも、チェックアウトのチームとトランザクションのチームに要件が多く出されていますが、メルカリのシステム、特にAPIのアーキテクチャは非常に複雑です。いくつかのコンポーネントやトランザクションシステム、チェックアウトシステムをデカップリングすることを行ってきましたが、このチェックアウトとトランザクションエリアが提供する機能のすべてを理解するうえで、私にとって非常に助けになりました。

Purchase History Consolidationのプロジェクトでは、お客さまの購入履歴に関する問い合わせを大幅に減らすことができたことができました。これは、お問い合わせに追われるCSチームの負荷軽減に寄与しました。このような機能が構築されたことで、お客さまに価値を提供することができましたし、GMVの向上などのビジネス貢献もできているのではないでしょうか。

また、Checkout Fee Calculator microserviceを活用することで、フロントエンドシステムやモバイルアプリのクライアントが、ビジネスロジックをすべてバックエンドシステムに戻すことができるため、端末やフロントエンドシステムのパフォーマンスを向上させることができます。

これらは、私たちのコラボレーションがもたらした成果だったと考えています。私たちは、チームとしてシステムをよりよく理解していくことができましたし、TPMの立場からは実現しやすくかつ取り組みやすいアイデアを考えることができるようになった、それは非常に良い経験でした。

@Suwen：今回のTPMとエンジニアのコラボレーションは「チームとして仕事をしている」ということが実感できた体験でした。必ずしもすべての要件をTPMが主導するのではなく、エンジニアリング側も何らかのアイデアや新しい取り組みが共有され、メルカリのシステムを次のステージに導いていく。これが、私の考える最高のコラボレーションのイメージです。