ServiceNow
「仕組みで回す」——SerivceNowの運用定着化とは
- 仕組み化
- 運用改善
- ワークフロー改善
- 運用定着
- 目次
1. 問題提起：「情シス頼み」で前に進まない
朝の打合せで「とりあえず情シスへ回して」と誰かが口にする。運用の現場では、よくある光景ではないでしょうか。この一言が続くと、現場の判断は止まりやすくなります。依頼が一か所に集まり、初動が遅れやすくなるからです。
本来、先に決めておきたいのはとてもシンプルです。誰が最初に動き、どこまで対応し、どの条件で引き継ぐのか。そのために使うのが、RACI（役割分担表）です。
Responsible、Accountable、Consulted、Informedを整理し、役割を分けます。あわせて、運用KPI（応答・解決・再発）を定義し、ダッシュボードで見える化します。さらに、SLA/OLA（SLAは利用者と合意する水準、OLAは部門間の取り決め）を土台に置くと、判断に迷いにくくなります。
ここで止まりやすいのが、決めたはずのことが日々の運用に染み込まない点です。
2. 現状の誤解・よくある状態：見える化もルールもあるのに動かない
「結局、情シスがやる」が前提になっている
問い合わせはすべてサービスデスク経由で情シスへ。こうした流れが続くと、一次対応の幅は自然と狭くなります。現場で判断できることも後ろ倒しになり、最終的にどの案件も情シス行きとなります。結果として、全体が詰まりやすい状態になりがちです。
KPIはあるが、運用に効く数字になっていない
ダッシュボードは用意した。けれど、件数や平均時間を並べただけで終わっている。そんな状態も少なくありません。打ち手につながらない数字では、現場は動きにくいのが実情です。
ITSM（ITサービス管理：インシデントや変更などの運用管理）を整えても、KPIが応答・解決・再発の3系統で揃っていないと改善は進みにくくなります。
ルールは作ったが、引き継ぎの運び方が曖昧
SLA（Service Level Agreement）は掲げたものの、部門内のOLA（Operational Level Agreement）が詰め切れていない。SOP（標準作業手順書）はあるが、更新や監査の回し方が決まっていない。ナレッジも作成で止まり、レビューや再利用まで回っていない。そこにシャドーIT（見えないIT資産や独自運用）が重なると、統制が効きにくくなります。
3. 原因分析：役割の曖昧さ、数字の弱さ、合意の浅さ
役割と引き継ぎ条件が決まっていない
一次対応の範囲、エスカレーションの基準、当番の責任が曖昧なままでは判断はどうしても遅れます。RACIで役割を明記していないと、受け渡しのたびに「誰がやるのか」で立ち止まりやすくなります。
可視化の土台となるデータがつながっていない
CMDB（構成管理データベース：機器やサービスの関係を記録）と運用データが連動していない。この状態では、原因特定や再発抑止が難しくなります。Tanium（エンドポイントの可視化・操作基盤）やEDR（Endpoint Detection & Response：端末の検知と対応）の情報が運用に戻らない場合も、是正の効果は見えにくくなります。
合意が“宣言”で止まり、手順に落ちていない
SLA/OLAは、数値・手順・責任まで落として初めて機能します。ゼロトラスト（境界に頼らず、ユーザーや端末状態で守る考え方）を掲げても同じです。権限付与やレビューの具体手順が決まっていないと、現場ごとに解釈が分かれます。その結果、“情シス頼み”の流れが残りやすくなります。
4. 解決アプローチ：役割設計×KPI×SLA/OLAを一本の流れに
RACIで「誰がどこまで」を決め切る
一次対応、判断、承認、レビューの役割をはっきりさせます。引き継ぎ条件と目安時間も、あわせて定義します。例外対応は悩みやすいため、扱い方だけを先に短くルール化しておくと混乱が減ります。
KPIは「応答・解決・再発」で揃える
応答は初動の速さ、解決は収束までの確実さ、再発は同じトラブルを抑える力を測ります。代表的な指標としては、初回応答時間、一次解決率、再発率が挙げられます。これに加えて、必要に応じてMTTR（復旧までにかかる平均時間）を使う場合は、対象とする業務範囲を明確にしておくことが重要です。
ダッシュボードは、役割別に分けて表示すると使われやすくなります。
SLA/OLAは「数値＋手順＋責任」で書く
「初回応答4時間」と書いても、その時間内に何をもって応答とするのかが分からなければ、判断は人に寄ってしまいます。そこで、数値は定義まで含めて明確にします。応答や解決がどの状態を指すのかを言葉で補います。
あわせて、手順も決めます。期限内に収まらない場合の通知や承認の順番まで落とすことで、迷いが減ります。
最後に、責任です。誰が判断し、誰が作業し、誰が最終的に責任を持つのかをはっきりさせます。
SLA（対ユーザー）とOLA（部門間）で、用語としきい値を揃えると、解釈のズレが生まれにくくなります。
ナレッジは「作る→見直す→使う」を仕組みにする
ナレッジは作るだけでは使われません。レビュー期限、承認者、更新ルールを先に決めます。
テンプレートとタグで検索性を整え、再利用率や参照数をKPIに入れると、自然と回り始めます。
教育はオンボーディングとロール別で最小構成に
新任者向けには、まず全員が共通で知るべき内容を教えます。
具体的には、RACI、KPI、SLA/OLA、ナレッジ、SOPが「何のためにあるか」を押さえます。
そのうえで、役割ごとに必要な運用や判断ポイントを別の研修で補います。
一度に詰め込まず、短いコースを繰り返す方が、現場の負担を増やさずに定着しやすくなります。
SOPは監査とセットで「生きた手順」にする
SOPは作った瞬間から古くなり始めます。版数、改訂日、責任者、保管場所を明確にします。月次の簡易監査で抜けや古い記述を見直し、次の改訂に反映する流れを作ります。
5. 実務ステップ：RACI、KPI、SLA/OLA、ナレッジ、教育、SOP、モニタリング
ステップ1：RACIと引き継ぎルールを固める
一次対応者、判断者、承認者、レビュー担当を定義します。引き継ぎ条件と連絡方法も決め、「今、誰がボールを持っているか」が分かる状態を目指します。
ステップ2：KPIを3系統で定義し、基準値を置く
応答・解決・再発のKPIを選び、現状値を測ります。基準値と目標値をServiceNow運用のダッシュボードへ反映します。
ステップ3：SLA/OLAを部門間で合意し、ワークフローに落とす
数値だけでなく、通知・承認・例外の手順まで文書化します。合意内容をそのままワークフロー条件に組み込みます。
ステップ4：ナレッジの作成・レビュー・再利用を定着させる
テンプレを統一し、必須項目を決めます。期限切れの記事は自動で見直しに回し、再利用率をKPIで追います。
ステップ5：教育は短く回す
オンボーディングは1〜2時間程度に絞ります。ロール別研修は月1回で、更新点を共有します。
ステップ6：SOPに版管理と簡易監査を付ける
参照場所を一つに集約し、月次の抜き取り監査で差分を洗い出します。改善点はナレッジと教育に反映します。
ステップ7：役割別ダッシュボードでモニタリングする
サービスデスク、情シス、責任者それぞれに必要な指標を表示します。CMDBと連携し、TaniumやEDRの情報も参照できると原因特定が速くなります。
6. 効果：属人化が下がり、対応が速く安定する
役割と引き継ぎが明確になると、案件は止まりにくくなります。KPIが揃うことで、改善の打ち手も見えやすくなります。ナレッジ、SOP、教育が回り始めると、担当が替わっても品質は保たれます。結果として、属人化が下がり、ServiceNow運用は安定していきます。
7. 結論：定着は「仕組み」で回す
「情シス頼み」から抜け出す近道は、役割設計、KPI、SLA/OLA、ナレッジ、教育、SOP、モニタリングを一本で回すことです。どれか一つだけでは効きにくく、連動して初めて力を発揮します。
今日決めたことが、明日も同じように回る。その当たり前を仕組みで支えることが、定着への近道です。
8. まず始めるチェックリスト
- RACIを作り、一次対応・判断・承認・レビューの役割と引き継ぎ条件を明記する
- KPIを「応答・解決・再発」の3系統で定義し、ダッシュボードに載せる
- SLA/OLAを数値・手順・責任まで書き、ワークフローに組み込む
- ナレッジの作成・レビュー・再利用の流れを定め、再利用率を追う
- 教育はオンボーディング＋ロール別の短いコースで回す
- SOPに版管理と月次の簡易監査を付ける
- CMDB連携の役割別ダッシュボードを整え、Tanium/EDRの情報も参照する
