【社内留学】カスタマーサクセスを体験するエンジニア

こんにちは。カスタマーサクセスチームの八木です。
Sprocketでは、カスタマーサクセスに所属しているのに私が採用ブログを連載しているように、事業にとって、会社にとって有益であればチームの垣根を越えて積極チャレンジすることを良しとする環境があります。

昨年の６月にエンジニアとして入社された杉山さん、なんと今年度の上半期よりカスタマーサクセスチームの仕事を兼任されています。完全なる留学ではありませんが、エンジニアとしての稼働に重きを置きつつ、カスタマーサクセス業務を兼務しております。

本人から「カスタマーサクセスをやりたい」という話を聞かされた時は、すごく感動しましたね。単に業務を知りたいという興味本位ではなく、それ以上の野心に満ちていたことに驚きました。その流れで杉山さんは私と一緒にカスタマーサクセス業務を行っております。

今回は杉山さんをお招きしてインタビューをお送りします。

カスタマーサクセスへの想い

八木）
杉山さんは、昨年の８月に公開したブログのインタビューでも象徴的な発言をされていました。30歳を目前にして、「目の前の仕事だけではなく会社全体を俯瞰して見られるようになりました。そのタイミングで、エンジニアの立場からカスタマーサクセスの重要性を考えるようになりました」と。

今回、カスタマーサクセスチームの仕事をやってみたいと志願されたのもこのあたりの考えが影響しているのでしょうか？

杉山）
そうですね。前職でもSaaSを取り扱っていたこともあり、カスタマーサクセスに興味がありました。

八木）
なるほど。私は最初この話をお聞きした時は、カスタマーサクセスチームの業務のごくごく一部の仕事を体験できればいいのかな、程度に捉えていたのですが、よくよく聞いてみるとそれ以上の野心に溢れていました。そのあたりは後で聞かせてもらいましょう。

普段のエンジニアの仕事

八木）
カスタマーサクセスチームの留学のお話に突入する前に、まずは杉山さんが入社されて以降のエンジニアでの仕事について聞かせてください。

協業でモノを作るという性質上、杉山さんが一人で何かを作っているという感じにはならないのですが、ざっくり言うとどんなことをされていますか？

杉山）
弊社の開発メンバーは、役割が異なる２つのチームのいずれかに所属して開発業務を行っています。

私が所属しているチームは、クライアントがSprocket（弊社のプロダクトの方）の設定を行うための管理画面の開発が主な担当範囲となっています。大体１日の３～４割の時間は、設計やミーティングなどを、６～７割くらいの時間はコーディングを行っています。

八木）
そもそも全くの異質のものなので違いだらけだとは思いますが、エンジニアの仕事とカスタマーサクセスチームの仕事と最も異なるポイントはどの辺にありますか？

進め方だったり、マインドだったり、違いを挙げたらキリがないと思うので、印象的なものでOKです。

杉山）
確かに、沢山ありますね。

やはり、ＫＰＩの違いは意識しています。開発の仕事は大部分が、決められた期日までに決められたプロダクトを作り上げることが目標だと思うのですが、カスタマーサクセスの場合はクライアントのＬＴＶを最大化することが目標であると認識しています。

私の経験が浅いことも影響しているとは思いますが、カスタマーサクセスの業務では、目標を達成するために取れるアクションが沢山あることと、とったアクションが正しかったのか検証することが難しい印象です。

八木）
そうですよねぇ。ＬＴＶ最大化はカスタマーサクセスの究極のゴールではありますが、まずは目の前の成果を上げる、クライアントの信頼を得るところからスタートとなりますし、その成果だって不確実なものですからね。

状況を見ながら臨機応変に対応を変えていく難しさはあるかもしれません。継続しようと解約されようと、その要因はひとつとは限らないですし、白黒はっきりしないことが多いとは思います。

カスタマーサクセスを知る

八木）
さていよいよ本題です。カスタマーサクセスを自ら体験したいと志願し、稼働時間の一部をプロダクト開発ではなくカスタマーサクセス業務に充てることも社内調整を済ませ、私の案件を一緒に進めてもらうことになりました。

もちろん自社プロダクトに対しては一定の理解はあったと思いますが、実際に案件を担当してみて、これまでにない発見はありましたか？

杉山）
カスタマーサクセスチームのみなさんは、プロダクトを使いやすく運用するためのノウハウをたくさん持っていました。

あとはクライアントと言っても、その人の役職や役割によって、持っている課題が違ったり、プロダクトとの接し方が変わるということを知ることができました。

八木）
施策の企画をしてその実装を行い、成果に繋がるようチューニングを繰り返したり、クライアントとの打ち合わせに参加したり、多くのことが初めての体験となったかと思います。

ご自身で実際に体験してみた印象はどうですか？

杉山）
まずは、純粋に成果が出る施策を考えるのは難しかったです。施策を考える時は、経験豊富なカスタマーサクセスチームのメンバーの皆さんに教えていただいたり、既に実績がある施策集（シナリオ事例集）がとても参考になりました。

打ち合わせでは、クライアントが潜在的に追っている数字を知ることの大切さを実感しました。クライアントによっては、施策による全体的なCVR増よりも、重視している数字があるということを身をもって体験できました。

八木）
そこもバランスのとり方というか、コミュニケーション含めて難しいところですよね。我々はコンバージョンの最適化を求められているので、そこで成果を出さない限りは本来は継続してもらえないはずです。

クライアントのウォッチしている他の指標の成果をあげてそれでも成果とみなしてもらえるなら良いのですが、そうはならないことも多いので。

いわゆる期待値コントロールがしづらいケースですよね。

真の狙い

八木）
はじめに杉山さんがカスタマーサクセスを体験してみたいという話を聞いた時は、最もシンボリックな業務内容でもある「案件対応」を指しているのだと思っていました。ただ、よくよく聞いてみると、どんな会議でどんな話をして、どのような方法で「解約（チャーン）」を防ぐ動きをしているのかを知りたいと。

カスタマーサクセスは、単にクライアントの支援をすることが目的ではなく、究極的には長く使い続けていただくようにすること。杉山さんの意識は「解約阻止」のための手立てを知りたいという方向に向いていました。

これは本当に驚きでした。この野心めいた思いは、エンジニアの立場で知っておきたいということでしたよね？

杉山）
一般的に、ＳａａＳでは、クライアントが増えれば増えるほど、新規案件獲得よりも、解約阻止や（金額的な意味での）アップセルの重要度が増してくると言われています。

そのため、事業が成長しているならば、解約阻止やアップセルに割くリソースは増えていくのではないかと考えています。私のロールはエンジニアなので、カスタマーサクセスチームが練り上げた、解約阻止やアップセルのための運用のコストを、開発したプロダクトによっていかに下げるかということが大事になってくるのではないかと考えています。

そのためには、実際どのように運用されているかや、プロダクトの課題を知っておきたいと思いました。

八木）
案件を少し体験した程度ではわかることはない。案件によって特徴はあるし、「解約」の要因も決してひとつではない。わりと長期スパンで体験しないと得られないことが多い。そこそこ腰を据えてやり続ける覚悟が必要だったと思います。

その意味では、まだまだ色々と杉山さんに伝えていかないといけないこともあると思ってますし、教える側としても道半ばという印象ではありますが、半年間の体験で得られたことはありますか？

杉山）
そうですね。正直分からないことが多く、もっと深く知りたいという気持ちの方が強まった半年間でした。得られたことを強いてあげるなら、開発したプロダクトのユースケースを多く知る事ができたことでしょうか。

開発業務では、少しずつですが、「〇〇という機能は✕✕という仕様」という説明以外に「〇〇という機能はユーザーの✕✕という課題を△△という形で解決するもの」という形で説明できるようになってきました。

八木）
仕様をユーザーの立場から知ることで、より具体的に言語化できるようになったというところでしょうか。野望実現に向け着実に進んでいるようですね。

違う立場から見た景色

八木）
エンジニアという立場からカスタマーサクセスを経験してみると、恐らく私たちとは違う見え方がするんじゃないかなぁと想像してます。カスタマーサクセスの仕事って、クライアントやエンドユーザーとのやり取りというか、駆け引きというか、心理戦みたいなところが多く、一言でいえば「非効率」なこともプロセス上はあったりすると思うんですよね。

あとは合理的に考えればその通りなんだけど、人的リソースや費用の問題で即解決できない事情などもあったりするので。でも現実問題、そういった課題を鑑みての動き方が重要だったりするので、「解約」されないためのコミュニケーションはかなり気を遣ってます。

エンジニアの立場なら、「こうしちゃえば解決するんじゃないか」など思うことも多いのではないかと思いますが、実際どうでしたか？

杉山）
難しい質問ですね（苦笑）。

おっしゃる通り、カスタマーサクセスの業務の中には必ずしも効率化することが正解でない業務もたくさんあると感じました。不確定要素が多い中で、次の契約日までに成果を出さなければいけないというカスタマーサクセス業務の難しさも知る事ができたました。

一方で、クライアントがプロダクトと関わる過程で得られたデータを、カスタマーサクセスのメンバーも利用できるようにすることで、少しでも多くの不確定要素を排除し、クライアントへの価値提供の速度を上げていけるのではないかと思っているます。

この辺りは是非これから試してみたいです。

課題と対策

八木）
考え方も進め方も、エンジニアとカスタマーサクセスでは大きく異なることが多く、同時並行で両業務を進めるのはなかなか大変だったと思いますが、この半年を振り返ってみて感じた課題はありますか？

杉山）
たくさんの小さな課題があると思いました。

それらの多くが、プロダクト開発側としては「このようにプロダクトを使ってほしい」という理想と、「実際の運用のされ方のズレ」の間に生まれるギャップに起因しているのではないかと思っています。

このギャップを解消していくことは、今のところ一番の課題のような気がしています。

八木）
この先まだまだ新しく見えてくる課題も出てくるとは思いますが、エンジニアとしてプロダクト開発に活かせそうなこと、一方でこれは難しそうだと思うことなど、対策に活かせそうなインプットは得られましたか。

杉山）
カスタマーサクセス業務を行う上で、クライアントがどの様にプロダクトと関わってくれているか、カスタマーサクセスのメンバーがプロダクトを含めた「サービスの価値」をどのようにクライアントに伝えているかを体験できたのは大きかったです。

開発チーム内でも、クライアントやカスタマーサクセスチームの課題を伝えることで、少しずつ、開発側とカスタマーサクセス側の認識のズレを埋めていけるようにしたいです。

八木）
プロダクトを使う現場の状況・実態・想いを、開発側にもフィードバックする伝道師の役割ですね！すごく大切な役割だと思いますし、カスタマーサクセスの現場にとっても期待が高まりそうです。

妄想で語るよりも体験談で語る方がはるかに説得力ありますしね。

応募検討者へのメッセージ

八木）
是非また少し時間が経過したら、その後の変化を杉山さんに改めて聞いてみたいですね。これからの活躍も期待しております。

そんな杉山さんから、最後に応募検討者向けへのメッセージをお願いします。

杉山）
Sprocket には人にロールが紐づくという社風があります。私自身、前述のように、開発・カスタマーサクセスの両チームの皆さんの協力もあり、入社時のロールに縛られない働き方ができています。

ロールにこだわることなく、広い視野で見つけた課題の解決に挑んでみたい方には特におすすめです。

ぜひ一緒に、クライアントに価値を提供し続けられるＳａａＳを創っていきましょう！

編集後記

企業同士で交わされる契約が、プロダクトの進化によって「解約を阻止」できる未来、杉山さんのカスタマーサクセスでの体験から機能化されるとしたら・・・そんな未来が訪れる日を思うとワクワクしますね。

市場には競合する製品・サービスが存在している以上、「解約されるリスク」は常につきまといます。その理由は、競合との関係もあれば、自社サービスにご満足いただけない、自社プロダクトにご満足いただけない、そもそも利用費用を捻出できなくなった等、様々です。

様々な理由があるからこそ、全ての解決策をプロダクト側で対応しようというのは恐らく現実的ではないでしょう。それでも、少しでも「解約の芽」をプロダクトによって摘み取れるのであれば、Sprocketの事業成長にとって大きな貢献となることは間違いないでしょう。

というわけで、今後の杉山さんの活動から目が離せませんね（プレッシャーになっちゃうかしら・・・）。結果が出ればもちろん喜ばしいことですが、こういったチャレンジをしようとする杉山さんを私は尊敬しています。

誰もがこのようなチャレンジを求められているわけではありません。任せられた守備範囲でしっかりと成果を出すことも大事です。それでも、やる気次第ではこのようなチャレンジも可能ということが伝われば幸いです。

全てはあなた次第。というわけで、ご興味をお持ちの方は、まずはカジュアル面談を受けてみることをおすすめいたします。

[最新の募集職種一覧]
https://note.com/sprocketrectruit/n/n7e3861b08edf
[コーポレートサイト]
https://www.sprocket.bz/
[採用情報]
https://www.sprocket.bz/company/recruit/
[技術ブログ]
https://medium.com/sprocket-inc