機能要望の一歩先へ。CSが新機能開発に参加してみた振り返り。
こんにちは！Repro株式会社 Customer Success Div.の佐々木です。
Repro（リプロ）では先日新機能として「シナリオ機能（β版）」をリリースしました。この機能をリリースするにあたり、裏側では「カスタマーサクセスがプロダクト開発チームのメンバーとして参加する」取り組みを実施しました。
CS⇔プロダクト開発の連携については参考になる記事がたくさん出ていますが、機能要望の整理についてフォーカスしたものが多く、CSが新機能の開発に参加する、という取り組みについてフィーチャーしたものは意外と少ないのでは？と思っています。
今回の取り組みを通して様々な学びや反省があったのでできるだけ解像度高く書いていきます。
----------------------------
Reproの開発・CS組織
今回の取り組みを紹介する前に、前提としてReproの開発組織やCS組織がどのようになっているのか簡単に紹介します。できるだけ「Repro」がどんな製品なのかわからなくとも読めるように記載しますが、気になる方はこちらへどうぞ！（宣伝）
Reproの開発組織
「Repro」自体はまだまだ発展途上のツールですが、それでも多くの機能があります。開発は機能単位でFeature Teamに割り当てられています。
各Feature TeamにはそれぞれPdMやPMM、Designer、Engineerが所属しており、基本的に各機能の開発はこのチーム内で完結します。
ReproのCS組織
ReproのCS組織の特徴として、通常のカスタマーサクセス（CS・CSM）のチームに加えて、私が所属するGrowth Marketing Teamというプロフェッショナルサービスを提供するチームが存在します。
Growth Marketing TeamではReproがこれまで培ってきたマーケティングナレッジを元に、クライアントサービスの課題定義からマーケティング戦略の立案、実行を一気通貫で支援しています
Growth Marketerと呼ばれるメンバーは「Repro」のツールを使ってクライアントのマーケティング施策を実行するため、Reproでは社内に自社ツールのヘビーユーザーを抱えていることになります。
また、Customer Success Teamでもツール利用のサポートを行うだけではなく、ツールを利用してクライアントのビジネスに貢献することをゴールとしており、CSメンバーの提案能力の高さやClient Firstな姿勢がReproの強みの一つとなっています。
----------------------------
取り組みを始めた背景
さて、本題です。CS組織・開発組織が拡大していくことで機能開発に以下のような課題感がありました。
・CS組織と開発組織それぞれが考える「顧客の課題」や「必要な機能」の認識にズレがある
・開発メンバーとユーザーの距離が遠く、ユーザーインタビューやPoCを実施する際のハードルが高い
・機能要望を中心にCS組織⇔開発組織の連携はあるものの、協働でプロダクト開発や改善していくためのスキームがなかった
・CSメンバーが多忙に思え、開発メンバーが気軽に相談しづらかった
----------------------------
取り組みの内容と振り返り
こうした課題を解決する一つの手段として、「CS・Growth MarketerがFeature Teamに参加する」取り組みが開始されました。
これまではFeature TeamがCSやGrowth Marketerに依頼を行う場合は依頼事項をまとめ、各チームのマネージャーを通して伝達されることが多く、コミュニケーションコストが大きくなったり、テキストベースでのやりとりが多くなっていました。
そこで、シナリオ機能の開発ではCSとGrowth Marketerをそれぞれ1名ずつシナリオ機能の担当として任命し、担当者はFeature Teamと週に1回の定例ミーティングを実施しました。
※Growth Marketer側の担当が私です
定例ミーティングの主要アジェンダ
開発優先度の議論
クライアントやCSとの橋渡しとなるタスクの進捗確認
UI/UXに関するフィードバック
以上が取り組みを整理する観点としても丁度よいため、この3つの観点で取り組みの詳細と振り返りを記載していきます。
開発優先度の議論
ReproではClickUpというタスク管理ツールを使って開発全体のマネジメントをしており、スクラム開発におけるPBI（プロダクトバックログアイテム）やマイルストーンの管理もここで行っています。
本取り組みではGrowth MarketerとCSもClickUpを利用し、月に1回程度の頻度でPBIリストのタスクの内容を確認・重要度を5段階でランク付けしました。（キャプチャの一番右）
例えば、「〇〇のデザインがわかりづらいので改善する」というタスクに対して、必要だと感じたら★5を付け、不要だと感じたら★1や2を付ける、という感じです。
評価の観点としては、シナリオ機能が「どの顧客セグメントに」「いつまでに」「どのような価値を提供するか」が定義されたロードマップを用いて、「各ステージングのゴールを達成するうえでどれくらい重要か」という観点で評価を行いました。
PdMやデザイナーはCS側の5段階評価を開発ロードマップに反映し、気になるものがあれば定例ミーティングの時間を使って認識のすり合わせを行います。この方法をとることで高頻度で認識のすり合わせができ、課題の一つであった顧客の課題や機能の優先度の認識のズレを埋めることができました。
余談ですが、CSメンバーは不要な機能については★1,2をどんどんつけていき、「これはいらないです」とはっきり伝えたのが開発側としては助かったという声がありました。日々の機能要望では「これが欲しい」というのを伝えることはできても、開発のロードマップを見て、「これはいらない」と伝えるのは難しいため、定例ミーティングを設けた一つのメリットだと感じました。
クライアント・CSとの橋渡し
いくらCSメンバーが顧客のことを理解しており、Growth Marketerがツール利用に習熟していると言えど、社内の人間であることには変わりありません。シナリオ開発では通常のツール開発と同様にユーザーを対象としたUXリサーチやPoC検証を実施しました。
これまではある程度機能開発が進んだ段階でFeature TeamのPMMやデザイナーから「〇〇のようなクライアントを紹介してほしい」という依頼が来ることが普通でした。
この方法自体に致命的な問題があったわけではないものの、機能開発に深く関わっていないCSマネージャーを通すことによって、なかなか本来伝えたい意義が伝わっていない、ということがありました。
一方で、シナリオの開発ではCSの担当者を置くことでその担当者が開発の文脈や現在検証したい仮説を把握できているため、他のCSメンバーに対して解像度高く説明をすることができ、場合によってはCS側から「こういったクライアントにPoCの打診をすべきではないか」という提案ができるようになりました。
そして、他のCSメンバーから「あれ、シナリオの開発って今どうなってたっけ」という質問があった際にすぐに担当者が回答することができるため、開発の透明性向上に繋がり、より現場メンバーの協力を得られやすくなりました。
UI/UXに関するフィードバック
UI/UXの中には「クライアントにインタビューするほどではないが、どういった形がいいのか悩ましい」ものがたくさんあります。CSの担当者がつくことで、SlackのFeature Teamのチャンネルや定例ミーティングで気軽にフィードバックができるようになりました。
これまでも全体向けのチャンネルに質問として投稿することはできましたが、開発の文脈や意図を整理して伝える必要があり、ある程度のコミュニケーションコストが必要でした。
モザイクだらけで何がなんやらですが、上記はUXデザイナーのKawanishiさんと私、PdMのMiyashitaさんのやりとりです。この1,2往復のやりとりで疑問が解消することもあるので、積もるとなかなかのコミュニケーションコストの削減になります。
トピックとしてはもう少し重い「Aという画面自体をどうするか」のような議論は定例ミーティングの時間で実施し、日々の疑問はSlack上で解決していました。
----------------------------
反省点
上記の3点は主にうまくいった点でしたが、もちろん反省点もありました。その中でも割とよく発生しそうなものを紹介します。
用語や概念の整理
シナリオ機能は「Repro」の機能の中でも複雑な機能であり、日々の議論の中でたくさんの用語や概念が登場しました。これに加えて、ビジネスサイドが現場で使っている用語や開発者が普段使っているお互いにとって親しみの無い言葉が議論の中でちょくちょく登場し、すり合わせに苦労しました。
途中でこれはまずいと思ったPdMとデザイナーが用語や概念の整理を行ってくれましたが、これはもっと最初の方にやっておくべきでした。
（概念のすり合わせだけで定例ミーティングが終わった週もありました、、、）
お互いの期待値のすり合わせを行っていなかった
何度かの議論を通して次第に定例ミーティングで話すことや日々のコミュニケーションの方法・頻度が決まっていきましたが、当初は互いの期待値がふわっとしており、十分に議論を尽くせなかったり、互いに遠慮してしまうことがありました。
CSの担当者や私としてはもっと色んな点の整理を手伝ったり、議論がしたいと思っていても、開発サイドからは「CSは忙しいと感じており、どのくらい巻き込んでいいかわからなかった」と思われてしまっていました。
頻繁にSlackの議論に参加したり、CS観点から整理した方がよい事項が発生すれば持ち帰りタスクとしたりすることで徐々に緩和していきましたが、最初にお互いの期待値や提供できる工数は伝えておくべきでした。
----------------------------
終わりに
CSメンバーがプロダクト開発に参加することで多くの学びが得られましたが、「より技術的な理解が求められる開発ではCSメンバーがきちんとフィードバックができるのか」、「革新的な機能ではCSのフィードバックはむしろ邪魔になってしまうのでは」、など転用可能性についてはまだまだ検討が必要な点が多いです。
しかし、ある程度成熟してきたSaaS企業で必ず発生する「BizサイドとDevサイドの距離が遠い」という課題を突破する手段として本取り組みは割と有力なのではないかと感じています。
是非なにか参考になれば幸いです！ここまで読んでいただきありがとうございました！
\\Customer Success Div.の求人はこちら//
\\Development Div.の求人はこちら//
この記事が気に入ったらサポートをしてみませんか？