プラットフォームエンジニア採用ガイド｜要件定義から選考・口説き方まで

プラットフォームエンジニアの採用を成功させる鍵は、①SRE・インフラエンジニアとの役割の違いを整理した要件定義、②IDP（Internal Developer Platform）の構想を具体的に示す求人票・スカウト、③経験者の少なさを前提にした隣接職種からのコンバート採用——この3点です。市場に経験者が極めて少ない職種のため、「経験者を探す」のではなく「素養を持つ人材を見極めて育てる」設計が現実的な最短ルートになります。

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

• プラットフォームエンジニアリングはGartnerが2026年までに80%の大規模ソフトウェア組織が専任チームを持つと予測した注目領域。採用需要は急拡大中

• SREやインフラエンジニアとの違いを正しく理解し、「開発者体験の向上」を軸にした要件定義が採用成功のカギ

• 年収相場はミドルで650〜950万円、シニアで950〜1,400万円。IDP構築やKubernetes運用の経験があると上振れする

• 求人票にはIDPの構想・技術スタック・開発者との関わり方を具体的に書くと候補者の関心を引きやすい

• 市場に経験者が極めて少ないため、SRE・インフラ・バックエンドからのコンバートを前提とした採用設計が現実的

プラットフォームエンジニアリングとは何か——なぜ今、採用が必要なのか

プラットフォームエンジニアリングとは、社内開発者向けのセルフサービス基盤（IDP）を設計・構築・運用する専門領域であり、開発組織のスケーリングに伴う生産性低下を解決する役割を担います。「開発チームのデプロイ待ちが長い」「インフラチームがボトルネックになっている」「新しいサービスを立ち上げるたびに同じ構築作業を繰り返している」——こうした課題を抱える組織で、いま最も採用ニーズが伸びている職種のひとつです。

プラットフォームエンジニアリングの定義

プラットフォームエンジニアリングとは、社内の開発者が自律的にインフラを利用できるようにするための基盤（Internal Developer Platform / IDP）を設計・構築・運用する専門領域です。

従来のインフラチームが「依頼を受けて環境を構築する」受動的な役割だったのに対し、プラットフォームエンジニアは「開発者がセルフサービスで使える仕組み」を能動的に作ります。いわば、社内向けのプロダクトを開発するエンジニアです。

Gartnerは「2026年末までに大規模ソフトウェア組織の80%がプラットフォームエンジニアリング専任チームを設置する」と予測しています（2022年時点では45%）。日本でも、メルカリ、サイバーエージェント、LINEヤフーなどの大手テック企業がプラットフォームチームを設置しはじめており、スタートアップにとっても無関係ではなくなってきました。

なぜ今、採用ニーズが高まっているのか

プラットフォームエンジニア採用の需要が急増している背景には、いくつかの構造的な要因があります。

エンジニア採用市場の統計データ：

• Gartnerは「2026年末までに大規模ソフトウェア組織の80%がプラットフォームエンジニアリング専任チームを設置する」と予測（2022年時点では45%）

• doda「転職求人倍率レポート（2026年5月）」によると、IT・通信の求人倍率は10.68倍と全職種平均を大きく上回る

• 経済産業省「IT人材需給に関する調査（2019年）」では、2030年に最大79万人のIT人材が不足すると推計

開発組織のスケーリング問題

エンジニアが10人から30人、50人と増えていく過程で、「環境構築のやり方がチームごとにバラバラ」「デプロイの手順が属人化している」といった問題が顕在化します。プラットフォームチームはこの混乱を標準化する役割を担います。

クラウドネイティブ技術の複雑化

Kubernetes、サービスメッシュ、GitOps、IaCツールの多様化——クラウドネイティブ技術のエコシステムは年々複雑さを増しています。アプリケーション開発者がこれらを全て理解して使いこなすのは現実的ではなく、抽象化レイヤーを提供するプラットフォームチームの存在が不可欠になってきました。

開発者体験（DevEx）への投資トレンド

開発者体験が生産性とリテンションに直結するという認識が広まり、「開発者が気持ちよく開発に集中できる環境」を整備する投資が増えています。プラットフォームエンジニアリングは、この開発者体験（DevEx）向上の中核を担う存在です。

SRE・DevOps・インフラエンジニアとの違いを正しく整理する

プラットフォームエンジニアとSRE・DevOpsエンジニアの最大の違いは、IDPを社内プロダクトとして捉える「プロダクトマネジメント思考」の有無です。この整理ができていないと要件定義がぼやけ、候補者にも刺さりません。採用の前に、まず役割の違いを正しく押さえましょう。

役割比較マトリクス

重なりと独自性

実際の現場では、これらの役割は明確に分かれておらず、相互に重なり合っています。特にスタートアップでは「SRE兼プラットフォームエンジニア」のような兼務が一般的です。

ただし、プラットフォームエンジニアリングに特有の性質が一つあります。それは**「プロダクトマネジメント思考」**です。

プラットフォームエンジニアは、IDPを社内プロダクトとして捉え、開発者をユーザーとして扱います。ユーザーリサーチをし、フィードバックを集め、ロードマップを策定し、採用率（Adoption Rate）を追いかける。この「社内プロダクトマネージャー」的な動きが、SREやインフラエンジニアとの最大の違いです。

求人タイトルの使い分け

求人票のタイトルで迷う場合は、以下を目安にしてください。

• 基盤の安定運用が主務 → SRE / インフラエンジニア

• CI/CDパイプラインの構築・改善が主務 → DevOpsエンジニア

• 開発者向けセルフサービス基盤の構築が主務 → プラットフォームエンジニア

候補者は求人タイトルで自分に合うかどうかを一瞬で判断します。実態に合ったタイトルを選ぶことが、ミスマッチ防止の第一歩です。

自社にプラットフォームエンジニアが必要か判断する5つのシグナル

プラットフォームエンジニアの採用判断は「流行っているから」ではなく、組織のペインに照らして行うべきです。以下の5つのシグナルのうち3つ以上が当てはまるなら、採用を検討する価値があります。

1. 開発者からインフラチームへの依頼が月20件を超えている：環境構築、権限付与、デプロイ設定の変更などの依頼がインフラチームに集中し、対応が追いつかない。開発者が対応を待つ時間は、そのまま開発速度の低下につながります

2. 同じようなインフラ構成を複数チームが個別に構築している：マイクロサービス組織で特に起きやすい問題です。チームごとに異なるKubernetesマニフェストとCI/CDパイプラインが乱立しているなら、標準化テンプレートを提供するプラットフォームチームで重複作業を大幅に削減できます

3. オンボーディングに1週間以上かかっている：新しく入ったエンジニアが最初のデプロイを行うまで1週間以上かかるなら、開発基盤の整備が不十分です。オンボーディングの改善と合わせて検討しましょう。基盤が機能している組織では、初日に開発環境が自動プロビジョニングされ、数時間で最初のコードをデプロイできる状態を目指します

4. エンジニアが20人を超え始めた：組織が20〜30人を超えたあたりから標準化・セルフサービス化の必要性が急激に高まります。急成長が見込まれるなら早めに1人目を採用して基盤を整えるのは有効な投資です。エンジニア組織のスケーリング採用戦略も参考にしてください

5. 「DevOps」を掲げたが実態はインフラチームのまま：DevOpsを導入したものの「依頼を受けて対応する」構造が変わっていない——多くの企業が陥るパターンです。プラットフォームエンジニアリングはこの状態から脱却する具体的なアプローチを提供します

プラットフォームエンジニアの要件定義——スキルマトリクスの設計

採用がうまくいかない最大の原因は、要件定義のミスです。特にプラットフォームエンジニアリングは新しい領域なので、「何を求めるのか」が曖昧になりやすい。ここでは実践的なスキルマトリクスの作り方を解説します。

技術スキル：6つのコアコンピテンシー

プラットフォームエンジニアに求められる技術スキルは、以下の6領域に整理できます。

ソフトスキル：プロダクト思考とコミュニケーション

技術力だけでは不十分です。プラットフォームエンジニアには、以下のソフトスキルも不可欠です。

• プロダクトマネジメント思考：IDPを「社内プロダクト」として捉え、開発者の声を聞き、優先順位を決め、ロードマップを策定する能力。「技術的にベストなもの」ではなく「開発者が実際に使うもの」を作れるかが重要

• ドキュメンテーション力：分かりやすいドキュメント・チュートリアル・サンプルコードを作成する力は、プラットフォームの採用率に直結する

• ステークホルダーマネジメント：経営層には「投資対効果」を、開発チームには「使い方とメリット」を、適切な粒度で説明する力

フェーズ別の要件調整

組織のフェーズによって、求める人材像は大きく変わります。

候補者に刺さる求人票の書き方

プラットフォームエンジニアの求人票で最も重要なのは、IDPの現状と構想を具体的に書くことです。市場に経験者が少ないため、求人票の質がそのまま候補者獲得を左右します。「何となくSREの延長」で書いた求人票では、優秀な候補者の目に留まりません。

求人票に必ず書くべき5つの要素

1. IDPの現状と構想

最も重要なのは「何を作るのか（作っているのか）」を明示することです。

悪い例： 「社内開発基盤の構築をお任せします」

良い例： 「現在、Kubernetes（EKS）+ Terraform + GitHub Actionsで基本的なCI/CDは構築済みです。今後、Backstageベースの開発者ポータルの導入、セルフサービスでの環境プロビジョニング機能の構築、サービスカタログの整備に取り組みます」

2. 技術スタックの詳細

プラットフォームエンジニアは技術選定に強いこだわりを持つ人が多いです。「クラウドを使った開発」のような曖昧な記述ではなく、具体的なツール・バージョンまで書きましょう。

3. 開発者との関わり方

「社内の開発チーム（現在8チーム・約35名）と密にコミュニケーションを取り、四半期ごとの開発者サーベイを基にロードマップを策定します」——このように、誰とどう関わるのかを具体的に書きます。

4. 裁量と意思決定の範囲

「技術選定はプラットフォームチームの裁量で行えます」「四半期の開発計画はチーム内で策定し、CTOと合意形成します」など、どこまで自分で決められるのかを明記します。

5. 年収レンジ

後述しますが、プラットフォームエンジニアの年収相場はSREと同等かそれ以上です。相場から大きく外れたレンジを提示すると、そもそもスカウトを開いてもらえません。

スカウト文面の設計——プラットフォームエンジニアの心を動かすポイント

プラットフォームエンジニアは転職市場で積極的に動いている人が少なく、ダイレクトスカウトが主要な採用チャネルになります。スカウト文面では「技術的チャレンジの具体性」と「内製プロダクト開発の面白さ」の2点を伝えることが返信率を左右します。

スカウトで狙うべきターゲット層

プラットフォームエンジニアの肩書きで活動している人はまだ少数です。以下の隣接職種から、プラットフォームエンジニアリングへの関心が高い層を狙いましょう。

• SRE — 信頼性だけでなく開発者体験にも関心を持つ層

• インフラエンジニア — IaCやKubernetesに精通し、自動化への志向が強い層

• バックエンドエンジニア — インフラに興味があり、CI/CD改善やDevOps的な活動を自発的に行っている層

• DevOpsエンジニア — パイプライン構築だけでなく、開発者向けツール開発にも取り組んでいる層

スカウト文面のポイント

技術的なチャレンジを具体的に伝える

「プラットフォームエンジニアを募集しています」だけでは弱い。「EKS上で動く200以上のマイクロサービスのデプロイを、現在の平均15分から5分に短縮するための基盤刷新プロジェクトをリードしていただきたい」——このレベルの具体性が必要です。

候補者の経歴に紐づけたパーソナライズ

「○○さんのGitHubで公開されているTerraformモジュールのリポジトリを拝見しました。IaCの設計思想が弊社の目指す方向と近く…」のように、その人だからこそ送っている理由を明確にします。

「内製プロダクト開発」の面白さを打ち出す

プラットフォームエンジニアリングの醍醐味は、社内向けとはいえ「プロダクト」を作れることです。ユーザー（開発者）からダイレクトにフィードバックを得られ、改善の効果がすぐに見える。この手触り感をスカウト文面で伝えましょう。

年収相場と報酬設計のポイント

プラットフォームエンジニアの年収相場はSREと同等かやや高めで、ミドルで650〜950万円、シニアで950〜1,400万円が目安です。報酬設計を誤ると候補者が集まらないか、入社後の不満につながるため、市場相場を正確に把握しましょう。

2026年時点の年収相場（目安）

一般的に、SREと同等かやや高めの水準になります。特にIDP構築の実務経験がある人材は市場に希少なため、シニアクラスではプレミアムがつく傾向があります。

報酬以外の訴求ポイント

年収だけで勝負するのはスタートアップにとって不利です。報酬設計の基本的な考え方を踏まえつつ、以下のポイントも組み合わせて総合的な魅力を打ち出しましょう。

• 技術選定の裁量: IDPの技術スタックを自ら選定・決定できる

• OSS貢献の推奨: 業務で開発したツールのOSS公開を奨励する文化

• カンファレンス登壇支援: PlatformCon、CloudNative Days等への登壇・参加費用を会社負担

• 学習予算: 年間20〜50万円の学習・資格取得予算

• ストックオプション: 未上場企業であればSOの付与で中長期的なリターンを提示

選考プロセスの設計——技術力とプロダクト思考を見極める

プラットフォームエンジニアの選考では、コーディング試験よりもシステム設計ディスカッションとワークサンプルテストが有効です。技術力だけでなく「プロダクトとして基盤を作れるか」を評価する仕組みを選考フローに組み込みましょう。

推奨する選考フロー

技術面接の設計：システム設計ディスカッション

プラットフォームエンジニアの技術面接では、コーディング試験よりもシステム設計ディスカッションが有効です。以下のような問いを出し、思考プロセスを観察します。

出題例1: IDP設計

「エンジニア30人・マイクロサービス20個の組織で、開発者が新しいサービスを10分以内にデプロイ可能な状態まで持っていけるIDPを設計してください。技術選定の理由も含めて説明してください」

出題例2: トレードオフの議論

「全チーム共通のCI/CDパイプラインを提供するか、各チームがカスタマイズ可能な柔軟なパイプラインを提供するか。それぞれのメリット・デメリットを挙げ、どちらを推奨するか理由とともに説明してください」

出題例3: 採用率（Adoption）の改善

「社内でIDPを構築したが、開発チームの半分しか使っていません。採用率を80%以上に引き上げるためにどうアプローチしますか？」

出題例3は、プラットフォームエンジニアならではの問いです。純粋な技術力だけでなく、プロダクト思考やコミュニケーション力を評価できます。

ワークサンプルテストの設計

実務に近い課題を2〜3時間の持ち帰りテストとして出します。

課題例:

「以下の要件を満たすサービステンプレートを作成してください。

• Helmチャートまたはkustomizeマニフェスト

• GitHub Actionsのワークフロー（ビルド・テスト・デプロイ）

• 使い方を説明するREADME

• 新規チームがこのテンプレートを使い始める手順のドキュメント」

評価のポイントは以下の通りです。

• 実装の品質: IaCのベストプラクティスに沿っているか

• 抽象化のレベル: 適切に設定値を外部化し、再利用性を考慮しているか

• ドキュメンテーション: 使い手（開発者）の視点で分かりやすく書けているか

• トレードオフの説明: 「なぜこの技術を選んだか」を言語化できているか

面接で聞くべき質問リスト

以下の質問は、プラットフォームエンジニアとしての適性を見極めるのに有効です。

• 「これまでに構築した開発者向けツールやプラットフォームで、最も誇りに思うものは何ですか？ユーザー（開発者）からのフィードバックはどうでしたか？」

• 「開発チームから『このツール使いにくい』と言われたとき、どう対応しましたか？」

• 「標準化を進めたいが、あるチームが独自の方法を使い続けたい場合、どうアプローチしますか？」

• 「プラットフォームの改善に使える時間が限られている中で、どう優先順位をつけますか？」

• 「社内プラットフォームと外部SaaSのどちらを採用するか、判断基準は何ですか？」

人材プールが限られる中での現実的な採用戦略

「プラットフォームエンジニア経験者」をピンポイントで探すのは、市場に出回っている経験者の数が圧倒的に少ないため現実的ではありません。コンバート採用・副業からの段階的採用・コミュニティ経由の3つのアプローチを組み合わせるのが実務的な解になります。

アプローチ1: 隣接職種からのコンバート採用

最も現実的なのは、SRE・インフラエンジニア・バックエンドエンジニアの中から、プラットフォームエンジニアリングへの適性が高い人材を採用し、社内で育成するアプローチです。

コンバートに向いている人材の4つの特徴:

1. 「仕組み化」「自動化」への強い志向がある

2. 社内ツールの開発やCI/CD改善を自発的に行った経験がある

3. 技術を使うだけでなく、他者が使えるようにするドキュメントやガイドを書いてきた

4. 「技術的に正しい解」より「チーム全体の生産性が上がる解」を選ぶ思考がある

選考では「プラットフォームエンジニアリングの経験」そのものではなく、上記の素養を持っているかどうかを評価します。

アプローチ2: 副業・業務委託からの段階的採用

フルタイムの正社員採用にこだわらず、まず副業・業務委託でプラットフォームエンジニアリングの知見を持つ人材を招き、IDP構築の方向性を固めるアプローチです。

メガベンチャーやSaaS企業でプラットフォームチームに所属しているシニアエンジニアが、副業でスタートアップのIDP構築をアドバイザリーするケースは増えています。週1〜2日の稼働でも、技術選定やアーキテクチャ設計のフェーズでは大きな価値を発揮します。

副業で相性を確認した上で、正社員にコンバートするパターンも有効です。

アプローチ3: コミュニティ経由の採用

プラットフォームエンジニアリングのコミュニティは急速に成長しています。以下のようなコミュニティに自社のエンジニアが参加し、存在感を高めることで、採用につなげるアプローチです。

• PlatformCon: プラットフォームエンジニアリングに特化したグローバルカンファレンス

• Platform Engineering Meetup（日本）: 国内のプラットフォームエンジニアリングコミュニティ

• CloudNative Days: CNCF関連の国内カンファレンス

• SRE NEXT: SREコミュニティだが、プラットフォームエンジニアリングの話題も多い

自社のIDP構築事例をテックブログで発信したり、Meetupで登壇したりすることで、プラットフォームエンジニアリングに関心の高いエンジニアとの接点を作ります。

プラットフォームチーム立ち上げのロードマップ

プラットフォームチームの立ち上げは「発見→MVP→拡大→成熟」の4フェーズで段階的に進めるのが成功パターンです。採用した人材が最初の90日で成果を出せるかどうかは、このロードマップの設計にかかっています。

1. フェーズ1: 発見（入社〜1ヶ月）——開発者への1on1ヒアリングと既存インフラ・CI/CD環境のアセスメントでペインポイントを把握し、クイックウィン（すぐに改善できる課題）を特定する

2. フェーズ2: MVP（1〜3ヶ月）——最も効果の大きいペインポイントに絞って小さなMVPを作り、1〜2チームでパイロット運用。開発者フィードバックで方向性を検証する

3. フェーズ3: 拡大（3〜6ヶ月）——パイロットの成果をもとに全チームへ展開。ドキュメント・チュートリアルを整備し、開発者サーベイで効果を定量測定する。必要に応じて2人目を採用

4. フェーズ4: 成熟（6ヶ月〜）——IDPロードマップを四半期ごとにアップデートし、セルフサービスの範囲を段階的に拡大。KPI（デプロイ頻度、環境構築時間、開発者NPS等）を定期的にモニタリングする

よくある失敗パターンと回避策（3パターン）

• 最初から完璧なIDPを作ろうとする：Backstage、Crossplane、ArgoCD……全てを最初から導入しようとすると何ヶ月経っても成果が出ません。まずは「一番痛い問題を一つ解決する」ことに集中する

• 開発者の声を聞かずに作る：「技術的に正しいから使うべき」という押し付けは採用率の低下を招きます。プラットフォームはプロダクト。ユーザー（開発者）のニーズから始める

• 成果を可視化しない：プラットフォームチームの成果は売上に直結して見えにくく、経営層の理解を得にくい。「環境構築時間がZ時間→W分に短縮」のように定量的な成果を常に示す

FAQ（よくある質問）

Q1: プラットフォームエンジニアとSREはどちらを先に採用すべきですか？

サービスの信頼性に課題がある（障害頻発、SLO未定義）ならSREが先、信頼性は担保できているが開発者の生産性やオンボーディング速度に課題があるならプラットフォームエンジニアが先です。多くのスタートアップでは、最初は1人が両方の役割を兼務し、組織拡大のタイミングで分離するパターンが現実的です。

Q2: プラットフォームエンジニアの経験がない候補者でも採用して大丈夫ですか？

大丈夫です。この肩書きで十分な経験を持つ人材は市場に限られています。SRE・インフラ・バックエンドエンジニアの中で「仕組み化・自動化への志向」「プロダクト思考」「ドキュメンテーション力」を持つ人材であれば、キャッチアップは十分可能です。

Q3: Backstageは導入すべきですか？

導入自体が目的化しないよう注意が必要です。エンジニア20人以下の組織であれば、GitHub Templateとシンプルなドキュメントサイトで十分なケースが多いです。組織が30人を超え、サービスが15個以上になったタイミングで導入を検討するのが一般的です。

Q4: プラットフォームチームのKPIはどう設定すべきですか？

デプロイ頻度・環境構築時間・開発者NPS・セルフサービス率（インフラチームへの依頼なしに開発者が自己完結できた割合）・オンボーディング時間（新メンバーが最初のデプロイを行うまでの時間）が一般的です。ただし数値だけを追うのではなく、開発者インタビューやレトロスペクティブ等の定性的なフィードバックも組み合わせることが重要です。

Q5: プラットフォームエンジニアの採用にはどのスカウトサービスが有効ですか？

Forkwell（技術力の高い層）、LAPRAS（GitHub活動をもとにスカウト可能）、転職ドラフト（年収の透明性）が有力です。LinkedInはグローバル人材やシニア層にリーチしやすく、経験者が比較的多い傾向があります。いずれも前述のスカウト文面のポイントを押さえた上でアプローチすることが重要です。

Q6: 小規模なスタートアップでもプラットフォームチームは必要ですか？

エンジニア10人以下の段階では専任チームはオーバースペックになりがちです。ただし「プラットフォーム的な考え方」を持つエンジニアが1人いるだけでCI/CDの標準化やIaCの整備が進み、後々のスケーリングが格段に楽になります。専任チームの設置は20〜30人超が一般的ですが、素養を持つ人材は小さいうちから意識的に採用しておくことをおすすめします。

Q7: プラットフォームエンジニアの面接で技術力を見極めるコツはありますか？

コーディング試験よりもシステム設計ディスカッションを重視することをおすすめします。「30人のエンジニア組織でIDPを設計してください」のような設計課題で技術選定の理由やトレードオフの考慮を評価しつつ、「開発チームが使いたがらないプラットフォームにどう対処するか」のようなプロダクト思考を問う質問を組み合わせ、「使われる仕組みを作れるか」を見極めます。

まとめ——プラットフォームエンジニア採用を成功させるために

プラットフォームエンジニアリングは、開発組織のスケーリングと生産性向上を支える重要な投資です。採用を成功させるために押さえるべきポイントは次の4つです。

1. 要件定義を曖昧にしない：SRE・DevOps・インフラエンジニアとの違いを理解し、「プラットフォームエンジニアに何を求めるのか」を明確にする。技術スキルだけでなく、プロダクト思考やドキュメンテーション力も要件に含める

2. 経験者採用にこだわりすぎない：経験者は市場に限られています。SRE・インフラ・バックエンドからのコンバートを前提に、素養を見極める選考を設計する

3. 求人票とスカウトで差をつける：IDPの構想、技術スタック、開発者との関わり方——これらを具体的に伝えることで候補者の関心を引きつける

4. 段階的にチームを立ち上げる：いきなり完璧なIDPを目指さず、最もインパクトの大きい課題から着手する。小さなMVPで成果を出し、社内の信頼を得ながら段階的に拡大する

プラットフォームエンジニアの採用は難易度が高いですが、成功すれば開発組織全体の生産性を大きく底上げできます。まずは自社のフェーズと課題を見極め、この記事で紹介した手法を一つずつ実践してみてください。

エンジニア採用に課題を感じたら、techcellarのエンジニア採用支援サービスもぜひご検討ください。エンジニア出身の採用のプロが、貴社の採用課題に合わせた戦略を提案します。