IT サポート ワークフローを改善する方法
チームで変更管理の役割と責任を共有する方法
変更管理プラクティスの中核となる目標は、顧客を満足させて競合他社よりも先んじてアップデートをリリースする際のインシデントを減らすことです。また、このプラクティスは重要です。今日、顧客は常に、パフォーマンスの高いサービスへの期待を高めています。さらにダイナミックな環境では、サービスを慎重に管理して頻繁な改善をリリースすることが不可欠です。モダンなチームは、可能な限り最も合理的でアジャイルな方法で顧客に価値を提供しながら、リスクの軽減を可能にするプラクティスを採用しています。
これらの目標を達成するために、組織は変更管理に関連するさまざまな役割と責任を指定しています。大企業では、さまざまな職務説明とチーム間でこれらを共有できます。
小規模な組織では、1 人の担当者が自分の仕事の他の要素と一緒に変更管理の責任を引き受ける場合があります。変更管理の責任を持つ担当者は、開発者またはチーム リーダーでもある場合があります。他のケースでは、プロセスはゆっくり組み込まれ、既存のチーム間で共有される場合があります。
変更管理の責任を割り当てるための適切なモデルは、1 つではありません。組織は、各自のニーズに最も適した配置を考え出す必要があります。つまりすべてのチームは、レビューするプロジェクトから非常に離れていることが多い特定の肩書きを持つ担当者に、変更責任を委任するアプローチを再考することで、メリットを得られます。
変更管理プラクティスを自動化して既存のワークフローに合理化する新しい機会を取り入れることで、変更管理に関わる担当者がより戦略的な役割を引き受けて、チームが最も重要な優先事項に集中できるようにできます。
変更管理の一般的な役割
変更管理に関与する役割は、IT 組織の規模や種類など、さまざまな要因によって異なります。ここでは、最も一般的な職位をいくつか示します。
変更マネージャー/コーディネーター
通常、変更マネージャー (変更コーディネーターとも呼ばれる) は、IT 変更のすべての側面を管理する責任があります。変更リクエストに優先順位を付けてその影響を評価し、変更を承認または拒否します。また、変更管理プロセスと変更計画もドキュメント化します。重要なのは、変更マネージャーが CAB ミーティングを準備して組織し、議長としての役割を果たすことです。変更マネージャーの成功は通常、タイミングと予算の目標を満たしているかどうかによって評価されます。
変更マネージャー/コーディネーター
通常、変更マネージャー (変更コーディネーターとも呼ばれる) は、IT 変更のすべての側面を管理する責任があります。変更リクエストに優先順位を付けてその影響を評価し、変更を承認または拒否します。また、変更管理プロセスと変更計画もドキュメント化します。重要なのは、変更マネージャーが CAB ミーティングを準備して組織し、議長としての役割を果たすことです。変更マネージャーの成功は通常、タイミングと予算の目標を満たしているかどうかによって評価されます。
変更マネージャー/コーディネーター
通常、変更マネージャー (変更コーディネーターとも呼ばれる) は、IT 変更のすべての側面を管理する責任があります。変更リクエストに優先順位を付けてその影響を評価し、変更を承認または拒否します。また、変更管理プロセスと変更計画もドキュメント化します。重要なのは、変更マネージャーが CAB ミーティングを準備して組織し、議長としての役割を果たすことです。変更マネージャーの成功は通常、タイミングと予算の目標を満たしているかどうかによって評価されます。
変更権限者/変更承認者
変更権限者とは、変更を承認するかどうかを決定する人です。これは、マネージャーやエグゼクティブなど、1 人の場合もあります。また、変更諮問委員会のメンバーのグループの場合もあります。さらに、ピア レビュアーの場合もあります。ITIL 4 によると、「ベロシティの高い組織では変更の承認を分散化して、ピア レビューを高パフォーマンスの重要な予測の手がかりにすることが一般的です」と説明されています。
通常、変更マネージャーは、変更権限者と緊密に連携して、変更を承認して組織内で変更を進めます。場合によっては、特に小規模な組織では、変更マネージャーが変更権限者であり、追加のスタッフやチームを関与させることなく、これらの決定を行う権限があります。
ビジネスの関係者
ビジネスの関係者は多くの場合、変更管理に関与して承認プロセスに関与させられます。ほとんどの企業にとってソフトウェア サービスの重要性を考えると、これはますます一般的になっています。
たとえば、変更が財務チームの支払追跡ソフトウェアとセールス チームの CRM 間の接続に影響を与える場合、財務チームとセールス チームの関係者は、CAB ミーティングと変更について行われた最終的な決定に関与する必要があることがあります。
エンジニア/開発者
開発チームは通常、承認のために変更を送信して、必要に応じてケースをドキュメント化します。変更が承認されると、自社で構築して実行するアプローチを採用している企業では、これらのチームが変更をデプロイして監視し、変更に関連するインシデントや問題に対応することがよくあります。他のケースでは、変更によって発生したインシデントを担当するインシデント管理チームが、変更を実装する開発者とは別の場合があります。
サービスデスクエージェント
サービス デスク エージェントは、変更によって発生する可能性のあるインシデントと一般的なサービスの課題について、独自の最前線の視点をもたらせます。
運用マネージャー
日常的にシステムの運用を維持する責任があるため、リスクと依存関係に介入します。
顧客関係マネージャー
顧客の声を表すために、顧客の考え方、不満、絶えず変化するニーズについての知識を提供できます。
情報セキュリティ担当者とネットワーク エンジニア
ネットワーク セキュリティとクラウド インフラストラクチャのエキスパートは、脅威と脆弱性に関する重要なインサイトをもたらします。
CAB (変更諮問委員会) の変容する役割
Change advisory boards have historically played a crucial role in assessing the risks associated with change requests and approving or rejecting them. Traditional CABs often acted as gatekeepers controlling the release of proposed changes.
However, they have been criticized for poor time management skills, lengthy change request backlogs, and their detachment from the actual work. Fortunately, CABs are evolving to become more strategic advisors, transforming their role in the change management process.
CAB の課題
役に立たないミーティングに関する決まり文句は、CAB にも当てはまります。私たちは、CAB が十分な成果を上げていない、関係するランダムな人々が多すぎる、「代わりに電子メールだったかもしれない」ときに CAB が存在しているため、CAB を時間の無駄としてかなり批判しています。これは部分的に、従来の CAB に責任で負担かけた方法によるものです。
その課題を説明するために、航空のメタファーを見てみましょう。CAB は空港の管制塔と見なせます。その管制塔には、着陸が許可されたら、飛行機に知らせるという 1 つの仕事があります。飛行機が構造的に安全であるかどうか、またはパイロットが正しい資格証明書を持っているかどうかを評価することは決してありません。これらの要素はすでに FAA などによって確認されているからです。
その一方で、あまりにも多くの CAB がさまざまな関係者を集め、あらゆる種類のさまざまな異なる変更について幅広い安全性の決定を行う任務を負います。これは、疲れきった人々が週末に向けて出発したがるようになるため、週末によく発生します。CAB は、成功するために設置されているのではありません。
さらに、多くの場合、CAB はインシデントを引き起こす変更のリスクを主に懸念しています。これはもちろん重要ですが、重要な変更を遅らせるリスクも検討する必要があります。移動が遅すぎると、顧客に損害を与える可能性があります。また、競争の激しいサービスとしてのソフトウェアの世界では、組織を沈める可能性があります。
CAB の役割を高め、その役割にフォーカスできます。適切なプラクティスを導入すれば、多くの変更を自動化できます。このように、CAB は重要なアドバイザーとなり、トレンドを追跡し、チームと連携して、顧客に利益をもたらす迅速な変更を実現できます。
CAB を戦略的なアドバイザーとして位置付ける方法
CAB を再配置する最初のステップは、ヘビーウェイトな変更管理が前向きな成果を生み出すという概念をなくすことです。DevOps 状況レポート 2019 のデータでは、CAB の承認を必要とするプロセスがソフトウェア デリバリーのパフォーマンスに悪影響を及ぼし、これらのプロセスに従った回答者は、パフォーマンスが低い可能性が 2.6 倍高いことがわかりました。さらに、正式な承認プロセスが変更の失敗率の低下に関連していることを裏付ける証拠はありませんでした。
このため、モダンなチームは、CAB を改善するために次のステップを実行しています。
組織の変更管理プラクティスにおける責任の割り当て
変更管理プラクティスにおける役割と責任の定義に関しては、まずすべてに適した答えはないことを理解することから始めます。企業の文化、チームの構造、利用可能なスキル、規制要件などを考慮する必要があります。
ビジネスに必要な役割と責任について真の賛同を得るには、当社の役割と責任を果たすことをおすすめします。これには、チームへの各メンバーの貢献と全員が成功するために必要なことを理解するために、全員をまとめることが含まれます。
変更管理のコンテキストで役割と責任に磨きをかけるには、チームをまとめて以下の質問について話し合うことから始めることをおすすめします。
- 私たちのチームにとって、さまざまなフレームワークが意味するものは何ですか? (DevOps、CI/CD、ITIL など)
- フレームワークを包括的に導入していますか? 私たちが理解することは、自動化のような戦術的なことに限られますか?
- これらのフレームワーク、特に DevOps と ITIL は、変更およびリリースのプラクティスにどのような影響を与えますか? また、どのように連携していますか?
- 現在の変更プロセスは何ですか?
- 誰が関わっていますか?
- 改善できる場所はどこですか?
- 通常変更を標準または事前承認に変更するためにできることは何ですか?
- 最も一般的な変更は何ですか?
- 「標準変更」とはどの変更ですか?
- どのようなサービスに影響を与えますか?
- 成功した変更はどれですか?
変更管理は重要なプラクティスです、すぐにはなくなりません。変更管理プラクティスの状態に関係なく、改善の余地は常にあります。それが変更の追跡から始まるのかリスク評価と自動化システムの導入から始まるのかにかかわらずです。Jira Service Management の変更管理機能によって IT オペレーション チームがどのように強化されるかをご覧ください。
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.
ホワイトペーパーを読むKnowledge Management Explained | Atlassian
Knowledge management processes create, curate, share, use, and manage knowledge across an organization and even across industries. Learn more here.
記事を読むデプロイを停止しない: 不透明な時期での変更管理の実践
一部の企業では、ヘビーウェイトな変更管理プロセスに戻っています。ここでは、コントロールの追加を回避し、さらにプラクティスを改善する方法についてのガイダンスを紹介します。