サービスデスク｜受付・分類・優先度・エスカレーションから復旧まで

問合せを専門担当へ送ったのに、利用者には誰からも連絡がない。技術的な担当は決まっていても、受付記録、復旧の確認、利用者への説明が途切れると支援は完了しません。サービスデスクを、電話を転送する場所ではなく、利用者と支援体制をつなぐ窓口として理解します。

この記事で理解すること

• サービスインシデント、サービス要求、問題管理の役割を区別する。

• 業務への影響と緊急度から優先度を決め、必要な担当へ引き継ぐ。

• 窓口と技術対応者の責任を分け、復旧確認・連絡・完了記録をつなぐ。

架空の倉庫サービスを例にします。通常は平日9時から17時まで、利用者がポータルや電話で連絡できます。重大な業務停止は別途合意した時間外の連絡経路を使うとします。営業時間外も常に同じ担当が即時対応するといった約束は前提にしません。

サービスデスクの役割：窓口と技術対応をつなぐ

サービスデスクは利用者との接点を持ち、問合せ・障害・要求を受け付け、適切な対応へつなぐ窓口です。利用者は内部の担当部署を全て知る必要がなく、窓口から状況を確認できます。統一窓口であることは、一人が全ての技術問題を解決するという意味ではありません。

複数の窓口がある場合も、受付記録と担当、利用者への通知を統合して扱います。ポータル、電話、チャットで同じ障害が届いたら、重複を対応付けます。一つの報告を閉じることで、関連する利用者全員の状況が確認されたと推測しないようにします。

インシデント・要求・問題を分類する

サービスインシデントは、サービスの計画外の中断や品質低下などです。主な目的は業務への悪影響を抑え、通常のサービスを早く復旧することです。原因を完全に除去するまで、復旧を待たなければならないとは限りません。

サービス要求は、利用者が開始する、通常の提供の一部として合意された依頼です。たとえば承認条件を満たすアカウント追加や、手順に沿う情報提供が該当します。依頼という文体だから全てサービス要求、緊急だから全てインシデント、と分類するわけではありません。

問題管理は、一つ以上のインシデントの原因や潜在的な原因を扱い、再発の防止等につなげます。原因が未確定でも記録できます。回避策で使える状態に戻ったことと、根本原因を除去したことを区別します。詳しい既知の誤りや構成情報は別記事へ分けます。

セキュリティインシデントが疑われる場合は、証拠保全や侵害の封じ込めが必要です。サービス復旧だけを理由にログを消したり、感染が疑われる端末を無条件に戻したりしません。通常のサービス支援と、既存のセキュリティ対応記事の役割を連携させます。

受付記録：次の担当が同じ事実を使えるようにする

記録には受付番号、連絡者、対象サービス、発生・検知・受付時刻、症状、業務影響、実施済みの操作、連絡先を含めます。事実と推測は別に書きます。「DBが壊れた」と断定するより、「出庫登録でエラーが出る。原因は未確認」と書く方が観測を正しく引き継げます。

パスワードや秘密のトークンを聞いて記録する方法は避け、許可された本人確認手順を使います。個人情報や業務データの添付も必要な範囲へ限定します。権限追加は、障害を急いで直す理由で承認や最小権限の条件を省略しません。

優先度：影響と緊急度を対応付ける

影響は、対象の利用者数だけでなく、停止した業務や売上・締切・安全等への広がりです。緊急度は、対応をどれだけ早く始める必要があるかです。同じ人数の障害でも、出荷締切直前と翌日まで代替できる状態では急ぎ方が違います。

影響と緊急度を使う優先度表を事前に合意し、重大インシデントの条件も定めます。一人だけの障害でも、必須の承認者が操作できず全拠点が止まるなら影響は大きくなり得ます。連絡者の肩書だけを優先順位の根拠にしません。

新しい情報で影響が広がったり、代替手段が使えなくなったりした場合は、優先度を再評価します。最初に付けた分類や番号を固定したまま待つのではなく、判断の根拠と変更時刻を記録します。

エスカレーション：専門性と権限の不足を補う

機能的エスカレーションは、専門知識や対応能力を持つチームへ引き継ぐことです。窓口での標準手順で直らなければアプリ担当やネットワーク担当へ進めます。階層的エスカレーションは、権限、資源、優先順位の判断等が必要なときに管理者へ上げることです。

両方が同時に必要になることもあります。アプリ担当へ調査を依頼しながら、広い業務停止のため管理者へ知らせ、他部門の応援や通知を判断してもらう場合です。決めた時間が過ぎるまで、重大な影響の報告を待つ必要はありません。

引継ぎには症状、時刻、影響、試した操作、その結果、関連する記録、次の連絡予定を含めます。担当が受領したか、誰が利用者へ連絡するかも確認します。メールを送信しただけでは、対応が開始され責任が移ったとは限りません。

復旧目標と経過時間：合意した測定ルールを使う

この例では受付から復旧までの経過時間を測り、重大停止は1時間以内の復旧を目標とします。9時05分に受け付け、9時40分に専門担当へ送ったら35分が経過し、残りの目安は25分です。内部担当への引継ぎで利用者向けの時計を最初から始める運用にはしません。

実際の契約では開始時刻、対象時間帯、利用者の回答待ちの扱い、測定範囲等が違います。自社に都合よく停止時間を除外せず、合意した条件で計算します。目標超過が見込まれる場合は、早めに管理者へ知らせ、見込みと代替手段を利用者へ伝えます。

復旧確認と完了：動いた範囲を確かめる

サーバのプロセスが起動しただけで、出庫業務の復旧とは限りません。利用者側で出庫登録を実施でき、データの整合や後続処理も条件を満たすかを確認します。代替手段で処理した記録がある場合は、二重登録を防ぎながら戻す手順も必要です。

復旧時刻、実施した対処、残る制限、利用者への通知、確認結果を記録します。対応を閉じる条件は運用で定め、利用者が応答しない場合も既定の確認・通知・期限の手順に従います。原因の詳細が未確定なら、そのことを明示して問題管理へ引き継ぎます。

似た問合せの件数、再発、一次解決率、応答・復旧時間、利用者の評価から改善対象を探します。一次解決率だけを上げるために、専門担当へ送るべき案件を窓口へ留めると復旧が遅れます。指標の目的と副作用を一緒に考えます。

演習1：新しい利用者

条件：新任者のアカウント追加を、合意済みの申請手順で依頼された。

問い：通常は何として扱い、何を確認するか。

解答例：サービス要求として扱い、本人・承認・必要な権限を確認する。

根拠と誤答の確認：新規の通常依頼と、既存サービスの中断を区別します。

演習2：優先度

条件：一人の担当だけが承認できず、全拠点の出荷が止まる。

問い：人数が一人なので低優先度と判断してよいか。

解答例：よくない。影響する業務範囲と締切、代替手段から判断する。

根拠と誤答の確認：影響は連絡人数だけでは決まりません。

演習3：専門担当への引継ぎ

条件：窓口の標準手順で解決せず、DBの専門調査が必要。

問い：どのエスカレーションを使うか。

解答例：機能的エスカレーションで専門チームへ引き継ぐ。

根拠と誤答の確認：管理者へ知らせる必要もあれば、階層的エスカレーションを併用します。

演習4：目標の残り

条件：受付9時05分、引継ぎ9時40分、受付から1時間が復旧目標。時間除外はない。

問い：経過時間と目標までの残りは幾つか。

解答例：35分経過、残り25分。引継ぎ後も受付から測る。

根拠と誤答の確認：担当が変わったから目標がさらに1時間になるわけではありません。

演習5：回避策での復旧

条件：一時的な回避策で業務は再開したが、根本原因は未除去。

問い：記録と次の対応はどうするか。

解答例：復旧と残る制限を記録し、根本原因の調査・除去を問題管理へ連携する。

根拠と誤答の確認：原因が未除去という事実を隠したり、復旧まで止め続けたりしません。

演習6：送信後の責任

条件：専門チームへメールを送ったが、受領確認も利用者への連絡担当もない。

問い：何を追加すべきか。

解答例：受領と担当を確認し、窓口との連絡責任・次の報告予定を決める。

根拠と誤答の確認：送信だけでは対応開始と利用者支援の継続を保証しません。

参照資料とこの記事の範囲

事例・図・演習は教材用に独自に作成しました。公式・教育機関の資料で仕組みを確認し、特定年度の問題本文を前提にせず学べる構成にしています。

PeopleCert ITIL4 サービスデスク

PeopleCert ITIL4 インシデント管理

PeopleCert ITIL4 サービス要求管理

PeopleCert インシデントと支援ツールの連携

IPA APシラバス

関連テーマを続けて学ぶ

プロジェクト計画と変更管理｜スコープ・WBS・関係者の合意をつなぐ

セキュリティインシデントの証拠と復旧

記述式の設問と本文根拠の読み方