developer-platform-hiring

Developer Platform の採用

採用担当者が Developer Platform 関連職の採用に必要とする成果物を作成します。自社のアーキタイプに合わせて調整した評価基準表、この分野で実際に使われている API 設計とシステム設計の分担に基づく面接プロセス、候補者のソーシング計画、そして独自のプラットフォーム職種ではなく、一般的なエンジニアリングまたは PM の職位体系を基準とする報酬方針です。

対象外の内容については、代わりに以下へ案内してください。

• 候補者へのコーチング - samber/developer-platform-skills@developer-platform-career は、このスキルを裏返したものです。
• デベロッパーアドボケイト、コミュニティマネージャー、デベロッパーエデュケーター、または DevRel 独自の DX エンジニアの採用 - samber/developer-relations-skills@devrel-hiring。これらの職種ではコミュニケーション力とコミュニティ運営の技術を審査します。このスキルが対象とする職種では、API とシステム設計の判断力を主要スキルとして審査します。

ユーザーが採用ではなく求職中の場合は、その旨を一行で伝え、developer-platform-career を案内してください。

まず「プラットフォームエンジニア」の意味を明確にする

業界の大半では、「プラットフォームエンジニア」や「プラットフォームエンジニアリング」は社内開発者プラットフォームを指します。つまり、自社のアプリケーションエンジニア向けに構築された、セルフサービス型インフラ、CI/CD、Kubernetes 抽象化、ゴールデンパスのことです。この用語を代表するコミュニティである PlatformCon は、まさにこの対象者に向けて開催されており、参加者は280,000人以上にのぼります。そして、このスキルで採用する職種に関する内容は一切扱っていません。

何かを作成する前に、まず尋ねてください。この職種が作るものを主に利用するのは誰ですか。自社のエンジニアリングチームですか、それとも社外の開発者（顧客、パートナー、サードパーティのアプリ開発者）ですか。社内の利用者であれば、社内プラットフォームエンジニアリングに該当し、このスキルの対象外です。社外の利用者であれば、このスキルの対象です。

PlatformCon 周辺のチャネル（Backstage コミュニティ、社内 IDP の求人掲示板）で職種を募集したり候補者を探したりすると、外部向け API プラットフォームの採用には不適切な候補者層が集まります。

メモリ（推奨）： メモリをファイルで管理している場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使っている場合は、そちらを利用してください。このファイルは参考用であり、必須ではありません。タスクごとに異なるセクションに情報を分けてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトのコンテキストには日付を付けないでください。面接の回答は、2つのタスク間で異なる場合があります。

面接

一度に質問するのは1つだけにしてください。可能な場合は選択式にします。すでに回答されている内容は省略してください。質問7～9では、以下の成果物の優先順位を付け直します。

1. 会社のアーキタイプ：（a）API が製品である、インフラ／API ファーストの会社（b）既存製品に公開 API を追加する会社（c）大規模なパートナー／ISV エコシステムを持つエンタープライズプラットフォーム（d）未定 - 職務内容の説明に基づいて推奨する。
2. 対象となる職種のトラック：（a）API プロダクトマネージャー（b）プラットフォームエンジニア／アーキテクト（c）パートナーエンジニア、関係構築を重視（d）インテグレーションエンジニア、アーキテクチャを重視（e）未定。
3. 現在、API の全領域を一貫して担当しているのは何人ですか。初の専任採用ですか、それとも既存のプラットフォームチームへの増員ですか。（Postman のデータによると、API チームの84%は1～9人です。既存製品に API を追加する会社にとって初の専任採用は、通常の欠員補充ではなく、実質的なリソース配分の変更です。）
4. この職種の評価指標は何ですか。API 設計の品質と契約の安定性、ロードマップと収益化の成果、または明確に定義されたパートナー対応指標（支援したパートナー数、リリースしたインテグレーション数、利用拡大）ですか。
5. この職種に実際に何人のメンバーと、どの程度の予算を割り当てますか。単独での担当、小規模チーム、既存のエンジニアリングスタッフとの兼任のいずれですか。
6. 報酬方針：想定レンジはありますか。また、会社の一般的なエンジニアリング／PM の職位体系を基準にしていますか、それとも独自の「プラットフォームエンジニア」職種の採用基準を設けていますか。
7. 採用期限：今月中、今四半期中、または期限なしですか。
8. 今回限りの採用ですか。それとも、評価基準表と面接プロセスを再利用する複数名の採用の第一弾ですか。
9. 工数の上限：候補者1人あたり、面接担当者の時間を何時間まで使えますか。また、採用担当者はいますか。

回答の読み方

• Q1でスコアカードのテンプレートと現実的な基準が決まります - references/company-type-hiring-bar.md を読み込みます。インフラ/API を最優先する採用では、最も高い技術的な深さが必要です。既存事業に付け加える採用は、通常、専門職を個別に探すのではなく、一般的なバックエンド採用に組み込まれます。エンタープライズエコシステムを担う採用では、GitLab の職種群で評価される、関係構築力と技術力を兼ね備えた人材が必要です。
• Q2で適用する選考プロセスの設計が決まります - トラックごとの面接形式については、以下の「ワークフロー」を参照してください。
• Q3はスコープが過剰に集中していないかを確認するものであり、単なるデータポイントではありません。 回答が「1人が設計、パートナー連携、開発者向けコンテンツを担当する」なら、その求人では1つのポジションに3人分のフルタイム業務を求めている可能性が非常に高いです - 以下の「危険信号を見つける求人票の読み方」を参照してください。
• Q4でスコアカードの成果指標が決まります - 汎用的な「API を担当する」という成果は決して書かず、この職務で実際に評価される項目を明記してください。
• Q5では、この分野で実際に見られる危険信号のパターンを確認します：チームも予算もないのに、API 設計、パートナー連携、開発者向けマーケティングを同時に担当することを期待される単独採用は、この分野の構造データが示す業務集約パターンです。
• Q6で「品質ゲート」の報酬確認が始まります - 同等レベルの一般的なエンジニアリング職または PM 職の給与体系を基準にし、独自のプラットフォーム職名で検索した結果を基準にしないでください。
• Q7では、既存の選考プロセスを一から設計するよりも再利用する方法が優先されます。
• Q8で、選考プロセスを簡素なままにするか（単発）、きちんと構築するか（継続的に価値が積み上がる）を決めます。
• Q9では、営業職や DevRel 職の採用で限られた面接官の時間を扱うときと同じように、選考段階の順番を入れ替えるのではなく、段階そのものを削除します。

ワークフロー

1. インタビューを実施します。会社のアーキタイプと職種トラックの調整内容を、ユーザーが異議を唱えられる短い段落で提示します。
2. 成果物 1 - 職種スコアカード。 references/company-type-hiring-bar.md に基づいて作成します。
   • アーキタイプと Q4 の指標を明記した、1 文のミッション
   • 測定可能な成果を 3～8 個記載します。「プラットフォームを担当する」のような曖昧な責任は記載しません。
   • トラックごとに重み付けしたコンピテンシーを記載します。API PM のスコアカードでは、ロードマップと収益化に関する判断を重視します。Platform Engineer／Architect のスコアカードでは、API／システム設計とインフラの提供を重視します。Partner Engineer のスコアカードでは、関係管理を重視します。Integration Engineer のスコアカードでは、アーキテクチャと信頼性を重視します。
3. 成果物 2 - 面接プロセス。 references/interview-loop-design.md に基づいて作成します。
   • エンジニアリングトラックの採用には、（大手企業の一般的なシステム設計とは異なる）API 設計面接形式を用います。評価では、規模に関するトレードオフそのものではなく、開発者向けの使いやすさと誤用への耐性を重視します。
   • API PM では、Google と Uber が自社の PM 面接プロセスで実施している方法に倣い、コーディング面接よりもスコープ設定とデザイン思考のラウンドを重視します。
   • Partner／Integration Engineer では、GitLab が実際に公開している選考手順を採用します。リクルーターとの面談、採用マネージャーとの面接、2～5 回のチーム面接、シニア採用では場合により役員面接を実施します。
   • すべてのトラックに適用できる、完全に文書化された開発者プラットフォーム特化型の面接プロセスが公開されているわけではないことを明記します。これは業界標準の模倣ではなく、組み立てた設計です。
4. 成果物 3 - 採用候補者のソーシング計画。 references/sourcing-channels.md に基づいて作成します。
   • API プラットフォームエンジニアと API プロダクトマネージャーの確かな採用イベントとして apidays を利用します。社内 IDP 層を対象とする PlatformCon は決して利用しません。
   • Platform Engineer と Integration Engineer のトラックでは、一般的なシニアバックエンドエンジニア向けの採用チャネル（リファラルネットワーク、シニア IC の採用候補者パイプライン、選考基準としてのオープンソースへの貢献履歴）のほうが、DevRel 隣接のチャネルより効果的です。
   • API PM のトラックでは、API または開発者向けプロダクトの経験で絞り込んだ、一般的な技術系プロダクトマネジメントの採用チャネルを利用します。
5. 成果物 4 - 報酬の方針。 references/compensation-guidance.md に基づいて作成します。
   • オファーの基準は、同等レベルにおける会社全体のソフトウェアエンジニアリングまたはプロダクトマネジメントの報酬バンドとします。データが少ないクラウドソーシング型の情報しか得られない、独自の「platform engineer」や「API product manager」という肩書きによる検索を基準にしてはいけません。
   • データの出典となる例として GitLab または Stripe 独自のレベル設定を挙げます。普遍的な基準として扱ってはいけません。
6. 以下の品質ゲートを実施します。合格するまで反復します。
7. ハーネスに永続メモリがある場合は、再度の採用で再利用できるよう、スコアカード、面接プロセスの設計、採用候補者のソーシング計画を保存します。

求人票の危険信号を見抜く

開発者向けプラットフォーム職について、出典のある、名称の定まった採用上の危険信号の分類体系はまだ存在しません。DevRel には文書化されたゲートキーパー／落とし穴のフレームワークがありますが、存在しない出典を引用するのではなく、この点を明確に述べてください。構造データから裏付けられるのは、同じパターンに別の名前を付けたものではなく、固有のパターンです。

• パターン：構築業務（API／スキーマ設計、パートナー統合アーキテクチャ）とアウトリーチ業務（開発者向けマーケティング、コンテンツ）を求人票に積み上げることです。これは、1つの職種内ではなく、複数の職種間でスコープが崩れている状態です。DevRel のゲートキーパーパターンとは異なり、個々に挙げられたスキルはどれも、優秀な候補者が実際に備えている可能性があります。問題は実行量がフルタイムの職務3つ分に及ぶことであり、不可能なスキルの羅列ではありません。
• 兆候：求人票に、3つの異なる機能に属する成果（リリース済み API サーフェス、明示されたパートナー統合件数、コンテンツまたはコミュニティの指標）が記載されている一方で、いずれ分割するための人員計画が示されていません。職種名は IC エンジニアとしてのシニアレベルを示唆しているのに、職務内容はプロダクトマネージャーの仕事に DevRel の仕事を重ねたものになっています。また、その機能を1人以上に拡大するための報告先や予算が明記されていません。

フォローアップ調査で確かな出典のある記述が見つからない限り、このパターンは Postman の少人数チームのデータと、DevRel の分類体系とのリポジトリ横断の類推から導いた構造的な推論であり、業界で命名・引用された診断ではないことを明確に述べてください。求人票を公開する前に、この観点で自己監査してください。テストに不合格となった求人票は、公開前にスコープを複数の採用枠に分割するか、リソースを明示する必要があります。

企業タイプと職種トラックの基準調整

1種類のスコアカードテンプレートがあらゆる企業タイプにそのまま適用できると考えてはいけません。全体比較と、少人数チームの割合が84％という調査結果は、references/company-type-hiring-bar.md にあります。

品質ゲート

最終成果物を提出する前に、以下のチェック項目に照らして成果物を評価してください。

1. 求人票またはスコアカードに、その職種が社内 IDP または外部 API のプラットフォームエンジニアリングのどちらを指すのかが明記されています。
2. スコアカードに実際の企業タイプと、この職種の評価指標が記載され、すべての成果が定量化されています。
3. 求人票は、スコープ崩壊の自己監査に合格しています。人員計画が示されていない、構築業務とアウトリーチ業務の積み上げがありません。
4. 面接設計が職種トラックに合っています。エンジニアリングトラックには API 設計形式、PM トラックにはスコープ設定／デザイン思考の面接ラウンド、Partner/Integration Engineer には GitLab の構造化された選考プロセスが使われています。
5. 候補者の募集には、必要に応じて apidays またはシニアバックエンド／PM 向けの一般的な採用チャネルを使います。外部 API の採用に PlatformCon を使ってはいけません。
6. 報酬方針は、企業の一般的なエンジニアリングまたは PM の給与体系を基準とし、出典と日付を明記しています。市場相場として提示する数値に、複数の給与体系を混ぜたり、特注の職種名で検索した数値を使ったりしてはいけません。

よくある失敗例

失敗	対策
外部 API プラットフォームの採用で、PlatformCon や社内 IDP のチャネルを使って候補者を探す	代わりに、apidays やシニアバックエンドエンジニア／PM 向けの一般的なチャネルを使います
チームも予算もないのに、API 設計、パートナー連携、開発者向けコンテンツを 1 人の採用者がすべて担うことを期待する	複数の採用者に業務範囲を分けるか、募集要項で必要なリソースを明示します
API 設計の判断力を評価する職種に、一般的なシステム設計面接を流用する	API 設計向けの形式を使い、開発者にとっての使いやすさと誤用への耐性を基準に評価します
クラウドソーシングサイトの独自の「プラットフォームエンジニア」給与額を引用する	同等レベルの、会社全体のエンジニアリング／PM の給与体系を基準にします
GitLab や Stripe が公開している組織構成を、業界全体に当てはまる標準として扱う	標準ではなく、情報源が確認できた一例として示します
API 全体をすでに 1〜9 人で運営している会社で、専門職（API PM、アーキテクト、パートナーエンジニア）を 3 人採用する	まず企業の類型を確認し、企業タイプの参考情報に基づいて実際のチーム規模に合った人員を採用します

参考資料

• references/company-type-hiring-bar.md - 3 つの企業類型、小規模チームが 84％を占めるという調査結果、そして業務範囲が縮小する前提条件について説明しています。
• references/interview-loop-design.md - API 設計とシステム設計の使い分け、職種ごとの面接プロセス、GitLab が実際に公開している選考手順について説明しています。
• references/sourcing-channels.md - apidays、PlatformCon に関する注意点、そしてこの候補者層を DevRel よりもシニアバックエンドエンジニアに近い方法で探す理由について説明しています。
• references/compensation-guidance.md - 一般的な給与体系に関する調査結果の全容と、現在の給与額を確認する方法について説明しています。
• 候補者側の視点については、samber/developer-platform-skills@developer-platform-career を参照してください。
• 募集要項でプラットフォーム職と混同されることのある、DevRel を主軸とした採用については、samber/developer-relations-skills@devrel-hiring を参照してください。上記の業務範囲が縮小する危険信号は、この混同でよく見られる症状です。