こんにちは。プロダクトエンジニアの ykarakita です。これまで基本機能や人事評価機能の開発チームで開発を行ってきましたが、2023年10月に「エンタープライズサクセス」というユニットを立ち上げました。耳慣れないポジションだと思いますので役割や立ち上げの背景、また立ち上げから1年ほど取り組んでみてわかってきたこともあるので、こちらの記事でご紹介します。
エンタープライズサクセスユニットとは
エンタープライズサクセスユニットは エンタープライズユーザーの導入成功を技術面から支援する というミッションを掲げて立ち上げられた組織です。担当プロダクトはなく、あくまで担当ユーザーの課題を主軸に動きます。 ユニット名からも想像できる通りカスタマーサクセス（CS）領域に近い開発組織で、語弊を恐れずに表すと「開発するCS」というとイメージしやすいかと思います。実際に業務ではCSのメンバーと一緒にユーザーの課題解決について話すことが多いですし、ユーザーヒアリングやユーザーとの定例の場に同席することもあります。
今回はこのユニットを立ち上げる意思決定に至った背景と、実際に立ち上げてみてどうだったかという点をお話します。
これまでの開発体制での課題
これまでSmartHRでは、プロダクト開発の優先順位を「多くのユーザーのニーズを満たせること」を主軸に据えて進めてきました。しかし、特定のエンタープライズユーザーの導入成功を求められるケースでは、いくつかのジレンマが生じることがありました。
多くのユーザーから寄せられる汎用的な機能要望に対して優先度が下がりがち
SmartHRの開発の優先順位は基本的に多くのユーザーから寄せられる要望をもとに決定されることが多いですが、その基準で特定エンタープライズユーザーからの要望を扱うと、優先順位が相対的に下がってしまうという課題がありました。 こうした要望も、他のユーザー要望と同様に期待されるアウトカムや要望の頻度を考慮して優先順位を決めるべきですが、多くのユーザーから求められている機能と、売上の大きい1ユーザーから求められている機能を天秤にかけてどちらを優先的に対応するか正しく判断するには次の難しさがあるように思います。
- 商談状況を織り込む必要がある
- 大口のユーザーの場合、その要望に応じることで契約やアップセルに繋がる可能性が高く、ビジネスに大きなインパクトを与えることがあります。
- 導入に成功した場合の波及効果も織り込む必要がある
- 大手企業の成功事例が他の潜在顧客に与える影響も無視できません。同業他社やグループ企業への波及効果も期待されます。
このように、優先順位の付け方が通常の開発プロセスとは異なり、判断が難しくなることがしばしばありました。
これについてはVP of Engineeringである森住さんの記事でも言及されています。
ジェネリックな機能開発を優先すべき SaaS 事業において、ARR へのインパクトが（直接的にも間接的にも）大きいエンタープライズ企業の要望への対応が難しい、という課題を解決するために組成したユニットです。
SmartHR開発組織の2023年振り返りと2024年の話 - SmartHR Tech Blog
導入プロジェクトの長期化と不確実性
エンタープライズユーザーの導入プロジェクトは数ヶ月から場合によっては数年にわたる長期的な取り組みとなることがあります。その間に新たな課題や要望が次々と浮上することがあります。そんな中、課題が見つかるたびに通常の開発ロードマップに急な変更を加えることは、全体の生産性を低下させるリスクがあります。 また複数プロダクトの改修が必要な場合はそれらの開発計画をチーム間でアラインさせるなどの調整も複雑化していきます。
エンタープライズサクセスユニットを新設
そんな中、あるエンタープライズユーザーの導入プロジェクトをきっかけに、エンタープライズサクセスユニットを立ち上げました。
これまではセールスやCSから開発チームに対して要望を伝えたとしても、他のユーザーからの要望が少ない場合は優先度がなかなか上げられないケースが多くありましたが、ユニット立ち上げ後は「エンタープライズサクセスユニットも含めて対応可否を相談してみましょう」という流れになることが何度もあり、ユニットとして一定のニーズがあることを再認識できました。 通常のプロダクト開発を止めることなく、特定のエンタープライズ企業の要望を拾うことができるようになったことで組織能力の拡大を実感しています。
またユーザーとの定例に参加することも多いため、要望が出てきた背景の理解度や、業務の解像度を高く持つことができるようになり、そのユーザーが本当に欲しいものは何なのか、どういうソリューションが最適なのかといったところから考えられるようになったことは、ユーザーに寄り添いながら開発していることの大きなメリットと感じました。
難しさ
一方で、通常のプロダクト開発とは異なる難しさもあることがわかってきました。
開発チームとのコミュニケーション
自分が担当しているプロダクトを開発するわけではないので、開発チームとのコミュニケーションや機能キャッチアップは丁寧に進める必要があります。また、機能リリース後はそのプロダクトの開発チームの持ち物になるため、理解やメンテナンスがしやすいコードを書くことや、引き継ぎを抜け漏れなく行うことが求められます。
個社要件対応のバランス
個社カスタマイズをしてでも要望を満たす開発をするというわけではありません。SmartHRで提供すべき機能か、他のユーザーにも価値があり使いやすい機能になるかを十分精査し、場合によっては対応を見送ることもあります。個社のニーズを満たしつつ、他のユーザーにとっても価値があると感じていただける汎用的な機能となるよう落とし所を見つけるのは難しくもあり醍醐味でもあります。
プロダクトロードマップとの整合性
柔軟な要望対応が可能になった分、優先順位決定プロセスがこれまでに比べて複雑化していると感じます。以前は単純に要望に優先順位をつけるだけで済みましたが、現在は「これはエンタープライズサクセスユニットで対応すべき要望かどうか」といった議論も加わっています。今後は、エンタープライズサクセスユニットで対応する要望の基準を明確にすることで、意思決定の負荷を減らしていきたいと考えています。
今後の展望
上述したようにエンタープライズサクセスという役割は、他のユーザーからの声は少ないが、インパクトの大きいユーザーの導入に必要なため優先して開発してほしい というシーンで一定のニーズがあることがわかりました。
まだセールスやCS、プロダクト開発チームとの連携フローには改善の余地があるため、今後はそこを整備しコミュニケーションのリードタイムを縮めることで、対応できる案件を増やしていくことに取り組んでいきます。 また、現在は相談があるときに声をかけてもらう受動的なスタイルになってしまっていますが、今後はエンタープライズサクセスユニット側からも受注やチャーン防止に効く施策がないか探して提案していければと思っています。
We Are Hiring!
SmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
