見出し画像

プロダクトチームとCSの連携のお話

この記事は 🎄10X プロダクトアドベントカレンダー2023の19日目(12/19)の記事です!
昨日は、データアナリストのむらなかさん(@ktrru)の「データ提供はプロダクトの機能の一部である」という記事を公開しています。
「データがプロダクトの提供先の小売企業にとって極めて大きな価値を提供していること」について学べる素敵な記事でした。(むらなかさん、めちゃ頼もしい方です!)

本日はサポート部(以下、CS)のogaが担当しますが、ちょうど去年の10Xのアドベントカレンダーには入社エントリをポストしました。

今回のアドベントカレンダーは「プロダクト」がテーマということで、本記事ではCSがプロダクト組織と日々どのようなコミュニケーションをとり連携し、一緒にどのような取り組みをしているかについて書いてみたいと思います。

そこで今回は、CS視点だけではなく、プロダクトから見たCSとの連携やそれに対する評価のような視点も入れようと思い、プロダクト組織からエンジニアのtakanamitoさんとプロダクトマネージャーのaineさんに協力してもらい、インタビューをしてきたので、対談形式でお届けします。


メンバー紹介

SWE takanamitoさん(@takanamito

10Xのお買い物チームのSWE。本アドベントカレンダー9日目の記事「grpc-dartのInterceptorを使う」を公開しているのでぜひ読んでみてください!


PdM aineさん(@i_nene

10XのマスターデータチームのPdM。昨年のアドベントカレンダーで「10Xで未経験からプロダクトマネジャーになるまでの話」という記事を公開してます。本アドベントカレンダーでは、21日目の記事を担当しているので楽しみです!


CS okaeriさん(@aqua0_0skow

10Xのサポート部メンバー。10X 創業6周年アドベントカレンダーで「「10X、馴染めるかな?」と思っていた私が「10X、大好きなんだけど!!」となるまで」という記事を公開しているので読んでみてください!


CS oga(@__ogacs__

10Xのサポート部メンバー。本記事の筆者。

※ 以下、敬称略

インタビュー①(エンジニア×CS)

まずは、エンジニア:takanamitoとCS:ogaで前期に行ったいくつかの改善の取り組みについて振り返ります。

  • インタビュアー:okaeri

  • インタビュイー:takanamito、oga

始まりはお互いの課題感

okaeri
「takanamitoさんとogaさんでいくつか改善をしたということなんですが、どういう経緯だったか教えてください。」

oga
「たしか5月くらいにtakanamitoさんからお声がけいただいたと思います。一緒に何をやったかというと、当時CSからお問い合わせの流れでお買い物チーム(10Xではドメインベースの開発体制をとっています)への開発関連のエスカレーションが多かったので、実際のエスカレーション内容を棚卸して効率化するとインパクトが大きそうなものを探しましたよね。」

okaeri
「当時はCSからの開発関連エスカレーションが多くて、エンジニアも逼迫していたんですか?」

takanamito
「逼迫するほどではなかったんですが、(本来は開発に集中すべきである)エンジニアが日々お問い合わせに(多くのリソースを割いて)対応するのが当たり前の状況になっていて、それをなんとかしたかったという課題が僕の中にあったんです。」

oga
「僕もCSからエンジニアへのエスカレーション含めて連携を効率化できないかという課題を持っていて、ちょうど取り組み始めた時だったので、とてもタイミングがよかったんです。」

エンジニアだけしかできなかったことをCSだけで完結させることにフォーカス

okaeri
「では、実際に棚卸しをしてみてどういうことがわかって改善する目処がついたんですか?」

takanamito
「一番最初にやったのは、ユーザー行動ログや注文や商品ステータスログの調査をCSが行えるようにすることでした。当時はある事情でCSが必要なデータにアクセスできない状況があったので、そこを改善することにしました。対応件数もユーザー行動ログ調査が多かったです。」

開発関連エスカレーション案件の棚卸しの一部

oga
「ログ調査もそうですが、ユーザーを退会させる処理や商品情報のマスターデータをDBにインポートする処理なども問い合わせによる発生件数が多い割に、エンジニアしかできなかったので適宜エスカレーションして都度手動で処理してもらっていました。それをCSだけで完結できるようになるといいよねという話をしていました。そしてそれらを管理画面に実装(ツール化)してもらい、CSが通常のオペレーションとして処理できるようになりました。」

okaeri
「なかなかCSだけからのレイズだと(元々予定されている開発計画もあるので)開発優先度が上がりづらい局面がありますが、takanamitoさんからチームに実装してくれとプッシュしてくれたんですか?」

takanamito
「いや、そんなにプッシュはしていないですし、それらを実際に僕が手を動かしてそれらを実装したわけではなく、ogaさんと一緒に棚卸し結果から道筋を立てました。それを整理した結果をいろいろな関係ありそうな人に共有はしました。今まであまりそのような機会がなかったので、解決すべき課題として共通認識が作れた思います。あと、エンジニアが対応した手動処理のエスカレーション対応をJIRAチケット化するフローも作りましたね。後から集計しやすくして、エンジニアのエスカレーション対応工数を可視化できました。」

okaeri
「たしかにそれもやりましたね!エンジニア工数だけでなく、CSとしてもエンジニアへのエスカレーション内容やボリュームを可視化できたので、管理や依頼がしやすくなりました。」

しっかりと成果を出せたのがWin

okaeri
「実際やってみてどのくらいの削減などの結果が出たんですか?」

takanamito
「先述の機能提供後、ogaさんと一緒に計測して定量結果をエンジニアリング本部に提出しました。CSのSLO(初回返信時間や問題解決時間)に大きな改善が見られた結果と、その中でエンジニアが実際に寄与した部分を明確にしてレポートしました。」

(レポート資料を見せる)

okaeri
「すごい改善成果が出てますね!」

oga
「特に退会機能のリリースによる成果がやばいですね(一同うなづく)!以前は、なんらかの事情でユーザーが自身で退会できない場合、CSから社内連携のワークフローを通じてエンジニアに依頼し、処理が完了するまで結構時間がかかってましたが、CSだけで完結できるようになってから、その事象における問題解決時間は97.3%短縮できました!ログ調査も同様に23.1%の短縮につながり、単純にエスカレーション件数を減らすことによってエンジニア工数を削減するだけでなく、問い合わせ対応時間(CSのKPIの一部)の短縮にも大きなインパクトを与えました。1〜2ヶ月でこのような成果が出せたのは本当によかったです。」

今後やりたいことは、CSが自走して改善を回すことと運営自律性を高めること

takanamito
「今回僕が意識したことは二つあって、一つ目は今後最終的にはCSが自走して今回のような改善のサイクルを回せるようになること。なので、一緒にエンジニアリング視点で伴走はしたけど、基本的にはogaさんに任せるようにしてました。二つ目は成果を数値で全社に共有すること。今回も良い結果が出て定性だけではなく、定量的に全社に共有できたことは狙い通りでした。」

okaeri
「お二人の取り組み自体は一旦前期で終了したかと思うのですが、今後やりたいことはありますか?」

takanamito
「会社が今期フォーカスしている運営自律性(運用コストの低減や、セルフサポートによるパートナーの意思決定の迅速化など)の改善は、今後やっていきたいですね!要は、10X側が手を動かさなくても、パートナー(ネットスーパー事業者)が自分自身でやりたいことをStailer上でできるようにするということ。これをCSと協力してやっていきたい。問い合わせがたくさんくる操作は本来機能化されていなければいけないものなのに、現状はそうなってはいななくて、問い合わせないと実現できないことがたくさんあるので、今後また棚卸してCSと議論していきたいです。」

oga
「実はCSでも同様の課題を持っていて話してました。会社の方針ともマッチするので、パートナーの運営自律性の改善にフォーカスを当てたいと思います。今は10X側がやっているログ調査などもパートナーに提供している管理画面上でできるようにするなど、できることはたくさんありそうですよね。今後一緒にやっていければいいなと思ってます!」

takanamito
「今後定期的に棚卸しや振り返り、情報交換の時間を設定しているのでやっていきましょう!」


インタビュー②(プロダクトマネージャー×CS)

次に、プロダクトマネージャー:aineとCS:okaeriが普段の業務でどのようにコミュニケーションをとり、連携しているのかを振り返ります。

  • インタビュアー:oga

  • インタビュイー:aine、okaeri

開発関連エスカレーションの社内連携ワークフローの改善


oga

「まず最初に、PdMとCSは普段どのようなコミュニケーションや連携をしていますか?」

okaeri
「主に二つあって、一つ目はCSに来た問い合わせでプロダクト側の調査やシステム改修が必要な案件に関しては、社内連携のワークフローを使って依頼を行うのですが、それらをどのように進めていくかをPdMと一緒に決めています。二つ目は、新しい機能やバグフィックスがリリースされる際に、リリース共有会というPdMとCSの共有の場を設けてSyncしています。」

oga
「前者のワークフローに関して、現在は少し違う形になってますが、以前はaineさんがリードでCSにヒアリングしながらワークフロー改善に取り組まれていましたよね?あの時(前期)はどのような課題があってやっていたんですか?」

aine
「前期の初めにドメインベースの開発体制に移行したこともあって、それまでのやり方では弊害が出るという課題感がありました。以前はその日のエスカレーション担当エンジニアに直接相談して、その人がその先の進め方を差配していたのですが、エンジニア1人で解決できない場合にはSlack上で別の詳しそうなエンジニアに独断でメンションしてアサインしていたので優先度や進行管理の煩雑さが課題でした。それをJIRAチケット化してチームにアサインするフローにしました。要は、ドメインベースの体制に合わせたということと、管理をしやすくしたということです。」

oga
「普段のCSオペレーションで一番多くのワークフロー依頼を出しているokaeriさんは、このような改善に対してどう思っていますか?」

okaeri
「このフローでうまく回っていると思ってます。CSとしても以前のフローだとCSメンバーそれぞれが該当の案件のSlackのスレッドを読み込まないと情報のキャッチアップができなかったので、とにかく把握コストがかかっていました。それがJIRAのチケットで管理できるようになったので、内容やアサイン、進捗の確認が誰でもスムーズにおこなえるようになりました。また、ドメインベースのチーム体制になったことによって、発生事象に対してアサイン先の定義が明確になったので、依頼時も判断コストが下がりました。アサインしたドメインチームのPdMが適切に進行してくれるのもありがたいなと思います。またボードで依頼案件が一覧で可視化されるのもとても助かってます。」

リリース共有会と試食会

oga
「情報とコミュニケーションが集約されて、両者にとっていい取り組みでしたね!また、先ほどの話の後者のリリース共有会に関して、CSにとっていいことはありますか?」

okaeri
「リリース共有会があることによって、機能開発をマネジメントしているそれぞれの担当PdMから事前にもれなく詳細なリリース情報をインプットできるのは助かっています。CSでは毎週、その週にリリースされる機能を実際に開発環境を触って事前にCS内でメンバー全員で仕様をキャッチアップする試食会(スーパーにちなんで)という場を設けているのですが、リリース共有会はその解像度を上げてくれるので、いいサイクルが回っていると思っています。」

oga
「aineさんとしては、以前はサクセスオペレーションチームがリードしていたリリース共有会をPdMが引き継いでリードすることによるメリットなどを感じていますか?もちろんサクセスオペレーションチームがリードしていたフェーズもCSは大変助かっていました!」

aine
「リリースされる機能について、リリースノートに載せるべきか、どのようにわかりやすく記載するかなど、一次情報を自身で持っているPdMがオーナーシップを持って自ら関係者に一気通貫で説明できるようになり、それがDBにストックされる仕組み自体はよかったと思います。以前はリリースノートを書く担当者がPdMではなく、その担当者がGithubの差分を確認して仕様をキャッチアップしたりJIRAや仕様書を一から読み込む必要があり、情報流通の面で課題がありました。それが解消したという意味ではいい改善だったのかなと。」

リリース情報を管理しているDB。リリース共有会で使用。

仕様書のアップデート運用のCS移管

oga
「ここで少し話は変わりますが、現在、仕様書のメンテナンスをCSが行う運用にシフトさせていますが、全社的に仕様書を有効活用しようとメンテナンスする中でPdMとしてどのようにCSとコミュニケーションしていますか?」

aine
「CSがお問い合わせベースで仕様書をアップデートしてそれをPdMに報告や確認依頼をする形で連携してくれています。以前は、リリース後もPdMが責任を持って更新し続ける運用でしたが、機能改修によって若干挙動が変わったりする中で、それを仕様書に落とし込み続けるのはPdMだと大変な作業だった。お問い合わせから発覚することも多いので、CSがこの運用を担当してくれることはありがたいです。」

okaeri
「私がこの運用をリードしているのですが、CSに任せてくれているのは役割分担として適切だったと思います。以前はCSが実際の機能・挙動とドキュメンの内容に差分を発見した際は、パートナーが使用するガイド・FAQはCSが更新し、仕様書はPdMに更新依頼をかけていましたが、それを一気通貫してCSが全てのドキュメントのナレッジ管理をできるようになりとても効率的になりました。」

今後やりたいことは、運営自律性の改善にCSが貢献していくこと

oga
「最後に、今後もしPdMとCSが協力することによって今までより良くなることがあれば、今考えている範囲で教えてもらえますか?」

aine
「最近良かったと思うことが二つあります。一つ目は、CSがマスターデータのインポートを実行できるようになったこと。二つ目は、パートナーからマスターデータの問題に関するお問い合わせをいただいた際に、CSで原因を特定して解決できるようになっていること。それがとてもいいなと思っているので、そのようなことを今後増やしていってもらいたいです。そうなると、現在、プロダクトがフォーカスしている運営自律性の改善にCSが貢献してくれるんじゃないかなと思っています。CSの中で仕様ノウハウが蓄積してくるとそれが資産となって、パートナー向けにナレッジとして共有できたり、機能に落とし込む提案ができるようになるので、個人的には期待しています。」

okaeri
「いい話ですね!現在、CSでも(不具合などを除いた仕様調査やログ調査などの)開発関連のエスカレーション率を下げようという取り組みを行っていて、そこにつながってくると思います。CSで蓄積したナレッジはガイドやFAQにどんどん書き起こして、CSで活用するだけではなく、パートナーでも解決できるようにしています。」

oga
「CSの開発関連エスカレーション率を削減する取り組みには、全社フォーカスの運営自律性の改善をまずは社内でCSが体現していくというテーマを持っています。先述の通り、CSの中での仕様の解像度が上がり運営自律性が高まることによって、それを機能としてパートナー展開できる可能性が出てくると思っています。まさにPdMとCSの思いがつながっていいお話でした!」


まとめ

  • CSとSWEで、定期的に開発関連エスカレーション案件を棚卸し、機能化するなどの改善サイクルを回している

  • CSとPdMで、通常のお問い合わせ業務の連携フローの改善に取り組んだり、リリース共有を仕組み化して密に行っている

  • CSも仕様書のメンテナンス運用リードを通じて、プロダクト仕様の解像度を高めている

  • 今後は、プロダクトサイドと共に全社フォーカスの「運営自律性の改善」にCSも貢献していく

終わりに

最後まで読んでいただきありがとうございます🙌いかがでしたでしょうか?
10XのCSではサポート機能もプロダクト・顧客体験の一部と考えていて、日々どうCS観点からプロダクトにインパクトを与えるかを試行錯誤しながらプロダクトサイドと連携を図っています。来年もさらにインパクトを出せるように仕込み中です🔥

明日、🎄10X プロダクトアドベントカレンダー2023の20日目は、品質管理部QAエンジニアの@tarappoさんの記事が公開予定です。お楽しみに👏

そして、皆さま、よい年末年始を👋🎄🎍

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