ServiceNowのContinual Improvement Management（CIM）の運用設計書 - 役割・体制・レビュー

改善活動の仕組みを入れても、数か月で更新が止まる。よくある展開です。原因の多くは機能不足ではなく設計の欠落にあります。誰が申請し、誰が承認し、どの頻度で効果を見直すかが決まっていません。ServiceNowのContinual Improvement Management（CIM）には4つのロールと9つの状態が用意されていて、そこから運用の骨格を読み取れます。実機の構造をもとに、目的・体制・プロセス・サービス・実施項目・モニタリングまで一気通貫で組み立てました。

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

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

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

• ③CIMとは何か：何を管理して誰に効くのか

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

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

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

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

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

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

どの組織でも行う改善活動は「誰も困らない仕事」ゆえ止まりやすい。それをサポートするのがCIMプラグイン

Incidentのような障害対応は、放っておいても電話とメールが鳴るので回ります。改善活動はそうではありません。今日やらなくても誰も困らず、明日に延ばしても叱られない。どの組織にもある仕事なのに、締切を外から与えられないという一点で、他のITSMプロセスとは性質が違います。だから優先度が下がり、担当者が異動し、いつのまにか止まります。

Continual Improvement Management（CIM）は、この止まりやすさを製品側からサポートするためのプラグインです。改善案1件ごとに担当と目標値を持たせ、受理・評価・承認という手番を踏ませ、状態が動かないレコードは一覧に残り続けます。放置を仕組みで見えるようにして、誰かが必ず見届ける状態を作るのがCIMの役割です。

ただし機能を入れただけでは回りません。誰が事務局を担い、どの頻度で棚卸しするかは人が決める必要があります。同じ構造は他のITSMプロセスでも変わらず、インシデント運用設計書では状態モデルと通知の設計を先に決めることで、担当者任せの運用から抜け出す型を示しました。CIMについてそれを組み立てたのが、この記事です。

CIMは何のための仕組みか：4ロール・9状態が示す活用方針

CIMの画面と設定を実機で読むと、製品側が想定している運用の形が見えてきます。ロールは申請者・事務局・マネージャー・管理者の4階層に分かれ、状態は受理・評価・承認を別々に区切る9段階です。通知は7件すべてが有効で、誰が何を待っているかを常に知らせる作りになっています。

この構造から逆算すると、CIMを導入する狙いは「改善案を思いつきで終わらせず、受理・評価・承認・効果測定という手番を踏ませて、誰かが必ず見届ける状態にすること」だと読み取れます。全社に開放した受付口と、絞り込んだ承認権限をセットで用意しているのが、この製品の活用方針の骨格です。

運用責任者が導入前に決める4つの論点

CIMを導入すると決めたとき、プロセスオーナーが最初に悩むのは機能の使い方ではありません。次の4つです。

誰に申請させるか。 全社員に開放するのか、特定の部門に絞るのか。

誰が受理と却下を判断するか。 出てきた案を誰がふるいにかけるか。

どの頻度でレビューするか。 月次なのか、四半期なのか、そもそも会議体を作るのか。

形骸化したときにどう手を打つか。 3か月で更新が止まる状態を、どう防ぐか。

これらの答えは、ServiceNowの画面のどこにも「正解」として書かれていません。ただし製品が用意しているロール構成や状態遷移からは、設計者が何を想定していたかを逆算できます。以降はその読み取りをもとに、体制・プロセス・サービス・実施項目・モニタリングの順に組み立てます。

この記事が扱う範囲：手順書・開発設計書とは何が違うのか

CIMを導入すると決めたあと、現場に配る資料は複数あります。「操作手順書」はボタンの押し方、「開発設計書」はテーブルやスクリプトをどう作り込むかを扱います。この記事はそのどちらでもありません。「誰が」「どのくらいの頻度で」「何を見て」判断するかという、運用体制そのものの設計を扱います。

この3種類を分ける考え方は、CIM以外の既存プロセスでも共通です。問題管理（Problem）運用設計書や変更管理（Change）運用設計書も、テーブル定義ではなく状態モデルとRACIをもとに運用の型を組み立てています。読む人も使う場面も違うので、分けて作るほうが機能します。

運用体制設計：ServiceNowの4ロールと、承認グループ・レビュー会をどう組むか

CIMを導入すると、画面の裏には4つのロールが増えます。ただし体制を設計するときは、ロール単体ではなく「誰が誰に何を渡すか」という関係で見るほうが分かりやすくなります。体制図で全体像を示したうえで、各役割を順に説明する構成にしました。

体制図：改善推進責任者・事務局・申請者・管理者に、承認グループとレビュー会を加える

図の起点は複数部門にまたがる申請者で、事務局へ改善案を届けます。事務局は受理と評価を自分の持ち場でこなし、承認だけを承認グループへ依頼します。承認グループはロールではなく、Flowの承認アクションに設定する宛先の集まりです（詳しくは有料部で扱います）。承認が下りると事務局が実行を進め、効果をプロセスオーナー（改善を推進する責任者）へ報告します。プロセスオーナーは月次の改善レビュー会にも事務局とともに出席し、全体の方針を決めます。システム管理者はこの流れに直接は登場せず、ロール付与や通知設定を事前に整える役目です。この記事では以降、この役割を「マネージャー」（sn_cim.improvement_managerのロール名）と表記します。

4ロールの公式説明を実機で確認する

CIMを導入すると増えるロールは4つです。名前と公式の説明文を実機で確認しました。

sn_cim.improvement_requester の公式説明です。

新規登録はできるが、他人のレコードは編集できず、ダッシュボードも見えません。

sn_cim.improvement_coordinator の公式説明です。

自分が担当する範囲に限定した権限です。この「their assigned」という限定が、事務局を1人に集約せず、部門ごとに分散配置する設計を後押ししています。

sn_cim.improvement_manager の公式説明です。

全レコードへの権限に加えて pa_power_user が付帯しており、Performance Analytics側の設定にも関与できます。

sn_cim.admin の公式説明です。

設定モジュールへのアクセスに絞られています。

この4段階の存在自体が、製品が「事務局のいる運用」を想定している証拠です。申請と承認の間に「事務局が担当分だけを見る」という中間層を用意しているのは、1人のマネージャーが全件を裁く運用を最初から想定していないからです。承認グループと改善レビュー会という2つの集まる場も含め、役割ごとの実務内容・想定人数・兼任の可否まで踏み込んだ整理は、有料部の役割定義表で扱います。

運用プロセス設計：Newから Closedまで、誰が判断し誰に渡すか

改善イニシアチブの状態は実機で9個確認できました。単なる進捗表示ではなく、誰の手番かを示す設計になっています。

New は誰でも作れます。Accepted と Assess は事務局が担当する段階です。Approved はマネージャーの手番に切り替わり、ここで初めて承認権限が要求されます。In Progress は実行担当者、Monitor/Review は再び事務局とマネージャーの手番に戻り、効果を確認してから Closed に進みます。

受理・評価・承認が別々の状態になっている点が運用設計上の要点です。改善案は現場から多く出るが、全部は実行できません。この3段階を踏ませることで、どこで絞り込んだかを記録に残す設計になっています。

各段階で「誰が判断し、何を入力し、次に誰へ渡すか」を、確認できたフィールド名をもとに整理すると次のようになります（判断者の割り当ては状態モデルとロール権限からの設計提案です）。

• New：判断なし。申請者が課題の概要と期待効果を入力し、事務局へ渡す

• Accepted：事務局が受理か却下かを判断する。重複がないか確認したうえで、自分自身のAssessへ進める

• Assess：事務局が着手優先度を評価する。Base value・Target value・Effort estimateを入力し、マネージャーへ承認を依頼する

• Approved：マネージャーが実行可否を承認する。承認コメントを残し、実行担当者のIn Progressへ渡す

• In Progress：実行担当者が日々の進め方を判断する。タスクの進捗を入力し、完了したら事務局のMonitor/Reviewへ渡す

• Monitor/Review：事務局とマネージャーが効果を確認する。実績値とTarget review dateを更新し、マネージャーのClosed判断へ渡す

• Closed：マネージャーが完了と認定する。Closure codeを入力して終える。次の手番はなく、報告だけが残る

分岐はOn HoldとCanceledの2つ

どの段階からでも On Hold と Canceled に分岐できます。優先度が下がった案件を無理に進めさせず、いったん止める・打ち切るという選択肢を常に持たせている設計です。運用ルールとしては、この分岐を「使ってよい逃げ道」として最初から周知しておくほうが、無理に完了させて数字だけ整える事態を防げます。

承認は1本のFlowに集約されている

Approved状態への遷移を支える自動化を確認すると、CIM Approval Workflow というFlowが1件だけ有効になっていました。

Accessible From は全アプリケーションスコープ、Active は true です。承認の経路が1本に集約されているということは、誰かが不在のときに承認が止まるリスクも1点に集約されているということです。標準の仕組みには代理承認や委任の設定は含まれていないため、運用ルールとして別途決めておく必要があります。この論点は承認（Approval）運用設計書でも扱った、承認プロセス全般に共通する弱点です。

購入すると何が手に入るか

ここまでで、CIMが持つロール・状態・通知・画面の構造を確認しました。ただしこれらはあくまで製品が用意した部品です。部品をどう組み合わせて、自社の運用として回すかは別の設計が要ります。

有料部には、運用体制・運用サービス・実施項目・モニタリングの4層で、次を成果物として収めています。

• 役割定義表（兼任の可否つき）：4ロールを権限・実務内容・想定人数・兼任できるかどうかで整理した表

• 運用サービス一覧表：改善活動を6つのサービスに分解し、提供先と提供内容を整理した表。4ロールの受け渡しを示すシーケンス図つき

• 運用カレンダーとレビュー会のアジェンダ：日次〜四半期の実施項目を、誰が・何を・どの画面で行うかまで具体化した資料

• モニタリング設計表：放置や滞留のサインを、どの画面・どの頻度で監視するかを整理した表

• 形骸化させないための失敗パターンと対策：5つの典型的な躓きを整理しました

表だけで6点、図1点を添えています。いずれもこの記事で確認した実機の構造を根拠に組み立てた設計案です。テンプレートとしてそのまま自社の運用ルールの叩き台に使える分量にしています。