ServiceNowのContinual Improvement Management（CIM）の開発設計書 - テーブル・ロール・状態・自動化・UI
CIMを自社に入れると決めたあと、開発者が最初に必要になるのは設計書です。ところがOOTBのアプリケーションには、機能の説明書はあっても設計書は付属しません。この記事は、CIMのOOTB実装を設計項目ごとに読み直し、開発設計書として整理したものです。自社でCIMを導入・カスタマイズするとき、どこを標準のまま使い、どこに手を入れるかを判断する下敷きとして使えます。
検証環境：Australia PDI / OOTB / 2026-08-14 確認。CIM プラグイン（com.sn_cim v11.1.0）を導入済み。設定は変更していません
CIMシリーズ（全9本） — 導入から設計・運用・トラブルまで通しで書いています。
⑥開発設計書：テーブル・ロール・状態・自動化・UI（有料300円）（この記事）
この設計書の構成：13の設計項目
CIMの実装には、設計書の章立てにできるだけの判断が埋め込まれています。
テーブルの継承と採番
状態の数と承認の入れ方
通知の出し方と画面の出し分け
権限の階層と自動化の役割分担
テストの用意
これらの判断の土台にあるのは3つの設計方針です。改善活動を「対応するもの」ではなく「計画して進めるもの」として扱う。改善案の大半を実行の手前で絞り込む前提を置く。権限とビジネスルールを「見せない」ではなく「書かせない」方向に寄せる。この3つが、実装全体を貫いています。
判断は大きく4つの層に分かれます。
テーブルとフィールド → データを持つ層
ステータス・プロセスフロー・自動化・通知 → 状態を動かす層
ロール・セキュリティ・UI → 人に見せる・触らせる層
連携・測定・拡張性 → 外とつなぎ、測り、切り替える層
データが状態を動かし、状態が自動化と通知を呼びます。ロールとセキュリティがUIの見え方を決め、UIが状態を進めるボタンを人に押させます。拡張性設計（プロパティ）は独立した層に置かれていません。承認要否や評価対象というプロセスフローと自動化の分岐そのものを外から切り替える仕組みとして、破線でつながっています。テスト設計も4層のどこかに納まる項目ではありません。自動化とプロセスフローが崩れていないかを外側から確かめる、検証のための層として重なります。
この13項目は、まず実機の画面ですぐに確認できる状態を動かす層とUIから始め、続けて残りの3層を扱います。各項目の末尾には「実装で手を入れるならここ」を置き、自社実装で何を変えることになりやすいか、変えないほうがよい部分はどこかをまとめています。
ステータス設計：評価と承認を別の関門にするため、状態を9値に分ける
改善案を受け取ってすぐ着手できる状態にはしない。受理・評価・承認という3つの関門を、それぞれ独立した状態として持たせる。 これが sn_cim_register（Improvement Initiative）の状態設計です。
主系列は New → Accepted → Assess → Approved → In Progress → Monitor/Review → Closed の7段階で、これに On Hold と Canceled を加えると9個になります。前半3つ（Accepted / Assess / Approved）を分けているのは、出てきた改善案の大半はこの3段階のどこかで着手されずに終わるという前提があるからです。全部の案を実行する組織なら3段階は冗長ですが、実務では優先順位をつけて絞り込むほうが普通です。その絞り込みを状態遷移として可視化するために、標準は関門を3つに割っています。
状態の裏に振られた値にも設計が表れています。
正の連番（本流の4状態）：New=1 / In Progress=2 / Closed=3 / Canceled=4
負の値（挟み込まれた5状態）：Accepted=-6 / Assess=-5 / Approved=-4 / Monitor/Review=-3 / On Hold=-2
最初に用意した4状態の番号を保ったまま、あとから挟んだ状態を負の値で追加するという割り振り方だと読めますが、この経緯自体は実装から確認できる範囲を超えた推測です。同じ型はChange Request（change_request.state）にも見られます。New=-5からReview=0まで実行前の状態はすべて0以下で進み、Closed=3・Canceled=4だけが正の値です。終了状態に正の値を割り当て、そのほかの状態番号は負の側に逃がすという数値の付け方は、CIM固有ではなくプラットフォームで繰り返し使われる型です。
CIM Task（sn_cim_task）側は状態を7個に分けています。Pending → Open → Work in Progress のあと、完了をClosed Complete / Closed Incomplete / Closed Skippedの3種類に分岐させ、On Holdを例外として持たせます。やり切った・途中で終わった・やらなかったを区別して残すためです。改善イニシアチブ側の状態が絞り込みの過程を記録するのに対し、タスク側の状態は実行の結末を記録するという役割分担です。
実装で手を入れるならここ
自社の承認プロセスが3段階より細かい、あるいは粗い場合は、状態の追加・削除を検討することになります。追加するなら、New・In Progress・Closed・Canceledが持つ正の連番（1・2・3・4）は変更せず、新しい状態は負の値で挟み込んでください。 既存のレポートやスクリプトの条件式（state>0のような判定）を壊さずに済みます。逆に触らないほうがよいのは、この4つの正の値そのものです。既存の集計・ダッシュボード・スクリプトが暗黙に依存している可能性があります。
プロセスフロー設計：承認の要否をプロパティで切り替え、フェーズを2階層目に置く
承認を必須にするかどうかを個別の改善イニシアチブごとに決めさせない。インスタンス単位でプロパティ1つに切り替えを集約する。 これがCIMの承認設計です。
sn_cim.need_approval の公式説明は次のとおりです。
sn_cim.need_approval: Enables approval process for Continual Improvement initiatives.（改善イニシアチブに対する承認プロセスを有効にする）
既定値はtrue（承認あり）です。承認プロセスの実体は CIM Approval Workflow という1件のFlowで、既定で有効化されています。
承認を「画面上の状態表示が変わるだけ」で終わらせない設計も見えます。既定値のままAssessボタンを押すと、承認レコード（sysapproval_approver）が自動で1件発行され、状態はRequested（承認依頼中）になります。Approved状態へ進めるのは、この承認レコードが承認された後だけです。承認という業務行為を、標準のワークフロー機構に載せて裏側で1件発生させる作りです。
もう1つの階層設計が、改善イニシアチブとタスクの間に置かれたPhaseです。この階層のためにテーブルは増やしません。sn_cim_task に cim_task_type というフィールドを持たせ、値が 1 ならCIM Phase、2 なら実行タスクとして扱わせます。1つのテーブルに、フェーズと実行タスクの両方を兼ねさせる構造です。
フェーズを既定で作るかどうかも、プロパティで制御します。
sn_cim.create_default_phase: Enable the property to create the default phase when an improvement initiative is created.（改善イニシアチブの作成時に既定のフェーズを作成する場合に、このプロパティを有効にする）
既定値はfalseです。小さな改善はイニシアチブの下に直接タスクを並べさせ、大きな改善だけプロパティを有効化してフェーズで区切らせる。最初は小さく、必要になったら増やすという設計方針が、既定値という形で表れています。
実装で手を入れるならここ
承認プロセスを自社の稟議フローに合わせるなら、CIM Approval Workflowを複製して自社の承認者選定ロジックに差し替えるのが基本線です。need_approvalプロパティ自体は安全に切り替えられますが、falseにした場合の画面遷移の変化は自社で一周確認してください（詳細は後述の「触ると危ないものの一覧」）。フェーズを標準運用にするならcreate_default_phaseをtrueにするだけで済み、cim_task_typeのテーブル構造には手を入れる必要がありません。
通知設計：主要な区切りを7件で押さえ、評価段階だけ意図的に外す
改善活動の節目ごとに関係者へ知らせる。ただし全部の節目を等しく通知しない。 これがCIMの通知設計です。sn_cim_register と sn_cim_task を対象にした通知は7件あり、すべて有効です。
CIM approval notification：承認が依頼されたとき
CIM from new to access notification：Newから受理された（Accepted）とき
CIM close notification：Closedになったとき
CIM cancel notification：Canceledになったとき
CIM Breach Notification：Target review dateの期限超過を検知したとき
CIM task assigned notification：CIM Taskが割り当てられたとき
CIM task closed：CIM Taskが完了したとき
受理・承認依頼・完了・中止・期限超過という改善イニシアチブ側の主要な区切りと、割当・完了というタスク側の区切りを、標準はひととおり押さえています。
一方で、評価段階の通知は標準の判断で外されています。通知を発火させるイベント一覧にはAssessイベントがありますが、これを発行するビジネスルール（Assess notification event）は無効のまま出荷されています。7件の通知はすべて有効なのに、Assessへ状態が進んだときだけ通知は飛びません。評価段階まで標準で通知を有効にすると、改善案が多い組織では通知過多になりかねないという判断が働いていると考えられますが、これは実装から読み取れる解釈であり、公式な意図表明ではありません。
実装で手を入れるならここ
Assessの通知が必要な組織は、無効なAssess notification eventを有効化するだけで済みます。 イベントの仕組み自体は標準にすでに存在するため、新規のビジネスルールを書く必要はありません。宛先グループやテンプレート文面を自社向けに直すのは、7件の通知いずれについても想定内の変更です。通知の枠組み（イベント登録・通知レコードの対応関係）そのものを作り替える必要はありません。
UI設計：モジュールの並び・画面の出し分け・段階的な入力要求で、使う順番を誘導する
画面の作り方そのものに、標準の意図が表れています。 ナビゲータ・一覧画面・フォームという3つの層で、それぞれ異なる仕掛けが入っています。
モジュールの並びで、使う順番を示す
ナビゲータの Continual Improvement メニューには17個のモジュールがあり、Order列がそのまま想定する利用順序になっています。
Getting Started(70) → Workbench(90、いちばんよく使う起点) → Enterprise Strategies(100、経営目標の参照)
Create New(200、起票) → Assigned to me / Open / Under Review / Closed(300〜600、状態別の進捗ビュー)
My CIM Initiatives / CIM Tasks / CIM Phases / Watched CIM Initiatives(620〜660、個人視点のビュー) → All(700)
Administration の区切りのあとに Spotlight Config / Properties / Guided Setup(800〜850)
Under Review を Open や Closed と並ぶ独立したメニューにしているのには理由があります。Monitor/Review 状態は、評価結果を確認するという能動的な行動を伴う段階だからと読めます。Roles列も見どころです。Workbench は sn_cim.improvement_coordinator に絞り、My CIM Initiatives は sn_cim.improvement_requester に絞ります。視点別に3つのメニューを、ロールで出し分けています。
担当者視点（Assigned to me）
申請者視点（My CIM Initiatives）
関心を持つ人の視点（Watched CIM Initiatives）
一覧画面は、状態によって見せ方を切り替える
Workbench の実画面では、状態ごとに表示形式そのものが変わります。
Work In Progress はカード1枚＝1件で、進捗率・担当者・優先度・期限を並べます。期限超過には赤いOverdue、保留にはOn Hold、完了には緑のCompleteバッジを付け、放置案件を色で目立たせる作りです。一方、下段の Under Review は同じ画面でもカードではなく表です。Number・Priority・Base value・Target valueなど7列を並べます。進行中は1件ずつ状況を追うカード、レビュー待ちは複数件を数値で見比べる表という、目的別の使い分けです。
フォームは、状態を進めるたびに要求を積み増す
改善イニシアチブのフォームには、進行状況を示す状態インジケータと、Goals / Details / Schedule / Notes / Closure Notes という5つのタブがあります。
Goals タブは既定で開き、Success measurement method / Improvement KPI / Base value / Percentage improvement / Target value / Target review date / Expected outcomes という成果測定に関わる項目だけを集めています。タブのヒント文は「この改善イニシアチブの成功をどう測定するかを指定してください」の一文です。測定に関わる項目を最初のタブに独立させることで、改善活動である以上まず何を測るかを決めさせる意図が表れています。
必須項目の要求を、フィールド定義でまとめて固定しない。状態を進めるボタンを押した瞬間に、その状態へ進むために必要な項目だけを都度要求する。 これがCIMのフォーム設計です。
Acceptを押すとCIM CoordinatorとStrategiesが必須になる
Assessを押すとTarget review dateとApprover groupが必須になる
ClosedにするとAchieved outcome category（達成した成果の分類）が必須になる
Achieved outcome categoryの選択肢は次の5つです。
Customer Satisfaction（顧客満足度）
Cost Reduction（コスト削減）
Quality Improvement（品質向上）
Revenue Generation（収益向上）
Time Saving（時間短縮）
Expected outcome（期待した成果）をGoalsタブで自由記述させておきながら、閉じるときは5分類のどれかに当てはめさせる二段構えです。 自由記述だけでは複数の改善イニシアチブを横断して集計できませんが、5分類に落とし込めば「今期は品質向上系の改善が何件終わったか」を数えられます。
Closedにはもう1段厳しい出し分けもあります。配下のCIM Taskが1件でも完了していない状態では、Closeボタンそのものを表示させません。 全タスクを閉じて初めてボタンを出す。必須項目の要求に加えて、ボタンの存在自体を条件で隠すという判定です。この判定はロールアップ処理と表裏の関係にあり、自動化設計の項目で扱います。
実装で手を入れるならここ
自社の業務でモジュールの並びや視点別メニューを追加するなら、既存17モジュールのOrder値の間（例: 305・605のような値）に新しいモジュールを挿し込めば、既存の並びを崩さずに済みます。フォームのタブ構成やカード/表の切り替えロジックはUI Policyとフォームレイアウトの標準機能の範囲で調整可能です。触らないほうがよいのは、状態を進めるボタンが要求する必須項目の判定ロジックそのものです。 この判定は次の有料エリアで扱うロール別の判定関数と共有されており、書き換えると影響範囲が広がります。
ここまでの設計項目、ここから先の設計項目
ここまでで全体像・ステータス・プロセスフロー・通知・UIを扱いました。ボタンを押すとどう動くか、通知はいつ飛ぶか、フォームはどう変化するかは、この記事だけで実機の挙動が分かる状態です。
ここから先の有料エリアには、次の設計項目を用意しました。
テーブル設計・フィールド設計：5テーブルの役割分担、採番とドメイン分離の扱い、参照先を固定しない source_table / source_id の判断
ロール設計・セキュリティ設計：4階層のロールと、ACL60件が「書かせない」に偏る理由
自動化設計・テスト設計：ビジネスルール30件の役割分担と、標準が用意した30本のATFテストが無効出荷される理由
UI設計（ロール別の表示設計）：CIMUtil の条件を1件ずつ確認し、同じボタンでもロールで挙動が違う理由
連携設計：起票元と連携先テーブルを固定しないための拡張ポイントの仕組み
測定設計・拡張性設計：KPIの測定方法とプロパティによる切り替えの中身
購入すると何が手に入るか
ここから先の有料エリアには、次の3つの成果物も用意しました。
設計判断シート：9項目の判断を、標準の実装・選ぶと得られるものとセットで1枚にまとめた表です。自社の設計会議にそのまま持ち込める形にしています。
拡張ポイントの一覧：標準のままで使える部分と、自社で作り込む部分を8領域に分けた表です。「全部作り直す」でも「全部標準のまま」でもない、実装ベースの線引きです。
触ると危ないものの一覧：無効化・変更するとほかの仕組みが前提を失うビジネスルール・スクリプトインクルード・プロパティを6件、対処方法とセットで一覧にしました。
分量は9つの設計項目の解説と、表3枚、それぞれの読み方を説明する本文です。ここから先を読めば、標準のCIMを自社にそのまま入れるか、どこを変えて入れるかを、その場で判断できる材料が揃います。
💰 ここから先は有料エリア
