DevOps プロセス: 変更承認の効率化

多くの IT 組織は、社内外に提供している IT サービスの変更を管理するため、チェンジ マネジメント プロセスを導入しています。多くの場合、このプロセスは運用やセキュリティに対する変更の影響を軽減する一次的なコントロールとして機能します。

多くの場合、チェンジ マネジメント プロセスには外部の審査担当者や変更諮問委員会(CAB)による承認プロセスが含まれています。

コンプライアンス管理者やセキュリティ管理者は、チェンジ マネジメント プロセスに従ってコンプライアンス要件の検証を行いますが、変更を承認するにはエビデンスが必要になります。

2019 年の State of DevOps Report(PDF)で公開されている DevOps Research and Assessment(DORA)の調査によると、変更承認は、開発プロセス中のピアレビューによって実施するのが最善であり、自動化によって補完されてソフトウェア デリバリー ライフサイクルの早い段階で不正な変更を検出、予防、修正できます。継続的なテスト継続的インテグレーション包括的なモニタリングとオブザーバビリティなどの手法によって早期検出、自動検出、可視化、迅速なフィードバックを提供します。

さらに、既存のプロセスをより適切に伝え、チームが効率的にプロセスを進められるようにすることで、組織のパフォーマンスを向上させることができます。チームメンバーが変更承認プロセスについて明確に理解していれば、パフォーマンスが向上します。

変更承認プロセスの実装方法

変更承認プロセスの 2 つの重要な目標は、変更によってリスクを軽減し、規制要件を満たすことです。一般的な規制要件の 1 つに職掌分散があります。これは、著者以外の関係者が変更を承認する必要があるため、個人がプロセス全体に対して完全な制御をできないようにします。

従来、これらの目標は、発案チーム外の人物(変更諮問委員会(CAB)やシニア マネージャーなど)による承認を含む影響力の大きいプロセスを通じて達成されていました。しかし、DORA の調査では、これらのアプローチはソフトウェア デリバリー パフォーマンスに悪影響を及ぼしています。さらに、より正式な外部レビュー プロセスによって変更失敗率を減少できるという仮説を支持する根拠も得られませんでした。

このような影響力の大きいアプローチでは、デリバリー プロセスが遅くなり、大規模なバッチのリリースにつながりづらくなります。また、高レベルのリスクが伴う可能性が高い本番環境システムへの影響も増大し、失敗率が高くなります。DORA の研究では、この仮説はデータでサポートされていることがわかりました。

代わりに、チームは次のことを行う必要があります。

目標は、定期的なチェンジ マネジメント プロセスを迅速かつ信頼性の高いものにして、緊急の変更にも使用できるようにすることです。

典型的な継続的デリバリーにおいて、CAB には、次のような重要な役割があります。

  • チーム間の通知や調整を円滑に促進する。
  • プロセス改善の取り組みにおいてチームを支援し、ソフトウェア デリバリー パフォーマンスを向上させる。
  • 製品化までの時間とビジネスリスクの判断など、より高いレベルでのトレードオフとサインオフを必要とする、重要なビジネス上の意思決定に重点を置く。

この新しい CAB の役割は戦略的です。詳細なコードレビューを実務担当者や自動化された方法に移行することで、リーダーや管理職の時間と労力を削減し、より戦略的な作業に集中できるようになります。このような、ゲートキーパーからプロセス アーキテクトおよび情報ビーコンへの移行は、ソフトウェア デリバリーのパフォーマンスに優れている組織の慣例と整合します。

変更承認プロセスで陥りやすい落とし穴

変更承認プロセスには次のような欠点があります。

エラーの発見と変更の承認を変更諮問委員会(CAB)に依存してしまう。これにより、遅れが生じたり、間違った判断が行われたりする可能性があります。CAB では、メンバー全員が変更を認識できますが、変更の現場から遠く離れているメンバーはその変更の意味を理解しない可能性があります。

すべての変更を同等に扱ってしまう。変更によってリスク プロファイルやタイミングが異なります。すべての変更を同じ承認プロセスで処理するのは効率的ではなく、重要な変更を見逃してしまう可能性があります。また、十分な時間を費やせないこともあります。

継続的な改善を適用できなかった。すべてのプロセスと同様、リードタイムや変更失敗率などの主要なパフォーマンス指標は、チェンジ マネジメント プロセスをより効果的にナビゲートするためのツールやトレーニングをチームに提供することを含め、チェンジ マネジメント プロセスのパフォーマンスを向上させることを目標とするべきです。

プロセスを追加して問題に対応する。多くの場合、組織は本番環境において安定性に問題が発生した場合、追加のプロセスと影響力の大きな承認を使用します。分析は、このアプローチはリードタイムとバッチサイズを増加させ、悪循環を生み出すため、状況を悪化させることを示唆しています。スピーディーかつ安全な変更を行うための投資に注力してください。

変更承認プロセスを改善する方法

変更承認プロセスを改善するには、次のことがポイントとなります。

  1. 個々の変更に対するピアレビュー ベースのプロセスに移行し、コード チェックイン時に適用され、自動テストによってサポートされる。
  2. 変更が確定された後に、できるだけ早く自動化された方法で、回帰、パフォーマンスの問題、セキュリティの問題などの問題を発見する方法を見つける。
  3. 継続的に分析によってリスクの高い変更を早期に検出して報告し、追加の調査をできるようにする。
  4. 変更プロセスをエンドツーエンドで確認してボトルネックを特定し、開発プラットフォームに検証機能を移行する方法を試してみる。
  5. ソフトウェア デリバリー プロセスの一部として手動でのレビューを行うのではなく、プラットフォームとインフラストラクチャ レイヤおよびデベロッパー ツールチェーンに情報セキュリティ制御を実装する。

2019 年の State of DevOps Report(PDF)から調査したところ、従来の正式なチェンジ マネジメント プロセスから脱却することは最終的な目標であり、既存のプロセスをより適切に伝えること、チームが効率的にプロセスを進められるようにすることで、ソフトウェア デリバリーのパフォーマンスに良い影響を与えます。チームメンバーは、変更の承認申請のプロセスを明確に把握でき、高いパフォーマンスが得られます。つまり、承認プロセスによってタイムリーに変更できることに自信を持っており、通常行うあらゆる種類の変更について、毎回「提出」から「承認」に至るまでに必要なステップを知っていることを意味します。

変更承認プロセスを測定する方法

変更承認プロセスの状態は次の方法で測定できます。

テスト項目 測定データ
手動による変更承認を行わずに変更を本番環境に移行できるか? 本番環境への移行を手動で行う必要がある変更の割合(または行う必要がない変更の割合)。

ヒント: この項目はリスク プロファイル別に測定することもできます。高リスク、中程度のリスク、低リスクのそれぞれの変更で手動承認が必要な割合を測定します。
本番環境に対する変更をデプロイまたは実装する前に社外の審査担当者の承認が必要か? 社外の審査担当者が変更を承認するまでの時間。

ヒント: 社内で承認を行っている場合は、社内の審査担当者または承認者が承認するまでの時間を測定します。

この項目もリスク プロファイル別に測定できます。外部の審査担当者による承認が必要な変更の数または割合、その承認にかかる時間を測定します。
変更管理にピアレビューを行っているか? ピアレビューで管理している変更の割合。

この項目もリスク プロファイル別に測定できます。
チームメンバーは、変更の承認を得るためのプロセスを明確に理解しているか。 チームメンバーが承認プロセスを介して適時に変更できることに自信を持っており、通常のあらゆる種類の変更に対して毎回「提出」から「承認」に至るまでに必要なステップを知っている。

環境はそれぞれ異なるため、自社の変更承認プロセスの状況を把握するために独自の測定方法が必要になることもあります。その場合、プロセスを測定するだけでなく、プロセスを改善するための対策も行う必要があります。

次のステップ