Terraform共通モジュールを チーム横断で“変えられる”運⽤へ 中間 啓介 株式会社SmartHR 2026.7.11 / SRE NEXT 2026 Lunch Sponsor Session / #srenext_c リリースと適⽤の分離 

⾃⼰紹介 経歴 ● 2022/5 SmartHRにバックエンドエンジニアとして入社 ● 2024/1 SREチームに異動 過去登壇 ● SRE Kaigi 2026 / 小さく始めるBCP ― 多プロダクト環境で始める 最初の一歩 中間 啓介（なかま けいすけ） 株式会社SmartHR / SRE 

© SmartHR, Inc. 01 会 社 概 要 © SmartHR, Inc. バックオフィスから まるごとスマートに。 ⼈事‧労務‧情シス業務を効率化。 みんなが使うから組織が変わる。 06 | 57 

1 SmartHRがTerraformの共通モジュールを使う背景 2 共通モジュールの課題 3 バージョニングによる解決 4 まとめ アジェンダ 

本⽇お持ち帰りできること ● Terraformの共通モジュールを運⽤するときのツラミ ● Terraformの共通モジュールをチーム横断で運⽤するためのヒント 

01 SmartHRがTerraformの モジュールを使う背景 

SmartHRのインフラ運⽤ ● SmartHRはマルチプロダクト構成 ○ プロダクトチームは約40チーム ● プロダクトチーム ○ インフラに対してオーナーシップを持ち、⾃分達で変更が⾏える体制 ● SREチーム ○ プロダクトチームがインフラを構築‧変更しやすいように、インフラ構築 ⽀援やTerraformの共通モジュールを整備している 

Terraformのディレクトリ構成 ● モノレポ構成 ● ルートモジュール ○ gcp/product/env ○ プロダクト✕環境別に⽤意 ● 共通モジュール ○ gcp/modules ○ 再利⽤可能なリソースを置く gcp/ ├── kintai // 勤怠管理プロダクト │ ├── development │ ├── production │ └── staging ├── kyuyo // 給与計算プロダクト │ ├── development │ ├── production │ └── staging ├── modules │ ├── cloud-storage ︙ ディレクトリ構成サンプル ルートモジュール 共通モジュール 

● よく使う構成の部品化 ○ SmartHRには似た構成のプロダクトが多く、よく使う構成をモジュール 化することで、同じ実装の繰り返しを減らす ● 安全なインフラ構築のセルフサービス化 ○ セキュリティ要件や推奨設定をモジュールに組み込むことで、プロダク トチームが安全に素早くインフラを構築できるようにする 共通モジュールを使う背景 

02 共通モジュールの課題 

● 影響確認が⼤変 ○ 共通モジュールを変更する場合、参照元のルートモジュールに破壊 的変更が起きないようにする必要がある ● Driftを⽣む ○ 共通モジュールを変更できたとしても、参照元のルートモジュール でDriftが発⽣してapplyがしづらくなる 共通モジュールは変更しづらい 

プロダクトチームへの悪影響 ● 共通モジュールを使わず、各チーム独⾃で実装するようになる ○ →実装‧レビュー⼯数が増える ○ →プロダクトチームのアジリティが下がる ● 共通モジュールの変更を諦めて、そのままにする ○ →インフラの最新の機能が使えなくなる ○ →インフラを最適な状態にできなくなる 

03 バージョニングによる解決 

● 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 

● モジュールの参照をGitタグ参照にして、共通モジュールのリリースと 適⽤を分離する バージョニング 

● 分離：共通モジュールのGitタグ参照化 ● リリース：共通モジュールの変更 ● 適⽤：共通モジュールの参照バージョン変更 バージョニングの流れ 

● 初期バージョンのタグを作成（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 

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 ここにタグを 指定する 

● 共通モジュールを変更する ● 次のバージョンのタグを作成する（tfactionのwolkflowを活⽤） ○ module_gcp_modules_cloud-storage_v0.0.1 リリース：共通モジュールの変更 

● プロダクトチームが好きなタイミングでモジュールの参照タグをv0.0.1に 変更する 適⽤：共通モジュールの参照バージョン変更 

RenovatePRの⾃動検知 v0.0.0 -> v0.0.1のア プデートを⾃動で検 知してPR作成 

共通モジュール 安全に変更できるようになった☺ 

が、新たな課題が... 

共通モジュールの変更から適⽤までのリードタイムが⻑い ● プロダクトチームのインフラに適⽤するまで半⽇〜1⽇かかる 半⽇〜1⽇ 

SREチームしか変更できない共通モジュール ● 煩雑な⼿作業が多く、SREチームに属⼈化が起きる SRE頼みになる 煩雑な⼿作業が多い 

● タグ作成等の単純作業はGitHub Actionsでやる ● リリースするまでの⼿順をAIのSkillsとして追加し、DevinやClaude Code に任せられるようにする ● RenovateのPRはplanにDriftがなければオートマージ AI/GitHub Actions/Renovateによる⾃動化 

リードタイム削減 ● 作業の⾃動化によって、半⽇〜1⽇かかる作業が30分に削減できた 30分 

煩雑な⼿作業は⾃動化 チーム横断で“変えられる”共通モジュール ● プロダクトチームが共通モジュールを変更できる状態になる プロダクトチームが変更できる状態 

04 まとめ 

● バージョニングを使えば、リリースと適⽤を分離でき、共通モジュールを 変更しやすくなる ● 煩雑な作業を⾃動化すれば、誰でも共通モジュールを変更でき、チーム横 断で変えられる共通モジュールを運⽤できる まとめ 

Special Thanks!! 

https://open.talentio.com/r/1/c/smarthr/pages/98449 シニアSRE 募集中です！！ We are hiring!! © SmartHR, Inc. 49 | 57 ご静聴ありがとうございました！