リリース管理の役割――ITプロセスを円滑に回すために：初心者歓迎！ ITIL連載講座（2/3 ページ）

[谷誠之，ITmedia]

リリース管理の活動

　変更管理の活動は、図1の通りである。リリース管理の活動は書籍によって、簡単に書かれているものもあれば非常に細かく書かれているものもあるが、本連載では最も簡単に説明することにする。

図1：リリース管理の活動

1．リリース計画立案

　変更管理で許可された変更に対して、リリース計画を立案していく。リリース計画において作成される文書には、次のようなものがある。

• リリース／ポリシー
• スタッフの役割と責任
• 社内スタッフと社外サプライヤの役割と責任
• リリースの設計、構築、実装の手順
• スタッフのトレーニング
• DSLの保守の方法

　特に重要なのは、リリース・ポリシーである。リリース・ポリシーは、リリース管理の責任と役割を明確にするものであり、以下のような内容を含む。

• リリースの名前付けルール
• リリースの定義（小規模、大規模、緊急）
• リリースのタイプ（フル、デルタ、パッケージ）
• 切り戻し計画の手引き
• スタッフの役割

2．リリースの設計、構築、開発

　いわゆる「手順書」を整備する段階である。主に次のような指示書を作成していく。

• 構築指示書
• リリースのための操作の手順書
• 自動インストールスクリプト
• ハードウェアやソフトウェアを購入する場合、その注文書
• DSLに保存されるべきソフトウェアやドキュメントの一覧
• 切り戻し手順書

　これらの手順書は重要なCIとして、CMDBに登録されるべきである。

3．リリースの受け入れ

　構築されたリリースが問題なく配布、構築できることを保証する段階である。ここで最も重要なのは、構築のためのテストである。リリース計画通りにきちんと配布・構築が可能なのか、リリースされたバージョンはビジネスの期待に応えることができるのか、新たな不具合やインシデントが存在しないか、徹底的にテストを行う。また、切り戻し計画に対するテストも行っておく必要がある。

　リリースのテストは、リリース計画を立てたスタッフとは別のメンバーが行うことが望ましい。それによってリリース計画を立てたスタッフが気付かなかった不具合に気付く可能性も出てくるからである。さらに、新たなインシデントが発生した場合、それに対するワークアラウンドも確立しておく必要がある。どうしても問題が改善されない場合は、リリースは延期されることになる。

4．投入計画立案

　テストが完了したら、詳細な計画を立てていく。正確なインストール計画、正確なタイムスケジュール、今回のリリースによって破棄すべきCIのリストなどを作成する。また、顧客やユーザとのコミュニケーション計画もここで立案する。

5．コミュニケーションと準備

　変更に関係のある顧客、ユーザ、ITスタッフなどに、リリース計画やリリースによる影響などを十分に伝える。何らかの制約があれば、必ず事前に伝えるようにする。特にサービスデスクは顧客窓口であるので、今回のリリースによって発生する影響と対策に関しては十分にトレーニングする必要がある。

6．配布

　作成されたリリース計画に基づいて実際の導入を行う段階である。リリースが完了したら、CMDBを最新の状態に更新することを忘れてはならない。また、一定期間様子を見て、必要であればいつでも切り戻せるように準備しておく。一定期間が経過すれば、その結果を変更管理にレビューする。