blog

DeNAのエンジニアが考えていることや、担当しているサービスについて情報発信しています

2024.09.10 技術記事

ヘルプデスクの即レス化を支える技術と運用

by Kunitate Katagiri

#zendesk #looker #情シス

この記事について

DeNAでは2023年の中頃にそれまで外部委託を中心に運営していた社内ITのヘルプデスク機能を内製化しました。 以降は社内をよく知るメンバを中心にヘルプデスクの運営を行っています。 伴っていくつかの従業員体験向上の施策を実施しましたが、その中でも2024年4月から実施している「即レス」化の施策について紹介します。 「即レス」化というのはそのままの意味で、営業時間内(10:00-18:00)の間であれば、何らかの意味のある返事をすぐにするというのを運用として維持するというものです。

グループのこと

IT本部IT戦略部エンプロイーエクスペリエンスグループの片桐です。 現在、主に社内ITヘルプデスクとPC端末管理・トラブル対応を行っています。

エンプロイーエクスペリエンスグループですが、ユーザーサポートグループを前身としており、2023/4に名称変更され発足したグループです(社内の従業員体験向上のためのグループです。主にやっていることは社内ITヘルプデスクとPC端末管理です)。 2022年以前は業務委託での協力者さんと連携して社内ITヘルプデスクとPC端末管理を運営するグループでしたが、2023/6からは正社員のみで運営するグループとなりました。

前提

DeNAのIT本部ではミッションとして「QCDの鼎立(ていりつ)」を掲げており、IT戦略部では社内ITについて「高いクオリティ」、「低コスト」、「より早いデリバリー」を最適なバランスで提供すべく日々活動しています。 エンプロイーエクスペリエンスグループでも同様に日々、クオリティ向上、コスト削減、デリバリー迅速化を高いバランスで提供できるよう取り組んでいます。

社内ITヘルプデスクについて言えば、最適な回答(Quality)、利用ツールコストや工数削減(Cost)、対応の迅速化(Delivery)を高次元で実現することがミッションとなります。今回は特にこの対応の迅速化(Delivery)について、ヘルプデスクにおけるWebチケット対応のステータス変更履歴を元にパフォーマンスを可視化する仕組みを作り、結果PDCAが回せるようになり運用改善が進んでいる話を紹介します。

ヘルプデスクにおけるKPIと分析ツール

ヘルプデスクの主な業務は、Webチケット対応と窓口対応です。 2024年7月現在、DeNAヘルプデスクはZendeskを導入し、社内問い合わせの受付窓口を開設しています。

ヘルプデスクのWeb窓口(Zendesk画面)

ヘルプデスクのWeb窓口(Zendesk画面)

どのような業務であっても、効率と成果を正確に把握するため、日々の活動を数値やグラフで表現したいという需要はあると思います。 これは指標さえはっきりと決めてしまえば技術的に難しいことではありませんが、作業記録のルール決めとその運用の定着、その上での記録を定期的に取得し時系列で保存する仕組みがセットで必要となり、そこまで考えると意外と難しいものです。

DeNAのヘルプデスクでも効率と成果を正確に把握するために、明確なKPI(重要業績評価指標)を設定し、これまで業務改善の活動をやってきました。1 Zendeskは「重要な指標の分析データを一元的に追跡、管理する機能」を持っているツールです。しかし、DeNAではこの仕組みとは別の内製の分析ツールを用意し、それらを活用してデータドリブンな運営をしています。

IT本部IT戦略部にはシステム開発グループという主に社内システムの内製開発を行っているグループがあります。 こちらのグループに、ZendeskのWebチケットの対応ステータスの遷移ログを定期的に取得し、BigQueryに保存してもらっています。 保存されたデータはヘルプデスク用に提供されたLooker Studioにより見ることができます。これによりヘルプデスクは具体的な分析データに基づいた改善活動を行うことができます。

KPIとしての「ユーザー待ち時間」と「問い合わせ解決時間」

現在、ヘルプデスクでは特にWebチケットの対応ステータスの遷移ログを元に計算された「ユーザー待ち時間」と「問い合わせ解決時間」を指標としてバリューの向上に努めています。下記画像は2022年Zendesk導入以降のDeNAヘルプデスクにおける「ユーザー待ち時間(オープンステータス)」のLookerグラフです。

ヘルプデスクパフォーマンスを示すグラフ

ヘルプデスクパフォーマンスを示すグラフ

基本的には「ユーザー待ち時間」減少の方向に推移していることが分かりますね。 特に内製化により社内をよく知るメンバでの担当をするようになったこと、早いサイクルでの改善活動ができるようになったことは待ち時間減の大きな要因の1つです。では「ユーザー待ち時間」と「問い合わせ解決時間」とは何なのでしょうか?それを説明します。

ヘルプデスクで利用しているZendeskのチケットステータス管理について

まず前提としてヘルプデスクにおけるWebチケット(Zendesk)のステータス種類と遷移について説明しなければいけません。 既に述べたように、DeNAのヘルプデスクではWebチケット対応のためにZendeskを使っています。 なので、チケットステータスの管理もZendeskのものに準ずるもの(下記5種類)がベースとなります。2

  • 新規
    • 起票された際の最初のステータス
  • オープン
    • 特定のエージェント(ヘルプデスク)に割り当てられたステータス
  • 保留中
    • チケットがまだ解決されておらず、さらに作業を進めるためにリクエスタからの情報を待っているステータス
  • 待機中
    • リクエスタ以外のユーザー(たとえば、上司や社内の開発者やシステム管理者)からの情報またはアクションを待機しているステータス(ユーザーからはオープンに見える)
  • 解決済み

DeNAヘルプデスクにおけるチケットライフサイクルの状態遷移は下記図のようになります。 言葉の使い方にブレがありますが、依頼者=リクエスタ=ユーザーは同じ対象と理解いただけますようお願いします。 これらのステータスを下記図のように状況に応じて切り替えて、受け付けた相談や依頼を解決まで導きます。

ヘルプデスクチケットのステータス遷移

ヘルプデスクチケットのステータス遷移

最初にリクエスタはチケットを起票し、その後ヘルプデスクボールかリクエスタボールかをお互い打ち返しながら状態遷移し、最終的に解決に向かう流れです。

「ユーザー待ち時間」と「問い合わせ解決時間」とは?

改めて「ユーザー待ち時間」と「問い合わせ解決時間」の取り決めについて説明します。 DeNAヘルプデスクではそれぞれについて下記のように決めてKPIとしています。

  • 「ユーザー待ち時間」:チケット担当の努力次第で早くなりうるユーザーを待たせている時間
  • 「問い合わせ解決時間」:純粋なチケット起票からチケット解決までの時間

先に記載した、「ヘルプデスクチケットのステータス遷移図」のうち、ヘルプデスクでリクエスタの返答時間をコントロールすることは困難ですので、ヘルプデスク側の努力で改善可能な下記赤い矢印の時間を合算し、「ユーザー待ち時間」として指標としています。とはいえ、リクエスタ側の対応待ち時間も含めたチケットライフサイクル全体の「問い合わせ解決時間」も重要な指標ではあります。

現在ヘルプデスクではこの2つの指標を元にストレッチな具体的な数字の目標設定をすることで、デリバリー観点でより高いバリューを発揮できるよう、日々の対応と改善活動をしています。

「即レス」にフォーカスした改善活動

2024年4月以降のヘルプデスクは特に「即レス」にフォーカスし改善を進めています。いくつかの運用ルールに従って対応していますが、その中でも大きく改善に効果のあった2つは下記でした。

  1. 「待機中」チケットの役割明確化と、ステータス設定の徹底
  2. 毎日朝夕2回(10:00、18:00 頃)でのマネージャーによる長期&放置チケットチェック

1.2. ともに効果のあった改善施策ですが、今回は特に 1. の詳細について紹介します。

上記で述べた 図.ヘルプデスクチケットのステータス遷移 のようにヘルプデスク側の作業ステータスについて「オープン」と「待機中」のステータスを使い分けて対応をしています。とはいえ2023年以前は「待機中」のステータスについて、「オープン」との使い分けが徹底されておらず、様々な事情で調整中(半分塩漬けなど)の超長期対応チケットが「オープン」のままになっているなどし、そのようなチケットによって大きくKPIを落としているようなことがありました。

「待機中」のステータスはZendeskでは、デフォルトで非アクティブとなっているステータスでオプションとして有効することで使えるようになるステータスです。3 例えば下記図のようにヘルプデスクとしては認知しておりかつ調整もしているが返事をしていないかつ、「オープン」状態のままというチケットもいくつかあり、またそのようなチケットは、1チケットが非常に大きい累計オープン時間で算出されるのでKPIを大きく落としていることがありました。問い合わせ者としても、裏で作業が進んでいてもその返事が無いと判断ができず困ることが多いです。

ヘルプデスクチケットのユーザー待ち時間時間計算その1

ヘルプデスクチケットのユーザー待ち時間時間計算その1

1. の運用で、「待機中」ステータスの利用ルールについて「リクエスタに次の進捗が示されている状態」ということを明記し、チケットが「オープン」状態であれば、即解決ができない(要調整)の場合でも、作業期日提示し即レス、なるはやで「待機中」にする運用を徹底し、放置状態となっているチケットを撲滅しています。

ヘルプデスクチケットのユーザー待ち時間時間計算その2

ヘルプデスクチケットのユーザー待ち時間時間計算その2

また長期に「待機中」ステータスとなっているチケットについては 2. の運用でマネージャーからの指摘が入るので、現在「放置状態」となっているチケットはDeNAヘルプデスクでは体制的に存在しない状態となっています。

改善施策の効果

上記までの対応はシンプルに言えば「チケットステータスの設定を徹底しよう」「放置チケットは毎日チェックして必要な対応をしよう」というある意味当たり前の対応とも言えますが、その効果はパフォーマンス視覚化の仕組みが無いと確認することができません。また効果がわからないものに対して継続するのは難しいものです。 下記に改善施策後の結果を示します。

改善施策前後のユーザー待ち時間の比較

改善施策前後のユーザー待ち時間の比較

改善施策前後のユーザー待ち時間の比較

改善施策前後のユーザー待ち時間の比較

見て分かるように施策開始前後でユーザー待ち時間(オープンステータス)は大きく減りました。 特に大きく効いているのは、超長期放置チケットによる値の悪化がなくなったことなので、必ずしもどのチケットでも等しくチケット応答速度が上がったというわけではないですが、それを踏まえても良い結果となりました。

改善施策前後の問い合わせ解決時間の比較

改善施策前後の問い合わせ解決時間の比較

改善施策前後の問い合わせ解決時間の比較

改善施策前後の問い合わせ解決時間の比較

問い合わせ解決時間についても、施策前後で大きく数値を減らせました。 こちらは、マネージャーによる長期&放置チケットチェックが効いているのでしょう。

パフォーマンス確認における平均値と90パーセンタイルの使い分けについて

DeNAヘルプデスクのパフォーマンス可視化では、平均値と90パーセンタイル値両方を確認できるようにしています。

チケット対応は基本的には、早く返事をし、早く解決できることに越したことはありませんが、あまりに早さを追求しすぎて実際には未解決のままチケットクローズするようなことはしないように気をつけています。解決困難な内容の場合にも何らかの落とし所を見つけ、クローズするよう丁寧な対応をしています。

難しい相談についても代替の提案なども含め相談にのっていますが、1チケットにあまりに長く対応することも難しいため、20日以上は未解決のままとならない範囲で対応を完了できるようには調整しています。

このような観点から、丁寧さを損ねてまで対応迅速化したいわけではなく、なのでパフォーマンス可視化にあたっても、平均値を過剰に減らすというより、90パーセンタイル値もチェックし、一部の突出して遅いチケットを少なくするというような方向での改善を意識しています。

ヘルプデスクパフォーマンス視覚化の仕組み(Zendesk+LookerStudio+Spreadsheet)

ZendeskにはExploreという蓄積したチケットデータを分析するためのクエリとダッシュボードの機能があります。4 ただ、DeNAヘルプデスクではこのExploreの機能はメインでは使っておらず、主にZendeskAPI経由でチケット変更履歴を定期的にBigQueryに連携するプログラムを内製し、その結果をLookerStudioで見て分析をするという方法を取っています。これにより期ごとに具体的な定量目標を立て改善施策や現場努力などを行っています。

IT戦略部内には、システム開発グループという開発部隊がいます。ヘルプデスクチームではZendeskの管理まではしていますが、ZendeskAPIからBigQuery(GCP)への連携プログラムやLookerStudioはシステム開発グループで管理してもらっています。5 6

IT戦略部としてKPI取得は、システム開発グループで実装されたBigQuery/Looker連携ツールによって成り立っています。 またスポットで特定目的などで詳細なチケット傾向を分析する際には都度ZendeskAPI経由でSpreadsheetにエクスポートするスクリプトなどを作って、その結果からLooker連携し、グラフから分析をしています。

ヘルプデスクパフォーマンス視覚化の仕組み

ヘルプデスクパフォーマンス視覚化の仕組み

この体制により、細やかなクエリ設定やそれに応じた通知機能の実装なども迅速かつ柔軟に連携しています。

補足情報:DeNAヘルプデスクの成り立ちと構造

DeNAヘルプデスクは2018年発足し、総務部、人事部、IT戦略部+CERT(セキュリティ)の混合部署体制で運営されています。 私は他社のヘルプデスク運営をあまり知らないですが、基本的には社内の疑問や依頼についてかなり広い範囲の領域のサポートをできる体制となっています。 ZendeskはIT戦略部で管理しているので、ITがフロント・ルータになることは多いです。 また設備×セキュリティに関する相談など部署をまたがった対応が必要になる場合には、各部署で協力して1つのチケット対応をすることもあります。

ヘルプデスク運営

ヘルプデスク運営

補足情報:数字で見るDeNA(IT)ヘルプデスク(1年間)

ここで、ヘルプデスク対応の規模や現場感が分かる資料として、1年間のDeNAヘルプデスクの各分析データを紹介します。 このような数字を見るだけでも面白いですね。

各グラフについて、母数のチケット数のフィルタ条件(ITのみ場合、一部総務も含まれる場合)など揃っておらず、各チケットの合計も揃っていません(基本的にIT戦略部がかかわるチケットという点は共通です)。正確な条件まではここには記載しませんので、参考程度の数字としてご理解ください。

月ごとにどれくらいITヘルプデスクチケットが上がっているか?

ITヘルプデスクの1年間の対応チケット数の推移のグラフです。

ヘルプデスク_問い合わせ件数_年間

ヘルプデスク_問い合わせ件数_年間

1年間、1ヶ月、1日でのITに関するチケット数は下記になります。

  • 6170 チケット/年
  • 約514 チケット/月
  • 約15チケット/日(営業日のみで計算)

チケット数の増減は、入社人数や対応数との相関がある程度あるようです。新入社員が最も多い新年度初めの4〜6月が多く、次に10月のチケット数が多いことが分かります。

チケットのユーザー待ち時間のヒストグラム

下記グラフは年間のチケット対応におけるユーザー待ち時間のヒストグラムです。多くのチケットは1時間以内のユーザー待ち時間で抑えられていることが分かりますね。

年間ユーザー待ち時間ヒストグラム

年間ユーザー待ち時間ヒストグラム

このユーザー待ち時間には、営業時間外の時間のカウントアップも含まれています。14時間~16時間に分布の山があるのは、即日解決とならず翌日なるはやでの対応となったチケット群がここに来ています。

時間の上位20%を28時間~342時間で範囲の棒グラフでまとめており、こちらも1000件を超える数がありなかなかの数があることが分かります。 28時間以上というのは、単純に対応が遅かったチケットも多少は含まれますが、例えば金曜日にオープン状態のまま休日に突入すると、金曜18:00~24:00(6時間), 土曜日曜0:00~24:00(48時間)、月曜10:00(10時間)で64時間がカウントされることとなり、そのようなチケットがここに大量に含まれています。

また、エンプロイーエクスペリエンスグループはヘルプデスクと端末管理業務を兼ねて実施しているグループなので、端末トラブルの技術・調査対応などで長期対応(1~2ヶ月など)する場合でも、ヘルプデスクとしてチケットをホールドしたままにすることも多いです。その場合もどの程度ステータス変更をこまめにやるかなどにもよりますが、100時間以上ユーザー待ち時間がカウントされることがあります。

操作質問、作業依頼など種類に偏りがあるか?

ITヘルプデスクの1年間の対応チケットにおける分類別集計のグラフです。

年間問い合わせ分類別チケット数

年間問い合わせ分類別チケット数

1番数が多いのは、操作質問のチケットです。ここにはいろんな難易度の操作質問がありますが、その多くにドキュメントの充実などで自己解決可能な質問も多く含まれます。 この部分についてヘルプデスクではドキュメント・ナレッジの充実、生成AIの活用に取り組んでおり、質問の多くについて社内WikiのURLを提示するのみで解決することも多く、対応工数の削減に取り組めています。

2番目に数が多いのは、作業依頼のチケットです。 通常多く発生する作業依頼はそれようの申請フォームの用意がされバックでは自動化されていますが、完全に定型化しきれない、もしくは頻繁に要件が変わる、もしくは人の目のチェックをするのが好ましいなどの様々な要因での作業依頼をZendeskのヘルプデスク窓口経由で受け付けています。

3番目に数が多いのは、トラブルシュートのチケットです。 ここはPC端末やSaaSによる社内ツールのトラブル問い合わせの数です。その多くは相互的なコミュニケーションによるヒアリングによる進めていくことが多く、場合によってはオフィスの窓口誘導と対面での対応も実施しています。チケット数は「操作質問」の半分以下ですが、対応工数は1番多い分類かもしれません。

チケット起票の時間帯の集計

ITヘルプデスクの1年間の起票時間別の分布のグラフです。当然ですが 0〜7時までの深夜早朝にかけては起票が極端に少ないことが分かります。

年間起票時刻別集計

年間起票時刻別集計

チケット起票が一番多い時間帯は 朝10時台の時間でした。始業後、ある程度落ち着いてから、次に何か困っていることなどをヘルプデスクに問い合わせるということが多いのかもしれません。 12時13時は、おそらく休憩・昼食の時間をとられるスタッフが多く一度起票が落ち着き、その後昼14〜15時にかけて2回目のピークが来ています。

チケット起票について曜日毎にどれくらいの偏りがあるか?

ITヘルプデスクの1年間の起票曜日別の分布のグラフです。

年間曜日別起票数

年間曜日別起票数

土日は起票が極端に少ないです。土日には緊急でのPC動作不良などの問い合わせがたまにあり、そのようなチケットがここにカウントされています。 週間において、大きく曜日毎に起票数の違いがありませんが、ある程度の傾向が読み取れます。起票のピークは火曜となっており、次は月曜でした。水曜〜金曜にかけて起票数が若干減っていくという傾向となっています。

締め

DeNAのヘルプデスクは、複数部署による混合部署体制で運営されており、基本的に社内のことについてなんでも相談と対応を受け付ける窓口となっています。 窓口やコミュニケーションハブとしての役割において、対応の迅速さというのは言うまでも無く重要な要素であり、ヘルプデスクの価値を決める指標になり得ます。

従業員にとって価値の高いヘルプデスクを提供するための一つとして「即レス」化に取り組んでおり、KPIを取得し、現場努力と運用改善による対応迅速化を進めてきました。 今後もITヘルプデスクは快適に社内ITを利用いただくための窓口と提供し、適切なKPI設定を元にしたストレッチな目標設定により改善を進め、従業員体験の向上をはかっていきます。


  1. Zendesk - カスタマーサポートとヘルプデスクで重要なKPI (指標) 14選  ↩︎

  2. Zendesk - 「オープン」、「保留中」、「待機中」のチケットのそれぞれの違い  ↩︎

  3. Zendesk Supportへの「待機中」チケットステータスの追加  ↩︎

  4. Zendesk Explore入門チュートリアル 〜 サポートチケット分析はじめの一歩  ↩︎

  5. Looker studio is a trademark of Google LLC. ↩︎

  6. BigQuery is a trademark of Google LLC. ↩︎

最後まで読んでいただき、ありがとうございます!
この記事をシェアしていただける方はこちらからお願いします。

recruit

DeNAでは、失敗を恐れず常に挑戦し続けるエンジニアを募集しています。