IT サポート ワークフローを改善する方法
IT 変更管理の進化
変更管理 (変更の有効化とも呼ばれる) は、重要なシステムおよびサービスを変更しながら、IT サービスの中断を最小限に抑えるように設計された IT プラクティスです。
変更とは、サービスに直接または間接に影響を与える可能性のあるものを追加、変更、削除することです。
変更管理プラクティスは、インシデントを減らして規制基準を満たすように設計されています。このプラクティスにより、IT インフラストラクチャおよびコードの変更を効率的かつ迅速に処理できるようになります。新しいサービスのロール アウト、既存のサービスの管理、コードの問題の解決など、最新の変更管理アプローチは、サイロ化の解消、コンテキストと透明性の提供、ボトルネックの回避、リスクの最小化を実現します。
リスク管理は、関連する ITIL 4 プラクティスです。「組織がリスクを理解して、効果的に処理することを確認するために」このプラクティスに従います。変更管理とリスク管理の両方では、監査可能な記録を提供するために、変更の追跡とリンクが必要です。以前の変更とその成功率に関するデータを利用できるため、組織はリスクとスピードのバランスをスマートにとる方法でプラクティスを適応させられます。
データに基づいた適応性のあるプラクティスは、従来の変更管理とは対照的に、効率性を追求しています。これは、多くの場合、不必要に遅くてプロセスが重く、過負荷になる可能性があります。変更管理は、リスクとコンプライアンス、監査能力、チーム間の調整に関する課題に対処するため、複雑かつ官僚的で、苦痛になることがよくあります。
しかし、このようにする必要はありません。変更管理は、ITSM の「野菜を食べる」と考えてください。常に食欲をそそるわけではありませんが、非常に重要です。適切なプラクティスと文化があれば、変更管理により、インシデントが減り、チームへのストレスが軽減され、顧客への価値の提供に費やす時間が増えます。
変更管理の定義
一部の人が変更管理について考える際、私たちの定義には、テクノロジー、人、プロセスから顧客やシステムへの影響まで、変更のあらゆる側面が含まれています。ITSM のコンテキスト内で明確にするために、ITIL 4 は IT 変更管理プラクティスと組織変更管理プラクティスを区別しています。
- 組織変更管理は、「組織内の変更がスムーズかつ正常に実装され、変更の人的側面を管理することによってその永続的なメリットが達成されていることを確認するプラクティス」です。
その後、ITIL 4 は、従来の変更管理プロセスを「変更コントロール」プラクティスとして再定義しました。
- 変更コントロール プラクティスは、「サービスおよび製品の成功する変更の数を最大化するために、リスクが適切に評価されて変更の続行を承認し、変更スケジュールを管理すること」を保証します。
この新しい名前の選択は論争を引き起こし、多くの IT チームが「コントロール」との関連を拒否しています。一部の人にとってこれは、作成において従来の変更管理の評判が悪くなった官僚主義、ボトルネック、不要な手順を想起させる有毒な言葉です。
AXELOS はフィードバックを確認して、回答しました。「ITIL 4 ファンデーションのリリース後、世界中の大勢の人々から、『このプラクティスが【変更のスピードを制御する】のではなく、【変更を制御する】または【チームを制御する】ことに焦点を当てていると誤って解釈されたり、誤解されたりした』と聞いています」と述べました。
ITIL は最終的にこのプラクティスを、「変更の有効化」と呼ぶことに切り替えました。新しい名前は、チームを支援して、変更を前進させる能力と自由をチームに提供するプラクティスを意味しています。
結局のところ、使用する用語は特に重要ではないと思います (この記事と Atlassian では、それを変更管理と呼びます)。重要なのは、あなたのアプローチです。健全なチームと適切な文化から始めると、組織は効果的な変更管理プラクティスを作成するために正しい軌道に乗ります。
変更管理とリリース管理の関係
リリース管理は、変更管理の会話で重要なもう 1 つのプラクティスです。ITIL 4 によると、「リリース管理 ... の目的は、新しいサービスと変更されたサービスおよび機能を使用できるようにすることです」と説明されています。リリースには、ソフトウェア機能の変更からドキュメントおよびトレーニングの更新まで、すべてが含まれる場合があります。
これまで、リリース管理は、変更を 1 つにまとめて、パッケージとして顧客に提示していました。従来のリリース管理は、厳格なプロジェクト管理基準を維持しており、価値あるアップデートを顧客にリリースする際に摩擦が生じ、アジャイルの原則に従ったチーム間でフラストレーションが発生する可能性があります。
DevOps コンテキストのためのリリース管理を再構築できます。従来のプロジェクト管理機能から離れると、リリース管理は統合と自動化に関するものになるはずです。これは、可能な場合は自動レビューを組み込み、追跡と監視を提供する安全なシステムにコード パイプラインを統合することから始まります。これにより過去のサイロ化されたアプローチが解消されて、本番環境への摩擦のないパスが提供されます。リリース管理とは、これまで以上に簡単に価値を継続的に提供できるようにして「自社で構築して所有する」という原則を適用することです。
IT 変更管理はなぜ重要なのか?
最近の組織は、IT チームに対して競合する重要な期待がいくつかあります。まず、確実に組織が生産的であり、エンドユーザーの期待に応えられる安定した信頼性の高いサービスを期待しています。次に、IT チームは定期的なサービス更新を実装して、絶えず変化するセキュリティ、コスト、ビジネスの諸要件に対応できるようにする必要があります。
いずれかを怠ると、悲惨な結果につながる可能性があります。信頼性の高いサービスを維持できないと、生産性とコストに大きな損害を与える可能性があります。Gartner によると、多くの組織はダウンタイムのコストが 1 時間あたり 30 万ドルを超えると報告しています。一部の Web ベースのサービスでは、その数が大幅に多くなる可能性があります。
同時に、将来に適応していない組織は、ビジネスのスピードに追い付けなくなり、競合他社に遅れをとることになります。変更のデプロイが遅すぎると、ぎこちなくシステムが少ない場所で従業員が作業に失敗したり、顧客がより多くの価値を提供する他の組織にサポートと費用を送ったりする可能性があります。
それでは、これらの矛盾するニーズをどのように管理すべきですか? 変更管理プラクティスにより、組織は安定性を確保してリスクを軽減しながら、アップデートをリリースできます。変更管理は、次の方法で変更を達成するのに役立ちます。
- 変更プロセスを管理するフレームワークを確立する
- リソースを適切に割り当てるために、必要な変更に優先順位を付ける
- よりスマートな意思決定のために関連情報を取り込む
- 承認のために、開発および IT から必要な関係者を参加させる
- インシデントを回避するために変更のテストを組み込む
- 変更のフローを合理化および改善して、価値をより迅速に提供する
変更のタイプ
ITIL は 3 つのタイプの変更を定義しています。
標準変更
標準変更はリスクが低くてよく繰り返され、事前承認されます。また頻繁に実行されてドキュメント化され、承認されたプロセスに従います。
たとえば、メモリやストレージの追加は標準変更です。障害が発生したルーターを正常に機能する同一のルーターに交換することは、標準変更です。データベースの新しいインスタンスの作成は、標準変更です。
これらの変更はすべて共通であり、明確に定義されたプロセスに従います。このプロセスは、変更管理のリスク評価と承認プロセスをすでに一度完了していると推測されるため、ルーターの交換が必要になるたびにプロセスを再度実行する必要はありません。
多くの企業にとって、標準変更は自動化の絶好の機会です。一部の企業は、標準変更を 70% も自動化できると報告しています。これにより、チームは通常変更と緊急変更に集中できるようになります。
通常変更
通常変更は、定義および事前承認されたプロセスがない非緊急の変更です。
たとえば、新しいコンテンツ管理システムへのアップグレードは、通常変更です。新しいデータ センターへの移行は、通常変更です。パフォーマンスの向上は、通常変更です。これらは、標準でも繰り返し可能でもありません。これらには、リスクが伴います。ただし、緊急ではありません。つまりこれらは、リスク評価と承認のために通常の変更管理キューに入れます。
データ センターの切り替えなど、一部の通常変更はリスクが高く、変更諮問委員会 (CAB) によるリスク評価と承認が必要になる場合があります。ウェブサイトの変更など、その他の変更はリスクが低い場合があり、指定された変更権限者によって、または自動チェックとピア レビューを通じて迅速なタイムラインで承認できます。
緊急変更
これらの変更は、予期しないエラーまたは脅威から発生し、すぐに対応する必要があります。通常は、顧客や従業員向けのサービスを復元したり、脅威からシステムを保護したりします。
たとえば、セキュリティ パッチの実装は、緊急変更です。サーバー停止の対処は、緊急変更です。重大なインシデントの解決は、緊急変更です。
緊急変更の緊急性は、課題の迅速な解決に伴うリスクよりも時間のかかるレビュー プロセスのリスクが高いため、より厳しいタイムラインで処理する必要があることを意味します。
変更を分類する方法は、組織、プロセス、リスク許容度などの要因によって異なります。当社では「すべてに適した」アプローチを廃止して、リスク評価に基づいて各変更を異なる方法で処理することを提唱しています。組織が以前のインシデント、特定のシステムについてさらに学び、その他の関連データを取り込むため、より高い割合の変更を標準として指定し、事前承認できます。最新の変更管理では、変更リクエストをできるだけ単純化して合理化する必要があります。
変更諮問委員会 (CAB) とは
従来のほとんどの IT 組織では、変更諮問委員会 (CAB) は、各変更のリスクを評価し、承認する (または承認しない) ことを任務としています。通常、CAB は、定期的にスケジュールされたミーティングを開催して提案された今後のすべての変更をレビューし、必要に応じてエキスパートを招いて変更を説明、主張、または一緒に評価します。
変更諮問委員会は、リスクを軽減し、変更が会社にとって単に機能しないときにアラートを発生させるのに役立ちます。その一方で、特に変更諮問委員会がデプロイする変更に近くない人々で構成されている場合は、ボトルネックになる可能性もあります。多くの企業では、変更諮問委員会 (CAB) の承認プロセスは複雑で時間がかかるため、変更プロセスの速度が低下します。
多くの IT チームは、従来の CAB ミーティングから離れるか、範囲を最もリスクの高い変更と組織の重要な懸念事項に範囲を限定しています。このパラダイムでは、CAB はトレンドを監視してプラクティスがどのようにトレンドに対処できるかについてアドバイスを行い、チームとそのニーズ間の調整を担当する信頼できるアドバイザーになれます。
また ITIL 4 は、変更権限者をビジネスの関係者またはピア レベルに分散することも奨励しています。別個の委員会を使用するのではなく、関連する関係者との通常のワークフローに変更管理を組み込みます。ボトルネックの状況を回避するには、より機敏で協力的な代替手段として、自動化、仮想チェックリスト、ピア レビューを検討してください。
変更管理プロセス
機敏でベロシティの高いチームの場合、変更管理プロセスは、時間のかかるレビューや技術以外の関係者の承認から、IT チームと開発チーム間の自動化された協調的なプロセスにシフトしています。これにより、リスクのバランスをとりながらアジャイルが向上します。
変更管理プロセスの基本的な概要と、価値を提供するスピードを上げるためのいくつかの推奨事項を次に示します。
| Step | Best Practices |
| 変更リクエスト - 誰かが変更をリクエストし、考えられるリスク、想定される実装、影響を受けるシステムに関するメモを含めます。 | 標準変更リクエストを簡単に起票するには、関係者と IT スタッフ向けの直感的なセルフサービス ポータルを設定します。 開発チームと IT チームが同じプラットフォーム上で共同作業を行い、変更リクエストのワークフロー全体で完全なコンテキストと透明性を確保できるようにします。 |
| 変更リクエストのレビュー - 変更管理者またはピア レビュアーが初期変更リクエストをレビューします。成功する可能性はどれくらいありますか? リスクとリターンは正確ですか? それは作る価値がありますか? | 自動化を使用して変更を自動承認するか、変更を実装する前に簡単な承認プロセスを開始します。 |
| 変更計画 - チームは変更のゲーム プランを作成します。期待される結果、リソース、タイムライン、テスト要件、必要に応じて変更をロールバックする方法をドキュメント化します。 | 変更管理のキックオフに合わせて関係者を迅速に調整します。 ナレッジ ベース テンプレートを使ってチーム内で同じ情報を共有し、変更計画をドキュメント化します。 |
| 変更の承認 - 適切な変更マネージャー、ピア レビュアー、またはレビュアー CAB が計画をレビューして変更を承認します。 | ピア レビューで承認を合理化します。作業の追跡とドキュメントを共有することで、サイロ化と戦い、非同期で簡単に共同作業を行えます。 |
| 変更の実装 - チームは変更をリリースして、さらに手順と結果を文書化します。 | 自動化を使用して、プロセスと基準を有効にします。ワークフローの自動化では、ビジネス ルールに基づいて、次の承認済み担当者にリクエストをルーティングして割り当てられます。 |
| 変更のクローズ - 必要に応じて、変更マネージャーが変更をレビューし、適切な場合は変更を閉じます。レポートは、変更が成功したかどうか、タイミングが適切か、見積もりが正確だったかどうか、予算内かなどを伝達する必要があります。 | チームが以前の作業から学べるように、アクセス可能なナレッジ ベースの記事とチケットを保持します。将来、同様の変更リクエストを自動化する機会があるかもしれません。 |
変更管理のベスト プラクティス
前に述べたように、変更管理は、一部の人が葉物野菜を食べることについて感じるのと同じ種類の不安を引き起こします。私たちはいつも料理を楽しみにしているわけではありませんが、それがどれほど重要かを知っています。そして、私たちは両方のことをより魅力的にするための手段を講じられます。
最新の変更管理のベスト プラクティスをいくつか紹介します。
- 組織のリスク許容度と規制上の義務を理解する
- 変更管理プロセスを可能な限り簡素化して自動化する
- CAB により戦略的な焦点を当てる
- 標準変更を新しい通常変更にするプラクティスを取り入れる
- ITIL や DevOps などのさまざまなフレームワークを検討して、組織に最適なガイドラインを見つける
- コラボレーションに優先順位を付ける
- カオス エンジニアリングを使用してリスクを軽減する
- IT チームと開発者チームの変更リクエストの取り込みを合理化する
- 変更メトリックと KPI で学習を加速させる
- リリース管理に対する DevOps 主導のアプローチを取り入れる
変更管理の課題にうまく対処する
開発者は、手動によるドキュメント化にさらなる時間と労力を費やすことなく、迅速にコードをロールアウトしたいと考えています。IT 運用チームは、リスクを軽減して監査用に詳細な記録を維持し、インシデントを回避しようと努めています。プロセスに追加手順を追加して物事を書き留め、出退勤時間を記録するように開発者に依頼することは、開発者を仕事の最終的な目標から遠ざけているように感じられます。既存のプロセスを見直すように運用チームに依頼して承認チェックを廃止し、多くを自動化にすることは容易ではなく、リスクが増大しているように感じられます。
一方で、プレッシャーがこれまで以上に大きくなっています。ソフトウェアを利用したサービスの台頭により、常時稼働の高パフォーマンスなサービスに対する顧客の期待と需要が高まっています。さらにダイナミックな環境では、サービスの管理に必要な作業が増え続けています。
では、これらの課題を克服するにはどうすればよいでしょうか? まず、重いプロセスがリスクを減らすという神話を払拭することから始まります。次に、チームのコラボレーションとリリースを支援する文化、対応するプラクティス、ツールを受け入れます。最後に、以前のステップの価値を示すために情報を継続的に取り込み、改善に向けて努力し続けます。
Jira Service Management が変更管理プロセスを変革する方法についてご覧ください。
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
ホワイトペーパーを読むナレッジ・ベース：コラボレーションを向上させる方法
ナレッジ・ベースがお客様のビジネスにどのように役立つかをご覧ください。生産性を高め、カスタマー・サービス強化し、情報管理を効果的に合理化します。
記事を読む