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

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

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

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

Jira Service Management によって、承認とワークフローを組織の仕様に合わせてカスタマイズできます。プロセスを必要に応じて柔軟化または自動化します。承認を得てよりリスクの低いプロセスを自動化し、より複雑なプロセスを保護できるはずです。

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

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

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

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

チームのこれまでの変更管理プラクティス、変更リスクの順に評価した後は、リスク評価ドキュメントを 1 か所にまとめると便利です。Jira Service Management の Confluence 統合によって、チームは変更計画ドキュメントに格納された 1 つの信頼できる情報源を参照できます。このページでは、コラボレーターはリスク評価情報に加えて変更計画テンプレートを追加できます。

誰一人として余分な作業は望んでいないことこそ、変更管理がしばしば厄介なものと見なされる理由です。多くの場合、変更管理プラクティスは作業したくないツールで何かをドキュメント化して、いくつかの追加ステップがあるプロセスを待機するようにスタッフに求めます。また、コードをライブでプッシュする開発者にとって、これらの追加タスクは実際の作業の邪魔になっていると感じる可能性があります。そこで、変更計画の Confluence ページのような信頼できる情報源があれば、チーム全体を関与させて簡単にドキュメントを作成できます。

この大きな課題に対する答えは、変更管理プロセスをできる限りシンプルにすることです。承認はできる限り最小限に抑えます。開発者が同じ情報を複数のシステムに入力不要にするように、シームレスに統合するテクノロジー ツールを選択します。そして、可能な限り自動化します。Jira Service Management のこれらの機能は、チームが自分のペースで自分のやり方で運用できる柔軟性を提供します。

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

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

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

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

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

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

チームがこれらのリリースを変更スケジュールに基づいて調整できれば、小規模で管理されたリリースの組織化が簡単になります。これによって、開発者は競合する領域を回避またはサービス停止期間を特定できます。Jira Service Management の変更管理機能によって、チームはこれらの切れぎれになったリリースの実行に必要な情報を含む一元化されたスケジュールにアクセスできます。

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

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

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

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

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

Jira Service Management のすべてはチームを統合して目標をより速く達成することを目的としており、この場合は変更をより速くインシデントなしで実行することを目的としています。まとまりのあるベロシティの高いチームのメカニズムは、コラボレーションです。Confluence などのツール、統合されたチャットやビデオ会議、カスタマイズ可能なワークフローを備えた透過性の高いプラットフォームによって、誰もが作業状況の経緯を理解したうえで参加し、自分のやり方で自分の役割を果たせるようになります。

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

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

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

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