Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離

1. Terraform共通モジュールを チーム横断で“変えられる”運⽤へ 中間 啓介 株式会社SmartHR 2026.7.11 / SRE NEXT 2026 Lunch Sponsor Session / #srenext_c リリースと適⽤の分離
2. ⾃⼰紹介 経歴 • 2022/5 SmartHRにバックエンドエンジニアとして入社 • 2024/1 SREチームに異動 過去登壇 • SRE Kaigi 2026 / 小さく始めるBCP ― 多プロダクト環境で始める 最初の一歩 中間 啓介（なかま けいすけ） 株式会社SmartHR / SRE
3. © SmartHR, Inc. 01 会 社 概 要 © SmartHR, Inc. バックオフィスから まるごとスマートに。 ⼈事‧労務‧情シス業務を効率化。 みんなが使うから組織が変わる。 06 | 57
4. 1 SmartHRがTerraformの共通モジュールを使う背景 2 共通モジュールの課題 3 バージョニングによる解決 4 まとめ アジェンダ
5. 本⽇お持ち帰りできること • Terraformの共通モジュールを運⽤するときのツラミ • Terraformの共通モジュールをチーム横断で運⽤するためのヒント
6. 01 SmartHRがTerraformの モジュールを使う背景
7. SmartHRのインフラ運⽤ • SmartHRはマルチプロダクト構成 ◦ プロダクトチームは約40チーム • プロダクトチーム ◦ インフラに対してオーナーシップを持ち、⾃分達で変更が⾏える体制 • SREチーム ◦ プロダクトチームがインフラを構築‧変更しやすいように、インフラ構築 ⽀援やTerraformの共通モジュールを整備している
8. Terraformのディレクトリ構成 • モノレポ構成 • ルートモジュール ◦ gcp/product/env ◦ プロダクト✕環境別に⽤意 • 共通モジュール ◦ gcp/modules ◦ 再利⽤可能なリソースを置く gcp/ ├── kintai // 勤怠管理プロダクト │ ├── development │ ├── production │ └── staging ├── kyuyo // 給与計算プロダクト │ ├── development │ ├── production │ └── staging ├── modules │ ├── cloud-storage ︙ ディレクトリ構成サンプル ルートモジュール 共通モジュール
9. • よく使う構成の部品化 ◦ SmartHRには似た構成のプロダクトが多く、よく使う構成をモジュール 化することで、同じ実装の繰り返しを減らす • 安全なインフラ構築のセルフサービス化 ◦ セキュリティ要件や推奨設定をモジュールに組み込むことで、プロダク トチームが安全に素早くインフラを構築できるようにする 共通モジュールを使う背景
10. 02 共通モジュールの課題
11. • 影響確認が⼤変 ◦ 共通モジュールを変更する場合、参照元のルートモジュールに破壊 的変更が起きないようにする必要がある • Driftを⽣む ◦ 共通モジュールを変更できたとしても、参照元のルートモジュール でDriftが発⽣してapplyがしづらくなる 共通モジュールは変更しづらい
12. プロダクトチームへの悪影響 • 共通モジュールを使わず、各チーム独⾃で実装するようになる ◦ →実装‧レビュー⼯数が増える ◦ →プロダクトチームのアジリティが下がる • 共通モジュールの変更を諦めて、そのままにする ◦ →インフラの最新の機能が使えなくなる ◦ →インフラを最適な状態にできなくなる
13. 03 バージョニングによる解決
14. • tfactionはモノレポ構成でTerraformを管理するための便利なGitHub Actionsが揃っている ◦ https://github.com/suzuki-shunsuke/tfaction • PRにplanの結果を⾒やすい形式でコメント • PRのマージでapply実⾏ • モジュールをバージョニングをするための便利なWorkflowを利⽤ ◦ https://suzuki-shunsuke.github.io/tfaction/docs/v1/feature/mo dule 前提：Terraformの実⾏環境はtfaction
15. • モジュールの参照をGitタグ参照にして、共通モジュールのリリースと 適⽤を分離する バージョニング
16. • 分離：共通モジュールのGitタグ参照化 • リリース：共通モジュールの変更 • 適⽤：共通モジュールの参照バージョン変更 バージョニングの流れ
17. • 初期バージョンのタグを作成（tfactionのwolkflowを活⽤） ◦ module_gcp_modules_cloud-storage_v0.0.0 • モジュールの参照を作成したタグ(v0.0.0)にする 分離：共通モジュールのGitタグ参照化 参考：tfaction - Manage Terraform Modules https://suzuki-shunsuke.github.io/tfaction/docs/v1/feature/module
18. Gitタグ参照のサンプルコード（v0.0.0） # gcp/kintai/development/cloud-storage.tf module "cloud_storage" { # source = "../../modules/cloud-storage" source = "github.com/org/repo//gcp/modules/cloud-storage?ref=module_gcp_modules_cloud-storage_v0.0.0" bucket_name = "kintai-development" location = "asia1" } 参考：Terraform - Use modules in your configuration https://developer.hashicorp.com/terraform/language/modules/configuration ここにタグを 指定する
19. • 共通モジュールを変更する • 次のバージョンのタグを作成する（tfactionのwolkflowを活⽤） ◦ module_gcp_modules_cloud-storage_v0.0.1 リリース：共通モジュールの変更
20. • プロダクトチームが好きなタイミングでモジュールの参照タグをv0.0.1に 変更する 適⽤：共通モジュールの参照バージョン変更
21. RenovatePRの⾃動検知 v0.0.0 -> v0.0.1のア プデートを⾃動で検 知してPR作成
22. 共通モジュール 安全に変更できるようになった☺
23. が、新たな課題が...
24. 共通モジュールの変更から適⽤までのリードタイムが⻑い • プロダクトチームのインフラに適⽤するまで半⽇〜1⽇かかる 半⽇〜1⽇
25. SREチームしか変更できない共通モジュール • 煩雑な⼿作業が多く、SREチームに属⼈化が起きる SRE頼みになる 煩雑な⼿作業が多い
26. • タグ作成等の単純作業はGitHub Actionsでやる • リリースするまでの⼿順をAIのSkillsとして追加し、DevinやClaude Code に任せられるようにする • RenovateのPRはplanにDriftがなければオートマージ AI/GitHub Actions/Renovateによる⾃動化
27. リードタイム削減 • 作業の⾃動化によって、半⽇〜1⽇かかる作業が30分に削減できた 30分
28. 煩雑な⼿作業は⾃動化 チーム横断で“変えられる”共通モジュール • プロダクトチームが共通モジュールを変更できる状態になる プロダクトチームが変更できる状態
29. 04 まとめ
30. • バージョニングを使えば、リリースと適⽤を分離でき、共通モジュールを 変更しやすくなる • 煩雑な作業を⾃動化すれば、誰でも共通モジュールを変更でき、チーム横 断で変えられる共通モジュールを運⽤できる まとめ
31. Special Thanks!!
32. https://open.talentio.com/r/1/c/smarthr/pages/98449 シニアSRE 募集中です！！ We are hiring!! © SmartHR, Inc. 49 | 57 ご静聴ありがとうございました！