SmartHR入社3年目の挑戦-データドリブンな改善提案-
こんにちは😊
SmartHRのカスタマーサポートとして働いている、tsubuです。
2024年3月末をもって、SmartHRに入社して丸3年が経過しました。この1年間はあまりnoteの執筆ができずにいたのですが、4年目突入の節目になったので、この機会にまた1年の振り返り記事を書いてみようと思います。
現職に入社してからの振り返り記事をいくつか貼っておくので、よかったら合わせてご覧ください。
今回取り上げるトピックは、この1年間（特に後半の半年間くらい）で注力したポイントでもある"データドリブン"についてです。
これまでのサポート職での就業経験の中では、これほどお問合せの「データ
」と真正面から向き合ったことがなかったかもしれません。そんな未経験の立場から挑戦した内容について綴っていきますので、日々お問合せ対応をしながら、プロダクト改善に繋げる役割を担っている方にお読みいただけたら嬉しいです。拙い部分も多々あるかと思いますが、あたたかい目で見てください🤲笑
問い合わせ件数はリリース当初の約2.5倍に…
まずは、今回なぜ「データ」をもとにした改善提案を検討したかについて簡単に記載します。
わたしがプロダクトエキスパートとして担当している「人事評価機能」では、2023年下期（7月〜12月）の6ヶ月間でおよそ1,800件のお問い合わせをいただいておりました。プロダクトがリリースされてから、順調に導入企業数が増えている背景もあり、年間のお問い合わせ件数はリリース当初の約2.5倍、昨対比では100件近く増加している状況です。
お問合せが入り始めた当初はまだ件数も少なく、1つ1つの内容とじっくり向き合いながらプロダクトの改善ポイントを確認していましたが、細かな内容までドキュメントにまとめる作業に徐々に限界を感じるようになりました。また、週次のドキュメントではどうしても断片的な情報になってしまい、「同じ問い合わせがどれくらい来ているのか」を掴みにくい点も課題でした。
代わりに、データの数としては十分な母数が確保できる状態になったので、昨年下期からは1件1件の詳細な問い合わせ内容よりもお問い合せ件数を武器として、開発チームと向き合う方向にシフトチェンジすることにしました。
データの蓄積と分類から見えたこと
わたしはまず、お問合せのデータをGoogleスプレッドシート上でカテゴライズすることから始めました。
具体的には、週単位でお問合せのリンク・大/小カテゴリ・タイプ・お問い合わせの概要を記載し、分類していきました。その中で、同じ要因でお問い合わせをいただくケースが見えてきたので、それらには別途フラグを立てて件数をカウントしていきました。
半年間のデータが溜まったところで分析してみたところ、評価を開始する際にエラーとなってしまい、エラー内容を読んでもどんな操作をしたら良いかわからずお問い合わせにつながるケースが17件ありました。
これは、評価者・評価共有者の設定に関するお問合せのうち約10%を占めることがわかり、（要望を除く）よくある問い合わせのうち一番多いものでした。この結果をもとに、開発チームに機能改善の相談を持ちかけることにしました。
改善提案、そして実装へ…！
現在、人事評価機能の開発チームのPM / PdEチーフと共に、隔週でMTGを実施しています。ここでは、お問い合わせ削減のための相談などを持ち込むことができます。
上述の分析結果とともに「なぜお問い合わせにつながるのか」を考えた上で、「問い合わせをしなくてもユーザーさま側で解決できる手段」としてエラー文言の改善提案をしました。
それをもとにPM / PdEを中心に検討していただき、先月ついにリリースに至りました🎉
もちろん、このリリースが終着点ではなく、今後はお問い合せ件数の変化も追っていかなければならないので、引き続き着目しながら分析を進めているところです👀
問い合わせに潜む声に耳を傾け、小さくはじめる
サポートの職種は、あくまでもお問い合わせをもとに、PMやPdEが機能改善の優先順位をつけるための"判断材料（＝ユーザーさまの声）"を提供する役割だと思っています。新規機能の開発や、もっと優先すべき機能改善などのロードマップは、事業戦略や競合との兼ね合いなどを考慮して検討・決定されているからです。
ただ、今回わたしが持ち込んだ改善提案は、以下の2点がこれまでと異なっていたと思います。
お問い合わせ件数（データ）をもとにした事実であること
開発工数が最小限で済むよう、なるべく小さく着手できるポイントに絞ること
1つ目についてはここまでで書いてきた通り、データを可視化することで、自分の主観や肌感ではなく「事実としてこうだった」ということを、開発メンバーに知ってもらう必要があったと感じていました。特に今回のエラーメッセージの改善については、ユーザーさまから「こうして欲しい」といった明確なご要望をいただいていたわけではなく、お問い合わせの後ろに潜んでいる「使いづらさ」を解消するための改善だったと思います。こうした声なき声をデータとして可視化し改善に繋げていけるのは、プロダクトエキスパートとしての仕事のやりがいでもあると感じます。
2つ目の「小さく着手」については、開発チームの実装工数を考慮することはもちろん、小さな改善でどれだけ大きなバリューをもたらすことができるかを意識しました。提案時点では「仮説」の状態ですが、これまでの傾向を踏まえた仮説を立てることで、分度器の角度が大きくなるようにじわじわと効果が出始め、後で振り返ったときに影響が大きかったと言える提案が大事だと思いました。
おわりに
ここまで"わたし自身が取り組んだこと"という観点で書いてきましたが、もちろんこれは自分一人で成し遂げられたことではありません。
日々問い合わせと向き合い対応をしてくれているチャットサポートのみんなや、問い合わせ削減の必要性を理解し、ユーザーさまのつまづきポイントを真摯に受け止めてくれるPM、実際に実装してくれるPdEたち、ヘルプページや文言の改善検討をしてくれるUXWとともに仕事に取り組めるからこそ、ここまでやりがいを持ってやってこれたなと感じます😌
今後は一層「マルチプロダクト化」を見越したサポートや、広い視野でプロダクト改善のタネを見つけていくことも求められるフェーズにあるので、わたしもプロダクトと共に成長していきたいです💪
この記事を読んで「一緒にやってみたい！」と感じた方はぜひ、カジュアル面談からでもお話しできればと思います🙌
この記事が気に入ったらサポートをしてみませんか？