リリース管理とは？ITILにおける目的・プロセス・展開管理との違いを解説

リリース管理とは、システムやアプリケーションの変更を、安全かつ計画的に本番環境へ提供するための管理プロセスです。

本プロセスはリリース内容の計画からテスト、承認、展開、リリース後の確認までを管理します。

本記事では、ITILにおけるリリース管理について、目的や具体的なプロセス、展開管理・変更管理との違いを初心者にも分かりやすく解説します。

リリース管理とは？

リリース管理とは、システムやアプリケーションの新機能追加、修正、アップデートなどを、安全かつ計画的に利用者へ提供するための管理活動です。

リリース内容の計画からテスト、承認、展開、リリース後の確認までを適切に管理することで、システム障害やサービスへの影響を抑えながら変更を提供できます。

ITILにおけるリリース管理の位置付け

ITILにおけるリリース管理は、承認された変更を安全かつ確実に本番環境へ展開し、サービスの品質を維持しながらユーザーが利用できるようにする重要なプラクティス（旧：プロセス）として位置づけられています。

リリース管理と展開管理の関係

リリース管理と展開管理は似ていますが、次のように役割が異なります。

リリース管理
「何を、いつ、どのように提供するか」を計画・管理する活動
（リリースの計画立案、スケジュール調整、ビルド、テスト（検証）、リリース全体の管理）
展開管理
「決められたリリースを対象となる環境へ反映する」活動
（本番環境への組み込み、インストールの実行、展開手順の管理、初期動作確認）

リリース及び展開管理の目的

リリース及び展開管理の目的は一言でいうと「変更を確実に実装する」ですが、もう少し細かく書くと次の内容があります。

システム変更による障害を防ぐ

システムに新機能を追加したり、既存機能を変更したりすると、意図しない不具合やシステム障害が発生する可能性があります。

これを防ぐために、本番環境へ変更を反映する前に、テストやレビュー、リリース内容の確認などを行うことで、変更によるリスクを抑えます。

＜ポイント＞

リリースする内容や実施日時、担当者、作業手順、影響範囲などを事前に整理
関係者（利用者、連携する他システム担当者、運用担当者など）とレビュー
万が一問題が発生した場合に備えて、復旧手順（切り戻し手順）をあらかじめ準備

リリースの追跡性・再現性の確保

リリース管理では、「いつ、誰が、何を、どのような手順でリリースしたのか」を後から確認できる状態を維持することも重要です。

たとえば、リリースしたバージョンや変更内容、実施日時、担当者、承認者、作業手順、テスト結果などを記録しておけば、リリース後に問題が発生した場合でも、原因を追跡しやすくなります。

リリース作業の品質を標準化

リリースの計画、テスト、承認、展開、確認といった手順を整理して、一定のルールに沿って実施できる状態を作ります。

このようなルールを標準化することで、作業ミスを減らし、リリース品質を安定させることができます。

リリース及び展開管理の開始タイミング

リリース及び展開管理は、変更管理で承認されたサービスがリリースパッケージとして作成・登録された時点で開始します。
複数の変更管理での活動がある場合、それぞれの活動に対しリリース及び展開管理をプロセスをする単体リリースや、複数変更の統合リリースをする場合もあります。
■単体リリース

■複数変更の統合リリース

リリース・リリースパッケージ・展開

ITILではリリースを「提供するもの(サービスなど)を用意する」、展開は「提供方法」としています。

一般的には新サービスなどを本環境へ移送することを「リリース」と呼びますが、ITILではリリース、展開で分けています。

リリースは複数で構成されることもあります。
本番環境への新サービス適用はシステム停止を伴うことが多いので、ひと月に１回システム停止をさせてもらってリリース及び展開をするというケースが多いです。
その場合、溜まっていたリリースを一気に展開します。

個々のコンポーネントをリリースユニットと言い、このリリースユニットをひとまとめにしたのがリリースパッケージです。

リリース及び展開管理の活動内容

リリース及び展開管理の活動内容（プロセス）はプロジェクトや規模によって異なることもありますが、「①計画立案　→　②リリース設計　→　③リリースの受け入れ試験　→　④展開計画・手順作成　→　⑤周知、トレーニング　→　⑥展開　→　⑦レビュー・クローズ」となります。

ここからフェーズごとの活動内容を説明します。

①計画立案

計画立案は次の内容を決めます。

目的
例：優先度が高となっていた新サービス、月次のOSパッチを本番環境へ適用する。
リリーススコープの定義
リリースするサービスを決めます。
例：以下３つを対象とする。
　①○○機能の改修（変更管理番号：XX）
　②□□機能の追加（変更管理番号：XX）
　③X月リリース分OSのパッチ
スケジュール
リリースするサービスの内容を考慮してスケジュールを作成します。
この後のリリース設計、リリースの受け入れ試験などのプロセスの実施日を可能であればガントチャートで作成します。
他システムとの調整
本システムと連携している△△システム側に影響が出ないよう本番環境への実装をする。

②リリース設計

リリース設計では、リリースユニット（モジュールやデータベースオブジェクト、ドキュメント等）、手順を作成します。

手順は担当部門や想定時間などを書いておくとこの後の作業がスムーズになります。

③リリースの受け入れ試験

検証環境（ステージング環境）を利用して、実際にリリース手順を実施して問題がないことを確認します。
前工程の変更管理プロセス（サービス設計と移行プロセス）にてユーザ受け入れ試験を未実施であれば、この活動で試験をします。
また、システムによっては検証環境がない場合もあるので、その場合は開発環境でリハーサルやユーザによる試験を実施します。

④展開計画・手順作成

展開計画・手順作成では、詳細なスケジュール作成や担当者への割り当てをします。

⑤周知、トレーニング

新機能に関する説明をユーザへ周知したり、他システム担当者と調整をしたりします。
必要に応じてサービスデスクと連携を取って対応します。
■主な内容

ユーザ向け教育　：　新機能や変更点の説明会、マニュアル作成
システム停止やユーザが必要な作業の周知　：　作業に伴うシステム停止や、ユーザでインストール作業が必要な場合の手順を周知
運用担当者向けトレーニング　：　運用手順の説明、運用マニュアルの修正
他システム担当者との調整　：　実装のスケジュール詳細を説明

⑥展開

上で作成した展開計画・手順に従い、展開作業を実施します。
作業の際は実施者、掛かった時間、エビデンスを記録しておき、次回の参考にできるようにしておくと良いです。

リリース管理で作成する資料

前の章で紹介した活動の中で次の資料を作成します。

リリース計画書

リリース計画書は、リリースの目的や対象、実施内容、スケジュール、体制、影響範囲などをまとめた資料です。

＜サンプル＞

１．背景
　業務効率化のため、手作業となっている△△の処理を自動化する必要がある。

２．リリースの目的
　△△処理の自動化により、作業時間の短縮とミス防止を実現するため、Aシステムに○○機能を追加する。

３．対象システム
　基幹システム（Aシステム）
　関連システム（Bシステム）

４．実施概要
　Aシステム：○○機能の追加
　Bシステム：連携APIの更新

５．実施体制
　開発チーム：リリース・展開作業
　運用チーム：バックアップ、立ち合い、利用者への通知
　サービスオーナー：リリース計画書、手順書の承認

６．影響範囲
　他システム：Bシステム側の改修が必要。Cシステムに影響なし。
　セキュリティ：影響なし
　ユーザー業務：現行のの業務開始に影響ないことをテストでも確認済み。
　　　　　　　　新機能は担当者向けに３０分程度の説明が必要。
　システム運用：新APIの死活監視を追加する必要がある。
　サービス停止：Aシステムは１時間の停止、Bシステムは影響なし

７．スケジュール
　別紙の全体スケジュールを参照

８．切り戻し（ロールバック）計画
（１）切り戻し（ロールバック）判断基準
　　以下のいずれかに該当する場合、切り戻し（ロールバック）を実施する。
　　・リリース後の動作確認チェックリストで重大項目が未達の場合
　　・他システムや業務に重大な影響が発生し、業務開始時刻までに復旧の見込みがない場合
　　・想定していた復旧手順で問題が解消できず、追加調査が必要となる場合
（２）切り戻し（ロールバック）手順
　　リリース手順書に記載する。