導入：ジョイン直後に感じた「開発サイクルの重さ」
「入社して3ヶ月、私はある『ジレンマ』を抱えていました。」
2025年11月、SREとしてjinjerにジョインした私を迎えたのは、Terraformによって厳格にコード化されたインフラ基盤でした。すべてのリソースがIaCで管理され、手動変更を排した運用ルールが徹底されている。これはSREとして、非常に信頼性の高い、誇れる環境だと言えます。
しかし、その「正しさ」が、開発のスピード感と衝突する場面を目の当たりにするようになりました。
たとえば、ECSのタスク定義にある環境変数を1つ追加するだけでも、SEからJiraで依頼を受け、SREがコードを修正・レビューし、3か所の環境すべてに適用されるのを待つフローが必要です。
手順は確立されているものの、アプリ側のリリースサイクルが加速する中で、「本質的にはアプリの一部である設定変更を、なぜインフラ側で一つひとつ承認・適用し続けなければならないのか」。ルールを守るからこそ発生するこの数日のリードタイムが、SREとSE、双方の機動力を削いでいるのではないかと感じ始めたのです。
プロダクトの立ち上げ期や基盤の安定性を最優先するフェーズにおいては、一元管理による統制と確実なセキュリティの担保が『最適解』でした。
今回は、そんな「守りのIaC」から「攻めのIaC」へシフトするために私たちが取り組んだ、責任境界線の引き直しについてお話しします。
現状分析：ルールを守るからこそ発生する「待ち時間」
当時の運用フローを整理すると、以下のような状況でした。
- SEが依頼：変更内容をJiraチケットに記載し、SREチームへ依頼する。
- SREが受領・作業：SREがチケットを確認し、Terraformのコードを修正・プルリクエスト作成・適用（apply）をおこなう。
- SEが確認：適用完了の連絡を受け、SEが動作確認をおこなう。
これが単発ならまだしも、開発・ステージング・本番という3か所の環境すべてでこのフローを繰り返す必要がありました。
SE側は「すぐに試して改善のサイクルを回したいのに、SRE側の手が空くまで待たされる」ことにフラストレーションを感じ、一方でSRE側も「アプリケーション起因の細かな設定変更に追われ、本来注力すべきインフラの全体最適化や基盤改善の手が止まってしまう」という、双方のチームが本来のパフォーマンスを最大限に発揮しづらい、もどかしい状況が生じていました。
仮説：なぜ「全部Terraform」が苦しいのか？
原因は、リソースの「ライフサイクル」の違いを無視して、すべてをTerraformで一元管理しようとしていたことにありました。
インフラ管理のカテゴリには、大きく分けて2つの性質があると考えています。
1. 静的リソース（インフラ基盤）
VPC、データベース、IAM、ロードバランサーなど。
これらは一度構築すれば変更頻度は低く、万が一壊れた際の影響範囲が極めて大きいため、SREがTerraformなどで厳格に管理すべき「土台」です。
2. 動的リソース（アプリケーション実行定義）
ECSのタスク定義、Step FunctionsのASL、各種環境変数など。
これらはアプリケーションの機能追加や改善に密接にリンクしており、変更頻度が非常に高いものです。いわば「アプリケーションの一部」としての性質が強いリソースです。
「すべてをインフラコード（Terraform）として管理・利用する」という方針は一見正しいように見えますが、「変化の激しいリソース」までSREの管理下に置いてしまったことで、開発の機動性が失われていたのです。
解決策：境界線の引き直し（責務の分離）
そこで私は、この「境界線」を引き直すことに着手しました。
結論として、「インフラのコード」と「デプロイのコード」を明確に分離する方針を立てました。Terraformでは「静」のリソース管理に特化し、ECSタスク定義やStep Functionsの設定といった「動」のリソースは、アプリケーションのリポジトリ側で管理し、SE自身が自律的にデプロイできる体制への移行を進めています。
これにより、SEはSREへの依頼を待つことなく、自分たちのタイミングで設定変更とデプロイを完結できるようになります。
変化と挑戦：見えてきた兆しと、次なる課題
この「責務の分離」は、まずはスモールステップとして一部のプロダクトから導入を開始しました。まだ道半ばではありますが、導入したチームでは確かな変化が現れ始めています。
最大の成果は、Jiraチケットを介した、「待ち時間」の解消です。これまで3か所の環境における設定変更と完了確認に数日を要していたケースもありましたが、対象プロダクトではCI/CDパイプラインによるセルフサービス化が実現し、数分から数十分で作業が完結するようになりました。
SREチームにとっても、定型的な「チケット対応」という割り込みタスクが削減され、より抽象度の高いインフラ基盤の改善に時間を割く兆しが見え始めています。
一方で、「全社的な横展開」はまさにこれからの大きな課題です。
プロダクトごとに構成や歴史が異なる中で、いかに汎用性を持たせてこの仕組みを広げていくか。理想のビジョンにたどり着くためには、まだ解決すべき技術的・組織的なハードルがいくつも残っています。
最後に：一緒に「境界線」を引き直す仲間（特にSRE！）を募集しています
今回ご紹介したエピソードは、ジンジャーにおけるエンジニアリングの日常のほんの一コマです。
私たちは「今の運用がこうだから」と諦めるのではなく、「どうすればもっと開発スピードを上げられるか」「誰が責任を持つのが最適か」を常に問い直し、本質的な課題解決に取り組んでいます。
特に、この記事を書いている私自身がSREとして日々実感しているのは、 「SREが定型的な運用対応に追われることなく、基盤の全体最適化という本質的な価値を発揮できる体制」 ということです。
現在、ジンジャーでは東京拠点のSREメンバーを積極的に募集しています。
- 「インフラの運用」で終わらず、開発組織のアーキテクチャそのものを改善したい
- SREとSEの垣根を越えて、理想の開発体験を追求したい
- まだ解決されていない「横展開」という難題に、同じSREとして挑んでみたい
そんな熱意を持った方と、ぜひお話ししたいです！まだ「一部の成功」に過ぎないこの取り組みを、共に全社規模の当たり前に変えていきませんか？
少しでも興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう。東京のオフィスで、お待ちしています！
Discussion