チーム化した情シスのヘルプデスク対応、属人対応から窓口一本化へ

情シスが複数人体制になったはずなのに、社員からの問い合わせは相変わらず特定の1人に集中する。「〇〇さんに聞けば早い」という認識が社内に定着してしまい、他のメンバーには問い合わせが来ない。これは、100〜300人規模で複数人体制へ移行した会社に非常によく見られる現象です。人数を増やしただけでは、問い合わせの分散は自動的には起きません。むしろ、窓口の設計を意図的に変えない限り、社員はこれまで慣れ親しんだ相手に問い合わせを続け、結果として「複数人いるのに実質ひとり対応」という状態が温存されてしまいます。このガイドでは、属人的な問い合わせ対応から、チームとして機能する窓口一本化への移行方法を、チケット運用の設計を中心に解説します。

なぜ複数人体制でも問い合わせが分散しないのか

ひとり情シスの時代、社員は「困ったら〇〇さんに聞く」という単純な行動パターンを身につけています。このパターンは、担当者が増えたからといって自動的には変わりません。理由はいくつかあります。

• 社員が新しい担当者の存在を知らない、あるいは信頼度を測りかねている: 長年対応してきた既存担当者に対する信頼と、新しく加わったメンバーへの信頼には、当然ながら差がある
• 問い合わせ先が明示されていない: 「誰に連絡すればよいか」の窓口が公式に周知されていないと、社員はこれまでの習慣通り、知っている人に直接連絡する
• 個人チャット・個人メールでのやり取りが黙認されている: 会社としての窓口を作っても、個人宛のダイレクトメッセージでの問い合わせを断らずに対応し続けると、社員はわざわざ公式窓口を使うメリットを感じない

これらの要因はすべて、「窓口を一本化する」という明確な意思決定と、その意思決定を実行する仕組みがない限り、自然には解消されません。複数人体制への移行がうまくいっている会社は、共通して「問い合わせの入り口を1つに統一する」という設計を、増員のタイミングと合わせて実施しています。

「増員した当初、私個人のチャットに相変わらず問い合わせが来ていました。新しいメンバーに『こっちにも聞いてください』と社内アナウンスしても、なかなか変わらなかったんです。結局、個人チャットへの問い合わせには『恐れ入りますが、こちらの窓口からお願いします』と毎回案内するのを徹底したところ、数ヶ月かけて少しずつ窓口経由に切り替わっていきました」

窓口一本化の基本設計: 「どこに聞けばよいか」を1つにする

窓口一本化とは、社員から見た問い合わせの入り口を1つに統一することを指します。対応するメンバーが複数人になったとしても、社員側が「誰が対応するか」を意識する必要がない状態を作ることが目的です。

窓口の形態には、主に次のような選択肢があります。

100〜300人規模になると、問い合わせの件数自体が増加する傾向にあるため、単なる共有メールアドレスだけでは、対応漏れや二重対応(複数の担当者が同じ問い合わせに気づかず、それぞれ対応してしまう)といった問題が起きやすくなります。この段階では、チケット管理の仕組みを導入し、「誰が」「いつ」「どの問い合わせに」対応しているかを可視化することが重要になります。

チケット運用を導入する前に整理すべきこと

チケット管理ツールを導入すれば自動的に運用が改善するわけではありません。ツールを導入する前に、次の点を整理しておくことをお勧めします。

1. 問い合わせのカテゴリ分類: 「PCトラブル」「アカウント関連」「ソフトウェア導入の相談」「その他」など、あらかじめ分類の軸を決めておくと、後述の担当割り振りがスムーズになる
2. 優先順位の判断基準: 「業務が完全に止まっている」「一部の作業に支障が出ている」「急ぎではない相談」など、対応の優先順位を判断する基準を、対応者間で共通認識にしておく
3. 一次対応の目標時間: 問い合わせを受けてから、最初のリアクション(受付確認、簡易な回答など)を返すまでの目安時間を決めておく。すべてを即座に解決する必要はなく、まず「受け取った」ことを伝えるだけでも、問い合わせた側の不安は大きく軽減される

これらの整理ができていないままチケット管理ツールだけを導入すると、単に「問い合わせがツールに溜まっていくだけ」の状態になり、かえって対応の遅延を可視化してしまうだけの結果に終わりかねません。運用ルールとツールは、セットで設計する必要があります。

担当割り振りのルールを決める

窓口を一本化すると、次に課題になるのが「入ってきた問い合わせを誰が対応するか」という割り振りのルールです。割り振りの方式には、いくつかのパターンがあります。

• カテゴリ別の固定割り振り: あらかじめ決めた担当分担(システム別・業務別)に沿って、カテゴリごとに担当を固定する
• ローテーション方式: 曜日や週単位で、一次対応の担当者を持ち回りにする。特定の人に負荷が偏りにくい
• 早い者勝ち方式: チームメンバー全員が問い合わせ一覧を見られる状態にし、対応できる人が自分から手を挙げて着手する

どの方式にも一長一短があります。カテゴリ別の固定割り振りは専門性を活かしやすい一方、担当者が不在のときに対応が滞りやすいという弱点があります。ローテーション方式は負荷分散に優れますが、担当外の分野の問い合わせに苦戦することもあります。早い者勝ち方式は柔軟性が高い反面、誰も手を挙げず放置される「対応の抜け」が起きるリスクがあります。

実務上は、これらを組み合わせて運用している会社が多く見られます。例えば、基本はカテゴリ別の固定割り振りとしつつ、担当者が不在・多忙な場合のバックアップとしてローテーション担当を置く、といった形です。担当分担そのものの決め方については兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で詳しく扱っているので、ヘルプデスクの割り振りルールを考える際の土台として参照してください。

個人チャットへの問い合わせにどう向き合うか

窓口一本化を進める過程で、必ず直面するのが「これまで通り個人チャットに直接連絡してくる社員」への対応です。ここでの対応方針は、複数人体制への移行の成否を左右する、意外と重要なポイントです。

個人チャットでの問い合わせを、これまで通り黙って対応し続けてしまうと、いつまで経っても窓口一本化は実現しません。一方で、いきなり「個人チャットでの対応は一切しません」と厳格に運用すると、社員側の不満や戸惑いを招き、情シスへの心理的な距離が広がってしまうリスクもあります。

現実的な移行の進め方として、次のようなステップが有効です。

1. 移行期間を設ける: 「〇月から窓口を一本化します」という告知を、十分な余裕を持って社内に周知する
2. 個人チャットへの問い合わせには、必ず窓口への案内を添えて返す: 対応自体は行いつつ、「次回からはこちらの窓口にお願いします」という一言を毎回添える
3. 一定期間経過後は、原則として窓口経由のみ受け付ける: 移行期間が終わったら、個人チャットへの問い合わせは窓口への転記を促す運用に切り替える

このプロセスには数ヶ月単位の時間がかかることを、あらかじめ見込んでおいてください。長年の習慣を変えるには、根気強い案内の継続が必要です。焦って強制的に切り替えようとすると、かえって社員の反発を招き、窓口自体への信頼を損なう結果になりかねません。

チケット管理ツール選定時の視点

チケット管理の仕組みを導入する際、専用のチケット管理システム(ヘルプデスクツール)を新規に導入するか、既存のチャットツールやグループウェアの機能で代用するかは、多くの会社が悩むポイントです。判断の目安として、次の観点を確認してください。

専用ツールを導入する場合、社員側の入力のハードルも考慮する必要があります。専用のフォームやポータルサイトからの起票を必須にすると、社員によっては「わざわざそこまでするほどでもない」と感じ、結局チャットでの直接連絡に戻ってしまうことがあります。導入初期は、チャットツールからの問い合わせも受け付けつつ、社内向けのbotやワークフローで自動的にチケット化する仕組みを組み合わせるなど、社員側の負担を増やさない工夫が定着を左右します。

既存のチャットツールやグループウェアの機能で代用する場合も、最低限「誰が対応中か」「対応済みかどうか」が一覧で分かる状態を作ることが重要です。スレッドへの絵文字リアクションで対応状況を示す、専用のステータス管理シートを併用するなど、ツールの機能に頼りきらず、運用でカバーする工夫も選択肢に入ります。

窓口一本化に伴う社内周知の設計

窓口一本化は、情シス側の仕組みを整えるだけでは完結しません。社員全員に「新しい窓口ができたこと」「そこに問い合わせてほしいこと」を周知し、行動を変えてもらう必要があります。周知が不十分なまま仕組みだけ整えても、結局誰も新しい窓口を使わないという事態に陥ります。

周知を効果的に行うためには、次のような工夫が有効です。

• 複数のチャネルで繰り返し告知する: 全社会議、社内チャット、メール、入社時のオンボーディング資料など、複数の接点で繰り返し伝える。1回の告知だけでは、社員の記憶に定着しにくい
• 「なぜ変えるのか」の理由も添える: 単に「窓口が変わりました」ではなく、「対応の質を上げるため」「対応漏れを防ぐため」といった理由を添えることで、社員側の納得感が高まる
• 入社時のオンボーディングに組み込む: 新しく入社する社員には、最初から新しい窓口の使い方を案内する。既存社員の習慣を変えるより、新入社員に最初から正しい行動を身につけてもらうほうが、長期的には浸透が早い
• 管理職・部署責任者を巻き込む: 各部署の責任者から、部署内のメンバーに向けて周知してもらうことで、情シスからの一方的な告知よりも浸透しやすくなる

社内周知は一度実施して終わりではなく、窓口が定着するまで、定期的にリマインドを続ける必要があります。特に、異動や新規配属で新しく加わったメンバーは、過去の周知を知らないため、継続的な情報発信の仕組みを作っておくことが重要です。

対応履歴を「個人の記憶」から「チームの資産」に変える

属人対応の最大の問題点は、対応の履歴が個人のメールボックスやメモに閉じてしまい、他のメンバーが参照できないことです。同じような問い合わせが再度発生したとき、過去にどう対応したかが分からず、毎回ゼロから調べ直すことになります。これは対応時間の無駄であると同時に、せっかく過去に得た知見が組織に蓄積されないという、機会損失でもあります。

窓口を一本化し、チケット管理の仕組みに移行すると、この対応履歴が自然とチームの共有資産に変わっていきます。過去のチケットを検索すれば、類似の問い合わせに対する過去の対応方法を確認でき、新しく加わったメンバーでも、先輂の対応履歴を参考にしながら対応できるようになります。

属人対応の時代は、この対応履歴が担当者個人の経験値としてのみ蓄積され、その担当者が異動・退職すればゼロから積み上げ直すしかありませんでした。チームの資産として蓄積する仕組みに切り替えることは、単なる業務効率化にとどまらず、組織としての対応力そのものを積み上げていく取り組みでもあります。

この効果を最大化するためには、次の工夫が有効です。

• 対応内容を簡潔にでもメモとして残す習慣をつける: 口頭で解決した場合でも、後から検索できるよう、簡単な要約をチケットに残す
• よくある問い合わせは、FAQやナレッジベースとして別途整理する: 頻出する問い合わせについては、チケットの中に埋もれさせず、独立した参照資料として整備する
• クローズしたチケットも、一定期間は検索可能な状態で保管する: 過去の対応履歴が消えてしまうと、ナレッジとしての価値が失われる

対応履歴の蓄積は、単に効率化のためだけでなく、複数人体制における「暗黙知の可視化」にも直結します。個々のメンバーの頭の中にしかなかった対応ノウハウが、チーム全体で参照できる形式知に変わっていくプロセスそのものが、属人化からの脱却です。

ヘルプデスク対応の量が増えたときの見極め

窓口を一本化すると、これまで個人チャットに分散していた問い合わせが、一箇所に集約されて可視化されます。このとき、初めて「実は思っていたよりも問い合わせの件数が多かった」という事実に直面する会社も少なくありません。

問い合わせ件数が可視化されたら、次の観点で対応体制の見直しを検討してください。

• 件数の推移: 月あたりの問い合わせ件数が、拠点や社員数の増加に伴ってどう推移しているか
• カテゴリ別の内訳: 特定のカテゴリ(例えばアカウント関連の問い合わせ)が突出して多くなっていないか
• 一次対応にかかる時間: 対応時間が長期化しているカテゴリがあれば、手順の見直しやFAQ化で効率化できないか

アカウント関連の問い合わせが特に増加している場合、それは単なるヘルプデスク対応の課題にとどまらず、入退社対応や権限管理の運用そのものを見直す必要があるサインかもしれません。この点については複数拠点・部署のアカウント管理、入退社対応の「量」が追いつかなくなったらで詳しく扱っています。

また、セキュリティに関わる問い合わせ(不審なメールを受信した、パスワードが漏れたかもしれない、といった内容)がヘルプデスクの窓口に混在してくる場合、通常の問い合わせとは異なる優先順位・エスカレーションのルールを設けておく必要があります。この点は従業員100人超えで必要になるセキュリティ体制、ひとり対応の限界ラインで扱っている内容と密接に関わるため、ヘルプデスクの運用ルールを設計する際にあわせて検討してください。

エスカレーションフローの設計

窓口一本化と担当割り振りのルールが整っても、すべての問い合わせが一次対応者だけで解決できるわけではありません。判断に迷う案件、専門性の高い技術的な問題、あるいは複数部署にまたがる調整が必要な問い合わせについては、次の対応者に引き継ぐエスカレーションのフローを明確にしておく必要があります。

エスカレーションフローを設計する際は、次の3階層を意識すると整理しやすくなります。

1. 一次対応: 窓口で受け付けたメンバーが、まず自分で解決を試みる範囲
2. 二次対応: 一次対応で解決できない場合に引き継ぐ、より専門性の高いメンバーやシステムの担当者
3. 外部エスカレーション: 社内メンバーだけでは対応できない場合の、外部ベンダーや開発会社への連絡

このフローが明確でないと、「誰に相談すればよいか分からず、一次対応者が抱え込んでしまう」という事態が起きやすくなります。特に、複数人体制になったばかりの時期は、新しく加わったメンバーが「これくらいで二次対応に回してよいのだろうか」と遠慮してしまい、本来もっと早く相談すべき案件を自分だけで抱え込んでしまうケースも見られます。エスカレーションは弱さの表れではなく、チームとして適切に機能するための仕組みであることを、日頃から周知しておくことが大切です。

エスカレーション先の連絡方法や、対応可能な時間帯についても、あらかじめ明文化しておくと、いざというときに迷わず動けます。特に外部ベンダーへのエスカレーションについては、契約上の対応範囲や連絡手順を、窓口対応者全員が把握している状態にしておく必要があります。

FAQ・セルフサービス化で問い合わせ自体を減らす

窓口一本化とチケット運用の整備が進んだら、次のステップとして、問い合わせ自体の件数を減らす取り組みも検討する価値があります。よくある問い合わせをFAQとして公開し、社員が自己解決できる仕組みを整えることで、ヘルプデスクの対応負荷そのものを軽減できます。

FAQ化を検討する際は、蓄積されたチケットの履歴から、頻出する問い合わせを定量的に洗い出すことが出発点になります。「パスワードを忘れた」「PCが遅い」「Wi-Fiに接続できない」といった典型的な問い合わせは、多くの会社で上位を占める傾向があります。個別のトラブルシューティングの手順そのものについては、コラム記事でも扱っているので、FAQ化の際の参考にしてください。

FAQを整備する際の注意点として、作っただけで満足せず、実際に社員が参照しているかを定期的に確認することが重要です。FAQの存在が周知されていなければ、結局窓口への問い合わせは減りません。問い合わせを受けた際に「こちらのFAQもご参照ください」と案内を添える運用を続けることで、徐々にFAQの認知度と活用率を高めていくことができます。

応答品質のばらつきをどう防ぐか

窓口を一本化し、複数のメンバーが対応するようになると、新たに浮上する課題が「対応品質のばらつき」です。ひとりで対応していたときは、対応の丁寧さや説明の分かりやすさは自然と一定でしたが、複数人が対応するようになると、メンバーごとの経験や説明スタイルの違いが、社員から見た体験の差として現れます。

対応品質のばらつきを防ぐためには、次のような取り組みが有効です。

• 定型的な回答文のテンプレート化: よくある問い合わせについては、返信の基本フォーマットをあらかじめ用意しておく。一から文章を考える負担を減らしつつ、回答の抜け漏れも防げる
• 対応後の簡易なふりかえり: 特に難しかった対応や、時間がかかった対応については、チームの定例ミーティングなどで簡単に共有する場を設ける。個人の経験がチーム全体のノウハウに変わっていく
• 新メンバーの対応を、一定期間は先輩がレビューする: 対応内容を送信する前に、あるいは送信後の履歴を、経験のあるメンバーが定期的に確認し、フィードバックする仕組みを設ける

品質のばらつきを完全にゼロにする必要はありません。むしろ、メンバーごとの個性や強みを活かしながら、最低限の一貫性(丁寧さ、対応の速さの目安など)を揃えるという発想のほうが、現実的で持続可能です。

対応時間帯・拠点をまたぐ体制の考慮

100〜300人規模になると、拠点が複数に分かれていたり、始業・終業の時間帯が部署によって異なっていたりするケースも増えてきます。窓口一本化を設計する際は、こうした時間帯・拠点の差異も考慮に入れる必要があります。

例えば、本社と支社で始業時刻が異なる場合、支社の始業直後に発生した問い合わせに、本社の対応メンバーがすぐに気づけない状態が続くと、支社側の社員に「対応が遅い」という不満が生まれやすくなります。この場合、次のような工夫が考えられます。

• 対応可能な時間帯を、窓口の案内ページや告知に明記しておく(社員側の期待値を事前に調整する)
• 拠点ごとに一次対応の担当を分散させる(拠点の状況に詳しいメンバーが、その拠点からの問い合わせを優先的に拾う)
• 緊急度の高い問い合わせについては、電話等の即時性の高い連絡手段を別途用意しておく

拠点をまたいだ体制の課題は、ヘルプデスク対応だけでなく、システムの棚卸しやアカウント管理など、他の業務領域にも共通して現れる課題です。拠点差異への対応の考え方は、複数拠点・部署のアカウント管理、入退社対応の「量」が追いつかなくなったらでも扱っているので、あわせて参照してください。

まとめ: 窓口一本化は「仕組み」と「粘り強い運用」の両輪

複数人体制になったからといって、問い合わせが自然に分散するわけではありません。窓口を意図的に一本化し、チケット管理の仕組みを整え、担当割り振りのルールを明確にすることで、初めて「複数人体制が機能している」状態が実現します。同時に、個人チャットへの問い合わせに対する粘り強い案内の継続や、対応履歴をチームの資産として蓄積していく地道な積み重ねも欠かせません。

窓口一本化は、一度仕組みを作れば完了するものではなく、社員の行動習慣が変わるまで、根気強く運用を続ける必要があるプロセスです。仕組みの設計と、粘り強い運用の両輪が揃って初めて、属人対応から脱却したヘルプデスク体制が実現します。

窓口一本化に着手するタイミングは、複数人体制への移行と同時、あるいはそれよりも少し前が理想的です。増員が決まってから窓口の設計を後回しにしてしまうと、新しいメンバーが加わった後も、結局既存担当者に問い合わせが集中し続け、増員の効果を十分に発揮できない期間が長引いてしまいます。増員のプロセス全体をどう設計するかについては、ひとり体制から複数人体制へ。情シスチームの役割分担をどう設計するかで扱っているので、窓口一本化の準備もこのプロセスの一部として組み込んでおくことをお勧めします。

最後に強調しておきたいのは、窓口一本化の目的は「情シス側の管理のしやすさ」だけではないということです。社員にとっても、「どこに聞けばよいか迷わない」「対応が誰であっても一定の品質が保たれる」という状態は、業務上のストレスを軽減する意味を持ちます。窓口一本化は、情シス側の都合だけで進めるのではなく、社員側の体験を向上させる取り組みとして位置づけ、丁寧に進めていくことが、結果的に社内からの信頼獲得にもつながります。

自社のヘルプデスク対応がどの程度属人化しているか、客観的に把握したい場合はひとり情シス危険度診断もあわせてご活用ください。窓口一本化・チケット運用・エスカレーションフローの整備は、どれも一朝一夕には完成しません。まずは今、社員からの問い合わせがどこに、どれだけ届いているかを可視化するところから始め、少しずつ仕組みを整えていくことをお勧めします。

窓口が一本化され、対応履歴がチームの資産として蓄積されていく過程は、社員から見た情シスへの信頼が積み上がっていく過程でもあります。誰に聞いても同じ品質の回答が返ってくる、対応の抜け漏れがない、過去の相談内容がきちんと記録されている。こうした積み重ねが、複数人体制になった情シスチーム全体への信頼へとつながっていきます。窓口一本化は地味な取り組みに見えるかもしれませんが、その効果は日々の小さな問い合わせ対応の質の積み重ねとして、着実に社内の評価に反映されていきます。地道な積み重ねを軽視せず、粘り強く続けていくことが、複数人体制の情シスチームに対する社内の信頼を、確かなものにしていきます。今日からできる小さな一歩として、まずは今の問い合わせがどこに集まっているかを確認するところから始めてみてください。