はじめに
2020/01から CSE という役割に就きました。
CSEは「Customer Success Engineer」の略称です。
この記事ではCSEとは?という話と、
弊社、株式会社マツリカでのCSEチームについて解説していきます。
CSEとは?
CSEとは「Customer Success Engineer」の略称です、と書きましたが、
Customer SuccessをEngineeringするとはどういうことでしょうか?
Customer Successとは?
そもそも「Customer Success」とは?ということから見ていきましょう(調べた)
雑にググった結果で恐縮ですが、以下の記事(英語)にはこう書かれています。
www.softwarebusinessgrowth.com
最初にCustomer Successeという名前のチームができたのは1997年にCRMベンダーであるVantive Corporationから始まりました。
当時のエンタープライズCRM(Customer Relationship Management)は失敗率が高く、Vantiveの新しいCSグループはその懸念に対処することを目的としていました。
(意訳)
というわけで、1997年にVantiveというアメリカの会社から始まった概念なようです。
この会社はCRM(顧客関係管理)ソフトを開発しています。
CRMは大量生産、大量消費の市場から顧客ごとのニーズにあわせる市場に変わったことにより、
個々の顧客と綿密な関係を築くために生まれたソリューションです。
で、このサービスの成功率を高めるために作られたチームがCustomer Successチームだったというわけです。
(と上記の記事を雑に訳すとそんな感じみたいです)
Customer Successってなにするの?
上記のVantive社ではまずCRMが割り当てられている顧客にとっての成功を定義し、
その定義した成功に向かって顧客と顧客のビジネスに協力していきました。
現代に置き換えると、SaasモデルにおけるCSの価値が高まっています。
いわゆるパッケージ販売と呼ばれた従来のソフトウェア販売戦略では最初の販売時点で一括に利益が得られていましたが、
SaaSモデルでは継続的に収益が発生していきます。
そのことから、1〜2年で解約してしまう顧客に対するアプローチが非常に大事だと考えられるようになります。
1〜2年での解約は将来に渡って得られるかもしれなかった利益を損ねてしまっているからです。
では、どうすれば1〜2年で解約してしまう顧客の存在を無くすことができるか?
それには、なぜ1〜2年で解約してしまうのか?を考えるとわかります。
単純にそのSaaSが顧客にとって費用に値するほどの価値を生み出せなかったからです。
価値はサービス自体の機能や品質なども重要な要素ですが、
そのサービスを使いこなせているか?というのも非常に重要な要素になります。
例えば以下のような状態では使いこなせていない可能性があります。
- 100個ある機能のうち1個しか使っていない
- まったくログインしていない
- 100人いる(費用を支払っている)うち5人しか使っていない
こういった使いこなせていない状況に対して、
サービス提供側がその顧客に応じて支援していくのがSaaS時代のCSとなります。
※実際には1/100機能でも費用対効果が高いと思えば使いこなせている場合もあります
同様に100人のうち5人が経営陣であれば継続して使われる可能性も高いでしょう
CSEってなにするの?
では、このCustomer Successに対してCustomer Success Engineerは何をするのでしょうか?
ググりましたが定義はこれですとか、起源はコレですというサイトは見つけられませんでした。
英語版のWikipediaにも無いですね。
ただこの役割で求人している企業はいくつも存在しており、
日本語のサイトもヒットします。
だいたいのサイトでは「顧客と製品の橋渡し」だったり、
「技術的な支援や教育をする」と言ったようなことが書かれています。
つまり、Customer Success Engineerは自社プロダクトに詳しく、
その周辺の技術やサービスに詳しく、
顧客の業務に明るくて、
Customer Successチームと共に顧客のビジネスの成功を技術的に支援していく役割となります。
具体的には?
具体的な業務は会社やサービスによって異なるでしょう。
一般的な以下のような業務が当てはまると思います。
- サービスのオンボード支援(技術中心)
- 他サビースとの連携支援
- 顧客からの問い合わせ対応
- Customer Successチームの技術的な支援
主に技術的な支援を行う役割なので、
自社プロダクトを構成する技術には明るい必要があります。
例えばUnix系のOSで稼働するサービスであればUnix系のOSに詳しい必要があるでしょう。
またCustomer Successチームの支援のために、
ユーザーの利用状況を計測、解析したり、データ分析を行ったり、
軽微な開発業務を求められることもあるかもしれません。
(ABテストとかもありそうですね)
なお、Customer Successチームに対しては、あくまで技術的な支援を行う役割となります。
昨今はCustomer Success Manager(CSM)と呼ばれるCustomer Successチームの取りまとめを行うような役割もあるため、
CSEはCSMの作成したストーリーに従って技術的な支援をしていくのが役割となります。
マツリカでのCSEチーム
ここまでは一般的なCSEの役割を見てきましたが、
マツリカでのCSEチームでは以下のような責務をもっていると定義しました。
通常のCSEの役割に加え、通常はCSEチームの役割には存在しない(しなくても良い)、
「Sales Engineer」と「System Engineer」が追加されています。
そのあたりも含めて解説していきます。
「Sales Engineer」と「System Engineer」が含まれている理由
マツリカにおけるCSEチームに期待されている役割として、
「開発以外の業務から開発人員の保護する」というものがあります。
これは数少ないエンジニア、PM(プロジェクトマネージャー)、PdM(プロダクトマネージャー)が開発に専念できるようにするためです。
そのため、CSEの役割に加えて「Sales Engineer」と「System Engineer」がCSEチームの役割に含まれています。
もう少し詳細に見てみましょう。
この記事を読まれているなかで経験がある方もいると思いますが、
エンジニアというのは様々な問い合わせや依頼を受けるものです。
「パソコンが起動しない」「ネットが繋がらない」「あれがない」
「新しいパソコン買ったらかセットアップしてくれ」「これがない」
「法律でシステム監査が必要になった」「AIでなんか上手くやってくれ」
「お客さんに〇〇と言われた(なんか上手くやって)」「明日から全社員のリモートワークよろしこ」
これらは社内からの問い合わせになりますが、
サービス提供しているとユーザーからの問い合わせも数多くあります。
これらの作業を開発業務に従事しているエンジニアに依頼すると、
その間は開発が止まるほか、元の開発作業にもどるまでのブランクが発生します。
このブランクは目に見えない分、計測しづらいものですが、かなりの時間が発生していると思っています。
ちなみにピンとこない方は、難しめのパズルを解きながら誰かに話しかけられるシーンをイメージしてください。
もしそれにストレスを感じず、話が終わっても話しかけられる前の状態にすぐ戻れるのであれば、
ぜひエンジニアになってください。向いています。
この開発業務に対する阻害を無くすために、
CSEチームではエンジニアやPM/PdMに対する開発以外の業務を引き受けています。
その開発以外の業務というのが主にCSEと「Sales Engineer」と「System Engineer」なわけですね。
マツリカでは次に書いたようなことを一部のエンジニアやPM/PdMが担当していました。
(そして大変そうだった)
「Sales Engineer」
マツリカのCSEチームでは「Sales Engineer」業務として、
主に契約前のプロダクトに対する技術的な問い合わせに対応したり、
プロダクトのデモ環境の整備を行ったり、
他システムやサービスとの連携についてサポートしています。
実際に商談に同行して連携について技術的な質問に答えたり(僕は行ってないけどw)、
商談の設計をしている営業さんの技術的なサポートをしたりしています。
例えばコレを書いた今日もお客さんから見たRPAとAPI連携の違いについて営業さんにレクチャーしたりしてます。
「System Engineer」
システムエンジニアと久しぶりに書きましたが、
これも役割がイマイチ明確ではないと思います。
ここでは自社プロダクト(システム)のエンジニアとして扱っています。
その役割は自社プロダクトと他サービスとの連携開発支援になります。
弊社のプロダクト「Senses(センシーズ)」は営業パーソン向けの支援ツール(いわゆるSFA)です。
このSFAは営業業務の中心に位置することもあって、様々なサービスやツールとの連携が求められます。
CRM、MAと言った顧客・営業関連のプロダクト、
Slackなどのチャットツール、メールサービス、データ分析、
グループウェア、会計ソフトなどがその対象です。
そのため、これらのサービスからの連携依頼や、
自社からの連携開発時にそのシステムのエンジニアとして連携のサポートを行っています。
いまやってる業務の一部紹介
現在は社外/社内の問い合わせに対応しつつ、CSチームの支援、
デモ環境の整備やシステム連携、商談のサポートをやっています。
その中で特筆すべきものとして、 問い合わせレポート というものを出しています。
これは週次で問い合わせの内容をレポートとしてまとめています。
目的は以下の通りです。
- 問い合わせから現場へのフィードバック
- 現場の成長
- 問い合わせの低減
弊社プロダクトの主な問い合わせ窓口はInterCOM(チャットサポート)になります。
その問い合わせ内容は殆どのエンジニアが知ることはなく、
どんな不具合があったか、どのような点が使いづらいかなどの有用な情報が伝わりません。
貴重な現場へのフィードバックが無くなってしまいます。
ですが、問い合わせをそのまま流したのでは開発業務が滞ってしまうので、
CSEチームが取捨選択してフィルタリングしたものを展開しています。
フィルタリングは不具合や問い合わせの原因がエンジニア起因であるものを抽出し、
それを教訓として提供しています。
実際の不具合からなるテストパターンの考慮漏れ、実装時の注意点は非常に勉強になります。
バグを作り込んだ事実はツライですが、であるからこそ、成長できることがあります。
また、問い合わせの現場にエンジニアが入ることで、
それまでにはなかった視点で問い合わせに対応することができます。
Q&Aの整備、マニュアル化、自動化、効率化といった観点で問い合わせの現場を支援し、
問い合わせを減らしていくことができると思っています。
これは現場ではなくしがちなふりかえりの視点をレポートとして提供しています。
他にも問い合わせ件数や、内容の種別(フロント/バックエンドとか)、
重さ、InterCOM全体の問い合件数とCSEチームに来た問い合わせ(技術的なもの)件数との比較などを提供しています。
このレポートの元ネタはSpreadsheetに溜め込んだ問い合わせ台帳から作成しています。
別にRedmineなどを使ってもいいのですが、
二人しかいないチームで素早く残すのであればSpreadsheetが便利です。
最近はOffice365のExcelでもいいかもしれませんね。
もう共有して編集して壊すこともなさそうです。
もうひとつこのレポートに込めているのはCSEの価値を社内にアピールすることです。
エンジニアの少ない弊社で開発をメインにしないエンジニアが二人もいるのは、考えどころでしょう。
実際に経営陣に対してはまだ十分に価値を伝えられているとは言い難い状況です。
ですが、現場、特に今まで問い合わせを受けてきていたエンジニアや、
営業に駆り出されていたPM/PdMには価値を感じてもらっています。
また積極的にCSや営業に協力することで、そちらの現場にも価値を感じてもらえるようになりました。
せっかくやるのであれば認めてもらえるほどの価値を出したいと思っているので、
そういったアピールも考えてレポートを出しています。
3ヶ月弱やってみた結果「CSEって結局はSIerのSE」
最後に3ヶ月弱CSEとして業務をした結果の印象ですが、
結局はSIerのSEだなぁという印象です。
ユーザーや社内の言うことを受け止めて(NOT御用聞き)、
一緒にあるべき方向を考えて、
一緒に歩いていくエンジニア。
これは完全に過去に自分がやっていたSEです。
中小の元請けSIerで管理も開発もやっていたあの頃と全く同じです。
電話(個人の他に社用携帯持ってた)とって、メール返して、メンバーの進捗管理して、資料作って顧客や会社に状況説明して、
自分でもコード書いて、現調いって、営業して仕事取ってきて…。
もちろん変わったものもあります。
電話は無くなりましたし、現調もありません。
仕事をもらうための営業もないですね。
他にも変わったことはありますが、基本的な考え方はなにも変わっていません。
相手(CSや営業、エンジニア、ユーザー)の望んでいることを把握して、
「どうすれば最も早く、低コストで、それが実現できるか?」を考える毎日です。
疲れますが、楽しい毎日を過ごしています。
さいごに
久しぶりに会社でなにやってるか的なブログでした。
CSEという役割が楽しくなってきたのと、
あまり周りで聞かない役割なので自分の勉強にしつつブログにもしてみました。
正直コード書きたいエンジニアには向かないでしょうけども、
自分には合っているなーという感じです。
4月からまた状況が変わるかもしれないので、3月中に出せてよかったw
