プロダクトの価値をユーザーに届けきるまで〜チェックポイントレポートで学んだPdEの責任〜

プロダクトの価値をユーザーに届けきるまで-チェックポイントレポートで学んだPdEの責任-

はじめに

はじめまして。RightTouchでProduct Engineer（以下 PdE）としてQANT Webのプロダクトリーダーをしているbossyです。
私は2023年7月にRightTouchにジョインして以来、約2年半にわたってQANT Webの開発に携わってきました。

PdEというロールは、単に仕様を実装するエンジニアではありません。
ユーザーの課題を起点に、何を作るべきかを考え、仕様を描き、開発をリードし、そして「使われて価値になるところまで」責任を持つ。
RightTouchでは、そんな立ち位置でプロダクトに向き合っています。

本記事では、2025年3月にリリースした QANT Webのチェックポイントレポートについて、その課題感、仕様策定、開発、リリース、そしてデリバリーまでを振り返りながら、RightTouchでのPdEとしての働き方を紹介したいと思います。
リリースから少し時間が経っていますが、「デリバリーまで責任をもつ」という点を特に伝えたく、このタイミングで執筆しました。

QANT Webとは

QANT Webは、Webサイト上でユーザーに困りごとが発生した際に、問い合わせ前に適切なサポートを提供することで自己解決を促進し、カスタマーサポートの業務効率化と事業貢献を同時に実現するRightTouchのプロダクトです。

QANT Webの機能の説明図 FAQページをただ「置いておく」だけではなく、ユーザーの行動や属性に応じて、必要な情報を、適切なタイミングで、適切なユーザーに届けることを重視しています。その中核となるのがサポートアクションという機能です。

サポートアクションとは

サポートアクションは、ユーザーの行動や属性、ページの状態などをトリガーに、「どのようなサポートを、どのタイミングで、どのようなユーザーに提供するか」を制御するQANT Web独自の機能です。

例えば、

ログインエラーが発生したユーザーに、エラーコードに応じて適切なFAQを出し分ける
問い合わせ前のユーザーに、解決につながりやすい選択肢を提示する
自己解決が難しそうな場合に、問い合わせやチャットへの導線を出す

といったように、ユーザーの状態に応じたサポートを柔軟に設計できます。サポートアクションの説明図

これにより、「本当は自己解決できたはずの問い合わせ」を減らしつつ、「人が対応すべき問い合わせ」はスムーズにCSへつなぐ、という役割分担が可能になります。 QANT Webは単なるFAQツールではなく、サポート体験そのものを設計・改善するためのプロダクトです。

チェックポイント機能や、そのデータを可視化するチェックポイントレポートも、こうした思想の延長線上にあります。

「推定解決数」への違和感

入社当時のQANT Webでは、「推定解決数」という指標を一つの重要なKPIとして追っていました。
推定解決数とは、アンサーを閲覧した後に問い合わせに至らなかったセッション数です。

この指標は一定の価値を持っていましたが、同時に大きな課題も抱えていました。
それは、「本当に解決したのか」が分からない、という点です。

問い合わせをしなかった理由は様々です。
自己解決したユーザーもいれば、途中で離脱しただけのサイレントカスタマーも含まれてしまう。
それを「解決」として語るには、どうしても解像度が粗い指標でした。

「本当にユーザーを解決に導けたのかを、ちゃんと測りたい」

そんな思いから、2024年8月にチェックポイント機能をリリースしました。
Web上でサポートした結果、ユーザーにとって欲しい行動を「チェックポイント」として設定することで、ユーザーが本当にその行動をとったのかを可視化し、解決の事実を計測できる仕組みです。

例えば、「ログインに困っているユーザーをサポートする」ためのサポートアクションを出していた場合、チェックポイントに「ログイン」を設定することで、サポートアクションが表示されたユーザーが、その後きちんとログインできたかを把握できるようになりました。

レポート全体を俯瞰し整理する

チェックポイントのリリース後、次に見えてきたのが、「このチェックポイントのデータを、ちゃんと価値として可視化したい」という課題でした。

一方で、QANT Webにはすでに数多くのレポートが存在しており、中にはあまり活用されていないものもありました。 QANT Webのレポート一覧の俯瞰図

そこでまず、レポート全体を俯瞰し、それぞれの役割や、どんな意思決定を支えているのかを整理しました。その上で、「今、足りていないレポートは何か」を丁寧に考えていく必要がありました。デザイナーがメインでワークを進めてくれ、プロダクトオーナーとともに議論を重ねました。

レポート整理のためのワークショップの様子

クライアントとの距離が最も近いCGP（Customer Growth Partner）へのヒアリングも行いました。（CGPについてはこちらの記事にまとめてあるのでぜひ読んでみてください！）

議論を重ねた結果、チェックポイントに特化したレポートを作成し、そのレポートを通じてチェックポイント達成に対するQANT Webの貢献度を可視化することで、QANT Webを活用することでCSがどれだけ事業に貢献できているのかを、より正確に示せるはずだ、という結論に至りました。

こうして、チェックポイントレポートの構想が本格的に始まり、仕様策定を進めました。この段階で行ったのが、

想定ユースケースの洗い出し
「この数字を見て、次に何をすればいいか」が分かるかの検証
プロトタイプができた段階で実際のクライアントへのインタビュー

です。

特に意識したのは、 できるだけ設定しなくても見られるレポートにすることでした。

初見で何を見ればいいか分からないレポートは、結局使われません。極力設定負荷を減らし、設定しなくても一定の価値を得られるレポートを目指しました。

開発

仕様やデザインが固まってきた2024年12月末、当時のプロダクトオーナーに、何気なく聞きました。「これ、いつまでに出したいですか？」

返ってきたのは、「開発のこと何も考えずに気持ちだけで言ったら、3月までには出したい」という答えでした。

正直、簡単なスケジュールではありませんでした。でもその一言で腹を括りました。リリース日を先に決め、そこから逆算してスケジュールを立てました。

RightTouchでは新機能を開発する際、ある程度機能ができたタイミングで社内メンバーに実際に触ってもらい、フィードバックを集める「ぽちぽち会」という場があります。この会を通じて、全く違う方向の機能を作ってしまうことを防げますし、時には、ここで出た要望をリリースまでに組み込むこともあります。

リリース予定日の2週間前にぽちぽち会を設定し、フロントエンドに強いデザインエンジニアと開発の担当を分け、間に合わせるために全力で進めました。「めちゃくちゃいい機能だから、早く届けたい」という、ただその気持ちだけで走っていました。

リリース前日は21時にバグを発見して修正したり、バグ発見時のslackの様子

夜中までエンジニアとデザイナーで細部にこだわり続け、チェックポイントレポートのリリース前のSlackの様子

なんとか形にしてリリースまでこぎつけました。チェックポイントレポートのリリース時のSlackの様子

信頼するメンバーと、心から良いと思える機能を全力で作り上げていく時間は、本当に楽しかったです。

出した、でも使われない

2025年3月7日、無事にリリースはできました。ひとまず、大きな達成感もありました。チェックポイントレポートの画面

bizメンバー全体に向けてチェックポイントレポートに関する共有の場を設け、クライアントにもリリースの共有をしてもらうようにしました。

デザイナーがレポートを使う人の視点に立ち、使い方を丁寧に説明したアンサーも綺麗に作ってくれて、サポートサイトに公開していました。

ただ、現実は甘くありませんでした。思っていた以上に、最初は使われなかったのです。

当時、チェックポイントを設定しているクライアントは全体の約1/3ほどでした。その数は、レポートのリリース後もしばらく大きくは変わりませんでした。 「良いものを作れば使われる」というのは幻想だと改めて突きつけられました。

なぜ使われなかったのか

使われなかった理由は明確でした。チェックポイントレポートは全く新しいレポートだったため、既存のPDCAサイクルの中に組み込まれていなかった のです。

いつ見るのか
どのタイミングで使うのか
何の判断に使えばいいのか

これが定義されていない状態では、どれだけ良い数字が並んでいても「見なくていいレポート」になってしまいます。

デリバリーでやったこと

そこで、社内のCGPと連携し、「どうすればこのレポートが日常業務の中で使われるか」を議論しました。

具体的には、

オンボーディングの中で
- 「チェックポイントとは何か」
- 「このレポートを見ることで何が分かるのか」
- 「どのようにレポートを見れば良いのか」をセットで説明してもらう
定例ミーティングの中で
- 「今月はこの数字を見て、次に何を改善するか」という使い方を、実例ベースで紹介してもらう
どのようなユースケースで使えるレポートなのかを言語化し、CGP内でも共有してもらう

といった取り組みを進めました。

単に「新しいレポートが出ました」と伝えるのではなく、業務の流れの中にどう組み込むか を強く意識したデリバリーです。