名ばかりPdMが生まれる3つの共通点｜採用前に潰す組織側の穴

「PdMを採用したのに、なぜか事業が伸びない。」——個人の能力不足に帰着させがちだ。だが現場を見ると、権限・指標・意思決定の場がないまま肩書きだけ置いていることが多い。

名ばかりPdMは、採用ミスというより組織設計の失敗として先に潰す。

共通点は、決める権限がない・成功指標が複数・エンジニアリングと分断、の3つだ。

3つの共通点

1. 決める権限がない: 優先順位の最終決裁が経営や営業に残り、PdMは調整係になる
2. 成功指標が複数／曖昧: 「全部大事」で、捨てる機能を決められない
3. 開発と分断: 仕様を投げて終わり。技術的制約がプロダクト判断に戻らない

深掘り事例

匿名化した一例。従業員80名のB2B。PdMを中途採用し、ロードマップ作成を依頼。だが価格・契約・開発優先度の決裁は別部門。PdMの提案は「参考」扱いで、四半期ごとに同じ機能リストが積み上がった。6ヶ月後に退職。

分岐点は採用前だ。決裁範囲（何を独断で止められるか）と、成功指標1つを先に書いていれば、採用要件も変わっていた。名ばかりを生んだのは、職務記述書の「プロダクトをグロースさせる」という一文の空虚さだった。

構造的原因

• 肩書きで安心したい経営側の需要
• 指標なき「スピード」文化
• EM／CTO不在で、技術との往復が起きない

PdM／EM／CTO代行の境界（短く）

役	主責任
PdM	何を作る／作らない（仮説と指標）
EM	チームが毎週前に進む仕組み
CTO代行	投資と技術リスクの経営接続

境界が曖昧なまま三人分の期待を一人に載せると、名ばかりが固定する。

判断軸

採用・配置を進める	先に組織を直す
決裁範囲と指標1つが書ける	調整役が欲しいだけ
開発との定例に決裁者が出る	仕様投げのみの文化
捨てる機能の権限がある	全ステークホルダー満足が必須

次に確認すること

1. PdMが独断で止められる範囲は何か
2. 成功指標は1つか
3. 開発リーダーとの意思決定の場はあるか
4. 職務記述に「調整」しか書いていないか
5. EM／技術顧問との役割重複はないか

まとめ

名ばかりPdMは、優秀な個人を入れれば消える現象ではない。権限・指標・技術との往復が欠けた組織に肩書きを足すと起きる。採用の前に、穴を一文で書く。

---

組織・役割設計の相談は、お問い合わせフォーム からどうぞ。