変更管理とは？システムを変更する前後の手順と記録

変更申請を作るだけでなく、判断と実施後の確認まで扱う

変更の依頼・申請は、判断材料を渡す入口です。申請したことが、その変更の実施や成功を意味するわけではありません。対象のシステムや業務に何を加え、変え、なくすのかを説明し、必要な影響評価、判断、時期と連絡、実施した内容、確認結果を一つの変更として追います。

例えば、アプリの表示や設定、処理の動かし方、基盤や接続先の変更は、利用者の仕事へ直接・間接に関係する場合があります。作業が簡単か、よく行うかだけで影響が小さいとは判断できません。一方、全てを同じ書式や承認段数にすると、変更を把握するための仕事が形だけになりやすくなります。

「何を変更管理の対象にするか」を、組織で先にそろえる

対象となるサービス、変更の種類、誰へ事前に共有するか、既に認められた手順を使える条件を明らかにします。判断が必要な変更と、定めた範囲内で反復できる作業の境目を、担当者が同じように読めることが大切です。新しい対象や条件外の作業を、名称だけで既定の扱いへ押し込みません。

ServiceNowの日本語解説は、IT変更の優先付け・承認・予定・実行、依頼に必要な情報と役割を説明しています。ただし、そこで例示されるCAB（変更を評価する会議体）や変更マネージャーの型を、全ての会社で必須の人数・役職にするものではありません。ServiceNow：IT変更管理の解説

変更する内容と、残したい業務を同じ案に書く

この案の目的は、出荷準備の前に、使う受注情報を確かめられるようにしたいという希望です。同時に、受発注担当が対象ファイルを確認し、出荷担当が取込結果を確かめる仕事は続けたい条件です。目的が書かれていても、現行の開始条件や関係する処理が分からなければ、何を変え、どこを試すかは決まりません。

手元にある資料例は、変更相談メモ（架空）と現行の運用メモ（架空）です。メモに変更希望があることと、その内容が実現可能であること、実施してよいことを分けてください。資料名だけでなく、対象のサービスと環境、どの版・箇所を見ているかを対応させます。

影響は、使う人と前後の仕事からたどる

取込の開始条件を変えるなら、対象ファイルがそろう条件、取込後の情報を使う人、後続の処理や締め作業などを確認します。目的の画面や処理だけでなく、同じ情報や基盤を使う仕事がないかを調べます。まだ関係が分からない所は、影響なしとせず、必要な資料と答えられる相手を残します。

判断材料には、使えなくなる時間や対象の利用者、データが書き換わる範囲、他の処理との順序、やり直しの可能性、担当が対応できる体制などがあります。全てを同じ細かさで調べるのではなく、その変更で業務が困る条件を説明できる範囲へ絞ります。

図で見る問い：受注取込の開始条件を変える案は、誰のどんな仕事に関係するでしょうか。変更相談の紙と、対象ファイルを確かめる人、取込結果を使う出荷準備の関係を見てください。

この解説図を原寸で見る

図の読み方：変更案を、使う資料と前後の仕事へ結びます。図の線は調べる関係で、全ての依存先や影響が判明した証拠ではありません。続けたい仕事を確認し、開始条件と後続の業務のどの記録が不足するかを、次の表で具体化します。

進める条件は、不足する資料と判断する人まで具体化する

直前の変更案と前後の仕事の図も使い、何の資料がそろえば影響を判断できるかを確かめてください。

「担当へ確認する」で終わらせず、何が分かれば次へ進めるかを添えます。この架空案では、次の内容が未確認です。未知の欄を埋めるために実施条件を推測せず、同じ変更案の対象と資料へ問いを結び付けます。

試す対象と、期待する結果を先に書く

変更した部分が動くかだけでなく、続けたい仕事が成立するかを確かめる観点を用意します。対象の環境・版・データと、通常時、入力や条件が違う場合、やり直しが必要な場合などを、変更の影響に合わせて選びます。試験を計画したことと、試験結果が得られたことは分けて記録します。

例えば、受注ファイルがそろわない場合や、途中で取り込めなかった場合を想定するなら、どの記録を見て止めるのか、再実行で重複しないかを確認します。記事の作例で実環境へ試験入力するものではありません。実データや本番への接続を使う条件は、自社の権限と情報管理の取り決めへ戻してください。

判断する役割と、実施・業務確認の役割を分ける

小さいチームでは役割を兼ねる場合もあります。人数を増やすことを完成条件にせず、技術面の判断、業務への影響の判断、実施と確認を、誰がどの根拠で担うかを明らかにします。一人では判断できない条件や委託先の範囲は、回答先と判断先を決めて戻します。

戻す案には、データと業務を確かめる条件も添える

止める兆候、止める判断をする人、回復の方法、連絡する相手を、作業前に検討します。設定や版を戻せても、その間に登録された受注や出荷の状態まで必ず元通りになるとは限りません。戻す方法の実行条件や試験状況、戻した後に重複・漏れを確かめる仕事を区別してください。

MicrosoftのAzure向け設計指針も、展開の段階ごとの確認、問題時の停止・回復、状態を持つデータの変更で戻すことの難しさを説明しています。ここでは考え方の参考にし、特定クラウドの自動化機能や展開方式を、全組織の必須方法へ転用していません。Microsoft Learn：安全な展開の設計指針

標準・通常・緊急は、名前だけでなく扱える条件で分ける

標準変更は、対象・手順・条件を事前に評価し、認めた範囲で繰り返す変更です。「よくある」「簡単」という担当者の印象だけで、確認や記録が不要になる意味ではありません。通常変更は、そのような事前の評価・了承が定まった範囲として扱えない変更を、今回のリスクに合わせて判断する区分です。

緊急変更は、待つことによる影響を踏まえ、急いで対応する必要がある変更を扱うための区分です。緊急と呼べば何も確認せずに実施してよい、という意味にはしません。自社の対象・区分・権限を確認して使います。

事前評価済み手順の比較例は、主変更の一部や、改善前後の結果ではありません。 手順の対象、許される値や環境、確認方法から外れるなら、同じ方法で進めてよいかを改めて判断します。

作業名を、そのまま全社共通の分類にしない

パッチ適用や機器交換、設定値の変更なども、環境と影響で扱いが変わります。事前評価した手順があり、その範囲に一致することを確かめる場合と、新しい条件を調べる必要がある場合を分けます。低リスクと評価されたことは、無害・失敗しないという保証ではありません。

Atlassianの公式解説は、標準を文書化・事前評価済みの反復として説明し、通常・緊急も組織とリスクに合わせて扱うとしています。本稿はこの区別を使い、例示された作業や自動化の比率、全変更を同じ会議へ送る型を転用していません。Atlassian：変更の種類

図で見る問い：評価済みの手順内で繰り返す作業と、今回の判断が必要な受注取込の案は、何をそろえて比べるのでしょうか。対象・手順・条件と、範囲に一致するかの確認を近くで見てください。

この解説図を原寸で見る

図の読み方：二つは別の例です。事前に認めた手順でも、今回がその対象と条件に一致するかを確かめます。主変更を簡単だから許可不要としたり、比較例を同じ変更の成功後にしたりしません。自社で定めた手順の範囲を確認し、外れる条件は判断する人へ戻してください。

了承・実施・技術確認・業務確認を、一つの変更へ結び付ける

「実施してよい」という判断と、実施した記録と、業務で使えた確認結果は別です。了承の対象と条件が分からないまま実施へ進めたり、技術側の完了連絡だけで業務側の確認まで終えたことにしたりはしません。次の図は残す記録の関係で、実際に全段階を通った経過ではありません。

技術的に動いたことと、業務が成立したことを合わせて読む

処理が起動した、ログに終了が出た、といった技術側の結果だけでは、必要な受注情報がそろい、出荷担当が対象を確認できたかまでは分かりません。業務側がどのデータ・画面・出力を確かめ、何が期待と違ったかを、同じ変更の記録へ結びます。実際の確認結果を得る前に、予定した確認項目を「合格」へ変えないでください。

未達や予定との差があれば、その条件に戻って判断する

期待した結果が得られない場合は、対象と条件、実際の結果、業務への影響を分け、止める・戻す・直す等を誰が判断するかへ戻します。回復の後も、データや業務の確認が必要です。変更記録は、完了という一語だけでなく、何を確認し、何が未解決かが分かる形で残します。

実施後の状態に応じて、構成台帳、運用手順、連絡先などを更新し、その根拠と確認時点を追えるようにします。台帳に入力したことだけで、実施や業務確認が済んだことにはしません。

図で見る問い：変更案と進める条件、実施した記録、業務で確かめた記録は、どう対応させるのでしょうか。別々の資料を同じ受注取込の案へ結ぶ線と、未確認の状態を見てください。

この解説図を原寸で見る

図の読み方：案を送る、了承する、実施する、業務で確かめるという仕事を区別します。この例はまだ未送信・未実施で、各段階の成功を示しません。自社では、実施した内容と期待した結果が同じ対象を指すかを照合し、未解決は条件と判断先を添えて残してください。

急ぐときも、何を先に確認し、何を後から残すかを決める

この架空例で緊急事態が発生したわけではありません。 ここでは、緊急時の扱いも事前に決めておく理由を説明します。待つことが業務や安全に大きな影響を与える場合、通常の予定のまま待つリスクと、急いで変更するリスクを比較する必要があります。

MicrosoftのAzure向け指針も、緊急時に手順を短縮する判断者と基準、後から行う確認を定める考え方を説明しています。特定製品の段階や機能を一律に使う意味ではありません。緊急と呼ぶだけで、対象・連絡・止める条件や結果の記録が不要になるとは扱わないでください。

判断材料が不足するなら、調べる範囲と保留する判断を明確にする

現行の開始条件が分からないなら、対象版の運用メモと実際に確認できる記録をそろえる所へ戻します。出荷への影響が分からないなら、取込後に何を使い、何がそろわないと困るかを業務担当へ確認します。試験の結果がないなら、計画書を結果として扱わず、試す対象と実施できる条件を確かめます。

調べた結果、変更が不要になった、条件を見直した、実施を見送ったという判断も、その理由と根拠を残します。反対に、通常の更新を何もしないことにもリスクがあるため、保留を無期限の放置にせず、次の確認内容と担当、判断し直す条件を決めます。

開発会社への追加希望の伝え方は、仕様変更依頼に追加機能・残す業務・未決事項を書く方法で扱っています。本稿は、その依頼だけで終わらず、運用上の変更を判断し、実施と業務確認を追う範囲を説明しています。

まとめ：目的と影響を説明し、了承・実施・確認を分けて記録する

同じ変更へ記録を結ぶ図に戻り、案・了承・実施・業務確認のどこに根拠が不足するかを整理してください。

ITの変更管理は、変更申請を増やすことだけではありません。何を変え、誰の仕事に関係し、どの条件で進め、何を実施し、業務で何を確かめたかを、一つの変更へ結び付けます。対象とリスクに合う方法を組織で定め、事前評価済み手順の範囲と、今回の判断が必要な条件、緊急時の扱いを区別します。

資料や了承が不足する所は、その対象と根拠、答えられる相手を絞って確かめます。実施したという連絡を、そのまま試験・業務確認・台帳更新の完了へ広げず、止める・戻す等を判断する条件と、回復後のデータの確認も分けてください。