チームで変更管理の役割と責任を共有する方法

変更マネージャー/コーディネーター

通常、変更マネージャー (変更コーディネーターとも呼ばれる) は、IT 変更のすべての側面を管理する責任があります。変更リクエストに優先順位を付けてその影響を評価し、変更を承認または拒否します。また、変更管理プロセスと変更計画もドキュメント化します。重要なのは、変更マネージャーが CAB ミーティングを準備して組織し、議長としての役割を果たすことです。変更マネージャーの成功は通常、タイミングと予算の目標を満たしているかどうかによって評価されます。

変更権限者/変更承認者

変更権限者とは、変更を承認するかどうかを決定する人です。これは、マネージャーやエグゼクティブなど、1 人の場合もあります。また、変更諮問委員会のメンバーのグループの場合もあります。さらに、ピア レビュアーの場合もあります。ITIL 4 によると、「ベロシティの高い組織では変更の承認を分散化して、ピア レビューを高パフォーマンスの重要な予測の手がかりにすることが一般的です」と説明されています。

通常、変更マネージャーは、変更権限者と緊密に連携して、変更を承認して組織内で変更を進めます。場合によっては、特に小規模な組織では、変更マネージャーが変更権限者であり、追加のスタッフやチームを関与させることなく、これらの決定を行う権限があります。

ビジネスの関係者

ビジネスの関係者は多くの場合、変更管理に関与して承認プロセスに関与させられます。ほとんどの企業にとってソフトウェア サービスの重要性を考えると、これはますます一般的になっています。

たとえば、変更が財務チームの支払追跡ソフトウェアとセールス チームの CRM 間の接続に影響を与える場合、財務チームとセールス チームの関係者は、CAB ミーティングと変更について行われた最終的な決定に関与する必要があることがあります。

エンジニア/開発者

開発チームは通常、承認のために変更を送信して、必要に応じてケースをドキュメント化します。変更が承認されると、自社で構築して実行するアプローチを採用している企業では、これらのチームが変更をデプロイして監視し、変更に関連するインシデントや問題に対応することがよくあります。他のケースでは、変更によって発生したインシデントを担当するインシデント管理チームが、変更を実装する開発者とは別の場合があります。

サービスデスクエージェント

サービス デスク エージェントは、変更によって発生する可能性のあるインシデントと一般的なサービスの課題について、独自の最前線の視点をもたらせます。

運用マネージャー

日常的にシステムの運用を維持する責任があるため、リスクと依存関係に介入します。

顧客関係マネージャー

顧客の声を表すために、顧客の考え方、不満、絶えず変化するニーズについての知識を提供できます。

情報セキュリティ担当者とネットワーク エンジニア

ネットワーク セキュリティとクラウド インフラストラクチャのエキスパートは、脅威と脆弱性に関する重要なインサイトをもたらします。

CAB とは

上記の責任を持つ人々を招集する変更諮問委員会 (CAB) は、各変更リクエストのリスクを評価し、承認する (または承認しない) ことを任務とするグループです。通常、CAB は、定期的にスケジュールされたミーティングを開催して提案された今後のすべての変更をレビューし、必要に応じてエキスパートを招いて変更を説明、主張、一緒に評価します。従来の CABは、変更のリリースを制御するゲートキーパーとして知られています。

これに加えて、面倒なミーティング、変更リクエストの長いバックログ、作業自体からの距離のため、CAB は軽視されがちです。幸いなことに、多くの CAB は、より戦略的なアドバイザリーの役割を引き受けて、アジャイルなソフトウェア デリバリーをより可能にするために進化しています。CAB は、変更のトレンドを監視して変更に対処できるプラクティスを推奨し、チームが顧客に価値を提供してリスクを軽減できるようにする方法を模索するアドバイザーへと変容しています。

CAB の課題

役に立たないミーティングに関する決まり文句は、CAB にも当てはまります。私たちは、CAB が十分な成果を上げていない、関係するランダムな人々が多すぎる、「代わりに電子メールだったかもしれない」ときに CAB が存在しているため、CAB を時間の無駄としてかなり批判しています。これは部分的に、従来の CAB に責任で負担かけた方法によるものです。

その課題を説明するために、航空のメタファーを見てみましょう。CAB は空港の管制塔と見なせます。その管制塔には、着陸が許可されたら、飛行機に知らせるという 1 つの仕事があります。飛行機が構造的に安全であるかどうか、またはパイロットが正しい資格証明書を持っているかどうかを評価することは決してありません。これらの要素はすでに FAA などによって確認されているからです。

その一方で、あまりにも多くの CAB がさまざまな関係者を集め、あらゆる種類のさまざまな異なる変更について幅広い安全性の決定を行う任務を負います。これは、疲れきった人々が週末に向けて出発したがるようになるため、週末によく発生します。CAB は、成功するために設置されているのではありません。

さらに、多くの場合、CAB はインシデントを引き起こす変更のリスクを主に懸念しています。これはもちろん重要ですが、重要な変更を遅らせるリスクも検討する必要があります。移動が遅すぎると、顧客に損害を与える可能性があります。また、競争の激しいサービスとしてのソフトウェアの世界では、組織を沈める可能性があります。

CAB の役割を高め、その役割にフォーカスできます。適切なプラクティスを導入すれば、多くの変更を自動化できます。このように、CAB は重要なアドバイザーとなり、トレンドを追跡し、チームと連携して、顧客に利益をもたらす迅速な変更を実現できます。

CAB を戦略的なアドバイザーとして位置付ける方法

CAB を再配置する最初のステップは、ヘビーウェイトな変更管理が前向きな成果を生み出すという概念をなくすことです。DevOps 状況レポート 2019 のデータでは、CAB の承認を必要とするプロセスがソフトウェア デリバリーのパフォーマンスに悪影響を及ぼし、これらのプロセスに従った回答者は、パフォーマンスが低い可能性が 2.6 倍高いことがわかりました。さらに、正式な承認プロセスが変更の失敗率の低下に関連していることを裏付ける証拠はありませんでした。

このため、モダンなチームは、CAB を改善するために次のステップを実行しています。

変更リクエストを「すべてに対応する」方法で処理するのを止める

あらゆる変更リクエストは、情報を追跡して収集する機会です。私たちは、成功率、関連するインシデント、それらと相関する要因について学べます。時間の経過とともに、データを適用すると、より多くの変更を事前承認して自動化できます。対面承認が必要となるのは、最も重要なリスクの高い変更だけです。

変更管理とリリース管理をより緊密に結びつける

リリースに対する従来のアプローチは、リリースを 1 つにまとめて一度にすべてを起動することでした。その後、CAB は膨大な変更パッケージを見直して承認する必要があります。このアプローチは、重大なインシデントにつながる可能性があり、問題が発生したときに問題の原因を見つけることが困難になります。また、チームが顧客に価値を提供できる速度も低下します。これは、変更マネージャーとリリース マネージャーがプロジェクト管理タスクに割り当てる時間を短縮できることも意味します。

段階的なリリースを使用してテストと反復を行う

段階的なアプローチでは、完全なデプロイの前に安定性をテストして証明するために、ユーザーの小さいサブセットでカナリアまたは機能フラグをデプロイします。これにより、潜在的なインシデントの範囲が制限され、すべての環境にロールアウトする前にデプロイの成功が証明されます。

自動化とツールを使用して、変更管理を合理化する

ベロシティの高いチームは、以前の承認モデルを再考し始めています。変更要求の長いバックログには毎週の対面会議で対処するのではなく、仮想コラボレーションを利用できます。これは変更リクエストの詳細を記載したメールと同じくらい簡単で、CAB ミーティングの前にレビューできます。また他のケースでは、Jira チケットや Confluence ページなどによって、レビュアーは非同期でコラボレーションして変更を承認するために必要なコンテキストを有効にできます。Jira Service Management によってチームはこのような方法でコラボレーションして、ビデオ会議に参加または指定された Slack チャンネルを作成できます。チームの連絡方法にもよりますがそれも同じ場所に保管されているため、チームメイト全員の足並みを揃えられます。

従来の ITSM ツールでは、インフラストラクチャ、運用、開発の各チームが変更リクエストを起票することが困難になります。変更情報を手動で入力する負担を減らすために、自動化と最新のソフトウェアをご検討ください。開発者が最も避けたいことは、その作業が自動で追跡できるのに不便な別のシステムでチケットを入力することです。Jira Service Management では、チームは自動化によって変更プロセスを合理化してリスクを最小限に抑え、ダウンタイムを削減できます。

シフト レフトして、変更管理と実務担当者をより緊密に結びつける

CAB 承認を置き換える、または減らすことが多い最も一般的な戦略の 1 つは、ピア レビューです。ピア レビューでは、コードを最もよく理解している人にコードの課題を特定する責任があります。ITIL 4 では、「ベロシティの高い組織では、変更の承認を分散化し、ピア レビューを高パフォーマンスの重要な予測の手がかりにすることが一般的です」と指摘しています。同様に、DevOps 状況レポート 2019 では、「組織は、開発プロセス時にピア レビューベースの承認を『シフト レフト』すること」が推奨されています。

規制の遵守を維持するには、細心の注意を払ってこのアプローチをドキュメント化する必要があります。そこで、Bitbucket のようなシステムを導入し、作成者とピア レビューを自動的に追跡し、必要なプロセスなしで変更がライブでプッシュされないようにします。

Atlassian では、ピア レビューは承認プロセスの核となる部分です。当社の IT リスクとコンプライアンスのエキスパートの 1 人の説明で、「Atlassian コードはすべて Bitbucket に格納されています。開発者が変更を加えたいときは、コードを Bitbucket から各自のノートパソコンにチェックアウトします。Bitbucket リポジトリに再びチェックインすると、コードを更新する代わりに、システムはピア レビューを要求するように設定されます。そのレビューが完了して承認された後にのみ、コードがリポジトリに再度プルされます。コードが承認されなかった場合は、ピア レビュアーのメモとともに元の開発者に送り返されます。開発者は間違っている内容を修正して、他のピア レビュー用に送信します」と述べています。

エキスパートを招集して優れたプラクティスを実現する

組織が複雑になるにつれ、チーム間の情報フローと調整の促進がますます重要になっています。CAB は、個々の変更リクエストを承認するのではなく、改善を実践することに焦点を移せます。このパラダイムでは、プラクティスの改善に関する推奨事項の提供、より優れた機能の実装、パフォーマンスの向上につながるリソースとツールの提供に注目できます。これにより、CAB の範囲が広がり、市場に価値を提供するには遅すぎるリスクに対処します。

従来の IT 組織でも、CAB は創造的なソリューションを考え出す場所になる可能性があります。あるケースでは、従来の ITSM ツールとプラクティスに固執するリスク回避を好む大学では、利用できない重要なサービスについて学生に知らせる方法を見つけ出す必要がありました。CAB は、新しい通信戦術をブレーンストーミングするためのフォーラムとなりました。計画されたシステム アップグレードについての受信リクエストを逸らすのに効果的だったキャンペーンで、キャンディやポスターを配ることに決めました。