サービスマネジメントでは、変更管理、リリース及び展開管理、構成管理、サービス要求管理など、似て見えて役割の異なる活動が並びます。
この記事では、利用者へ何を示すのか、変更を誰が判断するのか、何を本番へ導入するのか、何を記録するのかを分けます。読み終えると、事例の次の行動としてどのプロセスを選ぶか判断できるようになります。
先に結論：対象と役割を分ける
| 用語・プロセス | 主な役割 |
|---|---|
| サービスカタログ | 利用できるサービスの内容・条件を利用者へ示す |
| 変更管理 | 変更要求を記録し、影響・リスクを評価して承認可否を判断する |
| リリース及び展開管理 | 承認された変更を本番環境へ計画的に導入する |
| 構成管理 | 構成品目と相互関係を正確に記録・維持する |
| サービス要求管理 | 定型化された通常の依頼を処理する |
| サービスデスク | 利用者からの問合せ・依頼を受け付け、適切な担当へつなぐ |
同じ変更に関係していても、判断する・導入する・記録するは別の活動です。
1．サービスカタログは利用者向けの案内
サービスカタログは、利用者が利用できるサービスについて、必要な情報を整理したものです。
- サービスの名称・内容
- 対象となる利用者
- 提供時間・利用条件
- 申込み方法
- 問合せ先
掲載内容は正確で最新の状態に保ちます。
内部の管理情報とは目的が異なる
| 記録 | 主な目的 |
|---|---|
| サービスカタログ | 利用者へ利用可能なサービスを示す |
| 構成情報 | 機器・ソフトウェア・サービス間の関係を管理する |
| 変更記録 | 変更要求、評価、承認、実施結果を残す |
| インシデント記録 | 発生事象と復旧対応の状況を管理する |
「どのサービスを利用できるか分からない」という相談なら、まずサービスカタログを確認・整備します。
SLA、サービスレベル目標、SLMとの関係は「ITサービスマネジメントとSLA」で扱います。
2．変更・リリース・構成管理を区別する
三つはいずれも変更に関わりますが、担う役割が違います。承認を判断するのが変更管理、承認済みの変更を本番へ入れるのがリリース及び展開管理、対象と関係を記録するのが構成管理です。
変更管理は影響を評価して承認する
変更管理では、変更要求を記録し、サービス、利用者、セキュリティ、費用、日程などへの影響とリスクを評価します。
評価結果に基づき、権限を持つ者が承認・却下・延期などを判断します。
テストが完了していても、変更承認の代わりにはなりません。技術的に動作することと、事業・運用上の影響を許容できることは別だからです。
リリース及び展開管理は本番へ導入する
リリース及び展開管理では、承認済みの変更を、計画と受入れ基準に沿って本番環境へ導入します。
確認する代表例は、
- 対象となるリリース
- テスト・受入れ結果
- 実施日時・手順
- 関係者への周知
- 切戻し手順
- 実施後の確認
です。
変更管理＝承認判断、リリース及び展開管理＝承認済み変更の導入と分けます。
構成管理は構成品目と関係を維持する
構成管理では、サーバ、ネットワーク機器、ソフトウェア、文書など、サービスを構成する管理対象を構成品目（CI）として記録します。
個々のCIだけでなく、
- どのサーバでどのソフトウェアが動くか
- どのCIがどのサービスを支えるか
- 変更によって何が影響を受けるか
- 現在の版・設定・状態は何か
という関係も管理します。
資産管理が保有状況、契約、ライセンス、費用などを重視するのに対し、構成管理はサービスを構成する要素と関係を重視します。
3．変更は要求から事後確認まで管理する
基本的な流れは次のとおりです。
- 変更要求を記録する
- 目的、影響、リスク、優先度を評価する
- 権限を持つ者が承認・却下などを判断する
- テスト、周知、切戻しを含む実施計画を作る
- 承認された計画に従って導入する
- 結果を確認し、構成情報と記録を更新する
- 必要に応じて事後レビューを行う
緊急変更でも統制をなくさない
重大障害や脆弱性への対応では、通常より迅速な承認経路を使う場合があります。
ただし、緊急だからといって、責任者、影響・リスク、実施結果、切戻し又は代替策、事後確認まで全て省略するわけではありません。
緊急変更＝無承認・無記録で自由に変更できるではない、と判断します。
4．サービス要求は通常の依頼を扱う
サービス要求管理は、あらかじめ手順や条件が定められた通常の依頼を扱います。
代表例は、
- パスワード再発行
- 標準ソフトウェアの利用申請
- アカウント・権限の申請
- 情報や助言の依頼
- 定型的な機器・サービスの申込み
です。
サービス要求管理＝定型化された通常の依頼
インシデント管理＝サービスの中断・品質低下からの回復
インシデント管理と問題管理の詳しい区別は「用語の衝突を整理する」で扱います。
5．サービスデスクは利用者との窓口
サービスデスクは、利用者からの問合せ、申請、サービス要求、インシデントの連絡などを受け付ける窓口です。
内容を分類し、必要に応じて適切なプロセスや専門担当者へ引き継ぎます。このような引継ぎがエスカレーションです。
サービスデスクが全件を自ら解決する必要はありません。
6．科目Bでの使われ方
| 事例 | 判断 |
|---|---|
| 利用できるサービスと申込方法が分からない | サービスカタログを確認・整備する |
| テスト済みなので承認前に本番へ反映する | 変更管理の承認を経る |
| 承認された変更を本番へ導入する | リリース及び展開管理 |
| 変更対象と関連システムが分からない | 構成情報を確認する |
| 緊急変更なので記録を残さない | 記録と事後確認を残す |
| パスワード再発行を依頼された | サービス要求管理 |
| 窓口で解決できない | 適切な担当へエスカレーション |
判断の順序は、案内 → 承認判断 → 本番導入 → 構成記録 → 通常依頼か障害かです。
担当者としては、緊急の変更であっても記録と事後確認を省かず、承認の要否を担当者限りで判断しません。窓口で解決できない依頼は、抱え込まずに定められた担当へ引き継ぎます。
よくある取り違え
| 誤った考え方 | 正しい整理 |
|---|---|
| テストが完了すれば変更承認は不要 | 技術的に動くことと影響を許容できることは別 |
| リリース及び展開管理で承認を判断する | 承認判断は変更管理、導入がリリース及び展開管理 |
| 構成管理と資産管理は同じもの | 資産管理は保有・契約・費用、構成管理は構成要素と関係 |
まとめ
- サービスカタログは利用者向けのサービス案内
- 変更管理は影響・リスクを評価して承認可否を判断する
- リリース及び展開管理は承認済み変更を本番へ導入する
- 構成管理はCIと相互関係を維持する
- 緊急変更でも記録・責任・事後確認などの統制を残す
- サービス要求管理は定型化された通常依頼を扱う
- サービスデスクは受付・分類・連携・エスカレーションを行う
関連記事
- C10-T02：ITサービスマネジメントとSLA
- C10-T01：プロジェクトマネジメントの基礎
- C6-T02：初動対応とエスカレーション
- C4-T01：情報資産の洗出しと台帳
本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。
参考資料
- IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
- PeopleCert「ITIL FAQ」
- PeopleCert「ITIL 4 Practitioner: Service Request Management」
- PeopleCert「ITIL 4 Practitioner: Service Configuration Management」
- PeopleCert「ITIL 4 Practitioner: Release Management」
関連する問題
- 情報セキュリティマネジメント プロジェクト・サービスマネジメント・システム監査 一問一答 第6問〜第10問
- 情報セキュリティマネジメント プロジェクト・サービスマネジメント・システム監査 択一式（応用） 第1問〜第5問
- 情報セキュリティマネジメント プロジェクト・サービスマネジメント・システム監査 択一式（応用） 第6問〜第10問
コメント