SRE採用が難しい最大の理由は、「インフラ×ソフトウェア開発の交差領域に立てる人材」の絶対数が市場に極端に少ないことです。解決策は、自社フェーズに合わせた要件定義・相場に合った報酬レンジ・オンコール体制まで開示する求人票・個別化したスカウトの4点を揃えることに尽きます。筆者が採用支援の実務で蓄積してきたノウハウを体系的に解説します。

TL;DR（この記事の要約）

• SRE・インフラエンジニアは市場に人材が少なく求人倍率が極めて高いため、採用難度はトップクラス

• 「何でもできるインフラ人材」ではなく、自社フェーズに合った要件定義が採用成功の第一歩

• 年収レンジはミドル600〜900万円、シニア900〜1,300万円が目安。相場を外すとスカウトすら読まれない

• 求人票では技術スタック・SLO運用体制・オンコール頻度を具体的に開示するのが返信率向上のカギ

• スカウトは媒体選定×個別化×現場エンジニアの関与で返信率が大きく変わる

• 正社員にこだわらず、副業・業務委託からの段階的採用も有力な選択肢

SRE・インフラエンジニア採用はなぜこれほど難しいのか

SRE採用が難しいのは、人材供給の少なさ・スキル要件の広さ・報酬競争の激しさという3つの構造要因が重なっているためです。筆者がスタートアップの採用支援で最も頻繁に受ける相談が「SREを採用したいが、半年経っても1人も内定に至らない」というものですが、その大半は戦術ではなく構造の理解不足に原因があります。

まず市場全体の需給を押さえておきましょう。

• doda「転職求人倍率レポート」によると、IT・通信エンジニアの求人倍率は10.68倍（2026年データ）。全職種平均の約4倍の水準で推移しており、エンジニア採用全体が極端な売り手市場にある

• 経済産業省の試算では、2030年に最大79万人のIT人材が不足するとされ、構造的な人材不足は今後さらに深刻化する見込み

• その中でもSREは職種としての歴史が浅く、経験者の母数がアプリケーションエンジニアより一段と少ない

人材供給の絶対量が少ない

SREという職種自体がGoogle発祥の比較的新しい概念であり、日本では2018年前後から求人が増え始めました。歴史が浅い分、経験者の絶対数が限られています。アプリケーション開発者と比べて母数が圧倒的に少なく、「そもそも候補者がいない」状態に陥りやすいのが実情です。

求められるスキルセットが幅広い

SREに求められるスキルは従来のインフラエンジニアの範囲を大きく超えます。

Googleが提唱するSREの原則では「業務時間の50%以上はソフトウェアエンジニアリングに充てるべき」とされています。インフラの知識だけでなくコードを書ける力が必須であり、この交差領域に立てる人材は市場でも希少です。

大手企業との報酬競争と潜在層の多さ

メガベンチャーや外資系がシニアSREに年収1,000万円超を提示するケースは珍しくなく、スタートアップが同じ土俵で戦うのは容易ではありません。さらにSRE・インフラエンジニアは転職市場に能動的に出てくる人が少なく、転職サイトでの求人掲載だけでは十分な母集団を形成できません。ダイレクトリクルーティングやリファラル、技術コミュニティ経由のアプローチが不可欠です。

自社フェーズに合ったSRE要件を定義する

SRE要件定義の鉄則は、「SREを採りたい」という漠然としたオーダーを企業フェーズ別の具体的な役割に翻訳することです。筆者の経験上、採用で最もありがちな失敗は要件を曖昧なまま求人を出すことで、企業のフェーズによって求める人物像はまったく異なります。

フェーズ別の求める役割

シード〜シリーズA（10〜30名規模）：SRE専任を置く余裕がないことも多く、「インフラも見られるバックエンドエンジニア」が現実的です。クラウドの初期構築、CI/CD整備、デプロイ自動化が主務。必須スキルはAWSまたはGCP実務経験、Docker、基本的なLinux運用です。

シリーズA〜B（30〜100名規模）：SRE専任ポジションを設けるフェーズ。SLI/SLO策定、Kubernetes運用、監視体系整備、IaC標準化、オンコール体制構築が主務。必須スキルはKubernetes実務経験、Terraform、監視ツール設計経験です。

シリーズC以降（100名超）：SRE組織を拡大し開発者セルフサービス化を推進。IDP構築、マルチクラウド対応、FinOps、セキュリティ基盤が主務。大規模インフラ運用と組織設計の経験が必要です。

Must要件は3つ以内に絞る

要件定義では全てを「必須」にしないことが重要です。筆者の経験上、Must要件を3つに絞れた企業は候補者プールが大幅に広がり、採用成功率が明確に改善しています。

なお、機械学習基盤の運用を見据えるなら、SRE経験者はMLOpsエンジニアへのキャリア転換親和性が高い点も要件設計時に考慮すると、将来の組織拡張がスムーズになります。

SRE・インフラエンジニアの年収相場と報酬設計

年収相場の把握は採用活動の前提条件であり、相場から乖離したレンジを載せた求人やスカウトは開封すらされません。筆者が支援した企業でも、レンジを市場相場に合わせ直しただけでスカウト返信率が目に見えて改善した例が複数あります。

言語・職種別の詳細な市場データはエンジニア年収相場2026にまとめています。

年収の絶対額で大手に勝てない場合は、ストックオプション、技術投資の自由度、フルリモート制度、学習支援、オンコール手当などを組み合わせた「トータルリワード」で勝負しましょう。特にオンコール手当はSRE特有の負荷に対して報酬で報いる姿勢を示すものとして、信頼獲得に直結します。

候補者に響く求人票の書き方

SRE向け求人票の核心は、技術スタック・SLO運用・オンコール体制を数字で開示することです。SRE・インフラエンジニアは情報感度が高く求人票を細部まで読み込むため、曖昧な表現はそれだけで候補者を遠ざけます。

NG例とOK例

技術スタック

• NG: 「クラウド環境の構築・運用」

• OK: 「AWS（ECS Fargate / Aurora / CloudFront）を中心としたインフラ基盤。IaCはTerraformで管理、CI/CDはGitHub Actionsで自動化」

オンコール体制

• NG: （記載なし）

• OK: 「4名でローテーション（月1〜2回担当）。PagerDuty導入済み。深夜対応は月平均1〜2回。手当あり」

オンコール体制はSREの入社判断に直結する最重要情報です。書かないと「ブラックでは」と疑われます。求人票の書き方全般はエンジニア求人票の完全ガイドも参考にしてください。

必ず含めるべき7項目

1. 技術スタック一覧（クラウド・IaC・コンテナ・監視・CI/CD・言語）

2. チーム構成（SREチームの人数、開発チームとの関係性）

3. 担当サービスの規模感（リクエスト数/日、DAU）

4. SREプラクティスの導入状況（SLO運用有無、ポストモーテム頻度）

5. オンコール体制の詳細（ローテーション人数、頻度、手当）

6. キャリアパス（ICルート / マネジメントルートの選択肢）

7. 年収レンジ（「応相談」はNG、幅を持たせつつ具体的に）

オンコール体制の設計が採用力を左右する

オンコール体制の設計品質は、SRE採用における「隠れた採用力」です。筆者の支援先で辞退理由をヒアリングすると、報酬と並んで多いのが「オンコールの負荷が読めない」という不安でした。逆に言えば、ここを丁寧に設計・開示できる企業は、報酬で勝る競合からも候補者を獲得できます。

候補者が見ているオンコールの3条件

体制が未整備の場合は、正直に「未整備であること」と「設計を任せたいこと」をセットで伝えてください。筆者の経験では、ゼロから仕組みを作りたいタイプのSREにとって、未整備はむしろ魅力に変わります。重要なのは情報を隠さないことです。

入社後の定着まで見据える

オンコールの負荷設計は採用後の定着にも直結します。burnoutの兆候が出る前に、アラートのノイズ削減・ポストモーテムでの改善サイクル・四半期ごとの負荷レビューを仕組み化しておくと、「運用で疲弊しない環境」として採用広報の材料にもなります。エンジニアの定着施策全般はエンジニア定着戦略ガイドも参考にしてください。

インフラエンジニア・SREに届くスカウトの実践

インフラエンジニアへのスカウトで成果を分けるのは、媒体選定・文面の個別化・現場エンジニアの関与の3点です。SRE・インフラ層は転職顕在層が極端に薄いため、待ちの求人掲載ではなく攻めのスカウトが母集団形成の主戦場になります。

媒体ごとの特徴と使い分け

媒体の比較検討はエンジニア採用媒体の選び方で詳しく解説しています。

スカウト送信までの5ステップ

1. 候補者の公開情報を10分間調査する: GitHub・技術ブログ・登壇資料から、使用技術と関心領域を把握する

2. 「この人に送る理由」を1文で言語化する: 「Terraformモジュールの設計記事を拝見し、当社のIaC標準化を任せたいと感じた」のように具体化する

3. 件名に固有名詞を入れる: 「インフラエンジニア募集」ではなく「TerraformとEKS運用の知見を活かせるSREポジション」のように技術名を明示する

4. 本文は400〜600字に収め、技術課題を率直に書く: 「監視がCloudWatch頼みでSLOが未整備。ここをゼロから設計してほしい」のような率直さが響く

5. 送信者は現場エンジニアかCTO名義にする: 人事名義よりも現場名義の方が返信率が高いのは、筆者の支援先でも一貫した傾向

スカウト文面の詳細なテンプレートはエンジニアスカウトメールの書き方、候補者の探し方はエンジニアスカウトの候補者サーチ実践ガイドを参照してください。

返信率を下げるNGパターン

• 全員に同じ文面を一斉送信する（テンプレ感は数秒で見抜かれる）

• 「インフラ全般お任せします」と守備範囲を曖昧にする

• オンコールや障害対応の実態に触れない（隠している印象を与える）

• 年収レンジを伏せる（情報の非対称性を嫌う層に逆効果）

SRE選考で見極めるべきポイント

SREの選考では、コーディング力だけでなく障害対応力・設計思想・運用への当事者意識を多角的に見極めることが重要です。選考ステップは4つ以内、全体リードタイム2〜3週間以内を死守してください。SRE経験者は複数オファーを並行して受けているのが常で、選考スピードの遅さはそれだけで辞退理由になります。

技術面接で使える質問例

障害対応力: 「最も印象的な本番障害について教えてください。どのように検知し、対応しましたか？」「ポストモーテムからどんな改善アクションにつなげましたか？」

設計思想: 「SLOを設定する際、どのような基準で数値を決めますか？」「可用性99.9%と99.99%のコスト差をどう経営層に説明しますか？」

コラボレーション: 「開発チームに運用改善を提案した経験はありますか？どう合意形成しましたか？」

障害対応の語り口からは、技術力以上に「他責にしない姿勢」が読み取れます。障害を人のせいにせず仕組みの改善につなげた経験を語れる候補者は、入社後もブレームレス文化の中核になってくれます。技術面接の評価ポイント全般についてはエンジニア技術面接の評価ガイドもご覧ください。

システムデザイン演習で実務力を確認する

口頭の質問だけでは設計力の深さまでは測れません。筆者が推奨しているのは、自社の実環境に近いお題でのシステムデザイン演習です。

• 「月間1億リクエストのAPIに対して、SLOを定義し監視構成を設計してください」

• 「現在EC2に手作業デプロイしている構成を、IaC化・コンテナ化していく移行計画を立ててください」

• 「データベースのフェイルオーバー訓練を四半期ごとに実施する計画を設計してください」

評価のポイントは正解の有無ではなく、前提条件を確認する姿勢・トレードオフの言語化・コストへの意識の3点です。45〜60分の演習で、職務経歴書からは見えない実務感覚がはっきり可視化されます。評価基準を面接官間で揃えるには面接スコアカードの設計が有効です。

候補者側も企業を選考している

SREは引く手あまたの売り手市場にいるため、面接は「見極めの場」であると同時に「口説きの場」です。面接の後半10分は必ず候補者からの質問時間に充て、技術的負債の実態・SREへの経営層の理解度・技術選定の裁量範囲について率直に答えてください。取り繕った回答は見抜かれます。カジュアル面談から惹きつけを設計する方法はカジュアル面談ガイドで解説しています。

副業・業務委託からの段階的採用

正社員採用だけにこだわらず、副業・業務委託を入口にした段階的採用を組み合わせるのが、SRE確保の現実解です。特にスタートアップでは、フルタイムのシニアSREを1人雇う予算で、週2日稼働の実力者に基盤設計を任せる方が費用対効果が高いケースが少なくありません。

副業→正社員化を成功させるには、最初から正社員化の可能性を伝えること、3ヶ月程度の明確なゴール設定、チームへの参加機会の提供が重要です。報酬が業務委託時と正社員時で大きく乖離しないよう配慮することも忘れずに。詳細は副業・業務委託エンジニア活用ガイドで解説しています。

SRE採用を成功させる90日ロードマップ

SRE採用は「準備30日・母集団形成30日・選考30日」の3フェーズで設計すると、行き当たりばったりの長期化を防げます。筆者が支援する企業には、以下のロードマップをベースに各社の状況に合わせて調整することを推奨しています。

1. Day 1〜30（準備フェーズ）: 自社フェーズの特定、Must要件3つへの絞り込み、年収レンジの市場照合、求人票7項目の整備、オンコール体制の現状整理（未整備なら「これから設計を任せたい」と明文化）

2. Day 31〜60（母集団形成フェーズ）: スカウト媒体2つに絞って週20〜30通の個別化スカウト送信、社内エンジニア経由のリファラル依頼、SRE NEXTなど技術コミュニティへの参加開始

3. Day 61〜90（選考・クロージングフェーズ）: カジュアル面談→技術面接→最終面接を2週間以内で完走する体制の運用、辞退理由の記録と求人票・スカウト文面への反映、オファー面談での技術課題・裁量範囲の具体提示

90日経過時点で「スカウト返信率5%未満」「面談からの選考移行率3割未満」のいずれかに該当する場合は、要件か報酬レンジのどちらかが市場とずれているサインです。施策を増やす前に、まず要件定義に立ち返ってください。

FAQ（よくある質問）

Q1. SREとインフラエンジニアの違いは？

インフラエンジニアはサーバー・ネットワークの構築・運用が主務です。SREはソフトウェアエンジニアリングの手法で信頼性を向上させることに重点を置きます。SLI/SLO設計やトイル自動化など、定量的指標に基づく管理がSREの特徴です。

Q2. SRE採用が難しいのは自社の問題？市場の問題？

両方ですが、まず市場構造を理解すべきです。求人倍率が10倍を超えるエンジニア市場の中でも、SREは経験者母数が特に少ない職種です。そのうえで、要件の絞り込み・報酬レンジ・求人票の具体性という「自社でコントロールできる変数」を最適化することが現実的な打ち手になります。

Q3. SRE未経験者の育成は現実的ですか？

現実的です。バックエンドやインフラからSREへのキャリアチェンジは確立されたパスです。育成には6ヶ月〜1年程度の投資が必要で、外部の副業SREをメンターとして招くOJT形式が効率的です。

Q4. 1人目のSREはどんな人を採るべき？

「仕組みをゼロから作れる人」が適しています。大規模環境の運用経験だけでなく、何もない状態からの立ち上げ経験を面接で重点確認してください。整った環境でしか働いたことのないシニアより、未整備環境を楽しめるミドルの方が活躍するケースは多いです。

Q5. オンコール体制がない状態で求人を出して大丈夫？

大丈夫です。「オンコール体制をこれから設計する」と正直に伝え、「その設計を任せたい」とポジショニングすると、裁量を魅力に感じるSRE経験者は多いです。隠す方がリスクで、入社後のギャップは早期離職に直結します。

Q6. SRE採用で有効な転職媒体は？

LinkedIn、Forkwell、Findy、LAPRAS、転職ドラフトなど技術者特化型プラットフォームが有効です。ただし最も効果的なチャネルはSRE NEXTやCloudNative Days Tokyoなど技術カンファレンス経由のリファラルです。媒体経由とコミュニティ経由を並行して走らせるのが基本形です。

Q7. インフラエンジニアへのスカウト返信率の目安は？

個別化したスカウトで5〜10%が現実的なラインです。テンプレ一斉送信では1%を切ることも珍しくありません。返信率が5%未満の場合は、件名の固有名詞・技術課題の率直な開示・送信者名義（現場エンジニア/CTO）の3点を見直してください。

Q8. 採用予算が限られる場合、何から始めるべき？

副業・業務委託からの段階的採用が最有力です。月15〜30万円のスポット契約で実力者に基盤の健康診断をしてもらい、相性を確認したうえで稼働を増やす流れなら、ミスマッチのリスクとコストを同時に抑えられます。

まとめ

SRE・インフラエンジニアの採用は確かに難しい領域ですが、その難しさの多くは準備不足に起因しています。

1. 自社フェーズに合った要件定義を行い、Must要件を3つ以内に絞る

2. 市場相場に見合った報酬レンジを設定する

3. 技術スタック・SLO運用・オンコール体制を開示した求人票を作成する

4. 媒体を絞り、現場エンジニアを巻き込んだ個別化スカウトを送る

5. 正社員だけでなく副業・業務委託からの段階的採用も視野に入れる

これらの準備を丁寧に行うだけで、採用の成功確率は大きく変わります。まずは自社インフラの現状棚卸しと、90日ロードマップのDay 1〜30から始めてみてください。