レッスン6：ヘルプデスク・ITSM/ITIL 運用

このレッスンで学ぶこと

ヘルプデスクを「早く直す」から「二度と起こさない」へ転換する視点を語れる
チケット管理システム（Jira Service Management／Zendesk／Freshservice）の役割を理解できる
SLA 設定（優先度 1〜4）とエスカレーションのフローを組める
ナレッジベースの育て方（記事作成・更新・活用サイクル）を設計できる
AI チャットボット活用と PostMortem 運用の要点を挙げられる

前レッスンでは SaaS 選定・契約・棚卸しを扱いました。本レッスンでは、情シスの日常業務量として最も大きい「ヘルプデスク」と、その背後にある ITSM／ITIL の運用に踏み込みます。中核メッセージ 4「ヘルプデスクは早く直すより、二度と起こさないナレッジ化が本業」の実装編です。

ヘルプデスクの位置づけ

ヘルプデスクは、従業員からの IT 関連問い合わせを一次的に受け付ける窓口です。中堅企業では以下の 3 種類の問い合わせが主流です。

要求（Request）：アカウント作成、SaaS のライセンス追加、パスワードリセット
障害（Incident）：PC が動かない、Wi-Fi が繋がらない、SaaS がエラーで使えない
問い合わせ（Query）：使い方の質問、設定変更の相談

これらを「その場で直して終わり」の運用にすると、同じ問い合わせが繰り返し発生し、情シスの時間が奪われます。「二度と起こさない」視点でナレッジ化することが本質です。

ITSM／ITIL の概要

ITSM（IT Service Management）は、IT サービスの運用を体系化する考え方です。その代表的なフレームワークが ITIL（IT Infrastructure Library）で、最新版は 2019 年 2 月にリリースされた ITIL 4 です。

ITIL 4 の主なプラクティス

情シス業務に直接関わる主なプラクティスは次の通りです。

サービスデスク：ヘルプデスク運用
インシデント管理：障害対応の型
問題管理：根本原因の分析
変更有効化：設定変更のプロセス
サービス要求管理：定型要求の処理

中堅企業の情シスは、ITIL の全体をそのまま導入する必要はありません。中核となる「サービスデスク」「インシデント管理」「問題管理」の 3 つを軸に、自社に合った運用を組むのが実務的です。

チケット管理システムの役割

紙・メール・口頭で問い合わせを受け付ける運用は、10 人以下の会社なら回りますが、それ以上ではチケット管理システムが必須になります。

主なチケット管理システム

システム	特徴	適したシーン
Jira Service Management	Atlassian、開発チームとの統合	エンジニア組織中心
Zendesk	UI シンプル、カスタマーサポート系	顧客対応と社内対応の統合
Freshservice	ITSM 特化、AI 機能	中堅企業の情シス専用

いずれもチケットの作成・分類・担当者アサイン・ステータス管理・SLA トラッキング・レポート出力の基本機能を持ちます。

チケットのライフサイクル

flowchart LR
  A[問い合わせ受付] --> B[チケット化]
  B --> C[分類・優先度付け]
  C --> D[担当者アサイン]
  D --> E[対応・解決]
  E --> F[ナレッジ化]
  F --> G[クローズ]

対応が完了したらすぐクローズせず、ナレッジ化を経由することが「二度と起こさない」の実装です。

SLA 設定と優先度

SLA（Service Level Agreement）は、社内向けにも設定します。優先度 1〜4 で応答時間・解決時間を約束します。

優先度	定義	応答時間	解決時間目標
P1（緊急）	全社影響、業務停止	15 分以内	4 時間以内
P2（重大）	部署影響、業務遅延	1 時間以内	8 時間以内（1 営業日）
P3（通常）	個人影響、業務可能	4 時間以内	3 営業日以内
P4（軽微）	業務影響なし	1 営業日以内	1 週間以内

P1 は全社に影響するインシデントで、Wi-Fi 全断・メールサーバー全停止・Microsoft 365 全社ダウンなどが該当します。P4 は個人の設定変更相談やライセンス追加など、緊急性の低い要求です。

エスカレーションの型

応答時間超過 → 一次担当者から上位担当者へ
解決時間超過 → 情シスマネジャーへ、必要に応じてベンダーへ
P1 発生 → 即時に情シスマネジャーと経営陣へ通知

ナレッジベースの育て方

ナレッジ化は「二度と起こさない」の中核です。次の 4 ステップで運用します。

ステップ 1：記事作成

チケット対応が完了した時点で、対応担当者がナレッジ記事を書きます。要素は次の 3 つです。

症状：何が起きていたか
原因：なぜ起きたか
対応手順：どうやって直したか（スクリーンショット・コマンド例つき）

ステップ 2：記事共有

従業員向け：セルフサービスポータルで検索可能に
情シス内向け：新人研修資料としても利用

ステップ 3：定期更新

記事へのアクセス数・参照回数を追跡
SaaS の仕様変更などで情報が古くなった記事を更新
使われていない記事はアーカイブ

ステップ 4：閲覧・活用

従業員が同じ問い合わせをする前にセルフサービスで解決
情シス担当者も過去記事を参照して対応時間を短縮

💡 ポイント ナレッジ記事は「1 か月に 1 件も書けない」のではなく「1 チケット 1 記事」を目標にします。10 分で書ける短い記事の積み重ねが、3 年後の情シス業務の質を決めます。

AI チャットボットの活用

近年、ヘルプデスクの一次受付を AI チャットボットで自動化する事例が増えています。

AI チャットボットが得意な領域

パスワードリセットの案内
SaaS の使い方の初歩的な質問
ナレッジ記事の推薦（「これを見てください」）
チケット作成のアシスト

AI チャットボットが苦手な領域

複数システムをまたぐ複雑な問題の切り分け
高いストレス状態の従業員への感情対応
セキュリティに関わる判断が必要な問い合わせ

AI チャットボットは「情シス担当者の代替」ではなく「情シス担当者の一次受付補助」として位置付けるのが実務の標準です。過大な期待は反発を生み、過小な期待は活用機会を失います。

PostMortem 運用

PostMortem（事後検証）は、障害・インシデント発生後に「なぜ起きたか」「二度と起こさないためにどうするか」を分析する運用です。

PostMortem の 5 要素

タイムライン：何が起きたか、時刻順の詳細
影響範囲：誰が、何ができなかったか、業務影響
根本原因：直接原因と根本原因（5 Whys 分析）
アクション：再発防止のための具体的なタスク
学び：組織として何を学ぶか

責任追及ではなく学習の場に

PostMortem を「誰が悪かったか」の追及に使うと、情シス担当者が問題を隠すようになり、逆効果です。「なぜ起きたか」の分析と「二度と起こさない」ためのアクションに焦点を絞ります。「非難のない事後検証（Blameless PostMortem）」が推奨される運用です。

⚠️ 注意 PostMortem のアクションは「なんとなくの改善」ではなく「担当者・期限・完了条件が明確なタスク」にします。「気をつける」「注意する」といった精神論のアクションは、実際には何も変わらず、次の障害を防げません。

中核メッセージ 6 個の再掲

本コース全体を通じて、6 個のメッセージを繰り返します。

情シスは「守る・選ぶ・運用する」の 3 役割——役割ごとに時間を配分する
アカウント運用が情シスの生命線——入社と退社の 2 点で 8 割が決まる
SaaS は買った瞬間ではなく解約時に苦しむ——契約時に出口を設計する
ヘルプデスクは「早く直す」より「二度と起こさない」——ナレッジ化が本業
インシデントは一次受付・トリアージ・エスカレーションの 3 手で対応する
IT 予算は「守り・攻め・維持」の 3 分類で経営に説明する

このレッスンで扱うのはメッセージ 4「ヘルプデスクは早く直すより、二度と起こさないナレッジ化が本業」です。チケット管理・SLA・ナレッジベース・PostMortem を組み合わせることで、情シスは「消防隊」から「予防組織」へ進化できます。

次のレッスンで扱うこと

次のレッスン 7 では、インシデント対応と脆弱性管理を扱います。一次受付としての情シスの役割、トリアージの 3 判断、CSIRT へのエスカレーション基準、パッチ配信運用（Windows Update for Business／WSUS）、脆弱性情報の追跡（JPCERT/CC・IPA）まで整理します。CSIRT/SOC のインシデント対応体系そのものは既刊 IT 基礎系入門コースが扱いますが、本コースは「情シス担当者としての一次受付とエスカレーションの型」に絞ります。

確認クイズ

このレッスンで学んだ内容を確認しましょう。