TECH MEMO / FIELD NOTE同じ職位で転職活動をして見えてきた、現代SREの市場価値と求められるリアル
1. はじめに（転職の報告とこの記事の目的）
現職（リーガルテックのSaaS企業）での最終出社日を迎え、9月末の退職に向けて有給休暇の消化に入ることになりました。10月からは新たな環境へ転職します。
マネジメント職（EMなど）への転身ではなく、プレイヤーとしてSREを続ける同職種での転職です。新天地では「1人目SRE」として働きます。
バックエンド開発、MSPでのマルチクラウドインフラ、そして自社SaaSのSREを経て、なぜ今あえて新天地の「1人目SRE」を選んだのか。職種を変える転職では見えにくい、「企業ごとのSRE観の違い」や「現代SREの市場価値のリアル」について、思考の棚卸しとこれから転職を考える方へのヒントを兼ねてブログに残したいと思います。
この記事を通してお伝えしたいのはひとつだけです。
「現代のSREで評価されるのは、インフラ技術の広さだけではない。事業や組織の課題を信頼性の問題として捉え、測れる状態を作り、開発組織へ改善を広げられることに市場価値がある。」
2. 動機と軸（なぜ転職したのか・大切にした軸）
散らかった現場の「正常化」からSREの土台構築（0→1）をやり切るまで
現職のSRE組織は、初代SREチームの崩壊を経て、運用の属人化と手作業が放置され、インフラが腐敗していくという危機的なフェーズにありました。
その課題を解決すべく、全社の技術戦略をリードする方（当時の上司）が入社し、その戦略を実行して現場を牽引するSREとして、私がジョインしました。
この方は私の入社後数か月で退職することになってしまいましたが、今でも心から尊敬しており、キャリアの中で出会えたことは、私にとってかけがえのない財産です。そして退職後も、その技術戦略を引き継ぎ、崩壊したインフラを立て直すため、泥臭く正常化を牽引していきました。
- インフラ構成の再設計・最適化
- New Relicを中心とした可観測性（Observability）基盤の導入・ロードマップ策定
- SLI/SLOの定義と運用開始
- 生成AI（Claudeなど）を活用した運用トイル削減・セキュリティチェック回答自動化
- 脆弱性診断・ISMS・BCP訓練などのセキュリティ・ガバナンス対応
これらの取り組みは、仕組みを導入して終わりではありませんでした。インフラ構成の再設計・最適化により、一部のサービスではレスポンスタイムを77%短縮し、Windows Serverコンテナの実行基盤をECS on EC2からECS on Fargate（Windows）へリアーキテクチャしたことで、デプロイ所要時間も50%短縮しました。
また、営業部と連携してClaudeを活用したセキュリティチェックシートの回答支援を仕組み化し、回答業務の生産性を80%向上させました（営業視点での取り組みはこちらのnoteにもまとめられています）。この取り組みは、セキュリティチェックシートの記入において、プリセールスやCREが業務で手一杯になり浮いてしまったボールをSREが拾って対応することから始まりました。その中で見えてきた課題に対し、SRE側が一方的に自動化を押し付けたのではなく、営業現場とSREの双方が「回答業務の長期化と手作業の負荷」という共通のペインを感じていた中で、営業側から声をかけてもらったことをきっかけに改善プロジェクトが動き出しました。以前トイルについての記事でも考察しましたが、トイル削減の価値が最も大きく発揮されるのは、「エンジニアの自己満足ではなく、部門を超えてお互いに共通認識として抱えている課題を解くとき」だと確信しています。これらの改善は私一人で完結したものではなく、関係各所との調整・協力によって実現できたものです。
手探りと混沌の中、自ら課題を発見してロードマップを描き、技術基盤を整え直すことで、現場を「やっと本格的なSREができる状態（スタートライン）」へと引き上げることができました。
振り返れば、組織の変遷の中で、他チーム（CREなど）が機能不全に苦戦する状況もありました。そのなかで、時には実態に合わせて「インフラ担当」と看板を変えながらも、この3年間、現場を投げ出さずにプロダクトの信頼性を守り切ることができました。それは、最初に共有した「確固たる技術戦略」という北極星があったからだと実感しています。
直面した「1→10の壁」と組織構造
しかし、土台が整った後に直面したのが「文化の浸透（1→10）」という組織的な壁でした。
サービスレベルを設計・運用するにあたり、オライリーの『SLO サービスレベル目標』は大いに参考になり、実践の拠り所になりました。しかし、同書でも強く説かれている「組織への浸透や合意形成」のプロセスに向き合う中で、組織構造の壁に阻まれ、現場に浸透させる難しさを痛感したのも事実です。
0→1では個人の強いオーナーシップが推進力になります。しかし、1→10に進むにはそのオーナーシップを開発組織全体へ広げていく必要があります。信頼性に関する判断や運用をSREが抱え込み続けると、SRE自身が組織上の新たなSPOFになってしまうからです。
SREのキャリア観：「ツアー・オブ・デューティ（任期と使命）」の完遂
LinkedIn創業者のリード・ホフマンらが提唱した「ツアー・オブ・デューティ（Tour of Duty）」というキャリアの概念があります。終身雇用でも刹那的なジョブホッピングでもなく、「会社と個人が明確な変革ミッション（任期）を共有して全力でコミットし、それをやり遂げたら次の挑戦へ進む」というアライアンスの考え方です。
この考え方は、事業や組織のフェーズによって求められる役割が大きく変わるSREという職種に、極めてフィットすると感じています。
現職における私のツアー・オブ・デューティは、「崩壊後の散らかったインフラを正常化し、SREができる土台（0→1）を築くこと」でした。性能改善、コスト最適化（削減）、New RelicやSLOの導入、AIによるトイル削減までをやり切ったことで、私はこの任務を胸を張って完遂できたと実感しています。
そして、次の新天地で私が引き受ける新たなツアー・オブ・デューティこそが、「最初から分断を作らない1人目SREとして、0→1の基盤と1→10の文化を共同設計すること」です。
転職先を決めた決定打：経営層の理解と「プロダクトへの一目惚れ」
SREにとって技術はあくまで手段であり、目的は「事業・ドメインの成長を信頼性で支えること」です。数ある選択肢の中から次の環境を選んだ理由は、主に3つありました。
- 経営層が現状の課題を理解しSREの価値と必要性を深く理解していたこと
単なる「インフラの運用代行」ではなく、事業成長と開発スピードを加速させるパートナーとしてSREを求めていることが対話から伝わってきました。 - 現職での0→1（正常化）の実績を正当に評価してくれたこと
散らかった現場の課題を発見し、泥臭い正常化に始まり、SLO・可観測性・AI自動化まで自走したプロセスを高く評価してもらえたことは大きな自信になりました。 - 事業ドメインへの強烈な共感（プロダクトへの一目惚れ）
SREにとって技術はあくまで手段であり、「自分が支えるプロダクトのドメインに心から共感できるか」は極めて重要な軸です。現職のリーガルテックも、かつてSES/SIer時代に契約周りの手続きや非効率に振り回された苦い経験から、「この領域の課題を解決したい」と強い興味を持って入社しました。
そして今回の転職先は、企業のアイデンティティ統制や権限管理・組織のガバナンスを支える領域のプロダクトです。
現職でISMS対応やセキュリティ運用を主導する中で、毎月の組織変更に伴うアクセス権管理や統制面の泥臭い負荷・つらさを、まさに自分自身の「日々のリアルな業務」として身をもって痛感してきました。
過去の原体験以上に、直近の実務で自分自身が一番身近に感じていた切実なペインだったからこそ、その本質的な課題を解こうとしているプロダクトに出会ったとき、「この仕組みは世の中に絶対に必要だ」と直感し、プロダクトに一目惚れしました。
「焼け野原からの正常化」を経験したからこそ、後から分断を修復する難しさを痛感しました。だからこそ次は、自分自身が当事者として最も身近に感じた課題を解決できる事業ドメインに心から共感できる環境で、最初から分断を作らない1人目SREとしてカルチャーを共同設計できる環境を選びました。
3. 【学び①】面接で聞かれたこと・企業の関心事
スカウト20社の主ミッション分析：企業が求める背景のリアル
転職活動中にいただいたスカウト20社（スタートアップ〜メガベンチャー、上場企業子会社など）を分析すると、私に期待されたミッションは大きく以下のように分類できました。
① 0→1 専任立ち上げ型（1人目SRE）（15% / 3社）
- 主なフェーズ: Series A（10〜50名規模）
- ミッション: インフラの正常化、IaC化、監視基盤の立ち上げ、ISMS対応
- 現場のリアル: 開発者がインフラを兼任してきたが事業拡大で限界を迎えたフェーズ。「何から手をつけるべきか」の課題発見からロードマップ策定まで、ゼロから自走できる突破力が求められます。
② SRE組織の「再立ち上げ・立て直し」型（5% / 1社）
- 主なフェーズ: Series B/C（50〜100名規模）
- ミッション: 形骸化したSREチームの再構築、上場準備（コンプライアンス・ガバナンス整備）
- 現場のリアル: 「過去にSREチームを作ったが運用の丸投げ先になり空中分解した」「開発と運用の溝が深まった」という挫折経験を持つ企業。単なる技術導入ではなく、組織のコミュニケーションとカルチャーをリセットして再設計できる人材が切望されています（※現職で私が担った役割も、まさにこの「組織崩壊後の散らかった状態からの立て直し・正常化」でした）。
③ 新規プロダクト専任SRE型（10% / 2社）
- 主なフェーズ: 上場企業 / メガベンチャー / 金融系子会社
- ミッション: 新規SaaS・新規事業のアーキテクチャ設計、モダンな技術スタック（Go、Kubernetes、マルチクラウド）の立ち上げ
- 現場のリアル: レガシーな既存システムとは切り離し、最初からSRE原則を取り入れたモダンな信頼性基盤を作りたいという需要がありました。
④ 既存SRE / プラットフォーム組織の増員型（50% / 10社）
- 主なフェーズ: Series B/C〜D、上場企業 / メガベンチャー / 子会社（50名以上）
- ミッション: プラットフォームエンジニアリング（DevEx向上）、既存SREチームの増強
- 現場のリアル: 組織拡大に伴う増員が中心ですが、「SREと名乗りつつ実態は開発と切り離された運用部隊になっている」といった構造的な課題を抱えている企業も少なくありませんでした。
⑤ その他（SRE以外の隣接職種：CRE / FDE / セキュリティなど）（20% / 4社）
- 職種内訳: 1人目CRE（立ち上げ）、FDE（組織立ち上げ）、セキュリティエンジニア（買収後の組織浸透）、バックエンドリード
- なぜスカウトが届いたのか（特記）:
- CRE / FDE: バックエンド開発力に加え、MSPでの泥臭い運用・顧客対応の経験がマッチしたと推測しています。
- セキュリティ: SRE起点でISMS運用・脆弱性診断・AIによるチェックシート回答自動化まで「動くセキュリティ」を実践した実績が評価されたと推測しています。
- バックエンドリード: 非機能要件（性能改善・可観測性）を見据えたアーキテクチャ設計力が評価されたと推測しています。
働き方とAIツールのリアルなデータ
- 働き方: フルリモート40%（8社）、週1〜2日出社50%（10社）、週3日以上出社10%（2社）。今回の20社では、フルリモートまたは週1〜2日出社の企業が9割を占めました。
- 生成AIの実務利用: 20社中11社（55%）で「Claude Code」「Cursor」「Devin」のいずれかが明記されており、AIを活用した開発・自動化は珍しくなくなっています。
面接で頻出だった「開発・運用分断」への問い
実際に参加した面談・面接で特に評価されたのは「課題を自ら発見し、0から基準を作って形にした0→1の推進力」でした。
一方で、複数の面談・面接で繰り返し聞かれたのが「開発チームと運用の分断をどう防ぎ、どう巻き込むか？」です。 求人票にどれだけ魅力的な技術スタックが並んでいても、「SREを採用したものの、開発からの運用丸投げ先になってしまい、新しい縦割りができてしまった」という壁に、多くの企業が直面しているのが市場のリアルでした。
4. 【学び②】自分の強みとギャップの気づき
技術スタックの一致だけでは市場価値にならない
Kubernetes、Terraform、AWS/GCP、New Relicなどの経験は、選考に入るための基礎（前提条件）に過ぎません。SREからSREへの転職活動で問われたのは、その先にある「技術を事業価値へ接続できる力」でした。
- なぜその技術やアーキテクチャを選定したのか
- どのような仮説を立て、何を測って判断したのか
- それによって顧客影響やビジネスにどう貢献したのか
- 導入した仕組みを、開発組織へどう広げたのか
GoogleのSRE本は共通言語にはなりますが、Googleのやり方をそのまま模倣することが目的ではありません。自社の事業と組織に合わせて原則を適用する「判断の筋道」こそが評価されます。
システムは「運用を見据えた設計」でなければ意味がない
私がエンジニアとして最も大切にしている信念のひとつが、「システムは運用を見据えた設計ができていなければ意味がない」ということです。
リリースはシステムのライフサイクルにおける通過点であり、その後も「本番環境での運用・保守・進化」が続きます。 設計段階で「障害発生時にどう原因を特定するのか（可観測性）」「負荷急増時にどう縮退運転するのか」「日々の運用トイルをどう自動化・削減するのか」といった運用視点が抜け落ちたシステムは、どれほど美しく実装されていても、やがて開発組織のスピードを奪い、現場を疲弊させる負債と化してしまいます。
だからこそ、「開発と運用の分断」は絶対に起こしてはならないのです。 開発が運用を見据えずにコードを壁の向こうへ放り投げ、Opsがその火消しに追われ続ける構造のままでは、本質的な信頼性設計など実現できるはずがありません。
MSPで多様なシステムの泥臭い運用現場に携わり、自社SaaSで散らかったインフラの正常化をやり切ったからこそ、「運用を後から引き受けるだけのOps」ではなく、「設計の初期段階から開発チームと手を取り合い、運用性と信頼性をビルトインするSRE」でありたいと強く考えています。
AIネイティブ時代だからこそ問われる「ガードレール設計」とSREの真価
昨今のAI支援開発（Claude Code、Cursor、Devinなど）により、開発者がコードを生成・リリースするスピードは加速しつつあります。
しかし、コード生成が容易になったからこそ、「運用を見据えていないコード」や「非機能要件（性能・セキュリティ・可観測性）の考慮不足」が本番環境に持ち込まれるリスクも高まります。
ここでSREが「人手による関所（ゲートキーパー）」になってしまっては、開発の加速を阻害してしまいます。 これからのSREに求められるのは、開発者が安全に疾走できる「ガードレール（IaCテンプレート、CI/CDでの自動検査、組み込みの可観測性）」をプラットフォームとして整備することです。
そしてSRE自身も、定型業務や運用トイルをAIで徹底的に自動化・削減し、それによって生み出した時間で「アーキテクチャの対話」や「事業と信頼性の本質的な設計」に向き合うことこそが、AI時代のSREの真の価値だと実感しました。
自分の市場価値は「再現できる6つの型」にある
今回の転職活動を通じて、自分の市場価値は「SRE歴◯年」という経歴ではなく、以下の再現可能な型にあると確信できました。
- 曖昧な事業・組織の課題を発見する
- それを「信頼性の問題」として言語化する
- 測れる状態（可観測性・SLI/SLO）を作る
- 技術的負債を解消・改善する
- チームが自ら判断できる基準を作る
- 組織へオーナーシップを移譲する（SPOF化の防止）
1人で計画して進める突破力をベースにしつつ、次は最初からこの「組織への移譲（Enable）」を前提として動くアプローチへ進化させることが自分のテーマです。
5. 【学び③】カジュアル面談・面接の進め方
「SREを採用したい企業」と「SREが価値を出せる企業」は見極めが必要
求人があることと、SREとして本来の価値を発揮できる環境があることは別問題です。 面談や面接では、以下のポイントを逆質問などを通じて率直に確認することが極めて重要でした。
- 採用背景: 経営層や開発責任者が「なぜ今SREが必要なのか」を自分の言葉で説明できるか？
- 期待値と権限: SREを「インフラの何でも屋」にしようとしていないか？ 組織横断の改善を進める権限があるか？
- Dev/Opsの距離感: 開発チームは信頼性に関心を持っているか？ 責任分界をどう考えているか？
- 事業との接続: 信頼性の向上を事業成長とどう紐づけて捉えているか？
面談で盛り上がった「おすすめの逆質問」
特に現場のリアルなカルチャーや技術的成熟度を見極める上で、効果的だった逆質問が2つあります。
- 「エラーバジェットをもとに、リリース速度と信頼性のバランスをどう合意しているか？」
SLOが単なる「ダッシュボードのお飾り」になっていないか、エラーバジェットが枯渇した際に「機能開発の手を緩めて信頼性に投資する」という文化やポリシーが実際に機能しているかを見極めるリトマス試験紙になります。なお、まだサービスレベル（SLI/SLO）を設定していない企業であれば、「品質とリリーススピードが衝突した際、どちらを優先してどう合意しているか？」と言い換えて質問していました。これにより、フェーズを問わず開発組織と経営層のリアルな意思決定基準が浮き彫りになります。 - 「過去に『技術を捨てる（やめる）判断』をどう下したか？」
新しい技術を採用する話は誰でも熱く語れます。しかし、増えすぎたツールやレガシーなアーキテクチャを「どう見極め、どう捨てたか」というエピソードを聞くことで、その組織の技術的負債への向き合い方や意思決定の成熟度が驚くほどリアルに見えてきます。
特に1人目SREでは、技術的な裁量以上に「組織と対話し、文化を作っていける土壌があるか」が入社後の成否を分ける決定的な要素になります。
6. おわりに（次のチャレンジへの想い）
SREからSREへの転職活動は、自分の現在地と「SREという役割の本質」を客観視する最高の機会になりました。SREとしての道のりと、これから新天地で挑むテーマを図解にまとめると、以下のようになります。
SREの面白さは、何が正解かわからないこと
SREの現場には常にジレンマが存在します。
- 強いオーナーシップがなければ0→1は進まない ↔ 持ち続けるとサイロ（属人化）になる
- SLOがなければ信頼性を定量的に議論しにくい ↔ SLOそのものが目的化してしまう
- SREが必要だから採用する ↔ 最終的には特定のSREに依存しない組織を目指す
こうしたトレードオフがあるからこそ、その時点の事業・組織・システムにとっての「最適解」を問い続け、試し、学び、改善し続けることにSREの面白さがあります。
新天地での挑戦：Own（0→1）から Enable（1→10）、そして Transfer（理想）へ
ここでは、課題を自ら引き受ける段階をOwn、仕組みと判断を組織に広げる段階をEnable、特定の人に依存せずに改善が続く状態をTransferと呼んでいます。
現職において私は、SREとして「技術基盤の正常化（0→1 Own）」をやり切ることができました。 そして次の新天地では、この経験を確固たるベースとしながら、「仕組みと判断を組織へ広げる（1→10 Enable）」、そして「特定のSREに依存せずに改善が続く状態（Transfer）」を見据えて挑戦します。
残すべきなのは「自分が作ったダッシュボードや運用手順」ではなく、「顧客影響から信頼性を考え、測って判断し、障害から学び、信頼性を組織全体で持つ文化」です。
「SREの真の市場価値は、どれだけ多くの技術を自分で抱え込めるかではない。信頼性を組織の能力へと変換し、最終的に『特定のSREに依存しなくても信頼性が高い組織』を作れるかにある。」
新天地は、専任のSREがいない開発組織です。そこに1人目SREとして加わる以上、一目惚れしたプロダクトと事業ドメインを支えるために、「もし次の環境で分断が起きてしまったら、それは自分自身のアプローチに原因がある」という覚悟を持って、次のステージでも信頼性と事業成長をドライブしていきたいと思います。
10月に向けて充電期間中