今回より、NE株式会社マーケティング統括部の甲斐 愛佳(かい まなか)様をゲストにお招きして、Openpage代表・藤島との対談形式でお送りします。
1本目は、エンジニアからカスタマーサクセスに転身された甲斐さんの視点から、
カスタマーサクセスの魅力やエンジニアならではの、カスタマーサクセスに活かせる強み等についてお伺いします。
(以下、敬称略)
エンジニアだった甲斐さんがカスタマーサクセスに転身された理由とは?
藤島:
本日は、NE株式会社の甲斐さんにゲストに来ていただきました。
甲斐さんはエンジニアからカスタマーサクセスのOps(オペレーションズ)の仕事をされているそうです。
甲斐:
そうですね。
厳密にはカスタマーサクセスというより、Opsやデータの領域がメインになります。
これまでエンジニアとして、「作る」という事を仕事にしてきました。
そういう仕事をしている中で「作ったものがどうやって売られているのか」等が見えづらかったので、もう少し自分たちが顧客に近いような立場で何かを生み出したり、考えたりといったところに自分の力を使っていきたいなと考え、フロント側に異動しました。
藤島:
やはり、エンジニアのポジションだと「お客様にどう使ってもらってるんだろう」というところが気になりますか。
甲斐:
そうですね。
藤島:
これまでずっとエンジニアのポジションをやられていたのですか。
甲斐:
5年ほど、エンジニアをやった後にマーケティングに転籍をしました。
マーケティングの中ではデジタルマーケティングのような事をやっていこうと考えていましたが、
やっていく中でエンジニア自体の武器であるプログラムが書けることやデータベースが分かること等、
そういった武器を活かして「データを扱う」ということをマーケティングの中でも仕事としていました。
その中で「データの領域」というところに面白さを感じ、今のところ専門的にやっていくことになりました。
「エンジニア」と「カスタマーサクセス」の関係性
「カスタマーサクセス」への第一印象とは?
藤島:
エンジニアからマーケに行き、そこからカスタマーサクセスの仕事でもOps的なエンジニアのスキルを活かしたということですね。
カスタマーサクセスは、どのようなきっかけで仕事として始まったのですか。
甲斐:
弊社はもともとカスタマーサポートが主流の会社でしたが、
カスタマーサクセスを事業にしっかり取り入れていこうというプロジェクトが社内立ち上がり、
その中で「データの基盤を整えていく責任者」としてジョインをした事がカスタマーサクセスに入っていく一歩でした。
藤島:
カスタマーサクセスのデータ周りの立ち上げということですね。
甲斐さんはエンジニアからカスタマーサクセスのOpsやデータの仕事をされたという事ですが、
エンジニアの視点で見た時にカスタマーサクセスはどう映りましたか。
甲斐:
第一印象は「素敵だな」と感じました。
エンジニア目線で言えば今のカスタマーサクセスには「新・カスタマーサクセスの10の原則」があり、
その中でも「エンジニアとカスタマーサクセスは仲良く親友でいよう」というのがあって、これがすごく素敵だなと思います。
<編集部註:「新・カスタマーサクセスの10の原則」の詳細についてはこちらから>
弊社でカスタマーサクセスを導入する以前では、エンジニアとカスタマーサクセス担当との対立がよくありました。
開発側がお客様の事を十分理解できていないところもありますし、
カスタマーサクセス側は顧客の本当に求めている事をちゃんとキャッチできていないところもあります。
両方のコミュニケーションに課題があった中で、
「一緒に顧客の成功に向かって進めていこう」というような歩み寄りをするという考え方は、プロダクトにとってもすごく良い事だと言えます。
「カスタマーサクセス」と「エンジニア」のコミュニケーションのポイント
藤島:
確かにカスタマーサクセスは「エンジニアのプロダクト開発チームと親友であるべきだ」ということは10の原則でも書いてありましたが、
このようにフレーズとしてあると、上手くお互いが会話するいいきっかけになりますよね。
弊社openpageでもカスタマーサクセスとエンジニアの方が最近ご飯会を行ったり、一緒に合議のミーティングを始めています。
NEさんではエンジニアとカスタマーサクセスが仲良くなるイベントはありますか。
甲斐:
弊社ではエンジニアとカスタマーサクセスがslackでも同じ場所で同じトピックについてやり取りしたり、よくご飯等に行っています。
藤島:
エンジニアとカスタマーサクセスは結構距離が遠い形になりがちですが、
最近はその「距離を近づけ、一緒になって良いプロダクト作りをしよう」というような動きが結構見られるようになりましたね。
甲斐:
弊社でもかなり多い動きだと思います。
エンジニアをやっていて一番不幸なのは「作ったものが使われない」ということです。
お客様にちゃんと使ってもらいたい、届けたいという気持ちはエンジニアも強く持っているので
お客様のミスマッチを防ぎ、顧客の成功をCSと一緒になって考えるということが重要だと言えます。
エンジニアならではのカスタマーサクセスに活かせる「強み」とは?
エンジニアの「課題解決力」がプロダクト改善にも活きる
藤島:
エンジニアとカスタマーサクセスの関係をもっと深堀りしたいのですが、
「エンジニアならではの、カスタマーサクセスに活かせる強み」とはなんですか。
甲斐:
例えばユーザーの課題に向き合う時に、
カスタマーサクセスだと課題を抽出したりお客様の求めているものをキャッチするということは得意ですが、
「どういう形で解決するか」というところはエンジニアが持っている課題解決力が大事になります。
どう答えを導いていくか、プロダクトに落とし込んでいくか、というところの力があると上手く事が進むので、そういったところは「エンジニアの出番」だと言えます。
藤島:
確かにカスタマーサクセスの方がお客様の要望を聞き、
そのまま流して「これを作って欲しい」というコミュニケーションはよくあります。
僕も元々エンジニアをやっていたのでエンジニアの視点からすると、それをそのままやるのではなく、
「実はこういうソリューションの方が本当は一番大事な解決方法ではないか?」
「こういう表現で要望をもらったが、本当の悩みはそれではなく別のところにあるのでは?」
といった課題設定やプロダクトとして機能にどう落とし込んでいくのか、
というのはエンジニア視点なんだと感じます。
エンジニアならではのロジカル思考や「プロダクトがわかること」自体も強みに
甲斐:
カスタマーサクセスと一緒に何か会話をする時にも、エンジニアのロジカルな物事の整理の仕方等は結構生きていると思います。
藤島:
僕も甲斐さんとカスタマーサクセスの話をする時に、
非常に体系的でシステム的な思考をされているので勉強させていただいています。
エンジニアだと「プロダクトが分かること」は強みですよね。
甲斐:
私はエンジニアからOpsという領域に入っていますが、
プロダクトの中身を知っている事で、データの流れやどういうプロセスで構築されているかということが分かるので、
CSが「こういうことをやりたい」と考えた時に、
「こういうデータが取れる、みんながこう運用していったらいい」等スムーズに考えられるので「中身を知っている」ということはとても強みと言えます。
藤島:
今ヘルススコアを設計している会社は結構ありますが、
そのデータをどう取るのか、どういうデータが取れるのか等、
「エンジニアリングの知見」が無いとなかなかプロダクトでどういうログを持っているかも分かりません。
そこはエンジニアならではで、データベースの構造が全部分かっているからこそ、
こういうデータだったら取れる、これだったらこう見えるようにすると便利、と言えるのは確かに強みですよね。