リリースのタイプは、次のように分類できる。
関連するリリースユニット(ハードウェアやソフトウェア)全体をすべて更新するリリースである。テストや切り戻し計画もこの単位で行われるので、リリース後のインシデントが発生する可能性が低い。
リリースユニットの中の変更が発生する部分のみをリリースする方法である。テストや配布の工数を削減できる可能性があり、緊急度が高いリリースに向いている。
関連する複数のリリースを同時に行う方法である。パッケージリリースの中には、複数のフルリリース、またはデルタリリースが含まれる。ITサービス環境を長時間安定させたい場合に有効であるが、大規模になりがちで、その大規模なリリースを確実に実装できる技術力が必要である。
リリースは大小を問わず、必ずITサービスに何らかの影響を与える。リリース中はITサービスを一時的に止めなければならなかったり、新しい環境にユーザが慣れるのに時間がかかったりする。そのため、リリースの回数はできるだけ減らすのが望ましい。とはいえ、緊急性の高いリリースは一刻も早く導入しなければならない、という場合もある。上記の3つのリリース・タイプを念頭において、バランスのよいリリース計画を立てることが必要である。
リリース管理がうまくいっているかどうかを評価するためのKPI(重要業績評価指標)には、次のようなものが考えられる。
変更管理、リリース管理は、慣れなければ面倒な手順である。周知徹底されなければ、社内の反抗もあるだろう。しかし、成熟した変更管理、リリース管理は、実環境でのITサービスのインシデントや問題を確実に減らし、未許可のソフトウェアを減らし、サポートコストを減らす。その結果、ITサービスのビジネスに対する貢献度が増し、ITサービスに対する信頼度が増し、顧客満足度やユーザ満足度が増す。管理のための管理になってはいけないが、可能な範囲で、できるところから、プロセスをきちんと回していく努力を重ねよう。そのためには、経営者層の理解も必要不可欠である。
※本連載の用字用語については、ITILにおいて一般的な表記を採用しています。
Copyright © ITmedia, Inc. All Rights Reserved.