オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

DX

DXによるヘルプデスク改革

DX推進者の技術アンテナ
株式会社オージス総研
コンサルティング・サービス部
2021年1月21日



デジタルトランスフォーメーション(DX)の推進によってクラウドサービスの導入が増えて、ヘルプデスクへのユーザからの利用申請や問い合わせの負荷が高まっています。そのためヘルプデスク自体もDXによって効率化する必要があります。本稿では、ヘルプデスク業務でよくある問題点とその解決方法を述べつつ、クラウドサービスを利用したヘルプデスクのDX事例を紹介します。

ヘルプデスクが抱える問題

社内利用するシステムに対する利用者登録やユーザからの問い合わせ対応といった業務は、ヘルプデスクが実施します。ヘルプデスクはサービスデスクやコールセンターとも呼ばれます。多くのヘルプデスクが、以下のような問題を抱えています。

不透明なタスク管理

何のタスクがありだれがどのタスクをどこまで実施しているかがわからない、といった状態です。よくある原因を以下に述べます。

  • ユーザからの依頼を受付する窓口が定まっていない

  • ユーザからの依頼に対してヘルプデスク担当者が個別に対応を行っている

  • ヘルプデスクチーム全体で情報共有ができていない

フルサービス化

ヘルプデスクが過度な対応を行うことでフルサービス化してしまい、本来必要な業務に時間を割くことができない状態です。よくある原因を以下に述べます。

  • 業務においてユーザとヘルプデスクの責務があいまい、もしくは明示されていない

  • ユーザからの依頼にすべて答えようとして、ヘルプデスクの責務外の作業を行っている

  • マニュアルや手順書がユーザに公開されておらず、問題発生時にユーザが自己解決できない

業務を見直す余裕がない

ヘルプデスクチームが常に作業に追われていて、業務の見直しや改善のための時間がとれない状態です。前述のフルサービス化の状況では、この状態に陥りがちです。何か問題が起きても場当たり的な対応を繰り返すだけで、本質的な問題がいつまでも解決できず、必要のない業務をいつまでも行い続ける状況に陥ります。

ITILによる解決策

ITサービス管理のデファクトスタンダードであるITIL®を元に、前述の問題を解決する方法を述べます。

サービスデスクの設置

ITILでのサービスデスクとは、「ITのすべてのユーザにとっての一元的な単一窓口」と定義される機能です。サービスデスクの立ち上げを行い、あるシステムのユーザ登録の申請といった「サービスリクエスト」や、システムの不具合に関する問い合わせといった「インシデント」をサービスデスクに集約して一元管理することで、タスク状況の可視性が上がりつつ、ヘルプデスク内の情報共有も容易になります。

ナレッジ管理によるセルフサービス化

ナレッジ管理とは、「観点、アイデア、経験、および情報を共有し、それらを適切な時期に適切な場所で利用可能にし、情報に基づいた決定ができるようにする」ことを目的とするプロセスです。何か問題が発生した際にユーザがナレッジを参照して自己解決できれば、ヘルプデスク担当の作業は減少するため、本来必要な業務に時間を割くことができるようになります。ユーザが作業を実施するために必要な権限を適切に与えて、業務マニュアルやFAQといったナレッジを整理してユーザへ展開することで、ユーザが自己解決できる仕組みを構築します。

継続的サービス改善の実施

継続的サービス改善とは、ニーズに合わせてITサービスやプロセスを継続的に改善する活動であり、サービスが価値を提供し続けるための見直しのフェーズです。ヘルプデスク運営状況を示す各種指標(サービスレベルアグリーメント、SLA)についてモニタリングしつつ、定期的なふりかえりによりチーム全員で業務課題の洗い出しや改善検討を行います。定例ミーティング等で時間をかけて議論することが望ましいですが、まずは朝会や夕会にて短時間の議論を行うようにして、ふりかえりの実施を習慣化することからはじめます。

クラウドサービス活用による解決

前述の方法によりヘルプデスクの課題は解決できますが、一朝一夕で仕組みを整えることはできません。多くのヘルプデスクがエクセル方眼紙による申請書や、エクセルマクロを組み込んだタスク管理表を元に業務を行っており、解決のためには申請書フォーマット改修やエクセルマクロ改修といった作業が多数発生してしまいます。エクセル依存のヘルプデスクでは、解決のための作業自体がヘルプデスクにとっての大きな負担となってしまうため、クラウドサービスの活用が有効な解決策となります。

以下に代表的なクラウドサービスを列挙します。すべてITILに準拠したヘルプデスクを実現するためのクラウドサービスです。

本稿では、無料で利用可能なプランがあるアトラシアン社の「Jira Service Management(以下、JSMと表記)」および、同社のナレッジ管理クラウドサービスである「Confluence ( https://www.atlassian.com/ja/software/confluence )」の導入によるヘルプデスク業務改革の事例を紹介します。

ユースケースと全体像

本稿では、JSMおよびConfluenceを導入したヘルプデスク運営の例として、サービスリクエスト管理のユースケースで説明します。図 1に業務の流れとクラウドサービスの構成の全体像を示します。

図 1 サービスリクエスト管理の全体像

図 1 サービスリクエスト管理の全体像

ユーザはリクエストを行う前にまずConfluence上のナレッジベースを検索して、問題に対して自己解決を図ります。自己解決ができなかった場合に、JSM上のサービスデスクへリクエストを行います。リクエストはすべてJSM上で管理され、ヘルプデスクチームのメンバーが主体となってリクエスト処理を行います。

詳細

リクエストの受付

JSMではリクエスト受付をするためのポータルサイト(ヘルプセンター)が用意されており、社内システムサポートや人事、総務といった単位で専用の窓口を作成することができます。図 2はヘルプセンターのトップページです。サービスデスクで対応可能な業務が定義されており、ITILにおける「サービスカタログ」としての役割を果たしています。

図 2 ヘルプセンターのトップページ

図 2 ヘルプセンターのトップページ

ユーザはリクエストを行う前に、この画面上で手順書やFAQなどのナレッジベースを検索することができます。図 3に示すように、ヘルプセンターの検索窓にキーワードを入力すると、Confluenceで管理しているナレッジベースから関連があるページが表示されます。ここでユーザが対応方法を知って自己解決ができればリクエストは行われないため、ヘルプデスクの作業を低減することができます。

図 3 ナレッジベースの検索

図 3 ナレッジベースの検索

ユーザによる自己解決ができない場合は、受付窓口にアクセスして、リクエストを登録します。図 4は、リクエスト種類の選択画面で、窓口で受付可能なリクエストが表示されています。ユーザはリクエストする内容に応じて、どのリクエストを登録するか選択します。

図 4 リクエスト種類選択画面

図 4 リクエスト種類選択画面

リクエストに必要な情報は、リクエスト種類ごとに異なります。図 5はリクエスト情報の登録画面です。リクエストに必要な情報は画面項目として定義されており、ヘルプデスクチームはリクエスト種類ごとに項目を設定することができます。

図 5 リクエスト情報の登録画面

図 5 リクエスト情報の登録画面

トップページの検索窓だけではなく、図 6のようにリクエスト情報の登録画面においても、画面項目への入力内容を元にナレッジベースの検索が行われます。

図 6 ナレッジベースの検索(リクエスト入力時)

図 6 ナレッジベースの検索(リクエスト入力時)

図 7に示すように画面項目への入力が完了したら、「送信」ボタンを押下してリクエストを登録します。

図 7 リクエストの登録

図 7 リクエストの登録

リクエストの処理

次に、受付したリクエストに対して、ヘルプデスクチームがリクエストの処理を行います。

図 8は、JSM上で受付したリクエストの一覧画面です。現在の担当者や対応のステータスがひと目でわかるように設計されており、対応期限や優先度といった条件でのソートも可能です。ユーザが登録したリクエストは一覧に追加されます。JSMでは、タスクをキューと呼びます。

図 8 リクエストの一覧画面
図 8 リクエストの一覧画面

図 9はキューの詳細画面です。①ユーザが登録したリクエスト内容や、②ユーザとのコミュニケーションといった対応履歴、③SLA達成までの残り時間といった情報が表示されています。

図 9 キュー詳細画面

図 9 キュー詳細画面

ユーザからのリクエストの内容を確認したら、担当者をアサインします(図 10)。自分以外のメンバーを担当者にアサインするか、自分が担当者となってリクエストの処理を開始します。

図 10 担当者のアサイン

図 10 担当者のアサイン

リクエストの処理にあたって、リクエストを登録したユーザと対応する担当者間でコミュニケーションが必要となります。図 11のように該当のキュー上のコメント登録機能を利用してコミュニケーションを行います。メンションを利用して、相手に通知を送ることも可能です。

図 11 ユーザと担当者間のコミュニケーション

図 11 ユーザと担当者間のコミュニケーション

図 12のように、「内部メモ」機能を利用すると、ヘルプデスク内のみでコミュニケーションを行うことが可能です。内部メモの記載内容は、ヘルプデスクメンバーのみが参照可能で、ユーザは参照できません。

図 12 内部メモの利用

図 12 内部メモの利用

ユーザとの会話はすべて記録され、時系列で蓄積されます。リクエストへの対応が進むと、コメント欄は図 13のようになります。

図 13 コメント履歴の例

図 13 コメント履歴の例

ヘルプデスク担当者の対応が完了したら、図 14のリクエスト解決の画面から、①対応状況を選択して、②「この課題を解決」ボタンを押下して課題をクローズします。

図 14 リクエスト解決の画面

図 14 リクエスト解決の画面

課題をクローズした際に、図 15に示すようなメールがJSMからユーザへ自動送信されて対応の完了を通知します。メール中に満足度調査フォームが埋込まれており、ユーザはワンクリックでヘルプデスクに対する評価をフィードバックできます。

図 15 ユーザに自動送付されるメールの文面

図 15 ユーザに自動送付されるメールの文面

図 16は対応が完了したキューの詳細画面です。①課題の詳細、②対応の履歴、③SLA達成状況、④満足度といった情報を確認することが可能です。これらの情報は、後述する「継続的改善」において、課題分析に用いることができます。

図 16 キューの詳細画面(対応完了後)

図 16 キューの詳細画面(対応完了後)

ナレッジの管理

リクエストの対応内容については、次回からユーザが自己解決できるようにFAQとして取りまとめて公開します。図 17は、キュー詳細画面にて関連するナレッジベースを表示しているところで、ここから直接FAQの作成が開始できます。

図 17 FAQの作成

図 17 FAQの作成

図 18は、FAQ作成の画面です。FAQはConfluence上で作成します。テンプレートをあらかじめ用意して利用することで、一定の記載レベルでFAQを即時に作成することが可能です。

図 18 FAQ作成画面(Confluence)

図 18 FAQ作成画面(Confluence)

作成したFAQを公開すると前述のナレッジベース検索の結果にすぐ反映されます。図 19のようにユーザリクエストの際にFAQが表示されるようになり、同様の問題を自己解決できる可能性が高まります。

図 19 追加したFAQの検索結果

図 19 追加したFAQの検索結果

継続的改善の実施

継続的改善ではヘルプデスク業務のふりかえりを行います。ふりかえりでは、前述の図 16の情報や、リクエスト解決数の推移やSLA達成率を指標として、問題点の洗い出しや解決方法を検討します。図 20に示すSLA達成率グラフのように、JSMでは、各キューに蓄積された記録を元に、モニタリング指標を自動で算出して可視化できるので、情報収集や資料作成といった準備不要でふりかえりを実施できます。

図 20 SLA達成率のモニタリング

図 20 SLA達成率のモニタリング

おわりに

本稿では、ヘルプデスク業務における課題とその解決策、そしてクラウドサービスを利用したヘルプデスク業務改革の事例について紹介しました。サービスリクエスト管理業務を中心に述べましたが、ITILにおける問題管理やインシデント管理もあわせて実施することで、ヘルプデスクにあらゆる課題を集約しつつ改善が行われるようになるため、ユーザが利用するシステムの品質も向上します。ヘルプデスク業務改革は、単なる作業時間の削減にとどまらず、継続的な品質向上にもつながるため、改革を行う効果は絶大です。DX推進というと、よくAIや機械学習、データ活用といったワードが注目されていますが、ヘルプデスクのDXについても検討してみることをお勧めします。

ITIL® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.