小さく始めて、チームで回す プロダクトマネジメント入門
- サービスデザイン
- UX/UIデザイン
- マーケティング
理想的なプロダクトマネジメントを実践したいと思っても、現場では「専門知識がない」「体制が整っていない」といった壁に直面することが少なくありません。
企業で新規事業を立ち上げる際に、経験のない人がプロダクトマネージャーを担うケース。対応部署がまたがり、サービス全体を俯瞰する役割がいないケース。そうした「今いるメンバーでなんとかやっていく」状況は、多くのチームに共通しています。
こうした現場に向けて、2025年8月にコンセントデザインスクール「小さく始めて、チームで回すプロダクトマネジメント入門」と題したオンラインプログラムを開催しました。この記事では、そこでお伝えした「必要なことに絞って、みんなで協力して進める」ためのプロダクトマネジメントの考え方と実践のヒントを紹介します。
プロダクトマネジメントとは何をすること？
私たちは、プロダクトマネジメントを「プロダクトビジョンを達成するために、プロダクトをマネジメントすること」と定義しています。
「プロダクトビジョンを達成する」とは、「ユーザーに価値を届け、その対価として得た収益をさらに価値向上へ投資し続けられる状態」だと考えています。ユーザー価値と事業収益がシーソーのようにどちらか一方に傾くのではなく、互いに高め合う循環が回っている状態です。
その循環を実現するために、プロダクトマネジメントでは次の3つのアクションを行います。
- 1.目標を掲げる：現状とのギャップを明確にする
- 2.注力領域を定める：どこからギャップを埋めるかを決める
- 3.仮説をもって確かめる：実行し、成果を検証する
これはプロダクトマネジメントに限らず、マネジメントの基本動作でもあります。
つまりプロダクトマネジメントとは、「ユーザー価値と事業成果の循環を生み出すために、目標を掲げ、注力領域を定め、仮説をもって確かめ続けること」だと私たちは考えています。
プロダクトマネジメントができていないと？
では、もしプロダクトマネジメントがうまく機能していないと、どんなことが起きるのでしょうか？ ここからは、あるデザイナーの体験談を例に、3つのケースを紹介します。
CASE1：「目標を掲げる」ができていないと……
ある日、カエルくんのもとに会社のえらい人がやって来て、四半期KPIの「ナレッジ投稿数」をとにかく増やすよう指示しました。
プロダクトチームではさっそく会議が始まり、AI生成機能、ポイント付与、ノルマ制など、投稿数を増やすためのアイデアが次々と出てきます。そして、試行錯誤の末、なんとかリリースにこぎ着けました。
ところが、リリース後に聞こえてきたのは残念な評判ばかり。AI生成やポイント付与で記事の質が下がり、ノルマを促すポップアップが邪魔に感じられていたのです。
「投稿数を増やしたかっただけなのに……」ウサ吉くんは悲しみに暮れました。
CASE1のポイント
目標を掲げるとは「誰の／どんな課題を／どんな価値で解決するのか」を明確にすること。
売上や利益といったKPIだけを追っても、プロダクトのビジョンは示せません。短期の数字だけを見て進めてしまうと、本来届けたかった価値を損なってしまうことがあります。
CASE2：「注力領域を定める」ができていないと……
ある日、カエルくんのもとに営業担当者、マーケティング担当者、他部署のメンバーが次々とやって来て、それぞれ改善の要望を伝えました。
どれもよさそうな施策に思えたので、ウサ吉くんたちは手分けして開発を進めました。
しかし数週間後、どの施策も思うように進みません。あちこちから催促が飛んできます。
「いっぺんには進められないよ……」ウサ吉くんは悲しみに暮れました。
CASE2のポイント
限られたリソースを有効に使うためには、注力領域の設定が必要不可欠。
ただしこのケースのように、どの施策も一見よさそうに見える場合は、つい全部やろうとしたり、要望の出どころで優先度を決めてしまったりしがちです。
CASE3：「仮説をもって確かめる」ができていないと……
いろいろな施策に手を付けていたことを反省し、ウサ吉くんたちは投稿数を上げることに集中することにしました。
会議では次々とアイデアが生まれ、チームは意気揚々と開発を進めます。そしてついにリリース。めでたし、めでたし——のはずが……。
ダッシュボードを見ても投稿数は思ったほど伸びていません。
「いろいろ試したのに、何がよくて何が悪かったのかがわからない……」ウサ吉くんは悲しみに暮れました。
CASE3のポイント
仮説をもたずに施策を重ねると、結果の因果が見えず次の一手を打てません。
このケースでは課題を「投稿数アップ」に絞ったものの、検証したい仮説が曖昧で、アイデアを詰め込み過ぎてしまいました。何が効いたのかを確かめるには、「なぜそれをやるのか」「何を成功とするのか」を先に明確にすることが大切です。
ここから始める、プロダクトマネジメント
ウサ吉くんたち、大変そうでしたね……。けれど、似たような経験をしたことがある方も多いのではないでしょうか？
ここからは、そんな状況を打開するために使える“3つの道具”を紹介します。
- 1.目標を掲げるための道具：North Star Metric（NSM）
- 2.注力領域を定めるための道具：フライホイール
- 3.仮説をもって確かめるための道具：MVPキャンバス
1. 目標を掲げるための道具：North Star Metric（NSM）
あなたのプロダクトでは、どんな数値目標を掲げていますか？目標はチームの動きを左右する“羅針盤”のようなもの。設定を誤ると迷走してしまうこともあります。
例えば「購入者数10%アップ」という目標を立てた場合、派手な割引キャンペーンや、極端にいえばダークパターンを使っても数値上は達成できてしまいます。しかし、そうして得た結果は、本当にプロダクトビジョンの実現に近づいたと言えるでしょうか？
そこで登場するのが、North Star Metric（以下、NSMと表記）です。
NSMとは？
NSMは、プロダクトの顧客体験価値を測ることができ、なおかつ、売上などビジネス成果との相関をもつ指標です。「ここを高めればユーザーも自分たちも幸せになる」。そんな北極星のような存在です。
NSMのつくり方
NSMは、4つのステップで設定します。
STEP1｜提案価値の言語化
まず、プロダクトによって提案できる価値を言葉にします。何となく「共通認識がある」つもりでも、チームで話してみると意外とズレがあるもの。あらためてしっかり言語化しましょう。
ウサ吉くんのプロジェクトでの例。「プロダクトが提案できる価値」と合わせて「目指す状態」も言語化。
STEP2｜指標の洗い出し
次に、言語化した価値を数字で表せる指標をできるだけ挙げていきます。この段階では発散を恐れず、幅広く出して構いません。
ウサ吉くんのプロジェクトでの例。さまざまな視点をもつチームメンバーで意見交換するのも成功のコツ。
STEP3｜指標を評価
洗い出した指標を、次の3つの観点で絞り込みます。
- ユーザー価値との関連性
- 事業成果（売上など）との相関
- 測定のしやすさ
ウサ吉くんのプロジェクトでの例。星取り表で評価結果を整理。
STEP4｜NSMの決定
最後に、候補に残った指標をNSMとして掲げた場合、「どんなことが起きるか／どんな状態になれるか」を想像します。その上で「ユーザー側とビジネス側双方にとってよい」ということが示せる指標をNSMに決定します。
ウサ吉くんのプロジェクトでの例。NSMとして機能するかを確認して絞り込んだ結果、NSMは「一定回数以上閲覧された投稿の数」に決定。
最初の一歩を踏み出すヒント
とはいえ、NSMを定めることは、事業全体の“頑張り方”を決めることでもあります。いきなり事業全体を巻き込んで決定するのは、少しハードルが高いかもしれません。
そんなときは、次のような小さな問いから始めてみましょう。
- このプロダクトの価値を、数値で表すとしたらどんな指標になるだろう？
- 現在設定しているKPIは、どんな意図で決められているのだろう？
- このプロダクトならではの独自指標を挙げるとしたら何だろう？
2. 注力領域を定めるための道具：フライホイール
注力領域を決めるのは簡単ではありません。「どこに注力すべきか」という判断も難しければ、ステークホルダー全体の合意を得るのも一苦労です。そこで役立つのが、フライホイールです。
フライホイールとは？
フライホイールとは、プロダクトが持続的に成長していく好循環をモデル化したものです。
もともとは、ジム・コリンズが著書『ビジョナリー・カンパニー2 - 飛躍の法則』で提唱した概念で、Amazonの事例などをきっかけに広まりました。現在では、スタートアップなどの事業立ち上げ時の成長ロジックとして用いられることが増えています。
参考書籍をもとにコンセントで作成。参考：ジム・コリンズ著、山岡 洋一 翻訳『ビジョナリー・カンパニー 2 - 飛躍の法則』（2001）日経BP
ファネルのような直線的なモデルでは、「ゴールに到達したら終わり」という印象を受けがちです。一方で、フライホイールのような循環型モデルは、ユーザーに継続的に価値を感じてもらう仕組みを検討しやすくなります。
フライホイールのつくり方
フライホイールは、次の4つのステップで作成します。
STEP1｜体験価値の基本要素を整理
まずはユーザーにとっての体験価値を整理します。ユーザーが複数タイプいる場合は、それぞれの視点から要素を分解していきます。
ウサ吉くんたちのプロジェクトでの例。閲覧者と投稿者の2タイプのユーザー双方の視点から整理。
STEP2｜アウトカムの循環を描く
洗い出した要素を、プロダクトがコントロールできる“アウトカムの流れ”としてつなげます。例えば「業務効率が上がる」などプロダクト外の要因が強いものはここには含めません。
ウサ吉くんたちのプロジェクトでの例。投稿者と閲覧者のメリットを循環させる形で描いた。
STEP3｜アウトカムの循環を精緻化する
ロジックに飛躍がある部分を見つけ、間を埋めるように具体的な要素を追加していきます。例えば「投稿への反応が増える → 投稿者が増える」といった流れに無理がある場合は、中間要素を挟むことで筋の通った循環に整えます。
ウサ吉くんたちのプロジェクトでの例。飛躍した要素の間に「投稿が社内に広がる」「プロダクトの認知が広がる」などの要素を追加。
STEP4｜KPIを設定する
最後に、各要素に対応するKPIを割り当て、計測可能なフライホイールとして完成させます。
ウサ吉くんたちのプロジェクトでの例。ピンクで追加した要素が計測可能な数値を当てはめる。
最初の一歩を踏み出すヒント
とはいえ、フライホイールをステークホルダー全員で一緒につくり上げるのは、なかなかハードルが高いものです。そんなときは、まずはラフでいいので自分一人で書いてみて、今検討している施策がフライホイールのどこに効くのかを軽く整理してみましょう。
手を動かしてみることが、会話のきっかけにもなり、認識合わせの一歩にもつながります。
3. 仮説をもって確かめるための道具：MVPキャンバス
施策の成果が思うように出ない原因は、仮説が明確でなかったことにあります。仮説があれば、結果が期待通りでなくても「何が正しくなかったか」がわかり、次の改善につなげられます。「プロダクト開発は仮説を検証する実験である」と考えることが大切です。
そこで役立つのが、仮説の整理と検証を可視化できるフレームワークの一つ、MVPキャンバスです。
MVPキャンバスとは？
MVPキャンバスは、MVP（Minimum Viable Product）*をつくることで実験計画を可視化し、何を検証したいのかを整理するためのキャンバス（フレームワーク）です。MVPは、一般的に事業の立ち上げ時に活用されていますが、プロダクト運用フェーズでも役立つ考え方です。
参考：モンスターラボDXブログ「MVPキャンバスの作り方・書き方【テンプレート付き】」（閲覧日：2025年8月20日）
＊MVP（Minimum Viable Product）：最小限の機能で価値を検証するための試作プロダクトのこと。ユーザーの反応から学びを得て改善につなげるための考え方である。
MVPキャンバスのつくり方
MVPキャンバスは、次の3つのステップで作成します。
STEP1｜仮説を洗い出す
まず、検証対象となる仮説を洗い出します。この段階では、実際のデータや裏付けがなくても構いません。あくまで「こうかもしれない」という仮説です。
ウサ吉くんたちのプロジェクトでの例。「どうすれば投稿数を増やせるか」の仮説をみんなで洗い出し。
STEP2｜仮説を決める
洗い出した仮説は、影響度と不確実性の2つの軸で評価します。両方とも高い仮説から優先的に検証するのがポイントです。
- 影響度：仮説が成功または失敗したときにもたらす影響の大きさ。
- 不確実性：事実に基づいていない・推測が多い・前例がないなど、仮説のわからなさの度合い。
影響度も不確実性も高い仮説は、誤っている可能性が高い一方で、事業やユーザー体験の根幹に関わるため、最優先で扱う必要があります。
ウサ吉くんたちのプロジェクトでの例。マッピングの結果から優先する仮説と、検証によって明らかにしたいことを設定。
STEP3｜検証計画をつくる
決定した仮説をもとに、具体的な検証計画を立てます。
MVPキャンバスを活用すると、今何をどのように検証しているのかが常に可視化されます。そのため、思い付きのアイデアに振り回されず、仮説に基づいた意思決定を進めることができます。
ウサ吉くんのプロジェクトでの例。テンプレート機能を一部ユーザーに提供し、1カ月の投稿数の差で検証することに。
最初の一歩を踏み出すヒント
プロダクト開発は、仮説を検証する実験であるという考え方が大切です。
まずは、今検討している機能について「何がわかれば成功と言えるか」を問い直してみましょう。思ったような効果が出なかった場合でも、「効果が出なかったということからこういうことがわかった」と整理できることが重要です。
効果が出ないこと自体は失敗ではなく、学びが得られないことが失敗です。また、アイデア出しのブレインストーミングでは、裏にある仮説や検証したいことも一緒に共有する進め方を取り入れると、より有意義な議論になります。
さいごに
プロダクト開発にはさまざまな専門性をもつメンバーが関わるため、どうしても見えている景色がそれぞれ異なります。だからこそ、考えていることを言語化し、可視化し、チーム全体で目線をそろえることが大切です。
同じ方向を見ながら進めていくことこそが、「みんなでプロダクトマネジメントを小さく始める」ための第一歩になります。今日紹介したツールや考え方を、まずは無理のない範囲で取り入れてみてください。きっと前に進むための手応えがつかめるはずです。
- この記事は、コンセントデザインスクール「小さく始めて、チームで回すプロダクトマネジメント入門」の講演内容をもとに構成・執筆しています。
- 本プログラムのアーカイブ視聴や再演に関するご希望があれば「お問い合わせ」よりご相談ください。
[ 執筆者 ]
-
2015年よりエンターテインメント事業会社でデザイナーとして就業したのち、2018年にコンセント入社。2020年よりProduct Design group チームマネージャー。
新規事業開発プロジェクトに多数参加し、UX/UIデザイナーとしてアプリケーション開発に主に携わる。日経クロストレンドにて「『ダークパターン』予防線」（2022）を連載のほか、講演等ダークパターンに関する啓発活動の実績多数。 -
クライアントの組織開発支援、コンセプト開発支援など、幅広いプロジェクトに従事。
過去には、事業会社でのデザイン組織立ち上げ、社内へのUXデザインプロセス導入や、新規事業立ち上げに伴うコンセプト開発、プロダクトマネジメントなどを担当する。 -
作画担当。年のコンセント入社後、企業の社内報の編集ディレクションや雑誌デザインの進行管理など紙媒体のプロジェクトに関わる。その後、ウェブ領域のディレクターとして編集の経験を活かしつつ、アクセス解析などのデータ分析をもとにした情報設計やコンテンツ制作に従事。現在は媒体を問わず、幅広く企業のコミュニケーション戦略支援に携わる。
