Close

ベロシティの高い ITSM の準備

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

変更管理は、プロセスの負荷が大きく、ぎこちなく、難しいという評判があります。しかし、実際に必ずそうなるとは限りません。IT 変更管理がうまく実行されると、インシデントが減ると同時に、プロセスがアジャイルになり、作業の中断が最小限に抑えられます。

では、変更管理はどのように実行すればよいですか? 次の 10 のベスト プラクティスを開始することをおすすめします。

1. 組織のリスク許容度を理解し、それに応じて計画を立てる

リスクとスピードのバランスをとることに関しては、変更管理では、すべてに対応した万能のソリューションはありません。あらゆる組織には独自の文化、リスク許容度、対処すべき規制要件があり、各組織がこれらの考慮事項を変更管理のプラクティスに組み込む必要があります。

リスクを理解することの一部は、企業の規制およびコンプライアンス義務を理解することです。規制が入り込むと、事業を失う前にシステムがどれだけのダウンタイムを危険にさらす可能性があるのか、または問題を修正する必要がある場合にどのようなリソースがかかるのかという問題ではなくなります。さて、それは交渉の余地がない一連のルールです。特定の承認が必要になります。そこで、職務を分離します。SOX や GDPR などの規制により、プロセスが少し遅れただけでも、特定の活動は交渉不能になります。

良い点は、この計画は静的である必要がないということです。承認が多く、ワークフローが厳密である保守的なアプローチを選択している企業は、常に長期的に再評価し、プロセスの厳密性のレベルを調整してリスクのレベルとバランスを取れます。

2. データ主導のリスク評価を使用して、変更管理プラクティスを継続的に適応させる

指標、特に変更とインシデント間のリンクを追跡することは、変更プラクティスを改善するうえで重要な基盤となります。データはトレンドを強調し、インシデントに関与する可能性が最も低い変更のタイプ、チーム メンバー、サービスを明らかにします。この情報は、厳密性をさまざまな変更リクエストに対するリスクと一致させるのに役立ちます。

スマートなリスク評価では多くの場合、変更リクエストをそれほど厳密ではない承認ワークフローにダウングレードできます。Gartner の適応型変更管理プロセスが示すように、組織は、標準として分類され、事前承認および自動化される通常変更にますます取り組めます。

以下では標準変更を新しい通常変更にする、いくつかの実用的な手順をまとめています。

  1. 過去数か月間の変更をレビューする
    • 最も一般的な変更は何ですか?
    • 「標準変更」とはどの変更ですか?
    • どのようなサービスに影響を与えますか?
    • 成功した変更はどれですか?
    • これらの変更の実装に要した平均時間はどれくらいですか?
    • 開発チームからリクエストされた変更はどれですか?
  2. 自動化する候補として 3 ~ 5 つの標準変更を選択する
  3. サービス管理ソフトウェアの標準変更に対して、セルフサービス リクエスト タイプを作成する
    • テキストを追加して、標準変更リクエストの目的と範囲を明確にする
    • 変更されているシステム、アプリケーション、サービスなど、重要なフィールドを取り込む
    • 自動化ルールを作成して変更やトランジション ステータスを自動承認し、スタッフに更新を通知する
  4. この新機能について、時間をかけて IT スタッフと開発チームを教育およびトレーニングする
  5. 今後数か月間のパフォーマンスを監視する
    • 既存のサービスを改善するためのインサイトを得る
    • 自動化する追加の標準変更を特定する

3. 変更管理をできる限りシンプルにする

誰も余分な作業を望んでいません。そしてそれこそ、変更管理がしばしば厄介なものと見なされる理由です。変更管理プラクティスは、多くの場合、作業したくないツールで何かをドキュメント化し、追加ステップが 1 つまたは 2 つあるプロセスを待機するようスタッフに求めます。また、コードをライブでプッシュする開発者にとって、これらの追加タスクは実際の作業の邪魔になっているように感じることもあります。

この大きな課題に対する答えは、変更管理プロセスをできる限りシンプルにすることです。可能な限り承認を最小限に抑えてください。開発者が複数のシステムに同じ情報を入力する必要がないよう、シームレスに統合するテクノロジー ツールを選択します。そして、可能な限り自動化してください。

プロセスをシンプルにすればするほど、チームを参加させて確保することが容易になります。

4. 従来の CAB モデルを再考する

従来のほとんどの IT 組織では、変更諮問委員会 (CAB) は、変更要求の技術的およびビジネス上の影響を評価する任務を負っています。従来のプロセスでは、遅いリリース、ぎこちないプロセス、場合によってはコミュニケーションとコラボレーションの不足など、いくつかの課題が発生します。これが、最高の成果を上げているチームが CAB モデルを再考している理由です。

目標は、これらのボードが IT プロセスに付加する価値を維持して、コミュニケーションを可能にして変更の必要性とそれらの変更に伴うリスクのバランスをとる一方で、一般的な CAB プロセスをより機敏かつ戦略的にすることです。これは通常、次のことを意味します。

  • 最もリスクの高い変更についてのみ CAB の承認を求める (ピア レビュー、仮想チェックリスト、自動化などの実証されたツールを使用して、リスクが低い変更を管理する)
  • CAB に戦略を任せて、チームがリスクを軽減し、プロセスの効率化と自動化を通じて変更管理の作業負荷を削減するプラクティスを開発できるよう支援する
  • 主要な変更に対処したり、質問を処理したりするための対面会議を待つのではなく、CAB を仮想かつリアルタイムにする

ここでの鍵は、戦略へのシフトです。新しい CAB は、ゲートキーパーとして機能するのではなく、変更を可能にするためにあります。新しい CAB は、ボトルネックになるのではなく、戦略的なリソースです。コード レビューと技術的な詳細の確認は、ピア レビューやコード内のエラーを見つけるのに最適なスタッフのために予約されます。CAB は、プロセス、戦略、継続的なデリバリーのサポートに専念するために解放されます。

5. ツールを使用してプロセスを自動化し、プロセスに磨きをかける

ツール内の自動化は、チームにおける変更管理プロセスの負担を最小限に抑えるための最良の方法の 1 つです。ツール内のシンプルな牽制と均衡の仕組みによって、新しいプロセスに不要な時間を費やすことなく、コンプライアンスを維持してリスクを大幅に軽減できます。

Atlassian の Risk Futurist の Guy Herbert 氏は、コンプライアンスとリスクに関する最近の記事で「実際のところ、6 階層承認プロセスやコンプライアンス承認委員会との数か月にわたるやり取りが本当に必要な組織は、ほとんど存在しません。私たちに本当に必要なのは準拠していない変更がドアを通過しないようにする、いくつかのシンプルな牽制と均衡の仕組みです。そして、その多くは私たちのツール自体で行えます。たとえば Bitbucket では、別の適切な開発者によってピア レビューされるまで、開発者は作業したコードをデータベースにプッシュできません。Bamboo は、Bitbucket のコンプライアンス プロセスを通過していない新しいコードを起動しません」と語っています。

6. 小規模なリリースを段階的にデプロイして、変更がうまく行くようにする

リリースに対する従来のアプローチは、リリースを 1 つにまとめて一度にすべてを起動することでした。私たちのほとんどが現在知っていることは、このアプローチが重大なインシデントにつながり、問題が発生したときに問題の原因を見つけることが困難になるということです。より小規模で頻繁なリリースでは、潜在的なインシデントの範囲を制限できます。段階的なアプローチでは、完全なデプロイの前に安定性をテストして証明するために、ユーザーの小さいサブセットでカナリアまたは機能フラグをデプロイします。

7. ITIL を厳密なルールではなく、ガイドラインとして扱う

ITIL は、あらぬ非難を受けることがあります。それは、限定的で時代遅れであると見なされます。しかし実際には、ITIL は DevOps 文化を採用した IT チームなど、IT チームに提供するものがたくさんあります。ここでの問題は、ITIL が厳密すぎることではありません。それは、私たちがどのようにそのガイドラインに近づくかです。

一連の厳密なルールとして ITIL に取り組むと、当然のことながら堅苦しいと感じるでしょう。会社で推進できる一連の基本的なガイドラインとして ITIL に取り組むと、変更管理プラクティスを開発する際に足がかりのように感じるでしょう。

これは、あらゆるフレームワークと文化的なアプローチに適用されます。ITIL、リーン、DevOps、アジャイル、CD など、どんなに人気があっても、フレームワークは一挙にすべての問題を解決しません。私たちはチームの文化を調べる必要があるときに、内部の問題を解決するためのフレームワークやツールを探すことがよくあります。

8. コラボレーションに優先順位を付ける

CAB から DevOps グループまで、主要なチームはコラボレーション、オープン性、リアルタイムの更新を採用しています。チーム間で調整するために変更管理が存在します。変更、インシデント、問題は、複数のチームにわたって波及効果をもたらします。つまり、組織が複雑化するほど明らかになります。

優れた変更管理は、サイロでは実現できません。よりオープンなコラボレーションを促進するために取り組む組織は、変更プラクティスを向上させる可能性があります。

9. カオス エンジニアリングとレジリエンス エンジニアリングを活用する

カオス エンジニアリングは、製品またはサービスのコンポーネントを壊したり停止したりすることで、レジリエンスをテストすることに焦点を当てた最近のプラクティスです。同様に、レジリエンス エンジニアリングは、システム上で発生する可能性のあるすべてのストレス要因に意図的に対処します。たとえば、ユーザー数またはトラフィックが多いシステムをプッシュします。

どちらのプラクティスも、将来のインシデントを回避するために発生する問題と変更を特定するためのものです。この事前対策型アプローチは、変更管理チームにとって大きな価値をもたらし、インシデント管理チームの時間、予算、アラートによる疲弊を大幅に削減します。

10. 開発チームにとって身近で、開発チームによって採用されているツールを選ぶ

開発者が使用するツール全体にわたって、優れた変更管理プロセスを組み込む必要があります。新しいツールを学んだり、複数のツールに情報を入力したり、不慣れで使いづらいツールを扱うようにチームに依頼したりすると、導入が遅くなる傾向があり、価値あるアップデートを顧客に提供する能力が損なわれます。

Atlassian では、Jira Service Management を使用して変更を追跡します。Jira プラットフォームにより、開発チームと運用チームが簡単に連携できるようになり、開発者がコーディングを開始する前から、変更が本番環境にデプロイされるまで、透明性と追跡可能なコンテキストが提供されます。