Recruit Tech Blog
ユーザーの”困った”と徹底的に向き合った問い合わせ削減物語
はじめに
はじめまして、石丸と申します。
2022年2月にリクルートに入社し、人事の業務BPR支援や、社内のICTツールのお問い合わせ分析・削減活動に従事しています（人事の業務BPRについて興味があればこちらも見てみてくださいね）。
今回は、ICTのサポートに寄せられる問い合わせの分析効率化、ユーザーの生の声と徹底的に向き合い、問い合わせを年間50%削減した話を紹介します。
よろしくお願いします！
こんな方にはおすすめかも！
・お問い合わせ分析に忙殺されている方
・FAQは充実しているのに、マニュアルだってちゃんと用意しているのにお問い合わせが絶えず流れてくる…とお悩みのカスタマーサポート、サービス管理者の方
本編
リクルート全社業務を支える社内ICTの利用者総数は約4.5万人です。
リクルートでは社内ICTについて月間2500〜3000件、年間総数で約4万件のお問い合わせが発生していました。
毎日120人以上が本来悩まなくて良いことに悩み、業務生産性を低下させている状況です。こんな状況を打破すべく、我々が取り組んだことをお話します。
LLMを使った問い合わせデータ分析の効率化！
リクルートの社内問い合わせは有人チャットで受け付けています。しかし、そのやり取りのチャットログは1件あたり数百文字となるので、一つひとつを丁寧に見ることはできません（年間4万件ですからね…）。このため、問い合わせを削減しようにも、ユーザーが何に困っているのかを把握するには相当骨の折れる状況でした。
そこで、お問い合わせ内容をLLMを使って要約した結果を出力するようにしました。
問い合わせ内容を「事象」「理由」「対応」の3つの視点で要約してもらいます。
これにより、数百文字のチャットログが、たったの3行見るだけで概況が分かるようになりました。以下はその要約例です。
事象：OneDriveのリンクをクリックすると404 FILE NOT FOUNDエラーが表示された
理由：リンク先が存在しないため、アクセスができなかった
対応：他のメンバーからリンクを送り直してもらい、問題解決
こうした取り組みにより、問い合わせ分析が効率的に実施できるようになったため、分析回数を増やすことが可能になり、より多くの打ち手が実施できるようになりました。
結局は泥臭くデータを読んで「どうして困ったの？」を知る必要がある
前章で、「要約データを作って問い合わせ分析が簡単にしたよ！」というお話をしてきました。しかし、これはそんなお話を覆すタイトルですね…。
もちろん、要約を見るだけでも、「FAQを修正」「マニュアルを修正」といった打ち手がすぐに浮かび、実践できるものも多々あります。
しかし、「FAQ、マニュアルは読まれているのに、どうして問い合わせが来るのだろう」といった問いはやはり発生してしまいます。
この「真因」を掴むには、「ユーザーはどうして困ったのだろうか」を知る必要があります。ユーザーは問い合わせに至った原因をチャット上で言語化することはありません。問題が解決さえすればそれで良いわけですから。このため、「真因」を知り、「困った」の発生を断ち切るためには、我々がチャットログ上からユーザーが「困った」に至るまでの行動を読み取り、原因を推測し、手を打つ必要があります。
行動を読み取るにあたって大切なことは、自分がユーザーと同じ立場だったらその状況をどう捉えるか、どうなっていると幸せか、ということを考えることです。
上記観点を持ちながら、FAQやマニュアルを読んだ上で問い合わせてくるユーザーのチャットログを読み解き、特に躓いているポイントを洗い出しました。その結果、躓きポイントには2つの特徴があることが分かりました。
1.該当箇所を読み飛ばしている
2.読んで実践しても解決しない
項番2については、「そもそも困らない仕立てにできないか考えよう」にて言及しますので、まずは項番1についてお話をします。
マニュアルやFAQはとにかく簡単に！
なんで読み飛ばすの！？とユーザーにムッとした経験、ユーザーサポートを担当されている方であれば、一度はあるのではないでしょうか。マニュアルが読み飛ばされる原因は大別して3通りです。それぞれ陥りがちな原因を記載します。
-
1.文字量が多い
-
2.記載が難しい
-
3.マニュアル構造がわかりにくい
（１）文字量が多い
当社に限らず一般的なこととして、マニュアル作成の際、サービス提供側の免責のための記載が、文字量を増やすことに繋がりがちです。
（例）人によっては〜の場合があります…等。
もちろん、多くのユーザーに関係することの記載は必要です。しかし、少数の人に向けた記載があると、これに当てはまらない多くの人にとっては不要な情報になります。こうした情報が多く記載されていると、ユーザーは肝心な記載を読み飛ばしてしまいます。一度に入る情報量は少ないに越したことはありません。少数の人の問い合わせはあえて受け、多くの人が楽になる選択を取る勇気を持ち、免責・例外的な記載は削ることを推奨します。
また、冗長な表現も避けることが重要です。なるべく短い文章で言いたいことを伝えることで、ユーザー側の読む労力を削減しましょう。
（２）記載が難しい
部署内や、その道に詳しい人にしか分からない用語を用いないことが重要です。理解できない言葉が並んでいると、それだけでユーザーはマニュアルを読む気を無くしてしまいます。誰が読んでも何のことを言っているのかの理解が同じになる言葉を用いることが大切です。
（３）マニュアル構造がわかりにくい
1つのマニュアルから、別ページや、異なるマニュアルに遷移する構造を取っていると、マニュアル各項の前後のつながりが途切れ、ユーザーは迷子になります。その結果、作業順序や対応を誤り、問い合わせに至ります。
マニュアルはなるべく一本道にし、上から順に淡々と遂行していけば目的を達成できるという構造にしておくことが大切です。
「読み飛ばす」というユーザー行動一つとっても、その背景は様々であることがイメージいただけたのではないでしょうか。読み飛ばすのはユーザーが悪い！と言えばそれまでなのですが、こちらがそれを主張できるまで情報量を減らしているか、わかりやすくしているかは、今一度見直しても良いかもしれません。
そもそも困らない仕立てにできないか考えよう
ここまでは、FAQやマニュアルに情報を記載することを前提にお話を進めてきました。
しかし、「FAQやマニュアルを見る必要がない」状況こそが一番良いと言えるのではないしょうか。なぜなら、その状況ではユーザーは何も困っていないと言えるからです。
たとえば、パスワード忘れがよく発生するシステムなら、「パスワードを忘れたときは」といった趣旨のFAQを用意しておけば問い合わせは発生しません。しかし、そのシステムがパスワード以外（生体認証等）で認証するようにすれば、「パスワードを忘れたときは」といった趣旨のFAQ自体が要らなくなりますよね（＝パスワード忘れに困ることがない）
とはいえ、FAQやマニュアルは必要になることでしょう。マニュアル通りやってもうまくいかない、という作業がある場合、
・その作業がなくせないか
・なくせないならこの作業をもっと簡単にできないか
といった視点で、「困った」の原因の除去を目指します。
問い合わせ分析の中で出た上記のような視点のアイデアをサービス管理者に提案し、実現までこぎつけることで多くの問い合わせ削減につなげることができました。FAQやマニュアル修正と比較して根本の原因が除去されるので、問い合わせ削減効果も絶大です。
また、サービス自体の改善につながるため、実際にユーザーからも「大変楽になりました」など、喜びのお声をいただくこともありました。
サービスの仕立てを変えることは簡単ではありませんが、FAQやマニュアルでの対処にとらわれず、そもそも困らないためにできることはないか、ということを視野に入れてみることも大切です。
最後に
ここで語ったもの、外したもの含め大小様々な取り組みの積み重ねにより、2023年度比で約50%の問い合わせ削減を実現しました。しかし、リクルートにはまだまだ「困った」がありますし、サービスや環境の変化と共に新しい「困った」が生まれ続けます。こうした「困った」を解決することで約4.5万人の社内ユーザーの生産性の向上に寄与するので、やりがいたっぷりです！！
次のチャレンジとして、「まだ形になっていないナレッジの自動収集の仕組み化」と、更にその先の「問い合わせ対応の自動化」を目指しております。
ここまで読んで少しでも新しい発見や、リクルートの取り組みに興味を持っていただけましたら幸いです！
このブログを読んでピンと来た方は、ぜひ一度採用サイトもご覧いただけるとうれしいです。まずはカジュアル面談から、という方も大歓迎です。
また、他にも色々な記事を投稿していきます！
過去の記事もご興味あれば、ぜひ他の記事もあわせてご参照ください。
・Recruit Tech Blog
・リクルート ICT統括室 Advent Calendar 2024
・リクルート ICT統括室 Advent Calendar 2023