変更管理モジュールの運用手順書

本番に手を入れる変更には、CABの審議を経るもの、テンプレートから即日実施できるもの、障害対応で承認を後回しにするものの3種類がある。パターンによって入力する項目も承認の有無も変わる。この記事は、Normal・Standard・Emergencyそれぞれの起票からクローズまでの手順を、そのまま自社の運用手順書として使える形でまとめたものである。Australiaの PDI に実在するレコードを状態ごとに確認して作成した。

手順書に含む内容

• Normal・Standard・Emergency、3パターンそれぞれの起票からクローズまでの作業手順

• 各段階で入力する項目と記入例

• CABの承認が動く仕組みと、承認を経ない・承認を後回しにする仕組みの違い

• 3パターンのどれを選ぶかの判断基準

• 却下・保留でつまずいたときの対処

手順書として押さえること

• 3パターンともchange_request.stateの選択肢そのものは8個共通だが、実際に通過する状態の数と順序はChange Modelごとに異なる

• typeは新規作成のときにしか選べず、次の状態へ進むと変更できない

• Standardは個々の変更に承認レコードを作らない。承認はテンプレートを作る段階で完了している

• Emergencyは評価（Assess）を経ずに実施を優先し、CABの承認はAuthorize状態で事後に行う

以下の記入例・入力例は、操作を具体化するための推奨例である。対象CI・担当グループ・文言は、自社の変更内容に合わせて置き換える。

1. 本手順書の目的

変更管理の担当者が、起票から承認・実施・クローズまでの作業を、どのパターンでも迷わず同じ品質で進められるようにする。

記録の品質を保つこともこの手順書の目的である。変更の記録は、実施後の振り返りやCABの審議、障害が起きたときの原因調査に使われる。入力の粒度と判断の基準が担当者ごとにばらつくと、あとから経緯を追えなくなる。

2. 適用範囲と前提条件

2-1. 適用範囲

本手順書は、変更管理モジュールを使用する日常運用のうち、Normal・Standard・Emergencyの3パターンを対象とする。CAB Workbench（/cab）の画面操作そのものは対象外とする。

change_request と change_task はいずれも task テーブルを継承しており、Incident・Problemと共通の項目構造を持つ。継承元の項目（状態・優先度・担当者など）を先に把握しておくと、本手順書に出てくる固有項目との違いが分かりやすい。

• 参考：taskテーブル：ITSM全プロセスの共通の親 … change_requestが継承する共通項目

2-2. 前提条件

項目内容対象バージョンAustralia対象テーブルchange_request / change_task承認エンジンoff。実処理はFlow Designerが担うコンフリクト検知同一CI・ブラックアウトウィンドウ・メンテナンスウィンドウ・関連サービスは既定で有効必要なロールchange_manager（変更マネージャ）／itil（実施担当。sn_change_write を自動で継承する）／sn_change_cab.cab_manager（CAB管理）

承認エンジンが off であるため、承認の進み具合は sysapproval_approver の一覧だけでは追いきれない場面がある。Flow Designer側の実行状況もあわせて確認する。

3. 対象者と役割

役割担当する作業起票者変更内容の起票、対象CIと目的の記述変更マネージャリスク評価・実施計画の確認・CAB承認申請・日程調整・レビュー・クローズCAB承認者影響範囲を審議し、承認・却下を判断する実施担当change_task の実行、本番への適用作業

承認を申請する変更マネージャと、承認するCAB承認者を分けているのは、技術的な評価と組織としての実施可否を別の視点で確認するためである。同一人物が両方を兼ねると、この分離が働かなくなる。

4. 変更パターンの選定基準

3パターンの判断基準を先に示す。次のどれに当てはまるかで、進む手順が変わる。

事前承認済みのテンプレートに一致する定型作業はStandardを選ぶ。過去に何度も実施され、リスクが低いと分かっている作業や、事前に承認済みのテンプレートが用意されている場合が該当する。該当するテンプレートが無い場合は、Normalとして起票してから、繰り返し発生することが分かった時点でテンプレート化を検討する。

サービス停止や重大な障害の復旧など、通常のCAB開催を待つと業務影響が拡大する場合はEmergencyを選ぶ。単に急ぎたいという理由でEmergencyを選ぶと、事後のCAB審議で説明を求められる。

どちらにも当てはまらない変更はNormalを選ぶ。影響が読み切れない変更や複数チームの調整が要る変更が中心である。chg_modelのdefault_change_model=trueはNormalに設定されており、typeの選択で迷ったときの既定でもある。

実際に通過する状態の数はChange Modelごとに異なる。Normalは8個すべて、Standardは6個（Assess・Authorizeを除く）、Emergencyは7個（Assessを除く）である。

• 参考：変更管理モジュールの概要 … Standard・Normal・Emergencyの選定基準をさらに詳しく扱った記事

Normal Change の手順

Normalは、8個の状態をすべて順に通る、いちばん厚い手順である。CABの承認を経て実施するため、起票から完了まで複数の担当者が関わる。

全体像

起票からクローズまでは8つの段階で構成される。

Authorize（CAB承認待ち）に多くのレコードが滞留している実画面が確認できる。承認待ちで止まりやすいという傾向は、デモデータ固有の分布であって、どの環境でも同じ数字になるとは限らない。仕組みとして押さえるべきは、承認がそろうまでScheduledへ進めないという構造そのものである。

各段階で誰が何を入力し、どのボタンで次へ進むかを1枚にまとめた。

Change Modelが状態遷移を握る

STEP1でtype=Normalを選ぶと、chg_model（Change Model）が状態の並びとテンプレートを決める。Normalは default_change_model=true の唯一のモデルで、起票時に既定で適用される。状態の定義は sttrm_state という汎用の仕組みが担う（詳細は別記事）。

• 参考：State Transition Models（sttrm_model）：変更タイプごとに状態遷移を定義する仕組み … typeごとに状態の数と並びが変わる仕組み

承認はFlow Designerが動かす仕組み

Change Requestの承認プロパティ glide.approval_engine.change_request は off である。公式の説明は次のとおり。

（訳：承認をWorkflowで管理する場合はoffに設定する）

引用元: /sys_properties_list.do?sysparm_query=name=glide.approval_engine.change_request

承認の実処理はFlow Designerが担う。typeごとに専用のFlowがある（Change - Normal - Authorize など）。STEP3でRequest Approvalボタンを押すと、対応するFlowが承認者ごとに sysapproval_approver レコードを生成する。

実例としてCHG0000076の承認レコードを見ると、10人の承認者のうちRequestedが4人、No Longer Requiredが6人だった。

承認者は「影響を受ける領域の責任者」を基準に複数人を並列で登録する。議題を管理する画面はCAB Workbench（/cab）で、複数の変更をまとめて審議する運用ではこちらが早い。

• 参考：承認は1人1レコード（sysapproval_approver） … 承認レコードの構造

• 参考：CAB Workbench（/cab）の入口はカレンダー1枚 … CAB議題を管理する画面の構成

STEP1〜STEP3の後に有料ラインを置く。無料部は起票から承認申請までを扱う。

STEP1（New）：【起票者】変更内容をChange Requestとして起票する

操作：Change > Create New を開く。typeの選択肢が表示された場合はNormalを選ぶ。

入力する項目

欄記入例補足Short descriptionOracleパッチ10.2.0.1→10.2.0.3をSAP ORA01へ適用40文字以内で対象と作業を1文にするTypeNormaldefault_change_model=true のChange Modelが1件だけ存在し、既定で選ばれるCategorySoftware対象に応じて選ぶConfiguration itemSAP ORA01対象CIを必ず紐づけるJustification月次バッチの処理遅延を解消するため、DBパッチを適用する実施しない場合の影響も書くDescriptionパッチ適用手順に沿って10.2.0.3へ更新する。事前にバックアップを取得する手順の要約を書く

状態遷移：起票 → New（保存時。chg_modelが適用される）。Assessへは「Request Approval(Assess)」ボタンで進む

確認する項目

• Configuration itemが具体的な1つの実CIになっていること

• 同じ対象・同じ時期の重複した変更が既に起票されていないこと

エラー時の確認事項：保存できない場合は、エラーメッセージが示す欄名を確認し、空欄を埋めて再保存する。typeを迷ったまま選ぶと、新規作成時にしか変更できないためAssess以降で直せない。迷う場合はNewのまま保留し、4章の基準で確定する

記入例：起票時のJustification

月次決算バッチの処理がここ2週間で毎回1時間以上遅延している。
原因はOracle 10.2.0.1の既知の性能問題（パッチノート参照）。
10.2.0.3へ更新することで遅延を解消する。

STEP2（Assess）：【変更マネージャ】リスクと実施計画を固める

操作：対象レコードを開き、Planningタブに実施計画を記入する。

入力する項目

欄記入例補足RiskModerate選択肢は5段階定義だが、両端（Very High／None）は無効化されており実質3段階（High/Moderate/Low）から選ぶImpact2 - Medium影響範囲の広さを入れるAssignment groupDatabase実施担当のグループ。必須項目Implementation plan手順書v3のSTEP1〜STEP6に従って適用する実施の逐次手順を書くBackout planパッチ適用前に取得したバックアップから10.2.0.1へロールバックする空のまま次へ進めないTest plan適用後、バッチジョブを手動起動し完了時間を計測する完了の判断基準を書く

操作：リスクの自動計算について

Calculate Riskボタンを押すと RiskCalculator が risk_conditions（4件）と照合しRiskを自動設定する。プロパティ glide.ui.risk_calculate_rule が ui_action のため、保存だけではRiskは自動計算されない。

状態遷移：New → Assess（「Request Approval(Assess)」ボタン押下時）

確認する項目

• Backout planに、実際に戻せる具体的な手順が書かれていること

• Assignment groupに対応可能なメンバーが在籍していること

エラー時の確認事項：Assignment groupが空のまま保存しようとすると画面上でブロックされる（UI Policyによる制御。API経由の更新では働かない。7-3で詳述）。

Standardのテンプレートには切り戻し手順があらかじめ組み込まれている。Normalで毎回Backout planをゼロから書くのが負担になっている場合は、テンプレート側の記載形式を参考にすると書きやすい。

• 参考：変更申請テンプレートには切り戻し手順まで入っている？ … sttrm_base_templateの中身

STEP3（Assess→Authorize）：【変更マネージャ】CABへ承認を申請する

操作：ヘッダの「Request Approval(CAB)」ボタンを押す。

状態遷移：Assess → Authorize（ボタン押下時。ヘッダに「Change is waiting for approval」と表示され、Flowが承認者ごとにsysapproval_approverを生成する）

確認する項目

• 承認を依頼する対象が、影響を受ける領域の責任者になっていること

エラー時の確認事項：ボタンを押しても状態が変わらない場合の対応は6-2を参照する。

この記事の有料部に含まれるもの

STEP4以降の作業手順と、Standard・Emergencyそれぞれの起票からクローズまでの完結した手順を記載します。

• STEP4〜STEP8：承認判断・日程確定・実施・レビュー・クローズの操作と記入例（画面つき）

• Standard Changeの手順：テンプレートからの起票〜クローズまでのSTEP1〜STEP5

• Emergency Changeの手順：即時実施の判断〜事後CAB承認〜クローズまでのSTEP1〜STEP6

• 判断基準：コンフリクト発生時の判断、保留にする基準

• 異常時の対応：却下・保留中の保存エラー・typeの選定ミス・Closed後のclose_code訂正（監査証跡・承認要否）への対処

• 補足：記入式チェックリスト・症状別リカバリ表・必須項目の適用範囲・用語・実機で気づいたこと（5件）

記入例をそのまま自社の様式に置き換えれば、運用手順書として使えます。

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