インシデント管理モジュールの運用設計書
インシデント管理を動かすには、誰が何をするかを決める必要があります。ServiceNow は9つのロールと13件のSLA定義を用意していますが、それを誰に割り当て、どの体制で回すかは決めてくれません。この記事は、Australia の PDI の構成を前提とした運用設計書のサンプルです。章立てと記述の粒度を、そのまま自社の設計書に流用できる形にしています。
検証環境：Australia PDI / OOTB / 2026-08-31 確認
本書に含む章
運用設計書に必要な章立て
製品が想定している役割分担と、それに対応するロール
優先度ごとに必要な対応体制が違う理由
運用ルールとして文書化すべき項目
品質を測る指標の決め方
設計の前提
ロール9件は、一次受付・二次対応・管理の3層を想定した構成になっている
優先度1のSLAだけスケジュールが未設定で、24時間365日で計測される
通知23件はすべてレコードの項目から宛先を決め、固定の宛先を持たない
運用設計書の章立て
ServiceNow のモジュール運用設計書は、次の構成とする。
章内容1本書の目的と適用範囲2前提条件3運用体制4役割分担（RACI）5運用ルール6サービスレベル7エスカレーション8通知と報告9品質管理10会議体11教育と引き継ぎ12運用開始の準備13用語定義
開発設計書が「どう作るか」を定めるのに対し、運用設計書は「誰がどう回すか」を定める。両者で項目は重複させない。SLA の定義値は開発設計書に、その期限を守る体制は運用設計書に記載する。
第1章：本書の目的と適用範囲
本書は、ServiceNow のインシデント管理モジュールを日常運用するための体制・役割・ルールを定める。
対象読者は、運用の責任者と各役割の担当者とする。システムの設定値と実装方式は、別途の開発設計書で定める。
適用範囲は、インシデントの受付から記録の確定までの日常運用とする。重大インシデントの指揮系統は第8章に、問題管理への引き継ぎ基準は第5章に記載する。
運用の目的は、止まった業務を早く戻すことにある。原因の究明は問題管理、恒久対策は変更管理が担う。この分担を前提として、以降の章を定める。
第2章：前提条件
2-1. 製品が想定している役割分担
ロール9件の構成をもとに、体制を次のとおり定める。
層役割対応するロール利用者障害を連絡するsn_incident_read / snc_internal一次受付受け付けて分類し、切り分けるitil二次対応専門領域の調査と復旧itilリード割り当ての調整とエスカレーション受付itil ＋ itil_adminマネージャ重大案件の指揮と品質管理incident_manager管理者設定の変更sn_incident_admin
incident_manager の権限範囲は、製品の説明に従う。
Can administer Incident properties and Major Incident trigger rules.
（訳: インシデントのプロパティと重大インシデントの発動ルールを管理できる）
引用元: /sys_user_role_list.do?sysparm_query=name=incident_manager
マネージャの役割には「設定の管理」を含める。日々の案件の指揮に加え、プロパティと重大インシデントの基準を管理する立場とする。本書では、この権限の付与対象を第3章で定める。
2-2. 優先度によって必要な体制が変わる
SLA定義13件のスケジュール設定は、優先度によって扱いを分ける。
優先度1（Critical）のSLAはスケジュールを未設定とする。空の場合、計測は24時間365日で稼働する。応答15分・解決1時間の期限を、夜間・休日にも適用する。
優先度2から4は 8-5 weekdays（平日8時から17時）で計測する。
この設定により、必要な体制が決まる。優先度1が発生し得る環境では、夜間・休日の当番を必須とする。優先度2以下しか発生しない前提であれば、平日日中の体制とする。
サービス特性を確認したうえで、体制とSLAの設定を同時に決定する。片方のみを決めると、履行できない期限か、過剰な体制のいずれかになる。
参考：SLAが土日を飛ばす理由：営業時間（cmn_schedule） … 計測が止まる仕組み
2-3. 通知の宛先方針
通知の宛先は、レコードの項目から動的に決定する方式を採用する。特定のユーザーやグループを固定で指定しない。
宛先に使用する項目を次のとおり定める。
宛先を決める項目使用する通知の数送信対象assigned_to7担当者caller_id4利用者watch_list2通知の購読者assignment_group1担当グループwork_notes_list1作業メモの購読者
採用の理由
固定の宛先を指定すると、人事異動やチーム名の変更のたびに通知定義の修正が必要となる。レコードの項目から決定する方式であれば、担当者が変われば通知先も変わり、定義の変更を不要にできる。
標準の通知23件も、すべてこの方式で構成されている。recipient_users と recipient_groups はいずれも空である。自社で通知を追加する場合も、同じ方式を採用する。
例外を認める場合の条件
固定の宛先が必要になるのは、レコードの項目に該当する担当が存在しない場合に限る。「重大インシデント発生時に経営層へ通知する」といった要件がこれにあたる。この場合も、直接ユーザーを指定せず、専用のグループを作成して宛先とする。グループのメンバーを変更すれば、通知定義に触れずに宛先を変えられる。
参考：メール通知が飛ぶまでの4段階（Notification） … 通知が届かないときはここから追う
第3章：運用体制
3-1. 基本方針
一次受付と二次対応の2層で構成し、受付からクローズまでの窓口責任は一次受付が持つ
体制の規模は1日あたりの起票件数から算出する（本書は起票20件／日を想定）
優先度1の24時間計測に備え、夜間・休日はオンコール当番で対応する
運用で使用するグループには必ずマネージャを設定する
3-2. 概要図
利用者からの連絡は一次受付が受け、切り分けの後に二次対応3チームへ割り当てる。夜間・休日の優先度1はオンコール当番が受ける。
3-3. 設計項目
項目決定内容受付時間平日 9:00-18:00一次受付の人数2名（うち1名は電話専任）受付経路電話・メール・セルフサービスポータルの3経路一次切り分けの範囲ナレッジで解決できる範囲。上限15分二次対応の分割Network / Database / Application の3チーム・各2〜3名OLA（応答）割り当てから1時間以内に着手ベンダー窓口各チームのリード当番方式オンコール（優先度1のみ・週交代1名）グループの整備マネージャ必須。階層（parent）は組織に合わせて任意
3-4. 詳細設計
受付時間
受付時間は平日 9:00-18:00 とする。24時間受付とはせず、夜間・休日の優先度1は当番（後述）でカバーする。受付時間外の起票はセルフサービスポータルで受け付け、翌営業日の朝会で拾い上げる。
一次受付の人数
起票20件／日の想定に対し2名を配置し、うち1名を電話専任とする。電話受付から起票までは5分以内とする。2名とも通話中の時間帯が続く場合は、増員より先に受付経路の比率（電話をポータルへ誘導できないか）を見直す。
受付経路
電話・メール・セルフサービスポータルの3経路とする。受付経路は contact_type の7種類に対応させる。monitoring は選択肢が無効であるため、監視連携を導入する場合は有効化する。
Chat と Virtual Agent の使い分けも定める。チャットボットからの起票をどちらで記録するか揃えないと、経路別の集計が二重になる。
一次切り分けの範囲
一次受付はナレッジで解決できる範囲まで対応する。15分で解決しない場合は二次対応へ渡す。この上限を定めないと、一次受付が1件を抱え込み、電話の取りこぼしが発生する。あわせて、一次受付が参照するナレッジの範囲と更新責任を定める。
二次対応チームの分割
Network / Database / Application の3チーム・各2〜3名とする。分割の軸には、カテゴリに対応させる方法とシステムに対応させる方法がある。本設計はカテゴリ（category の Network / Database / Software）に対応させ、割り当てルールの自動振り分け（第5章）と揃える。
OLA（応答）
割り当てから1時間以内に着手する取り決めを、3チーム共通のOLAとして定義する。標準では Database group と Network group の解決OLAが2件用意されているのみで、応答のOLAは存在しない。着手の取り決めがないと、割り当て済みのまま放置された時間を計測できない。
ベンダー窓口
ベンダーへの連絡は各チームのリードが担当する。窓口を1人に定めれば、問い合わせ番号と回答期限の管理を集約できる。担当者が個別に連絡する運用では、督促の重複と漏れが発生する。
当番方式
優先度1のSLAが24時間365日で計測されるため、夜間・休日の体制を定める。
方式採用する場面交代勤務24時間稼働のサービスを持ち、夜間の発生件数が多いオンコール当番夜間の発生がまれで、電話による呼び出しが可能翌営業日対応優先度1が発生しない前提。SLAのスケジュールを平日に変更する
本設計はオンコール当番を採用する。当番の範囲は平日18:00-翌9:00と土日祝、呼び出しは優先度1のみ、呼び出しからの応答は15分以内（SLAの応答期限と同じ）とする。
翌営業日対応を採用する場合、優先度1のSLAにもスケジュールを設定する。スケジュールを体制に合わせておけば、遵守率は実態を映す数字になる。
グループの整備
項目標準の状態グループ総数97親グループが設定されているもの3マネージャが設定されているもの17ロールが設定されているもの4
エスカレーションの通知や承認の経路でグループのマネージャが参照されるため、運用で使用するグループには必ず設定する。標準ではマネージャ設定は2割弱にとどまっており、そのまま使える前提にはない。組織階層に沿った構造を採る場合は parent を設定する。
参考：ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる … 割り当ての実態はここで確認する
この記事の有料部に含まれるもの
4章以降に、運用設計書の記述サンプルを掲載します。
第4章 役割分担：RACI（15作業ぶん）と作業ごとの割り当ての意図
第5章 運用ルール：判定基準・記入基準・保留基準の雛形
第6章 サービスレベル：SLA・OLA・ベンダー契約の整合（実機の期限値つき）
第7章 エスカレーション：報告の起点7つと受け手の動き
第9章 品質管理：指標8つと集計式・目標のめやす
第10章 会議体：5種類の会議の頻度・参加者・議題
第11章 教育と引き継ぎ：教育項目と引き継ぎの書式
第12章 運用開始の準備：確認項目16件と分野別の完了基準
分量は本文の後半およそ12,000字です。自社で変えるのは受付時間・当番方式・OLA時間・指標の目標値の4つ。それ以外は据え置きでも運用設計書として使えます。
💰 ここから先は有料エリア
