TLの持ち回り制、マイクロサービスに合わせた「作り直し」──メルカリを裏側から支える“ちょっと変わった”チームの実態

メルカリが創業以来ずっと注力し続けてきたことの1つに「お客さま対応」があります。そんなお客さま対応を行うカスタマーサービス（CS）のオペレーションを支えているのが──CSToolチームです。

「つまり社内向けツールを開発するチームでしょ？」と侮るなかれ。実は、技術的にもチーム体制的にも他チームとは異なるアプローチを試みる“ちょっと変わったチーム”でもあるのです。

そんなCSToolチームが現在向き合っているのは、マイクロサービス化に伴う新たなCSツールの置き換えと拡大するメルカリグループに合わせた進化、そしてメンバー間の“役割ローテ”…。

そこで今回のメルカンでは、歴史が長いCSToolチームのメンバーにインタビューを実施しました。聞き手は、CSToolチームを含めたCRE領域のエンジニアリングマネージャー（EM）を務める@mohan.bhatkarです。

メルカリグループの半分以上のメンバーが触れるツールを開発

@mohan.bhatkar：僕にとってCSToolチームは、メルカリへ入社してから長く付き合いのあるチームの1つです。改めて、チームの役割を教えてもらえますか？

@wako：メインは、CS向けツールの開発です。ただ、業務内容はどんどん広がっている印象です。というのも、当初はCSメンバーが使うツールでしたが、今やメルカリグループにいる半分以上のメンバーが触れるツールになっています。なので「社内向け」とはいえ、責任範囲が広いツール開発をしているんですよね。

@wako

@mohan.bhatkar：具体的には、どんなツールがあるんですか？

@Peranikov：例えば、メルカリへのお問い合わせをCS側でハンドリングするためのツールやメルカリを使ってくださっているお客さまの情報閲覧・編集、メルカリの商品情報の閲覧・編集、違反出品を通報できるツールなど、CSオペレーションに関わる細かな機能まで担当しています。

＜開発事例＞
・ メルペイリリースのための関連情報追加
・ dポイント連携のための関連情報追加
・ メルカリからのメールが届かなくなってしまったお客さまをサポートする機能
・ 補償の対象になったお客さまを判別しやすくする機能

@Peranikov：ただ、ここ数年はメルカリグループがマイクロサービスという開発手法への移行を始めたこともあり、違反出品やお問い合わせをハンドリングするためのツールを新たにつくり、運用しようと試みています。現状では、CSオペレーションを効率化してビジネスに活かせる基盤づくりを目指しつつ、メンテナンスも進めているところです。

@mohan.bhatkar：@kazuさんは最近入社していますが、どんな印象ですか？

@kazu：僕は2021年10月に入社しました。まだオンボーディングにほとんどの時間を費やしている状況ではありますが（笑）。レガシーになりつつあるシステムをマイクロサービスへ切り出して動かしていくところは技術的にも興味深いですね。1チームだけでは技術領域が狭くなってしまうところがありますが、CSToolチームではフロントエンドをReact、バックエンドはGoなど幅広い範囲の技術を使っています。ここは、何より魅力的ですね。

@Peranikov：確かに、他チームに比べて幅広く技術を使っています。なぜなら、CSメンバーが使うツール開発のフロントエンドやバックエンド、インフラまで一気通貫しなくちゃいけないからです。僕はBackendエンジニアとして入社していますが、GCPを構築したり、データを表示するためにフロントエンドも担当しています。1チームで1社くらいの役割を持っているところは、CSToolチームの特徴と言えるかもしれません。

マイクロサービスへの移行とともに「ツールをつくり直す」

@mohan.bhatkar：他チームが機能ベースでマイクロサービス化しようとするなか、CSToolチームは別アプローチをとっていたわけですね？

@icchy：そうです。CSツールは創業してまもないころからありました。マイクロサービス化しようと全社で動き出したときにはすでにCS組織も大きくなり、オペレーションも多岐にわたっていたんです。そこで機能をそのまま切り出すのではなく、再設計して新しくつくる方向で動くことにしたんです。ちょっと時間はかかりましたが、違反検知とお問い合わせ関連のツールは無事にリリースできました。

@icchy

@waiting.lau：CSツールは、CS全体のオペレーションに関わるものです。だから、エンドポイントごとにマイクロサービス化するのは効率的ではなかった。当時の僕はテックリード（以下TL）として、PMたちと話し合いながら新しい機能としてつくることになったんです。

@hukurou：ただ、新しくつくって丸ごと差し替え…とできないのが難しいところでしたね。新しいオペレーションを設計していくわけですが、CSメンバーは1つのオペレーションの中でも状況によってさまざまな機能を使ってお客さまへの対応をしています。重要な機能から順番に開発していましたが、オペレーションによっては、一部の情報を旧ツールで閲覧する必要があるなど、CSメンバーの手間をとらせてしまうこともありました。そこは僕らとしても反省点でしたね。開発側としても、完全に移行できるまで元の機能を削除できないため、新旧ツールの両方をメンテナンスする期間が長くなる問題もありました。

@mohan.bhatkar：技術的な難しさはありましたか？

@mohan.bhatkar

@icchy：CSツールにはGraphQLを導入しています。CSツールのさまざまな機能を新しいツールとして切り出していく想定は当初からありました。そして、商品やお客さま情報取得など、どのツールでも共通して必要になる機能はあるだろうとも想定していました。

そこで、GraphQLを通して統一されたスキーマを提供することで開発を効率化させようと考えたんです。GraphQLのメインストリームはJavaScriptで、ecosystemの充実や情報の得やすさを考えるとそちらを選択したいところでした。しかし、社内でサポートされる共通ライブラリは基本的にGoで作成されるので、GoでGraphQL Serverを構築するための技術選定や、モニタリングするためのツールに適合するための実装をイチから進めなくちゃいけなかった。それはけっこう大変でした。

@waiting.lau：権限管理のツールも「自由度をどう高めるか問題」がありましたよね。CS組織にはさまざまな拠点があるので、特別な権限を付与しなければならない状況もありました。1年半ほど前に認可周りの設計を考え、GraphQLを通してどのオペレーターがどの操作を行えているかがチェックできるようになったんです。ここは、進化した部分ですね。

CSToolチーム内で「TLを持ち回り制」にした理由

@mohan.bhatkar：CSToolチームは「TLを持ち回り制にする」などユニークなこともしていますよね。なぜ持ち回り制にしたんですか？

@waiting.lau：チームのみんなで話し合って決めたことです。僕は3年ほど前にメルカリへ入社しましたが、しばらくしてTLをしました。CSToolチームでのTLは、マイクロサービス化したToolの導入や改修などさまざまなチームから相談が寄せられます。

おかげで、他チームが何をしているのか、何に集中したいのかがわかる。つまり、視座が変わるんですよね。持ち回り制にしたのは、TLとしての視座をみんなにシェアしたかったからです。みんながその視座を持てば、重要な判断をするときにも役に立つはず。

@waiting.lau

@wako：これは自慢ですが、うちのチームは本当にBe a Proなメンバーが揃っています。ある程度の情報をまとめて相談すると、プロフェッショナルな解決をしてくれる。それに、突破力もある。誰でもTLができるチームです（笑）。

@Peranikov：僕は2018年に入社して、当初はソフトウェアエンジニア、その後はTLを経てEMをしています。そして今、TLのバトンは@hukurouさんの手に！

@hukurou：まだTLを引き継いですぐなので、みなさんに比べてどのくらいできているかはわかりませんが（笑）。ただ、TLが他チームとどんな会話をして、どうやって結論を出してきたのか、何を判断しないといけないのかは、実際にTLにならないとわからない部分も多いなと実感しています。こういったチームのいろいろなことを判断する立場にいさせてもらっていることは、自分にとって今までにないチャレンジができそうな予感はありますね。

@hukurou

@mohan.bhatkar：@wakoさんも、エンジニアからプロダクトマネージャー（PM）へロールチェンジしていますよね？

@wako：そうですね。メルカリへ入社したのが2018年、PMへのロールチェンジをしたのが2021年2月からなので…そろそろ8ヶ月ほど経ちます。こうやって、他職種へチャレンジさせてもらえるのはありがたいですよね。僕はPMになる直前までTLをしていましたが、こうやってロールを大胆に変更できるのは、CSToolチームに底力があるからこそです。

「日が当たりにくいチーム」だけど…？

@mohan.bhatkar：みなさんは、CSToolチームのどこにモチベーションを感じていますか？

@Peranikov：はっきり言って、CSToolチームはメルカリの表面に出るような機能をつくりません。そういう意味だと、日が当たりにくいチームです。その一方で、モノリシックなものをマイクロサービスへ置き直す複雑性への技術的挑戦ができるし、何よりお客さまと間近でやりとりをするCSメンバーのオペレーションを支える＝ビジネスを支えていると言えます。そこにやりがいを感じられる人は、相性がいいかもしれません。

僕にとってこのチームでのモチベーションは、CSツールもメルカリにとって大事な一部だと思っているから。やるべきところに責任を持って挑めるのは、やっぱり楽しいですね。

@Peranikov

@wako：同じくですね。そして僕はCSツールを進化させることでCSメンバーの仕事の質を上げ、「メルカリはCSの質がいいから使いたい」と言われるようにしたいんです。確かに日が当たりづらい仕事かもしれませんが、僕はその目標に向けてひた走ることが何よりのモチベーションです。

@mohan.bhatkar：ほかのみなさんは？

@hukurou：CSツールは、お客さまへの直接的な影響はそれほど多くないかもしれません。ですが、メルカリのサービスへの影響は決して小さくありません。例えばどこかのチームで新しい機能を開発したいとなったら少なからずCSツールに影響が出ますし、状況によってはメルペイなど他の事業からの影響も受けます。そのため、広くさまざまなチームの提供しているサービスについて理解しておく必要があります。メルカリのサービスに広く関わっているCSツールを支えていることに、僕は手応えを感じていますね。

@waiting.lau：ほとんどのチームが、セクションごとに分かれて開発をしています。CStoolチームで開発している社内向けツールは、ほとんどの開発で使われています。先ほども話していたように、事業やサービス拡大とともに、僕らの挑戦も挑戦的なものになっている。僕は、マイクロサービス化を進めつつ、課題を乗り越えながら、メルカリのサービスへ継続的に貢献していることは、楽しいです。

@kazu：CSToolチームへのジョインを希望したのは、開発を通してサービスが持っている機能や課題などプロダクトの面でもいろいろなことを知れそうだったから。そして、その課題を解決していくことはやりがいがありそうだと思ったからでした。技術的な部分ではフロントエンド、バックエンド、インフラまで一貫してエンジニアが担当していて、幅広い知識を使ってマイクロサービス化など新たなチャレンジもできるところは、他にはない面白さがありますよね。

@kazu

@icchy：レガシーなシステムをマイクロサービスへ切り出したり、GraphQLを導入したり、他チームにはなかなかない挑戦ができるのはこのチームならではですね。今後はメルカリの成長に伴ってさまざまな課題が出てくるはず。挑戦しながら、解決していきたいです。

いちチームがプラットフォームになろうとする挑戦を！

@mohan.bhatkar：マイクロサービスへの移行もありますが、これからのCSToolチームはどんなことに挑む感じですか？

@Peranikov：ここ数年では、ドメインごとに新しいシステムへの切り出しを進めていました。でも、まだまだモノリシックなものは残っていて、なかでもPHPで書かれた初期のシステムをうまくマイクロサービスへ移行できず、難航しています。ここは全社的に取り組んできたことではありますが、PHPで書かれたコアな部分を疎結合化して、素早く新しいものへ変えるのは目下の目標です。

@wako：メルカリグループ内でも、メルペイにメルコイン、ソウゾウ、メルロジなどさまざまな会社が誕生しています。そのたびに、新たにCSToolをつくっていくのはさすがに大変です。

僕たちとしては、ここから3年ほどかけて、全社的な情報を集約できる場所へ進化できないかなと考えています。そうするとCSToolというチーム名じゃなくなるんですけど（笑）。いちチームがプラットフォームになろうとするのも、なかなかチャレンジングだと思うんですよね。

Meetyはこちら！