この記事はGYOMUハック/業務ハック Advent Calendar 2018の9日目の記事です。昨日は、honki4029さんの実践業務ハックです！
どうも、10月から社内唯一の業務改善担当になったキンチキです。
今回は業務改善の仕事をしていてデータ周りで感じたことを書きます。
- はじめに
- データと改善の流れ
- なぜデータが必要か
- まずはデータを可視化する
- 改善ポイントの発見・改善のための施策考案・効果予測
- 施策の取り組み・リリース
- 効果測定
- 新たなデータから次の改善ポイントを見つける
- おわりに
はじめに
この記事はデータを元にした話がメインで、業務改善系の話でよくある「現場が超大事」的な話ではないです。それを記事に書けるほど理解も実感もまだあまりできていないっていうダメダメな感じです。ダメダメですが、データも大事だよってことを伝えられると嬉しいです。
この記事はなんだか偉そうになっちゃった気がしますが、私がやったことは上司から指示を受けたりアドバイスをもらったことがほとんどで、それを元に私なりに解釈をして書いています。
データと改善の流れ
私が考えるデータを元にした業務改善の流れです。データに関しても業務改善に関しても圧倒的に経験とスキル不足なので、間違っている可能性は大いにあります。
- データを可視化する
- データから改善ポイントを見つける
- データから改善の施策案を考える
- データから改善の効果予測を立てる
- 施策の取り組み・リリース
- データから施策の効果を測定する
- 新たなデータから次の改善ポイントを見つける
- 以上繰り返し
なぜデータが必要か
私が業務改善担当として最初に行ったことは、CS業務の改善でした。具体的には、自社サービスの問い合わせフォームを変更して、ユーザーがヘルプページを見て自己解決しやすくしました。これにより問い合わせ数を減らし、CSチームの業務時間を削減することができます。
初めに課題や業務内容を知るために、CSチームの方々にヒアリングしたり業務を見せてもらったりします。
そこで私が「具体的に○○にはどれくらい時間がかかっているのか」というありふれた質問をすると、以下のような回答が返ってきました。
「わからない」
「測っていない」
「問い合わせ内容によって違いすぎる」
まあ予想通りの回答といえばそうなのですが、私の成果指標は業務の削減時間が主だったため、これだと成果が出るかわかりません。成果が出ないことをやっても仕方ありません。
この施策に取り組んでいた時期の半ばまで、当社のCSチームは経験豊富なメンバーが一人もおらず、改善していくような人も当時はいませんでした。そのため、CSは改善による効果が大きいと私もCSチームも感じていました。
しかし、実際にCSチームが体感から改善に取り組むべき（だから協力してほしい）と思っていても、今の工数がわからなければ、取り組んだ結果の効果の見込みが立てられず、業務メンバー以外が改善を行っていくという意思決定はしづらいです。
ということで、データを可視化してどこに時間がかかっていてどこを改善すれば効果があるか出すところから始めました。
まずはデータを可視化する
当社の問い合わせフォームや問い合わせの返信など、CS業務の多くはZendeskで運用しています。まずはZendeskのデータをGoogle Analytics（以後GA）で見られるようにしました。GAのトラッキングIDは登録されていましたが、誰も存在を知らなかったため新しくアカウントを作りました。。。
これでセッションや離脱率などWebページのデータは取れるようになります。
次は実際の問い合わせ件数です。こちらはZendeskのインサイトというBIツールのような機能で出せます。CSチームでこの機能を使っている人はおらず、そもそも存在を知っている人が一人いただけという状態でした。そのため使い方を聞く相手は誰もいない（そもそもZendeskの使い方をみなさんよく知らなかった）です。
しかし、そこはエンジニアなので、自分でいろいろ試したりひたすらZendeskのヘルプを見たり、時にはZendeskに問い合わせたりして1週間も使っていればほしいデータを出せるようになりました。
そしてたった一週間でなぜか社内で一番Zendeskに詳しくなっており、「Zendeskのことならキンチキ」という良いのか悪いのかわからない状態になりました笑
改善ポイントの発見・改善のための施策考案・効果予測
あとはそのデータからかかっている時間や改善ポイント、施策の案、その施策の効果予測を出していきます。ここは部署やその時々で大きく変わるでしょうから細かいことは書きません。
工数が大きな業務、改善ができそうな業務、改善コストが低い業務、効果が大きな業務などなどから考えます。
施策の取り組み・リリース
施策案ができたら、上長やCSチームに提案し、GOサインが出たら実際に取り組み始めます。
今回私がやったことは問い合わせフォームの変更です。具体的な変更内容はここでは省きますが、割とプログラミング（JS）を使った変更です。本当はZendeskのGUI部分だけで行いたかった変更ですが、どうしてもできなかったためコードを書きました。
CSチームの協力を得つつ施策に必要なことをすべて行い、変更をリリースしました。
効果測定
そして、その施策で効果が出たか確認するために、データを見ます。当然メンバーの声も聞きますが、すぐ効果が体感できなかったり特定のメンバーしかわからなかったり改善ポイントがわからなかったりしますので、やはりデータを見ることは重要です。
ユーザーの自己解決を促して問い合わせを減らすことが目的の施策だったので、主に以下のデータを確認して効果を測定をしました。
- 問い合わせ件数
- CVR（問い合わせ件数 / ヘルプページのセッション）
- 問い合わせに対するCSからの返信数（ユーザーとのやり取りの回数）
- ヘルプページ訪問から問い合わせ、返信を何回したかなどの転換率
効果を測定した結果、施策の効果が効果が大きかったことがわかりました。問い合わせ件数は季節や3連休などに影響するためそこだけ見てもわからないのですが、CVRが大きく下がっており、平均返信数や転換率も下がっていました。
開始からリリースまでに時間がかかっていたため、効果が出ていないことが怖くて測定することは怖かったですが、効果が出ていて心底ホッとしました笑
ここだけの話、最初は怖すぎて効果をしっかり測定できずにいたら、上司から効果について聞かれたときにそれがバレて怒られました。効果があったにしろ無かったにしろ、その結果がわからないとどうしようもないのですが、、、ビジネスマンとして大変お恥ずかしい話です。。。
新たなデータから次の改善ポイントを見つける
今回の施策によって、問い合わせ内容の分類の細分化とそのデータを出すことができ、どの問い合わせが多いのか≒どの問い合わせがユーザーが自己解決できていない割合が大きいかがわかるようになりました。
ここから、じゃあなにをより見ないといけないか、どの分類を優先して改善すべきなのか、ヘルプページの内容が少ないのではないか、、、といった考察ができ、次に改善すべきポイントが見えてきます。
データを出す、データから改善する、改善後のデータからさらに改善する、、、といった良いループを回していくことができます。
これを書いていて思いましたが、これはPDCAって言えるのですかね？ 恥ずかしながら、PDCAはあまり意識していないので自信ないです。
ちなみに、D(DO)に関してはこの記事ではあまり触れていないのですが、Dが最も大事だと思っています。
おわりに
データを元にした業務改善の流れ、いかがでしたでしょうか？
このやり方が正しいかどうかは知りませんが、少なくとも言えることは、現場の担当者が言っていることや感じていることが正しいとは限らないということです。なんとなくの数字、なんとなくの感覚の可能性があります。そして、データを使えばその「なんとなく」を数字で出すことができ（る可能性があり）ます。
なんか「現場の人を信じるな」という論調に捉えかねない気がしてきましたが、そんなことは全く思っておらず、「データも必要に応じて見ましょうね」ってことです。
データを現状を出し、予測を出し、効果を出し、意思決定を支えてくれるものです。データドリブンにできるものはそうしていきたいです。
ちなみに、業務改善担当になってから2ヶ月と少ししか経っていませんが、おそらく業務改善担当からもうすぐ別チームに移動します。その理由は主に成果が出せるかどうか（私のスキルと成長スピードとメンタリティの問題）の話で、今のままよりチームで仕事した方が成果が出そうだからとかそんな感じです。
その話はまた別の機会で。
ではまた。
