ServiceNowのCIM（継続的改善管理）とは何か？ 何を管理して誰に効くのかを実機で読む

「改善活動をやろう」と決めても、Excel に一覧を作って半年で更新が止まる。よくある展開です。ServiceNow には Continual Improvement Management（CIM）という専用の仕組みがあります。改善案1件ごとに KPI と目標値を持たせ、効果が出たかどうかまで追う設計でした。何を管理する仕組みで、誰に効くのかを実機で確かめます。

CIM とは：Continual Improvement Management（継続的改善管理）の略です。ITIL でいう継続的改善を ServiceNow 上で回すためのアプリケーションで、改善案を1件ずつレコードにし、KPI と目標値を付けて、効果が出たかどうかまで追います。プラグイン com.sn_cim を有効化すると使えるようになります。

CIMシリーズ（全9本） — 導入から設計・運用・トラブルまで通しで書いています。

• ①導入手順：CIMプラグインを入れる

• ②影響調査：プラグインを入れると何が変わるか（27か所）

• ③CIMとは何か：何を管理して誰に効くのか（この記事）

• ④最初の設定：プロパティ・ロール・承認

• ⑤運用手順：改善を1件流す（有料100円）

• ⑥開発設計書：テーブル・ロール・状態・自動化・UI（有料300円）

• ⑦運用設計書：役割・体制・レビュー（有料300円）

• ⑧連携：IncidentやProblemとどうつながるか

• ⑨トラブル：つまずく7つの点と直し方

結論：CIMは「改善案を、KPIと目標値つきのタスクとして管理する」仕組み

改善活動が続かない理由は、たいてい2つです。何をどれだけ良くするのかが曖昧で、やりっぱなしで効果を確認しない。

CIM はこの2つを構造で防ぎます。改善イニシアチブ1件に対して、良くしたい KPI を1つ指定し、現在値（Base value）と目標値（Target value）を入れる。そして Monitor/Review という状態がライフサイクルに組み込まれていて、完了の前に効果を見る段階を必ず通ります。

実装としては「計画タスク（Planned task）を継承した、KPI 付きのタスク」でした。

改善活動に本来ほしいもの

ITIL でいう継続的改善は、多くの組織が「やったほうがいいのは分かっている」領域です。ところが実務では続きません。

改善案を集める箱がない。 現場が気づいたことは、雑談やインシデントのコメント欄に埋もれます。

優先順位がつけられない。 集めても、どれから手を付けるかを決める基準がない。

効果が分からない。 やった気にはなるが、本当に良くなったのかを誰も測らない。

だから改善活動には最低限これがほしい、という要素が見えてきます。改善案を1件ずつ記録する場所。何をどれだけ良くするのかの目標。担当と期限。そして効果を確認する段取り。この4つが揃わないと続きません。

CIM がこの4つをどう持っているかを、以降で見ていきます。

似た仕組みとの位置づけ

ServiceNow には「何かを良くする」ための仕組みが複数あります。混同しやすいので先に整理します。

Problem 管理は「起きてしまった障害の根本原因」を扱います。 インシデントが発生したことが前提で、原因を取り除いたら終わりです。違いはServiceNow 問題管理（Problem）完全ガイド：IncidentとProblemの違いにまとめました。

変更管理は「決まった変更を安全に通す」仕組みです。 何をするかは既に決まっていて、リスクを評価して実施します。

CIM は「まだ問題になっていないが、良くできるところ」を扱います。 障害が起きていなくても、遅い・手間がかかる・満足度が低いという状態を改善対象にします。

決定的な違いが継承元に出ていました。Problem と変更は Task を継承していますが、CIM は Planned task を継承しています。

Planned task は開始日・終了日・進捗率を持つ、計画的な作業のための基盤です。つまり CIM は「対応するもの」ではなく「計画して進めるもの」として設計されています。プロジェクト管理と同じ土台に乗っているわけです。この違いが、後で見るフィールド構成にそのまま現れます。

ServiceNow自身の説明を読む

Application Manager でプラグインを開くと、製品側の Key Features が5つ挙がっていました。

2つ目が設計思想をよく表しています。 「日常使っているアプリで改善の機会を作り、CIM のレコードに自動変換する」。改善専用の画面を新しく覚えさせる作りにはしていません。既存の業務画面から拾うという考え方です。

3つ目の「期待値と実績を比較する」も、効果測定を前提にしていることを示しています。

プラグインの導入手順そのものは別記事で扱います。

Workbench が入口になる

CIM を開くと、まず Continual Improvement Workbench が出ます。

上部に Work In Progress として、進行中の改善がカード形式で並びます。1枚ごとに進捗率・担当者・優先度・期限が出ていて、Overdue（期限超過）や On Hold（保留）、Complete のバッジが付きます。

その下が Under Review。ここが CIM らしいところで、Base value（現在値）と Target value（目標値）、Target review date（効果を見る日）が列として並んでいます。一覧の時点で「何をどれだけ良くするのか」が見える作りです。

右上には Create Improvement、View Benchmarks、Go to Process Optimization の導線があります。

タブは Overview と Planning の2つ。改善の状況を見る画面と、計画を立てる画面が分かれています。

Workbench から外部の画面へ2本の導線がある

右上の View Benchmarks と Go to Process Optimization は、どちらも CIM の外に出るリンクです。

Benchmarks は自社の指標を他社の平均と比べる仕組みです。「うちのインシデント解決時間は業界平均と比べてどうか」を見て、改善対象を決める入口になります。ただしこれはオプトインが必要で、設定しないと数字が出ません。実際に開いて確かめた結果はBenchmarks（/benchmarks）を開いてもKPIは出ないに書きました。

Process Optimization は業務プロセスの実際の流れを分析する機能です。どこで手戻りが起きているかを見つけて、改善のネタにする。

つまり CIM は「改善の種を外から拾ってくる導線」を2本持っている設計です。改善案が思いつかない、という状態を想定していることが分かります。

ライフサイクルに「効果を見る」段階がある

改善イニシアチブの状態を実機で数えると、9つありました。

New → Accepted → Assess → Approved → In Progress → Monitor/Review → Closed。例外として On Hold と Canceled。

注目すべきは Monitor/Review です。 実行が終わってすぐ完了にはできません。効果を観察する段階が状態として存在します。

前半の Accepted → Assess → Approved も特徴的です。受理・評価・承認が別々の状態になっている。「出された改善案を受け取る」「やる価値があるか評価する」「実施を承認する」を分けて管理する設計です。

改善案は現場から数多く出るが、全部はやれない。だから評価と承認の段階を明示的に置いて、絞り込みを可視化するという意図が読めます。

実行はタスクに分解する

改善イニシアチブの下には CIM Task がぶら下がります。

タスク側の状態は Pending → Open → Work in Progress → Closed Complete / Closed Incomplete / Closed Skipped、それに On Hold。

完了の種類が3つあるのが実務的です。やり切った（Complete）、途中で終わった（Incomplete）、やらなかった（Skipped）を区別できます。改善活動では「やってみたが効果がなかったのでやめた」が普通に起きるので、この区別は後から振り返るときに効きます。

デモデータでは、改善イニシアチブ30件に対して CIM Task が70件でした。1件あたり2〜3タスクという粒度です。

KPIと目標値を持つのがCIMの核心

フィールド構成を見ると、この仕組みの狙いがはっきりします。

Improvement KPI は Performance Analytics のインジケータを参照します。改善対象の指標を、既存の測定の仕組みから選ぶわけです。自由記述ではありません。インジケータの仕組みはServiceNowのインジケータは履歴をどう持つ？にまとめました。

そこに Base value（現在値）と Target value（目標値）を入れ、Percentage improvement（改善率）が計算されます。「インシデントの平均解決時間を10時間から7.5時間に」という形で、改善が数字になります。

Impacted KPIs という別テーブルもあり、1つの改善が複数の指標に影響する場合を扱えます。

Strategies は経営目標への紐づけ、Business process は対象業務、Survey & Assessment はアンケートによる効果測定。改善を「上位の目標」と「測定手段」の両方に結びつける構造です。

Source Table と Source の組み合わせも重要で、どのレコードから起票されたかを任意のテーブルに対して持てます。ここが他モジュール連携の入口になります。

改善の種はどこから来るのか

Source Table と Source の2フィールドが、CIM の入口を決めています。

Source Table はテーブル名を入れるフィールドで、Source は document_id 型です。この型は「どのテーブルの、どのレコードか」を1組で持てるもので、参照先のテーブルが固定されません。

つまり Incident からでも、Problem からでも、アンケート結果からでも、同じ仕組みで起票できます。実際に「Create Improvement Initiative」という UI アクションが task テーブルに用意されていて、Task を継承するテーブルすべてから改善を作れる状態でした。Incident・Problem・Change・カタログタスクが全部対象です。

デモデータの短い説明を見ると、この設計が生きています。

• Event Management: The number of alerts from A…

• Survey Results: Customers are unhappy about th…

• Knowledge Improvement: Knowledge data does …

• Incident: Reduce the Incident backlog by 25% before Q2

先頭に出どころが書かれているのが分かります。イベント管理、アンケート結果、ナレッジ、インシデント。改善の種が業務のあちこちから来ることを、デモデータ自体が示しています。

誰に効くのか

実機の構造から、この仕組みが向く組織と役割が見えてきます。

すでに KPI を測っている組織に効きます。Improvement KPI がインジケータ参照である以上、測定の仕組みがない状態では目標値を入れられません。Performance Analytics でスコアを溜めているなら、その上に改善活動を載せられます。逆に何も測っていない組織が CIM から始めると、空欄だらけのフォームになります。

改善案が現場から出てくる組織に効きます。Source Table の仕組みは、日常業務のレコードから改善を起票する前提です。改善案がそもそも出てこない組織では、箱だけ用意しても埋まりません。

役割としては、増えたロールが4階層で用意されていました。

申請者を広く、管理者を狭く配るのが想定される形です。改善案は数が出ないと選べないので、出す側の間口は広げる。逆に承認と設定は絞る。ロールの配り方はServiceNowの権限は誰が持っている？が参考になります。

この4階層があるということは、製品が「事務局のいる運用」を想定しているということでもあります。調整担当（coordinator）という役割をわざわざ分けているので、案を集めて整理する人が要る前提です。1人で片手間に回す想定にはなっていません。

ナビゲーションの構成から使い方が読める

ナビゲータに増えたモジュールは17個でした。

並び順にそのまま意味があります。Workbench → Enterprise Strategies → Create New → Assigned to me → Open → Under Review → Closed → My CIM Initiatives → CIM Tasks → CIM Phases → Watched CIM Initiatives → All。

Under Review が独立したメニューになっているのが目を引きます。効果検証待ちの改善だけを見る画面が、標準で用意されている。やりっぱなしを防ぐ仕掛けです。

Watched CIM Initiatives（ウォッチ中）もあり、自分の担当ではないが気にしている改善を追えます。

管理側には Spotlight Config、Properties、Guided Setup が並びます。Guided Setup があるということは、設定手順が製品側に用意されているということです。

手順書と設計書は別に要る

CIM を導入すると決めたあと、現場に配るものが2種類あります。

操作手順書は「どのボタンを押すか」。改善イニシアチブをどう作り、どう進め、どこで完了にするか。

運用設計書は「誰が何をするか」。誰が申請でき、誰が承認し、どの頻度でレビューするか。

この2つは読む人も使う場面も違うので、分けて作るほうが機能します。既存プロセスでも同じ構成にしていて、問題管理なら問題管理（Problem）運用手順書と問題管理（Problem）運用設計書に分けました。

CIM の場合、運用設計書のほうが重くなります。改善活動は「やらなくても誰も困らない」業務なので、回す仕組みを設計しないと止まるからです。承認の有無、レビューの頻度、案が出ないときの対処。ここを決めずに箱だけ作ると、3か月で更新が止まります。

実機を見て気づいたこと

継承元が Task ではなく Planned task だった

これが CIM の性格を決めています。Incident や Problem のような「発生したら対応する」型ではありません。計画して、期間を決めて、進捗率で管理する型です。

だから開始日・終了日・進捗率が最初から入っていて、プロジェクト管理のテーブル群が一緒に入ってきます。改善活動をプロジェクトとして扱うという思想です。

導入すると project_manager などのロールまで付いてくる理由も、ここにあります。

状態の設計が「絞り込み」を前提にしている

Accepted Assess Approved の3段階は、裏を返せば「受理したが、やらない改善がある」ことを前提にしています。

改善案を全部やる組織なら、この3段階は無駄です。実際には出てきた案の大半は着手されないので、どこで落としたかを記録に残す設計になっている。承認プロセスの有無はプロパティで切り替えられます。

Workbench が一覧ではなくカードだった

改善イニシアチブの一覧はリスト表示もできますが、標準の入口はカード形式の Workbench です。

進捗率と期限とバッジで、放置されている改善が視覚的に浮き上がる作りになっています。デモデータでも Overdue が2件、On Hold が1件、赤とグレーで目立っていました。改善活動は放置されやすいので、この見せ方は理にかなっています。

実務では何に使えるか

改善案の置き場所を1つに決める

Excel や議事録に散っている改善案を、レコードとして集める箱になります。Source Table があるので、どのインシデントから出た改善かを辿れます。

目標値を入れる文化を作る

Base value と Target value が必須に近い形で並んでいるので、「何をどれだけ」を書かないと登録が進みません。これは制約ではなく、改善活動の質を上げる仕掛けです。

効果検証の会議体を設計する

Under Review のメニューと Target review date があるので、「今月レビューすべき改善」の一覧が自動で作れます。月次の改善レビュー会の議題を、この画面から出せます。

小さく始めて、レビューを1回まわす

いきなり全社展開すると、たいてい形だけになります。1チーム・改善3件から始めて、Monitor/Review まで1周させるのが現実的です。

1周させると、目標値の置き方が難しいこと、効果測定に必要なデータが揃っていないこと、レビューの場が要ることが分かります。この3つは机上では見えません。

測定の仕組みを先に用意する

CIM を入れる前に、Performance Analytics でインジケータを持っているかを確認してください。測っていない指標は改善対象に選べません。分析基盤の状態を見る方法はServiceNowの標準ダッシュボード28本を全部開いたで扱いました。

CIM Phases という3つ目のテーブル

ナビゲータに CIM Phases というメニューがありました。改善イニシアチブとタスクの間に、もう1階層あるということです。

プロパティにも sn_cim.create_default_phase があり、公式説明は Enable the property to create the default phase when an improvement initiative is created.（改善イニシアチブ作成時に既定のフェーズを作る）。既定値は false でした。

つまりフェーズは任意の階層です。小さな改善ならイニシアチブ直下にタスクを並べればよく、大きな改善なら「調査フェーズ」「実装フェーズ」「検証フェーズ」のように区切れる。

Parent initiative フィールドで改善そのものを親子にもできるので、大きな改善を分解する手段が2つ用意されていることになります。フェーズで区切るか、子イニシアチブに分けるか。どちらを使うかは設計判断です。

既定が false になっている点にも意味があります。製品は「まずフェーズなしで使え」と言っているわけです。階層を増やすと入力の手間が増え、改善活動そのものが面倒になる。使い始めは単純な構成にしておいて、必要になってから足す。導入時の設定判断としては、これに従うのが無難です。

用語

CIM（Continual Improvement Management）：継続的改善を管理するアプリケーション。プラグインは com.sn_cim、スコープは sn_cim。

改善イニシアチブ（sn_cim_register）：改善活動1件を表すレコード。Planned task を継承する。

CIM Task（sn_cim_task）：改善イニシアチブを実行に分解したタスク。

Improvement KPI：改善対象の指標。Performance Analytics のインジケータを参照する。

Monitor/Review：実行後に効果を確認する状態。完了の手前に置かれている。

Workbench：改善の進行状況をカード形式で見る画面。$cim-wb.do。

自分の環境で確認するときのURL

自分のインスタンス名に続けて開きます（CIM プラグインの導入が前提です）。

• Workbench：/$cim-wb.do

• 改善イニシアチブの一覧：/sn_cim_register_list.do?sysparm_query=ORDERBYnumber

• 状態別にまとめる：/sn_cim_register_list.do?sysparm_query=GROUPBYstate

• CIM Task：/sn_cim_task_list.do?sysparm_query=GROUPBYstate

• 影響を受けるKPI：/sn_cim_related_kpi_list.do

• 状態の選択肢を見る：/sys_choice_list.do?sysparm_query=name%3Dsn_cim_register%5Eelement%3Dstate%5EORDERBYsequence

• CIM のモジュール構成：/sys_app_module_list.do?sysparm_query=application.title%3DContinual%20Improvement%5EORDERBYorder

引用した公式説明を自分で開く

• Key Features：Application Manager で CIM を開くと表示されます

• テーブルの継承元（引用元）：/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsn_cim

• プラグインの説明（引用元）：/v_plugin_list.do?sysparm_query=id%3Dcom.sn_cim

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-14 に確認しました。CIM プラグインをデモデータ込みで導入した状態です。

改善イニシアチブを実際に1件作って、状態を最後まで進めてはいません。 状態の一覧とフィールド構成、デモデータの見え方を確認した範囲です。ライフサイクルを実際に流す手順は別記事で扱います。

Planning タブと View Benchmarks、Go to Process Optimization は開いていません。

承認プロセス（sn_cim.need_approval）は既定の true のままです。false にしたときの挙動は未確認です。

Performance Analytics のインジケータにスコアが溜まっていない環境なので、KPI の実績値が入った状態は見ていません。

デモデータの件数（改善イニシアチブ30件・CIM Task 70件）はこの環境の値です。本番では当然変わります。

関連記事

• ServiceNow 変更管理（Change）完全ガイド — 似た仕組みとの比較用

• ServiceNowのインジケータは履歴をどう持つ？ Data SnapshotsとCDCの除外リストを実機で読む — KPI の測定側の仕組み

• ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる — 4つのロールを配るときの前提