PK0-005 ・出題項目 4.5

ITプロジェクト中の運用変更管理プロセスの説明

プロジェクト中の運用変更管理プロセスを解説するよ！

最後の項目だよ！ここまで来たらあと少し、
頑張ろう！

概要

プロジェクトや運用中のシステムにおいて予期しない混乱やリスクを最小限にしながら、計画的に変更を実施する仕組みです。 ITサービス管理（ITSM）の中核的なプロセスのひとつで、ITILなどでも重視されています。適切な変更管理により、サービス停止や障害のリスクを減らし、安定した運用を維持します。

ITインフラストラクチャの変更管理

サーバー、ネットワーク、ストレージ、クラウド構成などの物理・論理インフラの変更を管理
変更内容、目的、影響範囲を事前に分析し、承認後に実施
失敗時のロールバック手順（元に戻す方法）を必ず用意
主な例：サーバー増設、ネットワーク構成変更、ファームウェア更新

ソフトウェアの変更管理

アプリケーションの新機能追加、バグ修正、設定変更などを管理
バージョン管理と密接に関わり、変更履歴の記録や追跡が重要
開発環境→テスト環境→本番環境への順番で段階的に適用
主なツール例：Git、Subversion（SVN）、Mercurial

CI/CD（継続的インテグレーション／継続的デプロイメント）

ソフトウェア開発における自動化された変更管理の考え方
CI（Continuous Integration）: 開発者のコードを頻繁に統合してビルド・テストを自動化
CD（Continuous Deployment）: テストをパスした変更を本番環境まで自動的にデプロイ
メリット：リリースサイクル短縮、品質向上、ヒューマンエラー削減
代表的ツール：Jenkins、GitLab CI、CircleCI、GitHub Actions
ユニットテスト（Unit Test）: モジュール式コーディングで最小の機能単位（コンポーネント）を検証するテスト。開発初期にバグを発見でき、修正コストと時間を大幅に削減できる。CI/CDにおける自動テストの基礎となる。

実稼働環境（Production）とステージング環境（Staging）

実稼働環境: ユーザーが実際に利用する本番環境。高い安定性と信頼性が求められる。
ステージング環境: 本番環境とほぼ同じ構成で、変更内容を検証するテスト環境。
本番環境に適用する前に、必ずステージング環境で十分にテストするのが重要。
このほか、開発（Development）、テスト（Testing）、QA（品質保証）環境なども運用される。

組織変更管理（OCM / Organizational Change Management）

定義: 新しいシステムやプロセスの導入に伴い、組織の従業員やグループがその「変化」に適応し、行動を変革できるように支援・管理するプロセス。
OCMの本質的役割と目的:
- 真の目的: プロジェクトによって生み出された変化を 「ユーザーに受け入れてもらう（受容と定着）」 ことにあります。
- OCMの目的ではないもの（試験の誤答ひっかけ）:
  - プロジェクトを完全に終了させること
  - プロジェクトのユーザーへの影響を制限・最小化すること
  - 各フェーズ終了時にプロジェクトを客観的に評価すること
技術的変更管理（CCB）との違い:
- 技術的変更管理（CCB / CAB）: スコープ、コスト、スケジュール、ITインフラへの変更要求を審査・承認・制御するプロセス。
- 組織変更管理（OCM）: 変更が組織の「人々」に与える影響を管理し、行動変容を促すプロセス。

OCMの時系列4ステップ（試験頻出・順番そのまま出題）

ステップ数	ステップ名（英語）	具体的な活動内容	試験対策上の重要ポイント
1	やり方を変える必要があるグループを特定する (Identify groups that need to change)	最初に「誰が変わらなければならないか」を特定します。	やり方を変える必要がある人々は変更に最も抵抗しやすいため、抵抗の大きさを事前に把握するために最初に行います。
2	人々が何を変える必要があるかを特定する (Identify what people need to change)	業務プロセス、システム操作などの具体的な変更点を洗い出します。	変更に対する反対を克服し、適切なトレーニングを計画するための基礎情報を収集します。
3	移行を促進する (Facilitate transition)	実際に人々の行動変容を支援します。	トレーニングの実施と社内からの手厚いサポートが不可欠なフェーズです。
4	採用を監視し強化する (Monitor and reinforce adoption)	導入後の利用率や定着度を測定・追跡します。	影響を受けた人々へフォローアップを行い、追加サポートが必要な人を特定して支援します。

ITインフラ・ソフトウェア変更管理プロセス（時系列ステップ）

本番運用中のIT環境を変更する際は、サービスの停止やシステム障害を防ぐため、以下の 時系列ステップ に従います。

変更要求（RFC : Request for Change）の提出: 変更の目的、対象、影響度、実施手順をまとめた変更要求書を起票します。
影響調査と検証（開発・テスト環境）: 開発・テスト環境で変更を事前に検証し、失敗した場合にシステムを以前の状態に安全に戻すための ロールバック計画（回帰計画） を必ず作成します。
変更管理委員会（CCB）による承認: 変更管理委員会（CCB）において、リスクと影響が審査され、実施が承認されます。併せて、夜間や週末などの本番利用が少ない「メンテナンスウィンドウ（時間枠）」が設定されます。
ステージング環境での最終検証: 本番環境（Production）と同一構成の ステージング環境（擬似本番環境） で変更を適用し、本番移行手順が正しく動作することを確認します。
本番デプロイとロールバックの備え: 承認されたメンテナンスウィンドウ中に、変更を本番環境に適用します。適用後に動作確認テストを実施し、万が一致命的な不具合が発生した場合は、速やかに用意していた ロールバック計画 を実行して以前の状態に戻します。
変更のクローズと文書化: 変更が成功したことを確認し、構成管理データベース（CMDB）やシステム構成書を更新し、変更ログをクローズします。

試験対策ポイント

IT運用変更管理プロセス（RFCの起票 → CCB/CAB承認 → テスト → 適用 → ロールバックへの備え）を理解する。
失敗した変更を元に戻す計画を「回帰計画（Regression Plan）」または「ロールバック計画（Rollback Plan）」と呼ぶ。
OCM（組織変更管理）の4ステップの正しい順番と各ステップの意味を記憶する。