Platformエンジニア転職ガイド｜内部基盤とGolden Path

Platformエンジニアは、開発者がプロダクト開発に集中できるよう、内部プロダクトとしてポータル、テンプレート、Golden Path、セルフサービスAPIを提供する職種です。このページはSREの職種・テーマの信頼性運用やDevOpsの職種・テーマのCI/CD全般と重複しないよう、「開発者向け内部基盤」に焦点を当てます。Kubernetesクラスタそのものの運用詳細はKubernetes一般、インフラ全般はインフラエンジニアを参照し、Platform固有のプロダクト思考と提供範囲を求人票から読み替えます。

Internal Developer Platform（IDP）

開発者がインフラ・ツール・テンプレートをセルフサービスで利用する内部基盤。Portal、API、テンプレートカタログを含む。

Golden Path

推奨される標準的な開発・デプロイの道筋。テンプレート、ドキュメント、サポート範囲がセット。Platformチームが提供・更新する。

Platform as Product

内部ユーザ（開発者）向けにプロダクト開発と同様に要件定義、ロードマップ、フィードバックを行う考え方。

セルフサービスプロビジョニング

開発者が申請するだけで環境・Namespace・DB等が払い出される仕組み。PlatformがAPI/Portalで提供する典型機能。

PlatformエンジニアはDevOps（パイプライン）、SRE（本番信頼性）、Kubernetes運用（クラスタ）、クラウド基盤（ネットワーク）と隣接しますが、このページは「開発者が使う内部プロダクト」の設計・提供に限定します。PagerDuty運用やSLO設計そのものはSREの職種・テーマ、汎用CI/CDはDevOpsの職種・テーマへ任せ、PlatformはGolden PathとDeveloper Experience（DX）の語彙で切り分けます。

Platformエンジニアの役割比較では、「軸」は「提供物」、「Platformエンジニア」は「IDP、Golden Path、テンプレート」、「隣接ロール」は「単一CI/CDパイプライン（DevOps）」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの役割比較では、「軸」は「ユーザー」、「Platformエンジニア」は「社内開発者」、「隣接ロール」は「エンドユーザー（プロダクト）」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの役割比較では、「軸」は「成功指標」、「Platformエンジニア」は「DX、テンプレート採用率、セルフサービス率」、「隣接ロール」は「SLO/エラーバジェット（SRE）」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの役割比較では、「軸」は「Kubernetes」、「Platformエンジニア」は「抽象化して提供」、「隣接ロール」は「クラスタ自体の運用（K8s運用記事）」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの役割比較では、「軸」は「オンコール」、「Platformエンジニア」は「Platform障害が主（場合による）」、「隣接ロール」は「全サービス本番障害（SRE）」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platform求人票では、IDPの機能範囲、テンプレートのバージョン管理、開発チームへのRollout、内部SLAの有無が曖昧です。以下の表で、書いてあること・確認したい実態・面談質問例を整理します。

Platformエンジニアの求人票の読み替えでは、「書いてあること」は「Platform Engineering」、「確認したい実態」は「IDP開発か運用保守か」、「面談での質問例」は「Backstage等の機能で自分がオーナーな項目は？」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの求人票の読み替えでは、「書いてあること」は「Golden Path」、「確認したい実態」は「テンプレート数と更新頻度」、「面談での質問例」は「Path未採用チームへの支援方針は？」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの求人票の読み替えでは、「書いてあること」は「Terraform/K8s」、「確認したい実態」は「開発者向け抽象化か」、「面談での質問例」は「開発者がRaw manifestを触れるか？」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの求人票の読み替えでは、「書いてあること」は「DevOps協業」、「確認したい実態」は「PlatformとDevOpsの分界」、「面談での質問例」は「CI/CDパイプラインは誰が所有？」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの求人票の読み替えでは、「書いてあること」は「SRE協業」、「確認したい実態」は「Platform SLAの有無」、「面談での質問例」は「Platform障害時のエスカレーション先は？」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

Platformエンジニアの求人票の読み替えでは、「書いてあること」は「プロダクト思考」、「確認したい実態」は「ロードマップとユーザーヒアリング」、「面談での質問例」は「四半期ごとのPlatform KPIは？」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

• IDPまたはGolden Pathを提供・改善したか
• 開発者向けセルフサービスAPI/Portalに関与したか
• テンプレートのバージョン管理とRolloutをしたか
• PlatformとDevOps/SREの責任分界を説明できるか
• 内部ユーザーヒアリングやドキュメント整備をしたか

確認ポイントは「IDPまたはGolden Pathを提供・改善したか」です。Platformエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「開発者向けセルフサービスAPI/Portalに関与したか」です。Platformエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「テンプレートのバージョン管理とRolloutをしたか」です。Platformエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「PlatformとDevOps/SREの責任分界を説明できるか」です。Platformエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「内部ユーザーヒアリングやドキュメント整備をしたか」です。Platformエンジニアの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

Platformエンジニアでは、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。

1. 01
   Platform提供物を一覧化

   Portal、テンプレート、API、ドキュメント、サポート時間帯を箇条書きし、自分がオーナーだった項目に印を付けます。

2. 02
   Golden Path実例を一般化

   標準デプロイ手順、推奨監視設定、セキュリティスキャン組込みなど、Pathに含めた要素を秘密情報を除いて記述します。

3. 03
   DevOps/SRE境界メモ

   DevOps/SREのチェック項目と照合し、重複する経歴はPlatform視点（開発者提供）で言い換えます。

4. 04
   IDP機能の質問リスト

   Catalog、Scaffolder、TechDocs等、利用ツールの機能で担当範囲を面談で確認する質問を作ります。

Platform設計は、CNCF Platform Engineering Whitepaperや各社公開のPlatform事例、利用するIDP（Backstage等）の公式ドキュメントを参照します。内部プロダクトなので公開情報は限られますが、提供機能の公式説明と自分の関与範囲を対応づけてください。

Platformエンジニア転職ガイド｜内部基盤とGolden Pathの判断材料は、出典が公開されている情報に限ります。媒体ごとの求人数や平均年収は集計定義が違うため、求人票や公式サイトの最新情報で確認してください。内定や年収アップは保証できません。提示された労働条件は書面で確認し、口頭の話だけを契約内容にしないでください。

Platform案件は名称だけでは中身が異なります。「Golden Path提供とIDP機能開発が主」と伝え、DevOps/SRE案件と同一求人へ重複応募しないよう一覧管理してください。

• クラウド×開発者体験に強いエージェント

  Platform案件の実態（IDPかDevOpsか）を整理してくれる担当者を選ぶとミスマッチが減ります。

• インフラからPlatformへの相談

  インフラエンジニアの経験をPlatformにどう言い換えるか、相談先と一緒にメモを作成するとよいです。

• Product/DevOps横断相談

  内部プロダクト思考の説明に慣れたエージェントに、Golden Path実例の一般化を手伝ってもらえます。

相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。

• DevOps経験をすべてPlatformと書く

  パイプライン構築だけではPlatformとは限りません。開発者向け提供物を分けて記載してください。

• Golden Pathを「標準化した」とだけ書く

  何を標準化し、開発者が何をセルフサービスで得るかまで書けると求人との一致度が上がります。

• SREのオンコール実績をPlatform実績と混同

  Platform障害対応と全サービスSREオンコールは別です。対象システムを明示してください。

応募前1週間は、内部プロダクトとしてのPlatform定義、Golden Path実例の整理、IDP機能リストの質問作成、DevOps/SREの職種・テーマとの境界確認の順で進めてください。

1. 01
   月：Platform Engineering資料を読む

   CNCF等の公開Whitepaperで用語を固定し、自分の経験に対応づけます。

2. 02
   火：求人3件でIDP/Golden Path確認

   DevOps/SRE求人と名称が似ていないかも併せて確認します。

3. 03
   水：経歴を内部プロダクト視点で推敲

   開発者数や利用チーム数など、確認できない数字は書かず、提供機能で説明します。

4. 04
   木〜金：面談でオーナーシップ確認

   Platformプロダクトオーナーが誰か、自分の関与深度を確認してから応募可否を決めます。