デプロイプロセスがチーム構造をそのまま映し出す理由
こんなシナリオを見たことがあるだろう。開発チームが機能を完成させる。QAに引き継ぐ。QAがテストを実行し、問題を見つけて差し戻す。何度かやり取りした後、QAが承認する。次にコードはインフラチームに渡され、サーバにデプロイされる。変更にデータベーススキーマの更新が含まれる場合、DBAチームが途中で関与する必要がある。各チームには独自のスケジュール、優先順位、作業方法がある。たった一つのシンプルなデプロイに数日かかる。複数の引き継ぎが摩擦を生む。どこかでコミュニケーションが途切れ、何かがうまくいかなくなる。
このパターンは偶然ではない。不運やツールの問題でもない。これはチームがどのように組織されているかを直接反映している。
どこにでも見られるパターン
別々のグループに分割されたチームを見ると、デプロイプロセスはその分割を反映する傾向がある。アプリケーションチームはコードを書くが、デプロイはできない。データベースチームはスキーマを管理するが、プロセスの後半まで関与しない。インフラチームはサーバをプロビジョニングするが、アプリケーションの動作を理解していない。QAチームはすべてをテストするが、システムの構築方法について発言権がない。
各グループが独自のゲートを追加する。各ゲートが待ち時間を追加する。結果として、デプロイプロセスは、あまりにも多くの走者がいて明確なゴールラインがないリレーレースのように感じられる。誰もが自分の担当部分に責任を持つが、全体がエンドツーエンドで機能することに責任を持つ者はいない。
次のフローチャートは、各チームがゲートを追加し、デプロイを遅いリレーレースに変える様子を示している。
これこそConwayの法則が働いている姿だ。この法則は、組織はそのコミュニケーション構造を反映したシステムを設計する、と述べている。チームがサイロ化していれば、システムもサイロ化する。デプロイに5つの異なるグループ間の調整が必要なら、それはプロセスの問題ではない。パイプラインに現れた組織の問題だ。
オーナーシップが明確になると何が変わるか
次に、別の種類のチームを見てみよう。1つのチームがサービスをエンドツーエンドで所有している。彼らはコードを書き、データベーススキーマを管理し、それを実行するインフラを扱い、自分たちで本番環境にデプロイする。変更をリリースする必要があるとき、別のチームの承認やデプロイの実行を待つ必要はない。彼らは関わるすべてのレイヤーを理解している。なぜなら、彼らがそれを構築し、運用しているからだ。
デプロイプロセスは単純になる。チームは変更を書き、テストを実行し、デプロイする。何かが壊れた場合、誰が修正すべきかを正確に把握している。コードを書いたのと同じ人が、午前2時にページャーで呼び出される。その一致が、品質、テスト、リスクに対する考え方を変える。
明確なオーナーシップは、すべてのチームがすべてをゼロから構築しなければならないことを意味しない。プラットフォームエンジニアリングチームが提供するプラットフォームやサービスを利用することもできる。重要なのは、チームが自身のサービスのデプロイを完全に制御できることだ。新しいバージョンをプッシュするために別のチームの許可を必要としない。共有カレンダーの共有デプロイスロットを待つこともない。
チーム構造がリスク管理に与える影響
チーム構造は、リスクの扱い方も形作る。断片化されたチームでは、システム全体の全体像を把握しているグループは一つもない。各チームは、自分のドメイン外で何が起こっているかを完全には信頼できないため、独自のチェックを追加する。アプリケーションチームは手動承認ステップを追加する。データベースチームは別の承認を追加する。インフラチームはさらに別の承認を追加する。結果として、デプロイプロセスは遅く、官僚的で、摩擦に満ちたものになる。
明確なオーナーシップを持つチームは、リスクベースのガバナンスをより効果的に適用できる。システム全体を理解しているため、変更の影響を理解している。重要でないエンドポイントへの小さな変更は、全ユーザに影響するデータベースマイグレーションと同じレベルの精査を必要としない。チームはその判断を下すことができる。なぜなら、彼らにはコンテキストがあるからだ。
自分のチームをチェックする実用的な方法
デプロイプロセスが遅くて苦痛だと感じるなら、まずチーム構造を見てみよう。いくつか質問をしてみてほしい。
- 現在、別のチームに許可を求めずに本番環境にデプロイできるのは誰か？
- 本番環境で何かが壊れたとき、コードを書いたチームが、それを実行するインフラとデータベースも所有しているか？
- コードがマージされてから本番環境で実行されるまでに、何回の引き継ぎが発生するか？
- それぞれの引き継ぎが、待ち時間、手戻り、または誤ったコミュニケーションを追加しているか？
答えが複数の引き継ぎと不明確なオーナーシップを指し示すなら、修正方法はより良いCI/CDツールではない。修正方法は、チームの構造を再編成することだ。
これがプラットフォームにとって意味すること
CI/CDプラットフォームを構築するとき、あなたは単にデプロイ手順を自動化しているわけではない。組織の働き方をコード化しているのだ。チームがサイロ化していれば、プラットフォームはそれを複雑な承認チェーン、誰も完全に所有していない複数の環境、そしてめったに会話しないグループ間の調整を必要とするデプロイプロセスとして反映する。
よりシンプルなデプロイを望むなら、よりシンプルなチーム構造から始めよう。チームに、彼らが構築するサービスの明確なオーナーシップを与えよう。それらのサービスを支えるインフラとデータベースを所有させよう。他のチームを待たずにデプロイする権限を与えよう。
プラットフォームはそのオーナーシップを支援すべきであり、置き換えるべきではない。優れたプラットフォームは、一貫性と安全性を維持しながら、チームが独立してデプロイするためのツールを提供する。組織のサイロをソフトウェアの形で再現するゲートを追加してはならない。
まとめ
デプロイプロセスは単なる技術的なパイプラインではない。それは組織を映し出す鏡だ。その鏡に複雑さ、遅延、摩擦が映っているなら、新しいツールやより良いスクリプトに答えを求めてはいけない。チームがどのように構造化されているかを見よう。シンプルで高速なデプロイは、システムをエンドツーエンドで所有するチームから生まれる。それ以外はすべて、単なる回避策に過ぎない。