エンジニア観点での「問い合わせ対応」の業務効率化

この記事は食べログアドベントカレンダー2024 の2日目の記事です🎅🎄

【はじめに】

初めまして。こんにちは。食べログ開発本部ウェブ開発1部のスギマルくんです。「システム運用改善チーム」というチームに所属し、食べログのシステムや運用面の改善に関連した業務をしています。

本日は、エンジニア観点での「問い合わせ対応」の業務効率化にまつわる取り組みを紹介します。まだ道半ばの活動ではありますが、皆様の業務効率化の参考になれば嬉しいです。エンジニア以外の職種の方にも当てはまる話なので、ぜひお読みください。

【食べログへの問い合わせ】

ご存知の通り、食べログは月間利用者数が9000万人を超えるサービスです。

多くの方に使っていただいているサービスですが、当然ながらユーザーさまからの問い合わせも存在します。エンジニアも、カスタマーサポートチーム（ユーザーさまからの問い合わせを受ける部署）を経由し、以下のような問い合わせを受けることがあります。

「PCとアプリで、表示される店舗情報が異なるのはなぜか？」

「アプリで口コミを投稿する際、画像がアップロードできないので、直してほしい」

「特定のブラウザでログインできない」

こちらは一例で、問い合わせの種類は多岐に渡ります。食べログのエンジニアは、これらの問い合わせに、適切なスピードで正確にお答えする責務を負っています。

【これまでの問い合わせ対応】

しかしながら、これまで食べログのエンジニアの問い合わせ対応には以下の課題があり、本来は1日でクローズできる問い合わせが数日に伸びてしまうことが多々ありました。

①悪気のないたらい回し

食べログは巨大なサービスで、ログイン機能、口コミ投稿、日記投稿、有料会員サービスなど、数多くの機能が存在します。また、実装から10年以上手が加えられていない画面もあり、誰も詳細を知らない機能もなくはありません。これらの事情が相まって、問い合わせ対応では、「たらい回し」が発生してしまいます。

例えば、問い合わせの窓口担当のメンバーが、「この機能について問い合わせが来てるんですが、Aさんに対応お願いできますか？」と問いかけると、こんな具合に...。

Aさん「この機能は知らないなあ。Bさんの方が詳しいはず」

Bさん「いや、私はこの機能、いじったことありません。コードを見たら、Cさんが数年前にいじってました」

Cさん「この機能、いじった気はするんですが、記憶が曖昧です。今、重要案件のリリース前なので、Dさんお願いできますか？」

Dさん「は、はい...（俺も忙しいのに...）」

ここで強調しておきたいのは、「誰も悪気はない」ということです。AさんやBさんは「もっと詳しい人に聞いた方が確実な答えを返せる」という親切心から、そのような対応をしているのでしょうし、Cさんにしても、実装から時間が経っているので、覚えていなくても仕方ありません。ただ、問い合わせの調査担当者が決まるまでに数時間かかってしまうことは問題ですし、結果的に担当することになった人は「押し付けられた感」を抱えたまま対応することになりかねません。

②問い合せからの脱線

カカクコムには「ユーザー本位」の考えが浸透しており、多くのエンジニアも「どうしたらユーザーに満足してもらえるか」を考えています。しかしながら、問い合わせ対応では、それが仇になることもあります。

例えばカスタマーサポートから、「ユーザーから特定のブラウザでA画面が表示できないと連絡が入っている。原因を教えてほしい。原因が分かり次第、ユーザーに回答します」という問い合わせがあったとします。それに対し、A画面の担当エンジニアはソースコードを解析したり、過去の仕様書を確認して、原因を探し出します。

ここで陥りがちなのが

「特定のブラウザでA画面で表示できない原因がわかった！改修しよう！」

という心持ちになり、カスタマーサポートに声をかけることなく、改修の準備や実際のコード修正を始めてしまうことです。

しかし、このケースにおいて、カスタマーサポートがシステムの改修を求めているとは限りません。

「現在、週明けの改修リリースに向けて担当者をアサインし、実装しているところです！」

とカスタマーサポートの方に回答したところ、

「ひとまず原因だけ分かれば大丈夫です」

といった返答をいただく可能性も大いにあります。このケースの場合、エンジニアが改修よりも先に原因を報告していれば、カスタマーサポートによるユーザーへの回答も、もっと早く実施できましたかもしれません。

【問い合わせ対応改善のために始めたこと】

本来、別の開発を予定していたメンバーが問い合わせ対応に必要以上の時間を使ってしまうと、過度な高稼動や、業務の遅延にも繋がってしまいます。そんな問題を解決すべく、今年度より、「問い合わせ対応の効率化」を目指す取り組みがエンジニアの部内で始まりました。

①悪気のないたらい回しの改善策

問い合わせのたらい回し改善のために着手した点は、「問い合わせ窓口担当者の業務範囲の広域化」です。

これまでも問い合わせ窓口担当者はいましたが、主な役割は、該当の問い合わせに詳しそうなチームやメンバーに、なるべく早く取り次ぐことがメインでした。もちろん、詳しそうなチームや人に速攻で見てもらうことで、問い合わせの早期クローズに繋がったことも多々ありますが、それによって、たらい回しが発生してしまったのも事実です。

そこで今期より、問い合わせの窓口担当者を入社数年経ったメンバーである私（＋私の所属するチームのメンバー）に固定し、「まずは窓口担当者が問い合わせをしっかり読み込む」という運用を取り入れました。その上で、窓口担当者のみで問い合わせに対する調査や回答が可能な場合は責任を持って調査を受け持ち、それが難しい場合はソースコードや仕様書に目を通すなどして担当者を明確にしてから、他のメンバーにお願いする業務フローを構築しました。また、担当チームが複数に跨る場合、窓口担当者が調査チームの牽引役となって会議を設定したり、クローズに向けた道筋を立てる役割を担うこととなりました。

もちろん、毎回、スムーズに事が運ぶわけではありません。しかしながら、徐々に改善の兆しは見え始めており、たらい回しは減ってきているように感じています。