プロダクトマネジメントトライアングルとは｜3つの軸で PM の役割を理解する

プロダクトマネジメントトライアングルとは

3つの軸で PM の責任範囲を可視化

プロダクトマネジメントトライアングルは、プロダクトマネージャーが向き合う3つの領域を三角形で表現したフレームワークです。その3つの軸は、ビジネス（Business）・ユーザー（User）・テクノロジー（Technology）です。PM はこの3つの交点で意思決定を行い、それぞれの領域のステークホルダーと協働しながらプロダクトを成長させていきます。

このフレームワークの特徴は、PM の責任範囲を「3つの独立した視点」として明確に分離することにあります。営業やマーケティングはビジネス視点、デザイナーはユーザー視点、エンジニアはテクノロジー視点に偏りやすいのに対し、PM はこれら3つすべてを同時に考慮する必要があります。

なぜこのフレームワークが必要か

PM の役割は企業によって定義が異なり、「営業寄り」「エンジニア寄り」「デザイン寄り」など、組織によって期待値がぶれやすい職種です。プロダクトマネジメントトライアングルは、この曖昧さを解消し、PM が本来向き合うべき3つの領域を明示します。

また、チーム間の期待値ズレを防ぐ効果も大きいです。営業から「売上を最優先にしてほしい」という要望が来たとき、PM は「ビジネス軸だけでなく、ユーザー満足度とテクノロジーの実現可能性も同時に考慮する」という判断基準を持つことで、説得力のある意思決定ができます。

プロダクトマネジメントトライアングルの3つの軸

ビジネス軸（Business）

ビジネス軸は、売上・利益・市場シェア・顧客獲得コスト（CAC）・ライフタイムバリュー（LTV）といった経営指標を指します。PM はこの軸を通じて、プロダクトが事業目標の達成にどう貢献するかを常に問い続けます。

具体的には、新機能の企画時に「この機能は月間経常利益にいくら貢献するか」「競合との差別化につながるか」「顧客の継続率を高めるか」といった問いを立てます。また、プロダクトロードマップの優先順位付けも、ビジネス軸の視点から「どの施策が事業成長に最も寄与するか」を判断する重要な職責です。

ユーザー軸（User）

ユーザー軸は、顧客ニーズ・満足度・ユーザー体験・NPS（Net Promoter Score）といった、ユーザーの視点から見たプロダクトの価値を指します。PM はこの軸を深掘りするため、ユーザーリサーチ・インタビュー・ユーザーテストを継続的に実施します。

ユーザー軸を軽視すると、プロダクトは「企業が売りたいもの」になり、「ユーザーが本当に欲しいもの」とズレていきます。PM の重要な職責は、ユーザーの潜在ニーズを引き出し、それをビジネス価値に変換することです。定性的なユーザーフィードバックと定量的な利用データの両方を組み合わせることで、ユーザー軸の理解が深まります。

テクノロジー軸（Technology）

テクノロジー軸は、技術的実現可能性・開発効率・システムアーキテクチャ・技術負債といった、エンジニアリング視点からのプロダクト開発の制約と機会を指します。PM はエンジニアと密に協働し、「理想的な機能」と「技術的に実現可能な機能」のギャップを理解する必要があります。

テクノロジー軸を無視して機能を積み重ねると、開発速度が低下し、バグが増え、保守コストが膨らみます。逆に、エンジニアの技術的な興味だけで開発を進めると、ビジネスやユーザーニーズと乖離したプロダクトになります。PM の役割は、この軸とビジネス・ユーザー軸のバランスを取ることです。

3つの軸のバランスが PM の成功を決める

ビジネス偏重の落とし穴

短期的な売上最大化を優先すると、ユーザー満足度が低下します。例えば、広告を過剰に挿入したり、有料機能を増やしすぎたりすると、ユーザーは離れていきます。また、ビジネス目標を達成するために無理な機能要望をエンジニアに押し付けると、技術負債が蓄積し、長期的には開発速度が鈍化します。

ビジネス偏重の PM は、短期的には成果を出すかもしれませんが、プロダクトの持続的な成長を損なわせます。

ユーザー偏重の落とし穴

ユーザーニーズへの対応に注力しすぎると、事業採算性を見失います。「ユーザーが望むなら実装する」という姿勢では、利益を生まない機能が増え、プロダクトの方向性が定まりません。また、ユーザーの要望を無批判に受け入れると、実装難度を軽視してしまい、エンジニアチームの負担が増加します。

ユーザー偏重の PM は、ユーザーからの評判は良いかもしれませんが、事業を成長させることができません。

テクノロジー偏重の落とし穴

技術的に優れたプロダクトでも、ユーザーニーズとズレていれば、市場では受け入れられません。また、テクノロジー偏重の PM は、技術的に面白い機能開発に時間を費やし、ビジネス価値を生まない施策に資源を配分してしまいます。

テクノロジー偏重の PM は、エンジニアからの信頼は厚いかもしれませんが、プロダクトの事業成長に貢献できません。

実務での活用方法

機能企画時の検証フレームワーク

新機能を提案するときは、プロダクトマネジメントトライアングルの3つの軸で検証します。「この機能はビジネス価値があるか」「ユーザーニーズを満たすか」「技術的に実現可能か」という3つの問いに、すべて Yes と答えられる施策のみ優先度を上げます。

1つの軸でも No が出た場合は、その軸の課題を解決するか、施策自体を見直す必要があります。例えば、ユーザーニーズは高いが技術的に実現困難な機能であれば、段階的な実装計画を立てるか、別のアプローチを検討します。

ステークホルダー調整の指針

営業（ビジネス視点）、デザイナー（ユーザー視点）、エンジニア（テクノロジー視点）の意見が対立するのは、各ステークホルダーが異なる軸を優先しているからです。プロダクトマネジメントトライアングルの枠組みを使うと、この対立を構造化できます。

「営業は売上を優先したいが、デザイナーはユーザー体験を優先したい」という対立は、「ビジネス軸とユーザー軸のどちらを優先するか」という明示的な議論に変わります。PM はこの議論を主導し、「今のプロダクトステージでは、どの軸に投資すべきか」を判断します。

プロダクト戦略の定期レビュー

四半期ごとに、現在のプロダクトが3つの軸のどこに偏っているかを可視化します。例えば、過去3ヶ月間の施策を振り返り、「ビジネス軸に 60%、ユーザー軸に 30%、テクノロジー軸に 10% の投資をした」というように分析します。

この分析から、不足している軸への投資を計画します。テクノロジー軸への投資が少なければ、技術負債の解消やアーキテクチャ改善に注力する四半期を設定します。ユーザー軸への投資が少なければ、ユーザーリサーチやUX改善に予算を配分します。

プロダクトマネジメントトライアングルと他のフレームワークの関係

OKR との組み合わせ

プロダクトマネジメントトライアングルは「何を考慮すべきか」の枠組みであり、OKR（Objectives and Key Results）は「何を目指すか」の目標設定フレームワークです。両者は補完関係にあります。

例えば、OKR で「月間経常利益を 20% 増加させる」という Objective を立てたとき、プロダクトマネジメントトライアングルを使うと、「ビジネス軸でこの目標を達成しつつ、ユーザー満足度を維持し、技術負債を増やさない施策は何か」という問いが立てられます。両者を組み合わせることで、バランスの取れた戦略立案が可能になります。

ユーザージャーニーマップとの違い

ユーザージャーニーマップはユーザー軸に特化したフレームワークで、ユーザーが製品やサービスと接触する一連のタッチポイントを可視化します。一方、プロダクトマネジメントトライアングルは、ビジネス・ユーザー・テクノロジーの3軸全体を俯瞰します。

ユーザージャーニーマップは、ユーザー軸を深掘りするときに有効ですが、ビジネスやテクノロジーの視点は含まれません。PM は両方のフレームワークを使い分け、ユーザー軸を詳細に理解しつつ、他の軸とのバランスを取ります。

PM キャリアを磨くために

3軸のバランス感覚が採用面接で評価される

PM の採用面接では、「ビジネスとユーザーのトレードオフをどう判断するか」「技術的な制約がある中で、どう優先順位を付けるか」といった質問が頻出します。プロダクトマネジメントトライアングルの理解があれば、これらの質問に対して、構造化された思考プロセスを示すことができます。

「短期的な売上と長期的なユーザー満足度のバランスを、どう考えるか」という質問に、「プロダクトマネジメントトライアングルの3軸を考慮して、現在のプロダクトステージに応じて判断する」と答えられれば、論理的で視野の広い PM として認識されます。

転職時の職務経歴書での活用

過去の施策を「3軸のどこに価値があったか」で整理すると、PM としての視点の広さが伝わります。例えば、「新機能 X を企画・実装した。ビジネス軸では月間売上を 15% 増加させ、ユーザー軸では NPS を 8 ポイント向上させ、テクノロジー軸では開発効率を 20% 改善した」というように記述すれば、バランスの取れた PM であることが明確に伝わります。

Granty の PdM 特化エージェントサービスは準備中です。サービス開始まで、どうぞご期待ください。