リリース及び展開管理

承認された変更を本番環境に確実にリリース・展開するプロセス。テスト済みのソフトウェアやハードウェアを計画的に導入し、サービスの安定稼働を維持しながら新機能を提供する。

変更を一つのリリース単位にまとめ、計画・構築・テストを経て本番環境へ展開するプロセス。展開の失敗に備え、切戻し手順をあらかじめ用意する。

承認された変更をリリースとしてまとめ、計画、構築、テストを経て稼働環境へ確実に展開するサービスマネジメントのプロセス。展開に失敗したときに元に戻す手順も用意し、サービスの品質を維持しながら新しい機能や修正を提供する。リリース管理と呼ぶこともある。

新規のサービスやサービスの変更をリリースとしてまとめ、計画、構築、テストを経て稼働環境へ展開するサービスマネジメントのプロセス。通常リリースや緊急リリースなどリリースの種類と受入れ基準を定め、基準を満たしたことを確かめてから展開し、失敗に備えて切り戻しの手順を用意する。継続的デリバリーとも連携する。リリース管理と呼ぶこともある。

承認された変更をリリースとしてまとめ、稼働環境へ展開するための計画、スケジュール管理、構築、テスト、展開を行うプロセス。リリースポリシーに基づいて段階的な展開やビッグバン展開などの方式を選び、サービスの品質を維持しながら変更を実施する。リリース管理と呼ぶこともある。

承認された変更をリリースとしてまとめ、稼働環境へ展開するための計画、スケジュール管理、構築、テスト、展開を行うプロセス。通常リリースや緊急リリースといったリリースの種類と受入れ基準を定め、リリースポリシーに基づいて段階的な展開やビッグバン展開などの方式を選ぶ。リリース管理と呼ぶこともある。

サービス、システム、プロジェクトの計画や成果物などに対して変更を求める正式な提案。ITサービスマネジメントではRFC（Request for Change）とも呼ばれ、変更管理で影響、リスク、費用を評価して承認の可否を決める。プロジェクトマネジメントでは、変更管理委員会などで審査してからベースラインを変える。

新規のサービスやサービスの大きな変更について、要求事項を満たすように計画、設計、構築、試験を行い、運用環境へ移行するサービスマネジメントのプロセス。JIS Q 20000-1の「サービスの設計，構築及び移行」に含まれ、変更管理、リリース及び展開管理と連携して進める。

プロジェクトで提出された変更要求と、その評価、承認・却下の判断、実施の状況を記録した文書。変更の経緯を追跡できるようにし、承認された変更が計画に反映されているかを確かめるために使う。

承認された計画の基準となる版。スコープ、スケジュール、コストのベースラインなどがあり、実績と比べて進捗や差異を測る基準として使う。変更するには正式な変更管理の手続を経る必要がある。

正式な変更管理の手続を経ないまま、プロジェクトのスコープ（成果物や作業の範囲）が少しずつ広がっていくこと。小さな追加要求の積み重ねで起こりやすく、スケジュールの遅れやコストの超過の原因になる。変更要求を必ず変更管理で審査することで防ぐ。

ハードウェア、ソフトウェア、ネットワーク、文書などの構成要素（構成品目）と、その設定、版数、相互の関係を識別・記録し、変更を管理して正確な状態を維持すること。サービスマネジメントの基盤となるほか、情報セキュリティでは承認されていない設定変更の検出や、安全な設定の基準の維持に役立つ。