1. はじめに
こんにちは。コーポレートエンジニアセクションで社内ITインフラ・ヘルプデスクを担当している冨田です。
私たちのチームは、従業員がより快適、かつスムーズに働ける環境を整えるべく、日々のITサポートをしています。今回は、長年の課題であった『社内問い合わせにおける構造的な課題』を解決し、次世代のヘルプデスク体制を構築するためにJira Service Management（JSM）を導入した事例をご紹介します。
社内ヘルプデスクの運用に課題を感じており、今後ツールの刷新を検討している情シス担当の方の参考になれば幸いです。
2. 現状の課題（計測不能なカオス状態と高いコミュニケーションコスト）
現在、私たちのヘルプデスク体制は、ユーザーと担当者双方に高い負荷をかける構造的な課題に直面しています。
- Slack → Backlog集約の過渡期における運用負荷 現在は、まずSlackで相談を受け、課題の可視化とナレッジの集約を目的に、必要に応じてBacklogへ起票・蓄積していく運用です。一方で、ユーザーには「相談」と「起票」を行き来してもらう場面があり、担当者側もSlackのスレッドとBacklogのチケットを往復しながら情報を突合する必要があります。結果として、ツール間をまたぐ確認作業が増え、スイッチングコストが高くなっています。
- ナレッジは蓄積されるが、活用が「検索中心」に留まる Backlogなどに対応履歴や解決策は蓄積されていく一方で、現時点では主な活用手段が「必要なときに検索して探す」ことに限られています。そのため、類似の問い合わせでも過去事例に辿り着けない、もしくは探し当てるまでに時間がかかり、結果として調査・回答のやり直しが発生しやすい状態です。
- 対応状況の不透明性と「計測不能」な状態 どこにどんな問い合わせがあり、誰がどれだけ時間をかけているかが完全にブラックボックス化しています。結果として、ボトルネックの特定や改善業務といった根本的な対策が「不可能な状態」に陥っています。
3. なぜJira Service Management（JSM）を選んだのか
ツールの分断による非効率やナレッジ活用の限界、ブラックボックス化した対応状況。これらの課題を根本から解消するため、私たちは複数のサービスデスクツールを吟味しました。その中でJSMこそが、我々の目指す『計測可能でナレッジが循環する組織』に最も適しているという結論に至りました。
- Slack中心の体験で「二度手間」をなくすシステム統合 最大の課題である「情報の分断」を防ぐためには、ユーザーは普段使っているSlackから離れずに完結し、担当者はチケット管理ツールだけで完結できるシームレスな仕組みが必須でした。JSMはSlack連携に優れており、両者のスイッチングコストを劇的に下げることができます。
- AIとナレッジ機能のネイティブな統合で「未蓄積」を解消 過去の対応履歴や解決策をナレッジとして自然に蓄積し、毎回ゼロから調査・回答する非効率を解消する仕組みがカギになります。JSMが持つConfluenceへ情報を集約し、AIが過去の類似チケットやFAQを即座にサジェストできる状態を作ることです。これにより、対応の属人化解消に直結します。
- ノーコードの自動化（Automation）とデータの可視化 これまでブラックボックス化していた対応時間や件数を定量化するレポート機能を備えています。さらに、定型処理をノーコードで設定できる柔軟なAutomation機能により、情シス側の運用コストを最小限に抑えながら「計測可能な」一元管理基盤が作れることに魅力を感じました。
4. 導入して分かった工夫とポイント
優れた機能を持つツールでも、「いかに心理的ハードルを下げて使ってもらうか」が重要です。ユーザーに受け入れてもらうための工夫として取り入れたポイントです。
① 親しみやすいAIサポート窓口「たすけ丸」の構想 「システム部門の受付」という堅苦しいイメージを払拭するため、サポート窓口そのものに「たすけ丸」という親しみやすい名前とキャラクターを設定しました。「とりあえず困ったら『たすけ丸』に聞けばいいんだな」という認識を社内に浸透させることを狙っています。
② SlackとJSMの双方向同期によるシームレスな体験 社員にはこれまで通り、専用Slackチャンネルで質問を投げてもらうフローを基本としました。投稿がJSMに自動起票されるだけでなく、情シス側のJSM上での回答がSlackスレッドへ即座に同期される「双方向の連携」を重視しました。これにより、ユーザーはSlackから離れることなくサポートを受けられ、情シス側はJSMで全ての履歴を一元管理できる環境を実現できました。
AI「たすけ丸」による一次回答
同期されたJSMのチケット
③ 点在するナレッジベースの集約 属人化の防止と効率化を両立するため、各所に点在していたナレッジをJSMへ統合し、ユーザーとAIの双方が活用しやすい形へと再整備をしています。
5. 導入して得られた効果（組織的な知識の資産化）
JSM（および『たすけ丸』）を導入・展開したことで、チームや全社に次のような変化が生まれました。
- 二度手間やスイッチングコストの大幅削減 「Slackで聞いてからBacklogに書く」といったユーザーの二度手間がなくなり、窓口と裏側の作業管理が完全に一元化されることで、情報分断による関係者の負担が解消されます。
- ナレッジの自動蓄積とAI連携による対応の効率化 問い合わせ内容や回答ログが自然とJSM上に蓄積されていきます。その情報を基に、AIが質問入力時に適切なFAQを即座に提案するため、ユーザーの自己解決率は飛躍的に向上します。担当者も過去事例のサジェストを活用し、対応時間を大幅に削ることができます。さらに、「蓄積したナレッジが実際の問い合わせ対応に活きる」体験が増えることで、チームとしてナレッジを継続的に蓄積していこうという意欲も高まります。
- 属人化からの脱却と「知識の資産化」 毎回ゼロから調べて回答していた状態から脱却し、個人の頭の中や各ツールに分散していたノウハウが、組織としての「知識の資産」として活用されるようになります。
【図解】理想のサポートフロー
6. 今後の展望（ITサービス品質の可視化から、ユーザーの生産性向上へ）
初期導入が完了し、現在は新プロセスの社内定着を図るフェーズにあります。しかし、真の目的は単なるチケット管理ツールのリプレイスではありません。
- 「計測不能」からの脱却とITサービス品質の可視化 これまで見えなかったボトルネックを独自のダッシュボード等で定量的に可視化し、データドリブンな改善サイクルを回していきます。
- 全社の生産性向上への貢献 ヘルプデスクの構造的な課題を解決し、浮いたIT部門のリソースをより戦略的なシステム企画や運用改善に振り向けます。最終的には、従業員（ユーザー）がバックオフィス対応に割く時間を最小化し、本来の業務に100%集中できる環境を作ることで、全社の生産性向上にダイレクトに貢献することが私たちの目標です。
- 他部門へのサービスデスクの横展開 まずは情シス領域で運用を磨き込み、問い合わせの受け方・ナレッジの整備・可視化の型を確立します。その上で、総務・人事・経理など、他部門の問い合わせ窓口にも同じ仕組みを横展開し、部門横断で「問い合わせ対応の標準化」と「ナレッジ資産化」を進めていきたいです。
7. おわりに
ヘルプデスク業務は「マイナスをゼロにする」側面の強い仕事だと思われがちですが、仕組みやテクノロジーの工夫次第で「ユーザーの生産性を向上させる」クリエイティブな仕事になると信じています。
JSMの導入プロジェクトは、私たちコーポレートエンジニアセクションにとって大きな挑戦でした。現在は新システムが稼働し、運用を回しながら改善サイクルを回しています。
