製品が市場から外れる本当の理由は、作りすぎではなく観測不足である

「顧客の声を聞いているのに、なぜ製品は市場から外れていくのか」。この問いへの答えは、顧客理解の不足ではなく、観測する時間と、観測結果を実装する時間の配分を誤っていることにあるかもしれません。

プロダクトマネージャーとプロダクトオーナーの役割分担、そして家計調査や社会生活基本調査のような統計データは、一見すると別々の話に見えます。しかし両者は、組織や社会が変化を捉え、行動を修正するための同じ問題を扱っています。それは、現実を観測し、意味を解釈し、具体的な行動に変換するという問題です。

製品開発で起きる失敗の多くは、データがないことから生まれるのではありません。観測者が実装に埋没するか、実装者が観測から切り離されることで、変化の信号が途中で消えることから生まれます。

製品開発の本当の制約は、時間ではなく観測帯域である

プロダクトマネージャーは通常、市場や顧客の課題を理解し、製品戦略を組み立て、事業上の成果につなげる役割を担います。一方、プロダクトオーナーは、開発チームと密接に協働し、何をどの順番で作るかを具体化する役割に重点を置きます。

両方を一人で担うことは可能です。特に顧客が社内の限られた部署で、利用者の多様性が小さく、要望にも直接アクセスできる場合、その役割の幅は比較的狭くなります。しかし、対象が市場全体に広がると話は変わります。顧客の分類、競合分析、利用データの解釈、将来の需要の予測が必要になり、開発チームとの日々の調整だけでは時間が足りなくなります。

プロダクトマネージャーがプロダクトオーナーの仕事まで深く担うと、負荷が大きく増えることがあります。問題は単なる長時間労働ではありません。より重大なのは、市場を観測するための帯域が失われることです。

開発チームとの会話は、非常に重要です。仕様の曖昧さを解消し、設計上の制約を理解し、実現可能な選択肢を判断するために欠かせません。しかし、その会話に時間を使いすぎると、顧客インタビュー、利用状況の分析、競合の変化の確認、製品戦略の更新が後回しになります。結果として、チームは効率よく作っているのに、作っているもの自体が市場の変化から遅れていくのです。

逆に、プロダクトマネージャーが市場調査や戦略策定に集中しすぎると、開発チームが孤立します。チームは手元にある情報だけで製品を作るしかなくなり、開発サイクルの終盤に「これは意図したものではない」という認識のずれが発生します。

製品開発のボトルネックは、作る能力ではなく、現実から得た信号を作る活動へ正確に届ける能力である。

この視点に立つと、PMとPOの分担は肩書きの問題ではなくなります。それは、組織の観測帯域をどのように設計するかという問題です。

統計は「数字」ではなく、変化の構造を読む装置である

社会の変化を捉えるときも、単一の数字だけを見てはいけません。たとえば感染症の流行期には、交通費、とりわけ鉄道運賃が大きく減少しました。外出の機会が減ったからです。しかし、靴の支出は外出自粛の解除後に元の水準へ戻った一方、口紅は戻りませんでした。

この差は重要です。靴の需要は、外出という行動が戻れば回復しやすい。しかし口紅の需要は、マスクという新しい生活条件によって、使用機会そのものが減少しました。つまり、同じ「外出関連の商品」に見えても、需要を決めている因果構造が違っていたのです。

ここから製品開発に応用できる原則があります。指標が元に戻らないとき、顧客が戻っていないのではなく、顧客の行動を支える環境が変わっている可能性があるということです。

飲食代や旅行代が減少する一方、家庭で購入する酒類や家電への支出が増えたことも同じ構造を示しています。需要は消滅したのではなく、場所を移しました。外食から宅飲みへ、移動を伴う余暇から自宅の快適さへ、消費の重心が移動したのです。

企業が「市場が縮小した」とだけ判断すれば、撤退や値下げという短絡的な対応を選ぶかもしれません。しかし「顧客が何を達成しようとしているか」という目的の水準まで掘り下げれば、別の見方ができます。人々は社交、休息、楽しみ、快適さを求め続けていました。ただし、それを実現する状況と手段が変わったのです。

プロダクトマネージャーが見るべきなのは、機能の利用数だけではありません。利用が減ったとき、顧客の目的が消えたのか、目的を達成する代替手段が現れたのか、あるいは環境によって行動が抑制されているのかを分けて考える必要があります。

たとえばオンライン会議サービスの利用時間が減ったとします。その理由は、需要が消えたからかもしれません。しかし、会議が短時間化した、非同期の文書共有に移った、対面の会議が復活したという可能性もあります。数値は同じ「減少」でも、次の製品戦略はまったく異なります。

開発チームの成熟度は、説明量を決める変数である

ここで、PMとPOの役割分担に戻りましょう。開発チームの成熟度が高く、設計原則、技術標準、レポートの形式、既存コンポーネントの使い方などが共有されている場合、プロダクトマネージャーは高いレベルの意図を伝えるだけで済むことがあります。

「新規利用者が初回設定を完了できるようにしたい」「管理者が異常を早く見つけられるようにしたい」といった目的を共有すれば、チームは適切な設計と実装に落とし込めます。これは、開発者が単に指示を受ける存在ではなく、製品の目的を理解して判断できる存在だからです。

一方で、標準や共通理解がないチームでは、同じ説明では足りません。画面の状態、例外処理、データの定義、レポートの構造まで細かく説明しなければ、意図が失われます。この状況でPMが開発チームに時間を使うことは、必ずしも過剰介入ではありません。翻訳コストが高い組織では、詳細な説明そのものが製品品質への投資になるからです。

ただし、ここにも罠があります。チームの成熟度が低いからといって、PMがすべての詳細を永続的に抱え込めば、組織は成熟しません。PMが仕様を細かく書き続けるだけでは、知識はチームに移転されず、PM自身が単一障害点になります。

必要なのは、個別の仕様を増やすことではなく、繰り返し現れる判断を標準化することです。たとえば、レポートを作るたびに表示形式を説明するのではなく、レポート設計の原則を共同で定める。毎回エラー処理を指示するのではなく、エラーの優先順位と表現規則を決める。こうすれば、PMの時間は個別説明から市場観測へ戻っていきます。

この考え方を、翻訳負債と呼ぶことができます。翻訳負債とは、顧客の目的を開発可能な判断へ変換するために、組織が毎回負担している説明と調整のコストです。標準の不足、用語の不一致、過去の判断の未整理は、すべて翻訳負債を増やします。

翻訳負債が大きい組織では、PMとPOを分けても問題は解決しません。役割間の境界で情報が失われるだけです。逆に、共通の原則と成熟したチームがあれば、一人のPMが市場と開発の両方をある程度つなぐことも可能になります。

変化を読む組織は、三つのループを持っている

製品組織が現実に適応するには、三つのループを分けて設計すると役立ちます。

第一は、観測ループです。顧客インタビュー、利用データ、問い合わせ、競合情報、社会統計などから、何が変化しているかを捉えます。ここでは「何が起きたか」を記録します。

第二は、解釈ループです。観測された変化の背後にある目的や制約を考えます。口紅の支出が戻らなかった理由を、単なる消費意欲の低下ではなく、マスクによる使用機会の減少として理解する段階です。ここでは「なぜ起きたか」を仮説化します。

第三は、実装ループです。仮説に基づいて優先順位を決め、設計し、開発し、検証します。ここでは「何を変えるか」を具体化します。

多くの組織は実装ループだけを細かく管理します。スプリントの進捗、チケットの消化、リリースの頻度は測るのに、観測と解釈の品質は管理しません。その結果、速く作れる組織が、速く間違える組織になります。

三つのループは、同じ人が担当しても構いません。ただし、それぞれに必要な時間と成果物を明示すべきです。観測には調査記録、解釈には仮説と反証条件、実装には受け入れ条件と検証結果を置きます。こうすることで、顧客の声が「要望の一覧」に縮小されず、意思決定の材料として残ります。

社会統計から得られる知見が有用なのは、特殊な状況が通常時には見えない因果関係を浮かび上がらせるからです。企業にとっても、危機や制度変更は単なる障害ではありません。顧客の行動が大きく変わるため、どの価値が本当に必要とされ、どの行動が環境に依存していたのかを観測する機会になります。

もちろん、特殊な状況で得たデータをそのまま将来に適用してはいけません。重要なのは数字を再利用することではなく、変化に対する人間の適応パターンを学ぶことです。需要は、消える、戻る、別の場所へ移る、別の方法で満たされるという複数の動きをします。

今日からできる、観測帯域の再設計

役割やプロセスを大きく変更しなくても、次の実践から始められます。

Key Takeaways

1. PMとPOの仕事を、肩書きではなく時間配分で可視化する
   一週間の時間を、市場観測、顧客理解、戦略、開発チームとの調整、仕様化に分けて記録します。どの役割を担っているかではなく、どのループに時間を使っているかを確認します。

2. 指標の変化を、目的と手段に分解する
   利用率や売上が下がったら、顧客の目的が消えたのか、環境が変わったのか、代替手段に移ったのかを区別します。「減少した」という事実だけで結論を出さないことが重要です。

3. 繰り返し説明している内容を、標準に変換する
   同じ説明が二度以上必要になったら、用語集、設計原則、テンプレート、共通コンポーネントの候補にします。これはPMの負担を減らすだけでなく、チームの判断力を高めます。

4. 各仮説に反証条件を置く
   「顧客はこの機能を求めている」と考えたら、どんなデータが出ればその仮説を捨てるのかを先に決めます。これにより、要望や思い込みが戦略として固定化するのを防げます。

5. 開発速度だけでなく、観測から実装までの遅延を測る
   顧客の変化を発見してから、意思決定し、リリースし、結果を検証するまでの日数を記録します。製品の適応力は、作業速度だけでなく、現実から学習する速度で決まります。

結局、プロダクトマネージャーとプロダクトオーナーの問題は、二つの職種をどう分けるかという話ではありません。社会や顧客の変化を、組織がどれだけ正確に受け取り、解釈し、実装できるかという話です。

一人に役割を集中させることが合理的な場合もあります。顧客が限定され、チームが成熟し、共通の標準があるなら、短い経路で判断できます。しかし市場が広く、変化が激しく、開発チームとの翻訳コストが高いなら、役割の分担と観測時間の保護が必要です。

優れた製品組織とは、最も速く機能を作る組織ではありません。現実が変わったとき、最も早く自分たちの前提を疑える組織です。

顧客の声を聞くとは、要望を集めることではありません。数字の変化の背後にある生活の変化を見つけ、その意味をチームと共有し、作るものを変えることです。製品の未来を決めるのは、誰がPMで誰がPOかではありません。組織が、現実からの信号をどれだけ長く、正確に、途切れなく扱えるかです。