変更管理モジュールの開発設計書

変更管理の開発設計書は、OOTBにそろっている標準のChange Model・リスク判定・コンフリクト検知を出発点として使えます。設計の大半は「どれをそのまま使い、どれを変えるか」の記述です。この記事は、Australia の PDI の構成を前提とした開発設計書のサンプルで、目次構成と記述の粒度をそのまま自社の設計書に流用できる形にしています。

本書に含む章

• 変更管理の開発設計書に必要な章立てと、各章の記述粒度

• OOTB を採用するか変更するかの判断基準

• 設計書に残すべきパラメータの一覧、移送と検証の計画

本記事で扱う内容

• 設計書の中心は新規開発の記述ではなく、標準機能の採否と変更点の記録

• type（4値）と chg_model（6件）の対応、risk_conditions が担うリスク判定を、名前が紛らわしい別機構（dl_risk_value）と区別して扱う方法

設計書の章立て

ServiceNow のモジュール設計書は、次の構成とする。

章内容主な記述1本書の目的と適用範囲対象モジュール・対象環境・読者2前提条件バージョン・プラグイン・既存資産3システム構成テーブル構成と関連する定義の全体像4OOTB実装設計標準機能の採否を判断する順序5データ設計テーブル・項目・選択肢・既定値6画面設計フォーム・UIポリシー・クライアントスクリプト7権限設計ロール・ACL8処理設計ビジネスルール・実行順序9通知設計通知定義・宛先・イベント10SLA設計期限・スケジュール・計測条件11外部連携設計他モジュール・外部システムとの接続12移送設計更新セットの単位・移送対象外の作業13制約事項と留意点アップグレードの影響・既知の課題14検証計画単体・結合の確認項目15用語定義本書で使う用語

このうち3章と4章に、ServiceNow 特有の内容を置く。標準機能が大量に用意されているため、「何を作るか」より先に「何を使うか」を決める必要がある。

5章以降の各設計章も、記述の中心を変更点に置く。標準のまま使う部分は「標準を採用する」と1行で記載し、変更する部分に紙面を割く。

第1章：本書の目的と適用範囲

本書は、ServiceNow の変更管理モジュールを自社向けに構築するための設計を定める。

対象読者は、設計を担当する技術者とレビューを行う責任者とする。運用の体制・役割・判断基準は、別途の運用設計書で定める。

適用範囲は change_request テーブルと change_task テーブル、および CAB・リスク評価・コンフリクト検知を含む紐づく設定とする。インシデント管理・問題管理そのものの設計は含まない。連携する部分のみ第11章に記載する。

第2章：前提条件

項目内容対象バージョンAustraliaベースとする状態OOTB（プラグイン追加・カスタマイズなし）アプリケーションスコープGlobal（cab_meeting のみ CAB Workbench 専用スコープアプリ）主テーブルchange_request（task を継承）作業タスクchange_task（change_request ではなく task を直接継承）

有効なプラグイン（主要なもの）

com.snc.change_request／com.snc.change_management（foundation・change_model・flows含む）／com.snc.change_management.cab（CAB Workbench）／com.snc.bestpractice.change_risk（Risk Calculator）。

com.snc.change.collision（Collision Detector）／com.snc.change_management.standard_change_catalog／com.glideapp.workflow_change_management（旧classic workflow、Flow Designer版と併存）。

無効なプラグイン

com.snc.change_management.risk_assessment（質問票方式のリスク評価）／.ml 系（Predictive／Risk Intelligence）／.change_success_score／.success_probability／.mass_update_ci／PA拡張系

本環境で実体を持たない項目

incident.rfc は sys_dictionary にも REST API のフィールド一覧にも存在しない。ACL 1件とプロパティ2件に項目名の記述が残るのみで、機能する連携経路としては採用しない（連携方式は第11章）。プラグイン構成が異なる環境では件数が変わるため、本書を他環境へ流用する場合は第3章の件数を再計測する。

確認済みのOOTB構成：本章のプラグイン一覧・件数は、この設計を成立させる前提条件のみを記載する。フィールド定義・ACL・ビジネスルールの詳細な実測根拠は基本設定にまとめ、本書は採否と推奨値の記述に専念する。

第3章：システム構成

3-1. 設計方針

1. 実装を、データ・画面・権限・処理・期限と通知・設定値の6層構造で構成する。層の並びは保存時の処理順序（画面制御→権限判定→処理補正→期限通知の起動）に対応させ、設定値層は処理層・通知層の挙動を外部から変更できる独立した位置に置く

2. 各層は総数と変更対象数を対で記述し、変更内容は ACL 121件（追加3・変更2・据置116） の形式で1行に集約する

3-2. 設計図

保存の流れに沿って層が重なる構造とする。画面層が入力を制御し、権限層が書き込みを判定し、処理層が値の補正とModel適用を行い、期限と通知の層が後続を動かす。設定値の層は処理層と通知層の挙動を外から変える位置に独立させる。

3-3. 設計項目

確認済みのOOTB構成と推奨するあるべき姿：層ごとの対象・OOTBの件数に加え、推奨方針・変更条件・設計成果物・担当者・検証方法を1枚の索引として持つ。詳細な決定内容は各設計成果物（第5〜13章）の節を正本とし、本表はそこへの入口として使う。

層総数本設計での扱いデータ（フィールド）118（change_request 110＋change_task 8）追加なし。選択肢と既定値の一部を変更画面（UIポリシー・スクリプト・UIアクション・データポリシー）94標準を採用。追加は第6章の基準に従う権限（ACL）121（change_request 72＋change_task 49）標準を採用。追加はフィールド単位処理（ビジネスルール）100（change_request 81＋change_task 19・有効のみ）標準を採用。追加は専用のorder帯期限と通知（SLA・通知）16（SLA 0＋通知16）設計例：第10章で新規に3件定義する。通知はevent_name1件を調整設定値（プロパティ）78コンフリクト検知2件・複製属性の対象項目を見直す（第5章5-4）合計527—

3-4. 詳細設計

件数は工数の見積もりに直結する。ACL 3件の変更と30件の変更では、設計・実装・検証のいずれも規模が一桁違う。本設計では、6層の総数（118／94／121／100／16／78、合計527）を変更規模の共有基準として採用する。上表の各行は、対象ごとの推奨方針（標準採用か変更か）・変更条件（いつ変更するか）・設計成果物（詳細を記載した章）・担当者・検証方法を持つ。したがって本表を読めば、変更対象の特定から担当割り当てまでを1枚で追える。

計測はテーブル単位で行う方式を採用する。データ層は sys_dictionary、権限層は sys_security_acl、処理層は sys_script を対象に、nameSTARTSWITH<table> によるテーブル単位の集計で再計測できる構成とする（nameLIKEchange は "changed" を含む無関係テーブルまで拾うため採らない。再計測用URLは付録に記載）。

定義とレコードの分離

本環境のデモデータは change_request が106件、change_task が10件である。定義件数とレコード件数は別の実測対象であり、6層の定義件数（118／94／121／100／16／78）はレコード件数の多寡と無関係に確定する。したがって本設計書では、検証環境のレコード件数によらず、この表の定義件数を工数見積りの基準として扱う。

• 参考：ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む … データ層の確認方法

• 参考：辞書オーバーライド：継承フィールドを子だけ上書き … change_request 4件・change_task 3件の上書きの仕組み

第4章：OOTB実装設計

4-1. 設計方針

1. 変更管理の実装は、リスク判定・標準変更の運用・日程重複検知・無許可変更対応のいずれも、標準機能をそのまま使う段階（後述の段階1）で要件を満たす構成とする。追加のプラグイン有効化や独自スクリプトの追加は行わない

2. 各要件の採否は、要件・採用した方法・不採用案・理由の4項目で記録し、アップグレード時に置き換え候補の標準機能と照合できる形で保持する

4-2. 設計図

下の段階へ進むほど保守の負担が増える構造とする。独自実装はアップグレード時の再検証が必要になるため、最後の選択肢に位置づける。

4-3. 設計項目

採否判断は次の4段階の枠組みで行う。

段階実現手段保守の負担1. 標準のままOOTB の機能・定義なし2. 設定変更プロパティ・選択肢・UIポリシー小。設定値の記録のみ3. 標準の拡張点ビジネスルール・スクリプトの追加中。アップグレード時に動作確認4. 独自実装独自テーブル・独自画面大。アップグレード時に再検証

4-4. 詳細設計

推奨するあるべき姿：4つの主要要件は、いずれも段階1（標準のまま）で充足する構成とし、次のとおり採否を記録する。

要件採用した方法不採用案理由変更のリスクを自動判定したい標準の risk_conditions（4件）＋ RiskCalculator（段階1）Risk Assessment questionnaireプラグインの有効化4件の条件定義で判定できる範囲であり、質問票運用の追加コストが生じないため標準的な変更を都度承認なしで通したいchg_model=Standard ＋ std_change_producer_version のテンプレート化（段階1）Normal Changeを個別に承認除外するスクリプトの追加標準変更カタログの仕組みが承認省略のパターンをすでに提供するため変更日程の重複を検知したいConflict Detection（段階1）＋担当者重複チェックの有効化（段階2）独自の重複チェックスクリプトの追加同一CI・ブラックアウト・メンテナンスウィンドウの主要チェックが標準で有効なため無許可の変更を検知後に事後承認へ回したいtype=emergency＋unauthorized=true のフラグ合成＋標準フロー（段階1）独自のUnauthorized Changeテーブルの追加標準のモデルとフローがすでに用意されているため

拡張時の決まり

• 新規要件は「標準のまま→設定変更→標準の拡張点→独自実装」の順に検討し、上の段階で満たせないことを確認してから次の段階へ進む

• 判断の記録は、アップグレード時の判断材料として使う。新しいバージョンで置き換え候補の標準機能が追加された場合、この記録の「不採用案」欄と照合する

• 参考：変更の流れを決める Change Model（chg_model） … 段階1で採用する標準機構の詳細

• 参考：変更管理モジュールのテーブル・フィールド構成 … type別の承認経路の基礎

この記事の有料部で得られるもの

ここまでで、設計書の章立てと基本方針の書き方が分かります。有料部では、5章から15章までの記述サンプルを載せます。

• 第5章 データ設計：パラメータ14項目の設計例（category分類・cab_required判定条件を含む）と CHG0000076 の記入例

• 第7章 権限設計：type書き込みACLの二重ロック（script ACL＋role=nobody）の実装分析

• 第10章 SLA設計：Normal/Emergency 3件のSLA設計例（期限・一時停止条件・通知先）

• 第11章 外部連携設計：incident.rfcの実体不在と、problem.rfc経由の連携設計

• 第14章 検証計画：前提ユーザー・入力値・操作・期待結果を持つテストケース11件

自社の要件を埋めれば、そのまま開発設計書として使える記述にしています。

💰 ここから先は有料エリア