メルカリのカスタマーサービス（CS）を支えるプロダクトについてメルカンで紹介したのは、2023年のこと。あれから、この領域の景色は大きく変わりました。

CSのビジョンとして「世界中のお客さまのお困りごとを5分で解決する」を掲げ、2025年には「安心・安全」のスタンスそのものを見直しています。お客さまの手間を最小限にして迅速に解決する「Effortless CX」が、いまCS領域全体の軸になりました。

その実現を担うのがCS Productです。

CSオペレーションのコアとなる社内ツールを持つCS Toolチーム、お問い合わせの受け付けと返信を担うContact Centerチーム、お客さまが直接触れるガイドと導線を持つHelp Centerチーム。3チームのエンジニアとPM、4人に、AIを前提にサポート体験をどうつくり直しているのかを聞きました。

”守り”から、ともにお客さま体験をつくる側へ

—— 2022年の記事から、一番変わったことは何でしょうか。

@kazu69: 当時の立ち位置は「ビジネスに貢献していく」というものでしたが、大きく変わったのは、CSのビジョンが「世界中のお客さまのお困りごとを5分で解決する」と、より明瞭になったことです。

そこからEffortless CXの軸が明確になりました。早く解決するための方法のひとつとして、まずメールからチャットへと切り替えていくこと。さらに、チャットというチャネルはAIとの相性がよく、お客さまの手元で解決できる可能性を上げられる方法だと意思決定され、大きく変えていくことになりました。

@peter: ビジョンに合わせて体制も変わりました。これまでは、オペレーション、プロダクト、エンジニアリングが一体で動くことは、そう多くなかったんです。Effortless CXでは、同じKPIを持ち、一つのワーキンググループとして進めるようになった。これは大きな転換点でした。必要なプロダクトをつくってCSを支える立場から、CSと一緒にお客さま体験をつくる立場へと変わってきました。

問い合わせが起きる前から、プロダクトに関わる

—— CS Productの特徴についても教えてください。

@hirano: Effortless CXでは2年ほどのロードマップを描き、PMとエンジニアが一緒に具体化しています。CSオペレーションとの距離もとても近い。僕が入社した当時と比べて、エンジニアがCSドメインの知識を吸収する力も上がり、「こういうことなので、この機能が必要ですよね」と、PMを介さず現場と話せる場面も増えています。

ではPMは何をするのか。ひとつは、2年先、3年先といった長い時間軸で考えること。もうひとつは、メルカリCSのなかでの最適化という閉じた発想にならないよう、それが世界的に見てベストプラクティスなのか、アンテナを張ることです。A、B、Cというプランしかなかったところに、Xというソリューションを提案してみる。既存の選択肢にとらわれず、組織に新しい視点を持ち込むことがPMの役割だと思っています。

私たちが目指すのは、対応を速くすることだけではありません。取引画面や決済画面など「メルカリ」側の仕様までさかのぼり、「そもそも、なぜここで迷うのか」を考える。問い合わせが起きないプロダクトをつくるため、CSの外側にも働きかけています。

非エンジニアリングの知見に、エンジニアリングを掛け合わせる

—— CSのオペレーションに対して、エンジニアはどう関わるべきだと感じていますか。

@peter: CSに蓄積されたオペレーションやお客さま対応の知見に、技術とプロセスの両面からエンジニアリングを掛け合わせ、複雑な領域を再現性のある形にしていく。それが、僕の考えるエンジニアリングです。課題を待つのではなく、自分たちから領域を広げ、「全部が自分たちの庭」だと思って拾いにいく。「ここはまとめて解決できるよね」と持っていける人に、活躍してほしい領域です。

@hukurou: 私が担当しているCS Toolは、CSのオペレーターがお客さまや取引の状況を確認し、お問い合わせの内容に応じた調査や各種オペレーションを行うための社内向け業務システム。CS業務やお客さまの体験を改善するには、現場の要望をそのまま機能にするだけではなく、エンジニア自身もシステムやCS業務のあるべき姿を考えることが重要です。

特に大きな案件では、最初から全体像やシステム上の解決策が見えているとは限りません。エンジニアがCSオペレーションの担当者と直接話し、PMも巻き込みながら、要望を要件へ落として形にしていく。PMやCSの領域にも知識を広げてインパクトを出すことが求められます。

CS Toolはサービス開始当時から存在しており、長期間運用されてきたがゆえに課題も多いです。特にフロントエンドには、完了できなかったマイグレーションによる技術的負債が重なっています。それでも、CS業務の改善や新機能の開発は止められません。新しい負債を増やさず、速度も落とさず、将来を見据えた解決策を探す。そのバランスが難しさであり、面白さでもあります。

@kazu69: ヘルプセンターは、自己解決のためのガイドとお問い合わせへの導線を担う、すべての起点です。トラブルのとき、お客さまが求めるのは斬新な体験より、とにかく早く、問題なく解決できること。いわば「普通に回っている」状態をつくりながら、事業成長にも貢献する必要があります。いまはグループの各事業が使えるプラットフォームへつくり直し、ガイドやフォーム、チャットを素早く提供しつつ、事業ごとの前提に合わせて、その都度アレンジしています。

AIを「追加機能」ではなく、仕組みを変える力に

—— AIは、実際のプロダクトや開発をどう変え始めていますか。

@hirano: お問い合わせへのAI自動返信を一部リリースしています。ただ、出品者と購入者それぞれの状況を踏まえた回答が必要で、誤返信のリスクもあるため、自動化できる範囲は想定より限定的でした。

そこで見えてきたのは、AIの精度向上だけでは解決しないということです。自動化を広げるには、オペレーションに踏み込み、方針やマニュアル自体を変える必要があります。

@peter: 私はAI AgentやAI Workflowが参照する「Knowledge Master」を構想しています。社内に分散しているSOP（Standard Operating Procedure=標準作業手順書）、メルカリガイド、返信テンプレート、お問い合わせ対応データなどを、人にもAIにも理解しやすく、再利用しやすい形へ整理するナレッジ管理基盤です。

単にドキュメントを一か所へ集めるのではなく、お問い合わせの種類や判断条件、参照すべき情報、実行できるアクションを整理し、バーチャルエージェントやCS担当者の支援、オペレーション改善に使える状態を目指しています。このテーマは別のメルカンで詳しくお話しする予定なので、ここではこのくらいにしておきます（笑）。

@hukurou: CS Toolでは、AIを使ったレガシーシステムのマイグレーションを進めています。複数のAI Agentで既存機能を新しい技術へ移行し、フロントエンドからバックエンドにも応用できる基盤を構築しています。

CS Toolは機能が広く、多くのマイクロサービスとも関わるため、AIに適切なデータを与え、動作を検証することが課題です。一方、既存機能をもとにつくり直す工程はかなり進められるようになりました。複数のAI Agentが連携することで、移行をこれまでの何倍もの速度にできる可能性が見えています。

ロールを越えて、変化を実装できる人と働きたい

—— 率直に、どんな人に来てほしいですか。

@hirano: 僕は巻き込み力が大事だと思っています。「何かやりたいと言うなら手を貸すよ」と思われるような熱量。自分の目指す方向を熱量を持って説明し、周囲の専門家を巻き込みながら流れをつくる。そういう「矢印をつくれる人」と働きたいですね。

@hukurou: エンジニアは、プロダクト視点で考えられる人ですね。技術だけでなく、そもそもプロダクトとしてどうなのかを考えられる人。気がついたら自然とロールの枠を越えている、という熱量のある人がいいと思います。

少し先のビジョンを描き、自分の考えを打ち出せる人は活躍しやすいと思います。

—— CS領域での経験は必須ですか？

@hirano: 「あると望ましい経験」には挙げていますが、必須ではないと思っています。プロダクト（ツール）を変えると、オペレーションには一時的な負荷がかかることもあります。だから、なぜ変えるのか、その先にどんな良い状態があるのかを具体的に説明し、理解と協力を得ることが大切です。ステークホルダーとは抽象度の高い話を熱量高く進めながら、現場には具体的に説明する。PMには、その二面性が必要だと思います。

@peter: CS領域は「支える」「裏方」と説明されがちですが、そのフェーズは変わってきています。システムやプロダクト（ツール）を変えれば、CSの業務にも影響が出る。

だからこそ、現場の難しさを近い距離で理解し、目的や背景をそろえながら、制約のなかで最適な形を一緒に探すことが大切かなと思いますね。

最後に

2022年から変わったのは、会社のグロースの支え方です。要求を受けて機能をつくる立場から、オペレーション、プロダクト、エンジニアリングがともに「何をつくるべきか」を定義し、AIを前提に仕組みそのものをつくり直す立場へと変わりました。

「ここの会社のチャットボット、CS対応は最高です、みたいなのって、まだ世の中にないんじゃないか。そこを目指していきたいですね」。座談会では、そんな言葉も出ました。

ベストプラクティスがないからこそ、自分たちでつくる。目の前のお問い合わせを解決するだけでなく、問い合わせが起きない体験を考え、ロールの境界を越えて変化を最後まで実装する。CS Productにおける「Product Manager」「Product Engineer」は、いままさに再定義されているところです。

写真：タケシタ トモヒロ