6つの組織から学んだCI/CDの真実
私が携わってきたどのエンジニアリングチームも、同じ出発点に立っていた。変更をユーザーが使える状態に届ける必要があったのだ。しかし、そのデリバリープロセスの作り方は、組織によってまったく異なっていた。
3人のスタートアップと、規制監督下にあるフィンテック企業では、同じパイプラインは必要ない。アプリストアにリリースするモバイルチームが直面する制約は、レガシーシステムを管理するデータベースチームが考えたこともないものだ。しかし、これらの事例を詳しく見ていくと、同じ3つのパターンが浮かび上がってくる。
パターン1: すべてのチームは同じニーズから始まる
組織の規模や業界を問わず、すべてのチームには3つのものが必要だ。
- 変更をユーザーがアクセスできる場所に送る仕組み
- その変更が何かを壊さないという確信
- 問題が起きたときに修正する手段
小さなスタートアップはシンプルなパイプラインと基本的なモニタリングでこれらのニーズを満たす。規制業界の企業は承認ステップと監査証跡を追加する。複数チームを持つSaaS企業はサービスカタログとゴールデンパスを構築する。モバイルファーストのチームは段階的ロールアウトとリモートコンフィグを実装する。レガシーデータベースを扱うチームは安全なマイグレーション戦略を策定する。インフラ中心のチームはInfrastructure as Codeのガバナンスとドリフト検知を追加する。
これらは異なるアプローチではない。同じ問いに対する同じ答えであり、複雑さのレベルが異なるだけだ。
パターン2: リスクが求める安全性のレベルを決める
ミスの影響が大きければ大きいほど、より多くのセーフガードを追加する。
小さなスタートアップはユーザーが少ないため、数分のダウンタイムを許容できる。フィンテック企業は1件のトランザクションエラーも許容できない。リスクが顧客と規制当局に直接影響するからだ。複数チームのSaaS企業は、あるチームが別のチームのサービスを壊すことを許せない。モバイルファーストのチームは、何千ものデバイスでクラッシュするアップデートをプッシュできない。レガシーデータベースを管理するチームは、復旧に数日かかるデータ損失を起こせない。インフラ中心のチームは、設定ドリフトがシステム全体に影響を及ぼすため、それを許容できない。
あなたのリスクプロファイルが、プロセスに必要な厳格さを決定する。実際のリスク以上に安全性を高める必要はない。しかし、リスクが求める安全性を下回ってもいけない。
パターン3: 自動化が目的ではない
自動化は反復的な手作業を減らすためのツールだ。自動化のために自動化する人はいない。
スタートアップがデプロイを自動化するのは、毎回サーバーにログインするのに疲れたからだ。規制業界の企業が監査証跡を自動化するのは、すべての判断を手動で記録することが不可能だからだ。SaaS企業がゴールデンパスを自動化するのは、新しいチームを毎回ゼロからトレーニングできないからだ。モバイルファーストのチームが段階的ロールアウトを自動化するのは、何千ものデバイスを1台ずつ制御するのが現実的でないからだ。レガシーデータベースチームがマイグレーションを自動化するのは、手動での変更がリスクが高すぎるからだ。インフラチームがドリフト検知を自動化するのは、大規模なインフラを手動でチェックするのが非現実的だからだ。
自動化は特定の課題を解決する。その課題がまだないのであれば、まだ自動化すべきではない。
各組織のスタート地点
違いは最終的に何を構築するかではない。どこから始め、何を優先するかにある。
スタートアップは可能な限りシンプルなパイプラインから始める。何かが痛みを生み出し始めたときにのみ、セーフガードを追加する。
規制業界の企業はコンプライアンスから始める。その後、コンプライアンスを失わずにプロセスを高速化する方法を模索する。
複数チームのSaaS企業は、チーム間の一貫性から始める。その後、合意された境界内で柔軟性を追加する。
モバイルファーストのチームは、配信コントロールから始める。その後、リリースの影響を監視するための可観測性を構築する。
レガシーデータベースチームは、安全なマイグレーションパターンから始める。その後、その周辺のアプリケーションデプロイプロセスを修正する。
インフラ中心のチームはガバナンスから始める。その後、インフラ変更がその上で動作するアプリケーションを妨げないようにする。
自チームへの適用方法
すべての組織に当てはまる単一のパターンは存在しない。しかし、自分たちのスタート地点を見つけるためのフレームワークはある。
まず、今最も痛みを感じている部分を特定する。デプロイはまだ手動か？エラーは本番に到達して初めて発見されるか？データベースの変更に不安を感じるか？インフラが望ましい設定から常にドリフトしているか？
次に、自分の状況に最も近いケーススタディを見つける。チームが小規模ならスタートアップのパターンから始める。規制監督下にあるなら規制業界のパターンから。複数チームがあるならSaaSマルチチームのパターンから。
第三に、安全性のレイヤーを一度に1つずつ構築する。シンプルなパイプラインから始める。基本的なモニタリングを追加する。高リスクの変更にのみ承認ステップを追加する。実際に必要性が現れたときにのみ、次のレイヤーを追加する。
実践的なクイックチェックリスト
次のパイプラインを設計したり、別のツールを追加したりする前に、これらの質問を自問してほしい。
- この変更が失敗した場合の実際のリスクは何か？
- 今、最も摩擦を生んでいる手動ステップは何か？
- 自動化を追加する前に、よりシンプルなアプローチでこれを解決できないか？
- このセーフガードは実際のリスクレベルに見合っているか、それとも過剰設計になっていないか？
具体的な教訓
デリバリープロセスは、チーム、プロダクト、リスクの成長に合わせて変化する。他人のパイプラインをコピーしてはいけない。今実際に必要なものを理解し、そのニーズを満たす最もシンプルなものを作り、痛みが正当化する場合にのみ複雑さを追加する。今日うまくいくパターンは、来年必要になるパターンとは異なる。それは正常なことだ。優れたエンジニアリング組織はそうやって進化していく。