職種・体制

Technical Product Manager

（てくにかるぷろだくとまねーじゃー／テクニカルプロダクトマネージャー）

登場（海外）: 2018年
国内で見られるように: 2022年ごろ
更新: 2026-08-24

一言でいうと

API・データ基盤・開発者向け機能といった技術寄りの領域を担当するプロダクトマネージャーで、利用者が開発者である点が通常のプロダクトマネージャーと異なります。

この職種の出自と登場時期

きっかけは、開発者を顧客とする製品が増えたことです。API、SDK、社内のプラットフォーム、データ基盤といった領域では、利用者が技術者であり、価値の判断に技術的な理解が必要になります。通常のプロダクトマネージャーの手法では扱いにくいため、技術寄りの担当を分ける形が2018年前後から広がりました。

platformengineering.org は、社内の開発者向けプラットフォームを製品として扱うべきだと整理しています。この考え方が広がるにつれて、社内プラットフォームにもプロダクトマネージャーを置く組織が現れました。

国内では2022年前後から、API を外部提供する事業会社と、プラットフォームチームを持つ企業で見られるようになりました。ただし求人数は限られ、「プロダクトマネージャー（基盤領域）」の名称で募集される場合が大半です。

ミッション

責任範囲は、技術者が使う製品として選ばれ、使われ続ける状態をつくることです。機能の数ではなく、開発者が短時間で目的を達成できるかが評価の対象になります。

利用者が技術者である以上、判断の根拠も技術的になります。設計の善し悪しが採用の可否を決めるため、仕様の細部まで踏み込む必要があります。

主な業務範囲

利用者調査。社内外の開発者に話を聞き、詰まっている箇所を特定する
API と仕様の設計への関与。使いやすさ、互換性、廃止の方針を開発チームと決める
ロードマップの策定。技術的な負債の返済と新機能の配分を決める
ドキュメントと開発者体験の設計。導入の手順、サンプル、エラーの伝え方を整える
利用状況の測定。導入までの時間、利用率、問い合わせの内容を追って改善する

求められる能力

前提になるのは、API 設計とシステム構成を理解し、開発チームと同じ言葉で議論できることです。自分で実装する必要はありませんが、設計の選択肢を評価できないとこの職種は成立しません。

技術以外では、通常のプロダクトマネージャーと同じく優先順位の判断と説明が中心です。加えて、後方互換性のように、利用者の負担と自社の都合が衝突する判断を扱う場面が多くなります。

この職種に就く人のキャリア経路

多いのはバックエンドエンジニアやプラットフォームエンジニアからの移行です。技術的な理解を土台に、プロダクト側の判断へ広がる流れが一般的です。プロダクトマネージャーが技術領域を担当するうちに専任になるケースもあります。

プロダクト組織かプラットフォーム組織の責任者へ進む例が代表的で、CTO に就く人もいます。

隣接職種との違い

職種	責任の中心	Technical Product Manager との違い
プロダクトマネージャー	利用者向け機能のプロダクト判断	利用者が一般の顧客。TPM は開発者が利用者になる
Platform Engineer	開発者向けプラットフォームの提供	自分で作る。TPM は何を作るかを決める
プロダクトエンジニア	事業成果まで含めた実装	実装が中心。TPM は実装しない
ソリューションアーキテクト	顧客への提案段階での技術構成	案件単位。TPM は製品として継続的に作り込む

採用担当の見極めポイント

求人票では、対象が社内向けか外部提供かを明記してください。社内基盤と外部APIでは、必要な経験も評価指標も異なります
職務経歴書を見るときは、技術的な意思決定に関わった範囲を確認してください。要望の取りまとめだけの経験では、この職種の中心部分を判断できません
開発チームとの分担を決めてください。設計の主導権がどちらにあるかが曖昧だと、着任後に役割が重なります

求人・市場の傾向

国内の母集団はきわめて薄く、この呼称で経歴を書いている候補者は限られます。プロダクトマネージャーのカテゴリに含まれてしまうため、この語だけの件数には意味がありません。媒体では「プロダクトマネージャー」「バックエンドエンジニア」の職種カテゴリで引き、API や基盤の企画に関わった記述があるかで絞る進め方が現実的です。

利用者である開発者が社内何名か、社外何社かを書いてください。この職種では、そこが仕事の性質を決めます。