自社プロダクトの売上を伸ばすには、顧客が対価を払うだけの価値を見極め、その価値を適切な時期に届けなければなりません。優れた企画でも開発が遅れれば市場機会を逃し、予定どおりに完成しても顧客が必要としなければ利用は続きません。顧客の課題を見極め、事業上の優先順位を決めるPdMと、実行計画やリスクを管理するPjMが同じ目標を共有してこそ、開発した機能を継続利用や追加契約につなげられます。両者が企画の段階から協力し、リリース後の効果検証まで一緒に進める必要があります。
【関連記事】サイトに来ない顧客をどう測る？AIエージェント時代のマーケティング指標とは
「顧客価値」と「開発力」のどちらが欠けても売上は伸びない
SaaSやWebサービスでは、新機能の公開が成果として報告されがちです。しかし、公開した機能が顧客の課題を解決し、実際に使われ、契約の継続や追加につながるまでは事業上の成果と呼べません。開発が終わっても、顧客への価値提供が終わったわけではありません。
売上が伸び悩む原因を開発速度だけに求めると、リリース後の利用状況や成果を見落とします。必要なのは、顧客が何に困り、なぜ対価を払うのかを見極める構想力と、企画を実行できる計画にまとめ、期限と品質を管理して提供する遂行力です。どちらかが欠けても、プロダクトの成長は途中で止まります。
機能を増やしても顧客が使うとは限らない
顧客が何に価値を感じるか十分に検討していない組織では、要望の多さや声の大きさが開発の優先順位を左右します。営業担当者が持ち込んだ個別の要望、競合製品にある機能、経営者が思いついた企画が次々とロードマップに加わり、開発チームは決められた順番で実装します。予定した機能をすべて公開できれば、プロジェクトとしては成功したように見えるでしょう。
ところが、要望を出した顧客が全体の一部にすぎなかったり、その要望が契約を続ける理由と結びついていなかったりすれば、利用者は増えません。機能が増えたために画面や操作が複雑になり、かえって既存顧客の使い勝手を損なう場合もあります。開発した機能の数やリリース回数だけでは、顧客が得た価値を測れません。
顧客が対価を払う理由を見極めるには、誰がどの課題に困り、利用後に何が変わり、それが事業にどう影響するのかを確認する必要があります。プロダクトマネージャー（PdM）は、市場や顧客を調べ、プロダクトの方向性と開発の優先順位を決めます。Atlassianも、PdMの役割としてプロダクト戦略、ビジョン、ロードマップ、機能の優先順位を挙げています。PdMは機能案を並べるのではなく、顧客と事業の両面から開発する理由を示します。
優れた企画も実現して市場へ届けなければ売上につながらない
顧客の課題を正しく捉えても、計画を実行する力が弱ければ売上にはつながりません。必要な要員を確保できない、他システムとの連携が遅れる、品質を確認する時間が足りない、営業やサポートへの説明が間に合わないといった問題が重なると、リリースが遅れます。開発を急いで不具合が増えれば、利用を始めた顧客の信頼も失いかねません。
企画を実現して市場へ届けるには、開発範囲、期限、要員、予算、依存関係、品質、リスクをまとめて管理しなければなりません。Project Management Instituteは、プロジェクト管理の主要な要素として、スコープの設定、成果物の特定、リスク管理、チーム間のコミュニケーションを挙げています。プロジェクトマネージャー（PjM）は、進捗を集めて報告するだけでなく、遅延や手戻りの兆候を早めに見つけ、必要に応じて計画を修正します。
遂行力が不足すると、市場投入の遅れによって商談を逃すだけでなく、社内の負担も増えます。営業は顧客へ予定の変更を説明し直し、カスタマーサクセスは不具合や問い合わせへの対応に追われ、開発者は機能改善より障害対応を優先せざるを得ません。企画の価値が高くても、顧客が安心して使える状態まで仕上げなければ、売上にはつながりません。
分断された組織では判断が噛み合わない
構想力と遂行力をそれぞれ備えていても、PdMとPjMが別々に動けば問題は残ります。PdMが顧客の要望を受けるたびに開発範囲を広げ、PjMが期限を守るために一部を削るだけでは、要求を追加しては削る状態が続きます。優先する課題と、顧客の反応を確かめるために必要な機能を共有していないためです。
逆に、PjMが実現可能な計画を先に固め、PdMが後から計画に収まる機能を選ぶ体制でも、開発しやすさが優先されます。完成日は明確になっても、なぜ作るのかが曖昧なままです。顧客が必要としているものと開発上の制約を別々に検討しているため、両者の判断が噛み合いません。
この分断は、評価指標によってさらに強まります。PdMを企画数や仕様書の作成数で評価し、PjMを納期の達成率だけで評価すれば、両者は自分の数字を守ろうとします。PdMは要求を増やし、PjMは変更を拒む方が評価されやすくなります。共通の評価指標がなければ、両者は自分の評価を優先し、顧客に必要な機能が後回しになります。
LTVは継続利用や追加契約を含めて評価する
プロダクトの成長を見る際には、一定期間の売上と顧客生涯価値（LTV）を区別します。LTVは、顧客との取引期間全体で得られる価値を示す指標です。Stripeは、顧客が生み出す価値と取引期間を基に、LTVを算出する方法を紹介しています。ただし、利益を含めるか、どの期間で測るかなど、算定方法は事業によって異なります。
SaaSでは、新規契約数だけでなく、顧客維持率、解約率、更新率、既存顧客からの売上も確認する必要があります。利用が定着して契約期間が延び、上位プランや追加アカウントの契約が増えれば、LTVの改善が期待できます。反対に、新規顧客を増やしても短期間で解約されれば、獲得にかけた費用を回収しにくくなります。
ただし、LTVの改善だけで総売上が決まるわけではありません。新規顧客の獲得数、価格、販売体制、市場規模なども影響します。また、継続率や追加契約は、営業、マーケティング、カスタマーサクセス、製品品質などにも左右されます。PdMとPjMが連携するだけでLTVが高まるわけではありませんが、顧客が必要とする機能を開発計画に組み込み、リリース後の結果を次の改善に生かしやすくなります。
PdMとPjMの役割分担
PdMとPjMは、同じプロダクトに関わりながら異なる責任を担います。役割を分ければ、PdMは顧客が必要とするものの見極めに、PjMは開発の実行管理に集中できます。ただし、役割の境界を固定し、仕事を引き渡すだけでは、企画と開発の分断を解消できません。
WhatとWhyはPdM、HowとWhenはPjMという整理は、両者の主な役割を理解するうえで役立ちます。しかし、市場へ投入する時期は事業戦略にも関わり、実現方法は開発上の制約によって変わります。実務では、どの事項を両者で決めるかを定める必要があります。
PdMは顧客の課題と開発の優先順位に責任を持つ
PdMは、市場や顧客を調べ、誰のどの課題を解決するのかを決めます。顧客から要望を集めるだけではありません。要望の背景にある困りごとを確認し、同じ課題を抱える顧客がどれだけいるか、解決によってどのような効果が見込めるか、事業目標とどう関係するかを踏まえて、取り組む順番を判断します。
ロードマップは、決めた方針と優先順位を関係者へ伝えるために使います。Atlassianは、ロードマップをプロダクトのビジョン、方向性、優先順位、進捗を示す戦略的な計画と説明しています。ロードマップは、一度決めたら変更できない機能一覧や納期表ではありません。市場環境や顧客の反応が変われば、目標を達成するために優先順位や開発内容を見直します。
PdMの成果も、提案した機能数や作成した仕様書の量では測れません。新規利用者が目的の操作まで進めたか、対象機能が継続して使われたか、顧客の業務が改善したか、契約の継続や追加に影響したかを確認します。PdMは、機能一覧ではなく、解決する顧客の課題と開発の優先順位を管理します。
PjMは企画を実行できる計画にまとめる
PjMは、合意した目的を実現するために、作業範囲、成果物、期限、要員、予算、依存関係、品質、リスクを管理します。担当者と期限を表に記入して進捗を確認するだけではありません。計画どおりに進まない要因を早めに見つけ、取り得る選択肢と、それぞれが計画に与える影響を整理します。
例えば、外部サービスとの連携が予定より遅れる場合でも、対応方法はすべての機能の公開を遅らせることだけではありません。連携が必要な機能を次回のリリースに回す、代替手段を用意する、対象顧客を限定して先に提供するなど、開発範囲と時期を調整できます。PjMは各案が期限、要員、リスクに与える影響を示し、PdMや開発チームの判断を支えます。
納期を守るために顧客にとって重要な機能まで削れば、予定どおり公開しても利用されません。反対に、価値が高いという理由だけで要求を増やし続ければ、品質や提供時期を守れません。PjMは、顧客に必要な機能を残しながら、開発範囲や日程を調整します。
PdMとPjMの連携
PdMがWhatとWhyを決め、その後でPjMへHowとWhenを任せる体制では、企画の段階で実現できるかどうかを十分に検討できません。PdMは市場投入の時期や効果を確かめる順番まで考える必要があり、PjMはロードマップを作る段階から工数、依存関係、リスクについて意見を出します。Atlassianも、両者が共通の目標と優先順位を持ち、ロードマップを検討する段階から実行上の問題を確認するよう勧めています。
技術面の実現方法は、PjMだけで決めるものではありません。システム構成、実装方式、保守性、性能、セキュリティなどは、エンジニアリングマネージャー、テックリード、開発チームが判断します。PdMは顧客の課題と事業目標を示し、PjMは期限や依存関係を整理し、開発チームは技術面の選択肢と、それぞれの影響を示します。3者で検討すれば、顧客に必要な機能と無理のない開発計画を両立できます。
企画を決めた後で開発チームへ渡す体制では、設計に入ってから制約が分かり、見積もりや納期をやり直す事態が増えます。反対に、技術的に作りやすい案だけで企画を選べば、顧客が必要とする機能を作れません。役割を分けるのは、各担当者を別々に動かすためではありません。企画の早い段階から、それぞれの専門知識を生かすためです。
肩書よりも意思決定権を明確にする
PdM、PjM、Product Ownerの責任範囲は、企業や開発手法によって異なります。Scrum Guideでは、Product Ownerがプロダクト価値の最大化とProduct Backlogの管理に責任を持ちます。Product Goalを伝え、Backlog Itemを明確にし、その順序を決める責任も含まれます。Scrumを採用しただけで、自社のPdMやPjMとの責任分担が決まるわけではありません。
優先順位の最終決定権を複数人に持たせると、意見が割れるたびに上位者の判断を待つようになります。反対に、誰にも決定権がない項目は、問題が起きるまで放置されます。解決する顧客の課題、ロードマップの変更、開発範囲、技術設計、リリース判定、提供後の評価について、誰が案を作り、誰が意見を出し、誰が最終的に決めるのかを明文化する必要があります。
専任のPdMとPjMを置ける組織では、それぞれの責任者を定めます。小規模な組織では、1人が両方を兼任しても構いません。ただし、顧客に必要な機能を選ぶ場面と、期限やリスクを管理する場面を意識して分けなければ、急ぎの案件が常に優先され、長期的な改善が後回しになります。役割を分ければ、同じ案について、顧客が必要としているか、期限内に開発できるかの両面から検討できます。
企画から効果測定までを1つの流れで管理する
PdMとPjMの連携を強めるために、会議や資料を闇雲に増やしても効果はありません。機能案ではなく顧客の課題から考え始め、同じ目標と指標を共有したうえで、どの段階で誰が何を決めるのかを定めます。PdMが顧客の課題と事業目標を示し、PjMと開発チームが工数を見積もり、依存関係とリスクを確認します。リリース後は利用状況を確認し、その結果を次の計画に反映します。
顧客の課題と成果指標を先に決める
最初に、PdMが対象となる顧客と解決したい課題を決め、顧客にどう使ってほしいか、事業として何を達成したいかを整理します。「売上を増やす」「解約を減らす」だけでは、どの機能が必要なのか判断できません。例えば、契約後の初期設定で離脱する顧客を減らす、特定の業務を毎週使ってもらう、社内で利用する部門を増やすなど、顧客の利用状況をどう変えたいのかまで示します。
次に、その変化を確認できる指標を選びます。初期設定の完了率、対象機能の利用率、一定期間後の継続率、解約率、更新率、既存顧客から得る売上などが候補になります。すべてを追うと、どの数字を重視すべきか分からなくなるため、解決したい課題と直接結びつく指標に絞ります。Stripeも、顧客維持を測る指標として顧客維持率、解約率、既存顧客から得られる売上、LTV、更新率などを挙げています。
営業やカスタマーサクセスが把握した顧客の意見や、失注・解約の理由も確認します。利用データと合わせれば、数字が変化した背景を読み取りやすくなります。開発前に評価方法を決めておけば、公開後に、成果が出たように見える数字だけを選ぶことも防げます。
工数とリスクを確認して優先順位を決める
顧客の課題と成果指標が決まったら、PjMと開発チームが必要な工数と要員を見積もり、リスクを洗い出します。他システムとの依存関係、データ移行、法務やセキュリティの確認、営業資料やサポート体制の準備まで洗い出します。公開日だけを先に決めると、後から必要な作業が分かり、品質確認の時間が削られます。
見積もりでは、開発範囲を絞る案、提供時期を分ける案、既存機能を使う案などを比べます。PjMと開発チームが期限、費用、品質、リスクへの影響を示し、PdMが顧客と事業への影響を示します。
優先順位は、顧客からの要望数だけでも、開発工数の小ささだけでも決められません。対象となる顧客、課題の深刻さ、事業への影響、顧客の反応を確かめるために必要な機能、提供時期、技術上のリスクを合わせて判断します。最初から完成形を目指さず、まず必要最小限の機能に絞れば、顧客の反応を早く得られます。ただし、セキュリティ対策や法令への対応、安定した運用に必要な作業まで削ってはいけません。
変更時の判断方法を事前に決める
開発中には、追加要望、見積もりのずれ、技術的な問題、外部サービスの遅延などが発生します。変更を一切認めなければ、状況が変わっても当初の計画を見直せません。反対に、すべての要望を受け入れれば、範囲が広がり続けて期限と品質を守れません。
変更が必要になった場合は、開発範囲、提供時期、要員、品質、リスクへの影響を確認します。PdMは顧客が得られる効果と事業への影響を示し、PjMは計画への影響を整理し、開発チームは技術面の選択肢を示します。そのうえで、残す機能と、変更する範囲や日程を決めます。PdMだけで要求を追加したり、PjMだけで顧客にとって重要な機能を削ったりしないための手順です。
変更時には、選択肢、決定内容、理由、影響、決定者を記録します。後から同じ議論が起きても、当時の前提と現在の条件を比べられます。変更内容と影響を確認すれば、顧客に必要な機能を残しながら、無理のない計画に修正できます。
リリースの速さと顧客の成果を分けて測る
開発工程の状態を確認するには、変更のリードタイム、提供頻度、障害からの復旧時間などを使います。DORAは、これらをソフトウェアを提供する速さと安定性を測る指標として示しています。企画から公開までに時間がかかる、公開のたびに障害が起きるといった問題を捉える際に役立ちます。
ただし、提供頻度が上がっても、顧客が必要としない機能を作っていればLTVは改善しません。開発工程の指標で開発速度と安定性を確認し、利用率、継続率、解約率、更新率などで利用や契約の変化を確認します。2種類の指標を分けて見れば、「必要な機能を決められているが提供が遅い」「提供は速いが顧客の利用が増えていない」といった違いを把握できます。
リリース後は、あらかじめ定めた期間と対象顧客で結果を確認します。利用が伸びない原因には、対象顧客の選び方、操作の難しさ、既存業務への組み込みにくさのほか、営業やサポートからの案内不足もあります。機能追加を決める前に、利用データと顧客の声を照合します。
提供後の結果を次のロードマップに反映する
リリースした時点で開発を終えたと考えると、PdMとPjMは次の案件へ移り、提供した機能の効果を検証しなくなります。利用状況や顧客の反応をカスタマーサクセスだけが把握しても、その情報を次に何を開発するかの判断に生かせません。その状態では、解約や利用停滞の原因が分からないまま、次々と機能を追加するようになります。
提供後の評価では、想定した使われ方や成果を確認できたか、予期しない問題が起きていないか、改善の余地があるかを確認します。成果が出ていれば、提供する顧客を広げ、出ていなければ原因を調べます。そのうえで、機能を改善するのか、提供を停止するのか、別案へ切り替えるのかを判断します。ロードマップと開発計画を更新し、必要なリスク対策を追加します。
共有する資料は、プロダクト目標、ロードマップ、主要指標、リスク、重要な決定事項とその理由に絞ります。会議も、顧客や事業環境の変化を確認する場、開発の進捗とリスクを確認する場、提供後の成果を評価する場に分け、それぞれ必要な関係者が参加します。
PdMとPjMを配置しても、両者が資料作成と調整だけに追われ、決定権が曖昧なままでは事業成果につながりません。開発速度だけを追ったり、リリース後の評価を他部署へ任せきったりすれば、顧客の反応を次の開発に生かせない状態が続きます。顧客の反応を次の企画と開発計画に反映してこそ、PdMとPjMの連携を売上やLTVの改善に生かせます。
まとめ
自社プロダクトの売上を伸ばすには、顧客が対価を払うだけの価値を見極め、期限と品質を管理しながら市場へ届ける必要があります。PdMは顧客の課題を見極めて事業上の優先順位を決め、PjMは開発範囲、期限、要員、依存関係、リスクを管理します。役割を分けても、目標と必要な情報は共有しなければなりません。
企画の初期から、PdMが顧客に必要な機能を示し、PjMと開発チームが工数やリスクを確認します。評価指標と変更時の判断方法を共有し、リリース後の効果も一緒に検証します。利用状況、継続率、解約率、更新率などを確認し、その結果を次のロードマップと開発計画に反映すれば、継続利用や追加契約を通じてLTVの改善を目指せます。
専任のPdMとPjMを置けるかどうかは、組織規模によって変わります。1人が兼任する場合でも、企画と開発管理の責任、意思決定権、評価指標を曖昧にしない運営は可能です。2名を配置するだけで売上が伸びるわけではありません。顧客の反応を開発計画に継続して反映し、提供後の結果に応じて次の企画や開発計画を見直せる体制が、プロダクトの成長を支えます。
参考文献
Product Manager: Role & Best Practices for Beginners
Product manager vs. project manager: Key differences and how they work together
この記事を書いた人
