リリース計画
まず、変更管理プロセスに対して変更要求(RFC)が出され、変更管理プロセスで変更を受入・承認したもののリリースを計画する。当然のことながら、このとき計画されているリリースが先に策定したリリース・ポリシーに基づいて計画されている必要がある。また、変更管理に対して、適宜リリース計画をレビューすることを推奨する。
設計
ソフトウェア・インフラストラクチャの設計を実施する。言うまでもないが、設計をする上で、構成管理データベース(CMDB)を必ず参照し、CIの属性等を考慮すること。
開発(購入)リリースの構築・構成
実際のソフトウェアの開発、インフラの調達・構築を実施する。ここで重要なのが、ソフトウェアの場合、パッケージ化、インストーラの作成など導入・変更する際の安全性を考慮することが必要である。また、リリース手順についても、この段階で作成・文書化する。
テスト計画・テスト
単体テスト、結合テスト、リリーステスト、切り戻しテストなどの計画、および実施を行う。ここで計画・実施されたものについて、必ず文書化する。
ロールアウト計画・トレーニング・レビュー
ロールアウト時の作業分担、責任範囲、詳細な作業内容、タイムスケジュールなどを文書化・レビューを実施する。また、作業員や(必要に応じ)ユーザー、サポートスタッフのトレーニングを実施する。
リリース
ソフトウェアの検証環境から本番環境への配置、ユーザー環境への配布、ハードウェアの設置を実施する。
導入後レビュー
リリース実施から一定期間経過後に実施されたすべての変更・結果についてレビューを実施する。これにより、次回以降のリリース計画にフィードバックされ、リリース成功率の向上に繋げる。
このサブプロセスは一例であるが、それぞれのサブプロセスごとに成果物を定めレビューを実施し、リリース管理マネジャーの承認を受けることを勧めたい。また、いずれのサブプロセスにおいても、コミュニケーションが重要である。顧客や、各プロセスのマネジャー、スタッフにリリースの計画内容、影響範囲を説明することが欠かせない。
リリース管理(構成管理、変更管理を含め)を導入することによりリリースの成功率は向上するが、100%を達成するのは難しい。現実問題として、新規リリースの場合、いくら綿密な計画やテストを実施しても想定外の事象が生じる可能性がある。
成功率向上の秘訣は、いかに(バージョンアップなどの)変更リリース手順を標準化し、リスクを抑えるかが重要である。そのためには、導入後のレビューを行い、来るべき次のリリース計画にフィードバックすることが何よりも重要なことになってくる。
Copyright © ITmedia, Inc. All Rights Reserved.