LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

変更管理とは — 本番変更を統制する仕組み

変更管理（Change Management）とは、本番環境のシステム構成やアプリケーションに加える変更を、リスクに応じて分類し、影響評価と承認のプロセスを経てから実施する統制の仕組みを指します。AWSのWell-Architected Framework（クラウド設計・運用のベストプラクティス集）は、デプロイに伴うリスクの緩和について「変更の展開によって生じる問題の影響を軽減する実践手法を採用すること」を目的として整理しています^*1。

変更管理が対象とするのは、アプリケーションのコード変更だけではありません。サーバー構成の変更、ネットワーク設定の変更、権限設定の変更など、本番環境に影響を与えうるあらゆる変更が対象になります。変更を無秩序に本番へ適用すると、想定していない副作用が発生し、サービス停止やデータ不整合につながる可能性があります。

変更管理という統制の仕組みが必要とされる背景には、変更そのものが障害の主要な引き金になりやすいという実務上の課題があります。AWSは堅牢なデプロイ戦略のアンチパターンとして「失敗した変更を一度にすべての本番環境へ展開した結果、すべての顧客が同時に影響を受ける」状態を挙げています^*1。変更管理は、こうした一括適用のリスクを構造的に減らすための仕組みだといえます。

標準変更・通常変更・緊急変更 — リスクに応じた3つの分類

変更管理の実務では、すべての変更を同じ手続きで扱うのではなく、リスクの大きさに応じて分類し、分類ごとに異なる承認の手続きを適用する考え方が広く採られています。ITサービスマネジメントの業界では、この分類を一般に「標準変更」「通常変更」「緊急変更」の3種類として整理する枠組みが用いられています。

標準変更は、手順が確立されており、リスクが低く、繰り返し発生する変更を指します。定期的なパッチ適用や、あらかじめ承認された手順に沿った設定変更などが該当し、実施の都度個別の審議を経ずに、事前に定めたモデル（変更のテンプレート）に沿って実行されるのが一般的な考え方です。通常変更は、標準変更ほど定型化されていないものの緊急性のない変更で、事前に影響評価と承認の手続きを経て実施します。緊急変更は、障害対応など早急な対応が必要な変更で、通常の審議プロセスを簡略化した手続きで承認を得ます。

この3分類の目的は、リスクの低い変更に余計な審議コストをかけず、リスクの高い変更にはしっかりと評価の目を通すという、リスクに応じた資源配分にあります。すべての変更を一律に重い手続きにかけると、変更管理そのものが開発・運用のボトルネックになりかねません。

変更要求（RFC）と影響・リスク評価の実務

変更管理プロセスの起点は、変更要求（RFC、Request for Change）の提出です。RFCには、変更の内容、変更が必要な理由、想定される影響範囲、実施予定日時、実施担当者、そして変更が失敗した場合の後方計画（ロールバック手順）を記載します。

影響評価では、変更が及ぶ範囲を技術面とビジネス面の両方から確認します。技術面では、変更対象のシステムに依存する他システムの有無、変更によって影響を受けるユーザー数、変更作業に要する停止時間の見込みを確認します。ビジネス面では、変更を実施する時間帯が業務のピーク時間と重なっていないか、関連する取引先や利用者への事前周知が必要かを確認します。

リスク評価では、変更が失敗した場合にどの程度の影響が生じるか、そして失敗をどれだけ早く検知し復旧できるかを合わせて検討します。AWSは変更が意図しない結果をもたらした場合の対応について「既知の正常な状態へ戻す、または本番環境で修復する計画を立てる」ことを推奨し、デプロイとロールバックの手順、変更ポリシー、フィーチャーフラグ、トラフィックの分離や切り替えといった手法を挙げています^*2。後方計画をあらかじめ用意しておくことが、平均修復時間（MTTR）の短縮と事業影響の低減につながるという考え方です^*2。

後方計画を欠いた変更は、失敗時の対応が現場の即興的な判断に依存します。変更が失敗してから復旧手順を検討し始めると、復旧までの時間が延び、サービス停止の影響が拡大しやすくなります。RFCの段階で後方計画を明文化しておくことが、リスク評価を実効性のあるものにする前提です。

CABの役割と、重くしすぎたときの副作用

CAB（Change Advisory Board、変更諮問委員会）とは、変更要求の妥当性をビジネスへの影響・リソース・技術的な観点から評価し、変更の実施について協議する会議体です。CABの位置づけは「承認」そのものを行う機関ではなく、変更の意思決定者に助言を行う諮問機関として整理されるのが一般的です。メンバーには、変更内容に応じて開発担当者・運用担当者・利用部門の代表者など、妥当性判断に必要な知識を持つ関係者が招集されます。

CABが機能を果たすと、単独の担当者が見落としがちな影響範囲を、複数の視点でチェックできます。特に、複数システムが連携する環境や、変更の影響範囲が事前に見積もりにくい大規模な変更では、CABでの多角的な確認が有効に働きます。

一方で、CABを重くしすぎることには副作用があります。すべての変更を毎週の定例会議でしか審議しない運用にすると、リスクの低い変更でも会議の開催まで実施が止まり、リリースのリードタイムが延びます。開発チームが変更のたびに数日から数週間の承認待ちを強いられる状態が続くと、変更管理そのものが開発速度を落とす要因として認識されてしまいます。

この副作用を避けるには、前章で整理した変更の分類を活用し、リスクの低い標準変更はCABの審議対象から外す設計が実務上重要になります。CABで審議すべき対象を、影響範囲が大きい変更・過去に失敗した実績のある変更・複数システムに関わる変更に絞り込むことで、審議の質を保ちながら審議件数を絞れます。

DevOps環境での標準変更の自動承認とリードタイム

DevOps（開発と運用が連携し継続的にリリースする開発体制）を実践する組織では、標準変更の大部分をCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインの中で自動化し、個別の人的承認を経ずに実施する運用が広がっています。AWSは、堅牢な本番リリースについて「フィーチャーフラグ・ワンボックス・ローリング（カナリアリリース）・イミュータブル・トラフィック分割・ブルーグリーンデプロイといった戦略」を用いて、望ましい結果を検証しながら影響範囲を限定する仕組みを紹介しています^*2。

この考え方の要点は、変更管理の目的である「リスクの適切な統制」を、会議での事前承認だけでなく、デプロイの仕組み自体に組み込むという発想です。承認をパイプラインの手前に置くのではなく、変更を段階的に適用しながら異常を検知した時点で自動的に停止・復旧する仕組みにすることで、統制と速度の両方を確保できます。AWSはこの背景として「継続的デリバリーの失敗はサービスの可用性低下と顧客体験の悪化につながる」とし、デプロイの成功率を高めるための保護機構をリリースプロセス全体に組み込む重要性を述べています^*2。

ただし、自動承認の対象を広げるには前提条件があります。対象の変更が過去に十分な実績を積み、影響範囲が限定されており、異常時の自動ロールバックが機能することを確認できている必要があります。この前提が整わないまま自動承認の範囲を広げると、統制が形式だけのものになり、変更管理が本来防ぐべきリスクを見逃す結果になります。

監査・コンプライアンスと変更管理の証跡

変更管理は、内部統制やシステム監査の観点からも重要な位置づけを持ちます。経済産業省は、財務報告に関わる情報システムの内部統制の指針として「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」を公表しており、令和6年（2024年）12月25日付で改訂版が示されています^*3。同ガイダンスは、情報システムの構成要素に対する変更などを統制の対象として扱う枠組みを示すものです^*3。

監査の視点から重視されるのは、変更が「誰の申請で・誰が承認し・いつ実施され・どのような結果になったか」を後から検証できる状態にあるかどうかです。承認記録・実施記録・テスト結果・ロールバックの有無が一貫して保管されていれば、監査時に変更管理プロセスが実効的に運用されていることを示せます。逆に、承認の記録が残っていない変更や、承認者と実施者の分離（職務分掌）が確認できない変更は、内部統制の不備として指摘される対象になりやすくなります。

証跡を残す実務では、RFCの内容・CABでの審議記録・承認者の署名（電子的な承認履歴を含む）・実施結果・異常発生時の対応記録を、変更管理システムやチケット管理ツールに一元的に記録する運用が実務的です。口頭やチャットでの承認は、後から検証可能な記録として残りにくいため、正式な記録媒体に承認を残す運用ルールをあらかじめ定めておく必要があります。

外注の委託範囲と発注準備

変更管理・リリース承認プロセスの整備を外部に委託する場合、委託範囲は主に4つの工程に分けられます。第一に変更の分類基準（標準変更・通常変更・緊急変更の切り分けルール）の設計、第二に変更要求（RFC）のテンプレートと影響・リスク評価の基準設計、第三にCABの運用設計とファシリテーション、第四に承認記録・実施記録を証跡として一元管理する仕組みの構築です。

変更管理の整備を内製だけで進めるには、ITILの分類体系やCABの運用に関する知見、監査で求められる証跡の要件、CI/CDパイプラインへの承認組み込みといった複数領域の理解が必要です。既存の運用フローを把握した担当者を複数名確保し、分類基準の設計から記録体制の構築まで一定の期間をかけて整備する体制が求められます。この立ち上げを内製だけで担おうとすると、既存業務と並行して基準策定を進める負荷が生じやすくなります。

発注前に準備しておくべき情報としては、過去に発生した変更の種類・頻度・失敗事例、既存システムの構成と依存関係、承認権限を持つ関係者の範囲、監査対応で求められる証跡の要件が挙げられます。これらが整理されているほど、委託先は自社の変更リスクの実態に合った分類基準と承認フローを早く設計できます。

委託範囲を決める際は、初期の基準設計とCAB運用の立ち上げ支援のみを外部に依頼し、定着後の日次運用は社内で回す形も選択できます。立ち上げ期に体系的な設計の知見を借りることで、社内に運用の型を移植しながら、初期段階で生じやすい分類基準の抜け漏れを避けられます。

まとめ — 変更管理を整備する3つの判断軸

本稿では、変更管理の定義と標準変更・通常変更・緊急変更の分類、CABの役割と副作用、監査対応に必要な証跡、外注する場合の委託範囲と発注準備を整理しました。要点を3つに集約すると次の通りです。第一に、変更管理は変更をリスクに応じて分類し、影響評価と承認を経て実施する統制の仕組みであり、後方計画の有無が失敗時の影響範囲を左右します。第二に、CABは変更の意思決定を支える諮問機関であり、審議対象を絞り込まずに重くしすぎると、DevOps環境ではリリースのリードタイムが延びる副作用が生じます。第三に、外注する場合は分類基準の設計から承認記録の証跡化まで委託範囲を切り分け、過去の変更実績と監査要件を発注前に整理しておくことが整備の成否を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「AWS Well-Architected Framework – OPS06-BP03 Employ safe deployment strategies」（https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_mit_deploy_risks_deploy_mgmt_sys.html）
2. *2　出典：AWS「AWS Well-Architected Framework – OPS06-BP01 Plan for unsuccessful changes／OPS06-BP03 Employ safe deployment strategies」（https://docs.aws.amazon.com/wellarchitected/latest/framework/ops-06.html）
3. *3　出典：経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（令和6年12月25日改訂）（https://www.meti.go.jp/policy/netsecurity/docs/secgov/2024_ZaimuHoukokuNiKakaruITTouseiGuidance.pdf）

Tweet