変更管理モジュールの運用設計書
変更管理を動かすには、誰がタイプを判定し、いつCABに諮り、いつ実施してよいかを決める必要があります。ServiceNow は8状態の遷移ボタンと4種のタイプ、条件ベースのリスク判定を用意していますが、「CABは何人で開くか」「リードタイムは何日前か」「凍結期間はいつ設けるか」は決めてくれません。この記事は、Australia PDIの構成を前提とした運用設計書のサンプルです。そのまま自社の設計書に流用できる粒度にしています。
検証環境：Australia PDI / OOTB / 2026-09-01 確認
本書に含む章
運用設計書に必要な章立て
変更管理者・CAB・実装担当という3層の役割分担
CAB定足数を実測（cab_meeting 6件）から設計する方法
risk_conditions 4件を自社のリスク基準に変換する方法
Unauthorized Change監視の前提条件（既定で無効という実測）
設計の前提
ロール7件は、変更管理者・CAB・実装担当の3層を想定した構成
SLA定義（contract_sla）はcollection=change_requestで0件が標準で、時間管理はリードタイム基準に委ねられている
CAB（cab_meeting）は実測6件がすべて同一ボード「Network CAB」で、対象はtype×risk×categoryで絞り込まれる
運用設計書の章立て
ServiceNow のモジュール運用設計書は、次の構成とする。
章内容1本書の目的と適用範囲2前提条件3運用体制4役割分担（RACI）5運用ルール6サービスレベル7エスカレーション8通知と報告9環境をまたぐ実装フロー10品質管理11会議体12教育と引き継ぎ13運用開始の準備14用語定義
開発設計書が「どう作るか」を定めるのに対し、運用設計書は「誰がどう回すか」を定め、項目は重複させない。riskの計算ロジックは開発設計書、CABがそれをどう扱うかは運用設計書に書く。個々の操作手順は運用手順書へ渡す。
第1章：本書の目的と適用範囲
本書は、ServiceNow の変更管理モジュールを日常運用するための体制・役割・ルールを定める。
本書が対象とするのは、運用の責任者と各役割の担当者である。システムの設定値と実装方式は、別途の開発設計書で定める。
適用範囲は、変更の起票からClosedまでの日常運用とする。インシデント・問題からの起票基準、Backout・凍結期間・コンフリクトの運用ルールを第5章に記載する。複数の変更をまとめるReleaseと、定型サービスを申請するService Requestは対象外とし、本書はChange Requestの個々の実施までを扱う。
運用の目的は、本番への変更を統制下に置きながら実施速度を落とさないことにある。一律に重い承認を課すと現場が疲弊し、統制を緩めると本番障害を招く。この両立をタイプとリスクの重みづけで実現する方針を、以降の章で具体化する。change_requestはIncident・Problemと同じくtaskテーブルを継承する構造であり、共通部分は「taskテーブル：ITSM全プロセスの共通の親」で確認できる。
第2章：前提条件
2-1. 製品が想定している役割分担
ロール7件の構成をもとに、体制を次のとおり定める。
層役割対応するロール起票者変更を申請するitil（追加ロールなしでsn_change_writeを自動保有）変更管理者タイプ判定・スケジュール統括・審議依頼を担うchange_managerCABNormal／Emergencyの承認審議を担うsn_change_cab.cab_manager実装担当自分に割り当てられたchange_taskのみ読み書きするsn_change_task_assigned_user管理者設定・Change Modelの変更を行うsn_change_admin
sn_change_task_assigned_userの権限範囲は、製品の説明に従う。
Access to change_task if the change_task is assigned to the user.
（訳: change_taskが自分に割り当てられている場合のみ、そのchange_taskへアクセスできる）
引用元: /sys_user_role_list.do?sysparm_query=nameLIKEchange
sn_change_task_assigned_userは担当タスクに絞られ、change_managerはテーブル全体を見渡す。sn_change_cab.cab_managerも独立した合議体であるため、本設計では実装担当・変更管理者・CABの3層に分ける。
2-2. Change に SLA が無い前提
contract_slaをchange_requestで絞ると0件になる。インシデント・問題管理と同じく、変更管理にもOOTBのSLA定義は存在しない。
本環境ではSLA定義が0件である。したがって本設計ではSLAを追加せず、risk_conditionsが内蔵する「開始予定日まで3日以内ならリスクを上げる」という既定の境界を土台に、type別のリードタイム基準を第6章で自社定義する。
2-3. 通知の宛先方針
有効な通知16件を確認すると、宛先はassigned_to・assignment_group・requested_by・watch_list・work_notes_listの5種類に収まる。本設計もこの5項目で通知の宛先を構成し、固定の追加宛先は置かない。
本環境ではon_hold系3件のevent_nameがapproval.cancelled（Approval用の流用）になっている。したがって本設計では、この3件を第8章で修正対象として扱う。
第3章：運用体制
3-1. 基本方針
変更管理者1名の下にCABを置き、AssessからScheduledまでの進行管理責任を持たせる
CABは対象を絞って審議する。全Normal／Emergencyを一律に審議しない
実装担当はロール保持者に絞り込まれているため、ロール付与を体制構築の起点にする
Standardはテンプレートで事前承認を済ませ、CABを通さず速く回す
3-2. 概要図
起票された変更はtypeで分岐し、Normal・Emergencyのうちcab_definitionの対象条件に合致するものだけがCABへ進む。対象外は変更管理者が単独で判断する。
3-3. 設計項目
本環境のcab_definitionは1件で、対象をtype IN (Normal, Emergency) かつ risk IN (Very High, High, Moderate) かつ category = Networkに絞っている。Standard・Low risk・Network以外のカテゴリはこのCABの対象外である。
項目決定内容変更管理者の人数1名CAB対象の絞り込みtype×risk×categoryで条件定義（cab_definitionのchange_condition）CAB出席者実測3名/回（6ミーティング全件で均等）1回あたりの審議件数実測平均10件/回（agenda_item 60件÷6回）1回の所要時間実測2時間（09:00-11:00固定）Standardの起票経路テンプレ（std_change_producer_version）経由のみ、Create Newには出さない
3-4. 詳細設計
変更管理者の人数
1名を専任として置く。タイプ判定・CAB審議依頼・スケジュール統括という一貫性が求められる役割が中心なためである。複数人に分散すると、Standard昇格の判断や凍結期間の設定がぶれる。
CAB対象の絞り込み
本環境のcab_definitionは1件で、対象カテゴリをNetworkに絞っている。したがって本設計では、カテゴリごとにcab_definitionを追加する構成を採用する。全カテゴリを1つのCABに詰め込むと、無関係な議題の審議に時間を割く。
CAB出席者
実測では6回のミーティングいずれも出席者が3名で均等である。したがって本設計ではCAB定足数の目安を3名とし、最低2名（過半数）を成立条件とする。3名は、影響を受ける領域の責任者を漏れなく含めつつ招集の負荷を抑える下限に近い。
1回あたりの審議件数
実測では60件の議題が6回に均等に近い形で配分されており、1回あたり平均10件である。したがって本設計ではCAB定例1回の審議上限を10〜15件とし、超過が続く場合は開催頻度を週次から週2回へ見直す。
Standardの起票経路
chg_modelのうちStandardはavailable_in_ui=falseで、Create Newの画面には出てこない。標準変更はテンプレート（std_change_producer_version）を経由してのみ起票される仕組みである。したがって本設計では、Standardの入口をテンプレート登録に一本化し、Create Newからの手動作成を許可しない。
記入例（体制の運用イメージ）
CHG0000076（Change default router on unix201）は、type=Normal・risk=High・Category=Networkである。cab_definitionの対象条件に合致し、CABの議題にも実際に載っている。承認者の内訳は4-4で示すが、本設計の3名という定足数の目安に対し、実際の承認依頼は6名に広がっている。
この記事の有料部に含まれるもの
4章以降に、運用設計書の記述サンプルを掲載します。
第4章 役割分担：RACI（14作業・6役割、全行A1つ）と割り当ての意図
第5章 運用ルール：type選択基準・リスク評価基準の自社基準化・変更凍結期間・コンフリクト運用
第6章 サービスレベル：SLA非採用の判断と、type別リードタイム基準の設計
第7章 エスカレーション：Authorize滞留の判定方法（初期基準例58%）を定義し直した報告基準6つ
第8章 通知と報告：通知16件の目的・重複整理・抑止条件と、incident.rfcの実態
第9章 環境をまたぐ実装フロー：change_taskの構成基準とUpdate Setの移送・エビデンスの残し方
第10章 品質管理：KPI5つ（分子・分母つき）と実測の着地
第11章 会議体：4会議体の開催条件・招集責任者・未決エスカレーション
第12章 教育と引き継ぎ：教育項目と引き継ぎの書式
第13章 運用開始の準備：確認項目14件（完了条件・証跡つき）
自社で変えるのはCAB対象条件・リードタイム日数・KPIの目標値の3つ。それ以外は据え置きでも運用設計書として使えます。
💰 ここから先は有料エリア
