組織のソフトウェアデリバリー速度を決定する6つの次元
チームがデプロイ計画を立てるとき、会話の内容は技術的な準備状況以上に多くのことを明らかにします。誰かが「今夜DBAは対応可能か」と尋ねます。別のメンバーはステージング環境に古いデータベーススキーマが残っていないか確認します。さらに別の人は、先月本番環境で障害を引き起こした最後の変更を誰が承認したのか気にします。
これらの質問は、より深い問題の症状です。組織がソフトウェアをデリバリーする能力を促進するか、あるいは阻害する特定の領域を示しています。長年の経験から、コードから本番環境への移行をチームがどれだけスムーズに行えるかを一貫して決定する6つの次元があることがわかりました。各次元における現在地を理解することが、意味のある改善への第一歩です。
デリバリー：変更が実際に本番環境に到達する方法
デリバリーの次元は、コードの変更がコミットからデプロイに至る経路を評価します。その経路は主に手動ですか、それとも自動化されていますか？開発者は他チームの助けを借りずに自分の変更をデプロイできますか？それとも、すべてのデプロイにチェックリスト、スケジュールされたメンテナンスウィンドウ、そしてタイミング悪く沈黙するグループチャットが必要ですか？
ここでの単純な指標は、チームがいつでもデプロイできるか、それとも特定の曜日の特定の時間帯にしかデプロイできないかです。デプロイに開発者、テスター、運用チーム間の手動の引き継ぎが必要な場合、デリバリーではなく調整にエネルギーを費やしていることになります。目標は人間の判断をすべて排除することではなく、機械の方がより確実に処理できる反復作業を排除することです。
プラットフォーム：チームが作業する環境
すべてのチームにはアプリケーションを実行する場所が必要です。プラットフォームの次元は、その環境をどれだけ簡単に入手できるかを問います。開発者はメニューからオプションを選択するだけで数分で新しい環境を立ち上げられますか？それとも、チケットを提出し、承認を待ち、誰かが手動でサーバーをプロビジョニングするのを待つ必要がありますか？
チームがプロジェクトごとにインフラストラクチャをゼロから構築しなければならない場合、同じパターンを何度も再発明することに時間を浪費します。優れた内部プラットフォームは、コンピュート、ストレージ、ネットワーキング、モニタリングといったすぐに使えるサービスを提供します。開発者はアプリケーションに集中でき、10回目のロードバランサー設定に時間を費やす必要はありません。
指標はシンプルです：新しい環境を入手するのにどれくらい時間がかかりますか？答えが週単位で測られるなら、プラットフォームがボトルネックです。
ガバナンス：スピードを落とさずに制御する
ガバナンスとはリスク管理です。すべての組織は、変更が安全で、コンプライアンスに準拠し、レビューされていることを保証する必要があります。しかし、ガバナンスの実装方法によって結果は大きく異なります。すべての変更に長い手動承認プロセスが必要ですか？それとも、問題が本番環境に到達する前に自動的に検出するポリシーがありますか？
最良のガバナンスは、物事が順調に進んでいる間は目に見えません。危険な変更は自動的にブロックし、安全な変更は摩擦なく通過させます。チームがコードを書くよりもフォームへの記入に多くの時間を費やしているなら、ガバナンスが逆効果になっています。
有用な指標：リスクの低い変更の場合、チームは不要な承認を回避できますか？それとも、コンテキストに関係なく、すべての変更が同じレベルの精査を受けますか？
データベース：しばしば忘れられるボトルネック
多くの組織では、アプリケーションコードのパイプラインはスムーズでも、データベースの変更は依然として手動介入を必要とします。開発者がマイグレーションスクリプトを作成し、DBAに送信して待ちます。DBAがレビューし、メンテナンスウィンドウをスケジュールし、アプリケーションのデプロイとは別に実行します。
これにより調整の問題が発生します。アプリケーションとデータベースの同期が取れなくなります。チームは2つの別々のデプロイを計画する必要があり、データベースの変更がしばしば全体を遅らせるボトルネックになります。
ここでの指標は、データベーススキーマの変更をアプリケーションコードの変更と一緒にデプロイできるかどうかです。別々のスケジューリングが必要な場合、デリバリー能力にギャップがあります。
インフラストラクチャ：サーバー、ネットワーク、そしてその下にあるすべて
インフラストラクチャは、アプリケーションを実行する物理的および仮想的なコンポーネント（サーバー、ロードバランサー、ファイアウォール、DNS、ネットワーキング）をカバーします。問題は、このインフラストラクチャがどのように管理されているかです。SSHと共有ドキュメントを通じて手動で設定されていますか？それとも、バージョン管理、レビュー、再現が可能なコードとして定義されていますか？
インフラストラクチャが手動で管理されている場合、それは脆弱になります。知識は一人の頭の中に保持されます。その人が去れば、知識も一緒に去ります。本番環境をゼロから再現することは、日常的なタスクではなくプロジェクトになります。
指標：スクリプトを実行するだけで、インフラストラクチャ全体を何もない状態から再現できますか？答えが「いいえ」の場合、構成ドリフトと文書化されていない依存関係が存在します。
アウトカム：実際に何が起こっているかを測定する
アウトカムの次元は他の次元とは異なります。プロセスやツールではなく、結果に注目します。組織は、デプロイの頻度、変更がユーザーに届くまでのリードタイム、デプロイが問題を引き起こす頻度、問題発生時の復旧速度を把握していますか？
データがなければ、チームは感覚に頼ることになります。「順調に進んでいる気がする」は指標ではありません。4つの主要なアウトカムは、デプロイ頻度、変更のリードタイム、変更失敗率、平均復旧時間です。これらの質問に数値で答えられなければ、手探りで進んでいることになります。
実用的な自己評価チェックリスト
以下のチェックリストを使用して、組織の現在地を素早く把握してください。各次元について、その記述が現在の現状を表しているかどうかを自問してみてください。
以下の図は、各次元がどのように相互に接続し影響を与え合い、デリバリーを加速または阻害するシステムを形成しているかを示しています。
- デリバリー: 開発者は他チームを待たずに自分の変更をデプロイできる。
- プラットフォーム: 新しい環境を数分で作成でき、数日や数週間はかからない。
- ガバナンス: 自動化されたポリシーがリスクの高い変更を検出し、手動承認は例外であり標準ではない。
- データベース: スキーマ変更はアプリケーションコードと一緒にデプロイされ、別途スケジュールされることはない。
- インフラストラクチャ: インフラストラクチャ全体をコードから単一のコマンドで再現できる。
- アウトカム: チームはデプロイ頻度、リードタイム、変更失敗率、復旧時間を追跡している。
これらのいずれかに「いいえ」と答えた場合、その次元は改善の候補です。
まとめ
これら6つの次元は、すべてを完璧にするためのスコアカードではありません。診断ツールです。ほとんどの組織には、得意な分野と苦手な分野があります。デリバリーに優れたチームでも、データベースの変更が手動であるために苦戦するかもしれません。インフラストラクチャが成熟しているチームでも、ガバナンスに3層の承認が必要なために遅くなる可能性があります。
目標は、今現在あなたを妨げているボトルネックを見つけることです。最初にそれを修正します。次に次のボトルネックに移ります。時間の経過とともに、6つの次元はバランスを取り戻し、組織はより速く、より安全に、そしてより少ない摩擦でソフトウェアをリリースできるようになります。