SRE・プラットフォーム・クラウド・インフラ｜求人票の職種名と実務の対応表

2026年9月21日

約9分で読めます

「SRE」と書かれた求人でも、障害対応が主の会社と、基盤改善が主の会社が混在します。肩書きの一致より先に、目的・利用者・成果物を見ます。

前回の「転職で同じ落ち方を繰り返さない｜ラウンド終了の検証ログ」では、ラウンド終了を検証 1 単位にしました。今回は応募前に、職種名と実務のずれを対応表で見つけます。特定サービスの紹介はしません。

前回から今回への差分

前回完了時	今回完了後
落ち方は仮説1つと変更1つで残る	職種名ではなく目的・利用者・成果物で役割を見る
応募先の肩書きはまだ読み分けない	構築・運用・改善・調整の対応表と確認質問を持って面談に入る

4 職種の違いがすでに腹落ちしている場合は、「4 つの職種を目的・利用者・成果物で整理する」を飛ばせます。対応表の型だけ欲しい場合は、導入を短く読んで付属表へ進みます。

なぜ職種名の次に実務を見るのか

求人票の肩書きは、社内の呼び方です。Google の SRE Book は、SRE を「ソフトウェアエンジニアに運用チームを設計させたときに起きること」と説明しています。同じ「SRE」でも、運用負荷の上限や改善の比重は会社ごとに違います。

CNCF の Platforms White Paper は、プラットフォームを内部顧客（開発者など）向けの能力の束として定義しています。求人票に「プラットフォーム」とあっても、社内の開発者向け土台なのか、クラウド基盤そのものなのかは、記載だけでは決まりません。

先に分けるのは次の 2 つです。

求人票から分かる事実（記載されている業務・必須条件・チーム名）
まだ分からないこと（比率、優先順位、他チームとの境界）

業務比率を勝手に数値化しません。分からないセルは仮説のまま残し、面談の質問に変えます。How（表の埋め方）はその後です。

用語表

用語	この記事での意味
職種名	求人票に書かれた肩書きです
実務	実際に担う構築・運用・改善・調整の範囲です
対応表	職種名と実務を並べ、ずれを見つけるための表です
仮説	求人票の記載から立てる推測です。断定ではありません
トイル	手作業で繰り返し、自動化でき、サービス拡大に比例して増える運用作業です（SRE Book の定義）

構成図

求人票の職種名
        │
        ▼
目的・利用者・成果物を1行で書く
        │
        ▼
構築 / 運用 / 改善 / 調整 の対応表
        │
        ├── 記載がある → 事実として残す
        └── 空欄・比率不明 → 仮説のまま質問化する
        │
        ▼
面談で「最近の案件を1つ」聞く
        │
        ▼
希望の時間の使い方と照合する

4つの職種を、目的・利用者・成果物で整理する

ここでは読み方の枠です。会社によって境界は重なります。

職種名（求人でよく見る呼び方）	目的の向き	主な利用者	成果物の例
インフラ	基盤を安定して使える状態にする	社内の開発・運用全体	基盤設計、構築手順、監視の土台
クラウド	クラウド上の基盤・サービスを設計・運用する	開発チーム、基盤利用者	IaC、権限設計、コストと可用性の設計
プラットフォーム	開発者が速く安全に届ける土台を整える	開発者（内部顧客）	共通基盤、デプロイ経路、開発者向け文書
SRE	信頼性を測り、改善と運用を回す	サービス利用者・開発・運用	SLO、インシデント対応、改善バックログ

重なりの例です。クラウド上の基盤改善は、クラウド／プラットフォーム／ SRE のどれにも書かれます。だから職種名の次に、目的・利用者・成果物を見ます。

Google の運用負荷の目安は、SRE の時間のうち運用（チケット、オンコール、手作業）を合計 50 ％以下に抑える、という上限です。求人票にこの数字が無いなら、自社の比率として補いません。面談で「運用と改善のどちらが多いか」を聞きます。

構築・運用・改善・調整を実務の対応表に落とす

次の表は、求人票を読むときのたたき台です。空欄は面談で埋めます。セルは「主／副／なし／不明」で足ります。

付属: 職種と実務の対応表（コピー用）

実務の軸	インフラ	クラウド	プラットフォーム	SRE	自分の希望（書く）
構築（新規・更新）
運用（監視・障害・定常）
改善（自動化・削減・品質）
調整（他チーム・優先順位）

記入の目安は一般例です。会社により異なります。

実務の軸	よく載る内容の例（仮説）
構築	設計、構築、移行、IaC、権限設計
運用	監視、オンコール、障害対応、定常変更
改善	トイル削減、自動化、性能、コスト、信頼性改善
調整	開発との分担、優先順位、インシデント後の合意

架空の例です。「SRE」と書いてあっても、改善より運用比率が高い求人もあります。実在企業の内部比率ではありません。

不明セルを質問に変える

分かる事実と、まだ分からないことを分けます。

分かる事実（記載があるもの）	まだ分からないこと（勝手に埋めない）
必須・歓迎の技術名	週あたりの運用と改善の比率
チーム名・募集人数	オンコールの頻度と補償の詳細
記載された業務箇条	「プラットフォーム」が社内で指す範囲
出社・リモートの条件	入社直後に求められる初期成果

確認事項の作り方は単純です。対応表で「不明」にしたセルを、質問文にします。推測で埋めません。

次のコマンドは、架空の 4 セルを「不明」判定する例です。リポジトリは不要です。python3 があれば同じ出力になります。

python3 -c 'cells=[("構築","不明"),("運用","主"),("改善","不明"),("調整","なし")]; unknown=[n for n,v in cells if v=="不明"]; print("不明セル数:", len(unknown));
[print("質問化:", n) for n in unknown]; print("面談に持っていく:", "yes" if unknown else "no")'

2026-09-21 に実行した出力は次のとおりです。

不明セル数: 2
質問化: 構築
質問化: 改善
面談に持っていく: yes

不明セル数: 0 なら、職種の読み分けは一通り終わっています。残るのは希望との照合です。

面談で実際の担当範囲を確かめる質問

そのまま読んでも、自分の言葉に直しても構いません。

直近 1 か月で、いちばん時間がかかった仕事は何ですか。
構築・運用・改善・調整のうち、いまのチームで比率が高いのはどれですか。
開発チームとの分担は、どこで切れていますか。
入社後 3 か月で期待される成果は何ですか。
同じ職種名の人でも、担当が分かれている場合はどう分かれていますか。

答えが抽象的なら、「最近の案件を 1 つだけ」と具体例を頼みます。

自分が担いたい役割と求人を照合する

最後に、希望と避けたい負担を書き、対応表を完成させます。

項目	自分の記入
増やしたい実務（構築／運用／改善／調整）
減らしたい実務
求人票で一致している点
面談で確認する点（不明セル）
応募する／保留／見送り

照合のコツは、職種名の一致より、日常の時間の使い方の一致を見ることです。私は「改善を増やしたい」と書いてあるのに、求人の箇条が障害対応ばかりなら、保留にします。

よくあるエラー

症状	よくある原因	直し方
全部の職種に応募したくなる	境界の重なりを無視している	目的・利用者・成果物で1行ずつ書く
面談で何を聞くか決まらない	「不明」を推測で埋めている	不明セルを質問に変える
業務比率を数字で決めつける	求人票に無い数値を補っている	事実と仮説を分ける
Google の 50 ％上限を相手に当てはめる	自社の運用を一般化する	相手の直近 1 か月の時間の使い方を聞く

飛ばせる章

いまの状態	飛ばせる章
4 職種の違いがすでに腹落ちしている	「4 つの職種を、目的・利用者・成果物で整理する」
対応表の型だけ欲しい	導入と Why を短く読み、付属表へ
質問文だけ欲しい	「面談で実際の担当範囲を確かめる質問」

やらないこと

年収煽りや「これで受かる」断定
特定転職サービスの売り込み
実在企業の内部比率の創作
架空例を実績として書くこと

出典

主張・型	出典	扱い
SRE はソフトウェアエンジニアが運用チームを設計した結果、という説明。運用負荷の 50 ％上限	Google SRE Book / Introduction	定義と上限の一次情報。求人の比率には使わない
トイルは手作業・繰り返し・自動化可能・線形に増える運用作業	Google SRE Book / Eliminating Toil	「改善」と「運用」を分ける語彙
プラットフォームは内部顧客向けの能力の束	CNCF Platforms White Paper	「プラットフォーム」求人の読み方。導入範囲の断定には使わない

まとめ

職種名は入口です。実務は、構築・運用・改善・調整の対応表で読みます。分からないことは仮説のまま残し、面談の質問に変えます。

この記事を書いた人

hibana

技術ブログを運営しています。日々の学びや発見を発信中。