はじめに
マネジメントを勉強していく中でプロジェクト中に起こる変更管理についてメモを残していきます。
目次
変更管理について
ITサービス(Webサービス等)を使うにはエンジニア達が開発して終わり...ではなくユーザーが利用できるようにするために、リリース管理を行う必要があります。また、変更を管理する変更管理という管理も必要な一つです。
管理とつくだけにリリース管理、変更管理は複数の工程で管理されています。
変更管理
変更管理は「システムやサービスを変更しながらITサービスの中断を抑えられるように管理する。」という内容になります。ここでの「変更」はITサービスに直接または間接的な影響を与える可能性のあるハードウェアやソフトウェアが該当します。
変更管理の例として新規画面の追加や既存画面の削除です。
機能統合による不具合影響の発生やセキュリティパッチの障害発生といったリスクを最小限にとどめるために、変更管理として制御します。
変更管理と関連性があり、重要なプロセスの展開管理、リリース管理があります。
展開管理
新規および変更されたハードウェア、ソフトウェア、その他コンポーネントを稼働環境に移行すること。
リリース管理
新規および変更されたサービスを利用可能状態にすること。
展開管理は稼働環境に移行することが目的で展開管理時点ではまだ利用できません。リリース管理を行うことで展開された稼働環境を利用できるようにします。
変更管理を行う前に
変更管理は上記で書いたようにITサービスの中断を抑えられるように管理することが重要です。
展開管理やリリース管理から、サービスがある稼働環境に変更を加えるため不具合や障害を出さないようにするために変更管理を行う際は以下のような確認を行います。
変更の承認
プロジェクトの上位権限者(PMやPL)に承認をもらう。プロジェクトが大きくなるほどアプリケーション(フロントエンド)を管理するチームやサーバ、API等を管理するチーム(バックエンド)の上位者に確認を行います。
変更スケジュールの作成
「明日、サービスの最新版をリリースします」というようなことはなく、事前に何月何日にリリースするかのスケジュールを作成します。作成したスケジュールにより、チーム間の衝突(アプリチームとサーバチームのそれぞれの変更)やインシデント管理に役立ちます。次回のリリースにてAのインシデントとBのインシデントの修正パッチを入れるため今週は「この修正パッチにリソース(人員や時間等)ができる」といったことができます。