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

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

プロジェクトスタートから1年以上が経ち、いまプロジェクトはどのように進捗しているか。RFSにおいて3つを注力する領域、「C2Cトランザクション」「IDプラットフォーム」「CSツール」をそれぞれ担当するチームのキーパーソンたちに、プロジェクトにおける課題とそれにどのように向き合ってきたのか、3回にわたってうかがっていきます。第2回は「CSツール」の領域を担うCS Tool Teamのマネージャーとテックリードに、それぞれの観点からプロジェクトの現在地を聞きました。

2チーム体制で、CSツールの機能開発に挑む

──CS Tool チームは2つのチームに分かれていますが、まずは皆さんのキャリアと役割からうかがっていきたいと思います。まずは、CS Tool 1（以下、Team1）からお願いします。

@Unsu：僕はソウルのIT企業でウェブ開発を担当した後、2016年に東京に移住して楽天に入社しました。そこでバックエンドチームに所属しながらソフトウェアエンジニアとエンジニアリングマネージャーを担当しました。その後はLINEに入社し、銀行開発プロジェクトに参画しました。そして、メルカリには2022年2月に入社しました。現在はTeam1のエンジニアリングマネージャーとして働いています。

@hukurou：僕は2020年4月に新卒入社したので、もう少しで4年目になります。元々、2018年の夏に1ヶ月だけインターンをしていました。その後、メルカリにソフトウェアエンジニアとして入社してからは、CS Tool チームにずっと所属しています。いまはTeam1のテックリードとして働いています。

──では、CS Tool 2（以下、Team2）もお願いします。

@Peranikov：私はメルカリに2018年11月に入社しました。入社以来、CS Tool チームにずっと所属しています。最初はバックエンドエンジニアとしてメルカリでのキャリアをスタートしましたが、CS Tool チームはTechLeadの持ち回り体制をとっているので、途中でテックリードなどを経験しつつ、2022年の4月からエンジニアリングマネージャーになり、今に至っています。元々、チームの生産性の向上には興味があったので、技術を極める方向だけなく、いつかはマネージャーをやるかもしれないな…となんとなく思っていたところに、チーム体制を変えるタイミングでマネージャーになりました。

松久保敬人（Yuto Matsukubo）

@waiting.lau：私は2018年3月入社なので、この中では一番メルカリ歴が長いですね。最初の3ヶ月だけ他のチームに所属していましたが、その後CS Toolチームに異動しました。バックエンドエンジニアとして入社しましたが、現在はTeam2のテックリードとしてバックエンドやインフラの変更などに着手しています。

──CS Toolチームは事業が拡張していく中で、2チーム体制になったと聞いていますが、それぞれのチームのミッション、これから目指してることなどを紹介してください。

@Unsu：Team1はアプリケーションを含むサービス開発を中心に担当しています。例えば、画面の仕様変更を伴う機能開発をはじめ、実際にCS（カスタマーサービス）のメンバーが使う機能全体を改修したり、開発することがおもな役割です。

具体的にRFSではどのようなことを進めているのかというと、CSツールから直接メルカリのコアとなる巨大なデータベースを参照している部分を排除して、ツール同士の依存性をなくそうとしています。お互いのツールが独立性を持つことで、開発をもっと容易にできるようになるからです。

Eunsu Jang

また、CSツールのフロントエンド側のフレームワークが、現在ではメジャーとは言えないフレームワークを使っている部分があるので、新しいメジャーなフレームワークに切り替えていくことも進めています。これによりシステムの安全性や開発者体験（Developer Experience）が改善することが期待されています。これからの事業拡大によって、新しく発生するCSからの開発要望をより効果的に対応していくために必要なことだと考えています。

@Peranikov：Team2はバックエンドエンジニアとしてキャリアのあるメンバーで構成されています。CSツールの機能を作るという点では、Team1と変わらないんですけれども、Team1がもっと開発しやすくなるような状態をつくるというか、インフラを含むCSツールのシステム基盤、プラットフォームをサポートするという側面が強いかなと思っています。

例としては、いま進めているGKEマイグレーションですね。過去にもオンプレミスで運用していたアプリケーションをGCPに移行したことがあるのですが、これを、メルカリが持ってる他のマイクロサービスと同じ基盤であるGKE上に移し替えるプロジェクトです。CSツールの開発を、他のマイクロサービスと同様な開発の方法で行えることを目指しています。

──プロジェクトの進め方という意味では、それぞれのチームがパラレルで動いているのでしょうか？それともチーム全体として共通のOKRを追っているようなイメージですか？

@Unsu：先ほどお話ししたように、CSツールの開発に両チームとも関わっているので、それぞれのOKRを持ってはいますが密接に関係しています。CS Tool両チームで、OKRの進捗確認をWeeklyで行っていますし、四半期の終わりにはOKRのRetrospective（振り返り）も行っています。そこでもTeam1とTeam2が別々に行うのではなく、両チームのメンバー全員が集まって、それぞれのOKRの達成度を一緒に振り返ったり、お互いの良かった点を称えあったりしています。

いかに集中できる環境を作っていくか、RFSを通して醸成されたチームのカルチャー

──RFSに取り組んでいく中で、チームの開発体制はどのようにアップデートされてきましたか？

@Peranikov：CS Tool チームの歴史から見ると、チームが1つだったときは5人のエンジニアがいました。そのエンジニアの1人だった僕がエンジニアリングマネージャーになり、もう1人がプロダクトマネージャーになって、エンジニアが3人になったことも一瞬あったのですが、RSFという大きなプロジェクトの中で、CSツールにコミットしていくということが決まったので、そこで採用を強化していく流れになり、現在の2チーム合わせてエンジニアが8人の体制になりました。これは僕のマネージャーとしてのキャリアから見ると、けっこうジェットコースターだったなと思うんですよね（笑）。マネージャー目線で大変だったのは、急激にメンバーが増えていくなかで、メンバーがきちんと集中して働きやすい環境を作るにはどうすればいいかっていうことを考えていました。

やはり、CSツールというメルカリの中の1システムをチームで全部見ているため、携わらなくてはいけないドメインも幅広いですし、CSからの問い合わせの対応であったり、他のチームからのリクエストの対応も行わなければいけない。けっこう多岐にわたる仕事をするチームだと思っています。

チームメンバー全員がシステムの全体に対して常にチャレンジをしていることは、それはそれでひとつの理想ではあるんですけれども、コンテキストスイッチとかを意識していくと、集中しなくてはいけない場面の切り替わりが多いこと自体は、開発者の生産性というところにクリティカルに響いてくるところです。そこはチームを2つに分けて、それぞれフォーカスするべきところをある程度絞って、それぞれやるべきことに集中していくという方針に変わったのがここ1年の変化であり、アップデートなのかなと思います。

──確かに大きな変化ですね。Unsuさんの視点で、率直にそのCSツールチームに対して感じた課題感、そこから何を進化させてきたかみたいなところを教えてください。

@Unsu：私が入社した時期がちょうどチームを2つに分けることを検討している段階でした。どういった形でチームを2つにしていくべきかとか、それぞれのチームにどういう役割を持たせるべきなのか、長い時間をかけて議論して決めた覚えがあります。

やっぱり1つだったチームを2つに分けるというのは簡単ではありません。今ではある程度、Team 1はアプリケーション側、Team 2はプラットフォーム側と分けられてはいますが、例えばアラートログに対して監視対応をするオンコールという業務があるのですが、その場合にどちらのチームがどの領域を見て対応するべきか、決めきれていない部分が残っており、これは両チームにプロジェクトのアサインをする時も課題と感じる部分がありました。

この部分については改めて議論を行い、お互いのチームがどの領域を担当するのか、また相手のチームの領域を対応するようになった場合にどのような知識を持っておくべきかを定め、よりクリアにすることができたのかなと思います。

また、チームを分けたばかりの頃は、お互いのチームがどういったプロジェクトをどのような進捗で進めているかが見えづらいという課題がありましたが、先ほど言ったWeeklyの進捗確認会を設けることでそのあたりを改善しました。

これは元々、RSFに特化した進捗確認会だったんですけど、お互いのチームのやっていることを可視化していくべきだろうという方向に向かっていきました。そこからRFSだけではなく、チーム全体の進捗確認会にしていったことで、現在ではそれぞれのチームのタスクがどういった状況で、なにがボトルネックになっているか、他のチームが協力する部分があるかなど、全体的に把握できるようになってきましたね。

──お話しをうかがっていて、チームとしていかに集中できる環境を作っていくことを重視してきたのだと思いました。kimuraさんとtsukaさんの対談でも語られていた、「エンジニア組織のカルチャーのアップデート」というところにつながりますね。では、このRFSにおいて、CS Tool チームとして求められていることは、どういう役割だったと理解していますか？

@Peranikov：CS Tool チーム自体のミッションは、2チーム体制になる前からあまり変わってはいません。僕らはメルカリのお客さまに直接的な価値を提供するというよりは、メルカリのCSに対して技術力を提供して、それを通してお客様の満足度を向上させることを昔から目指しています。

なので、直接的に相対するのはメルカリのCSということになるので、メルカリのCSのメンバーたちが様々なオペレーションを実施するうえで、いかに安全に効率よく行えるかっていうところを、技術力を提供してサポートしていくことがチームの役割です。

もう少し俯瞰した視点で話すと、僕らがメンテナンスしているCSツールというものは、メルカリの創業当初からずっとメンテナンスされ続けてきたもので、他の新しいマイクロサービスと比べると、改善しなくてはならない点がものすごく多くなってきているのが現状です。メンテナンスしながら使い続けてきた結果、技術力によってCSに価値提供できるスピードが遅くなってきてしまっているという問題が起こっている。そこから脱却しなくてはならないフェーズにあります。

RFSのような技術基盤強化プロジェクトを通して、アーキテクチャがビジネスやトレンドに追いつけず技術的に問題になっている、もっと言うと負債になっているところを改善して、最終的にはCSに対して技術力の価値をより早く提供できる形で持っていくのが僕らのミッションであり役割です。

──いつかは取り組まなくてはいけない問題だったけど、ようやくこうした課題に会社として投資していくことになりました。そこでの皆さんのモチベーションみたいなものを聞いてみたいです。「この機会に徹底的にやってやろう！」みたいな気持ちなのでしょうか？

@hukurou：僕が入社する前から、CS ToolチームはCSツールのマイクロサービス化を進めてきていて、元のCSツールから少しずつ機能を減らして、最終的になくなることを目指していました。ただ、実際にマイクロサービス化を進めると、想像以上に機能が多くて複雑な上に、CSオペレーションの調整も必要になるため、かなりの時間がかかっていました。実際、完全にマイクロサービス化することはなかなか難しいだろうと感じていたメンバーは多かったと思うんですよね。なので、既存のCSツールを分けていくという話ではなくて、複雑な機能も含めてしっかりメンテしていく方向に舵とりできたのは、中長期的に見ていいことだとは思っています。

石井怜央（Reo Ishii）

@waiting.lau：インフラに技術的負債があることを現場のメンバーみんな知っていても、そういうことをきちんと解決しようという会社は少ないと思います。インフラの方をきちんと直していくことはかなりコストがかかりますし、インフラ改善のプロジェクトに携われるのは自分にとってはすごく嬉しいことです。自分がインフラでもっとも重視していることはメンテナビリティです。さっき、hukurouさんが言っていたように、CSツールには機能がたくさんあるので、将来的にメンテできなくなる可能性は十分にあると思っているので、いかにメンテナビリティを高めていくかがRFSでの最重要課題ですね。

@hukurou：エンジニアが3人から8人になったとは言え、ドメインが広くていろんな範囲について知っている必要があったので、チーム全体での理解度の向上は必須でしたよね。特にTeam 1は新しいメンバーがほとんどなので、ドメイン知識のサポートなどは意識してきたつもりです。これまでの歴史的な経緯みたいな部分ももちろんそうですし、ここまで何度も皆さんが言っているとおり単純に機能がすごく多いんですね。例えば、3ヶ月に1回ぐらいしか使われないような機能もあったりするので、そうしたことへの問い合わせに対応するのはなかなか慣れないと難しい部分があると思います。

@waiting.lau：hukurouさんが言うように、このチームは本当に仕事の範囲がすごく広いです。他のチームだったら、入社した際のオンボーディングタスクで、ある程度自社サービスとか、ドメインの知識があれば、これまでの経験値から開発に着手できると思うんですよ。

CS Toolチームはその点、他のチーム、特にCSとのコミュニケーションが必須なんですね。メルカリのサービスの利用の仕方については、CSがいろんな対応を丁寧にしてくれますが、僕はいまメルカリで5年目になりますが、いまだに初めて知る機能があったりします（笑）。

──では、あえて聞きますが、大規模な技術基盤強化プロジェクトに挑むことの難しさはどこにありますか？

@hukurou：まだ本当の意味で技術基盤強化というところまで進められてはいないのですが、データベース間の依存を減らしていくとか、フロントエンドを作り直していくみたいなところは、たくさんのCSメンバーが日常的に業務で使っている状態を維持しながら、大きく手を入れていくことはかなり難しいところだとは思います。

「ここは絶対に変更した方がいいだろう」というようなところであっても、いま最適化されているオペレーションが根本から崩れてしまうみたいなところがあったりするので、その辺りの影響も鑑みながら進めるのが難しい部分かなと思いますね。

──大規模な技術基盤強化というまで進められていないと言っていましたが、RFS全体から見ると現在の進捗は何%ぐらいまできてるイメージなんでしょうか？

@hukurou：RFSの最終ゴールをどこに置くのかによるのですが、本当に大規模な技術基盤強化を完了させるという意味で言うと、まだ10〜20%ぐらいなのではないかなと思います。

@Unsu：将来、このRFSで推進したことがチームのカルチャーとして根付いて、継続していける状態を目指すのであれば、まだスタートを切ったばかりというか、10〜20%くらいを着実に進めてこられたと思います。また、現在目指しているフェーズに対してという話で言うならば、今年の6月の完了に向けて、オンスケジュールで進められていると思います。

扱うドメインの範囲も広い、だからこそ基盤から考えられる

──こうした技術基盤強化プロジェクトに携わることが、これからの自身のキャリアにどんな影響を及ぼすと思いますか？

@hukurou：CSツールは機能がたくさんあるという話を何度もしてきましたが、それは昔からずっと継続的にたくさんの人たちがメンテしてくれてきたから今があると思うんですね。たくさんの機能の中には、ビジネスにおいて重要な機能もたくさん含まれているんですけど、そのわりに「古いツールだから」と扱われ方が雑だったと思うんですね。良くない言い方かもしれないですが。

ビジネス的に重要な部分だったりとか、これまでのメルカリの基盤を支えてきてくれたツールに、大きく手を入れるというところの面白さはなかなかない機会ですし、確実に大きな経験になりますね。

@waiting.lau：メルカリアプリは一番大事なプロダクトなので大きな変更が難しいです。というか、ほぼできないんです。だけど、CSツールだとビジネス上の重要度は高いけど、社内向けのツールなので変更させられる余地がある。そして扱うドメインの範囲も広いから、結局はそもそもの基盤から考えることになりますよね。それは、自分のエンジニアのキャリアを考えるうえで、とても刺激的なことだし、すごく面白い。

自分はテックリードなので、他のチームとの相談をしながら進めますが、そこで合意を取るというのがやはり難しいと感じます。それはチームによってそれぞれ要望が違うから。他のチームの要望をそのまま実現しようとすると、CSツールが煩雑なつくりになり、将来的に管理しにくくなっていくんですよね。だから、そのあたりのバランスの取り方がせめぎあいです。自分にとって、CSツールは特別なプロダクトだと感じているので、そのプロダクトを適切に管理してメンテナンスしていくためには、他のチームからの問い合わせや要望に応えられる体制も整備しなければならないと思っています。

Jason Lau

──なるほど、自分たちで適切に管理するために、コミュニケーション面を整備していくというのは、非常に大切な話ですね！では、最後にマネジメント目線からも難しさとおもしろさを、ぜひ聞かせてください。

@Unsu：そうですね。やはりRFSは全社的なプロジェクトになりますが、とはいえRFSを進めながら、事業の優先度的に別のプロジェクトが入ることもあります。その中で、どのような優先度でRFSのプロジェクトと別のプロジェクトを両立して上手く進捗させていくかという課題を感じることがあります。。チームが大きくなったとは言え、まだまだ人が足りないので。

反対に面白さという意味では、こういう全社規模の改修プロジェクト自体がそもそも珍しいし、そういう機会に携われることはありがたいなと思っているので、このプロジェクトが完遂した後でも、ここで培ったことをチームの文化として根付かせていくことがマネジメント面でのチャレンジですね。

@Peranikov：こういったリプレイスの案件は、どう効果を測定するかという課題がありますよね。売り上げやコストカットだと、直接的にビジネスインパクトが出るので、効果として示しやすいのですが、基盤を変えることによってどういったビジネスインパクトを与えられるのか、その指標を定めるのはけっこう難しいところです。そういったところに取り組めていなかったので、計測する仕組みというもの自体が存在していない。なので、これから継続的に活動していくのであれば、やはり数値として見ることができて、こういう効果が出ましたよというのを伝えていくべきかなと思っています。計測するための仕組みをつくることを念頭に入れながら、長期的にシステム改善していくことをも考えなければいけない、かなり難易度の高いテーマであり、それを考えること自体は苦しくも楽しいですね（笑）。