CLOUD SECURITY LAB

🏗️ Terraformコード、誰が書くべきか？ — インフラチーム vs 開発チームの論争に終止符を

—

by

cslab
in

「うちのチームが書けばいいじゃないですか」

— この一言が組織の3ヶ月を無駄にする。

>

🎯 この記事で扱うこと

  • Terraformコードの所有権論争が起こる本当の理由
  • インフラチームが担当する場合の利点と限界
  • 開発チーム（DevOpsを含む）が担当する場合の利点と限界
  • 実際の現場で通用する3つのモデル
  • 組織規模別の最適構造提案

📌 導入 / 背景

クラウド導入が加速するにつれて、Terraformはいつの間にか「インフラチームの専有物」から「誰もが触れるべき共有リソース」へと変化しました。

問題はここから始まります。

「ECSクラスターを一つ作ってほしいとチケットを上げたら2週間かかりました。」

「開発チームが直接書いたTerraformコードが本番VPCを消してしまいました。」

どちらの話も実際に起こることです。前者はインフラチームがボトルネックになったケースで、後者は所有権なく誰もが触った結果起こった惨事です。

Terraformコードの所有権問題は、単に「誰がコードを書くか」の問題ではありません。組織構造、責任の所在、変更速度の3つが絡み合った複雑な問題です。

🔍 まずTerraformが扱う領域を区分しよう

Terraformコードは大きく2つのレイヤーに分けられます。

レイヤー1 — プラットフォームインフラ (Foundation Layer)

  • VPC、サブネット、ルーティング、TGW
  • IAMポリシー、セキュリティグループの基本テンプレート
  • EKS/ECSクラスター自体
  • S3バケットポリシー、KMSキー
  • DNS (Route 53ホストゾーン)

この領域は変更頻度が低く、誤って触ると全社的な障害につながります。慎重さが必要です。

レイヤー2 — アプリケーションインフラ (App Layer)

  • ECSサービス、タスク定義
  • Lambda関数、API Gateway
  • RDSインスタンス（アプリ専用）
  • CloudFront配信設定
  • 環境別変数、サービス別S3バケット

この領域は変更頻度が高く、デプロイサイクルに直結します。速度が重要です。

この2つのレイヤーを同じチームが同じ方法で管理しようとすると衝突が発生します。

⚙️ モデル1 — インフラチーム集中所有 (Centralized)

インフラチーム（またはSREチーム）がすべてのTerraformコードを所有し、管理する方式です。

利点

  • 標準化が容易：命名規則、タグ付けポリシー、モジュール構造が一貫します
  • セキュリティ統制：誰が何を作成するかは必ずレビューを経ます
  • 専門性の集中：Terraform Providerのバージョン管理、stateファイル管理など、熟練度が向上します

欠点

  • ボトルネック発生：開発チームからのリクエストが溜まるとチケットキューが爆発します
  • コンテキストの欠如：インフラチームがアプリの要件を完全に理解しないままコードを作成します
  • デプロイ速度の低下：機敏なCI/CDパイプラインと衝突します

適した組織

  • 金融、公共、医療などセキュリティ・コンプライアンス要件が強い場所
  • インフラ変更が稀なオンプレミス + クラウドハイブリッド環境
  • クラウド移行初期段階（まだ標準化が確立されていない時期）

⚙️ モデル2 — 開発チーム自律所有 (Decentralized / “You Build It, You Run It”)

各開発チーム（サービスチーム）が自身のサービスに必要なインフラを直接Terraformで定義する方式です。Netflix、Spotifyのような大手テック企業が採用しているモデルです。

利点

  • デプロイ速度：PRを上げればすぐに反映可能。インフラチームの待機なし
  • コンテキストの一致：アプリを最もよく知るチームがインフラも決定
  • 責任の明確化：「私が作ったインフラは私が責任を持つ」

欠点

  • 断片化のリスク：チームごとに異なる方法でリソースを作成し、一貫性が損なわれます
  • セキュリティ事故のリスク：Terraformの知識が不足している開発者がパブリックS3バケットを作成する可能性があります
  • stateファイルの衝突：複数のチームが重複するリソースを触る際に状態ファイルが壊れます

適した組織

  • DevOps成熟度が高いスタートアップやテック企業
  • MSA（マイクロサービス）でチーム単位が明確に分離された組織
  • 開発者がクラウドに慣れている環境（AWS資格レベル以上）

⚙️ モデル3 — プラットフォームチーム + Golden Pathモデル (Platform Engineering)

現在最も注目されているモデルです。インフラチームは「プラットフォーム」を作り、開発チームは「サービス」をデプロイするという概念です。

核心アイデア：インフラチームが検証済みのTerraformモジュールを作成して提供し、開発チームはそのモジュールを利用する。

# インフラチームが作成した検証済みモジュール（例）
module "my_ecs_service" {
  source  = "git::https://github.com/company/terraform-modules//ecs-service?ref=v2.1.0"

  # 開発チームが入力する値
  service_name   = "payment-api"
  container_port = 8080
  desired_count  = 2
  cpu            = 512
  memory         = 1024

  # セキュリティ関連はモジュール内部で強制適用される
  environment = "prod"
  vpc_id      = var.vpc_id
}

開発チームはソースモジュールを変更できず、許可された変数のみを入力します。セキュリティグループのルール、IAMポリシー、タグ付け標準はモジュール内部にすでに組み込まれています。

利点

  • 速度と標準化を同時に達成
  • 開発チームはTerraformの専門家である必要がない
  • インフラチームはモジュールの品質にのみ集中

欠点

  • モジュール設計の初期費用が大きい
  • モジュールが制限的すぎると開発チームの不満が発生
  • モジュールバージョン管理が必要（?ref=v2.1.0形式でのタグ付けが必須）

適した組織

  • 中堅〜大企業、チーム数が5つ以上の規模
  • Platform EngineeringまたはDevEx（Developer Experience）チームを別途運営している場所
  • 内部開発者ポータル（IDP, Internal Developer Portal）を構築しようとしている組織

💡 現実でよく見られる誤ったパターン

❌ パターン1 — 「みんなで一緒に使おう」

別途の所有権区分なく、誰もがmainブランチにPRを投げます。レビュー基準もなく、stateロックの衝突が定期的に発生します。小規模チームで始まり、よく定着してしまうパターンです。

❌ パターン2 — インフラチームがすべて作成するがレビューがない

中央集権化はされているものの、コード品質管理がありません。数年経ったTerraformコードに誰も手を出せない「レガシーIaC」になります。

❌ パターン3 — 開発チームが作成するがインフラチームに共有しない

「私たちのサービスインフラは私たちが知っている」と独立して運用し、セキュリティ監査で大量の未承認リソースが発覚します。

✅ まとめ / 終わりに

「Terraformは誰が書くべきか」の正解は、組織の規模と成熟度によって異なります。
組織状況 推奨モデル
クラウド移行初期、5人以下のチーム インフラチーム集中所有
DevOps成熟、MSA、小規模スタートアップ 開発チーム自律所有
チーム5つ以上、標準化が必要 プラットフォームチーム + Golden Pathモジュール
金融/公共などコンプライアンスが強い環境 インフラチーム所有 + 必須レビューゲート

最も重要な原則はこれです。

プラットフォームインフラ（VPC、IAM、クラスター）はインフラチームが、アプリレイヤー（サービス、関数）は開発チームが

— ただし、モジュールと標準はインフラチームが提供する。

所有権が明確であれば、障害発生時に誰が対応するかも明確になります。コードの所有権は、運用責任そのものです。

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です