見出し画像
Photo by sachikoua

カスタマーサクセスマネージャがオンボーディング成功率向上にむけて実践した3つのステップ〜後編〜

hiroseayumi


みなさんこんにちは。エンジニアスカウトサービスLAPRAS SCOUTのカスタマーサクセスチームマネージャをしております廣瀬です。

突然ですが、HUNTER×HUNTER37巻はもう読まれましたか？私は読むのに2時間かかりました。
冨樫先生の、”深さと広さ”に圧倒され、打ちひしがれ、それでもなお自分が努力しなくてもよいという理由にはならない、と、超久々に記事でも書くか…と重い腰を上げた今日このごろです。

さて、本記事はHUNTER×HUNTERを読んでいても読んでいなくても、全く問題なく読んで頂ける内容ですのでご安心ください。

■この記事でまとめたこと


以前、LAPRAS SCOUTを導入いただいた顧客のオンボーディング率を向上していくために、イチから取り組んだ内容をまとめた記事を書かせていただきました。そこから早くも1年以上が経とうとしております…。

その後、LAPRAS SCOUTのオンボーディングプロセスを当初から大きく変えていますので、本日はその変化や今後取り組みたいことについてまとめていきたいと思います。

■オンボーディングプロセスの変更点とその背景

オンボーディング成功の定義

まず、成功の定義そのものを大きく変化させました。

変更前：定量評価（面談獲得件数）のみ
変更後：定量評価（面談獲得件数）と定性評価（スキル・リソース）どちらも満たすこと

変更の背景
オンボーディングの定義を導入した当初は、まずは管理のしやすさ≒振り返りのしやすさを重視し、シンプルに定量評価のみを用いていました。
しかし、やはり面談を獲得できていても、実はマッチ度が低い方との面談が多かったり、マッチ度が高い方と会えたけれども、スカウトリソースが不足し、採用成功に至りうるまでに十分な人数と面談が組めない、といった理由で採用成功や契約更新に至らず終わってしまうということも散見されました。
「このままの運用を続けることで採用成功の可能性が一定以上あるか？」をより精緻に前指標として取るために、採用成功に至っていただくために必要な運用リソースが整っているか？という観点と、できる限りマッチした方と会っていただくためにLAPRAS SCOUTを最大限うまく活用いただいているかという、2つの定性観点をオンボーディング成功の定義に取り入れています。

オンボーディング期間の定義

前述のオンボーディング成功の定義を変化させたことに伴い、オンボーディング期間の定義も、下記の様に変更しています。

変更前：導入開始から1ヶ月間
変更後：導入開始から3ヶ月間


もちろんある程度のエンジニアダイレクトリクルーティングの成功の型・パターンは存在していますが、成果創出にあたっては生身の人間同士のやり取りになるため、やはり絶対的な正解は存在しません。
そこに加え、そもそもエンジニア採用市場は超売り手市場であるため、アプローチ数に頼った運用だとほぼ成果が出る前に母集団が枯渇する、ということも頻発します。
そのため、何度も仮説検証を回して自社における成功パターンを見つけていくまで並走が必要、と判断し、オンボーディング期間を３ヶ月と定義し直しました。

各定期MTGのゴール設定

変更前：定期MTGはキックオフ、1週間後、1ヶ月後の3回。各MTGの大まかなアジェンダのみCSMメンバーで共通認識をもつ
変更後：定期MTGはキックオフ、1週間後、1ヶ月後、2ヶ月後、3ヶ月後の5回に変更。各MTGごとに顧客のあるべき姿を定義。MTG前にGAP確認と課題、ネクストアクション立てを実施。


前述の通り、LAPRAS SCOUTにおけるオンボーディングは仮説検証の繰り返しです。
この仮説検証の精度を各CSMメンバー全員で揃えられるように、各定期MTGごとにその時点でのあるべき状態を定義し、その状態と現状のGAPはなにか、そのGAPを埋めるための課題はなにか、そのために何が必要か、を都度事前に言語化するようにしました。
ただし、このプロセスは同じCSMメンバーでも、これまでの仕事環境やバックグラウンドによって慣れている人・そうでない人の差が大きく出る部分なので、今は２人１組となって１人で抱え込まないような運用をはじめています。

現状把握のための定量レポート

変更前：プロダクト上のスカウト実績表
変更後：LAPRAS SCOUT PLAYBOOK

これまでは、プロダクト上にある下記のスカウト実績表をもとに顧客との振り返りを行っていました。

LAPRAS SCOUT上に表示されるスカウト実績表

しかし仮説検証をより早く・正確に回していくために、さらに細かくデータを見たい、というニーズがチーム内で高まってきました。
そのため、今はLAPRAS SCOUTからダウンロードしたCSVを使って、いつでも簡単に下記のような詳細な運用レポートが作成できるツール（LAPRAS SCOUT PLAYBOOK）を各顧客に用意し、定期MTGでは必ずこの定量レポートをもとにボトルネックの把握、課題抽出やヒアリングを行っています。
今ではもう、このPLAYBOOKがないとどうやってMTGすんの？ってくらい必須アイテムになっています。

LAPRAS SCOUT PLAYBOOK


チーム構成

変更前：特に担当割り振りを決めず、ランダムで担当を決定
変更後：LAPRAS SCOUTの運用体制ごとに、CSM担当をチーム分けする

CSMチームメンバーも４人に増えてきたので、そろそろサブチームに分けてみようかと考えたとき、最初は、顧客の事業ドメインや企業規模ごとに分けようか迷いました。
ただ、結局はLAPRAS SCOUTの運用体制ごとに担当を分けることにしました。

理由は下記の３つです。

  1. エンジニア採用のダイレクトリクルーティングには、とにかく必要となる工数及びスキルセットの性質から、１人で運用を完結できることは非常に稀。であるがゆえに人事・エンジニア・採用代行業者（RPO）、などなど、ステークホルダーやそれぞれのメインミッションが異なるメンバーが運用に関わることが多くなる

  2. RPOが入ると、情報連携のチャネルが一気に増える（人事⇔エンジニアに加え、人事⇔RPO、エンジニア⇔RPOが加わる。LAPRASも加わるとなると、組み合わせは更に増える）ため、ステークホルダー間の情報連携がさらに重要になる。そして直近のLAPRAS SCOUT導入企業において、RPOが入っているケースは４割近くにのぼる

  3. 企業規模が大きい場合でも、最初は1事業部に絞ってスモールに回したほうがオンボーディング成功率が上がる

そのため、サブチームは下記のように分け、今Qのメインテーマを持ってもらいました。

  • スクラム運用を組める企業担当チーム
    →CSMハイパフォーマーの動きを見える化・一般化し、チーム内に横展開する仕組みをつくる

  • RPOが運用に入っている企業のオンボーディングチーム
    →まずは、各RPOの現状把握・課題の特定を行う

これによって、ある程度これまでの知見がある領域と、解像度が低い領域とで、異なる部分にフォーカスした動きが取れるようにしました。

■なぜここまでオンボーディングに投資するの？

ここまで読んできて、もしかしたら気づく方もいるかも知れません。

いくら一般にオンボーディングが重要といわれていても、CSMのリソース割きすぎじゃね？と。

そうですよね。私もそう思います。

ただ、言い訳がましいのは重々承知ですが、このオンボーディングプロセス自体、もはややってることはゴリゴリの仮説検証とプロジェクトマネジメントです。
少なくとも向こう数年はエンジニア採用が超売り手市場であり、エンジニアダイレクトリクルーティングの知見を持った採用人事自体もまだまだニーズに対して足りていない状況が続くと考えていますので、LAPRAS SCOUTのオンボーディングにはこのノウハウが必須になるだろうと考えています。
また、メンバーひとりひとりの仮説検証とプロジェクトマネジメントスキルが伸びれば、更に質のいい課題設定やプロジェクト推進ができるようになることにも確実につながり、そしてそのスキルアップのノウハウが形となっていれば、今後CSMメンバーが増えたときもよりチーム全体の生産性が上がる下地にもなると考え、この取組に投資してきました。

正直、不安や迷いがないか全くないかというとウソになります。

ですが、例えばPLAYBOOKの発案は入社1.5年のなりさんが、各定期MTGのゴール設定やノウハウの横展開は入社1年の千里さんが、RPOの現状把握についてはマサさんが主体となって、もがきながらも顧客のために取り組んでくれているのをみると、多分LAPRAS社でなくても、CSMという職種ではなくてもきっと今やってもらっていることは活きると信じています。

■今後特にやりたいこと

 とは言え、オンボーディングに今ほどのCSMリソースを投下し続ける形ではサービススケールのスピードを上げることは出来ません。

実は今期から開発チームの体制も変わったため、よりSales,CSMを通じて顧客の声をプロダクトに反映したり、抜本的なプロダクト改善にも着手しやすい体制が整ってきました。
オンボーディング強化で培ってきた知見を活かし、CSMがプロダクトにゴリゴリ関与していくことがこれまで以上に重要になると考えていますし、ずっとあたためていたアイデアも一歩一歩進みはじめています。
こういったプロダクトフィードバックについての取り組みも、またぜひ後日記事にまとめたいと思います！

■まとめ

まだまだ課題は山積みですし、なんなら今がまさにサービスとしての転換期を迎えようとしていると思います。
LAPRAS SCOUTは、顧客のサクセスが採用成功という形でわかりやすく現れる反面、競争激しいエンジニア採用市場が主戦場であり、そしてBとCという異なるユーザーをマッチさせる、という非常にサクセス提供の難易度が高いサービスです。（本当は、採用できた企業が更に成長して、入社した方自身の成長につながるまでがサクセスだ！といいたいところですが、これは今後の宿題…。）

ですが、だからこそLAPRAS SCOUTでCSMを担うということは、ハイタッチな支援も行いつつ、B向けプロダクトにも、C向けプロダクトにも大きく関与しながら、課題解決を行っていく必要があります。
ぜひこういった難しい課題を一緒に楽しんで解決していきたい！という方は、お気軽にお声掛けいただけたらと思います！

https://twitter.com/AyumiHirose3


この記事が気に入ったらサポートをしてみませんか？