developer-platform-career

Developer Platform Career

1 人のための開発者向けプラットフォームのキャリアコーチです。どのトラックと企業の類型を目指すべきかを選び、現在の立ち位置からこの分野に参入する方法を考え、この分野で実際に行われる面接に備え、DevRel とは異なり、調査不足の独立したものではない職位階層を基準にオファーを評価できるよう支援します。

対象外の場合は、代わりに次の案内をします。

• 雇用主側の採用プロセス、求人情報、評価基準 — samber/developer-platform-skills@developer-platform-hiring は、このスキルを反対側から見たものです。
• デベロッパーアドボケイト、コミュニティマネージャー、デベロッパーエデュケーター、または DevRel 独自のタイプの DX エンジニア — samber/developer-relations-skills@devrel-career。これらの職種では、コミュニケーション能力とコミュニティ運営のスキルが評価されます。このスキルの対象となる職種では、API とシステム設計に関する判断力が主要なスキルとして評価されます。

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

まず「platform engineer」の意味を明確にする

業界では、「platform engineer」や「platform engineering」は、その大半が社内開発者プラットフォームを指します。つまり、セルフサービス型のインフラ、CI/CD、Kubernetes の抽象化、そして企業内のアプリケーションエンジニア向けに構築されたゴールデンパスです。この言葉を掲げる主要コミュニティである PlatformCon は、28 万人を超える実務者を対象としており、このスキルの対象となる内容は扱っていません。

このスキルの対象は、それとは異なる、より限定された層です。企業の公開 API や外部向け API、および統合機能を設計・運用するエンジニアや PM です。

この職種が構築するものの主な利用者が誰なのか、質問するか、職種名や履歴書の記述から推測してください。企業内のエンジニアリングチームなのか、それとも企業外の開発者（顧客、パートナー、サードパーティーのアプリ開発者）なのか。社内の利用者であれば、社内プラットフォームエンジニアリングに該当し、このスキルの対象外です。コレクション内に案内先はありません。社外の利用者であれば、このスキルの対象です。

この点を取り違えると、誤ったコミュニティ（PlatformCon と apidays）を参照し、誤った報酬水準（一般的なインフラ／SRE と、API 設計を専門とする一般的なバックエンド／プロダクトエンジニアリング）を基準にし、誤った求人情報を読むことになります。

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

面接

可能な場合は選択式で、一度に質問を1つだけしてください。すでに回答済みの質問はスキップしてください。質問7〜9は、経路の候補と準備項目の優先順位を調整するものです。計画を作成する前に質問してください。

1. 現在の状況はどれですか。（a）まだプラットフォーム関連の仕事には就いていない――一般的なバックエンドエンジニア、一般的なPM、または隣接する別の職種。（b）既存のエンジニアリング組織内で社内APIを構築している。（c）プラットフォームチームまたはAPIチームのジュニア。（d）中堅のAPI PM、プラットフォームエンジニア、またはパートナーエンジニア。（e）シニアで、スタッフ／プリンシパルまたはディレクターレベルを目指している。
2. 目指す企業の類型はどれですか。（a）APIが製品である、インフラ／APIファーストの企業。（b）既存製品に公開APIを追加している企業。（c）大規模なパートナー／ISVエコシステムを持つエンタープライズプラットフォーム。（d）未定。
3. 目指す職種の方向性はどれですか。（a）APIプロダクトマネージャー。（b）プラットフォームエンジニア／アーキテクト。（c）パートナー／インテグレーションエンジニア。（d）未定――企業の類型に基づいて提案してください。
4. 公開できる実績はありますか。機密情報を開示せずに説明できるRFCや設計ドキュメント、リリースしたAPI／スキーマ設計、オープンソースへの貢献実績、構築したパートナー連携などはありますか。
5. 現在、社内APIや社内向けインテグレーションを構築していますか。これは外部向けの仕事に進むための、リスクの低い練習の場です。
6. どのエコシステムやプロトコルに精通した人材として認められたいですか。REST、GraphQL、gRPC、webhook、または特定ベンダーのSDKエコシステムなどですか。
7. 期限はありますか。現在面接中、1〜3か月、6〜12か月、または期限なしのいずれですか。
8. 一度きりの転職と、経験を積み重ねることのどちらを重視しますか。できるだけ早く次の職に就くことと、複数の雇用先でプラットフォーム／APIに関する判断力を継続的に磨くことのどちらですか。
9. 労力の上限はどのくらいですか。現職以外で、ポートフォリオ（RFC、サンプルAPI、オープンソースへの取り組みなど）の作成に充てられる時間は、週に何時間ですか。

企業の類型を選ぶ

ある類型から別の類型も予測できると決めつけてはいけません。日々の業務、キャリアラダー、採用者の評価基準はすべて異なります。

類型	業務の特徴	採用者の評価基準
インフラ／APIファースト（Stripe、Twilioのような企業）	APIが製品であり、専任のプラットフォームチームがあり、技術的な深さが最も求められる	API設計の品質、インフラの信頼性、契約の安定性
既存製品に公開APIを追加する企業	専任チームはまれで、API設計は一般的なバックエンドエンジニアリングに組み込まれている	一般的なエンジニアリングの遂行能力、複数ある能力の1つとしてのAPI設計
エンタープライズのパートナー／ISVエコシステム	独自のマネージャーとディレクターを置く、名称の定まったパートナーエンジニアリング機能がある（GitLabの組織構造など）	支援したパートナー、リリースしたインテグレーション、利用の拡大

実情として支配的であり、期待値を設定するうえで知っておくべき点があります。Postmanの「State of the API Report」によると、APIチームの84％は1〜9人のグループで運営されており、大半の企業では一般的なエンジニアリング部門とは別に、独立した中央集約型のプラットフォーム機能が設けられていません。真のインフラファースト企業や大規模なパートナーエコシステムを持つエンタープライズを除けば、業務範囲の狭い専門職ではなく、API設計に加え、パートナー業務や社内への働きかけも担う幅広い役割を想定してください。

各類型の詳細な比較と、候補者がそれぞれに期待すべきことについては、references/company-type-bar.mdをご覧ください。

キャリアラダー

API プロダクトマネージャーやプラットフォームエンジニアには、DevRel の各職種と同様に、業界横断で標準化された IC キャリアラダーがありません。ただし、明確に述べておくべき違いが 1 つあります（「報酬」を参照）。プラットフォーム系の役職名は、独自のキャリアラダーを必要とせず、一般的なエンジニアリングまたは PM のキャリアラダーに沿っています。

4 つの職種と、それぞれで評価される内容は次のとおりです。

• API プロダクトマネージャー - ライフサイクル全体にわたって API をプロダクトとして担当します。戦略、ロードマップ、ステークホルダー管理、収益化、利用データに基づく改善が含まれます。機能の採用状況だけでなく、統合時の摩擦や破壊的変更のコストについても評価されます。キャリアアップは一般的な PM のキャリアラダー（APM -> PM -> Senior PM -> Principal/Staff PM -> Director）に沿い、すべてのレベルで技術的な比重が加わります。
• プラットフォームエンジニア／プラットフォームアーキテクト - エンジニアは日々の構築と運用を担い、アーキテクトは長期的な技術ビジョンを策定します。ただし、求人では両者の役割が頻繁に混在しており、実際に分けているのは大規模な組織に限られます。Stripe の Staff Software Engineer, API Platform の求人は、具体的で高い基準の一例です。技術分野で 12 年以上の経験、戦略的な技術リーダーシップで 5 年以上の経験、インフラ／プロダクトの実践的なデリバリー経験、Java、Ruby、Python、または Go が求められます。
• パートナーエンジニアとインテグレーションエンジニア - どちらも API の利用境界に位置しますが、対外的な関係構築を担うかどうかが異なります。パートナーエンジニアは、外部パートナーやマーケットプレイスの開発者（GitLab、Uber）との技術的な窓口です。インテグレーションエンジニアは社内向けで、アーキテクチャに重点を置き、複数のサービスやサードパーティーシステム間で信頼性の高いデータ交換を実現します。
• 開発者プラットフォームリード - この名称で標準化された役職名やキャリアラダーは見つかっていません。独自の外部採用市場を持つ職種名ではなく、統合インターフェースの戦略的な意思決定を担う人を示す、組織ごとの呼称です。

GitLab は、この分野で実際に名称が定められた唯一の 3 段階のキャリアラダーを公開しており、具体例として役立ちます。Associate Partner Integration Engineer -> Partner Integration Engineer -> Manager, Partner Integration Engineers。すべてのレベルで求められる要件は、Ruby/Rails または Go の習熟、最新の SDLC 実践、オープンソースへの貢献実績、部門横断的な関係構築・管理です。

職種の詳細な定義、GitLab のキャリアラダー全文、および情報源については、references/role-taxonomy-and-ladder.md を参照してください。

エントリー経路

この専門分野に特化した学位やブートキャンプの経路はありません。情報源として確認したすべての求人情報によると、一般的なソフトウェアエンジニアリングまたは PM の基盤に専門性を積み重ねていくものです。

• エンジニアリング側の参入基準には大きな幅があります。 GitLab のアソシエイトレベルでは、学士号または同等の資格、Ruby/Rails または Go のスキル、そして特筆すべき点として、エントリーレベルでもオープンソースへの貢献実績が求められます。Stripe のスタッフレベルの求人では、はるかに高い基準が設けられており、経験 12 年以上、そのうち戦略的な技術リーダーシップの経験が 5 年以上必要です。
• RFC の執筆は、この分野で実際に確認できるポートフォリオの成果物です。 DevRel における登壇やブログ記事に相当します。現在掲載されているバックエンド関連の複数の求人では、「技術設計ドキュメントや RFC の作成とレビュー」が中核的な責務として挙げられています。ただし、GitHub プロフィールに相当する「API 設計 RFC のポートフォリオ」をまとめた公開リポジトリは存在しません。同等の成果物は実際の雇用主向けに作成した設計ドキュメントですが、ブログ記事よりも公開しにくいものです。
• 認定資格は、ほとんど意味がありません。 現在も実施されている唯一の実質的な資格は apidays の apiMasters プログラムです。DevRel がベンダー認定資格を扱うのと同様に、せいぜい参考情報として考えてください。採用の必須条件として明示されることはありません。

この分野で確立された経路ではありませんが、試す価値のある方法： 既存のエンジニアリング組織内で内部 API を構築する場合、公開 API をリリースする場合ほど外部利用者に対する責任は重くありません。そのため、外部向けの API をリリースするチームに移る前に練習する場として、実現可能性があり、より取り組みやすい選択肢です。この特定の移行を経験した人物の証言は見つかっていないため、確認済みの経路ではなく仮説として提示してください。

詳細と、情報が限られている点については、references/entry-paths-and-skills.md を参照してください。

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

面接対策

大手企業（特に Meta）では、API 設計は一般的なシステム設計とは別の、明確に区別された面接形式になっています。 システム設計では大規模な分散システムのアーキテクチャを評価します。一方、API 設計では、開発者が利用するインターフェースの設計判断と、その後に生じる影響を評価します。判断基準となるのは、規模に関するトレードオフの考慮そのものではなく、明確さと誤用への耐性です。よく例に挙げられる課題は、カード決済処理に範囲を絞った決済 API の設計です。この場合の「ユーザー」は、自社製品に API を組み込む開発者です。

PM 候補者に求められる基準は、設計上、エンジニアリング候補者とは異なります。深い技術実装の知識を証明することではなく、設計の考え方をどれだけ適切に絞り込み、構成し、伝えられるかが評価されます（Google でも同様です）。一方、PM の面接プロセスによっては（Uber など）、エンジニアとの実際の技術的な対話が含まれることもあります。

GitLab の公開ハンドブックには、実際に掲載されているエンジニアリング側の選考プロセスがあります。リクルーターとの電話面談 -> 採用マネージャーとの面接 -> チームとの面接 2～5 回 -> シニア職では役員面接の可能性、という流れです。この採用区分では、API 設計に特化した面接や課題は明記されていません。「SDK または API のインターフェースを設計する課題」は、上記の API 設計面接形式からの類推として妥当ではありますが、実施が直接確認されているものとして扱わないでください。

質問の傾向、他社の持ち帰り課題の実例、確認済みの情報と推定の区別については、references/interview-loop-patterns.md を参照してください。

トップクラスの実践者を際立たせるもの

この分野について、採用やキャリアの観点から実践者が語った情報は乏しいため、以下の引用を採用に特化した差別化要因として扱わないでください。実際に引用できるのは、このトラックが対象とする種類の企業に所属する、実名の実践者による API 設計の技量に関する見解です。

• Brandur Leach（Stripe、後に OpenAI）：「API に関しては、変更は歓迎されません。ソフトウェア開発者は迅速かつ頻繁に反復することに慣れていますが、API 開発者は、たった 1 人でもユーザーがインターフェースを使い始めた時点で、その柔軟性を失います。」このトラックでの判断が、ほとんどのエンジニアリング上の決定よりも長く影響を及ぼす理由を示す、現場の実践者ならではの見解です。
• Zalando の RESTful API Guidelines：「優れた RESTful API は、単一のチームが設計したかのように見えます」。エンドポイント間の一貫性がもたらすものを最も明快に一文で表したものであり、ポートフォリオレビューで候補者自身の設計を評価する際の基準にもなります。
• Stripe の Staff Software Engineer, API Platform の求人情報には、求める基準が自社の言葉で記されています。純粋なインフラストラクチャの経歴を持つ候補者も、初めてインフラストラクチャに携わる候補者も歓迎する一方で、「API 設計、抽象化、フレームワーク、またはクライアントライブラリに取り組むエンジニアリングチームを率いた経験」があり、高い自律性を持って業務を進められることを求めています。求められるのは、特定の技術スタックでの在籍年数ではなく、API の方向性を定める業務でのリーダーシップです。

引用が付いていなくても、ポートフォリオで参考にする価値のある著名なフレームワークとして、Google の AIPs（レビュー委員会によるガバナンスモデルを含む）、Microsoft の REST API Guidelines、Zalando のガイドライン、Richardson Maturity Model があります。これらを基にした完全なレビュー用チェックリストについては、samber/developer-platform-skills@public-api-design-review を参照してください。

報酬

このニッチな分野には、DevRel と同じく、調査水準を満たす報酬データセットがありません。日付のない数値を、検証済みの情報として提示しないでください。

**このトラックが DevRel とどう異なるかを明確に示す、構造上の重要な特徴は一つです。**プラットフォーム職の報酬は、独立した調査不足の等級体系ではなく、一般的なエンジニアリングまたは PM の等級体系に基づきます。Stripe がこの職務そのものについて出している求人のタイトルは「Staff Software Engineer, API Platform」です。「Staff Software Engineer」は一般的なエンジニアリング職の等級を示し、「API Platform」はチーム名を補足するもので、独自の給与体系を示すものではありません。API プロダクトマネージャーに関する文献も、PM 側から同じ傾向を示しています。レベルは「通常、企業ごとに異なります……ただし、技術や開発者向けスキルをより重視しながら、一般的なプロダクトマネジメントのキャリアラダーを反映するのが一般的です」。

これは、DevRel における報酬情報の不足に対する答えよりも、実務上はるかに有用です。この職種の報酬は、同等レベルの一般的なソフトウェアエンジニアリング職またはプロダクトマネジメント職の報酬レンジを基準にしてください。他のバックエンドエンジニアリングや PM の専門職と同じ考え方です。クラウドソーシング型の等級情報サイトではデータが乏しい、「プラットフォームエンジニア」や「API プロダクトマネージャー」という独自の職種名で検索するのではありません。

ウェブを閲覧できる場合は、成果物で使用する前に、出典、日付、レベルを添えて最新の数値を確認してください。詳細については、references/compensation.md を参照してください。

失敗パターン

• 外部向け／パブリック API プラットフォームの採用に、PlatformCon 風の社内 IDP チャネルや報酬データを参照・ベンチマークすること、またはその逆。
• ある企業のキャリアラダー（Stripe または GitLab）を、具体的な出典に基づく一例ではなく、業界全体に共通する基準として示すこと。
• apiMasters を採用の必須条件として扱い、参考情報として扱わないこと。
• Postman の認定資格コミュニティについて、現在も活動していることと実際の位置づけを確認せずに引用すること。
• 日付のない、個別の職種名を検索して得た報酬額を引用し、一般的なエンジニアリング／PM のキャリアラダーとのベンチマークを行わないこと。
• 内部 API の実践を通じた入職経路を、妥当そうではあるものの未検証の仮説ではなく、実務者の情報に裏付けられた確立済みのパターンとして扱うこと。
• 求人票が社内 IDP の職種層を指すのか、外部 API の職種層を指すのかを最初に確認せず、「プラットフォームエンジニア」を対象にすること。

目標と評価基準

このスキルの成果物は、以下をすべて満たした場合にのみ合格となります。

1. 対象の職種トラック（API PM、プラットフォームエンジニア／アーキテクト、パートナー／統合エンジニア）と、対象企業の類型（インフラ／API ファースト、後付け、エンタープライズのパートナーエコシステム）の両方を明示していること。
2. 「プラットフォームエンジニア」という職種名に言及する場合は、その主張に用いる前に、社内 IDP の職種層か外部 API の職種層かを明記していること。
3. キャリアラダーに関する主張では、その根拠となる出典付きの例が Stripe または GitLab のどちらかを明記し、普遍的なラダーとして提示しないこと。
4. 報酬額は、同等レベルの一般的なエンジニアリング／PM のキャリアラダーを基準にベンチマークし、出典と日付を示すか、最新情報の確認が必要であると明記していること。
5. 内部 API を通じた入職経路を推奨する場合は、確立済みの経路ではなく仮説と明記していること。

参考資料

• references/role-taxonomy-and-ladder.md - 4 種類の職種定義、GitLab の実際のキャリアラダー、出典情報。
• references/entry-paths-and-skills.md - エンジニアリング職側の採用基準、RFC 作成によるポートフォリオ上のアピール材料、apiMasters、および各レベルのスキル内訳に関する情報が限定的であることへの注意。
• references/interview-loop-patterns.md - API 設計とシステム設計の違い、PM とエンジニアの面接プロセスの違い、課題テストの慣行、GitLab の実際の面接プロセス。
• references/company-type-bar.md - 3 種類の企業類型、チームの 84％が小規模であるという調査結果、および候補者が各類型で想定すべきこと。
• references/compensation.md - 一般的なキャリアラダーに関する調査結果の全容、および最新の報酬額を確認する際のポイント。
• 雇用主側のこの表については、samber/developer-platform-skills@developer-platform-hiring を参照してください。
• デベロッパーアドボケイト、コミュニティマネージャー、デベロッパーエデュケーターの職種、またはプラットフォームエンジニアリングの意味ではなく、DevRel におけるアドボカシー寄りの意味で「DX エンジニア」という職種名を指す場合は、samber/developer-relations-skills@devrel-career を参照してください。