変更管理運用ガイド

 変更管理とは
 変更管理の概要
 変更管理プロセス
 推奨トレーニング コース

変更管理は、IT 環境に変更をすばやく導入して、サービスの中断時間を最小限に抑えることを狙いとするプロセスです。技術、システム、アプリケーション、ハードウェア、ツール、ドキュメント、およびプロセスに関する変更、さらに役割と責任に関する変更が、変更管理の対象となります。変更管理では、変更要求を迅速かつ効率的に処理することが課題となります。

変更管理プロセスでは、実施が予定されている変更の影響を受けるすべての関係者にその影響を認識および理解させることが重要な目標の 1 つとなります。ほとんどのシステムは互いに密接な相関関係にあるので、システムのある部分に対する変更がほかの部分やほかのシステムに大きな影響を与える可能性があります。変更管理では、変更を実施する前に、その影響を受けるすべてのシステムとプロセスを特定することで、悪影響を緩和または排除することを目指します。

変更管理プロセスは、すべての変更要求を受け取って変更管理ログに記録します。それらの変更要求を評価し、承認するか却下するかを判断した上で、承認済み変更要求の実施時期をスケジューリングします。承認済み変更要求は、ソフトウェア コンポーネントおよびハードウェア コンポーネントの調達や開発を担当するグループに渡されます。標準変更以外の変更を計画および実施する権限は、リリース管理に付与されます。標準変更は、サービス デスクなどの適切なグループに委ねられます。標準変更については、このドキュメントで後述します。

変更管理では、開発/調達から実施に至るまでの変更プロセスを監視します。また、プロセス全体に関する情報が適切に変更管理ログに記録されるように保証します。このログには、変更に関して、変更要求ステータス、スケジュール情報、および作業指示などの情報が記録されます。変更管理は構成管理と密接に連携して、IT コンポーネントに対するすべての変更が構成管理データベース (CMDB) に適切に記録されるように保証します。CMDB は、IT 環境の全コンポーネントのステータスを追跡するためのリポジトリです。詳細については、構成管理プロセスに関するドキュメントを参照してください。

ハードウェア、ソフトウェア、およびそれらのドキュメントなど、IT 環境におけるあらゆるコンポーネントが構成項目 (CI) となります。これらの CI が CMDB に記録されます。変更マネージャと変更オーナー (変更の実施担当者) は、IT 環境に対して実施または削除する CI とそれらのステータスなどの情報を構成管理に渡さなければなりません。

変更管理では、変更実施後に、変更プロセス全体のレビューと評価を行います。

IT 環境下で変更を正しく実施するには、組織内の多くの活動を取りまとめる必要があります。図 1 は、変更管理とその他の MOF プロセスの間の関係を図示しています。

図 1: リリース管理、変更管理、構成管理、およびその他の関連プロセスの間の関係
拡大表示する

可用性管理
可用性管理では、IT コンピューティング環境の可用性と信頼性を管理します。可用性コーディネータとの間で変更要求評価プロセスを取りまとめて、提案された変更の実施により IT 環境の可用性と信頼性が受ける影響を確認する必要があります。可用性管理では、変更要求が頻繁に発生します。

キャパシティ管理
キャパシティ管理では、現在のシステムにおけるリソース使用量が上限に近づいた際のリソース追加を計画することにより、業務上の必要条件を満たすための適切な IT リソースの可用性を保証します。キャパシティ マネージャは、変更要求をレビューして、変更の実施により既存の IT インフラストラクチャのパフォーマンスとキャパシティが受ける影響を確認します。さらに、キャパシティ コーディネータが変更実施後に IT インフラストラクチャを評価して、IT 環境が実際に被った影響を調査します。キャパシティ管理では、変更要求が頻繁に発生します。

構成管理
構成管理は、ハードウェア、ソフトウェア、ドキュメントなど、IT 環境のコンポーネントの追跡とアカウンティングを行うプロセスです。すべての IT 関連コンポーネントを追跡するための CMDB は、構成管理を通じて維持されます。

IT 環境の基準評価は、構成コーディネータが担当します。変更管理では、この基準評価に基づいて、変更が及ぼす影響を評価します。

構成管理では、変更プロセスおよびリリース プロセスの進行中に CMDB を更新し、IT システム コンポーネントに関する変更をすべて反映させると共に、コンポーネントのステータスをドキュメント化する必要があります。

ネットワーク管理
ネットワーク管理は、組織内のすべてのネットワーク管理を設計および管理するプロセスです。ネットワーク コーディネータは、すべてのシステム ネットワークに対して変更要求が及ぼす影響の評価を担当します。ネットワーク管理では、変更要求が頻繁に発生します。

問題管理
問題管理では、問題の根本的な原因を究明します。ここで、「問題」とは、同様な症状を伴う 1 つまたは複数のインシデントを意味します。問題管理で提案されたソリューションが変更要求になることが多いため、問題管理と変更管理の間には密接なつながりがあります。

リリース管理
リリース管理では、IT 環境に対するリリースの取りまとめと管理を行います。IT 環境内で変更を実施することが承認された後、そのリリースを計画および実施するための権限がリリース管理に与えられます。

セキュリティ管理
セキュリティ管理では、IT 環境の安全性とセキュリティを確保するためのセキュリティ制御手段 (ソフトウェア制御手段や技術インフラストラクチャなど) を開発、実施、および管理します。変更管理が変更要求を承認する前に、必ずセキュリティ コーディネータが変更要求をレビューして、IT 環境に対する変更の影響を評価しなければなりません。また、変更実施後には、その都度、セキュリティ コーディネータがシステムのセキュリティを評価します。

サービス デスク
サービス デスクは、質の高いユーザー サポートとインシデント管理を効率的かつタイムリーに提供する責任を負います。ユーザー コミュニティからのフィードバックはサービス デスクを通じて収集され、その結果として、変更要求が頻繁に発生します。サービス デスクは、変更管理の承認を得た後、IT 環境に対して標準変更を実施します。

 ページのトップへ

変更管理では、IT 環境を変更による悪影響から保護することに主眼を置きます。変更管理には、以下の目標があります。

• 標準化された包括的なアプローチで IT 環境に対する変更を実施できるようにすること

• IT 環境への悪影響を最小限に抑えること

• すべての変更要求を効率的かつ迅速に処理すること (変更要求の評価と承認)

• 実施スケジュールを確立すること

• 変更によって影響を受ける各関係者とのコミュニケーションをとること

• IT 環境に対する変更の計画、開発、テスト、および実施の活動状況を監視すること

• 変更プロセスをレビューおよび評価すること

変更管理は、変更プロセスを管理する責任を負います。変更管理は、リリース管理および構成管理と特に密接な関係にあります。変更管理には、提案された変更が IT 環境に及ぼす影響の評価、変更の優先順位付けと分類、方針の決定、変更の計画から開発とテストを通じて実施に至るまでのプロセスの監視が含まれます。変更管理プロセスを通じて不必要な変更の数を減らすことで、サービス可用性と IT 効率を向上できます。

変更管理の対象になるのは、以下に該当する変更です。

• 変更により複数のユーザーが影響を受ける。

• 変更により基幹的な機能が使用できなくなる可能性がある。

• 変更に伴い、ハードウェア (サーバーなど) やソフトウェアの変更が必要になる。

• 変更に伴い、操作やプロセスに関する変更が必要になり、複数のユーザーが影響を受ける。

スケジュールに基づく定期的な保守、実行頻度の高い管理タスク、パスワードの変更などのマイナーなサービス要求は、変更管理の対象外です。

ここで言う "変更" とは、IT 環境に対する変更のうち、IT サービス レベル契約 (SLA) に影響を及ぼす可能性があるあらゆる変更を意味します。ハードウェア、ソフトウェア、システム コンポーネント、ドキュメントなどに対する変更が含まれます。変更には、恒久的変更と一時的変更があります。恒久的変更は、現在のコンポーネントを完全に置き換える変更です。一時的変更は、恒久的変更が実施可能になるまでの暫定的変更か、または特別な目的で一時的に実施される変更です。

変更管理の役割と責任
変更管理には、以下の 3 つの重要な役割があります。

• 変更イニシエータ

• 変更マネージャ

• 変更オーナー

変更管理プロセスそのものの管理は、一般に、2 つの委員会が担当します。以下の委員会です。

• 変更諮問委員会 (CAB : Change Advisory Board)

• IT 実行委員会

変更イニシエータは、変更要求を提出して変更プロセスを開始します。変更マネージャは変更プロセス全体を管理し、変更オーナーは変更の計画と実施を担当します。また、変更の承認、スケジューリング、および評価に際しては、CAB と IT 実行委員会が重要な役割を果たします。それぞれの役割については、次の節で詳細に述べます。

変更管理に関連する役割と責任を次の表にまとめて示します。

表 1 変更管理の役割と責任

変更イニシエータ
変更要求を提出する権限は、組織内のどの人員にも付与する必要があります。マネージャ レベルより下位の社員が変更要求を提出する際には、まず直属のマネージャに対して変更要求を提出し、承認を受けた上で変更マネージャに変更要求を渡すようにすることをお勧めします。変更イニシエータは、変更要求フォームに必要事項を漏れなく書き込む必要があります。変更要求の理由、要求する実施日、変更によって影響を受けるシステムや人員などの情報の記入が必要です。変更イニシエータには、変更が承認されたかどうかが通知され、変更プロセスが完了するまでの間、変更要求のステータスが継続的に通知されます。変更イニシエータは、変更マネージャ/CAB が変更要求の優先度を決定する際や、変更プロセスを終了時にレビューする際に手助けをします。

変更マネージャ
変更マネージャは、変更管理プロセス活動の管理を担当します。変更要求の受け付けから IT 環境に対する変更の実施に至るまで、プロセス中のあらゆる段階に関与します。どの変更についても、IT 環境への適切な実施に関する最終的な責任は、変更マネージャが負います。変更マネージャは、多くのタスクを受け持ちます。以下のようなタスクがあります。

• 変更要求を受け取って、それらが変更管理ログに適切に記録されるように保証する。

• 変更要求に記載漏れがないことをチェックする。

• CAB メンバを選別し、CAB ミーティングを円滑化する。

• CAB ミーティングの議事日程を作成し、委員会ミーティングに先行して必要なレビュー情報を CAB メンバに提供する。

• 必要に応じて、変更要求の影響分析とリスク評価を実施するチームを割り当てる。

• 変更要求の分析、優先度付け、分類、承認、およびスケジューリングを行う。

• 影響を受ける各関係者に変更通知を伝達する。

• 変更の管理、構築、テスト、および実施を含めて、すべての変更要求が問題なく完了したかどうかを監視し、これらのプロセスが変更スケジュールに従うように保証する。

• 変更プロセスをレビューおよび評価する。

変更オーナー
変更オーナーは、IT 環境内の変更の計画と実施を担当します。主要な変更や小規模な変更の場合はリリース マネージャが変更オーナーになり、新しい PC の環境設定などの標準変更の場合はサービス デスクが変更オーナーになることが考えられます。変更オーナーは、変更マネージャまたは CAB から変更を受け取り、CAB によって定義された変更スケジュールに従います。変更オーナーは、割り当てられた変更の開発/調達、テスト、および実施の取りまとめを担当します。

変更オーナーは、変更マネージャにプロジェクト ステータスのフィードバックを返し、発生した問題を特定します。変更オーナーは、変更イニシエータと連携して、変更が変更イニシエータの要求条件に一致するように保証すると共に、問題を修正し、変更要求の意図に沿った正しいシステム強化を提供しなければなりません。変更オーナーは、変更実施後、変更マネージャが変更プロセスを評価する際の手助けをします。

CAB ( 変更諮問委員会 )
IT 環境のどのコンポーネントと組織内のどのグループが影響を受けるかは、変更要求によって異なります。このため、CAB のメンバ構成は、変更要求の対象範囲に依存します。リリース、キャパシティ、構成、ネットワーク、システム管理の各マネージャは、中心的なメンバとして常に CAB に参加します。CAB のその他のメンバは、各変更要求を効果的に評価するために必要な実地知識および変更の影響を直接受ける部分に応じて選定します。

幅広い実地知識が得られるように、CAB には幅広い分野からメンバを集める必要があります。業務要件、ユーザー コミュニティ、および IT システム テクノロジに精通したメンバが必要です。組織のアプリケーション開発、テスト、およびサポートのスタッフもメンバに含める必要があります。さらに、変更の影響を受ける組織内グループの代表者も CAB に参加させます。各変更に対応する CAB メンバの選定は、変更マネージャが担当します。ハードウェアやソフトウェアに関する大規模な変更に際して、変更マネージャが必要と判断した場合は、 OEM ベンダの代理人も CAB に参加させます。これにより、ベンダと組織の間のコミュニケーションとタスクの取りまとめを円滑に進めることが可能になります。また、ベンダの代理人を CAB に参加させれば、変更プロセスおよびリリース プロセス中に発生した問題を円滑に解決できるようになります。

変更マネージャに承認権限のない変更要求は、CAB に提出されます。大規模な組織では、CAB ミーティングを定期的に (毎週など) 開催して、変更要求のレビュー、優先度付け、承認、およびスケジューリングを行うことが望ましくなります。CAB が変更要求を承認するには、予算やリソースに関連する意思決定を行う権限が必要です。CAB では、変更プロセス全体を通じて各変更のステータスをレビューする、承認したスケジュールを基準として進行状況を評価する、特定された問題の修正方法を決定する、調査結果を適切なマネージャおよび関係者との間でやり取りするなどの活動も行います。

組織の IT においてリーダー的な立場にあるメンバ (IT ディレクタなど) を CAB のメンバに加えることが特に重要です。CAB で決定を下せない変更がある場合は、変更を承認するかどうかをこのメンバが最終的に判断することになります。

CAB のメンバは、日常業務の合間を縫って CAB に参加することになるので、CAB メンバとしての責任を果たすことにあまり多くの時間を割くことができません。変更マネージャが CAB ミーティングをスケジューリングし、議事日程を作成する際には、このことを念頭に置く必要があります。

CAB は、変更マネージャに承認権限のない緊急の変更を評価および承認します。このような性質の変更は、環境への影響が大きかったり、組織リソースを大量に消費したりすることになります。CAB のメンバには、急を要するミーティングに参加したり、電子メールなどのコミュニケーション形態で意見を提出したりするなどの柔軟性が求められます。

IT 実行委員会
IT 実行委員会は、IT 環境に対する主要な変更の承認機構として機能し、CAB が実行するのと同じ分析タスクおよび承認タスクを実行します。承認後には、CAB が変更要求をスケジューリングし、変更プロセスを監視します。IT 実行委員会には、組織内のすべての IT グループから代表者が参加します。主に、予算やリソースに関連する意思決定を行う権限を持つマネージャがこれらのメンバとなります。

変更の優先度付け
変更には、緊急度と影響度に応じた優先度を付けます。次の図に示すように、変更は、まず最初に緊急の変更と緊急でない変更に分類されます。

図 2: 変更要求の優先度付けと分類

緊急の変更とは、基幹的な機能に影響する問題が IT 環境に発生しており、その問題をできるだけ早期に解決するために実施する必要のある変更を意味します。緊急の変更は、緊急変更プロセスに沿って実施されます。

緊急以外の変更は、優先度「高」、「中」、「低」のいずれかに区分されます。各優先度の例を以下に示します。

• 高優先度 基幹的なサーバーに関する問題を修正するために提案された変更は、高優先度の変更に分類されます。

• 中優先度 少数のユーザーに影響を及ぼす変更は、中優先度の変更に分類されます。

• 低優先度 次回のメジャー リリース時期まで先送りできる変更は、低優先度の変更に分類されます。

CAB が変更をレビューする順序、さらにその後、変更を実施する順序は、これらの優先度によって決まります。

変更の分類
変更は、「主要」、「大幅」、「小規模」、「標準」の 4 つに分類されます。変更の分類は、組織に及ぼす影響と、変更を計画、開発および実施するために必要になるリソースによって決まります。各分類の説明は、以下のとおりです。

主要な変更
主要な変更とは、IT 環境に大きな影響を及ぼすか、計画、開発、および実施に大量のリソースを要する変更を意味します。主要な変更には、新しいシステム機能の導入や既存の機能の強化が含まれます。これらの変更は、IT 実行委員会の承認を受ける必要があります。承認された主要な変更は、CAB に渡され、スケジューリングが行われます。その後、リリース管理に渡され、計画と実施が行われます。

重大な変更
重大な変更とは、計画、開発、および IT 環境内での実施に大量のリソースを要する変更を意味します。重大な変更は、変更マネージャのレビューを経て CAB に渡され、分析と承認を受けます。

小規模な変更
小規模な変更とは、多くのリソースを必要としない変更を意味します。小規模な変更は、IT 環境への影響が少なく、環境内のごく少数のユーザーにしか影響を及ぼさないのが普通です。小規模な変更の承認権限は、変更マネージャに委任するのが妥当です。この権限を委任されたマネージャは、その場で変更を承認することもできれば、変更を CAB に提出して、レビューと承認を仰ぐこともできます。

標準変更
標準変更とは、確立され文書化されたアプローチに従って実施される変更を意味します。ほとんどの場合、標準変更は、IT 環境の信頼性に悪影響を及ぼしません。標準変更は、変更マネージャの承認を受けた後、変更の計画と実施の権限があらかじめ付与されている適切な変更オーナー (サービス デスクなど) に渡されます。たとえば、新入社員用の PC をセットアップして環境設定するなどの処理は、標準変更として扱われます。

 ページのトップへ

変更管理には、以下の 7 つの活動項目があります。

• 変更要求の受付

• CAB/IT 実行委員会による変更の分析とレビュー

• 変更の通知とリリース

• 変更の開発、テスト、および実施の監視

• 変更結果の通知

• 実施後の評価

• 緊急変更プロセス

各活動項目は、変更管理プロセスと一体化しています。以降の節では、フロー図を交えて、変更管理におけるこれらの 7 つの活動項目のそれぞれについて説明します。

変更要求の受付
次の図は、変更要求の受付およびレビューのプロセスを示しています。

図 3: 変更要求の受付

変更マネージャは、受け付けた変更要求をその都度、変更管理ログに記録します。変更マネージャは、変更プロセス全体を通じて変更要求のステータスを変更管理ログに記録しなければなりません。

変更マネージャは、すべての変更要求をレビューして、記載漏れがないこと、実現可能な変更であることをチェックします。変更マネージャは、却下した変更要求を説明付きで変更イニシエータに返却し、承認した変更要求に優先度を付けます。

優先度緊急の変更要求は、適切なグループに渡されます。その他の優先度の変更要求は、CAB による分析と承認を受けた後、変更マネージャによって分類され、適切な変更オーナーに渡されます。

変更の提出
前述したように、組織内のどの社員も変更要求を提出できます。どの社員が変更マネージャに直接変更要求を提出でき、どの社員が直属の上司 (マネージャ) に変更要求を提出してレビューを受ける必要があるかを区別するためのガイドラインを制定することも、変更マネージャの仕事の 1 つになります。上司によるレビューは、検討に値しないような変更要求が変更マネージャに殺到するのを防ぐためのフィルタとして機能します。レビューにあたるマネージャは、承認した変更をすべて変更マネージャに渡します。

問題管理では、多数の変更要求が発生します。これらの変更要求を変更管理ログに入力する際は、問題管理プロセスで変更要求と問題番号を相互参照および追跡できるように、問題番号を付記しておく必要があります。変更プロセス全体を通じて、変更のステータスと実施に際して発生した問題に関する最新情報を常に問題管理に伝達する必要があります。

変更要求フォームの内容
変更要求は、要求のステータスを開始から完了まで追跡するための公式レコードとして機能します。変更要求は、紙のフォーム (用紙) で提出することも、電子的に提出することもできます。図 4 に示すように、変更要求フォームには、変更マネージャ/CAB が要求を評価するために必要十分な情報の記入欄を用意する必要があります。同時に、記入の容易さも考慮しなければなりません。最初の 3 つのセクションは、変更イニシエータが記入します。

フォームの最初のセクションには、変更イニシエータに関する情報と望ましいと思われる変更優先度の記入欄があります。変更マネージャは、要求を最初に評価するときに、その優先度レベルを承諾するか、または適切に調整します。また、変更マネージャは、受け付けた変更要求を最初に文書処理するときに、変更要求番号をフォームに記入します。

フォームの 2 番目のセクションには、変更の説明、変更を要求する業務上の理由、および変更の影響を受けるプラットフォームとユーザーに関する情報の記入欄があります。影響を受けるプラットフォームには、ハードウェア、ソフトウェア、データベースなど、その変更に影響されるコンポーネントがすべて含まれます。変更イニシエータは、さらに、変更実施時に問題が生じた場合の取り消し計画をこのセクションに記入する必要があります。ただし、変更の開発とテストを完了しない限り、このような計画を立てられない場合もあります。たとえば、新しいアプリケーションの開発または調達が必要になる変更の場合は、アプリケーションをテストしなければ取り消し計画を策定できません。

フォームの 3 番目のセクションには、変更の実施に伴う影響と必要なトレーニングに関する情報の記入欄があります。大規模な変更の場合は、変更要求影響分析のほか、構成管理基準レポートなどから得られた補足情報に基づいて、CAB が影響を評価することが多くなります。

変更要求フォーム

図 4: 変更要求フォームのサンプル

4 番目のセクションには、変更オーナー、サポート担当者、およびバックアップ担当者に関する情報の記入欄があります。変更イニシエータが記入した者とは異なる変更オーナーが変更マネージャ/CAB によって指名されることがあります。問題発生時に必要なリソースを確保できるように、サポート担当者の名前を連絡先情報と共に指定する必要があります。

最後のセクションは、変更マネージャが記入します。実施日は、変更マネージャ/CAB が提示した予定日とします。変更マネージャは、実施完了後にその結果を記録します。実施に失敗した場合は、失敗の理由と次にとるべき処置に関する詳細な情報を記入する必要があります。

変更イニシエータは、できるだけ詳細な情報を提示します。フォームを記入する際に不明な点がある場合は、サービス デスクが手助けをします。変更要求の受付後に、変更マネージャが情報を補足しなければならなくなることがあります。たとえば、変更要求が IT 環境に及ぼす影響や変更を実施するために必要となるリソースを変更イニシエータとサービス デスクが正確に把握しているとは限りません。

変更の記録 / 変更管理ログ
変更要求を受け付けた変更マネージャは、要求に一意な識別番号を割り当てて、変更管理ログに要求を記録します。変更プロセス中は、開始、終結、承認、却下、保留、遅延など、変更のステータスを更新します。このように更新しておけば、変更ログを閲覧することで、すべての変更要求のステータスをすばやくチェックできるようになります。問題レコード (PR) への解決策として提出された変更の場合は、PR ステータス追跡用の相互参照として、PR の番号も変更管理ログに記録します。

変更管理ログには、少なくとも以下の情報を維持します。

• 一意な識別番号

• 変更イニシエータの氏名、役職、および連絡先情報

• 変更オーナーの氏名、役職、および連絡先情報

• 変更要求開始日

• 変更要求の説明

• 変更要求終結日

• 変更要求ステータス

• PR 番号 (問題レポート発行の場合)

• プロセス中に発生した問題の説明

変更プロセス全体を通じて、発生した問題を反映するようにログを更新します。

変更ログは、作業指示のステータス追跡にも使用されます。指示の発行日時、指示のステータス、問題、および指示の終結日時に関する情報を変更ログに含めます。変更ログには、変更要求スケジュールも記録され、変更プロジェクトの現在のステータスを反映するように定期的に更新されます。

変更マネージャによる変更のレビュー
変更マネージャは、変更要求を変更管理ログに入力した後、変更要求に記載漏れがなく、実現可能であるかどうかをレビューします。記入にミスや漏れのある変更要求は、変更イニシエータに返却して修正させます。この場合、変更ログのステータスは、"保留" に更新します。たとえば、IT 環境が受ける影響に関して十分な情報を変更イニシエータが提示しなかった場合などに、変更要求が返却されます。変更マネージャは、実現性に乏しい要求や不必要な要求を却下し、その理由を明示します。この情報は変更イニシエータに公開し、変更ログに記録します。このレビューを通じて受理した変更は、ログ内で "レビュー済み" として分類されます。

初期優先順位付けと分類
変更マネージャは、変更イニシエータの協力の下、レビューの結果、記載に漏れがなく実現可能であることが確認された変更のそれぞれに初期優先度を割り当てます。

変更マネージャと変更イニシエータは、変更に高、中、低のいずれかの優先度を付与します。このときに考慮すべき要因としては、組織の業務ニーズ、変更の実施までに要する時間、現在計画と実施を勧めているその他の変更があります。

次に、変更マネージャは、変更要求を緊急の変更として分類すべきかどうかを判断します。緊急の変更は、後述の緊急変更プロセス (本書の 2.3.8 項参照) に沿って実施されます。その他の変更は、小規模な変更、重大な変更、主要な変更、標準変更のいずれかに分類されます。

小規模な変更を承認およびスケジューリングする権限と標準変更を組織内の適切なグループに渡す権限は、変更マネージャが必要に応じて事前に委任します。権限を委任した場合は、次回の CAB ミーティングで CAB に対して適切な通知を行う必要があります。

重大な変更または主要な変更と分類された変更要求は、CAB または IT 実行委員会に提出して、レビュー、承認、およびスケジューリングされます。変更マネージャ、CAB、IT 実行委員会のいずれが変更要求に優先度と分類を割り当てた場合でも、それらの割り当てを反映するように変更ログを更新しなければなりません。

CAB/IT 実行委員会による変更の分析とレビュー
CAB および IT 実行委員会は、変更マネージャが処理できない変更の評価と承認を担当します。図 5 に示すように、これらのグループでは、変更の計画、開発、テスト、および実施に伴う緊急度、リスク、潜在的影響、コスト、および必要リソースを評価します。その評価結果に基づいて、変更要求を承認するか却下するかが決定されます。

図 5: CAB/IT 実行委員会による変更の分析とレビュー

却下された変更要求は、説明付きで変更イニシエータに返却されます。却下理由をより明確にする必要がある場合、変更イニシエータは、要求を再提出できます。承認された変更は、適切な変更オーナーと適切な組織に渡されます。

CAB ( 変更諮問委員会 ) のミーティング
前述したように、組織の規模と提出中の変更要求の数に応じて定期的に (毎週など) CAB ミーティングが開催されます。CAB ミーティングのスケジューリング、取りまとめ、および円滑化は、変更マネージャが行います。CAB の承認を要する緊急変更要求の場合は、変更マネージャが緊急 CAB ミーティングを召集したり、電子メールやテレフォニー システムを通じて評価と承認を指揮することがあります。

定期的な CAB ミーティングの活動項目には、以下の項目があります。

• 新規提出された変更要求と再提出された変更要求の評価および承認

• 変更要求のスケジューリング

• 既存の変更プロジェクトの評価と問題修正の円滑化

• 完了した変更要求のレビュー

• 問題なく完了した変更要求の終結

変更要求評価時、CAB は主に以下の項目を分析します。

• 変更の実施が IT 環境の運用信頼性に及ぼす影響

• 変更を実施しない場合にビジネス プロセスが受ける影響

• 人員、インフラストラクチャ、および予算など、必要なリソース

• 取り消し計画の信頼性

IT 実行委員会は、主要な変更を評価します。さらに、承認した変更要求を CAB に渡し、CAB によるスケジューリングに委ねます。

レビューと分類
付加的な情報が必要になった場合、委員会は、変更マネージャに対し、作業指示を発行して情報を収集するように求めます。その後、変更マネージャは、収集した情報をすべての変更要求関連情報と共に CAB または IT 実行委員会のメンバに提出して、レビューを受けます。この情報は、ミーティングに先行して委員会のメンバに公開する必要があります。

CAB または IT 実行委員会が判断を下す前に変更イニシエータからの付加的情報が必要になった場合は、変更要求が説明付きで変更イニシエータに返却されます。変更イニシエータは、必要な修正を変更要求に加えた後、変更要求を変更マネージャに再提出して、再レビューを仰ぐことができます。CAB または IT 実行委員会が変更要求を却下した場合にも、変更要求が説明付きで変更イニシエータに返却されます。

承認された変更は、変更要求に割り当てられた緊急度、影響分析の結果、変更要求に提示されているリソース要件に関する情報と変更マネージャによって収集された情報に基づいて、主要な変更、重大な変更、または小規模な変更のいずれかに分類されます。委員会は、変更の分類を行った後で、変更オーナーを割り当てます。プロセス内のこの時点では、リリース マネージャが変更オーナーになるのが普通です。

スケジュール
CAB は、標準変更として渡された変更要求を除く変更要求をすべてスケジューリングします。標準変更は、変更マネージャがスケジューリングします。変更のスケジューリングに際しては、変更に割り当てられている優先度が重要な役割を果たします。CAB が優先度を割り当てる際には、変更の実施に要する時間と関連する業務要件を考慮する必要があります。また、影響を受けるグループとの間で変更のスケジューリングを調整することも必要です。

リリースに対する変更の割り当ては、つぶさに監視する必要があります。変更プロジェクトの数が管理可能な範囲内に収まるように、CAB が承認した変更をターゲット リリース (メジャー リリースまたはマイナー リリース) に合わせてスケジューリングすることも望ましくなります。ただし、ある一定の点を超えると逆効果になります。リリースに含まれる変更が多くなりすぎると、リリースの管理が煩雑になり、問題の特定が困難になります。スケジューリングされているリリース プロファイルに適さない変更や、次期リリースより早期に実施する必要のある変更は、個別にスケジューリングする必要があります。

CAB は、事前に定義された保守時間枠内に変更実施をスケジューリングするように努めます。保守時間枠とは、装置またはシステムが保守のために稼動を停止する時間です。変更を保守時間枠内にスケジューリングすれば、ユーザーへの影響を軽減できます。影響を受けるシステムのユーザーおよびその他の関係者に対しては、保守時間枠に関する通知を行います。これらの時間枠のスケジュールは、ユーザーがシステムのダウンタイムに備えることができるように、早い時期から決定されているのが普通です。

各変更スケジュールには、変更のビルド、テスト、および実施のタイムラインとマイルストーンを含める必要があります。さらに、要員トレーニング、ドキュメント作成、およびサポート準備のタイムラインも含めます。このスケジュールは、すべての関係者が責任感を持って予定どおり変更を実施するための基盤になります。完成したスケジュールを適切な IT リーダーおよびユーザー コミュニティ リーダーに提出して、承認を受ける必要があります。スケジュールに変更を加えるには、IT またはユーザー管理責任者の承認が必須です。変更内容は、プロジェクトの全関係者に伝達します。

変更の通知とリリース
図 6 に示すように、変更の承認とスケジューリングは、変更マネージャまたは CAB が変更イニシエータ、変更オーナー、およびすべての関係者に対して通知する必要があります。影響を受けるすべての関係者に対して、実施が予定されている変更プロジェクトに関するフィードバックを提出するように奨励することも必要です。

図 6: 変更の通知とリリース活動

通知
変更管理では、実施が予定されている変更の初期通知を処理し、各関係者に対して高レベルの情報を提供します。プロジェクト全体を通じて、影響を受ける各関係者に対し、変更オーナーが詳細な情報を提供する必要があります。また、変更マネージャは、すべての関係者に対して事前に変更計画 (FSC) を提供する必要があります。影響を受ける各関係者は、このレポートに基づいて、変更に伴うシステムのダウンタイムに備えることができます。図 6 は、変更通知およびリリース活動を示しています。

変更イニシエータ
変更イニシエータに対しては、変更要求の承認または却下が通知されます。変更イニシエータには、実施予定日や変更準備に必要なその他の情報を知らせる必要があります。また、変更要求に対して計画された変更プロセスに関する質問や疑問点などに関するフィードバックを変更管理に返すことを変更イニシエータに奨励することも望ましくなります。

関係者
関係者とは、変更の影響を受ける人や実施が予定されている変更の通知を必要とする人を意味します。提供する情報は、対象者によって異なります。たとえば、変更が作業環境に及ぼす影響と変更の実施時期を知るだけで十分なユーザーもいます。これに対し、対象者が IT 管理者の場合は、変更の詳細、計画された変更プロセス、および取り消し手順を通知する必要があります。どのグループの関係者が影響を受けるかは、変更ごとに異なります。プロジェクト全体を通じて関係者に常に最新の情報を提供できるように、通知リストを作成する必要があります。

変更オーナー
変更オーナーに対しては、変更に関する詳細情報を知らせる必要があります。この情報には、変更の理由、変更スケジュール、影響分析およびリスク評価の結果、変更に伴うタスクなどを含めます。変更オーナーは、プロジェクト ステータスや発生した問題などを含め、プロジェクトと変更管理の歩調を合わせるように努力しなければなりません。

変更計画 (FSC : Forward Schedules of Change)
CAB ミーティングに引き続き、変更マネージャは、承認された変更、変更の割り当て先のリリース、およびその実施日を詳細に示す FSC を発行します。変更マネージャは、すべての関係者に必要な情報を提示し、変更プロセスへの意識を喚起することを目的として FSC を発行します。関係者が十分な時間をかけて、システムのダウンタイムや、その他、通常の運用に対する影響に備えることができるようにすることも、FSC の目的となります。組織内のすべてのグループに対し、FSC に無理がないかどうかなどを含めたフィードバックを返すように奨励する必要があります。

リリース
変更要求の承認およびスケジューリングが完了し、すべての関係者に対する変更通知が完了したら、組織内の適切なグループに作業指示が渡されます。すべての作業指示はそのステータスと共に変更管理ログに記録され追跡されます。変更オーナーには、実施計画立案プロセスの開始権限が与えられます。変更のオーナーシップは変更オーナーに渡されますが、IT 環境内でタイムリーかつ適切に変更を実施することについては変更管理が全面的な責任を負います。

変更の開発、テスト、および実施の監視
変更マネージャは、変更プロセスの進捗を監視し、CAB にフィードバックを返します。CAB と変更マネージャは、監視結果に基づいて、問題の調査と修正を行い、スケジュールを調整します。

開発、テスト、および実施
図 7 は、変更の開発、テスト、および実施に対する監視タスクを示しています。

図 7: 変更監視活動

前述したように、IT 環境内でタイムリーかつ適切に変更を実施することについては変更管理が全面的な責任を負います。変更を渡された変更オーナーは、変更プロセスの監視と実施を担当し、これと並行して、変更プロセスの取りまとめと変更の計画および実施の責任を果たします。

変更マネージャに対しては、プロセス全体を通じて、定期的なステータス レポート (毎週など) を提供し、進行中の各プロジェクトに関して発生した予想外の問題を通知する必要があります。変更マネージャは、返されたフィードバックに基づいて各プロジェクトを監視し、CAB の策定したマスタ スケジュールを各プロジェクトが満たしていることを確認します。変更プロセス中に必要リソースが利用できないことが判明した場合は、変更プロセスを中止するかどうかを変更マネージャが決定します。プロセスを中止した場合は、変更要求を CAB に差し戻し、スケジューリング変更を求めます。

変更要求を受け取った変更オーナーは、変更プロセスに関与しているすべてのグループの活動内容の監督と取りまとめにあたります。これには、変更計画の立案、変更コンポーネントの開発/調達、テスト、パイロット ステージング、および実施が含まれます。これらのプロセスの詳細については、リリース管理のドキュメントを参照してください。

変更プロセス中、変更オーナーは、定期的な更新を行うと共に、発生した問題を変更マネージャに通知します。変更マネージャ/CAB は、変更オーナーが問題を修正したり、問題解決を円滑に進めるために必要なリソースを取得したりする際の手助けをします。

変更マネージャおよび構成マネージャは、互いに協力して CMDB を更新しなければなりません。また、変更ログを更新して、変更のステータスを反映させると共に、発生した問題に関する情報を付記します。

実施後の作業
変更実施後は、変更マネージャと変更イニシエータが 1 ～ 2 週間にわたって IT 環境を監視し、変更の運用機能を評価し、ユーザーのフィードバックを求めます。また、多くの場合は、IT 組織のスタッフからも情報を収集し、新しいシステムが効果的に動作しており、信頼性の点でも申し分ないかどうかを評価します。この情報は、設計/ビルド プロセスで設定し、ユーザー満足度テストで確認したシステム パフォーマンスや可用性基準などのパフォーマンス メトリックと比較されます。

変更の評価後、変更マネージャと変更イニシエータが結果に満足できない場合は、変更を取り消しまたは手直しすることができます。変更マネージャまたは変更オーナーと変更イニシエータが必要な取り消しの種類を決定し、プロセスを開始します。変更マネージャは、変更の取り消しと IT 環境の復元を実施したことを変更ログに付記します。また、変更マネージャは、取り消しの理由をログに記入します。

取り消しを実行する場合、変更マネージャ、変更オーナー、および変更イニシエータは、どのような方針をとるかを決定しなければなりません。問題を簡単に修正できるのであれば、修正をその場で実施し、再テストと実施に進みます。CAB メンバに通知を行うと共に、新しい実施を反映するように変更スケジュールを調整する必要があります。問題を簡単に修正できない場合は、変更要求を CAB に差し戻して、分析し直す必要があります。この場合、オリジナルの変更要求は終結させる必要があります。

変更をまだ実施する必要があると判断された場合は、変更プロセスをもう一度開始することになります。レポートおよび分析用に新しい変更要求番号を割り当てる必要があります。

問題の根が深い場合は、変更マネージャと変更イニシエータが代替策 (一時または恒久) を検討しなければならなくなることもあります。代替策としては、新しい変更コンポーネントを入手したり、変更に盛り込む必要がある機能をアウトソーシングしたりすることなどが考えられます。変更を実施しなければ組織の業務要件に対してどのような影響と反動が生じるかについては、変更イニシエータが最もよく理解しているはずなので、変更イニシエータの意見を反映する必要があります。変更マネージャと変更イニシエータは、実施を変更しないことで生じる影響が重大で、緊急の措置が必要であると判断した場合には、緊急の変更を宣言することができます。

変更結果の通知
図 8 は、結果の通知プロセスを図示しています。

図 8: 変更結果の通知

変更プロセスの完了時には、CAB と変更マネージャがすべての関係者に対して結果の通知を行います。この通知は、実施が成功しなかった場合にも行う必要があります。変更実施プロセス終了後、できるだけ迅速に通知を行います。1 ～ 2 週間にわたって行う評価フェーズ (IT 環境内における変更の監視) 中には、評価のステータスと検出された問題に関する最新情報を各関係者に通知します。

変更マネージャが変更プロセスを評価するために行う変更レビュー プロセスの影響を受けない関係者に対しても、通知が必要です。

実施に失敗した場合は、失敗の理由、今後の方針、および関係者に対する影響を詳細に述べる適切な通知を提供します。

変更の実施を取りやめ、代替策を評価するか、または変更を全面的に取り消すことを決定した場合は、その旨を関係者に通知しなければなりません。

変更の実施に成功した場合も、すべての関係者に通知を伝達します。フォローアップ活動を開始する場合は、その旨を関係者に知らせます。

実施後の評価
実施後の評価は、変更管理プロセスの最終フェーズとなります。この活動では、個人面談やドキュメントのレビューを通じて、変更要求の受付から実施に至るまでの変更管理プロセス全体を評価します。この活動では、変更プロセスの有効性を評価することに主眼を置きます。実施に失敗した変更についても、さらなる変更を開始する前に問題を特定および修正できるように十分な評価を行います。

図 9: 実施後の評価活動

リリース評価
実施後の評価に関しては、変更マネージャが責任を負います。変更マネージャは、個人面談やリリース ドキュメントのレビューを通じて収集した情報に基づいて、評価レポートを作成します。変更マネージャが実施後の評価を指揮するにあたっては、CAB メンバやその他の人員の助けを借りることがよくあります。

変更の実施が完了した後、変更マネージャは直ちに情報収集を開始します。正確さを確保するには、タイムラインが重要です。

この評価は、以下のようなさまざまな観点から行います。

• 変更要求レビュー プロセスと承認プロセスのタイムライン

• CAB ミーティング

• 変更ログに記録された変更プロセスの情報

• CMDB に記録された CI の情報

• CAB が定義したプロジェクト スケジュールが守られているかどうか

• プロジェクト チーム メンバの結集

• 伝達プロセスの有効性

• プロジェクトのエラーと問題の処理

• 変更プロセス進行中における IT 環境の可用性と信頼性

• ユーザーに対するサポートの可用性と質

• ユーザーおよびサポートのトレーニングの有効性

• パイロットおよびフル リリースの実施プロセスの有効性

• 変更が目標を満たしているかどうか

プロジェクトの各フェーズに関する評価が必要です。たとえば、プロジェクト進行中にユーザーに提供したトレーニングの有効性に関して、ユーザーの意見や感想を求めます。実行チームに対しては、パイロットおよびフル リリースの実施手順を改善するには、どうすればよいかを質問します。プロセス全体を評価して、合理化と改善の方法を決定します。

実行計画と取り消し計画を含む変更計画を評価し、実際のプロセスが計画と食い違っていなかったかどうかを調べます。食い違いがあった場合は、その理由を調査し、プロセスを改善するための調整方法をドキュメント化します。変更オーナーおよびその他の重要なプロジェクト関係者から、今後の変更プロジェクト メンバにとって参考になる教訓的な情報を収集します。

プロジェクトの成果についても評価が必要です。失敗した変更を調査し、失敗の原因を特定すると共に、今後の変更プロジェクトで同じ問題の再発を防止する方法を検討します。失敗の評価に際しては、変更オーナーの協力も求めて、問題の具体的な原因を調査します。こうして得られた情報は、すべて完全に変更ログ/CMDB に記録します。変更マネージャは、教訓レポートを作成して、関係者に配布します。さらに、変更マネージャは、完全な評価レポートを作成して、適切な担当者に配布します。

変更要求の終結
変更マネージャは、実施後のレビューで得られた調査結果を CAB メンバに提出し、CMDB 内の変更要求を終結させるかどうかの判断を仰ぎます。CAB メンバが変更要求を終結させることに合意したら、変更マネージャはその旨を変更ログに付記します。

変更要求は、以下の条件が成立した後でのみ終結します。

• IT とユーザー コミュニティのリーダーが終了の署名を行っていること

• IT 環境に関して予想外の副作用のないことが既に確認されていること

• CMDB を含むすべてのドキュメントが既に更新されており、変更が反映されていること

緊急変更プロセス
次の図は、緊急変更プロセスを示しています。

図 10: 緊急変更プロセス

変更マネージャが変更要求を緊急の変更として分類することがあります。緊急の変更とは、ユーザーのダウンタイムやサービスの悪化が業務プロセスに悪影響を及ぼすのを防止する目的で、できるだけ早期に実施する必要のある変更を意味します。基幹的な業務アプリケーションを復元するために必要な変更や、大きな影響を生じるユーザー ダウンタイムを防止するために必要な変更などが、緊急の変更の代表例です。

緊急変更プロセスは、組織がシステムをできるだけ早く通常の動作状態に戻せるようにすることを目的とします。基本的には通常の変更プロセスと同じですが、時間的制約が許す限り、短時間でプロセスを進める点が異なります。緊急の変更ではテストに時間をかけることができないので、緊急の変更が多ければ、その分 IT 環境に対するリスクが高くなります。したがって、緊急の変更の数は、最小限にとどめる必要があります。

変更イニシエータが変更管理から事前の承認を受けることなく、上記の緊急基準に一致する変更を実施する場合もあります。どちらの経緯をたどった場合でも、変更ログと CMDB を更新すると共に、影響を受ける関係者に対して変更の実施を伝達しなければなりません。

ほとんどの場合は、実施プロセスの進行中や実施完了直後に、通知を行うことになります。時間的制約があるので、事前の通知を行わないのが普通です。変更の内容、ユーザー機能と業務プロセスが受ける影響、フォローアップ処置の有無と内容をユーザーおよびその他すべての関係者に通知しなければなりません。変更マネージャと変更イニシエータは、実施プロセスの開始前、進行中、または完了後に変更通知をできるだけ早く提供するように努力します。

緊急の変更の実施が反映されるように変更ログと CMDB を更新することは、きわめて重要です。変更ログを適切に更新しておけば、変更マネージャと変更イニシエータが時間的制約のためにステータスと問題に関する情報を提供できなかった場合でも、CAB および影響を受ける関係者が情報を収集できるようになります。ログと CMDB は、変更プロセス全体を通じて更新するのが理想的ですが、時間的制約のためにプロセス中の更新が不可能であれば、変更実施プロセスの直後に更新します。

変更マネージャが緊急の優先度を割り当てた変更要求は、変更コンポーネントを必要に応じて開発または調達できるように、組織内の適切なグループに直ちに渡されます。時間的に余裕があれば、テスト コーディネータにも変更が渡されます。変更マネージャが現在の情報だけで変更を承認してよいかどうか判断できない場合は、CAB/IT 実行委員会でミーティングを持ちます。変更マネージャがこのアプローチをとるのは、変更の緊急度が不確かな場合や、実施に際してのリソース要件が特に高い場合です。IT 実行委員会は CAB と同じ機能 (変更の評価と承認) を担いますが、時間枠は CAB の場合より短くなります。変更の実施に失敗した場合は、変更マネージャおよび CAB が変更を再評価し、問題を修正して、変更を適切に実施するための迅速な対策を講じます。

変更管理の承認を得ずに特定の変更を実施する権限を組織内のグループ (サービス デスクなど) に付与する必要があります。

メモ この方法での実施が許容されるのは、変更イニシエータが影響の大きいユーザー ダウンタイムを防止するために必要と判断した場合だけです。

このパスをたどってもよいのは、迅速な対処が必要になった場合だけです。この場合の変更イニシエータは、変更オーナーを兼ねることになり、実行計画、そしてさらに重要な取り消し計画を作成する責任を負います。この変更イニシエータは、影響を受けるすべての関係者に対して、できるだけ早く通知を行わなければなりません。変更プロセスをバイパスする場合は、CMDB を更新して変更を反映できるように、変更イニシエータから変更管理に対して通知を行うことがきわめて重要です。変更が既に実施された場合でも、適切な関係者が変更を認知できるように変更要求を提出する必要があります。適切に実施されなかった場合や、問題が発生した場合は、変更を取り消しし、変更マネージャと CAB に提出してレビューを受けます。変更マネージャは、変更イニシエータが問題を修正して変更を実施できるように、必要なリソースを提供します。

緊急の変更の実施に成功したら、変更マネージャ、変更イニシエータ、および変更オーナー (多くの場合、最後の 2 つの役割は同一人物が兼ねることになります) は、影響を受けるすべての関係者に対して変更に関する適切な情報を伝達します。変更マネージャおよび変更イニシエータは、さらに、実施後の評価プロセスを開始し、その後、IT とユーザー コミュニティのリーダーが変更の終了に署名したら、変更要求を終結させます。変更の終了に対する署名が得られない場合は、変更を取り消しして、CAB に提出しレビューを受けます。

 ページのトップへ

このガイドで説明したタスクを実行するために最低限必要な予備知識については、以下に示す Windows 2000 用トレーニング リソースを参照してください。これらのコースの詳細情報は、https://www.microsoft.com/learning/default.mspx (英語) および https://www.microsoft.com/japan/learning/training/default.mspx に記載されています。

コース名
1267 : Planning and Implementing Active Directory (英語コース)

1556 : Administering Microsoft Windows 2000 (英語コース)

1557 : Installing and Configuring Microsoft Windows 2000 (英語コース)

1558 : Advanced Administration for Microsoft Windows 2000 (英語コース)

1561 : Microsoft Windows 2000 ディレクトリ サービス

2151 : Windows 2000 ネットワーク エッセンシャル

2152 : Microsoft Windows 2000 インプリメンテーション

2153 : Microsoft Windows2000ネットワークインプリメンテーション

2154 : Microsoft Windows 2000 ディレクトリーサービスインプレメンテーション

この文書の著者は、Accenture 社の Curt Humes です。

このドキュメントに記載されている実地情報の多くは、Accenture、Avanade、Microsoft Consulting Services、Hewlett-Packard Company、Lucent Technologies/NetworkCare Professional Services、および Compaq Global Services の IT 分野におけるさまざまな実装の経験に基づいています。

この文書に資料を提供していただいた各団体の寛大な支援に対し、心から感謝いたします。

© 2001 Microsoft Corporation.All rights reserved.

この文書で例として挙げられている企業、その他の組織、製品、職業、イベントは、仮想のものです。それらが、いずれかの実際の企業、組織、製品、人物、またはイベントを指していることはなく、そのように解釈されるべきではありません。

この文書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

この文書は、情報の提供のみを目的としています。Microsoft はこの文書に記載されている情報について明示的にも暗黙的にも一切の保証をいたしません。

Microsoft および Windows は、米国およびその他の国における米国 Microsoft Corporation の登録商標または商標です。

 ページのトップへ