小規模チームでも安定して運用できるTerraform構成 ─ PIVOTがIaC化で実現した安全性と拡張性

ツール導入前の課題

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構成は、PIVOTの現行チーム体制とプロダクト数に最適化された設計になっています。
ただし、今後プロダクトが増えたり、チームが分かれて複数体制での開発・運用が進む場合には、構成の最適解も変わっていくと考えています。

そのため、今の構成に固執せず、チーム規模や開発フローの変化に応じて柔軟に調整していく方針です。
たとえば、将来的にプロダクトごとの独立性が高まれば、Terraformのモジュール分割やリポジトリ構成の再検討も視野に入れています。

運用の安定性を保ちながら、環境変化に適応できる構成を維持していくことを目指しています。