こんにちは！エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている永井（@sho0910K）です。
Gaudiyではここ数ヶ月、CSチームとエンジニアチームのコラボレーションがうまく回り始めていると感じています。
GaudiyにおけるCSチームは、Gaudiyが提供するファンコミュニティでユーザーさんのサポートや体験づくりを担当しているチームです。 社内では「コミュニティチーム」と呼んでいますが、一般的にはCS（カスタマーサポート、カスタマーサクセス）チームが近いと思いますので、今回は「CSチーム」と呼ばせていただきます。
先日公開した2022年の抱負blogにある「プロダクト主導型組織」としてはまだまだ改善すべきところは多いですが、以前に比べればCSチームとエンジニアチームのコラボレーションは多くなってきており、CSチームを通してエンジニアチームにもユーザーさんの声がよく届くようになってきていると感じています。
そこで今回は、CSチームとうまくコラボレーションするために、エンジニアとして大切にしていることをご紹介したいと思います。
エンジニアとCSチームの連携がうまくいっていないと感じている方、プロダクトの改善がユーザーさんに届いているか不安に思っている方の改善の参考になれば幸いです。
- 1. CSチームとのコラボレーションで大切にしていること
- 2. 以前はCSチームとのコラボレーションはうまくいっていなかった
- 3. 改善のきっかけは率直なフィードバックを求めたこと
- 4. CSチームとのコラボレーションで実施してること
- 5. CSチームとのコラボレーションからの学び
- 6. さいごに
1. CSチームとのコラボレーションで大切にしていること
より良いプロダクト開発を進めるためには、CSチームとのコラボレーションは不可欠です。その連携において、エンジニアとしては次のことを大切にしています。
- フィードバックをプロダクト目線で捉える
- ユーザーさんにプロダクトの改善を届ける
- エンジニア視点でのみ話さない
1-1. フィードバックをプロダクト目線で捉える
CSチームからはユーザーさんの率直な意見がたくさん共有されますが、これを受け止める際には「プロダクト目線」を大切にしています。
Gaudiyの提供するコミュニティアプリは、共通基盤をもつワンプロダクトですが、IPごとに別々のファンコミュニティとして提供されています。 そのため改善に関しては、特定のコミュニティでのみ考えるのではなく、コミュニティアプリというプロダクト全体に関わる改善として考えています。
そこで大切なのは、フィードバックとして挙げられた要望の背景をエンジニアとしても理解することです。 背景を理解した上で、最適な設計に落とし込めるようにPdM・エンジニア含めて議論しています。
1-2. ユーザーさんにプロダクトの改善を届ける
フィードバックを元にプロダクトの改善を行ったら、その改善をユーザーさんにきちんと届けることが大切です。 プロダクトの改善は、困っていたユーザーさんに改善された旨が伝わり、再度使っていただいた上で実際に改善されたとわかっていただくまでがゴールだと考えています。
これにはCSチームとのコラボレーションが不可欠で、「今回のリリースでは何を改善したのか」をCSチーム宛に連携することで、ユーザーさんにも改善の旨を伝えてもらっています。
1-3. エンジニア視点でのみ話さない
僕の所属するエンジニアチームでは、週の初めに一週間分の開発スプリントを決めていますが、このミーティングにはCSチームも参加しています。実際のユーザーさんの投稿を参考にして、優先度や対応する項目を議論しています。
この議論の際には、エンジニア視点だけで話さずに、実際にコミュニティを使う側を想定して話したり・技術的な用語を噛み砕いて話したりしています。
2. 以前はCSチームとのコラボレーションはうまくいっていなかった
そもそもの背景として、半年ほど前はCSチームとエンジニアのコラボレーションがうまく回っていませんでした。 具体的には、以下の課題を抱えていました。
- ユーザーフィードバックの優先度があがらない
- CSチームから声があがりづらくなる
- フィードバックに対応するエンジニアが偏る
- プロダクトの改善がユーザーに届いてない
2-1. ユーザーフィードバックの優先度があがらない
Gaudiyはまだまだリソースの多くない組織です。そのため、事業的な開発リソースと運用上でてくる改善や問題への対応のリソースの配分において、どうしても事業進捗に関わる部分の開発のほうが優先されている時期がありました。そんな中では、せっかくCSチームからあがった改善の対応に関しても優先度が上がりづらくなっていました。
2-2. CSチームからの声があがりづらくなる
開発のスプリントとして優先度が落ちてしまうと、スプリントを決める会において、CSチームから発言や改善要望がなかなかあがりづらい状況になっていました。実際、声をあげたとしても受け入れられるかわからないという感覚をCSチームに与えてしまっていたと思います。
2-3. フィードバックに対応するエンジニアが偏る
CSチームから声が上がりづらい状況になったために、突発的なフィードバックに対応するエンジニアも限られていました。当時はエンジニアチームとCSチーム間のコラボレーションも、限られたメンバーで行うなどの偏りがあったため、そこに関わっているメンバーしか自発的に動かないような状況でした。対応をお願いしたとしても「やらされている感」を感じさせてしまっていたと思います。
2-4. プロダクトの改善がユーザーに届いてない
さらに、フィードバックを受けてプロダクトに反映し改善版リリースを行ったとしても、それがユーザーさんに届いていないことがありました。 CSチームがその改善がリリースされたことに気づいていない、ユーザー告知するリリース内容から漏れてしまうといった問題がありました。
3. 改善のきっかけは率直なフィードバックを求めたこと
そんなモヤモヤした状況でしたが、その流れが吹っきれたのは、取締役でPdMを担う後藤からの「CSチームは率直にユーザーさんの声をエンジニアチーム宛に伝えた方がいいと思います」という一言でした。
僕自身もここにモヤモヤを感じていたため、すぐさま賛同しぜひにと相槌を激しく打ったものです。 そしてこの日を境に、Slackの#mimamoriチャンネルから来る通知の量が格段に多くなりました。
4. CSチームとのコラボレーションで実施してること
- ラフにユーザーさんの報告や改善を投稿できる場作り
- リリース内容の共有
- Whyの明確化
4-1. ラフにユーザーさんの報告や改善を投稿できる場作り
CSチームを通してのユーザーさんからの報告は気軽さを優先して、Slackのmimamoriチャンネルに投稿してもらうようにしています。 投稿のフォーマットも現在は設けておらず、かなりラフに投げていただいています。
この投稿に特定のスタンプを付けることで、Shortcutというチケット管理ツールに自動登録されるようにしており、バックログリファインメントの際に確認できるようにしています。
4-2. リリース内容の共有
リリース内容の共有は、Slackのワークフローを使って情報連携を行っています。
リリース内容を確認できるプレビュー環境も共有することで、今回のリリースでどのような内容が更新されるのかを、CSチームのメンバーが実際のプロダクトを触りながら確認できるようにしています。
4-3. Whyの明確化
CSチームから改善要望や施策の相談があがった際には、背景を理解することを意識しています。 その改善や施策が求められている背景は何なのか、一番良い解決策やプロダクトの将来性も含めて議論できるようにしています。
これに関しても、Slackの投稿スレッドでCSメンバーとエンジニア、そしてPdMを交えて活発にやり取りしています。
5. CSチームとのコラボレーションからの学び
以前はCSチームからの報告に対応するエンジニアは限られていましたが、上述したような工夫をしたことで、これまで参加していなかったエンジニアもCSチームとの会話に入ってきたり、報告をキャッチアップしてWhyを聞きに行ったりと、とても自律的に動くメンバーが増えてきたと感じています。
これはCSチームのメンバーが率直にユーザーさんのフィードバックを届けてくれるようになり、Slack上でのフィードバックや改善に対する議論が盛んになったからだと思います。
6. さいごに
Gaudiyのバリューのひとつに「Fandom」という考えがあります。これはあらゆるステークホルダーに最高のファン体験を届ける、というものです。
まだまだプロダクト主導型組織として足りてないところは多いと思いますが、ひとつでも多くユーザーさんにFandomを届けられるように、よりエンジニアチームとCSチームのコラボレーションを濃くしていきたいと思っています。
Gaudiyで一緒にユーザーさんにFandomを届けたい方（エンジニアやカスタマーサクセス問わず）や、CSチームとの連携で同じような課題感を持っているエンジニアの方、ぜひお話しましょう！
Gaudiyの技術スタックやその選定思想については、以下記事をご参考ください。
