小規模チームでも安定して運用できるTerraform構成 ─ PIVOTがIaC化で実現した安全性と拡張性
PIVOT株式会社 / tawachan
テックリード / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 10名以下
| ツールの利用規模 | 事業形態 |
|---|---|
| 10名以下 | B to C |
| ツールの利用規模 | 10名以下 |
|---|---|
| 事業形態 | B to C |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
PIVOTの開発チームは、正社員エンジニア3名、QA1名、PdM1名、業務委託メンバーが在籍する体制でした。
各エンジニアがiOS、Android、Web(フロントエンド・バックエンド)を分担し、私がWebとインフラを横断的に担当していました。
当時はGoogle Cloudコンソールでの手作業が中心で、変更履歴が残らず、設定の再現性も確保されていませんでした。
誰が・いつ・どのようにリソースを変更したかを把握できず、属人化が進行していました。
一方で、開発スピードを優先する段階では運用負荷が後回しになりがちで、徐々に技術的負債として表面化していました。
主な課題は次の通りです。
- IaCが未整備で、設定変更が属人的かつ不透明
- コンソール操作に依存しており、変更履歴を追跡できない
- 環境間で微妙な設定差が生じ、ステージングと本番の整合性が崩れる
- 操作ミスによる設定事故のリスクが常に存在する
どのような状態を目指していたか
チームとして目指したのは、属人性を排除し、インフラ構成を透明化・再現可能にすることでした。
Terraformを軸に、誰でも安全に変更を提案・適用できる仕組みを整えることをゴールに設定しました。
全リソースのコード化とGit管理の徹底
→ 変更履歴を可視化し、誰が・いつ・何を変更したかを追跡可能にする。小規模チームでも維持できる運用構成
→ 専任SREがいなくても、Terraformを中心に安全な変更管理を実現する。AI活用を前提にしたコード構成
→ AIツールが既存コードを容易に参照・理解できるよう、コンテキストを一箇所に集約する。GitOpsによる自動化とレビュー体制の確立
→ PR単位でplan/applyを行い、レビューを通じて安全に反映できる運用フローを整備する。
初期段階では、各リポジトリごとにTerraformを分散管理するPoCを試しましたが、命名規則や変数定義が統一できず、早期に管理負担の増大が見えました。
この経験を踏まえ、モノレポ化とリソース種別ベースの構成を採用する方針に転換。
結果として、チーム全体で見通しがよく、AI支援との相性も高い構成を実現することができました。
比較検討したサービス
特に他のツールは比較検討しませんでした。
導入の成果
改善したかった課題はどれくらい解決されたか
TerraformによるIaC化を進めた結果、導入前に抱えていた課題はほぼ解決されました。
Google Cloudコンソール上での手動操作は不要となり、インフラ構成がすべてコードで管理されるようになりました。
変更履歴がGit上で明確に追えるため、過去の設定変更の影響範囲を簡単に把握できるようになりました。
これまでGUI上でペア作業(いわば“インフラのペアプロ”)としてダブルチェックしていた設定変更も、コードレビューで完結できるようになりました。
結果として、リリース時の安全性が高まり、レビューを通じた確認プロセスがより合理的な形に置き換わりました。
属人化やヒューマンエラーのリスクは大幅に低下し、Terraformによる自動plan/applyフローの確立で、インフラ変更の透明性・再現性・安全性が確実に向上しました。
どのような成果が得られたか
リリースおよび設定変更の安全性が向上
→ 手動操作をなくし、PRレビューを通じて変更内容を可視化・承認できるようになった。GUI操作でのペア作業が不要に
→ コンソール上での共同確認が不要となり、コードレビューを通じて安全性を担保。
→ 作業コストを減らしつつ、人為的な見落としを防止できるようになった。インフラ操作のハードルが下がった
→ AI支援を活用し、Terraformに詳しくないメンバーでも自然言語で設定変更の提案が可能に。
→ 結果として、インフラ運用がチーム全体で共有可能な領域へと拡張された。GitOps運用と自動化の定着
→ plan/applyをGitHub Actions上で自動化し、変更内容の可視化と安全な反映を実現。長期的な拡張性の確保
→ 今後のGitHub組織管理やネットワーク構成のIaC化にも対応可能な基盤を構築。
これにより、インフラ運用が属人化から脱却し、チーム全体で安全かつ効率的に扱える状態へ移行しました。
「インフラを触るのが怖い」という心理的ハードルも下がり、運用面での健全性が格段に高まりました。
導入に向けた社内への説明
上長・チームへの説明
Terraform導入については、ツール自体への異論はなく、チーム内でもすぐに合意が得られました。 全員がある程度Terraformの経験を持っており、既存のコード片も残っていたため、採用そのものよりも「いつ取り組むか」が議論の焦点でした。
当時はアーキテクチャ刷新が一段落し、新機能開発が本格化する前のタイミングでした。 この段階でIaC基盤を整えることで、今後のインフラ追加や変更時の管理コストを抑えられると説明しました。 新しいリソースが増えてからIaC化に取り組むよりも、現時点で整備したほうが長期的に効率が良いと判断し、タイミング面での納得感を重視しました。
活用方法
よく使う機能
Terraformでは以下の機能を中心に活用しています。
terraform plan
→ 変更内容を事前に確認し、影響範囲を可視化。GitHub Actions上で自動実行されるようにしており、レビュー時に差分を明確に把握できます。terraform apply
→ mainブランチへのマージをトリガーに自動適用される仕組みを構築。人手によるapply操作を廃止し、リリース手順を標準化しました。moduleの再利用
→ Cloud RunやCloud Schedulerなどの共通リソースをモジュール化。新規サービス追加時は既存モジュールを呼び出すだけで構築可能です。
これらの運用を通じて、手動でのリリースや設定変更を廃止し、PRベースの安全なインフラ更新を実現しています。
ツールの良い点
コードによる一貫したインフラ管理が可能
→ 手動操作を排除し、環境差異やヒューマンエラーを防止できる。GitHub Actionsとの統合で自動化が容易
→ PRベースでplan/applyが実行され、安全なGitOps運用を実現。モジュール設計による再利用性の高さ
→ Cloud Runやバッチジョブなど共通構成をテンプレート化し、新規サービス追加も容易。AIツールとの親和性が高い
→ リソース種別ごとのモノレポ構成により、AIが既存設定を参照しやすく、自然言語操作が実用的に。GUI操作が不要となり、リリース作業が安全かつ効率的に
→ 以前はペアでダブルチェックしていた操作をコードレビューで完結できるようになった。
ツールの課題点
学習コストの高さ
→ 初心者にとってTerraform特有の概念(state管理やmodule構成)を理解するのに一定の習熟が必要。リファクタリング時の影響範囲が大きい
→ モノレポ構成のため、共通モジュール変更時には複数環境への影響確認が求められる。state管理の煩雑さ
→ 複数環境でのstate分離やバックエンド構成を誤ると運用リスクが発生する可能性がある。
今後の展望
現時点のTerraform構成は、PIVOTの現行チーム体制とプロダクト数に最適化された設計になっています。
ただし、今後プロダクトが増えたり、チームが分かれて複数体制での開発・運用が進む場合には、構成の最適解も変わっていくと考えています。
そのため、今の構成に固執せず、チーム規模や開発フローの変化に応じて柔軟に調整していく方針です。
たとえば、将来的にプロダクトごとの独立性が高まれば、Terraformのモジュール分割やリポジトリ構成の再検討も視野に入れています。
運用の安定性を保ちながら、環境変化に適応できる構成を維持していくことを目指しています。
PIVOT株式会社 / tawachan
テックリード / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 10名以下
よく見られているレビュー
PIVOT株式会社 / tawachan
テックリード / バックエンドエンジニア / 従業員規模: 51名〜100名 / エンジニア組織: 10名以下
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法


