こんにちは、ホスティング事業部でCREをやっているmochikoです。
5月に公開された「minne CREを紹介します」と6月に公開された「SUZURI CRE 1年目のふりかえりとこれから」につづいて7月はホスティング事業部からCREに関する話題をお届けします。 ホスティング事業部のCR（Customer Reliability）チームは2020年1月に発足したチームで、エンジニア以外もメンバーにいることからCRチームとして活動しています。 今回の記事では、おもにお問い合わせのデータ可視化と活用について試行錯誤して得られた知見をシェアしたいと思います。
ホスティング事業部CRチームとは
ホスティング事業部CRチーム（以下CRチーム）では現在、おもにユーザーからのお問い合わせに基づき調査・改善を行ったり、お問い合わせ対応に関連する業務効率改善のためのツールを作ったりしています。
チーム発足当初から考えていたこと
他チームからお問い合わせの対応業務を引き継いだということもあり、最初はとにかく目の前の対応に追われていたのですが、もともとCRチーム発足時のキックオフミーティングの中で お問い合わせ内容と対応結果をデータとしてためて活用したい という話をしていました。 お問い合わせの内容をデータとして蓄積して、たとえば下記のようなことができるのではないかと考えていたのです。
- VoCの分析に使えないか？
- お問い合わせの傾向が分かれば改善要望の優先度づけができるかもしれない
- お問い合わせ件数などをアラートとして検知できないか？
- 最近○○○のお問い合わせが多く感じる、で検知するより迅速に原因究明ができるかもしれない
- お問い合わせ対応業務の効率アップに使えないか？
- もっとも効果がある改善ポイントに注力することができるかもしれない
ということで、チーム発足から半年ほど経過した2020年の8月にデータ活用のための取り組みをはじめました。
そこから手探りでお問い合わせの概要を地道にデータベース化＆可視化した結果、2021年7月現在も改善の途中ではありますが、お問い合わせ内容の傾向から次に着手すべき改善ポイントについての議論ができるような状態になっています。
私たちがお問い合わせ内容の傾向分析を少しずつ改善していった経緯をご紹介することで、どなたかのお役に立てれば幸いです。
お問い合わせデータ活用の道のり
CRチームでどのような試行錯誤を続けてきたのか、各段階でのモチベーションとそこで取り組んできた内容をご紹介します。
(1) どのお問い合わせの対応に時間がかかっているかを知りたい
最初の頃はとにかくお問い合わせの対応そのものに追われている状態だったので、改善に着手する時間が確保できないというジレンマがありました。そこでまずはどの対応に時間がかかってるかを知り、業務効率改善を進めようという話になりました。 対応時間はきっちり正確でなくてもいいし、とにかくスモールスタートでいいからやってみないと始まらないということで、スプレッドシートに対応内容と対応時間を愚直にメモしていくところから始まりました。
最初のフェーズで行ったことは下記の通りです。
- スプレッドシートを使ってとにかくまずはデータを貯めることを始めてみた
- スプレッドシート上でチーム全員がお問い合わせ内容と対応結果を俯瞰で見れるようにした
これによって、件数では目立たないけど時間がかかっているお問い合わせや、逆に件数は多いけどすぐに解決できるお問い合わせなどの傾向をつかむことができました。 業務効率改善のためのツールを自分たちで用意して、対応時間の短縮を実現することができました。
(2) もっとお問い合わせの内容にフォーカスして可視化したい
まずはデータをとってみる、というアプローチのおかげでより多くの時間を割いている業務の効率化を進めることができました。 しかし対応内容を個人でサマライズして記載していたこともあり、これは内容や原因を分類するためのデータとしては機能しませんでした。 特定の事象に対して何件のお問い合わせがあったかを知るためには、スプレッドシート上で期間を絞ってタイトルや対応内容から検索して、それをカウントして確認している状態です。 理想としては現在の状態を視覚的に見れるダッシュボードのような形にしたいので、そのためにまずはスプレッドシートに貯めているデータを集計に適した状態に整形する必要がありました。
CRチームはユーザーからのお問い合わせに基づいて調査を開始するのですが、私たちが直接ユーザーとやりとりするのではなく、CSチームからのエスカレーションという形で調査や対応の依頼を受けています。 このとき、エスカレーションされた時点ではあくまで「ユーザーから見える事象」について言及されており、実際に調査してみると異なる事象に見える2つのお問い合わせの原因が同じであった、などということが起こりえます。 ユーザーの申告内容をもとにそれぞれのお問い合わせの概要をサマライズしていましたが、それではパターンが多すぎて集計に活用できるデータにはならないという問題がありました。
ユーザーはどういう内容でサポートに連絡してきていて、どこのサーバーで何が起こっていて、どのような対処をしたのか、というような形でお問い合わせの内容にそってデータを取得したいという目的があり、そのためにどうすればいいのかをチームで議論しました。
結果として、ある1つのお問い合わせに対して複数の軸に分類した上で、それぞれの分類の中でラベリングをしていくことになりました。 これによって複数の切り口でお問い合わせを捉えることができるようになります。
サーバーの種別、事象、原因などのいくつかの軸に分類して、それぞれの分類の中でラベルをつけたのが下図のような状態です。
データの形を修正したことで、集計と可視化に使えるデータになりました。グラフの作成はGoogle Data Portalを使いました。 これでダッシュボードとしてデータをいつでも視覚的に確認することができるようになりました。
2段階目のフェーズで行ったことは下記の通りです。
- テキストでサマリーを入力していたがデータとして活用できないので各分類の中でラベルを選択する方式にした
- ラベルはできるだけ細分化して、ラベルを組み合わせることで詳細なデータが取れるようにした
- スプレッドシートのデータをGoogle Data Portalで読みこんでグラフとして可視化するようにした
(3) 使わない計測結果を整理する
ラベルを細分化してデータを集めた結果、さまざまな切り口でお問い合わせの傾向を可視化できるようになりました。 しかし3ヵ月ほど運用してみた結果、一度も使っていないラベルがあったり、ラベリングしても件数が少ないため集計結果上でノイズになったりするものがあることに気づきました。 ここであらためて、チームメンバーで「なんのためにデータを可視化するのか」を議論しました。現在Google Data Portalで読み込んでいるデータは、そもそもどのような目的のために集めているのか、という原点に立ち返った形です。
分類を始めた当初は「できるかぎり詳細にすべてを把握できるように」ということで細かく分類したのですが、もともとすべてを把握するためにデータを集めていたわけではなく、傾向を掴むためにデータを集めていたのでした。 チーム内での議論の結果、発生頻度が低いものについては計測できたところで活用していないので不要である、という結論に達しました。 そこで、詳細な分類のために用意していた多くのラベルをある程度まとめたり、逆に「その他」のようなラベルによってブラックボックス化しすぎないよう適切な粒度で抽象化したラベルを用意したり、という調整を行いました。
この時点で、すでにCRチームのメンバー全員がお問い合わせ対応を随分やってきていたので、ある程度「どのラベルがよく使われて、どのラベルが使われていない」というような認識にずれがなくスムーズに議論ができました。 「データとして可視化されていないけど、なんとなくこういう傾向があるなぁ」というような共通認識がある場合は、このあたりの粒度の調整は最初からうまくやれるのかもしれません。 今回はチーム発足時点のなにも知見がない状態から現状を把握するためにデータを貯めていく、という試みだったのでここまでの歩みは割と遠回りになっていると思います。
また、このタイミングでUIが使いやすいNotionのデータベース上でラベリングをして、それをスプレッドシートに取り込むという仕様に変えました。 Notionのデータベースには柔軟なフィルター機能とそれを使ったビューの切り替え機能があります。これにより任意のラベルの組み合わせでフィルタリングしたお問い合わせの一覧を瞬時に閲覧できるようになり、またラベルの色分けもできるので視認性もあがりました。
下の画像はNotionでビューに設定しているものの一例です。
3段階目のフェーズで行ったことは下記の通りです。
- ラベルの粒度を見直して、細かすぎるところと大雑把すぎるところを調整した
- Notionをつかうことで、一覧のリストでもより柔軟なフィルタリングとビューを活用できるようにした
以上のように着手してからおよそ1年弱で、3つの段階をへてCRチームではお問い合わせのデータを蓄積して活用するという流れを作ってきました。
現在のデータ活用状況
現在のCRチームにおいて、データそのものやデータをもとに可視化されたグラフや表をどのように活用しているかをご紹介します。
(1) とにかく毎日ながめる、週次ミーティングで活用する
毎朝Slackにお問い合わせ状況のダッシュボードのグラフが流れるようにしており、全員がお問い合わせの状況について視覚的に把握できるようになっています。 週次のチームミーティングでは、分類データをもとに先週のお問い合わせで気になったものや、今後注視したいものなどを共有するようにしています。
また、お問い合わせの件数ベースで先週と比較して有意な差が見られる場合は、サーバー側の何かしらの変更が影響を与えている可能性がないかをインフラチームに確認しています。 逆にサーバー側で変更があった際に「○○○に関連するお問い合わせを注視しておいてほしい」というような依頼をインフラチームからうけることもあり、その場合は一定期間お問い合わせの状況を確認しながら適宜フィードバックしたりもします。
(2) 定量的な結果からタスクの優先度を判断する
お問い合わせの件数や対応時間をもとにして、どのタスクを優先すべきかなどの意思決定にデータを活用しています。 また、ユーザーへの影響がより大きいと考えられる箇所から優先的に改善したり、業務効率改善の効果測定にも活用します。
とはいえ、現在集めているデータがCRチームへのエスカレーションという限定的なものであるため意思決定の根拠として完全ではなく、今後はより広いスコープで優先度判断ができるようデータの見直しを続ける必要があると思っています。
(3) 課題発見に使う
たとえばメール関連のお問い合わせが恒常的に多かったとしたら、それの原因について掘り下げてみる、ということをやっています。 メール関連のお問い合わせのうち、さらに特定のラベルのお問い合わせが多いのはなぜか、それを減らすにはなにをすればよいのか、という視点で考えます。
今後も必要に応じてラベルをさらに細分化したり統合したりして調整しながら、適切な粒度で抽象化してお問い合わせの内容が可視化できるようにしていきたいと考えています。
お問い合わせ傾向の可視化をやってきて
CRチームでは、以上のような流れで「使えるデータ作り」をしながら一歩ずつ改善を進めてきました。 3つの段階まで1年弱かかったのですが、振り返ってみると実際はもっと早いタイミングで改善できたのではないかなと思っています。
実際にCRチームとしてデータ活用の試行錯誤をやってきて、反省点と良かった点を振り返っておこうと思います。
反省点
- 可視化されたら嬉しくなってしまい、そこで立ち止まってしまった
- 他の業務と並行してやっていることもあり、可視化＝ゴールとなってしまう
- データを使ってどう意思決定するのかが重要で、きれいなグラフになったところで満足してはいけない
- 可視化した結果どういうことがわかるはずである、という仮説を持って進める必要がある
- データの取得方法やデータとして扱う項目は定期的に見直しが必要だった
- 「可視化された先」の視点を持っていなかったため使いづらいデータをズルズルと取り続けていた
- そもそも見直しが必要であるという観点を持っていなかった
良かった点
- 最初は何をデータとして貯めたらよいかが不明なので全部取ってみるというアプローチは必要だった
- ある程度傾向が把握できたら欲しい結果から逆算してデータを再設計するという形でブラッシュアップできた
- ラベルを見直す際にチームの共通認識があってスムーズだった
- お問い合わせの対応の知見がチームにたまっていたので、適切な粒度でラベルを抽象化したり具体化したりすることができた
これらの試行錯誤を経て、チームで動くときにはまずデータでの現状把握から始まり、取り組むタスクをデータをもとに決め、効果測定もデータで行う、という一連の流れが習慣になったのは大きな収穫です。 タスクに着手するときに、効果測定のためのデータを取る方法から議論が始まるのが、現在のCRチームの強みの1つです。 Customer Reliability（顧客信頼性）という計測しにくい指標を相手にしているからこそ、計測できるところはしっかり計測してデータを使って意思決定していきたいと思っています。
データ活用の今後
振り返りのところでも少し触れましたが、現在は「お問い合わせ傾向の可視化」と言いつつCRチームへのエスカレーションに関する可視化にとどまっている状況ですので、さらなる改善が必要です。具体的には、もう少し広いスコープでデータを収集するべきであると考えています。 たとえばCSチームで取得しているデータと組み合わせて、すべてのお問い合わせについていろいろな切り口で可視化してみるとか、サーバーのメトリクスのデータとお問い合わせのデータを組み合わせてみるとか、そういうことができるといいのではないか、という形で試行錯誤を始めようとしています。
CRチームは、より速く確実にユーザーの困り事や不安を解決する糸口が見つけられるよう、これからも改善を続けていきます。 まずデータを取ってみる、というところから始まったお問い合わせ状況の可視化ですが、今後も戦略的にデータを活用していけるようにやっていきたいです！