変更管理

変更管理入門

ITILと聞くと、組織が内部顧客にサービスを提供する方法を定義する厳格なプロセスと手順の集合体を思い浮かべるかもしれません。しかし、ITILを真に深く理解している人々は、このフレームワークが決して硬直したものではないことを知っています。実際、ITILライフサイクルは動的であり、常に変化し続けるものです。変更管理は、ITILライフサイクルのすべての段階を支援するという点で、とりわけ強力で広範な影響力を持ちます。変更管理を考える際には、組織のサービス目標を支援するために定義・管理が必要な戦略的、戦術的、および運用上の変更が存在することを認識することが重要です。ここに成功の鍵があります。

最も根本的なレベルでは、変更管理は組織のリスク理解に関連しています。リスク管理がビジネス戦略と組織の能力に基づいてリスクを受容、無視、低減、または活用することを教えてくれる一方で、変更管理は組織に対するリスクを管理することに他なりません。このガイドでは、さまざまな種類の変更について解説します。効果的な変更管理の鍵は、リスク許容度によって変更タイプを定義し、IT組織が必要とする適切なレベルの検証を定めることです。

私の長年にわたるITILの経験の中で、変更管理に苦労していない組織はほとんど見たことがありません。多くの企業にとって、それはプロセスの定義を真に理解していないことが問題でした。非常によくあるのは、組織がプロセスの一つまたは二つの側面だけを実装して、それを変更管理と呼んでいるケースです。例えば、変更承認または実装後レビューのみを行い、それを変更管理と呼んでいる企業もあります。また、変更管理とリリース・デプロイメントの違いを十分に把握していない組織や、リリース・デプロイメントが何であるかを正しく理解していない組織も存在します。一般的に言って、これはプロセス自体に対する成熟度の問題であり、ベストプラクティスを深く掘り下げるにつれて、変更管理プロセスが形を成し、真の成果をもたらし始めます。

すべてのITILプロセスと同様に、変更管理には多くの課題が存在します。教育機会、専門コンサルティング、およびベストオブブリードテクノロジーを活用することで、プロセスとビジネスのサービス成果を改善するとともに、DevOps、ビッグデータ、IoT、サイバーレジリエンス、デジタルトランスフォーメーションなどのイニシアティブの推進にも役立てることができます。

このガイドのコンテンツを読み進める際には、組織にとって本質的なことを実践し、人材、プロセス、テクノロジー、そしてサプライヤーを活用して目標を達成することのビジネスへの価値を念頭に置いてください。サービスエクセレンスとは終わりのない旅であり、継続的に実践し磨き続けなければなりません。そして、成功を祝うことも忘れずに！

変更管理とは何ですか？

変更管理プロセスは、標準化された手順を通じて、ITサービスに対する戦略的、戦術的、および運用上の変更のライフサイクルを管理・制御するために設計されています。変更管理の目標は、リスクを制御し、関連するITサービスおよびビジネスオペレーションへの混乱を最小限に抑えることです。

注記：組織的変更管理（OCM）は変更管理と混同されることがありますが、OCMは新しいプロセスや組織構造の変化が人々に与える影響を扱うものです。組織構造は人々とプロセスの行動に影響を与えるため、OCMと変更管理は連携して機能します。

変更管理の目標

変更管理の目標は、変更がビジネスオペレーションに与えるリスクと影響を大幅に最小化するために、変更要求をアジャイルかつ効率的に管理するための標準的な手順を確立することです。

変更管理のメリット

いかなるベストプラクティス、フレームワーク、または方法論も100%の成功を保証することはできませんが、変更管理はリスクの管理を支援し、提供・サポートするITサービスを不必要なエラーから守ることができます。信頼性の高いビジネスシステムの維持は、今日の競争的な市場環境において、あらゆる組織の存続にとって不可欠です。ITインフラ内のあらゆる要素への調整はサービス価値を損ない、生産性に悪影響を与える可能性があります。構造化・計画された変更は、インフラ変更に伴う潜在的なリスクを最小化するのに役立ちます。同時に、適切に構造化・計画された変更管理プロセスは、ビジネスに大きなメリットをもたらします。

変更管理によってもたらされるメリットには以下が含まれます。

• ITとビジネスの整合性の向上
• ビジネスオペレーションへの悪影響の低減
• IT変更に対する可視性の向上
• 変更への優先的な対応力の強化
• 政府およびその他のコンプライアンス規制への準拠
• リスク管理の改善
• サービス中断およびシステムダウンタイムの削減
• スタッフの生産性向上
• 変更実装の迅速化

サービストランジションにおける変更管理の役割

変更管理は、サービストランジション刊行物における重要なプロセスです。これは、新規または変更されたITサービスの構築、デプロイ、および運用への移行に関するガイダンスを含む、ITILのサービス管理ベストプラクティスフレームワークの一部です。サービスの廃止に関するガイダンスも提供されています。ITプロセスライフサイクルにおけるサービストランジションの目的は、リスクを最小化しながらITサービスへの変更を計画・管理し、ユーザーおよびビジネスに対する意思決定支援を改善することです。

ITILサービストランジションのプロセスには以下が含まれます。

• 変更管理
• サービスアセットおよび構成管理
• リリースおよびデプロイメント管理
• ナレッジ管理
• サービスの妥当性確認とテスト
• 変更評価
• トランジション計画とサポート

「変更」の定義

ITILによれば、変更とは「ITサービスに影響を与える可能性のある、承認済み、計画済み、またはサポート対象のサービスやサービスコンポーネントの追加、修正、または削除」です。多くの場合、変更とは変更権限者によって承認されたイベントであり、リスクを最小化しながら評価・実装され、構成アイテム（CI）のステータスを調整し、ビジネスとその顧客に価値をもたらすものです。

変更は以下の2つの方法によって発生します。

1）変更要求またはChange Request（RFC）

変更要求は、構成アイテムの変更を求めるために、組織内のステークホルダーが提出するか、またはサービスユーザーがリクエスト履行プロセスを活用してサービスデスク経由で提出できる正式な提案です。

2）変更提案

変更提案は、新しいサービスの導入または重要な変更に関する高レベルの説明であり、ビジネスケースと実装スケジュールを含みます。これらの提案は通常、サービス戦略におけるサービスポートフォリオ管理プロセスによって作成され、変更管理プロセスに引き渡されます。

**通常サービスデスクが処理するサービスリクエストは、変更要求となる場合があります。サービスリクエストは、その変更がITサービスのコンポーネントや構成アイテムの追加、修正、または廃止によりITサービスに影響を与える場合、変更要求となり得ます。サービスリクエストはサービスデスクのリクエスト履行プロセスを使用して処理され、変更管理プロセス（および場合によってはサプライヤー管理プロセス）も関与します。多くのサービスリクエストは標準変更です。

変更の種類

1）緊急変更／至急変更

緊急変更とは、重大なインシデントを解決するために可能な限り迅速に評価・実装しなければならない変更です。緊急変更は混乱を招きやすく失敗率が高いため、最小限に抑えるべきです。緊急変更の正確な定義は、変更管理ポリシーに定められるべきです。

2）標準変更

標準変更とは、頻繁に発生し、リスクが低く、完了のための文書化されたタスクを伴う事前確立された手順を持つ変更です。標準変更は変更管理プロセスを迅速化するために事前承認の対象となります。繰り返し発生する変更を処理するためのプロセスを説明する変更モデル（特定の種類の変更を管理するための文書化された再現可能な計画）は、多くの場合、標準変更のために作成されます。標準変更タイプが組織にとってリスクの高いものになった場合、通常変更となる場合があります。

3）重大変更

重大な財務的影響を伴う可能性があり、かつ／またはリスクが高い変更です。このような変更には、財務上の正当性と適切なレベルの経営承認を含む詳細な変更提案が必要です。重大変更を特定・管理するための各組織のプロセスは、ビジネスの規模と複雑さによって異なります。このケースでは、変更が運用レベルから戦術レベル、または戦術レベルから戦略レベルへと移行し、承認に別のレベルの権限が必要となる場合があります。

4）通常変更

通常変更とは、標準でも緊急でもなく、サービスまたはITインフラへの重要な変更を一般的に必要とする変更です。通常変更は、変更諮問委員会（CAB）によるレビューおよび承認・却下を含む、完全な変更管理レビュープロセスの対象となります。

追加の変更要求には以下が含まれます。

• アプリケーション変更
• ハードウェア変更
• ソフトウェア変更
• ネットワーク変更
• ドキュメント変更
• 環境変更

変更管理プロセスフロー

ITILは、組織個々のサービス提供とサポート要件に対応できる適応性の高いフレームワークを提供します。経営陣が承認した標準化された変更管理プロセスを設計することで、変更が発生した際に迅速、経済的、かつ効果的に管理することが可能になります。そのプロセスはその後、サービス管理サポートソフトウェアによって自動化できます。変更コントロールは、変更管理プロセス全体の下位要素であり、変更が管理、記録、分析、および承認されることを確保するために設計されています。

一般的な変更管理プロセスには以下の活動が含まれます。

1）変更要求（RFC）の作成およびログ記録

変更要求は通常、変更を必要とする個人、プロセス、またはビジネスユニットによって作成されます。変更の種類に応じて、RFCレコードには変更の承認と実装に関する意思決定に必要なさまざまな情報が含まれます。具体的には、識別情報、説明、変更が発生する構成アイテム、変更の理由、申請者の連絡先情報、変更の種類、タイムフレーム、コスト、バックアウト計画、およびビジネス上の正当性が含まれます。

2）変更要求（RFC）のレビュー

各変更要求は、ビジネス上の実現可能性について変更権限者によってレビューおよび優先順位付けされる必要があります。これらのリクエストは拒否され、通知として、または詳細情報の要求として申請者または管理者に返却される場合があります。これらの未承認変更は監視され、必要に応じてクローズされる必要があります。

デモを見る: Ivanti Neurons for ITSM - 変更管理

3）変更の評価

ビジネスオペレーションへの不必要な混乱を回避するために、ITサービスへの影響、リスク、およびメリットを評価する変更の評価が不可欠です。重大変更などの特定の変更タイプについては、変更評価プロセスによって正式な変更評価が実施され、変更評価レポートに文書化されます。影響評価では、ビジネス、インフラ、顧客サービス、IT・非ITサービスを含むその他のサービス、実装リソース、および変更ログに現在スケジュールされている変更への影響が考慮されます。変更諮問委員会（CAB）も変更を評価することができます。CABは、変更の必要性を評価するためのサービスオーナー、技術担当者、および／または財務担当者などのさまざまなステークホルダーで構成することができます。

4）変更の承認／認可

変更要求は通常、実装前に認可を必要とし、各変更は変更の種類（戦略的、戦術的、運用的）に応じた適切な権限レベルからの認可を必要とします。これは組織によって異なりますが、一般的にはビジネスの規模、変更の予想リスク、潜在的な財務的影響、および変更のスコープに依存します。

5）実装の調整

認可後、変更要求または変更レコードは、変更の構築、テスト、およびデプロイのための適切な技術・アプリケーション管理チームとの調整・協力のためにリリースおよびデプロイメントプロセスに引き渡されます。各変更には、実装失敗に備えた修復計画を事前に準備しておく必要があります。構築とテストが完了したら、リリースおよびデプロイメントは変更マネージャーに結果と推奨される実装要件を通知する必要があります。変更マネージャーは、推奨される実装要件とビジネスリスクの管理に基づいて各変更をスケジュールする必要があります。変更マネージャーは、変更スケジュール（FSC：Forward Schedule of Changes）または変更スケジュールを使用して、影響を受ける可能性のあるすべてのステークホルダーに今後の変更を通知します。FSCは、予測されるサービス停止（PSO）や予想されるサービス可用性の偏差とともに、変更実装の調整時に考慮されます。リリースおよびデプロイメントは、実装とトレーニングニーズの調整を担当します。

6）変更要求のレビューおよびクローズ

変更の完了後、詳細な実装結果のレビューである実装後レビュー（PIR）を実施し、変更が目標を正常に達成したことを確認する必要があります。実装が成功した場合、かつその変更がサービスのエラー修正に関連していた場合、関連するすべての問題と既知のエラーはクローズされる必要があります。成功しなかった場合は、修復計画を適切に発動する必要があります。

変更管理ポリシーもプロセスを支援するために定義される必要があります。このポリシーには、緊急変更の定義、プロセスの明示的なメリット、変更とITILに親和性の高いビジネス文化の醸成、さまざまな変更管理活動に対する役割と責任の確立、認可されたスタッフへの変更管理アクセスの制限、リスク管理、およびパフォーマンス測定などが含まれる場合があります。

相互関連するITILプロセス

変更管理は、問題管理および構成管理を含む、サービスライフサイクル全体にわたる他のITILサービス管理プロセスと連携します。

1）問題管理

問題を解決するためには、回避策の実装および既知のエラーの解決に向けた変更が必要となる場合が多くあります。問題管理は、問題やインシデントを引き起こしているITインフラのエラーを解決するためにRFCを提出することができます。問題管理は、通常、標準、または緊急変更プロセスを使用して機能します。いずれの場合もRFCの提出が必要です。

2）構成およびアセット管理

変更管理は、ITインフラへの変更の影響を評価する際に、CMDB内の構成管理情報に依拠します。変更によって影響を受けるCIを特定することが不可欠です。影響を受ける構成アイテム（CI）に関連する情報も、変更管理プロセス全体を通じて更新されます。

3）リリースおよびデプロイメント管理

変更管理は変更を管理し、リリースおよびデプロイメントプロセスとの連携により構築、テスト、および実装を調整します。この2つのプロセスは非常に緊密に統合されており、引き継ぎの観点から1つのプロセスのように見えるべきです。これはサービス指向を促進し、いわゆる「フェンス越しに投げる」方式と呼ばれる実装へのプロセスサイロを排除するのに役立ちます。

4）ITサービス継続管理

ビジネスに悪影響を与えるリスクを最小化・管理するために、ITサービス継続管理は必要なITサービスが合意された最小サービスレベル内で再開されることを確保します。ITサービス継続管理には、正確性を維持するために定期的な更新を必要とする多数の手順が関連しています。これらの更新と変更は変更管理プロセスによって管理されます。

5）セキュリティ管理

発生するすべての変更は、セキュリティへの影響について評価されます。

6）ナレッジ管理

変更に関する意思決定支援を確保するために役立ちます。これには、サービス指向の意思決定に向けたデータ、情報、およびナレッジの発展に向けた他のプロセス領域との調整および協力が含まれます。

7）リクエスト履行

ユーザーは、管理が必要なITサービスまたは構成アイテムへの変更をリクエストする場合があります。変更管理は、変更のリスクが特定の変更を通常変更として管理することを必要とするまで、またはその場合を除き、これらの変更のほとんどを標準変更として管理します。

8）ポートフォリオ管理

ポートフォリオ管理は、さらなる処理のために変更管理に変更提案を提出します。

変更管理の役割と責任

明確に定義された役割と責任が、変更管理の成功につながります。各組織が独自の要件を決定しますが、変更管理チームには一般的に以下の役割が存在します。

1）変更申請者／起票者

変更を要求する個人またはビジネスユニット。

2）変更諮問委員会（CAB）

変更評価を実施するビジネス、財務、および技術担当者で構成されるグループ。変更マネージャー／権限者は通常、変更諮問委員会（CAB）の議長を務め、メンバーには顧客、経営陣、開発者、コンサルタント、技術スタッフ、および非IT部門のオフィススタッフが含まれる場合があります。代表者のグループは、検討中の変更の種類によって異なります。各CAB会議は、議論すべき変更トピックに優先順位を付けるCABアジェンダによって進行されます。緊急変更が発生した際に迅速に招集できる緊急変更諮問委員会（ECAB）も設置される場合があり、この編成はポリシーに含まれる必要があります。CABは変更管理プロセス自体の改善にも活用できます。

3）変更オーナー／マネージャー／権限者

変更マネージャーまたは変更権限者は、変更管理プロセスのオーナーです。この担当者はすべての変更要求をレビューし、情報が不十分なリクエストを拒否し、CAB会議を主導し、関連するCABメンバーを特定し、変更スケジュール（FSC）を作成・管理し、変更の調整のための連絡役を担い、実装された変更をレビューし、PIRを管理し、RFCをクローズし、経営レポートを提出します。一部の組織では、変更オーナーと変更マネージャー／権限者が別々に存在します。オーナーはプロセスの有効性とその改善に対して責任を持ち、マネージャーはプロセスの実行に対して責任を持ちます。1つの役割のみが存在する場合、その役割がすべての責任を担います。

変更管理の主要業績評価指標（KPI）

各ITILプロセスは、コスト削減、可用性と信頼性を含むサービス価値の向上における成功について測定される必要があります。サービスコンシューマライゼーションのトレンドを特定し、変更の影響を測定し、変更に起因するビジネス中断の削減を実証することは、変更管理の成果をビジネス目標に結びつけるための重要な改善事項です。

変更管理プロセスにおける重要な変更管理KPIおよびメトリクスには以下が含まれます。

• サービス市場性の向上
• 実装された変更の成功件数
• サービス中断件数の削減
• 未承認変更件数の削減
• 変更要求バックログの減少
• 変更に関連するインシデント
• 変更実装にかかる平均時間
• 変更成功率
• 失敗した変更によって引き起こされた中断（インシデント、問題）の件数
• 変更の頻度と量
• 計画的変更と非計画的変更の比率

変更管理の導入と実装におけるベストプラクティス

変更のスピードはかつてないほど速まっており、高品質な変更管理プロセスを実装することで、絶え間ない変更への対応が大幅に管理しやすくなります。ITILのプロセスを導入することは容易ではなく、変更管理も例外ではありません。それは相当な規模の戦略的プロジェクトです。変更ガバナンスに向けた経営幹部および上層管理職からのサポートを得ることは、フレームワークの実装と遵守の両方を期待するスタッフからの賛同を獲得するうえで不可欠です。変更管理の導入は、各ステークホルダーにとっての価値として示される必要があります。また、ITILプロセスをサポートするためのITサービス管理ソリューションを整備するとともに、実装を調整するための専任プロジェクト管理体制を確立することも重要です。

1）ビジネスケースを構築する

変更管理は把握が難しい概念となる場合があります。適切に構造化された変更管理プロセスの目的とメリットを組織のあらゆる階層と共有し、組織リーダーからの賛同を得て、指揮系統を通じて浸透させていきます。すべてのステークホルダーを巻き込むことが、変更管理成功の基盤となります。

2）組織における「変更」を定義する

取り扱う各変更タイプの種類と基準を定義します。

3）主要な役割と責任を定義する

変更マネージャー、変更諮問委員会（CAB）メンバー、およびエグゼクティブスポンサーを含む、変更管理プロセスに関わるすべての担当者の役割と責任を明確に特定します。

4）変更管理プロセスを設計する

上記で特定された各変更タイプには、申請者とサポートスタッフの期待値を設定するのに役立つプロセスが必要となります。これらのプロセスは、自動化された管理のためにITSMソリューションに実装することができます。

5）主要業績評価指標（KPI）を定義する

ビジネスステークホルダーにとって重要な測定指標を特定します。これらを活用して改善を実証し、その成果を共有します。

6）継続的サービス改善を実装する

変更管理プロセス、関与する人材、および使用するテクノロジーは、定期的にパフォーマンスの監査またはレビューを実施し、運用効率を確保するための改善を継続的に行う必要があります。

7）リスク許容レベルを理解する

これは、組織のガバナンスおよび／またはさまざまな変更タイプを適切に処理するうえでの変更管理プロセスの成熟度に基づいて決定することができます。

変更管理ソフトウェアの機能チェックリスト

変更管理ソフトウェアおよび／または変更管理機能を提供するITサービス管理スイートを評価しているIT組織にとって、以下の機能は主要なプロセスを効果的にサポートするうえで重要、あるいは不可欠です。

変更管理ソフトウェアは最低限、管理者が以下を実行できるようにする必要があります。

• 変更プロセスの設定
• 変更分類の設定
• 変更要求の作成、修正、解決、およびクローズ
• ITILまたはその他の業界ベストプラクティスフレームワークの実装
• RFC内でのバックアウト手順、インストール、および引き継ぎの文書化
• 変更の先行スケジュールの作成
• メンテナンス活動などの定期的なイベントのスケジュール設定
• 関連するCIに変更を加える際の影響を受けるCIの特定
• インシデント／問題レコードからのフィールド自動入力によるRFCの作成
• RFCが更新された際の適切な担当者への自動通知
• 変更管理レポート、KPI、およびダッシュボードの生成
• インシデント管理、問題管理、構成管理、リリース管理、およびサービスレベル管理との統合
• 変更要求内からの影響を受けるCIの確認
• 問題およびインシデントと変更要求のリンク
• 必要に応じたステークホルダーおよび変更諮問委員会（CAB）への積極的な通知
• ロールベースの作成、更新、および承認の活用
• 変更プロセスの一部としてのリリースおよびデプロイメント管理のサポート
• CIに対して未承認の変更が行われた際の変更作成の自動化
• 競合が存在する場合の変更のスケジュール変更
• 自動承認ワークフローの設定
• 複数承認者への割り当て
• 応答タイムラインの設定および必要に応じた自動リマインダーの送信
• フリーテキスト、ドロップダウン、日時、添付ファイル、スクリーンキャプチャを含む柔軟なフィールド設定の活用
• 監査ログ内の履歴データの自動記録へのアクセス
• 適切な承認段階を通じたリクエストの自動進行
• 各変更要求に関連付けられた固有のレコード番号の生成