プラットフォームエンジニア求人が少ない理由、SREとの違い

「プラットフォームエンジニアの求人を探しているのに、SREの求人ばかり出てきて肝心の求人票にたどり着けない」——最近の転職相談で、こう漏らす方が目立つようになりました。私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、実際にdodaで求人数を数えてみると、プラットフォームエンジニアの求人はSREの5分の1程度しかありません。今回は、この求人数の差がなぜ生まれるのかという構造的な理由と、求人票の文言からSREとの違いを見分ける実務的なチェックポイントを、現役エージェントの視点でお伝えします。

目次

1. プラットフォームエンジニア求人はSREの5分の1、dodaで見る現状
2. なぜプラットフォームエンジニアの求人がまだ少ないのか
3. ①肩書きとして定義しきれていない
4. ②SRE組織の中の一機能として存在している
5. ③社内SE・インフラエンジニア求人の中に溶け込んでいる
6. ④求人媒体側の職種カテゴリがまだ追いついていない
7. SREとプラットフォームエンジニアリング、目的の違いをおさらいする
8. IDPと開発者体験、求人票に出てくる頻出語
9. 求人票でSREとPEを見分けるチェックリスト
10. 実例、二通のスカウトの中身がほぼ同じだったKさんのケース
11. SREからプラットフォームエンジニアへ、キャリアチェンジの動き方
12. プラットフォームエンジニアの年収相場
13. よくある疑問に答えます
14. インフラエンジニアからプラットフォームエンジニアを目指すのは遠回りですか
15. 「プラットフォームエンジニア」を名乗る求人が今後増える見込みはありますか
16. SREとプラットフォームエンジニア、両方の経験があると評価されますか
17. 求人が少ない今のうちに応募するのは狙い目ですか
18. まとめ、肩書きより求人票の中身で判断する

プラットフォームエンジニア求人はSREの5分の1、dodaで見る現状

まず数字から見ていきます。2026年9月時点でdodaを「SRE」というキーワードで検索すると、該当求人は685件でした。同じサイトで「プラットフォームエンジニア」を検索すると134件です。求人サイトの掲載数はキーワードの表記ゆれや掲載期間で日々変動するため絶対的な指標ではありませんが、同じ日・同じサイトで比較した数字として、求人数がおよそ5倍違うという事実は押さえておく価値があります(doda「SRE」求人検索結果、doda「プラットフォームエンジニア」求人ページ)。

年収レンジも見てみると、プラットフォームエンジニアの求人は300万円台から2,350万円まで幅があります。私の担当領域で見ても、企業側が「プラットフォームエンジニア」という肩書きをどこまでの職責と紐づけているかがまちまちで、若手のインフラ運用担当に付けている企業もあれば、基盤全体の設計権限を持つポジションに付けている企業もあります。同じ肩書きでもレンジがここまで開くのは、求人数がまだ少なく相場が固まっていないことの裏返しだと私は見ています。

こうした「肩書きが先に広まり、求人票の定着が後から追いつく」現象自体は、今回が初めてではありません。数年前の「DevOpsエンジニア」という肩書きも、概念が浸透し始めた当初は求人票にほとんど登場せず、実態はインフラエンジニアや開発エンジニアの求人の中に業務内容として溶け込んでいました。プラットフォームエンジニアという肩書きも、同じ経路をたどっている途中だと考えると、求人数の少なさにも説明がつきます。

多くの解説記事は、ここでSREとプラットフォームエンジニアの目的の違い(信頼性か開発者体験か)を説明して終わります。ですが求職者が知りたいのは概念の違いより、なぜこの肩書きの求人がまだ少ないのか、そして今出ている求人票をどう見分ければいいのか、という実務的な話のはずです。ここから先はその2点に絞って書いていきます。

なぜプラットフォームエンジニアの求人がまだ少ないのか

求人が少ない理由を、採用担当者や現場のマネージャーとやり取りしてきた実感から4つに整理します。

①肩書きとして定義しきれていない

プラットフォームエンジニアリングという考え方自体、国内で広く語られるようになったのはここ数年のことです。採用側の人事も現場のマネージャーも、この肩書きで求人票を書いた経験がまだ少なく、募集要項に落とし込む段階で「結局これはSREの求人と何が違うのか」を社内で説明しきれないまま、慣れている「SRE」や「インフラエンジニア」という肩書きに寄せてしまうケースをよく見ます。

私が求人票の作成を手伝う場面でも、企業側の担当者から「プラットフォームエンジニアという肩書きで出して、応募が集まらなかったらどうするか」という不安を聞くことが少なくありません。認知度の低い肩書きで求人を出すこと自体がリスクだと感じられているため、実績のある「SRE」やより広い「インフラエンジニア」という枠で母集団を確保し、面接の中で実際の業務内容(基盤整備が中心であること)を説明する、という進め方を取る企業が今のところ多数派です。

②SRE組織の中の一機能として存在している

国内の事業会社では、CI/CDや共通基盤の整備を専任チームとして独立させるのではなく、SRE組織の中の一つの役割として抱え込んでいる会社が多いという実感があります。この場合、業務内容としてはプラットフォームエンジニアリングそのものでも、求人票の肩書きは「SRE」のまま出ることになります。肩書きと実態が一致していないという状態が、求人数の差としてそのまま数字に表れていると私は考えています。

実際に採用担当者と話していても、「うちのSREチームの中に、基盤整備専任の人間が2人いる」という説明を受けることがよくあります。その2人を独立した「プラットフォームエンジニア」として募集すればいいはずですが、社内の職種等級や評価制度がSREという肩書きに紐づいているため、切り出すこと自体が人事制度上の手間になり、結局そのままSREの求人として出す、という判断がされているのが実情です。

③社内SE・インフラエンジニア求人の中に溶け込んでいる

もう一つ見落とされがちなのが、社内SEやインフラエンジニアの求人票の中に、プラットフォームエンジニアリング的な業務が「歓迎スキル」として埋もれているケースです。「開発チームが使う共通基盤の整備経験があれば尚可」のような一文がインフラエンジニア求人の後半に添えられているだけで、独立した求人カテゴリとしては検索に引っかかってこない。求人サイトのキーワード検索だけで市場規模を判断すると、実態より過小に見えてしまう構造がここにあります。

私が担当した案件でも、求人票のタイトルは「インフラエンジニア(クラウド基盤運用)」だったのに、実際にヒアリングしてみるとCI/CDテンプレートの整備や開発者向けドキュメントの作成が業務時間の半分以上を占めていた、というケースがありました。企業側にとってはインフラエンジニアの延長という認識でも、候補者から見ればプラットフォームエンジニアリングそのものの仕事です。求人票の検索に引っかからないだけで、業務の実態としては既に存在しているというのが私の実感です。

④求人媒体側の職種カテゴリがまだ追いついていない

求人サイト側の事情も見逃せません。多くの転職サイトでは職種を選択式のカテゴリから選ぶ仕組みになっており、「プラットフォームエンジニア」という独立したカテゴリがまだ用意されていないサイトも少なくありません。企業の採用担当者が実態に近い肩書きで求人票を書こうとしても、カテゴリ選択の段階で「インフラエンジニア」や「SRE」を選ばざるを得ない、という媒体側の制約もまた、検索結果に出てくる求人数を実態より少なく見せている一因だと考えています。

SREとプラットフォームエンジニアリング、目的の違いをおさらいする

見分け方に入る前に、目的の違いを簡潔に整理しておきます。SREは信頼性(Reliability)の維持が軸で、SLI/SLOやエラーバジェットという指標を使い、システムが落ちない・落ちてもすぐ戻せる状態を作る仕事です。プラットフォームエンジニアリングは開発者の生産性・開発者体験(DevEx)が軸で、開発チームが自分たちでインフラを扱えるようにするための共通基盤やツールを整える仕事です(SREとPlatform Engineerの違いを3つのポイントで理解する／スリーシェイク)。

どちらもDevOpsが掲げる「開発と運用の壁をなくす」という原則を実装するための手段であり、対立する概念ではありません。DevOpsが目指す姿を思想として、SREがその信頼性の側面を担い、プラットフォームエンジニアリングが開発生産性の側面を担う、という三者関係で整理すると分かりやすいと私は考えています。実務では両者が同じチームに同居し、同じエンジニアがオンコール対応と基盤整備の両方を担当している会社も珍しくないというのが私の実感です。この重なりの大きさこそが、求人票の肩書きが揺れる最大の原因だと考えています。

簡単に対比を表にまとめておきます。

IDPと開発者体験、求人票に出てくる頻出語

プラットフォームエンジニアリングの求人票を読み解く上で押さえておきたいのが、内部開発者プラットフォーム(IDP:Internal Developer Platform)という言葉です。開発者が自分でサービスをデプロイしたり、必要なリソースを申請したりできるセルフサービス型の基盤を指します。DevOpsやSREを実践した先で、ツールがチームごとにサイロ化し、開発者一人ひとりの認知負荷がかえって増えるという課題が生まれ、その解決策としてプラットフォームエンジニアリングという考え方が広がった、というのがこの言葉が生まれた経緯です。

求人票では「開発者ポータルの構築」「セルフサービス化」「トイル削減による開発者体験の向上」といった表現でこの領域が語られます。開発者ポータルの具体例としてはBackstageのようなOSSを使ったカタログ整備が挙げられ、その裏側でTerraformモジュールを共通化してセルフサービスのインフラ申請を実現する、という組み合わせが実務ではよく見られます。この言葉が歓迎要件に入っているかどうかは、次の見分け方チェックでも重要な判断材料になります。

求人票でSREとPEを見分けるチェックリスト

抽象的な「信頼性か生産性か」という対比だけでは、実際の求人票を前にしたときに判断がつきません。私が求人票を読むときに見ている、具体的な文言ベースのチェックポイントを挙げます。

実際の求人票は、必須要件欄にSRE寄りの文言が並び、歓迎スキル欄にIDP関連の文言がぽつんと入っているというパターンが最も多いというのが私の実感です。この場合、業務の中心はSRE寄りで、プラットフォームエンジニアリング的な仕事はまだ会社の中で立ち上げ途中だと読むのが妥当です。逆に、必須要件からしてIDPや開発者ポータルの話が中心なら、独立したプラットフォームチームとして採用予算が確保されている可能性が高いと判断しています。

ポイント： 肩書きよりも、必須要件欄の一文目に何が書かれているかを見る。オンコールの話が先に来るか、開発者向け基盤の話が先に来るかで、実態はかなり読み分けられます。

求人票の文言だけで判断がつかないときは、面談・面接の場で次のような質問を投げると、実態がかなりはっきりします。

この3つに具体的な数字や進捗で答えられる会社は、肩書きが何であれ実態が伴っている可能性が高いと判断しています。逆に「今後やっていきたい」という将来形の答えしか返ってこない場合は、その肩書きの業務がまだ立ち上がっていないと見た方が安全です。

実例、二通のスカウトの中身がほぼ同じだったKさんのケース

同じ週に届いた二通のスカウトメールを並べて見比べたところ、件名は一方が「SRE」、もう一方が「プラットフォームエンジニア」なのに、業務内容の説明文がほとんど同じだった——そんな戸惑いを相談してきたのが、独立系SIerのインフラ運用チームに所属していたKさん(35歳・経験10年)でした。

Kさんはオンプレのサーバ・ネットワーク運用を長く担当しており、クラウド基盤の運用経験を積みたいと考えて複数社に登録していました。届いた二通のスカウトはどちらも決済系のシステムを持つ自社開発企業からで、文面だけでは違いが判断できず、どちらの面談を優先すべきか決めかねている状態でした。

そこで私が提案したのは、二社の求人票を並べて、先ほどのチェックリストの文言がどちらの欄に出てくるかを照らし合わせることでした。「SRE」と名乗る求人の方は、必須要件の一文目からIDPと開発者ポータルの話が続き、オンコールは歓迎スキル欄の最後に一行あるだけでした。一方「プラットフォームエンジニア」と名乗る求人は、必須要件がオンコール対応・障害対応の実務経験で埋まっていて、IDPの話は「将来的に取り組む予定」という歓迎スキル欄の記述にとどまっていました。

Kさんは当初、肩書きの印象通りに「プラットフォームエンジニア」の方を本命として準備を進めようとしていました。オンプレ運用の経験を基盤整備の実績として語る想定でいたためです。私から「必須要件を先に読むと、この会社が今求めているのはオンコール対応の即戦力の方に見える」と伝えたところ、Kさんも求人票を読み返して「たしかに、開発者向けの話は最後の一行だけですね」と納得した様子でした。

面談で深掘りの質問をしてもらった結果、この読み方はそのまま裏付けられました。「SRE」と名乗る会社の担当者は、面談の冒頭から開発者ポータルの構築計画を熱心に語り、逆に「プラットフォームエンジニア」の会社は当面の課題としてオンコール体制の立て直しを挙げていました。肩書きの通りに準備していたら、力を入れる先を取り違えるところだったとKさん自身も振り返っています。最終的にKさんは、IDP整備の裁量が大きかった「SRE」求人の方に進み、基盤構築の経験を積める配属を条件に交渉した上で内定を受けました。肩書きを鵜呑みにせず、求人票の中身で判断したことが結果につながった例だと思います。

このようなズレは、スカウト経由の求人で特に起こりやすいというのが私の実感です。スカウトはキーワードマッチングで候補者に送られる仕組みのため、送信側の企業が「SRE」「プラットフォームエンジニア」の両方の肩書きで求人票を登録していたり、採用担当者が候補者の経歴に合わせて件名の肩書きだけを書き換えていたりすることがあります。件名の肩書きは検索や母集団形成のための表示に過ぎず、業務の実態を保証するものではないと考えておいた方が安全です。

SREからプラットフォームエンジニアへ、キャリアチェンジの動き方

SREとして働きながらプラットフォームエンジニアリングに寄せていきたい場合、社外に転職する前に、まず今の会社の中でトイル削減や共通基盤整備にどれだけ工数を割けているかを振り返ることを勧めています。オンコール対応に追われる日々が「SRE求人の名ばかり実態」と重なる部分は多く、以前この記事でも触れた通り、トイル削減にどれだけ時間と予算が配分されているかが、そのままキャリアの伸びしろに直結します。

転職活動で職務経歴書を書く際は、障害対応の実績だけでなく、共通化・自動化によってチーム全体の作業時間をどれだけ減らしたかという定量的な成果を前面に出すことが重要です。「オンコール対応◯件」ではなく「自動復旧の仕組みを整備し、夜間呼び出しを月◯件から◯件に減らした」のように、開発者体験を改善した実績として語り直すと、プラットフォームエンジニアの求人票の言葉に合いやすくなります。

なお、待遇面を比較する際はオンコール手当の織り込み方によって実質的な負担が大きく変わる点にも注意が必要です。こちらの記事で計算式を紹介していますが、肩書きが変わっても待遇を実質時給で比較する考え方はそのまま使えます。

プラットフォームエンジニアの年収相場

年収相場については、まだ求人数自体が少ないため相場と呼べるほどのデータが蓄積されていないのが正直なところです。それでも私が担当してきた案件の傾向を挙げると、若手〜中堅(経験5〜8年程度)で550万〜750万円、基盤設計の責任者クラスになると900万円を超える提示も見てきました。SREの相場とほぼ重なるレンジですが、上振れの幅がSREよりやや大きい印象があります。

doda掲載の求人でも、企業ごとのオファー例として600万〜900万円、あるいは645万〜1,411万円といった幅広いレンジが並んでいます。同じ「プラットフォームエンジニア」という肩書きでも、企業によって求める職責の重さがここまで違うということです。求人票だけでレンジの妥当性を判断せず、面談で任される権限の範囲(基盤の設計から関わるのか、既存の仕組みの運用が中心なのか)を必ず確認するようにしてください。

相場がまだ固まっていないということは、企業側も「いくら出せば採用できるのか」を手探りで決めている段階だということでもあります。求人票のレンジ下限で提示されても、基盤設計から任される裁量があるなら、その実績を積んだ上で次の転職で相場を追いかける、という2段階の戦略も十分に成立すると私は考えています。

これは、プラットフォームエンジニアという肩書きで採用する企業ほど、開発生産性の向上という経営レベルの課題に直接紐づけて採用予算を確保しているケースが多いためだと見ています。裏を返せば、求人票の必須要件が薄い割に年収レンジだけ高い場合は、期待値と実際の裁量が釣り合っていない可能性もあるため、面談で任される範囲を具体的に確認することをお勧めします。

よくある疑問に答えます

インフラエンジニアからプラットフォームエンジニアを目指すのは遠回りですか

遠回りにはなりません。むしろオンプレ・クラウド双方の運用経験は、共通基盤を設計する上での土台になります。ただし求人票の必須要件にCI/CDやIaCの経験が明記されている場合は、実務でどこまで触れているかを具体的に説明できるようにしておく必要があります。

「プラットフォームエンジニア」を名乗る求人が今後増える見込みはありますか

増えると見ています。DevOpsやSREを実践した企業が次に直面するのが、ツールのサイロ化と開発者の認知負荷の増大という課題で、この解決策としてプラットフォームエンジニアリングを掲げる企業が国内でも徐々に増えている実感があります。ただし肩書きが先に広まり、実態が追いつかない求人票もしばらく混在すると見ておいた方がいいでしょう。

SREとプラットフォームエンジニア、両方の経験があると評価されますか

評価されます。オンコール対応の実務と基盤整備の両方を語れる人材は、採用側にとって組織設計の柔軟性が高く見えるためです。ただし職務経歴書で両方を並べる際は、どちらの比重が大きかったかを明確にしないと、器用貧乏な印象を与えてしまうこともあるので注意してください。

求人が少ない今のうちに応募するのは狙い目ですか

狙い目だと考えています。求人数が少ないぶん競合となる応募者も限られており、SRE経験を基盤整備の言葉に翻訳して出せる人材はまだ市場に多くありません。相場が固まりきっていない今の時期は、面談での交渉次第でレンジの上振れを引き出しやすいという側面もあります。ただし前述の通り、求人票の必須要件が薄い割に年収だけ高い案件には注意し、任される裁量を面談で具体的に確認してから進めることをお勧めします。

まとめ、肩書きより求人票の中身で判断する

プラットフォームエンジニアの求人がまだ少ないのは、需要がないからではなく、肩書きとして定義・切り出しが追いついていないからです。SRE組織の一機能として、あるいは社内SE・インフラエンジニア求人の歓迎スキル欄として、実態は既にあちこちに存在しています。求人票の肩書きだけを頼りに検索していると、この求人を見落とすことになります。

概念解説だけを読んで「信頼性か生産性か」という対比を覚えても、目の前の求人票をどちらだと判断すればいいかは分かりません。必須要件欄の一文目に何が書かれているかで、その求人の実態はかなり読み分けられます。オンコールと障害対応が先に来るか、IDPと開発者ポータルの話が先に来るか。この記事で紹介したチェックリストと質問例を手元に置いて、肩書きではなく求人票の中身で判断する視点を持ってもらえればと思います。求人数がまだ少ない今だからこそ、その見極めができるかどうかが、応募先を選ぶ精度の差になります。