目次
この記事のポイント
- ServiceNowはNow Platform上のアプリ群。ITSM（ITサービス管理）から始めて ITOM・CSM へ広げられる
- インシデント（復旧）・問題（原因）・変更（統制）・要求（依頼）は目的が違う。同じ箱で扱うと統制が崩れる
- 導入効果は「チケット削減」ではなく復旧時間の短縮と変更の安全度向上で測る
- 最初に決めるのはカテゴリ・優先度・SLA の3つ。これが無いとレポートが機能しない
01WHAT ITサービスを「プロセス」として扱うための土台
ServiceNow は、IT サービスを業務プロセスとして管理するためのプラットフォーム（Now Platform）です。その上に、インシデント管理・問題管理・変更管理・サービス要求管理といったアプリが載り、共通のデータモデル（テーブル）とワークフロー（Flow Designer）を共有します。重要なのは、これらが「別々のツール」ではなく同じ構成情報（CMDB）とユーザー情報を参照する点です。誰が何を壊したか、どの変更がどの障害の原因かを追えるのは、この共通土台があるからです。
インシデント・問題・変更・要求の役割分担
4つは似て見えて目的が異なります。インシデントは「サービスを早く復旧させる」ための記録、問題は「同じ障害が再発しないよう根本原因を潰す」ための管理、変更は「本番環境を変える行為を統制する」ための承認プロセス、要求は「利用者からの依頼をカタログ化して処理する」仕組みです。復旧を優先すべき場面で原因究明の議論を始めると現場が止まるため、目的ごとに箱を分けることが重要です。
導入で実際に変わる3つのこと
効果が出るのは、①問い合わせ窓口が一本化され、進捗が利用者から見える ②優先度と SLA が定義され、重大障害の扱いが属人的でなくなる ③変更が承認フローを通るため、突発作業と障害の因果関係が追える、の3点です。逆に、カテゴリや優先度の定義が曖昧なまま導入すると「ただのチケット管理」で終わります。
補足：ITIL は「フレームワーク」、ServiceNow は「実装基盤」
ITIL はプロセスの考え方を示す指針で、製品名ではありません。ServiceNow は ITIL に沿ったプロセスを実装済みの形で提供し、自社の運用に合わせて設定できる点が特徴です。
02POINTS ITSM導入を成功させる4つの手順
- サービスカタログとカテゴリを決める。「何をサービスとして提供しているか」を一覧化し、問い合わせのカテゴリをサービスに紐づけます。ここが曖昧だと分類が属人的になります。
- 優先度とSLAを定義する。影響度（何人・どの業務が止まるか）と緊急度から優先度を決め、優先度ごとの一次応答・復旧目標時間を決めます。
- CMDBの最小範囲を決める。最初から全システムを登録せず、影響の大きい基幹系（例：SAP、認証基盤、ネットワーク）から始めます。
- レポートを運用会議で使う。未解決件数・SLA達成率・変更成功率を作り、定例会議でそのまま使います。数字が会議で使われると分類の精度が上がります。
重大障害（メジャーインシデント）は先に定義する
「いつ重大宣言するか」「誰が宣言するか」「宣言後の連絡先と更新頻度」を決めておくと、初動が速くなります。宣言基準を金額や影響人数で数値化しておくと、判断が属人的になりません。
03INSIGHT 「復旧の速さ」と「変更の安全度」を同時に上げる設計
ITSM 導入の価値は、復旧時間（MTTR）の短縮と、変更起因の障害（変更失敗率）の低減という相反しがちな2つの指標を同時に改善できる点にあります。鍵は CMDB です。「この変更はどの業務に影響するか」が構成情報から自動で見えると、承認の質が上がり、同時に障害発生時の影響範囲の特定も速くなります。
当社は SAP を中心とした基幹システムの運用支援で培った知見をもとに、ServiceNow の導入設計（カテゴリ・優先度・SLA・CMDB の最小範囲）と、SAP を含む基幹システムとの連携設計を支援します。IT 部門の運用を「見える化」して終わらせず、定例会議で使われる数字にするところまでを設計範囲としています。
導入が定着するかは、リリース後の 3 か月で決まります。この間に、カテゴリの使われ方・エスカレーションの発生理由・解決に時間を要した種別を振り返り、定義を修正します。月 1 回・1 時間の運用会議をあらかじめカレンダーに入れてしまうのが最も効果的です。会議体が無いまま始めると、半年後に「使われていないシステム」になりがちです。
豆知識：Service Portal は「利用者向けの入口」
IT 部門が使う管理画面（Now Platform）とは別に、一般利用者向けのポータル（Service Portal）を用意できます。カタログとナレッジを整えておくと、問い合わせの前に自己解決する流れが生まれます。
まとめ
- ServiceNowはITサービスをプロセスとして管理する Now Platform 上のアプリ群
- インシデント・問題・変更・要求は目的が違うため分けて設計する
- 最初に決めるのはカテゴリ・優先度・SLA。これがレポートの前提になる
- CMDBは基幹系から段階的に。変更と障害の因果を追えるようにする
- 効果はMTTR短縮と変更失敗率の低減で測る
出典・参考
- ServiceNow 公式サイト（製品・プラットフォームの一次情報） https://www.servicenow.com/jp/
- ServiceNow 製品ドキュメント（設定・データモデルの一次情報） https://docs.servicenow.com/
- ServiceNow Community（実装事例・ベストプラクティス） https://www.servicenow.com/community/
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-12）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
Excel や既存のチケットシステムでは不十分ですか？
記録はできますが、優先度・SLA・構成情報（CMDB）・変更承認が連動しないため、重大障害の判断や影響範囲の特定が属人的になります。運用の再現性が必要になった段階が導入の目安です。
導入期間の目安はどれくらいですか？
ITSM の基本プロセス（インシデント・要求・変更・ナレッジ）を1部門で運用開始するまでに数か月、全社展開と CMDB 整備を含めると半年〜1年以上を見込みます。範囲の切り方で大きく変わります。
ITSM から始めるべきですか？
多くの場合、ITSM（特にインシデントとサービス要求）から始めるのが効果的です。利用者との接点が多く効果が見えやすく、CMDB や ITOM の整備はその後段階的に進められます。
社内に専任担当は必要ですか？
カテゴリ追加・フロー修正・レポート整備を継続するため、プラットフォーム管理者とプロセスオーナーの設置を推奨します。特にプロセスオーナー（運用責任者）が不在だと、設計が現場の実態と乖離します。
ITSM と ITOM の違いは何ですか？
ITSM は「利用者からの依頼や障害にどう対応するか」というプロセスを扱い、ITOM は「監視・検知・自動復旧」といった運用そのものを扱います。ITSM で窓口とルールを整え、ITOM で検知と自動化を強化する順序が現実的です。