この記事のポイント
- インシデントは復旧、問題は再発防止。切り替えの基準（宣言・昇格）を先に決める
- 重大障害（メジャーインシデント）は影響度の数値基準で宣言し、連絡先と更新頻度を固定する
- 変更は「標準・通常・緊急」の3種に分ける。すべてを承認にかけると現場が迂回する
- SLAの未達は誰が何をするかまで決めて初めて機能する
01WHAT 3つのプロセスは「時間軸」でつながっている
インシデントは「今サービスが止まっている」状態に対する活動で、目標は復旧です。復旧の過程で同じ原因による再発が見込まれる場合、問題レコードに昇格し、根本原因の調査と恒久対策を管理します。恒久対策が「本番環境を変える」行為であれば変更要求（Change Request）として起票され、承認を経て実施されます。インシデント（今）→ 問題（再発防止）→ 変更（本番統制）という時間軸でつながることで、場当たり的な復旧と、統制の効いた改善が両立します。
重大障害の宣言基準を数値で決める
「影響が大きいとき」では判断がぶれます。たとえば「基幹システムの停止」「影響利用者 50 名以上」「主要業務が 30 分以上継続不能」のように、影響度を数値・システム名で定義します。宣言後の動きも固定します：専用の連絡チャネル、影響者への第一報、30 分ごとの状況更新、収束後の振り返り（ポストモーテム）。宣言者を当直・サービスデスクに委任しておくと、初動が数分単位で速くなります。
変更を3種類に分ける
変更をすべて承認フローに載せると、現場は「急ぎの作業を事前申請なしでやる」ようになり、統制が形骸化します。定型作業は標準変更（事前承認済み・事後記録）、影響が読めるものは通常変更（CAB 承認）、障害復旧に伴うものは緊急変更（事後承認＋振り返り）と分けます。分類基準を「影響範囲」「作業の定型度」「停止時間」で定義すると、運用が安定します。
補足：SLA は「達成率」より「未達時の行動」が重要
SLA を設定しても、未達時に誰が何をするかが決まっていなければ意味がありません。未達時のエスカレーション、顧客への説明、原因分析の記録までをセットで運用します。
02POINTS つながる運用を作る4つの設計
- 重大障害の宣言基準と手順を決める。影響度を数値で定義し、宣言者・連絡先・更新頻度・振り返り（ポストモーテム）の実施条件まで決めます。
- 問題への昇格ルールを決める。「同一原因で2回以上」「重大障害」「ベンダー対応が必要」など、昇格条件を明文化します。昇格後の担当と期限も決めます。
- 変更区分と承認フローを決める。標準・通常・緊急の3区分と、各区分の承認者・リードタイム・必要情報（影響範囲・ロールバック手順）を決めます。
- レポートと振り返りを月次で回す。MTTR・再発率・変更成功率・緊急変更比率を定例で確認し、基準そのものを改善します。
ポストモーテムは「人」ではなく「仕組み」を問う
振り返りで個人の不注意を結論にすると、以後は事実が上がってこなくなります。「なぜその作業をその手順で行う必要があったのか」「なぜ気づけなかったのか」を問い、変更区分・手順・監視の改善に落とします。
03INSIGHT 運用の質は「緊急変更の割合」に表れる
統制が機能している組織では、緊急変更の比率が下がっていきます。逆に緊急変更が多い状態は、変更計画の粒度が粗いか、標準変更として定型化できていない作業が多いことを示します。緊急変更の理由を分類するだけで、改善テーマ（手順書の不足、テスト環境の不備、監視の穴）が具体的に見えてきます。
当社は基幹システム（SAP）の運用支援で、変更の影響評価と障害対応の切り分けを日常的に行っており、その経験を ServiceNow のプロセス設計に反映できます。特に「SAP の移送・締め処理とどう整合させるか」という観点は、ITSM 設計だけでは抜けやすい論点です。
重大障害の初動を速くするには、当直（オンコール）の設計が欠かせません。「誰が宣言するか」を決めても、深夜にその人が連絡を取れなければ機能しません。当番表は「一次対応者」「判断者」「連絡係」の 3 役を明示し、週次で更新する運用を推奨します。あわせて、宣言時の連絡テンプレート（第一報・経過報・収束報）を準備しておくと情報の抜けが減り、復旧に集中できます。
豆知識：緊急変更にも記録と承認は必要
緊急変更を「記録なし」にすると、後から障害の原因を追えなくなります。実施後に必ず記録し、必要情報（実施内容・影響・ロールバック）を揃えて事後承認する運用が現実的です。
まとめ
- インシデント＝復旧、問題＝再発防止、変更＝本番統制。目的ごとに分けてつなぐ
- 重大障害は影響度の数値基準で宣言し、連絡先・更新頻度・振り返りまで固定する
- 変更は標準・通常・緊急の3区分。承認の重さを分けないと現場が迂回する
- SLAは未達時の行動まで決めて初めて機能する
- MTTR・再発率・変更成功率・初回解決率を定例で回す
出典・参考
- ServiceNow 公式サイト（製品・プラットフォームの一次情報） https://www.servicenow.com/jp/
- ServiceNow 製品ドキュメント（設定・データモデルの一次情報） https://docs.servicenow.com/
- ServiceNow Community（実装事例・ベストプラクティス） https://www.servicenow.com/community/
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-12）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
重大障害（メジャーインシデント）の基準はどう決めますか？
影響を受けるシステム、利用者数、業務停止時間、財務影響などの数値で定義します。あわせて、宣言者・連絡先・更新頻度・収束後の振り返り実施条件まで決めておくことで、初動が属人的にならなくなります。
問題管理は必ず全インシデントに対して行いますか？
いいえ。同一原因の再発、重大障害、ベンダー対応が必要な事象など、昇格条件を決めて該当するものだけを問題として管理します。すべてを問題化すると管理不能になります。
変更が承認待ちで滞留しています。どう改善しますか？
定型度の高い作業を標準変更として事前承認し、承認フローから外すのが有効です。また承認に必要な情報（影響範囲・ロールバック手順・検証方法）をテンプレート化すると、判断が速くなります。
指標はまず何から見ればよいですか？
復旧時間（MTTR）と緊急変更の比率の2つから始めることを推奨します。前者は対応力、後者は統制の効き具合を示し、どちらも改善テーマが具体的に見つかります。
ポストモーテムはどのくらいの頻度で行うべきですか？
重大障害（影響度の高い停止）は必ず発生後 1 週間以内に行い、それ以外は月次にまとめて振り返るのが現実的です。重要なのは頻度より、振り返りで決めた改善策を変更として起票し、実施まで追跡することです。
インシデントとサービス要求の違いは何ですか？
インシデントは「サービスが止まっている・品質が落ちている」状態への対応、サービス要求は「標準的な作業（アカウント追加等）の依頼」です。優先度の付け方が異なるため、カテゴリを分けて別のフローで処理します。