プロダクトマネージャーの役割と責任範囲

「ミニCEOではない」という前提から始める理由

プロダクトマネージャーの説明でよく使われる「ミニCEO」という比喩は、権限の広さを強調する一方で、実際の意思決定の境界を曖昧にします。CEOは資本配分と人事の最終権限を持ちますが、PMにはどちらもありません。PMが持つのは「このプロダクトが解決すべき課題は何か」「どの施策から着手するか」を決める権限であり、それを実行するエンジニアリングやデザインのリソース配分そのものはエンジニアリングマネージャーやデザインリードの領分です。

Marty Cagan は著書『INSPIRED』の中で、PMの価値は権限の大きさではなく、顧客・技術・ビジネスの三つの制約を同時に理解し、実現可能でユーザーに愛され事業として成立する製品を見極める力にあると述べています。権限の所在を曖昧にしたまま「何でも決める人」として扱うと、チームはPMに責任を集中させ、結果としてPM自身がボトルネックになります。

PMが実際に持つ責任範囲

持つもの

PMが一次的に責任を持つのは、次の三つに整理できます。第一に、課題定義とその優先順位づけ。第二に、施策がユーザーと事業の両方に効果を持つかどうかの検証設計。第三に、リリース後の指標の解釈と、次に何を試すかの提案です。これらはいずれも「決める」というより「決めるための材料を揃え、根拠を持って提案する」仕事に近いといえます。

持たないもの

一方で、エンジニアの評価・採用、技術アーキテクチャの選定、デザインシステムの運用ルールは、多くの組織でPMの権限外です。予算執行権も、シード期のスタートアップを除けば創業者やファイナンス部門にあるのが一般的です。PMがこれらに口を出す場面はありますが、それは越権であって、職務定義ではありません。責任範囲を明文化していないチームほど、この境界が崩れやすくなります。

ディスカバリーとデリバリーの往復

PMの一週間は、大きく二つのモードに分かれます。ディスカバリーは「作るべきものが正しいか」を、プロトタイプやユーザーインタビューを通じて安く速く検証する活動です。デリバリーは、検証済みのアイデアを実際に開発・リリースするプロセスの管理です。Cagan はこの二つを並走させる「デュアルトラック・アジャイル」という考え方を提唱しており、デリバリー中のスプリントと並行して次の施策のディスカバリーを進めることを推奨しています。

この往復ができていないチームでは、デリバリーだけが回り続け、PMはバックログの交通整理役に固定化されます。ディスカバリーに割く時間が実質ゼロになると、PMの提案はステークホルダーの思いつきをそのままチケット化するだけの作業に近づきます。ユーザーインタビューの具体的な進め方はユーザーインタビューの設計と実施で扱っています。

企業のステージで役割がどう変わるか

アーリーステージ（PMF前）

プロダクト・マーケット・フィット（PMF）に到達する前は、PMの仕事の大半がディスカバリーに寄ります。機能開発よりも「誰のどの課題を解いているのか」を突き詰める比重が高く、創業者自身がPMを兼務することも珍しくありません。

グロースステージ

PMFが見え始めると、指標設計とロードマップの優先順位づけが中心になります。北极星指標（North Star Metric）を軸に、複数の施策をどの順で試すかを決める仕事が増え、専任PMの採用が進むのもこの段階です。

成熟ステージ

プロダクトが複数事業部にまたがる規模になると、PMは自分のプロダクト領域の意思決定に加えて、他チームとの整合性の調整に時間を取られるようになります。新規機能より既存機能の負債整理や指標の防衛（既存の主要指標を落とさない改善）に比重が移る組織も多く見られます。

つまずきやすい点

もっとも多い誤解は、PMを「開発の進行管理者」として採用してしまうケースです。この場合、ディスカバリーの権限も時間も与えられないまま「役割の割に決められることが少ない」という不満が双方に生まれます。逆に、PMに権限を集中させすぎると、他職能の当事者意識が下がり、エンジニアやデザイナーが「言われたものを作るだけ」の姿勢になる副作用もあります。責任範囲は職務定義書だけでなく、実際の意思決定の場でどちらが最終判断者かを都度確認する運用が必要です。ただし、この境界は組織図で一度決めて終わりではなく、プロダクトの成長段階に応じて見直すべきものです。

次に読む

ビジョンと戦略の接続についてはプロダクトビジョン・戦略・ロードマップの違いと接続で扱っています。ディスカバリーの具体的な実施方法はユーザーインタビューの設計と実施を参照してください。