# チャプター1 皆さん、おはようございます。 スタートアップCSベースプレゼンツゼロから始めるCSラジオです。 このチャンネルは、CSを任されたけど何から手を付ければいいのかと悩んでいる方に向けて、 毎週月曜日の朝、次の一手を一緒に考えていく番組です。 私、進行役の岩田と申します。よろしくお願いします。 本日のテーマは、採用プラットフォームにおけるプロダクト連携のポイントとなっております。 お話し伺うのは、こちらのお二人です。 どうぞ。 皆さん、おはようございます。 私が新規事業立ち上げであてるカスタマーサクセス経験10年元に、 その領域の支援をしているエティという会社の代表、 そして、カスタマーサクセス向けのコミュニティ、スタートアップCSベースを主催している白田です。 よろしくお願いします。 よろしくお願いします。 皆さん、おはようございます。 HRのスタートアップでCSの立ち上げを経験した後に、 今は10名以上のCSチームのマネジメントを務めております。 中川と申します。よろしくお願いします。 よろしくお願いします。 それでは、今日お伺いするポイント、先に3つご紹介します。 1つ目、プロダクト連携は、Howではなく、Whyで語れ。 2つ目、顧客回答度は、採用戦略×現場オペ×データ構造で見る。 3つ目、連携価値をARRインパクトに翻訳できるかが勝負ということになっております。 こちらについて、それぞれ深掘りしてお話し聞いていきましょう。 まず1つ目、プロダクト連携は、Howではなく、Whyで語れということなんですけど、 これはどういうふうな内容でしょうか。 はい、これ1点目、中川のほうから話させていただきます。 このHowではなく、Whyでっていうのが、 PDMとかPMの界隈だとなかなかありがちな話かなと思うんですけれども、 CSからプロダクトのチームにこういう機能開発してくれとか、 こういうことお客さん困ってますっていうときに、 この機能を作ってくださいっていうことをお伝えするのがあまりいけてないのかなというふうに思ってます。 例えば、この採用プラットフォームだと、このATSと連携できるようにしてくださいとか、 応募者データをExcelでダウンロードするときに、この列を追加できるようにしてくださいとか、 だからそういうHowの話ではなくて、お客さんがExcelでアウトプットするのって、 ATSにこういうふうに読み込ませたいからですよねとか、 もっと先のお話をすると、面接の設定を早くしたいからですよねとか、 経営時に対して正しくデータを集計してグラフにしたいからですよねというようなところで、 お客さんが本当に求めているのってどういう体験をしたいとか、 どこを楽したいからなんでしたっけっていうところを含めて、 PMの方とかエンジニアの方でもお伝えをするのが大事かなというふうに思ってます。 なので、お客さんの課題とか、本当はこういう状態がいいんだけど今できてないですよっていう、 2Bの状態というところがプロダクト連携の上では必要かなというふうに思ってます。 これがまさにお客さんが言っているHowをYに翻訳するっていうのが、 CSの大事な仕事かなというふうに思ってますというところです。 そうですね。これ結構CSを何社もやってると、 まさにこのコミュニケーションによってお客さんにいいプロダクトが届けられるのかっていうのも、 肝な話なのかなと僕は思ってて、 この話シンプルに言うと、 Howベースで機能を作ってしまうと、 本当は背景にある課題を捉えたときに解決策が、 お客さんが言っているHow、この機能っていうのが最適じゃないケースがありますというところですね。 本当はこのAという機能をつけると、 B、Cとの機能の連動性が悪くなって、 実はAという機能をつけちゃうと、全体的に見ると、 構数が増えちゃうよみたいなケースがあったりだとかもするので、 その部分はそのY、何でそれをつけたいんですかっていうところを把握した上で、 HowはCSであったりだとか、 開発側と会話した上で、お客さんでの提供価値が最大化されて、 かつプロダクト側としても効率性があるみたいなところを最終的に議論するために、 その前提になるYを持って帰っていく必要があるっていうところが、 僕の中でも普段、CSをしながら結構意識しているポイントかなというところですね。 確かに。欲しいものを全部つけているとぐちゃぐちゃになりますもんね、多分ね。 結局機能が増えると、選択するボタンが増えるんで、 それが難しくなってくるっていう。 ありがとうございます。 こういう文化だったりもすると思うので、 やっぱりチームのメンバーと一緒にこういう風にしていこうねっていう目線合わせも 必要なのかななんて聞きながら思いました。 ありがとうございます。 それでは2つ目についてお伺いします。 2つ目のテーマ、顧客解像度は採用戦略×現場オペ×データ行動で見るということなんですけど、 これはどういう意味ですか? そうですね。これ結局、機能開発をプロダクト連携をする上で、 ちゃんとお客さんのレイヤーに合わせて求めている成果であったりだとか、体験って変わりますよっていう話ですと。 僕に関しては大きく3つで分けていて、経営レイヤー、戦略レイヤー、現場レイヤーみたいになったときに、 経営レイヤーからすると、例えば採用系のプラットフォームを使っている場合だと、 いわば前回の収録でもお伝えしたような、3年後にこういう事業にしたいから、そのために人というリソースを取りたいみたいになると。 それが本当に達成できるのかみたいなところに対して、手段としてプラットフォームを使っていますというところですと。 戦略レイヤーになると、実際それを採用戦略に落とし込んで、 各事業部であったりだとか、各部署に対してどういうターゲットで何人取るかみたいなところに落とし込まれていく。 現場レイヤーになると、それを実際に面接設定をしてオペレーションを回していくっていう形。 見ている目線と時間軸が全然変わってきますっていうときに、実際1個目のYって変わってくるよねっていう話ですと。 例えばなんですけど、現場で面接調整をする方からすると、 例えばデータの入力のしやすさとか、ミスがない面接調整ができるようなダブルチェック機能とかが欲しかったりしますと。 これが戦略経営レイヤーになると、そもそも何人取れんのみたいな全体のダッシュボード機能が欲しいよねとか。 あとは場合によっては、車と比較したときにこのままの推移でいくと、 今年着地何人取れんのとか、どこがボトルネックになっているからいるのかみたいな、その課題を抽出したいみたいな機能のほうが求められますっていうところ。 そうなったときに、大体プラットフォームを提供している企業っていうのは無限に3つがあるわけではないので、 その中でその企業にとって、あとは実際活用いただいているお客様全体を見たときに、 どのレイヤーの課題を解決していくのが一番お客様の活用、採用成功につながるのか。 ないし、自社にとっても良いインパクトを与えるのかっていう、このレイヤー階層に落とし込んで考えていくみたいなところは結構重要なのかなと思います。 あと最後に1個、データ構造みたいなところについては、割とプロダクト扱うものだと根幹になるので、 正しく顧客解像度を持って設計しておかないと、後々データ構造をいじるのって結構リスクあるし、 開発コースもかかってしまうので、ある意味そこを正しくどういう状態になるとお客様が採用成功するのかみたいなところの解像度を持って PDMエンジニアと会話していくっていうところは、CSが一番求められるというか、 バリューを発揮できる1個の役割なのかなっていうところを僕も思ってますというところですね。 そうですね。CSとしては、たぶん現場の方と一緒にお話をすることが一番多くはなってくると思うんですけれども、 その現場の方と一緒に会社の経営をどう動かすかっていうところがまさに大事かなと思いますね。 それができるとお客様の担当者が出世したりとか、MVPもらったりとか、そういう経験をCSとしては一緒に届けたいなというのはずっと思ってますね。 そうですよね。目の前の主担当の方が分かってなければ、それを一緒に捉えに行きましょうということをやってあげることが 目の前のお客さんの成功になる、いわば担当の方の評価につながるというのは、結局目の前のお客さんの方が評価されれば会社としても良い成果が得ているということなので、 それは支援において僕も結構大切にしてますね、目の前のお客さん。 はい。 ありがとうございます。お二人の経験をもとに聞けたお話かなと思います。ありがとうございます。 それでは三つ目も聞いていきましょう。三つ目なんですが、連携価値をARRインパクトに翻訳できるかが勝負ということなんですけれども、これお話を伺っていきます。 まずARRって何というところからお願いしたいんですが、こちらいかがですか? はい。ありがとうございます。ARRって、すごい平たい言葉で言うと売り上げみたいなところなんですけれども、サブスク型のビジネスだと年間の売り上げとか、年間の計上収益みたいなところになっています。 今、1年でどれだけ儲かりますかというところなんですけど、やっぱりプロダクトのチーム、開発のチームにお伝えするときは、この機能があったらとか、この開発をしてくれたら、このぐらい売りにつながるよ、このぐらい会社の利益につながるよというものに最後は翻訳をする必要があるのかなというところになりますと。 結局、チャーンが増えるとか、お客さんの単価が上がるよとか、利給率が上がりますというところになってくるんですけれども、そこを定量化をして翻訳をして、売り上げに置き直して、プロダクトのチームに連携をしていく。 その売り上げの大きさとか優先順位をつけながら、いいプロダクトサービスを作っていくというところが必要になってくるのかなというふうに思いますというところです。 これがないとお客さん困るんですというところよりかは、守れる売り上げがいくらですとか、そういったところまで翻訳をするというところが大事かなというふうに思います。 そうですね。ただこれめっちゃ難しいですよね。 めちゃくちゃの理想を言うと、今既存のお客さんが1000社いて、その中の7割がA、B、Cという機能がボトルネックで解約懸念が出てますとか、そこを要望を求めてますとか。 例えばその機能が解消されると何社のいくらの解約が防げそうです。 いわばこの機能が追加されたら、より入り追加してくれるお客さんが何社いていくらになりますというのが伝えられるということが重要なんですけど、 そもそもこれ伝えるためには、お客さん、冒頭言った各階層に対しての顧客との接点、お客さんをどれだけ正しく把握できているのかというところにもなるので、 そのためにも結局N1で目の前のお客さんに対して、こういうものがボトルネックなんですね。 それはなぜですかとか、それが解決されたら、お店にとってどういうインパクトがありますかというのをちゃんと機能単位で、かつ顧客単位で把握している。 そこを一個ずつ正しく深く把握していくものを、やっぱりPDM開発側に渡していくということが、PDM側も判断しやすくなるかなというところで。 最終的にプロダクト体験を含めて、自社のインパクトとか事業戦略上でどういう機能をつけていくというところは、多分開発PDMまたになるかなと思うんですけど、 正しく判断できる材料をちゃんと渡してあげるというのが結構重要なのかなとは思いますね。 そうですね。開発の方々をという話ではないんですけど、お客さんに一番向き合っているのはカスタマーサクセスじゃないですか、多分。 だからこそカスタマーサクセスから優先順位をレコメンド上げたいですね。開発の方々は逆に僕らのことを信じて開発してくださるというところだと思うので。 そうですね。あえて綺麗な言葉を使わずに言うと、ぶっちゃけこれ一生一生聞いてくるのめんどくさいですからね。 めんどくさいっていう自分の実利じゃなくて、ちゃんとそういうお客さんの声をプロダクトに反映して、お客さんの課題解決と自社の事業成長になっているという、 ちゃんと責任とプロフェッショナルを持ってお客さんと対峙するっていうのがスタンス面においては重要かなというのを。 人間なんでめんどくさいことをやりたくないっていうのが人間の差だかなと思いつつも、そのプロフェッショナル性を求められるっていうのはあるかなと思いますね。 ありがとうございます。難しいことなんですけど、こういう方が開発の方も自分の成果につながるというか、そういう話もしやすいのかなと思うので、すごく大事なことなんだろうなと思いました。ありがとうございます。 それでは、今日3つのテーマについてお話し伺いました。 翌週しますと、1つ目、プロダクト連携はHowではなく、ファイで語れ。 2つ目、顧客解像度は、対応戦略×現場オペ×データ構造で見る。 3つ目、連携価値をARRインパクトに翻訳できるかが勝負という、この3つについてお話し伺いました。 次回は、ファイオプラットフォームのCSのキャリアパスもテーマに、リアルな現場のお話を伺っていきます。 それでは、毎週月曜日の朝に、スタートアップCSベースプレゼンツゼロから始めるCSラジオでまたお会いしましょう。ありがとうございました。 ありがとうございました。