IT 変更管理とは IT システムの優先付け、承認、スケジューリング、実行を適切に行うための実践方法のことです。
テクノロジーが進歩し、市場が変わり、ビジネスが成長するにつれて、企業の IT インフラストラクチャには新しいニーズに対応するために進化する能力が求められます。しかし、社内のシステムに変更要求を展開する作業は難しく、リスクが伴い、時間がかかるおそれがあります。
おそらくさらに重要なのは、IT システムの変更が、会社のテクノロジーに依存する従業員の生産性とエンゲージメントに直接影響を与える可能性があるということです。新しいオフィスプリンターを追加するだけの変更でも、全社的に新しいテクノロジーを導入するような変更でも、必要となる文書化、承認、導入の手法が成功の鍵を握ります。
IT 変更管理ではすべての変更が「標準」、「緊急」、「通常」のいずれかに分類され、可能な限り自動化が多用されます。こうして円滑な移行を図り、概念段階から導入完了までの変更をガイドするプロセスを標準化します。IT 変更管理とは異なる組織変更管理は一般的に、企業の従業員の役割やプロセスの変更管理のことを指します。
予定されたウイルス対策ソフトウェアの更新などの定期的な作業のように、定期的なメンテナンスタスクは通常はとても単純で比較的苦労なく行えます。しかし、セキュリティパッチが適用される間、内部や外部と接続されたシステムはダウンタイムやその他の問題が生じる可能性があります。このため、システムの更新中にいつも中断が発生する状態か、あるいはセキュリティツールを更新せずに大きな問題を引き起こすリスクを抱えるか、企業は困難な選択を迫られています。
企業が競争力を維持するために、IT チームには安定、確実、一貫したサービスの提供が求められます。同時に、変化するニーズに適応できるように、定期的なサービス更新により支援する必要もあります。残念ながら、多くの場合にこれらの 2 つは相反する命題となります。安定性と信頼性のために一貫性が求められる一方で、サービスの更新はそもそも「変化」を導入する性質を持つためです。
変更管理は「それぞれの長所」を活かしたアプローチをとることで、企業が重要な変更を導入する過程を定義すると同時に、そのためのサービスの中断を最小限に抑えます。そのために、変更管理では企業が次のことを行うのを支援します。
- 各変更に優先順位を付けてリソースを割り当てる。
- 関連情報を収集して分かりやすい文書に整理する。
- 提案された変更を確実にテストし調査する。
- 変更プロセスを管理する最終的なフレームワークを確立する。
- 必要なステークホルダー間のコミュニケーションチャネルを構築する。
- 効果的な承認プロセスを確立する。
- 変更プロセス全体を簡素化し、サービス中断の時間を大幅に短縮しつつ、エンドユーザーに迅速に価値を提供できるようにする。
IT 変更管理には、次をはじめとするいくつかの用途や頭字語が存在します。
ITIL は企業の IT サービスのライフサイクルを標準化するためのフレームワークで、IT サービスの選択、提供、管理、メンテナンスなどの効率と予測可能性を高めるために用いられます。
ITIL は IT サービス管理 (ITSM) の最も一般的なフレームワークで、ほぼすべての業界で使用されています。IT 変更管理に関して、ITIL では変更を 3 つのグループに分類しています。
- 標準的な変更
確立された手順がとられる低リスクの変更です。あらかじめ承認を受け、リスクは非常に低いのが普通です。所定の手順に従うため、自動化が容易です。例として、ソフトウェアのパッチ適用と更新、旧式ハードウェアの交換、新しい DNS エントリの作成などがあります。 - 緊急の変更
予期しない変更で、一般的に緊急事態の悪影響を緩和し最小に抑えるためにただちに実行する必要があります。大規模な DDoS 攻撃からのネットワークの分離や、ゼロデイ攻撃に対する緊急パッチの適用などの例があります。 - 通常の変更
標準的な変更や緊急の変更でない変更はすべてこれに該当します。関連するリスクに応じて、さらにマイナー、重要、メジャーの分類があります。事前の承認やスケジュールはありませんが、緊急時の変更ほどの緊急性はありません。
変更管理の詳細と ServiceNow がサポートする要求タイプ
RFC は変更を導入するための正式の要求で、変更の評価、承認、却下のために必要なすべての情報とともに、変更の規模や潜在的な影響とリスクに応じて詳細レベルを含める必要があります。
RFC は詳細な変更要求ではあるものの、変更そのものではありません。この要求は CAB に送られます。その際、変更について正確に評価するために必要な情報をすべて提供しなければなりません。
CAB は提案された IT 環境の変更を評価する役割を持つチームです。CAB の形式や複雑さは企業ごとに異なり、メールリストやフォーラムのようなシンプルなものから、専任の議長のもと正式な委員会が設けられるものまであります。いずれの場合も、CAB の構成メンバーは、変更を評価できる知識と経験を有する IT 関連の意思決定者と技術エキスパートでなければなりません。
変更が提案されると、CAB は関連する RFC を受け取り、その情報をもとに評価を行います。ただし、CAB は最終決定をする責任はなく、最終的な承認は「変更マネージャー」に委ねられます。
CAB ワークベンチは、次の形で CAB 会議の管理を支援します。
- CAB 会議のスケジュールの定義
- CAB 会議の出席者の定義
- CAB 会議のアジェンダの定義
- 変更カレンダーの表示
- 変更要求の承認あるいは却下
- 会議メモの表示と記録
IT 変更管理は、本質的に、企業のあらゆる部分に影響を与えるため、変更管理に関連した役割と責務を明に定義するのは困難な場合があります。また、ビジネスが異なれば、役割もその役割に割り当てるタスクも異なるので、すべてに共通する標準的なリストを作ることは不可能です。とは言え、多くの企業は変更管理イニシアチブにおいて次のような (または次と似た) 役割を設けています。
変更管理プロセス全体を監督し、その責任を負います。
CAB の管理者としてチームやステークホルダーの調整にあたり、提案された変更の承認と却下の最終判断をして、変更の実行を指示します。
変更を提案し、関連情報の収集と整理をして、変更の実行プランを作成します。
提案された変更の分析と評価を行い、変更マネージャーが承認の際に参考にすることができる推薦事項を提供します。
「変更イニシエーター」の役割を担うことが多く、ほとんどの IT 変更と直接関わることから、他のほとんどの IT 変更管理の役割と合わせて検討するに値します。
IT 変更管理は IT 変更の要求、評価、承認、実行、およびレビューのプロセスと関連しますが、リリース管理は変更の計画と実施の詳細に関係しています。
リリース管理の主な目的は、関係者全員に使用可能なリソースとリソースの展開方法、変更を実行するチームや部署、タスクの実行手順を十分理解してもらうことにあります。
一部重複はしますが、リリース管理は変更管理とは異なるものの関連がある機能です。リリース管理では多くの場合、シームレスなレビュー、追跡、および監視を容易にする高度な自動化が取り入れられています。
IT 変更管理は企業の成長と適応の不可欠な側面であり、次の重要な目的を持っています。
適切なプロセスがないと、変更はすぐさま手に負えなくなります。IT 変更管理は企業が行う変更に対する管理を強化し、計画、リスク評価、追跡など、すべてのステップの効果的な管理を可能にします。これによりリスクを最小限に抑え、変更を迅速かつ正確に実施することができます。
IT 変更管理はすべての変更要求を追跡します。IT 変更に対してより組織的で管理可能なアプローチがとれるだけでなく、無許可の変更を排除するためにも役立ちます。統一されたプロセスを設け、明確な責務を確立することにより、業務全般における変更の導入を最適な形で行えます。
大規模で全面的な変更は大きなリスクを伴い、混乱に陥ることが多いものです。一方、小規模の変更を続けて IT インフラストラクチャの効率や機能を高める継続的な変更はずっと管理しやすくなります。適切な IT 変更管理によって企業は、継続的な改善を進め、日常の業務への大きな影響を避けながら業界トレンドに遅れることなく重要な変更を実施することができます。
IT 変更管理でおそらく最も重要なのが、ITSM、ITOM、DevOps の各チームの連携です。DevOps 関連のアプローチは変更の回数を増やすことが求められ、変更マネージャーに対する圧力が強まります。優れた変更管理ソリューションには、高度な自動化やガバナンス機能により変更を適時効果的に実行するだけでなく、各部署のコミュニケーションと連携の強化を促進する能力も求められます。
これらの主要な関係者を結集し、組織全体で一元化された信頼できる唯一の情報源となることで、ServiceNow の ServiceNow AI Platform は変更管理のための最適な連携を可能にします。
効果的な IT 変更管理には変更の依頼、評価、承認、および実施のための明確なプロセスが必要です。多くの企業は規定の手順に従って、これを行っています。
変更の必要性が明らかになると、まず、考えられるリスクや利益、影響を受ける可能性のあるシステムなどの基本的な変更情報を収集します。この情報をもとに RFC を作成します。
承認の前に RFC を検討して間違いのないことを確かめ、要求された変更が必要であり実現可能であることを確認します。
要求が確定したら、変更を十分計画する必要があります。計画ステージでは、変更に伴う影響、ロールアウトプラン、バックアウトプラン、変更の役割、関連するダウンタイムなどを考慮して詳細を文書化する必要があります。
RFC は CAB に提出されるだけでなく、変更に関わる他の権限所有者や内部グループにも送られます。CAB は入手した情報を検討し、十分な情報をもとにリスクと利益を評価し、最終承認にあたる変更マネージャーに提案します。これを受けて変更マネージャーは、変更を承認あるいは却下します。
承認がなされると、変更の導入を開始できます。これにはタスクのスケジュール設定、割り当てや委任が含まれます。また、IT プロジェクト管理を活用することで、大規模な変更をより効果的に管理することや、増えた人員やタスクに指示をしやすくすることも可能です。
変更が実施されたら、続いてレビューと評価を行い、変更の成否や計画からの許容できない逸脱がなかったかどうかを判断します。問題が見つかった場合は、変更を終結する前に解決しなければなりません。
最終ステップとして、実施されレビューされた変更が成功、失敗、未完了のいずれであるかを記録します。終結状況を適切に記録することで、作業が重複するリスクを減らし、重要な変更の見落としを避けるのに役立ちます。
一連の明確なプロセスに従って IT 変更を計画、承認、および実施することで、変更管理には、いくつかの大きなメリットがあります。
- 同時に計画された変更が多すぎてリソースの競合や酷使が生じる状況を減らせます。
- 他の業務に悪影響を与えることなく変更を実施する能力が高まります。
- 詳細な文書と効果的なレビューおよび評価プロセスにより、変更の失敗を減らせます。
- 変更の分類精度を高めることができます。
- 変更プロセスを全社的に統合できます。
- 変更の自動化を改善し、プロセスを簡素化して、他の重要タスクに人員を充てられます。
- ビジネス成果を ITIL 4 に適合させ、CI/CD、フェイルセーフテスト、フィードバックループの短縮など、主要な DevOps のコンセプトを変更作業に融合できます。
- 計画された変更に関連する透明性が向上します。
- コミュニケーションの向上によりダウンタイムが短縮します。
- 無許可の変更や計画の不十分な変更による業務中断が少なくなります。
IT 変更管理のメリットは広く認識されていますが、効果的な導入の妨げとなりやすい課題もいくつか存在します。
提案された変更の範囲によっては、IT 変更管理プロセスにコストがかかり過ぎて導入が難しくなることがあります。
時として、詳細で段階的な変更プロセスによりデリバリ全体が長期化することがあります。IT 変更管理プロセスに含めなくても処理できる標準的な変更の場合には特にそうです。
変更の失敗が多い場合、それは変更管理プロセスが不適切である兆候かもしれず、価値ある成果が得られないままリソースや時間を浪費している可能性があります。
未承認の変更が行われるのは、IT 変更管理の導入が普及しておらず、承認メカニズムが効果的でないか整備されていない、あるいは適切なステークホルダーが承認プロセスに含まれていない場合です。未承認の変更が実行されると、支出が適切に記録されず、追跡が困難になります。確立された手順に従えば避けられる予期しない問題が生じることにもなります。
コミュニケーションが不十分で効果的な計画が立てられないと、同時に複数の変更が計画されることがあり、変更そのものが中断する原因となり、IT インフラストラクチャのさらなる複雑さを招くことになります。
緊急の変更はできるだけ速やかに対処する必要があるため、IT 変更管理プロセスの一部の過程が省略されがちになります。あまりに多くの変更を緊急時のものとして分類すると、遅れや混乱が生じやすく、実際の緊急事態に本来の対処ができなくなる可能性があります。
最良の結果を得るために、企業の変更管理アプローチには次のベストプラクティスが推奨されます。
変更の種類により異なるプロセスが求められることがあります。固有のカテゴリを設けて変更を提案し、優先度やその他の要件に応じて最も効果的な変更のプロセスを確立することにより、できる限り効率的な変更アプローチを取れます。
組織ごとに固有のリスク許容度や規制制約があります。これらの考慮すべき事項を理解し、計画や評価段階に組み入れることで、提案された変更によって無用の問題が生じることを避けられます。
可能で適切であれば、変更マネージャーやその他の変更責任者は他の信頼できる人物に積極的に責務を任せるべきです。これにより日常のタスクに忙殺されることなく、全体を見通すことに集中できるようになります。
変更の文書化は変更要求のステップから始める必要があります。提案された変更を一元的にデジタル管理することで、より効果的に変更を優先付けて、余裕ができたときに優先度の低い変更に手を回すことができます。
提案された変更はすべて何らかのリスクとリソース要件を伴います。それぞれの変更についてリスクおよびインパクト分析を行うことにより、意思決定者は最終承認に必要な明確なインサイトが得られます。
多くの場合、変更管理プロセスには、さまざまなロールが参加する数多くのステップが含まれており、承認やその他の情報待ちで前に進まなくなることがよくあります。効果的な自動化はプロセス全体を簡素化するのに役立ち、変更をスケジュールどおりに進めるためにぜひ導入したいものです。
変更プロセステンプレートは基本的に、個々の組織のニーズに応じてカスタマイズできる形式になっています。これらのテンプレートを作成して利用することで、変更要求を標準化して関連タスクを割り当てることができます。
IT 変更管理は手続きの変更と同じく文化の変更が求められる側面があります。このため組織は継続的な変更を新しい標準と位置づけ、すべての関連部署やステークホルダーに導入を徹底するよう努める必要があります。
効果的な変更管理のためにさまざまなフレームワークが存在します。それぞれについて時間をかけてメリットを十分検討し、ニーズに最適なフレームワークを選ぶようにしてください。
ステークホルダーが計画された変更スケジュールを知らされないとインシデントや混乱のもととなり、他のサービスに悪影響が出ることもあります。スケジュール設定にステークホルダーを含めることで問題の可能性を排除し、管理職からの継続的なサポートを促すことにもつながります。
変更プロセスの効果を判断するために、まずは関連する測定基準と KPI を確認する必要があります。変更管理の成功を定量化して評価することにより、プロセスの継続的改善に役立つ具体的なデータが得られます。
変更が必ずしも望ましい成果を生むとは限りません。変更が失敗したときに切り戻し計画があると損失をカットでき、既存の IT インフラストラクチャへの損害を食い止める唯一の手段となり得ます。
ServiceNow Change Management は、複雑な IT 変更プロセスを簡素化および迅速化するためのツールとサポートを提供します。定評ある ServiceNow AI Platform をベースに高度な自動化と AI 機能を搭載し、より簡単、効果的に変更管理ソリューションを活用できます。
ServiceNow Change Management は、あらゆる組織での変更の最適化、監視、および簡素化に必要なツールとリソースを提供します。ServiceNow Change Management には次の機能が含まれています。
- マルチモーダルの変更
変更作業やワークフローを特定ケースに合わせてカスタマイズ。 - 成功スコアの自動化
数値による変更の成功スコアを割り当て、低リスクの変更の自動承認による成功の可能性を評価。 - ダイナミックな承認ポリシー
承認定義を使用してビジネス要件に応じて承認を実行。 - ビルトインのリスク評価
すぐに利用可能な機械学習機能を適用してリスク評価の有効性を向上。 - 競合検出
構成アイテムや計画された変更の開始/終了日をもとに、スケジュールの競合を発見して解決。 - 同時変更管理
インタラクティブなカレンダーを使用して、計画された変更、ブラックアウト、およびメンテナンスのスケジュールを確認。 - ガイド付きセットアップ
ガイド付き手順、ビジュアルなステータス確認、その他の埋め込みヘルプオプションを参照して、変更を迅速に実行。 - CAB ワークベンチ
効果的な CAB 会議を設定して実施し、ハイレベルなストラテジストを結集してガイダンス、評価、および変更失敗の可能性の検討を実施。 - 単一統合プラットフォーム
ITSM、ITOM、DevOps、変更管理などを単一プラットフォームに集約。チーム間の最適なコラボレーションを促進し、単一の記録システムをもとに構成アイテムや接続サービスを検討するとともに、すべての変更とリリースプランの影響を詳細に把握できます。
ガイド、スケジュール設定、文書化、タイムライン、分析など、多くの機能を搭載した ServiceNow Change Management をご利用になれば、より多くの変更を、より効果的に、より頻繁に実施することができます。
ServiceNow の力を御社の IT 変更管理に活かし、成長に必要なリソースを手に入れてください。