社内ヘルプデスクの効率化：問い合わせを減らす仕組みとナレッジ運用

社内ヘルプデスクの効率化とは、問い合わせ1件あたりの手間を減らすことと、問い合わせそのものが発生しない仕組みを作ることの両方で、効果が大きいのは後者です。回答のテンプレートや対応の速さを磨いても、同じ質問が毎週届くなら、担当者の時間は同じように消えていきます。

組み立てる順番は、窓口を1つにして記録を取る、分類と指標で発生源を突き止める、設定の見直しとセルフサービスで発生源をつぶす、ナレッジで利用者が自分で解決できる状態を保つ、の4段です。受付フォームの項目、指標の定義、FAQ記事のテンプレート、チャットボットを入れる前にそろえる条件まで、そのまま使える形で並べます。

ヘルプデスク効率化の第一歩：窓口を1つにする

電話、個人宛てのチャット、廊下での声かけ、メールと入口が散らばっていると、記録が残らず、同じ問題が何件起きているかが誰にもわかりません。入口はフォームか専用のチャットチャンネルのどちらかに決め、どちらから来ても必ずチケットになる形にします。1週間だけ記録を取って上位の問い合わせを知る方法は情シスとはで触れましたが、ここではその記録を毎日続けられる仕組みにします。

入れてはいけない項目もあります。「カテゴリ」を利用者に選ばせると選び方が人によってばらつき、分類の集計が当てになりません。「優先度」を選ばせると、ほとんどが「高」になりがちです。利用者には影響範囲と業務への影響を事実として答えてもらい、分類と優先度は受け付けた情シスが付けます。

個人宛てのチャットで来た依頼は、断らずに情シス側でチケットに転記し、「チケット番号○○で受け付けました。以後はこちらで連絡します」と返します。利用者が窓口を覚えるまでは、この転記を続けます。叱って窓口に誘導すると、次から相談自体が来なくなり、問題が見えないところで大きくなります。

分類と指標：毎月なにを見るか

分類は2階層で足ります。1階層目は対象（アカウント、端末、ネットワーク、業務システム、SaaS、印刷、その他）、2階層目は種類（障害／依頼／質問）です。障害と依頼を分けるのは、ITILでいうインシデントとサービス要求の区別と同じで、処理の流れが違うからです。障害は優先度で順番を決め、依頼は手順書どおりにさばき、質問はFAQに変える候補になります。

件数の削減だけを目標にするのは避けてください。問い合わせの件数は、窓口が使いにくくなっても減ります。件数と一緒に、自己解決の手段が使われているか（FAQの閲覧数、セルフサービスのパスワードリセットの利用回数）を並べて見て、「なぜ減ったか」を説明できる状態にしておきます。

月次の見直しは30分で回します。議題は、上位5分類の件数と前月からの変化、発生源への打ち手の進み具合、「解決しなかった」の多いFAQと社内検索でヒットしなかった語、再発した障害、そして来月着手する打ち手を1つ決めること、の順です。最後の「1つ」が肝です。打ち手を複数同時に始めると、どれが効いたのか翌月の数字で判断できなくなります。毎月1つずつ発生源をつぶしていけば、上位の顔ぶれは少しずつ入れ替わっていきます。

社内問い合わせの削減：発生源で減らす打ち手

上位に来た分類は、回答を速くするより、発生させない方法を探します。上位に来やすい問い合わせと、その発生源、発生源での打ち手を並べます。

効果が大きいのは1行目のパスワードです。定期的な変更を強制すると、利用者は末尾の数字を1つずつ増やすような予測しやすい変更をしがちで、安全性はかえって下がるという考え方が主流になっています（米国NISTのパスワードに関するガイドラインもこの立場です）。やめる前提として、MFAの全員登録を先に済ませます。2行目のアプリのカタログは、端末管理の仕組みがあれば用意できます。WindowsならIntuneで始めるWindows端末管理のアプリ配布の手順がそのまま使えます。

パスワードやMFAのリセットを受け付けるときは、本人確認の手順を必ず決め、例外なく守ってください。社員を装ってヘルプデスクに電話し、MFAのリセットを依頼する手口は、実際の侵入の入口として使われています。折り返しは人事の台帳にある番号へかける、上長にチャットで確認してもらう、といった手順を、相手が役員を名乗っても省かないことが条件です。

ナレッジ運用：FAQ記事のテンプレートと古くしないルール

FAQは作るより保つ方が難しい仕組みです。古い手順が1つ見つかると、利用者はFAQ全体を信用しなくなり、問い合わせに戻ります。書き方と保ち方の両方を最初に決めておきます。記事は次のテンプレートで書きます。

タイトル：利用者が見た表示や、利用者の言葉をそのまま書く
　　　　　例：経費精算システムを開くと「権限がありません」と表示される
対象　　：どの端末・どのシステム・どの部門の人向けか
症状　　：何をしたときに、何が起きるか（1〜2行）
原因　　：わかっている範囲で1行。わからなければ書かない
手順　　：番号付きで、1つの手順に1つの操作。画面の写真を添える
解決しないとき：連絡先と、連絡するときに添えてほしい情報
最終確認日：○年○月○日　　確認者：○○

• タイトルは利用者の言葉で書く。「SSOの認証エラー」ではなく「会社のアカウントでログインできない」
• 解決したチケットから書く。例として「同じ質問が2回来たら記事にする」と決める
• 記事の末尾に「解決した／しなかった」のボタンを置き、「しなかった」が続く記事から直す
• 最終確認日から一定期間（例：半年）更新のない記事は、担当者が確認し直すか非公開にする
• 社内検索で「ヒットしなかった検索語」を月1回見て、足りない記事を作る

解決しながら書き、使われながら直す、という考え方は、サポートの分野ではKCS（Knowledge-Centered Service）という手法として体系化されています。小さな情シスで取り入れるなら、「チケットを閉じるときに、関連するFAQ記事のリンクを貼る。なければ下書きを作る」という1つのルールから始めるのが現実的です。チケットと記事が結びつくと、どの記事が何件の問い合わせを減らしたかも数えられるようになります。

チャットボットや生成AIを入れる前に

一次対応をチャットボットや生成AIに任せる構想はよく出ますが、答えの元になるナレッジが整っていない状態で入れると、もっともらしい誤答で問い合わせがかえって増えます。入れる前に、次の条件をそろえてください。

• 上位の問い合わせについて、最終確認日の新しいFAQ記事がある
• ボットが答えられなかったとき、会話の内容ごとチケットに引き継げる
• 回答の根拠にした記事へのリンクを必ず表示し、利用者が確かめられる
• 管理者向けの手順など、権限のある人にしか見せられない文書を参照先から外している
• 誤答を報告する手段があり、報告された記事を直す担当者が決まっている

生成AIが社内文書を検索して答える仕組み（RAG）の設計と、権限の扱いの考え方はRAGとはで扱っています。ヘルプデスクの用途では、参照先を公開してよいFAQとマニュアルだけに絞るところから始めると、権限の事故を避けながら効果を確かめられます。

生成AIのボットに社内のファイル共有をまるごと読ませるのは避けてください。人事や経営の資料が参照先に紛れ込むと、ボットが権限のない社員にその内容を答えてしまうおそれがあります。ボットの参照先は、公開してよいと確認した文書の置き場所を別に作り、そこだけを読ませます。

よくある失敗パターン

1行目は特に起きやすい失敗です。ツールの選定は、フォームと表計算で分類・指標・月次の見直しを回してみて、「チケットとFAQを結びつけたい」「優先度ごとの時間を自動で測りたい」といった具体的な不足が出てからにします。不足が言葉になっていれば、比較する機能も自然に決まります。

よくある質問

サポート業務を効率化するにはどうしたらいいですか？

対応を速くするより、問い合わせが生まれる原因を減らす方が効きます。窓口を1つにしてすべてを記録し、分類ごとの件数から上位の原因を選び、設定の見直しやセルフサービスで発生源をつぶします。残った問い合わせは、FAQと回答のテンプレートで1件あたりの手間を減らします。

業務効率化のアイデア10選は？

ヘルプデスクに絞ると、窓口の一本化、受付フォームの必須項目化、分類の2階層化、パスワードのセルフリセット、承認済みアプリのセルフインストール、権限申請のワークフロー化、SaaS更新の事前告知、利用者の言葉で書くFAQ、ヒットしなかった検索語の月次確認、部門ごとの相談役の任命の10個が、少ない投資で効果の出やすい打ち手です。

事務を効率化するアイデアはありますか？

情シスが関わる事務なら、紙やメールで回している申請をフォームとワークフローに置き換え、承認の記録が自動で残るようにするのが効果の大きい打ち手です。入社や退職の手続きのように毎回同じ手順のものは、先にチェックリストにそろえてから自動化します。手順がばらばらのまま自動化すると、例外処理が増えて続きません。

まとめ

ヘルプデスクの効率化の本体は、回答を速くする工夫ではなく、問い合わせを生まれにくくする仕組みです。窓口を1つにして記録を取り、毎月1つずつ発生源をつぶし、FAQは最終確認日と利用者の評価で保ちます。チャットボットは、その土台がそろってから載せる最後の段だと考えてください。

次に読む

• ITILとは？情シスに必要なプラクティスだけを取り入れる方法
• Intuneで始めるWindows端末管理：登録・コンプライアンス・アプリ配布の手順
• RAGとは？仕組みと社内導入で失敗しない設計原則をわかりやすく解説