市場を見る目と開発する手を分けないと、プロダクトは必ず迷子になる

Hatched by tttt

Jun 25, 2026

1 min read

1 views

86%

その機能、本当に「作るべきもの」ですか？

多くの組織では、プロダクトの失敗は「アイデア不足」から起きると思われています。けれど、実際には逆です。失敗の多くは、何を作るかを考える力と、それをどう実装するかを詰める力を、ひとりの頭の中で曖昧に混ぜてしまうことから起きます。

ここに、見落とされがちな重要な区別があります。データ分析でいうクラスタリングと分類の違いです。まず全体を眺めて「どんなグループがあるのか」を見つけるのがクラスタリング。次に、新しく入ってきたものを「どのグループに入るのか」と割り当てるのが分類です。プロダクト開発もまったく同じで、市場を見て構造を発見する仕事と、開発チームに入ってきた要求を適切な形に落とす仕事は、似ているようで別物です。

この区別が曖昧になると、PMは現場に埋もれて市場を見失い、逆に現場にいなさすぎるとチームは迷走します。つまり問題は、忙しさそのものではありません。問題は、外向きの知覚と内向きの実装を往復する設計がないことです。

プロダクトの失敗は、間違った答えを出すことよりも、そもそも違う問いを解いてしまうことで起きる。

PMとPOは役割分担ではなく、認知モードの切り替えである

PMとPOを単なる肩書きの分担だと考えると、すぐに混乱します。実際にはこの二つは、仕事の種類が違うというより、使うべき認知モードが違うと捉えたほうがうまくいきます。

PMの役割は、外を見ることです。市場はどこへ向かっているのか。顧客は何に困っているのか。競合はどの前提を破壊しようとしているのか。価格や流通、営業やマーケティングはどう動くべきか。PMは、点在する情報をつなぎ合わせて、まだ見えていない地形を地図にする仕事を担います。これはクラスタリングに近い。個別の声を拾うだけではなく、その背後にある構造を発見するからです。

一方、POの役割は、内側で現実を動かすことです。バックログを整え、優先順位を決め、開発チームが迷わず進めるようにする。ここで必要なのは、情報を大づかみにする能力よりも、曖昧な要求を解像度高く分解し、チームが実装可能な形に変換する力です。これは分類に近い。新しく入ってきた要求を、「どの箱に入れるべきか」「どの順番で扱うべきか」「本当に同じ問題群なのか」を見極めるからです。

この二つを同一視すると、プロダクトは壊れます。PMがPOに寄りすぎると、顧客や市場を直接見る時間が消えます。すると、営業からの又聞きや、社内で都合よく加工された要望だけが入力になり、最終的には「便利そうだが使われない機能」が量産されます。逆にPMがPOを軽視すると、チームにはWhyが届かず、開発は推測ゲームになります。レビューの最後に「それは意図していない」でひっくり返る。これは単なるコミュニケーション不全ではなく、市場認識と実装認識の断絶です。

重要なのは、PMとPOを上下関係で考えないことです。どちらが上かではなく、どちらのレンズで今プロダクトを見ているかが本質です。視野が広すぎて焦点が定まらない状態も危険だし、焦点が細かすぎて地図を失う状態も危険です。

なぜ「顧客の声」を聞いても、間違った機能が増えるのか

ここで厄介なのは、顧客の声を聞いているのに、なぜかプロダクトがズレることです。これは矛盾ではありません。むしろ自然な結果です。多くの場合、顧客は解決策を語り、私たちはそれをそのまま要件として受け取ってしまうからです。

たとえば営業が「Aという機能があれば売れる」と言う。これをそのまま信じて作ると、完成したものは立派でも、使われないことがあります。なぜなら、顧客が本当に困っていたのはAではなく、その裏にあるBという課題だったからです。これは分類の失敗というより、そもそもクラスタリングが浅かったと言えます。表面的な要望を似たもの同士で並べただけで、根本にある困りごとの構造を掘れていないのです。

ここで有効なのは、顧客の言葉を「そのまま受け取る」のではなく、「その言葉が発生した文脈」を取りに行くことです。なぜその場面で不便なのか。何を代替しているのか。今はどんな工夫でしのいでいるのか。誰がその問題で最も損をしているのか。こうした問いを重ねると、要望は単体の機能ではなく、行動のパターンとして見えてきます。

たとえば、顧客が「検索を速くしてほしい」と言うとします。表面的には速度の問題です。しかし深掘りすると、実際には「必要な情報にたどり着くまでの不安」が本質かもしれない。ならば答えは単純な高速化ではなく、結果の絞り込み、保存、履歴、推薦の設計かもしれません。つまり、聞くべきなのは要望の表面ではなく、その要望が所属しているクラスターです。

この発想はPMにとって非常に重要です。市場調査、顧客インタビュー、営業同行、サポートの現場観察は、単なる情報収集ではありません。プロダクトの背後にある「問題の地形」を描くための作業です。そしてその地形が見えてはじめて、開発チームは意味のある分類作業に入れます。

バランスとは折衷ではなく、時間の設計である

PMとPOのバランスについて語られるとき、よくある誤解があります。それは、両方をほどほどにやればよい、という考えです。しかし実際には、バランスは平均化ではありません。時間配分の設計です。

PMがPOに偏りすぎると、会議とバックログ更新に追われ、外を見る時間が消えます。顧客との対話が途切れ、競合の変化にも鈍くなる。その結果、プロダクトは内部的には整っているように見えても、外部世界からは少しずつズレていきます。これは、細かい作業を丁寧にやっている人ほど陥りやすい罠です。内部の秩序を整えることに成功するほど、外部の変化を見落としやすくなるからです。

逆に、PMが外の仕事に偏りすぎると、ビジョンは立派でも実装の現場に翻訳されません。開発チームは「何を、なぜ作るのか」がわからないまま、自力で意味を補完するしかなくなります。ここで起きるのは、単なる遅延ではありません。チームの判断基準そのものが不安定になることです。何度も優先順位が変わり、レビューで否定され、成果と顧客価値の接点が見えなくなる。するとモチベーションは下がり、速度も落ちます。

この問題に対する本質的な対策は、根性論ではありません。カレンダーの設計です。週に半日でもいいので、顧客と話す時間と市場を読む時間を先にブロックする。逆に、スプリント計画、レビュー、レトロスペクティブは、単なる会議ではなく、PMがチームの認知と同期するためのインターフェースだと位置づける。ここに意味づけを与えるだけで、役割は大きく変わります。

バランスが崩れるのは、意志が足りないからではない。時間が「どの問いに使われるべきか」を決めていないからだ。

さらに重要なのは、組織の成熟度によって最適解が変わることです。スタートアップ期のように市場自体をまだ作っている段階では、一人が広く深くやるほうが速いことがあります。QAやサポートまで含めて、何でも屋として動く方が合理的な場合もあるでしょう。けれど、規模が拡大し、顧客もチームも増え、複雑性が跳ね上がると、役割の分離が必要になります。外を見る人と、内を整える人を分けなければ、どちらも中途半端になるからです。

本当に必要なのは「役割」ではなく「翻訳」である

ここまでを一段抽象化すると、PMとPOの問題は、実は役割分担の問題ではありません。核心にあるのは翻訳です。

市場の言葉は曖昧です。顧客は問題を語るが、解法は誤っていることが多い。営業は売れる理由を語るが、実際の痛みを十分に掘れていないことがある。経営は成果を語るが、現場で何が起きるかまでは見えにくい。開発は実装可能性を語るが、市場のダイナミクスとは距離がある。プロダクトマネジメントの難しさは、この異なる言語をそのまま並べるのではなく、意味が失われないように変換することにあります。

この視点に立つと、PMとPOの理想像は変わります。PMは市場を観察する人であると同時に、市場のノイズを構造へ翻訳する人です。POは要求を整理する人であると同時に、開発の制約をビジネスの文脈へ翻訳する人です。つまり両者は、別の方向に向いた通訳者なのです。

この翻訳の質を上げるには、二つの原則が役立ちます。

一次情報に触れること
又聞きは圧縮されすぎています。顧客に直接会い、実際の現場を見ることでしか、問題の輪郭は掴めません。
Whyを失わないこと
Whatだけが流通すると、開発チームは局所最適に陥ります。Whyが共有されると、チームは自律的により良い解を考えられます。

この二つを両立できたとき、プロダクトは初めて「作業」ではなく「学習」になります。何を作るかが市場理解を深め、作ったものが次の観察を生む。バックログは単なるタスクの列ではなく、仮説の進化ログになるのです。

Key Takeaways

PMとPOは肩書きの違いではなく、認知モードの違いとして捉える。PMは市場を発見し、POはその発見を実装可能な形に翻訳する。
顧客要望をそのまま機能にしない。必ず「なぜその要望が出たのか」を掘り、問題のクラスターを見極める。
外向きの時間を予定に組み込む。週に半日でも、顧客接点と市場分析を先にカレンダーに固定する。
アジャイルセレモニーを情報共有ではなく同期の場として扱う。スプリント計画、レビュー、レトロスペクティブは、Whyを更新する重要な接点。
組織の成熟度に合わせて役割を変える。小さな組織では兼務が速いこともあるが、成長すると分離が必要になる。

迷わないプロダクトは、よく分けられたプロダクトではない

最終的に目指すべきなのは、PMとPOをきれいに分けた組織ではありません。もっと大事なのは、市場を見る目と、開発する手が、互いに違うことを理解したうえでつながっている状態です。

プロダクトが迷子になるのは、誰かが怠けたからではありません。むしろ真面目に働きすぎて、全体を見る目と局所を整える手を同じ箱に詰め込んでしまったときに起こります。だから問うべきなのは、「誰がPMか、誰がPOか」だけではありません。今この瞬間、私たちはクラスタリングをしているのか、分類をしているのか。外の世界を発見しているのか、内の世界を整えているのか。

この問いを持てるようになると、会議の意味も、顧客訪問の意味も、バックログ更新の意味も変わります。プロダクトとは、機能の集合ではなく、外部世界の構造を内部の行動に変換し続ける装置だからです。そこに気づいたとき、PMとPOの議論はようやく本質に戻ります。役割の争いではなく、世界を正しく読むための分業へ。