この記事では、コードも書くインフラ寄りのSREとして、デプロイフローやCI/CD、Infrastructure as Codeの整備を続けてきたエンジニアに、「なぜ改善が届かないのか」「どうやって開発の流れごと変えていったのか」を聞きました。
- 年代30代前半
- 現職プロダクトSRE（インフラ寄り）コンテナ基盤やネットワーク、CI/CDパイプラインの構築・運用を担当。KubernetesやTerraformなどを用いて、開発チームが安全かつ素早くリリースできる土台づくりに取り組んでいる。
- キャリア受託インフラ → 内製インフラ → SRE新卒で受託開発企業に入社し、オンプレミス環境でのサーバ構築・運用を担当。その後、事業会社のインフラエンジニアとしてクラウド移行やCI/CD導入に携わり、現在はSREとしてプロダクト横断のインフラ改善と運用自動化を推進している。
- プライベートゲームとポケカが息抜き休みの日はゲームで遊んだり、友人とポケモンカード対戦を楽しむことが多い。デッキを組むときも「回しやすさ」と「安定性」を重視するタイプ。
キャリアの流れ ― インフラから“流れ”を整えるSREへ
オンプレ時代に身についた“手を動かす”基礎体力
最初のキャリアは、受託開発企業でのインフラ担当でした。物理サーバのセットアップからOSのインストール、ミドルウェアのチューニング、障害対応まで、一通りなんでもやる仕事です。夜間対応もありましたし、ログを追いかけながら原因を特定するような泥臭い作業も多かったですね。
当時はまだコードでインフラを管理する文化が弱くて、シェルスクリプトは書いていましたが、今のようなTerraformやAnsibleといったツールはほとんど使えていませんでした。それでも、「自分の手で環境を作って、動かして、壊して、また直す」という経験を積めたことは、今の自分のベースになっていると感じます。
クラウド移行とCI/CDで見えた「開発速度」の世界
そこから内製の開発組織に移ったタイミングで、クラウド移行とCI/CD導入のプロジェクトに関わることになりました。ここで初めて「インフラの設計が、そのまま開発速度やリリース頻度に効いてくる」という感覚を持てたのが大きかったです。
例えば、手作業で構築していた環境をTerraformでコード化し、CI/CDパイプラインから自動で反映できるようにしたことで、環境差異によるトラブルが減り、リリース前の“謎の不具合調査”に割いていた時間が大きく減りました。その経験から、「環境をきれいにすること」よりも「開発の流れを止めないこと」が、インフラの価値として重要なんだと意識が変わっていきました。
インフラSREとして向き合う、“改善が届かない”現実
パイプラインと環境をつなぐ“裏方エンジニア”
今は、プロダクトの開発チームと一緒に、コンテナ基盤とCI/CDパイプラインを整える仕事が中心です。具体的には、Kubernetesクラスタの設計・運用や、GitOps的なデプロイフローの整備、Terraformによるインフラリソースの定義などですね。
ただ、自分の感覚としては「インフラを運用する人」というより、「コードで環境と開発の動線をつなぐ人」というイメージの方が近いです。開発者が意識しなくても、テストやデプロイまで流れるように進む状態を作りたい。そのために、パイプラインやツールの裏側をいい感じに調整していく、いわば“裏方のエンジニア”だと捉えています。
良い仕組みを作っても、誰も使ってくれない悔しさ
一方で、「これは良い改善だ」と思って用意した仕組みが、なかなか開発チームに使われないという経験もたくさんしてきました。テスト自動化のジョブを整備してもスキップされてしまったり、新しいパイプラインを作っても「今のままで慣れているから」と移行されなかったり。
そのときに痛感したのは、「技術的に正しいかどうか」と「普段の開発フローの中で自然に使えるかどうか」は別軸だということです。良いツールやパイプラインを用意しただけでは、現場の人たちの“手の動かし方”は変わりません。そこから、「改善をどうやって流れに乗せるか」という視点を持つようになりました。
なぜ改善は届かないのか ― 技術ではなく“流れ”の問題
入口が増えるほど、現場は迷子になる
今振り返ると、改善が届かなかった理由のひとつは、「入口を増やしすぎていた」ことだと思っています。新しいツールやパイプラインを追加するとき、つい「これも便利」「あれもやっておきたい」と思ってしまうんですが、結果として選択肢だけが増えてしまう。
開発者の立場から見ると、「どのジョブを選べばいいのか」「どのブランチ戦略と組み合わせればいいのか」が分かりづらくなり、結局これまでと同じ手順に戻ってしまう。技術的には正しい改善でも、「どこから入ればいいか」が分からないと、現場では動かないということを学びました。
“楽になる瞬間”が早く訪れるように設計する
もうひとつ大きかったのは、「楽になる瞬間が遅い改善は、なかなか受け入れられない」という気づきです。例えば、テストカバレッジを上げるために、新しいテストフレームワークやジョブを導入するケースがありますよね。
長期的には価値があるとしても、「最初の数週間はテストコードを書く手間が増えるだけ」という状態だと、どうしても優先度が下がってしまう。そこで意識するようになったのは、「導入した直後から、目に見えて嬉しい効果が出るポイントをどこに置くか」という設計です。例えば、テストに通ると自動でステージング環境にデプロイされるようにしておけば、「テストを書くと確認が早く進む」というメリットをすぐに感じてもらえます。
コードで“流れ”を変える ─ 実際にやったこと
パイプラインを“一本化”して、迷いを減らす
ひとつ大きかったのは、プロダクトごとにバラバラだったパイプラインを、パターンごとに整理して“実質一本化”したことです。それまでは、チームごとに少しずつ異なるYAMLやスクリプトを使っていて、ジョブ名もルールも統一されていませんでした。
そこで、よくある変更パターンを洗い出し、「普段使うのはこのパイプライン」「特殊なときだけこっち」という形に整理しました。そのうえで、リポジトリに置くテンプレートやドキュメントも合わせて更新し、「新しいブランチを切ったら、まずこのファイルをそのまま使えばOK」という動線を作りました。結果として、「どのジョブを選べばいいのか」という迷いが減り、自然と新しいパイプラインの採用率が上がっていきました。
失敗しても壊れない“安全な遊び場”を用意する
もうひとつ意識しているのは、「失敗しても大丈夫な場所を先に用意しておく」ことです。新しい仕組みを使うとき、開発者が一番不安なのは「もしミスったら本番に影響が出るんじゃないか」という点ですよね。
そこで、ステージング向けの環境や検証用クラスターを手軽に触れるようにしておき、「まずここで試してみてください」という導線を整えました。Terraformのコードも、本番用と検証用で明確に分け、プルリクを見る側も「これは検証用だから、多少試行錯誤していてもOK」と判別しやすくしています。
ゲームが好きな人なら分かると思うんですが、新しいデッキや戦術をいきなり本番のランクマッチで試すのは怖いですよね。まずはフリーマッチや身内対戦で試してから本番に持ち込む。その感覚に近いものを、インフラ側でも用意したいと思っています。
SREとして大事にしている視点と、これからのキャリア
“速さ”と“安全さ”のバランスを、コードで調整する
自分がSREとして意識しているのは、「速さ」と「安全さ」のバランスを、コードでうまく調整することです。速くリリースしたい気持ちと、事故を起こしたくない気持ちは、どちらも本物です。その両方を叶えるために、チェックやガードレールを手作業ではなくパイプラインや設定で表現していく。
例えば、レビューの有無やテストの結果によって通るルートを変えることで、「急ぎの対応だけど、最低限ここまでは守ろう」というラインを自動的に担保できます。そういう意味で、SREの仕事は“制限を増やすこと”ではなく、“安心してアクセルを踏める範囲を広げること”だと思っています。
「このプロダクト、触っていて気持ちいいよね」と言われる状態を増やしたい
今後のキャリアとしては、特定の技術スタックだけではなく、「開発体験そのものをどう設計するか」という観点をもっと深めていきたいと考えています。ビルドが速い、テストが信頼できる、ログが追いやすい、デプロイが怖くない。そういう“触っていて気持ちいいプロダクト”を増やしたいです。
個人的には、ゲームやポケカでデッキを組むときも、「派手なコンボが決まるかどうか」より「ちゃんと回るかどうか」を重視するタイプなんですよね。どんな手札が来ても、それなりに戦える構成にしておきたい。その感覚は、プロダクトの運用にも通じるものがあると感じています。
インタビューを終えて
入口を増やしすぎると迷子になること、楽になる瞬間が遠い改善は受け入れられにくいこと、そして「安心してアクセルを踏める範囲を広げる」という表現。どれも、手を動かすSREとして現場にいるからこその言葉だと感じました。
インフラ寄りでコードも書くSREの仕事は、まだ一般的なイメージが固まっていない領域かもしれません。でも、「回しやすさ」や「気持ちよさ」を意識してプロダクトの流れを設計していく視点は、多くのチームにとってヒントになるはずです。今回のインタビューが、同じように現場で試行錯誤している方の背中を、少しでもそっと押せていたらうれしいです。
