サービスマネジメント

問題、変更、リリース、構成管理

問題管理

問題管理の目的は、インシデントの根本原因を突き止めて、恒久的な解決策を提供すること。
問題のトレンド（傾向）を分析し、将来起こり得るインシデントに対して前もって対策しておき、インシデントの発生を防ぐことでビジネスに対する負のインパクトを最小限におさえることも目的です。

・問題コントロールは問題の識別と根本原因の調査を目的としている。（左図）
・エラーコントロールは、既知のエラーに対する根本的な解決策を提供することを目的とする。（右図）

変更管理

変更管理とは、ITサービスを提供するITインフラストラクチャ（ソフトウェア、ハードウェア、ネットワーク等）の変更を効率的かつ効果的に実施するための活動。
高い変更率に対して効率的かつ効果的に対応するとともに、より優れたリスクおよびコスト評価を提供し、ITとビジネスの整合性の向上を目指します。

変更管理の活動

活動	内容
登録とフィルタリング	「インシデント解決のため」「サービスに対する不満を改善するため」などの理由で作成されたRFC（変更要求）を先のステップで検討できるようにするために1箇所にまとめる作業。
優先度の割り当て	RFCの原因の影響度と、変更の緊急度に基づいて優先順位を明確化にさせる段階であり、問題を是正するためのRFCはその問題重要度コードに基づき決めることが望ましいとされる。
変更のカテゴリ化	変更が組織に与えるインパクト、変更を達成するために必要なリソース、両方の観点からRFCを評価してカテゴリ分けを行う。
インパクトとリソースの評価	サービス提供者のマネージャーおよび技術者などから構成されるCAB（変更諮問委員会）を中心に「利用者のビジネスに与える影響」「システムに与える影響」「変更に実施に必要なリソース、コスト」などの観点から変更の実施について最終的な検討を実施する。
変更の認可	CABで認可が下りた変更の実施に向けて、組織から「財務上の認可」「技術上の認可」「事業場の認可」について最終的な認可をもらう。
変更のスケジュール化テストおよび実装	認可の下りた変更は実施に向けスケジュールが組まれます。準備が整うと、「パフォーマンス」「セキュリティ」「保守性」「サポート性」「信頼性/可用性」の観点からテストを実施します。問題がないことが確認できたならば、次の「リリース管理」のプロセスでいよいよ実施段階に入る。

リリース管理

リリース管理の目的は、変更管理で承認されたRFCに対する変更を、ビジネス的な観点においても技術的な観点においても確実に実装することです。
正式な手順とチェックで稼働環境とそのITサービスを保護し、変更によって発生する負のインパクトを最小限に抑えることも重要な目的です。

変更管理とリリース管理の違い

変更管理とリリース管理の責任範疇は大きく異なる。
変更管理は、ビジネスに対する正のインパクトを確実に与え、負のインパクトを最小限にするためにはどのような変更を行えばよいか、ということに責任を持つ。
リリース管理は変更管理で承認された変更が確実に行われることそのものに責任を持つ。
変更管理とリリース管理は綿密に連携し合わなければならない。

構成管理

インシデント管理、問題管理、変更管理、リリース管理を支える重要な活動を行います。
ITサービスを構成するハードウェアやソフトウェア、ネットワーク、ドキュメントなどの「構成品目（CI）」の情報を正確に把握し、よりよいITサービスを提供するために維持していく活動のことを構成管理と呼びます。

構成管理の主な活動

計画立案	構成管理の目的、適用範囲、達成目標、役割分担、スケジュール、手順などを決定して、実施に備える。
識別	構成品目を組織が必要とするレベルまで詳細化し、関連付け、命名などを行う。
コントロール	許可された構成品目だけが、正確に構成管理データベースに登録されるようにコントロールする。
ステータスの説明	構成品目の現在のステータス情報や更新情報を提供する。
検証と監査	現状のシステムと構成管理データベースに登録された構成品目が一致することを検証する。