【企業連携】問い合わせ対応の業務効率を改善するためには？

ケース
2025-03-25
パートナー情報 関彰商事株式会社
研究者情報 丸田敦貴・滝波俊平・朱明睿・高橋慧・崔涵喬・高木祐介（株式会社自動処理）

取り組みの概要

背景と課題

本記事は，2024年度のMDAトップ人材養成特別演習において，関彰商事株式会社様とパートナーを組み，課題解決に取り組んだ際の報告記事である．

関彰商事株式会社は，勤怠管理システムを運用しており，システム導入から導入後のサポートまでのサービスを展開している．その中でも，システム導入後のサポートとして，システム利用者から操作方法や設定といった様々な問い合わせに対応する業務が行われている．

我々はシステム導入後サポートの問い合わせ業務に着目し，この業務の効率化に取り組んだ．

問い合わせ業務についてヒアリングを行った結果，ベテラン社員への業務集中が起きていることが明らかになった．

図1. 現在の問い合わせ業務の体制．

図1に現在の問い合わせ業務の体制を図示した．これは，システムに関するエラーや操作方法などの問い合わせメールが受信されてから，回答を送信するまでの流れである．

ベテランでない社員はエラーの原因の調査や修正の考案の際に，ベテラン社員に相談することによって解決している．一方で，ベテラン社員は他の社員の補助やシステムの導入業務に取り組みながら，自らに割り当てられたメールの返信をしている．

我々は本演習において，この課題の解決に取り組むことを決定した．

目的

図2. 本演習の目的．

図2は本演習の目的を図示している．本演習の目的は勤怠システムの問い合わせ対応の業務効率を改善することである．そのために，提案システムを導入し，これまでにベテランに相談していた部分をシステムに置き換えることを目指す．

事前分析

我々は提案システムを考案するにあたり，問い合わせ業務について深く理解する必要があると考え，過去の問い合わせデータの分析と現地調査によって，問い合わせ業務について理解を深めた．

過去の問い合わせデータの分析

どんな問い合わせが来るのか？

最初に，どんな問い合わせが来るのかを明らかにするために，直近1000件のメールデータを人手で分類した．人手で行ったのは，各学生が問い合わせを実際に読むことで，問い合わせ業務を理解することができると考えたためである．

表1に問い合わせの分類法を示す．この分類法は階層的な構造になっており，上層に質問の分類，下層に回答の分類がある．我々は質問を4つに分類(操作方法の質問，システム変更の要望，エラーについての質問，システム以外の質問)し，それぞれの質問に対して，回答を1つまたは2つに分類した．

図3. 各分類カテゴリのメール件数が全体に占める割合．

図3に各分類カテゴリのメール件数が全体に占める割合を示す．質問の分類に着目すると，操作方法の質問は25%，システム変更の要望は34%，エラーについての質問は29%を占めることが明らかになった．

いつ問い合わせが来るのか？

次に，過去5年間の問い合わせデータに対して，問い合わせが来るタイミングについて分析を行った．

図4. 年毎の問い合わせ件数．具体的な数値は非公開．

図4は年毎の問い合わせ件数を図示している．この図を見るに，年々問い合わせ件数が増えていることがわかる．ここから，今後さらに問い合わせ業務の圧迫が進むことが考えられ，業務効率改善の必要性が高まることが示唆される．

図5. 月毎の問い合わせ件数．具体的な数値は非公開．

図5は月毎の問い合わせ件数を図示したものである．この図から3月や4月に問い合わせが増えていることが見てとれる．これは，年度が新しくなることによって，人事の変更が起こり，勤怠システムを変更する機会が増えることが要因となり，勤怠システムのエラーや操作方法についての相談が増えたためだと考えられる．ここから，年度が新しくなる期間には対応人数を増やすなどの対応が必要だと考えられる．

現地調査

図6. 現地調査での写真．

次に我々は現地調査を行い，詳細な問い合わせ対応のフローや問い合わせの各工程にかかる時間を調査した（図6）．

問い合わせ対応のフロー
図7. 問い合わせ対応の詳細なフロー．

図7に現地調査で明らかになった問い合わせ対応のフローを図示する．過去の問い合わせの分析に基づき，質問の種類毎に対応工程をヒアリングした．その結果，質問によって回答に必要な工程数が異なり，工程数の多さが回答の難しさにつながっていることが明らかになった．

  • 操作方法の質問に対して，問い合わせ対応の知識（自身の経験，過去の対応事例，ベテラン社員の知識）にアクセスすることで，対応することができる．この質問に対してはベテランではない社員も簡単に対応することができる．
  • システム変更の要望に対しては，問い合わせ対応の知識にアクセスし，対応の方針を決めた後，勤怠項目の計算式を確認または変更を行うことで，対応することができる．
  • エラーについての質問では，問い合わせ対応の知識にアクセスし，対応の方針を決めた後，お客さんのデータを見て，状況を把握し，勤怠項目の計算式を確認または変更を行うことで，対応することができる．この質問に対しては，ベテラン社員でないと対応することが難しい．

ヒアリングによって，システム変更の要望やエラーについての質問はアクセスする情報源が多く，対応が難しいことが明らかになった．

問い合わせの工程にかかる体感時間
図8. メール返信の各工程にかかる時間の割合．

図8はメール返信の各工程にかかる時間の割合を図示している．まず，計算式を考える時間が全体の53%を占めていることが明らかになった．ここから，計算式の考案が問い合わせ対応業務において最も苦労する工程であり，この工程の時間を削減することが業務効率の改善に大きく寄与することが示唆される．

次に大きな割合を占めていたのが，他のメンバーへの質問であり，全体の15%を占めていた．ここから，他のメンバーへの相談時間も削減することも業務効率の改善に寄与することが示唆される．

事前分析の結果

過去の問い合わせの分析と現地調査によって，以下の知見を得た．

  • 問い合わせにはいくつかの種類があり，種類によって対応工程数が異なる．
  • 問い合わせ対応の際，過去の対応事例を参考にすることがある．
  • 計算式の考案に時間がかかる．

提案システム

事前分析を踏まえて，過去の対応事例に簡単にアクセスできるようになれば，ベテランに相談せずとも問い合わせ対応できるようになり，​サポートデスク対応に要する時間を減らすことができるのではないかと考えた．そこで，​我々は過去の問い合わせの対応事例検索システムを提案した．

図9. 提案システムのスクリーンショット．

図9は提案システムのスクリーンショットであり，我々は2つの検索機能を作成した．まず問い合わせの内容をそのまま入力し，関連する過去事例を検索するベクトル検索機能，そして，問い合わせの内容に応じて検索結果を絞り込むカテゴリ検索機能である．

想定する利用方法としては，問い合わせ（メール）が来たときに，メール本文をコピーし，そのまま検索ボックスにペーストすることで対応事例を検索する．そして，検索結果から関連する事例を参照しながら回答文を作成する流れを想定している．

ベクトル検索機能

ベクトル検索機能は文章の意味の類似度で検索する機能であり，問い合わせの文章をそのまま入力しても，意味的に類似したメールを検索することができる．

この機能を作成した理由は，ヒアリングの際に，利用しているメールアプリの検索機能は単語が厳密に一致していないと検索することができない，という声があり，ベクトル検索であれば，単語が一致していなくても，意味的に近いメールを検索することが可能だと考えたためである．

カテゴリ検索機能

我々はさらに，カテゴリでのフィルタリング検索機能を追加することによって，ユーザ自身による検索結果の詳細な絞り込みを可能にした．

この機能を作成した理由は，ベクトル検索は柔軟な検索を可能にする一方で，どのようなクエリを入力したら，どのような結果が返ってくるか不明瞭な部分があり，ユーザによる制御が難しいと考えたためである．そこで，カテゴリ検索機能を追加することで，ユーザ自身が検索結果を制御しやすくし，より目的に合った情報にアクセスできるようになると考えた．これにより，ユーザが必要な情報を効率良く見つけるだけでなく，検索の挙動を直感的に理解できるようになることを目指した．

我々は以下の手順でカテゴリ機能を実装した．

  1. 問い合わせ対応で使われる専門用語354単語を基に，階層的な分類法(大カテゴリ・小カテゴリ・単語)を作成する
  2. 専門用語が出現したメールにカテゴリを割り当てる

実装の詳細

図10. 実装の詳細．

図10に実装の詳細を図示する．新着メールおよびカテゴリ分類済みの対応履歴は日本語埋め込みモデルRuri-small1を用いて，ベクトルに変換し，検索ライブラリElastic Search2に格納する．そして，Elastic Searchを用いて，ユーザが入力したメールと意味的に類似する過去の対応履歴を検索し，さらに，カテゴリ検索による検索結果の絞り込みを実装した．また，ユーザインタフェースにはStreamlit3を用いた．

システム導入

導入スケジュールと評価方法

導入スケジュール

2024年11月15日から11月27日までの平日10日間，ベクトル検索機能のみを提供した．この期間では，ベクトル検索の利便性が問い合わせ業務の効率化にどの程度寄与するかを評価した．

2024年11月28日から12月10日までの平日9日間，ベクトル検索機能に加えてカテゴリ検索機能を提供した．この段階では，両機能を併用することによる効率化と検索性能の向上を検証した．

評価方法

業務負担感の改善について

  • 主観的なメール返信の負担
    • 問い合わせ対応者にアンケートを実施し，システム導入前後で各工程（問い合わせ内容確認，計算式の考案，設定，回答文作成，他のメンバーへの質問）の業務負担の変化を5段階の尺度（大幅に負担が減った，少し負担が減った，負担は変わらない，少し負担が増えた，大幅に負担が増えた）で回答してもらった．
  • 体感時間の変化
    • アンケートにより，メール返信の各工程にかかる主観的な所要時間を回答してもらった．

システムの評価について

  • システム利用率
    • 問い合わせに対して，システムがどの程度利用されたかを計測した．
  • 検索有効性
    • システムが適切な過去事例を検索できているか，回答の正確性を検証した．検索するごとに利用者から検索した情報の有用性を4段階の尺度(問題なく使えた，加工すれば使えた，参考にはなるが使えない，ほぼ使えない)で回答してもらった．

新人が1人でもメールを書けるかを検証

  • システムを利用することで，新人社員がベテラン社員の助けを借りずに問い合わせに対応できるかを検証した．業務に慣れていない新人社員に実際に頼むことは困難であったため，今回は学生が新人社員としてシステムを使ってメールを作成し，ベテラン社員に評価してもらった．メール返信の難易度を４段階（簡単：すぐに回答できる，普通：設定を見れば回答できる，少し難しい：計算式の確認が必要，難しい：ベテラン社員に聞かないと回答できない）に分け，それぞれの難易度のメールを用意してもらい，学生が書いた返信メールを0~4点（0点：全く使えない，1点：部分的に返信に使える情報がある，2点：内容を少し足せば送信できる，3点：少し表現を変更すれば送信できる，4点：そのまま送信できる）で評価してもらった．

導入結果

導入1回目　ベクトル検索機能のみの結果

主観の業務負担の変化について

図11. アンケートによる導入1回目の各工程の負担の変化．

図11はアンケートによる導入1回目の各工程の負担の変化についての調査結果である．この図から，回答文の作成，設定，計算式の考案において，「少し負担が増えた」と感じていたユーザが多いことが見てとれる．

図12. 導入1回目の各工程の体感時間．

図12はアンケートによる導入1回目の各工程の体感時間の調査結果である．計算式の考案で体感時間が減っているものの，合計時間では体感時間が増えてしまっていることが明らかになった．

ここから，システムの利用によって反対に負担が増えてしまったり，対応に時間がかかるように感じさせてしまったことが明らかになった．

システムの評価について

図13. 導入1回目のシステム利用率．

図13は導入1回目の問い合わせに関するシステムの利用率を図示している．導入1回目の期間中，26.5%の問い合わせに対してこのシステムが利用されたことが明らかになった．また，導入1回目の後半期間はシステムの利用が見られなかった．この結果に関して，対応が簡単な問い合わせに対しては過去の事例を検索せずとも返信することができるため，簡単な問い合わせが多く来た可能性や，システムの使いづらさから利用率が低い可能性が示唆される．

図14. 導入1回目の検索有効性の評価．

図14は導入2回目の検索有効性の評価結果である．この図を見るに，約80%の検索が問い合わせ対応にほぼ使えない情報を返していたことが明らかになった．

さらに，ユーザから以下のようなフィードバックを得た．

  • 遅刻に関する過去のデータを確認したかったが、遅刻ではなく早退に関する問い合わせで出力されてしまい、遅刻に関しては出てきませんでした。
  • 有休付与に関する問い合わせが5ページ出力された。時間有休に関する回答を求めていた。

ここから，システムの検索性能が低く，ユーザが欲しい情報を検索できないことで，利用率が下がっていることが示唆される．

導入2回目　ベクトル検索機能+カテゴリ検索機能の結果

主観の業務負担の変化について

図15. 導入2回目の各工程の負担の変化．

図15は導入2回目の各工程の負担の変化についての調査結果である．この図を見るに，1回目の導入結果と比べて「負担が減った」と回答された項目が増えていることが見てとれる．

図16. 導入2回目の各工程の体感時間．

図16は導入2回目の各工程の体感時間についての調査結果である．導入前と比べて，合計時間がわずかに減少していることが明らかになった．

これらの結果から，導入1回目と比べて，ユーザの主観的な負担が軽減されていることが明らかになった．

システムの評価について

図17. 導入2回目のシステム利用率．

図17は導入2回目のシステム利用率を図示している．導入2回目では，53.6%の問い合わせに対して，システムが利用されていたことが明らかになった．これは，カテゴリ検索機能の追加によってシステムの操作性が向上したためだと考えられる．

図18. 導入2回目の検索有効性の評価．

図18は導入2回目の検索有効性の評価結果である．導入2回目では，66.7%の検索結果が，回答の参考になる情報を含んでいたことが明らかになった．これはカテゴリ検索機能の追加によって，1回目の導入に比べて検索有効性が高まったと考えられる．

さらにユーザからのフィードバックを以下に示す．

  • 過去に対応した同様の内容が検索結果として出ました。実際に返信の作成に加工して使える部分がありました。
  • 回答の参考になるような問い合わせが検索できた。

以上の結果から，カテゴリ検索機能の追加によって，ユーザ自身で検索結果を絞り込めるようになったことが，ユーザの検索のしやすさに繋がり，検索有効性や利用率が高まったことが示唆される．

新人が1人でもメールを書けるかを検証

図19. 新人のメール回答の評価結果．

図19は提案システムを用いた新人のメール回答の評価結果を図示している．この図から，難易度が簡単（すぐに回答できる），普通（設定を見れば回答できる）のメールに対して，約2点（内容を少し足せば送信できる）の回答が可能であることが見てとれる．一方で，少し難しい（計算式の確認が必要），難しい（ベテラン社員に聞かないと回答できない）メールに対しては，回答が困難であることが明らかになった．

ここから，システムの利用によって，全く業務を知らなくても，部分的にメールの返信内容を書くことが可能であることが示唆される．

今後の方針

今後の方針として，検索機能の追加とユーザビリティの改善が必要であると考えている．

検索機能の追加

  • 勤怠システムの計算式を検索できるようにすること
    • 「新人が1人でもメールを書けるかを検証」において，計算式を見る必要がある問い合わせに対しては全く返信できないことが明らかになった．そのため，このシステムから計算式にアクセスできるようになれば，「少し難しい」メールの返信も可能になると考えられる．
  • ベクトル検索だけでなく，キーワードの厳密一致での検索も可能にすること
    • ユーザのフィードバックの中で，特定の単語が入っている対応事例を検索することができない，という声が上がっており，最新のベクトル検索を採用したことによって，既存の単語の厳密一致検索の必要性が明らかになった．そこで，ベクトル検索の結果と単語の厳密一致の検索の結果を結合させたハイブリッド検索手法を採用するなどの手段が考えられる．

ユーザビリティの改善

  • メールを入力してから，検索結果が返ってくるまでの時間を短縮すること
    • 今回作成したシステムでは，検索から結果が返ってくるまでに2秒ほどかかってしまっていた．これは，UIにStreamlitを採用したことが原因であると考えれられる．そのため，UIの実装に他のライブラリを利用することが効果的だと考えられる．
  • ページ遷移を可能にすること
    • Streamlitの仕様上，Webページの遷移の実装が困難であるため，JavaScriptやPHPを用いてWebページを作成するといった手段が考えられる

まとめ

本演習では，関彰商事株式会社様とパートナーを組み，勤怠システムにおける問い合わせ対応の業務効率の改善に取り組んだ．

過去の問い合わせデータの分析と現地調査によって問い合わせ業務について理解を深め，これらの調査を踏まえて過去の問い合わせの対応事例検索システムを提案，実装，導入した．

導入の結果，1回目ではシステムの検索性能が低く，ユーザが欲しい情報を検索できないことが明らかになったが，2回目では，システムの利用による業務負担の軽減や利用率および検索有効性の向上が確認された．

今後，計算式の検索機能やキーワード検索機能の追加や，ユーザビリティの向上により，さらなる業務効率の改善が見られるだろう．

後記

図20. 関彰商事様と学生の集合写真．

本演習で学んだこと

  • 数字で人を説得することの重要性​
    • システムの導入が何%の業務効率の改善につながるのか，そして，その改善が何円の原価削減につながるのか，これらの問いにきちんと答えられるような提案にするべきだ，ということをメンターの高木様からご指導いただきました．
    • 最初はあまりイメージがつきませんでしたが，議論やヒアリングの中で数値を測ることを意識していき，最終発表で金銭的な効果の概算を発表したところ，とても良い評価を受けて，数字で効果を表すことの重要性を実感することができました．
  • 秘匿性のあるデータを使う際の制限が大きい​こと
    • 今回はメールデータという大変貴重なデータを扱わせていただきました．個人情報の部分はマスクされていたものの，社内ルールによりメールデータを扱う際にChatGPTのような最先端の外部AIを使うことが困難でした．代わりに小型の言語モデルを使ってみましたが，求める精度に届きませんでした．ここから，機密情報を扱うことの難しさを学びました．
  • ヒアリングにおける心理的な安全性が重要であること
    • オンラインとオフラインではコミニュケーションの質が全く異なると感じました．オフラインの方がよりリラックスして話していただけるように感じました．さらに，自分たちが現地に赴いた時がさらによく話していただけたことから，円滑なコミュニケーションのための機会を自分たちが作っていくことの重要性を学びました．
  • 業務の効率化を測るための客観的なデータを取得することの難しさ
    • 今回は施策全体の評価をする際に，主観的な負担と体感時間を使いましたが，もっと客観的な指標（問い合わせの返信にかかる時間など）を計測すればよかったと思いました．
  • システムの実装に多くの工程と相手企業とのコミュニケーションが必要であること
  • 様々な専門分野のメンバーが所属するチームにおいて，自らが貢献できそうなポイントを考え，実行する重要性
  • ローカルLarge Language Model (LLM)の実装コストの大きさ
    • はじめはローカルLLMを使って業務の一部自動化ができたらいいなという動機も参加した理由の一つでした.
    • ただ、実装に着手してみると大変なことが多く、今回は実装を見送りました。
    • ローカルLLMを使う際は以下のようなことを考慮することと、プロジェクトでグループ全体で演習全体にわたって取り組むくらいの労力が必要なことを意識してほしいです.
      • ローカルLLMにさせるタスクを明確に定義できているか.
      • 実装する時の計算機環境は整っているか. (8Bや13B程度だと工夫が相当必要になってきます)
      • プロンプト間の比較
      • 複数モデル間の比較
      • ファインチューニング

苦労した点

  • 毎回のミーティング
    • 企業の方や先生方がいらっしゃる中で，議論の方針を決めていく必要があり，慣れない状況での意思決定に苦労しました．
    • 最初は何が良いのかが自分の中でわかっていない状態で不安な時期が続きましたが，自分の中で答えを決めていくことで，少しずつスムーズに議論することができるようになってきました．
  • いくつかの意思決定での紆余曲折
    1. 最初の課題の設定
      • 我々は最初勤怠時間とWell beingの関係性を分析することを目的としていました．しかし，この分析から課題の解決（Well beingの向上）に繋げることは困難と判断し，方向性を修正しました．
    2. 次の課題の設定
      • 次に設定した課題が，勤怠システム導入業務の効率化です．そのために，我々は「仕事の割り振りに必要な情報を提示するシステム」や「システム導入効率化のためのチャットボットシステム」などを提案したが，導入業務に関するデータの少なさやお客さんにシステムを使ってもらうことのリスクなどから方向を転換しました．
    3. 提案システムの考案
      • 検索システムの提案の前に，いくつかのボツになった提案がありました．「メールを入力すると事前に決められたテンプレートが返されるシステム」，「メールの内容を入力すると返信メールの本文が生成されるシステム」などがありましたが，前者はテンプレートのみでは網羅的な対応が困難であることから却下され，後者は外部AIの利用制限から却下されました．
  1. https://huggingface.co/cl-nagoya/ruri-small ↩︎
  2. https://www.elastic.co/jp/elasticsearch ↩︎
  3. https://streamlit.io/ ↩︎