# プロダクトマネージャーとは

自社の製品やサービスについて、何を開発するか、事業として成立するかを判断し、成果に責任を負う役割です。肩書きより判断の権限と時間の有無が役割の機能を左右し、小さな製品では事業責任者が兼任して開始できます。

## プロダクトマネージャーとは

プロダクトマネージャーの略称はPdM（Product Manager）で、自社の製品について誰のどんな課題を解決し、事業として成立するかを判断し、開発対象を決定する役割です。助言会社SVPG（Silicon Valley Product Group）の整理では、プロダクトマネージャーは[価値と事業としての成立に責任を負い、製品の成果に説明責任を負う人](https://www.svpg.com/four-big-risks/)とされています。

利用者の声やデータで優先順位を設定し、開発しないものも決定します。目的は使用されない機能と事業の行き詰まりの防止です。

プロジェクトマネージャーは期限のある取り組みの[品質、予算、リスクを管理します](https://www.apm.org.uk/resources/what-is-project-management/)。一方、プロダクトオーナーは開発の枠組みであるスクラムで、[製品の価値を最大化することと、作業の一覧の管理に責任を負います](https://scrumguides.org/scrum-guide.html)。飲食店ならメニューと価格を決定する店主がプロダクトマネージャー、新店舗の開業担当がプロジェクトマネージャーに近い立場です。

![プロダクトマネージャー、プロジェクトマネージャー、プロダクトオーナーが責任を負う範囲の比較。プロダクトマネージャーは価値と事業成立、プロジェクトマネージャーは品質・予算・リスク、プロダクトオーナーは価値と作業の一覧に責任を負うことを、●の位置で示す表です。空欄は出典に記載がないことを示し、担当しないとは限りません。](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-02a59f91b644d6e630fc7db2259b3bbd41eaeb4dcc3f1afbfd302185bf62dc95.png)

## なぜ必要か

判断に必要な情報が関係者に分散している場合があります。たとえば顧客の声は営業、事業の数字は経営、技術上の制約は開発者が把握しています。全体を把握する人がいないと要望が個別に開発へ伝達され、機能は増加するのに利用が拡大しない状態になるおそれがあります。

![営業の顧客の声、経営の事業の数字、開発者の技術上の制約がプロダクトマネージャーに集約され、何を開発するかが決定される流れを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-6c5e98312b965020fb5c84c81fdc4b9dcecac2c50fea14abbf1f243231a2595e.png)

確定した機能の一覧を提示されて開発するだけのチームでは、[価値と事業としての成立の責任が、機能を依頼した部署や役員に帰属する](https://www.svpg.com/product-vs-feature-teams/)とされています。SVPGの整理では製品のリスクは[4種類に分類され](https://www.svpg.com/four-big-risks/)、価値と事業としての成立はプロダクトマネージャー、利用しやすさはデザイナー、実現可能性は開発の技術責任者の担当とされています。事業としての成立には費用、販売方法、契約、法令の条件が含まれます。

## 効果とコスト

- 要望の受付と優先順位の決め方を統一し、個別依頼による混乱の低減を目的とする
- 開発する前に利用と採算を検証し、使用されない機能の開発削減が期待できる
- 兼任でも判断の時間が必要になる。専任の新規採用では人件費が増加し、社内異動では元の業務の補充が必要になる。調査や試作には開発者やデザイナーの時間もかかる
- 権限を付与しないと役割が調整に限定される。機能の一覧を提示される体制では[実態がプロジェクトマネージャーに近くなる](https://www.svpg.com/product-vs-feature-teams/)とされる
- 顧客との対話とデータ確認が継続し、計測の仕組みの維持費もかかる
- 要望を却下された部署から不満が出うる。経営の支持がないと却下する判断を継続しにくい
- 事業、顧客、開発を理解した人材の確保に時間を要する場合もある

![プロダクトマネージャーを配置する効果と費用の内訳。要望の窓口を統一し、開発前に利用と採算を検証することで、使用されない機能の開発削減を目的とします。判断の時間、採用の人件費か異動元の補充、調査・試作・計測が費用の内訳です。](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-0a9cf68856e2051c876f34eaaa856f92004713e856449e603165064250cc6478.png)

## 専任の配置と事業責任者の兼任

製品数と開発チーム数がともに1つの小さな製品なら、事業責任者の兼任から開始できます。兼任で十分かは製品の数でなく、判断に時間と知識を確保できるかに左右されます。2007年のSVPGの記事では、[単純な製品を除けば専任を要する仕事量になる](https://www.svpg.com/product-management-vs-product-marketing/)とされています。

兼任で十分な目安は次のすべてに該当する間です。

- 顧客と対話し、利用データを自分で確認する時間を継続して確保できている
- 開発計画を停止せずに優先順位の判断を伝達できている
- リリース後に成果を確認している

1つでも充足できなくなったら、専任の配置か分担の見直しを行います。顧客調査が後回しになっている場合は、開発が停止していなくても同様です。複数の製品や開発チームで、同じ顧客、予算、開発者に関する判断が競合し始めたときも同様です。

![兼任の条件の判断。顧客とデータを確認する時間、開発を停止しない判断、成果の確認の3つをすべて充足すれば事業責任者が兼任を継続し、充足しなければ専任の配置か分担の見直しを行います。](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-692aafcc5cb8f6f80ceac2fc862f2d887fe26d94aaae40d4ab5b6b79cd305b70.png)

### 専任が不要な場合

SaaS（Software as a Service）は、ソフトウェアをインターネット経由で利用する提供形態です。これをそのまま利用する業務や、機能追加のほとんどない社内システムでは、専任が不要な場合もあります。社内向けの製品にも同じ4種類のリスクがあり、それぞれを満たすためのハードルは[商用製品より低いのが普通](https://www.svpg.com/commercial-vs-internal-products/)とされています。専任が不要でも、効果と費用、継続利用の判断を担う業務責任者は、運用を担う情報システム担当とは別に決定します。

## プロジェクトマネージャーやプロダクトオーナーがいればプロダクトマネージャーは不要か

肩書きが異なっても、価値と事業としての成立に責任と権限を備え、判断に時間と知識を確保できる人が製品ごとにいれば十分です。何を開発するかを決定する権限がないプロジェクトマネージャーは、代わりになりません。プロダクトマネージャーがいないスクラムのチームでは、[プロダクトオーナーがその責任の一部を担うことが多い](https://www.atlassian.com/agile/product-management/product-manager)とされています。

次の3点の答えが同じ人を指し、その人に判断の時間と知識があれば、新たに人を配置する必要はありません。

- 機能要望を却下する判断を、最終的に誰が行っているか
- 売上や解約など、製品の数字の責任者は誰か
- 部署や役員の要望に対して優先順位を決定する権限を備えているのは誰か

![要望を却下する人、数字の責任者、優先順位を決定する人が重複する部分は、3つに該当し判断の時間と知識もある人です。その人がいれば新たに人を配置しないことを示すベン図です。](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-b78e1ca8167aac6e84055d56a6cb9ab6a87dc757a314684fe8e5bcde1498222e.png)

答えが人ごとに異なる、誰もいない、時間がない場合は、役割を担う人が不在です。担当者を決定します。

## 要望が競合したときの判断

[大口顧客1社を満足させる一方で小口の顧客100社を不満にさせうる機能](https://www.atlassian.com/agile/product-management/product-manager)を選択するかは、Atlassianの解説で決定の例とされています。特定の顧客の追加要望と、多くの利用者が離脱する操作の改善が競合したときは、発言力でなく次の4点を比較します。

- 影響する利用者の範囲と頻度
- 面談、問合せ、利用データのどれで課題の存在を確認できたか
- 契約の更新や解約、法令対応といった事業への影響
- 運用と問合せ対応を含む費用

確認が不足しているときは小さな試作や一部の利用者への提供で先に検証し、検証後に4点を比較して優先する要望を決定します。

![要望の優先順位を比較する4つの観点を示す図です。利用者の範囲と頻度、課題の裏付けになる面談やデータ、事業への影響、運用込みの費用を比較します。](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-b9346b3a204e2d27c3fb92b8837ea13cb06188664c70b69aff2c91a0ed59a81a.png)


## 委任する範囲と付与する権限

成果への責任とともに、経営がプロダクトマネージャーへ次の権限を付与します。

- 優先順位の最終決定: 部署や役員の要望に対して、開発しない判断もできる
- 顧客と利用データへのアクセス: 必要な範囲を、他部署を経由せずに確認できる
- 成果の指標: 機能の数でなく、利用や売上などのKPI（Key Performance Indicator）、つまり目標への進み具合を測定する指標で評価する
- 予算と人員の枠: 経営が定める。承認された予算の中の優先順位は委任し、追加予算や事業の撤退は経営が決定する

![経営が承認した予算と人員の枠の中に委任する範囲（優先順位の最終決定、顧客・利用データの確認）があり、枠の外の追加予算と事業の撤退は経営が決定することを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-7e3bc4aac4a043ea96c7ece624484e19c4e2b09c780e98a0b005cacaa7b880c0.png)

スクラムではプロダクトオーナーの決定を[組織全体が尊重しなければならない](https://scrumguides.org/scrum-guide.html)とされています。プロダクトマネージャーでも、委任した範囲内の判断を理由なく繰り返し覆すと、役割が機能しにくくなります。戦略や予算、法令の条件が変化したときの見直しは経営の役割です。経営は見直しの手順を最初に明示します。

## よくある誤解

![プロダクトマネージャーの4つの誤解と実際。進捗管理役は開発対象を決定する役、全権を保有は特別な権限なし、技術者だけは経歴が多様、定義は統一は組織で異なります。](https://media.marketing.kdotdev-tunnel.org/glossary-product-manager-e7d2e5e6de08034305496867528657962fdb0adfd670479ac989e03e7f4139ab.png)

### 開発の進捗を管理する人

[進捗の監視や予算の管理](https://www.apm.org.uk/resources/what-is-project-management/)はプロジェクトマネージャーの仕事です。[1日の大半をプロジェクト管理に使用していないか](https://www.svpg.com/product-vs-feature-teams/)は、SVPGの整理では、機能の一覧を提示される体制かどうかを判別する問いの1つとされています。該当する場合は何を開発するかを誰が決定しているか、判断に必要な権限と時間があるかを確認します。

### 製品の最高責任者だから何でも決定できる

英語では製品のCEO（Chief Executive Officer）という比喩が使用される場合も、[特別な権限を保有するわけではない](https://www.atlassian.com/agile/product-management/product-manager)とAtlassianの解説で指摘されています。

### プロダクトマネージャーは技術者でなければ担当できない

プロダクトマネージャーには、[技術、設計、事業、マーケティングなど、さまざまな経歴の人がいる](https://www.atlassian.com/agile/product-management/product-manager)とされています。技術上の制約や費用、期間の違いを理解し、技術責任者と選択肢を比較する知識は必要です。

### 職務の定義は統一されている

統一されていません。Atlassianの解説は、[責任が組織の規模で異なり、役割の内容自体もまだ確定していない](https://www.atlassian.com/agile/product-management/product-manager)としています。採用や配置の前に、判断の内容と権限を自社で明文化します。