IT運用管理には、リリース管理のほかにも、サービスレベル管理、インシデント管理、問題管理など、様々な管理プロセスが定義されていますが、とりわけこのリリース管理は、導入する組織によって定義・範囲が曖昧で、運用のあり方が大きく異なるケースが数多く見られます。

とはいえリリース管理がめざす目的自体には、いずれのケースであっても大きな違いはありません。その目的とは、先述したとおり「リリース管理」という仕組みを通じて、ITサービスの品質を一定に保つことであり、より具体的には、本番環境に加えたい変更を、安全・無事に遂行できるようにすること、にあります。なお、ITサービスマネジメントシステムの国際規格であるISO20000では、リリース管理の目的を次のように定めています。

「リリースにおける一つ以上の変更を、稼働環境に配送し、配布し、かつ、追跡するため」

ちなみに、IT運用管理のベストプラクティス集であるITILでは、Ver2でサービスサポートの1プロセスとして、また、Ver3ではサービス移行（サービストランジション）の1プロセスとして定義されています。

リリース管理は、大きく次の2つのプロセスに分類することができます。

• リリース管理プロセス
• 展開管理プロセス

リリース管理プロセスは、主としてソフトウエアやハードウエアのライフサイクル（生涯）を通じて、どのようなリリース（本番環境への変更）を行っていくかについての管理のことであり、展開管理プロセスは、主として実際に本番環境に対して変更を加える際に、どのような準備・実行・見直しを行うかについての管理のことをさします。

言い換えますと、

• システムに、どのような計画で手を加えていくのか
• どういった単位で、どのようなタイミングで、何を本番環境に反映していくのか
• どのようにリリース管理プロセスの継続的改善を行っていくのか（目標設定やその見直しをどうやって行うのか）

といったようなことを考えていくことがリリース管理プロセスであり、一方、本番環境に実際に変更を加える段階で、

• きちんと全てのテストが完了しているのか
• 変更の反映手順はどうするのか
• 変更作業が失敗した際にはどのようなバックアッププランを発動するのか
• 変更について誰に何を連絡をして、誰の承認ををもらうのか
• 今回行う変更に伴い、何と何の情報更新（構成管理）を行う必要があるのか

といったようなことを考えることが展開管理プロセスになります。

リリース管理では、「リリース管理ポリシー」と呼ばれる、（適用範囲となる）組織全体において例外なく遵守されるべき方針を定めることが重要になります。これは主として、リリース管理は幅広い役割を担うものであることから、そこで定めるルールに不整合が生じないようにする必要があること、あわせて、システム利用者に影響を及ぼす（例：変更のためシステムをシャットダウンさせるなど）可能性の高い作業管理を行うものであるため、ステークホルダー（システム利用者）が最大の関心をよせるものであること（どのような方針に基づいてリリースを行うのか知りたがる）、といった以上2つの理由から、特に必要性が高い、と考えられています。

参考までに、「リリースポリシー」には、以下のような項目を含めることが一般的です。

• リリース管理体制、役割と責任
• リリースユニット、リリースパッケージの単位
• リリース種別
• 種別に基づく頻度
• ナンバリング（ソフトウエアへの付版）ルール
• テスト
• 記録
• ロールバック、など

「リリース管理」と「変更管理」はいずれも「ITサービスの品質を保つために既存の情報システム環境へ加える変更をコントロールする」、つまり門番的な役割を担う、という点では大きな共通点を持つことから、そもそもの意義や実際に現場へ導入するプロセスが曖昧になりがちです。

しかしながら、この2つのプロセスは「ITサービスの品質を保つ」ための焦点を合わせるエリアが異なります。変更管理では、変更内容にコントロールの主眼がおかれているのに対し、リリース管理では、変更作業そのものに対してコントロールの主眼がおかれています。すなわち、「その変更は本当に必要なのか」といった問いについて考えるのが「変更管理」であるのに対し、「どのように本番環境への変更の反映を行うのか」について考えていくのが「リリース管理」であるということもできます。

したがって、これら2つのプロセスに求められる役割や手段は、密接につながりながらも、大きく異なっている、ということができます。