20チームが混沌なくリリースし続ける方法

あなたはSaaS企業で働いています。プロダクトチームは5つ、10、あるいは20かもしれません。あるチームは決済APIを担当し、別のチームは通知を処理し、さらに別のチームはユーザーダッシュボードを管理しています。各チームには独自のスタック、独自のリリースリズム、そして独自のやり方があります。

ここでの問題は「1つのチームがどうやって高速にリリースするか」ではありません。問題は「20のチームが互いに干渉せず、運用を混乱させずに高速にリリースするにはどうするか」です。もしすべてのチームが独自のデプロイ方法、独自のツール、独自のパイプライン構造を選んだとしたら、イノベーションは生まれません。断片化が起こります。運用チームは20種類の異なるデプロイワークフローを覚えなければならず、セキュリティチームは一貫性をチェックできません。インシデントが発生したとき、誰が何をどのように変更したのか、誰もすぐに把握できません。

ここで役立つのが、サービスカタログとゴールデンパスという2つの概念です。

サービスカタログの実際の役割

サービスカタログとは、組織内で動作しているすべてのサービスの中央レジストリです。単なる名前のリストではありません。どの環境で動作しているか、誰が所有しているか、どのようにデプロイされるか、コードはどこにあるか、依存関係は何かといった有用な情報を保持します。

以下の図は、サービスカタログがチーム、そのサービス、そしてゴールデンパスをどのように結びつけるかを示しています。

flowchart TD SC[サービスカタログ] T1[チームA] T2[チームB] T3[チームC] S1[決済API] S2[通知] S3[ユーザーダッシュボード] GP[ゴールデンパス] T1 -- 所有 --> S1 T2 -- 所有 --> S2 T3 -- 所有 --> S3 S1 -- 登録 --> SC S2 -- 登録 --> SC S3 -- 登録 --> SC GP -- デプロイ方法を定義 --> S1 GP -- デプロイ方法を定義 --> S2 GP -- デプロイ方法を定義 --> S3 SC -- ライフサイクルを追跡 --> S1 SC -- ライフサイクルを追跡 --> S2 SC -- ライフサイクルを追跡 --> S3

チームが新しいサービスを作成すると、それをカタログに登録します。サービスが使われなくなると、カタログがそのライフサイクルを追跡します。カタログは「今、本番で実際に何が動いているのか」という問いに答えるための唯一の情報源となります。

これがないと、誰も更新しないスプレッドシート、6ヶ月前の情報が古くなったWikiページ、「請求サービスを誰が担当しているか知ってる？」というSlackメッセージで終わります。カタログはその推測作業を排除します。理論上の概念ではなく、実用的なツールです。

「自分で選ぶ」よりもゴールデンパスが優れている理由

ゴールデンパスは「好きなものを選んでいい」の反対です。各チームにビルド、テスト、デプロイの方法を自由に決めさせる代わりに、組織は十分にテストされ、文書化され、完全にサポートされた1つのパスを提供します。チームは異なるパスを選ぶこともできますが、その場合、サポート、セキュリティ、メンテナンスは自分たちで負うことになります。

ゴールデンパスは強制ではありません。ゼロから構築するよりも簡単で安全な「提案」です。

具体的な例を挙げましょう。あなたの会社が、ビルド、ユニットテスト、セキュリティスキャン、統合テスト、ステージングへのデプロイを含むパイプラインテンプレートを提供しているとします。そのテンプレートはすでにサービスカタログと統合されています。チームがテンプレートを使うと、サービスが自動的に登録されます。チームはサービス名、ポート、依存関係、所有チームといったいくつかのパラメータを入力するだけで済みます。残りはすべて自動で処理されます。

もしチームが独自のパイプラインを使いたい場合は、自由にそうできます。ただし、パイプラインを自分たちで管理し、独自のセキュリティスキャンを設定し、カタログに手動で登録する必要があります。ほとんどのチームは、ゴールデンパスの方が速くて面倒な作業が減るため、そちらを選ぶでしょう。

一貫性と自律性のバランス

このアプローチの興味深い点は、生み出されるバランスです。チームはすべてを同じ方法で行うことを強制されません。高い柔軟性が必要なチームは独自の道を行くことができます。しかし、ゴールデンパスの方が簡単で速いため、ほとんどのチームはそれを選びます。結果として、チームの創造性を犠牲にすることなく一貫性が生まれます。

このバランスは、あなたが思う以上に重要です。すべてのチームにまったく同じプロセスを強制すると、異なるものを必要とするチームを苛立たせます。すべてのチームに好き放題させると、運用上の混乱を引き起こします。ゴールデンパスのアプローチは、チームに強力なデフォルトを提供しますが、檻ではありません。

運用とセキュリティへのメリット

サービスカタログとゴールデンパスは、開発者向けのツールだけではありません。運用チームとセキュリティチームが安心して夜を過ごせるようにもします。

20種類の異なるデプロイ方法を監査する代わりに、運用チームはゴールデンパスが安全であることを確認するだけで済みます。その後、どのサービスがゴールデンパスを使い、どのサービスが使っていないかを監視します。ゴールデンパス外のサービスは追加の精査を受けるか、移行が促されます。

インシデントが発生したとき、運用チームはサービスカタログを見て、所有チーム、デプロイ方法、依存関係を特定できます。基本情報を把握するためにSlackで人を追いかける必要はありません。

セキュリティチームも同様の恩恵を受けます。2年前に誰かが急いで作った特注パイプラインをすべて監査しようとする代わりに、ゴールデンパスのセキュリティ確保にエネルギーを集中できます。

開発者が実際に経験すること

開発者の視点から見ると、ゴールデンパスは意思決定の疲れを軽減します。新しいサービスを作成する必要があるとき、開発者は「CI/CDを適切に設定するにはどうすればいいか」を考える必要がありません。テンプレートに従い、いくつかのパラメータを入力するだけです。それで完了です。

これにより、アイデアから本番リリースまでの時間が短縮されます。開発者はパイプラインの配管作業ではなく、ビジネスロジックに集中できます。多くのチームを持つ企業では、これが大きな時間節約になります。

始めるための実践的チェックリスト

組織にサービスカタログとゴールデンパスを導入したい場合、最初のステップを導く短いチェックリストを以下に示します。

  • 小さく始める。 1つのチームと1つのサービス種別を選びます。その特定のケース向けにゴールデンパスを構築します。初日からすべてのシナリオをカバーしようとしないでください。
  • カタログとゴールデンパスを統合する。 チームがゴールデンパスを使うと、サービスが自動的に登録されるようにします。手動登録は、人々がスキップしてしまう障壁です。
  • ゴールデンパスを明白な選択肢にする。 独自に構築するよりも、速く、安全で、文書化が充実している必要があります。そうでなければ、チームは無視します。
  • 例外を許可するが、可視化する。 チームは異なるパスを選べますが、その選択はカタログに記録されるべきです。運用チームとセキュリティチームは、それらの例外にどれだけの精査が必要かを判断できます。
  • フィードバックに基づいて反復する。 ゴールデンパスは固定されたものではありません。チームがより良い方法を見つけたら更新します。生きた状態を保ちます。

具体的な結論

サービスカタログとゴールデンパスは、管理統制のためではありません。開発者の摩擦を取り除き、運用とセキュリティを健全に保つためのものです。20のチームが混沌なくリリースできるようになれば、組織全体のスピードが上がります。1つのゴールデンパスから始め、シンプルなカタログと統合し、結果が物語るのを見守りましょう。