対象試験と出題頻度
リリース管理は、基本情報技術者・応用情報技術者で出題されるテーマです。
ITサービスマネジメントのプロセス比較問題として定番化しており、「変更管理」「構成管理」「インシデント管理」「問題管理」との役割の違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「リリース管理って変更管理と何が違うの？」と混乱しがちです。
リリース管理（Release Management）とは、一言で言うと
「承認された変更を、本番環境へ安全・確実に届けるためのプロセス」
のことです。
イメージとしては、「引っ越し業者」です。
「どの家具を持っていくか」を決めるのは家の持ち主（変更管理）の役目です。引っ越し業者は、決まった荷物を傷つけず、計画した日時に、新居へきちんと運び込むことに専念します。
リリース管理も同じで、「何を変えるか」ではなく「決まった変更を壊さず本番へ運び込む」ことに責任を持ちます。
📊 リリース管理の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Release Management |
| ITILでの分類 | サービストランジション（移行）。現行ITILでは「リリース及び展開管理」と呼ぶ |
| 目的 | 承認済みの変更を本番環境へ正しく反映させる作業の統制 |
| 主な活動 | リリース計画、ビルド、テスト、本番展開、切り戻し準備 |
解説
ITサービスは、機能追加やバグ修正のために絶えず手を加えられます。
しかし、本番で動いているシステムへ変更を反映する作業は、一歩間違えればサービス全体を止めかねません。
そこで「変更を決める仕事」と「変更を実際に届ける仕事」を切り分け、後者を専門に担う仕組みが整えられました。これがリリース管理です。
変更管理との役割分担
もっとも混同しやすいのが変更管理です。両者は前工程・後工程の関係にあります。
変更管理が「やってよいか」を判断し、リリース管理が「実際に届ける」と覚えてください。
変更が本番に届くまでの流れ
変更を承認・計画
ビルド・テスト・展開
利用者が使う
▲ 構成管理（CMDB）が裏で全体の構成情報を記録し、各プロセスを支える
関連プロセスとの比較
リリース管理を正しく位置づけるには、隣接するプロセスと「何に責任を持つか」で整理するのが近道です。
| プロセス | 担う責任 | 見分けキーワード |
|---|---|---|
| リリース管理 | 承認済み変更を本番へ展開する作業の統制 | 本番反映、展開、切り戻し |
| 変更管理 | 変更要求（RFC）の評価・承認 | RFC、承認、リスク評価 |
| 構成管理 | 構成アイテム（CI）情報の正確な維持管理 | CI、CMDB、構成情報 |
| インシデント管理 | 中断したサービスを合意時間内に復旧 | 迅速復旧、影響最小化 |
| 問題管理 | 障害の根本原因の追及と再発防止 | 根本原因、恒久対策 |
リリースの「種類」と切り戻し
リリースには規模に応じた区分があります。規模が大きいほど影響範囲が広がるため、展開方法も変わります。
メジャー：大規模な機能追加やアーキテクチャ変更を伴うリリース。
マイナー：小規模な改善や軽微なバグ修正のリリース。
緊急：重大な不具合を急いで直すホットフィックス的なリリース。
そして展開時に欠かせないのが、トラブル時に旧環境へ戻す「切り戻し（ロールバック）」の準備です。
リリース計画には、作業が時間内に終わらない場合や障害発生時の判断基準まで含めておきます。
💡 リリース管理の核心を3行で
・承認済みの変更を本番環境へ安全に展開するプロセス
・「変更を決める」変更管理の後工程にあたり、「実際に届ける」役割を担う
・展開計画には切り戻し（ロールバック）と障害時の判断基準を必ず含める
では、この用語が試験でどのように出題されるか見ていきましょう。
試験ではこう出る！
リリース管理は、FE・APの午前問題でITサービスマネジメントのプロセス識別問題として繰り返し登場しています。
出題パターンは大きく2つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H24秋 午前 問56 |
問題管理プロセスの目標を選ばせ、選択肢にリリース管理等の説明を並べる問題。 | ・「本番環境への反映」がリリース管理 ・問題管理（根本原因）との混同が狙い |
| AP H25春 午前 問56 |
障害対応の活動とITILの管理プロセスの組合せを選ぶ問題。 | ・稼働環境へのアプリ適用が「リリース及び展開管理」 ・各プロセスの役割の対応づけ |
| IP H27秋 問34 |
リリース管理に関する適切な記述を選ぶ問題。 | ・「計画時間内に終わらない想定も行う」が正解 ・事後通知でよい／備え不要などが誤り |
📝 IPA試験での出題パターン
パターン1：「プロセスの説明を選べ」
ITサービスマネジメントの複数プロセスの説明文が並び、リリース管理に該当するものを選ぶ形式。ひっかけとして「根本原因を突き止める」（問題管理）、「合意時間内に復旧する」（インシデント管理）、「変更を承認する」（変更管理）が紛れ込む。キーワードは「本番環境への反映」「展開」。
パターン2：「適切な実施手順を選べ」
IP H27秋のように、リリース作業の進め方として正しい記述を選ぶ形式。「障害発生に備える」「計画時間を超過する想定をする」が正解になりやすく、「事後通知でよい」「備えは不要」は誤りと判断する。
試験ではここまででOKです。メジャー／マイナーの厳密な閾値まで問われることはほぼないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ITサービスマネジメントにおけるリリース管理の説明として、最も適切なものはどれでしょうか？
- A. インシデントによって中断したITサービスを、合意した時間内に復旧させることを目的とする。
- B. 構成アイテム（CI）の情報を正確に収集・維持管理し、その整合性を確認・監査する。
- C. 変更管理で承認された内容を、本番環境に正しく反映させる作業を統制する。
正解と解説を見る
正解：C
解説：
選択肢Cが正解です。リリース管理は、変更管理プロセスで承認された変更を本番環境へ確実に届ける作業をコントロールするプロセスであり、「本番環境への反映」がこのプロセスを見分ける決め手になります。
選択肢Aはインシデント管理の説明です。中断したサービスを合意時間内に復旧させ、事業への影響を最小限に抑えることを目的とするプロセスで、変更を届けるリリース管理とは目的が異なります。選択肢Bは構成管理の説明です。構成アイテム（CI）情報の正確な維持管理と監査を担うプロセスであり、変更の本番展開そのものを行うわけではありません。
よくある質問（FAQ）
Q. 現在のITILでは「リリース管理」という名前ではないと聞きました。試験ではどちらで覚えるべきですか？
現在のITIL（v3以降）では「リリース及び展開管理（Release and Deployment Management）」という名称が使われ、サービストランジションに属します。一方で旧来の「リリース管理」という呼び方も過去問に残っています。IPA試験では両方の名称が登場するため、「名前が変わっても役割は同じ＝承認済み変更を本番へ届ける」と押さえておけば、どちらの表記で出題されても対応できます。
Q. 「DSL」「DML」という用語が出てきましたが、リリース管理と関係ありますか？
関係あります。DSL（Definitive Software Library／確定版ソフトウェアライブラリ）は、承認済みの正規なソフトウェアを安全に保管する場所で、リリース時はここから取り出して展開します。現在のITILではDML（Definitive Media Library）と呼ばれます。リリースの「品質保証された原本をどこから出すか」を支える仕組みで、構成管理と密接に連携します。試験では用語の存在を知っておけば十分です。
Q. 実務ではリリース作業はどんなタイミングで行うのですか？
利用者への影響が小さい時間帯、たとえば深夜や休日に実施することが一般的です。多くの現場では「リリース・カレンダー」で展開日程を事前に共有し、関係者へ周知します。近年はCI/CDツールで自動化し、本番に少しずつ反映する手法（カナリアリリースなど）も広がっています。リスクを抑えつつ段階的に展開する考え方は、過去問の「規模に応じて段階的にリリースする」という記述とも一致します。
Q. リリースとデプロイ（デプロイメント）は同じ意味ですか？
厳密には少し異なります。デプロイは「成果物を環境へ配置・配備する技術的な作業」そのものを指し、リリースは「その変更を利用者が使える状態にする」という、より広い管理プロセスを指します。配備（デプロイ）しても機能をすぐ有効化せず、後から切り替えるケースもあります。ただしIPA試験の範囲では、両者を厳密に区別する設問はほとんど出ないため、「本番へ届ける活動」とまとめて理解しておけば得点に支障はありません。
