IT、ITIL、ITSMにおける変更管理

IT変更管理とは、「標準化された方法と手順を駆使して、あらゆる変更を効率的かつ迅速に処理し、変更に起因するインシデントがサービス品質に与える影響を最小限に抑えることで、組織の日常業務を改善する」ためのプロセスです。この定義は、1989年にIT変更管理プロセスを初めて体系化したITIL (旧称：Information Technology Infrastructure Library)と呼ばれる組織によって定められました。

ITで唯一変わらないことは「常に変化する」ということです。それは大半のテクノロジー分野と同様です。ITILの取り組みにより、プロセスを標準化し、ビジネス全体のニーズを考慮して変更が行われるようにすることを目的としてIT変更管理のフレームワークが構築されました。その後、企業ではCOBIT、Six Sigma、TOGAFなど、他のフレームワークの採用が進んでいますが、ITILのフレームワークは今でも変更管理のデファクトスタンダードとして健在です。

IT変更管理(組織変更管理)は、ITサービス管理(ITSM)と密接に関連しており、通常はITSMの要素の1つと見なされることにご注意ください。どちらの分野も、ITインフラストラクチャに対する変更を組織が再現可能な形で効果的かつ効率的に実施し、文書化や測定を可能にすることを目指しています。さらにITSMでは、顧客が受けるサービスの品質という観点から、変更の結果として生じる顧客エクスペリエンスにも重点が置かれています。

以降のセクションでは、IT変更管理に関する知識を深め、変更の種類を明確に区別する方法について解説します。また、変更管理をまだ導入していない組織がこのプロセスを導入する方法についても解説し、すでに導入済みの組織に対しては、導入済みのプロセスを評価し、そのプロセスが可能な限り効果的に機能していることを確認するためのガイダンスを提供します。

IT変更管理の重要性

ITは現代の組織のあらゆる側面に浸透しており、ほぼすべての従業員、部門、組織、企業が確実に成果を上げるために欠かせないものです。IT変更管理を重要な分野として組織に取り入れなければ、新しいソフトウェア、ハードウェア、サービスを追加することも、既存のソフトウェアやシステムを更新、アップグレード、効率化することも不可能になるでしょう。また、ITインフラストラクチャを維持したり、他の組織や部署と協力したりすることもできなくなります。IT変更管理は新しいテクノロジーではありませんが、ある程度の従業員を抱えるすべての組織にとって不可欠なプロセスです。新しい組織の場合は、変更管理をできるだけ早く導入し、成長のためのフレームワークを最初から整えておく必要があります。

変更管理の種類

文書化した正式な変更管理プロセスにより、すべてのサービス提供者と関係者を変更戦略で連携させることができます。また、変更が適切に実装されなかった場合は、その変更をロールバックできます。

ITILフレームワークの現バージョンであるITIL4では、次の3種類の変更が定義されています。

強力な変更管理プロセスはすべての関係者を連携させることができ、標準変更、通常変更、緊急変更の3種類で構成されています。

標準変更：リスクの低い、事前に承認された変更。サービス要求として開始されることが多く、業務の変更である場合もあります。標準変更の手順を作成または変更した後は、完全なリスク評価と承認が必要です。

通常変更：所定のプロセスに沿ってスケジュールを設定し、評価し、承認することを必要とする変更戦略です。リスクの低い通常変更はローカルの組織や管理者が承認できますが、重大な通常変更には経営層の承認が必要になることもあります。

緊急変更：可能な限り速やかに実装する必要のある変更であり、通常は変更管理計画に組み込みません。迅速に実装できるよう、多くの場合は評価と承認のプロセスを速めます。テスト、評価、承認は可能な限り通常変更と同様に行うべきですが、スケジュール設定と文書化の優先度は下がります。

基本的な変更管理プロセス

IT変更管理は、ITハードウェア、システムソフトウェア、アプリケーションソフトウェア、および手順に関する変更を提案、評価、承認、拒否するプロセスです。ITILの変更管理プロセスでは、「提案された変更の影響、コスト、メリット、リスク、ビジネスにおける正当性の確立と承認の獲得、変更の実装の管理と調整、実装の監視と報告、変更要求のレビューとクローズ」について評価します。

これらの変更を管理するために、明確に定義された一連の変更実装手順を遵守します。この手順は、ワークフローを中断せず、ユーザーと管理者が困惑することなく変更を実装できるように定義されています。ITILのガイドラインでは、変更管理は通常、ユーザーが生成する変更要求(RFC)によって開始されます。次に、ITチームが変更の提案を評価して、変更の種類や緊急度を判断し、計画されている他の変更を考慮してスケジュールを検討します。

そして、適切な意思決定者に変更の許可を申請します。多くの場合はここで、変更諮問委員会(CAB)による変更の評価、優先順位付け、承認も行われます。

承認されなかった変更は、後で更新して、承認を再申請できます。必要な承認をすべて得た変更は、リリース管理チームがテスト、統合、導入を行います。実装後は変更管理チームがフォローアップし、変更が期待された成果を上げているか確認します。

変更諮問委員会(CAB)とは？

変更諮問委員会(CAB)とは、変更要求を承認または却下するグループのことです。CABは多くの場合、組織の中心的なIT担当者で構成されており、変更要求を効率的に処理するために、社内外の他の人々の知識や専門性を活用することもあります。

CABは、変更管理の基本原則が遵守され、変更による潜在的な影響がすべて考慮され、あらゆる変更が文書化されるようにする役割を担いますが、変更管理プロセスのボトルネックとなる可能性も少なくありません。特に大規模な組織では、CABやCABの定めた要件と手順が肥大化し、遅れが生じたり機能不全に陥ったりすることがあります。そして、変更の提案に「ノー」を突きつけることが、CABにとって最も無難な対応になるという状況が起こりがちです。

その結果、多くの組織でCABの概念や構成に変化が起きています。具体的には、CABの管轄範囲が最も潜在的リスクの高い変更要求に限定される一方、IT部門が自らの裁量で必要と思われる変更を実装できる範囲が拡大しています。CABは多くの場合、ITの変更要求や実施中の変更を組織全体で理解できるようにしたり、規制の立場ではなくアドバイスの立場で機能したりすることで、より効果的に機能します。組織にとっては、効果的なコミュニケーション計画を立てることが、最も重要な変更要求とその変更の影響をCABに伝え、全員が同じ認識を持てるようにするうえで大いに役立ちます。

IT変更管理のメリット

ITILによれば、IT変更管理には次のようなメリットがあります。

• 標準化したサービス提供で、全体的な効率を高める。
• 規制コンプライアンス要件の遵守方法を改善する。
• 反復的な手動作業を排除し、より革新的で付加価値を生むサービスを提供することへの注力を可能にする。
• エンドユーザーのみでなく、サービスの関係者全員を考慮できる。
• 価値を実現するための反復的アプローチで、サービスを継続的に改善する。

IT変更管理プロセスのデメリット

他のプロセスと同じように、どれほど適切に設計されたIT変更管理プロセスでも、人的な要素が障害となることがあります。官僚的なレビュープロセスに従うという考え方は、成長を望んでいる組織のあらゆるプロセス、サービス、経営者にとって、進歩を阻む大きな要因となる可能性があります。とはいえ、機会を捉えるためにすばやく変更を実装しようとすれば、リスクとリターンのトレードオフが間違いなく発生します。変更管理プロセスの効果を高めるには、進歩を遂げるための迅速な行動とリスクを避けるための慎重な行動とのバランスを考慮する必要があります。実際、多くの組織がこの2つの相反する目標に適切に対処するために、変更管理プロセスを分散化しています。

ITサービス管理(ITSM)の一部としてのIT変更管理

ITサービス管理(ITSM)は、組織とその従業員、顧客、ビジネスパートナーへITサービスおよびサポートを提供するための戦略です。その主眼は、エンドユーザーが何を期待しているかを理解し、ITサービスとその提供方法の両方を改善していくことにあります。

ITサービス管理はIT変更管理と同じではありませんが、この2つは密接に関連しています。実際、IT変更管理は、包括的なITSM戦略の構成要素の1つと見なされています。

ITSMフレームワークには次のようなものがあります。

• 要求実現：ユーザーからのあらゆるサービス要求のライフサイクルを管理します。
• インシデント管理：ヘルプ要求への対応や問題の修復を行い、サービスを通常状態に復帰させて、ビジネスへの影響を最小限に抑えます。
• 変更管理：ITサービスにおいて実施されるあらゆる変更の管理手順を標準化します。
• ナレッジ管理：IT製品およびサービスの情報を整理し、ユーザーが利用できるようにする方法がまとめられています。
• 可用性管理：サービスの中断を最小限に抑えるために、ITインフラのサービス、性能、サポートを最適化する方法が定義されています。
• サービスレベル管理：顧客に提供するサービスレベルを改善および管理し、サービスレベル契約(SLA)を遵守する方法がまとめられています。

DevOps環境における変更管理

IT変更管理の原則は、共通のビジョンに向かってコラボレーション、実験、学習を行うというDevOpsの文化を強化するものです。

IT変更管理は、包括的なITSM戦略の要素の1つです。ITSMは、反復可能なフレームワークと明確に定義された役割および責任を用いて、IT変更管理を含むサービス提供ライフサイクルに標準化とガバナンスをもたらします。一方でDevOpsは、ソフトウェア提供における速度、俊敏性、サイロ解消に重点があります。DevOpsはコラボレーション、透明性、オープンなコミュニケーションといったコアバリューを重視しますが、その手引きとなるベストプラクティスの正式な手法や文書はありません。

• IT変更管理とDevOpsは相互に補完しますが、一部の組織は、ITSMとDevOpsが相いれない手法であるとか、ITSMとDevOpsの世界は無関係であるといった誤解を抱いています。実際、IT変更管理の効果的なプロセスやベストプラクティスがDevOpsで扱われることはありません。その主な理由は、目標とアプリケーションを中心とした運用形態とエンドユーザーを中心とした運用形態が大きく異なるためです。また、ポリシーの影響もIT環境とDevOps環境では大きく異なります。
• IT変更管理は、共通の目標に向かってコラボレーション、実験、学習ができ、失敗を責めない文化を醸成するというDevOpsの基本原則を強化するものであり、こうした目標を達成するためのフレームワークを導入します。
• IT変更管理は、適切に実装されれば、チームの俊敏性を高めるのに役立つものであり、ITサービスにおいて実施されるあらゆる変更の管理手順を標準化します。
• IT変更管理とDevOpsの一方のみを選択する必要はありません。組織はIT変更管理、ITSM、およびDevOpsについて、ビジネス価値を等しく提供し、併用することで相乗効果をもたらす補完的な手法と捉える必要があります。
• 可用性管理では、サービスの中断を最小限に抑えるために、ITインフラのサービス、性能、サポートを最適化する方法が定義されています。

IT変更管理が機能していることを確認する方法

ほとんどのITツールが何十ものメトリクスを追跡しますが、データはITサービスの管理者がITサービスチームのパフォーマンスを把握するためのものです。その点で、次に挙げるメトリクスが、ITの変更とIT変更管理プロセス全体を評価する際に特に重要となります。(これらのメトリクスを使用して、組織の全体的なITSMプロセスの有効性を追跡することもできます。)

チケットあたりのコスト：ITサービスおよびサポートの効率を知るために役立つメトリクス。サービスデスクの月間合計運用費(給与、テクノロジーおよび設備費、オフィス用品など)を月間合計チケット数で割って算出します。

顧客満足度：組織のITサービスおよびサポートのパフォーマンスがどれほど優れているのかを知りたいとき、一般的に最も適した指標はユーザーの満足度です。

一次解決率：ユーザーとの初回コンタクトで解決したチケットの割合を測定したもの。一次解決率の高さと顧客満足度の高さには、強い相関があります。

技術者の稼働率：労働効率を測定したものであり、チケットあたりのコストと密接な関連があります。通常は、技術者の稼働率が高いとチケットあたりのコストが低く、技術者の稼働率が低いとチケットあたりのコストが高くなります。

一次レベル解決率：総所有コスト(TCO)にかかわる指標の1つであり、ITサポートの真の効率を見極めるために役立ちます。たとえば、ある一次レベルのサービスデスクのチケットあたりのコストが低い理由が、上位レベルのサポートへエスカレーションしているからだとします。その場合、効率的なサービスデスクという印象を与える一方で、TCOは増加します。

技術者の職務満足度：当然ながら、技術者の職務満足度が高ければ離職や常習的な欠勤は少なくなります。それだけでなく、一次解決率の高さと処理時間の短さとも相関します。結果として、チケットあたりのコストの低減と、顧客満足度の向上につながります。

平均解決時間(MTTR)：問題解決にかかる平均業務時間(チケットのオープンからクローズまで)を測定する、サービスレベルのメトリクス。

IT変更管理の導入方法

IT変更管理プロセスは、組織に導入される他の主要な戦略と同じように導入できます。新たにIT変更管理プロセスを導入する際のベストプラクティスを以下に示します。

1. プロセスを実装する意図をすべての関係者に伝えます。
2. 関係者と情報収集のための会議を開き、プロセスに対するニーズと要望、および発生する懸念事項について話し合います。
3. 議論の内容を文書にまとめ、調査結果をすべての関係者が確認できるようにします。
4. 変更管理戦略を策定し、伝達します。
5. このプロセスを主導するチームを指名します。
6. IT変更管理プロセスを導入するのに利用可能な手法を評価します。
7. その中から最善の手法を選択し、導入を開始します。

また、IT担当者は構成管理データベース(CMDB)など、さまざまな変更管理ツールも利用できます。CMDBは、IT資産やその他の構成アイテムに関する情報を保管する共通の場所を提供し、ユーザーが利用できるようにするものです。とりわけ、CMDBを使用することで、IT担当者はさまざまなアプリケーションを採用して別の部門にデプロイしたり、ハードウェア、ソフトウェア、ライセンスなどの資産が企業でどのようにデプロイされているかをライフサイクル全体で追跡したりできるようになります。

IT変更管理のベストプラクティス

IT変更管理プロセスは、その名が示すとおり、1つのプロセスです。管理システムとして、組織の短期的および長期的なニーズを満たす必要があるため、すべての関係者に役立つだけでなく、新たなボトルネックを生み出したり既存のボトルネックを悪化させたりすることなく、ITの変更を効果的に管理することが求められます。立ち上げたばかりの新しい会社や小規模なスタートアップ企業でない限り、企業はおそらくIT変更管理プロセスをすでに導入していることでしょう。そこで、自社のプロセスの構築や改善に役立つベストプラクティスをいくつかご紹介します。

関係者とコミュニケーションを取る：関係者は、現在のIT変更管理プロセスが機能していると感じているでしょうか。それとも、ボトルネックやその他の非効率性への対処を頻繁に行わざるを得ない状況でしょうか。

シンプルさを重視する：組織の変更管理プロセスがどのように機能しているのかを確認するのに数分以上かかる場合は、プロセスが複雑すぎる可能性があります。どこをシンプルにできるのか検討しましょう。

CABの戦略的な重点を決める：CABの概念は、かつてはIT変更管理の中核とされていましたが、成果を上げている組織の多くは、CABで変更要求の技術的な根拠とビジネス上の根拠の両方を検討するか、プロセスを完全に分散させています。

測定を可能にする：「測定できないものは管理できない」という古い格言は今でも有効です。

プロセスを自動化する：ITILのガイドラインは更新され続けていますが、20年以上前に策定されたものです。今では自動化されたITSMツールが利用可能です。自動化により、人間主導のプロセスでは不可能な方法で変更管理プロセスの規模を拡大できます。

DevOpsがIT変更管理に代わる存在ではないことを理解する：一部の組織は、ITSMとDevOpsは相いれない方法論であると誤解しています。実際には、サポート、ガバナンス、予算管理といったITSMの機能は現代のあらゆるビジネスにおいて不可欠ですが、DevOpsではこれらを取り扱いません。

結論：IT変更管理はあらゆるIT組織にとって不可欠なツール

多くのテクノロジー製品は、導入にあたって詳細な説明や説得力のある価値提案を必要としますが、効果的なIT変更管理プロセスは、ある程度以上の従業員を抱える組織にとって必要不可欠なものです。企業は、不十分な計画に基づいて実施したIT変更を大急ぎで元に戻したり、最初からやり直したりする作業に莫大な費用を費やしています。効果的なIT変更管理プロセスは、収益、従業員、顧客、評判への影響を最小限に抑えながら、テクノロジーインフラストラクチャを最新の状態に保つことができる、最もシンプルで費用対効果の高い手段です。

このブログはこちらの英語ブログの翻訳です。