プロダクト開発は、組織にセンサーとアクチュエーターを埋め込む仕事である

「優秀なチームなのに、なぜ顧客の役に立たないものが次々と完成するのか」。この問いに対する答えは、技術力や努力不足ではないかもしれません。組織が、現実を感じ取る仕組みと、感じ取ったことに基づいて動く仕組みを、別々のものとして扱っているからです。

人工知能を考えるとき、私たちはつい高度な推論や生成能力に目を向けます。しかし、知的なシステムの基本はもっと素朴です。環境を感知するセンサーと、環境に作用するアクチュエーターがあり、経験やデータを通じて行動の質を高めていく。プロダクト開発の組織にも、ほとんど同じ構造があります。

顧客、市場、事業の変化を読み取るのがセンサーです。開発チームとともに、優先順位を決め、ソフトウェアを世の中に送り出すのがアクチュエーターです。この二つをつなぎ、学習できる循環を設計することこそ、PMとPOの分業を理解する本質ではないでしょうか。

優れたプロダクト組織とは、最初から正しい答えを知っている組織ではない。現実から学び、次の行動を変えられる組織である。

PMとPOの違いは、肩書きではなく知覚と行動の違い

PMは「何を作るか」「なぜ作るか」に責任を持ちます。顧客の困りごと、市場の変化、競争環境、事業上の機会を見ながら、製品が向かう方向を定める役割です。POは、開発チームが「今、何を優先して作るか」を決められるように、要求を具体化し、順序を整理し、日々の判断を支えます。

この違いは、戦略と実行という単純な二分法ではありません。より正確には、PMは外部世界に対する感知の責任を持ち、POは感知した情報を開発という行動へ変換する責任を持つのです。

もちろん、PMも行動の結果を見なければなりません。POも顧客価値を理解しなければなりません。二人の役割は完全に分離された箱ではなく、同じ学習ループの異なる場所です。PMが市場を見ず、POがチームの現実を見なければ、ループは切断されます。

たとえば、経営陣が「若年層向けの新機能を作る」と決めたとします。PMが顧客インタビューや利用データから、本当の課題が「機能不足」ではなく「初回利用時の不安」だと発見できれば、作るべきものは変わります。POはその発見を、画面の振る舞い、ユーザーストーリー、受け入れ条件、実装順序へと翻訳します。

ここで翻訳が失敗すると、開発チームは極めて効率的に間違ったものを作れます。仕様は明確で、進捗も順調で、品質も高い。しかし、解いている問題が顧客の問題ではない。これは開発の失敗というより、センサーからアクチュエーターへの接続不良です。

組織はロボットに似ている。ただし、壊れ方が見えにくい

ロボットは、センサーで周囲を感じ取り、アクチュエーターで周囲に働きかけます。障害物を検出すれば停止し、位置を測れば進路を修正する。センサーがなければ、ロボットは目隠しされたまま動きます。アクチュエーターがなければ、状況を正確に把握していても何も変えられません。

プロダクト組織も同じです。顧客の声、利用ログ、解約率、問い合わせ、営業現場の観察はセンサーに相当します。優先順位、設計、実装、リリース、価格変更、サポート改善はアクチュエーターに相当します。

しかし組織の問題は、ロボットの故障より発見しにくいものです。センサーが壊れていても、会議資料やロードマップは作れます。アクチュエーターが弱くても、議論や分析は続けられます。その結果、誰もが忙しいのに、システム全体は学習していないという状態が生まれます。

典型的な症状は三つあります。

第一に、顧客情報が意思決定の材料ではなく、報告資料になっていることです。インタビューを何十件実施しても、その結果が優先順位に影響しなければ、情報は単なる装飾です。

第二に、バックログが価値の一覧ではなく、依頼の墓場になっていることです。項目が増えるほど、何を捨てるべきかが見えなくなります。POが優先順位を決めるとは、すべての要求を受け入れることではなく、限られた時間で何を選ばないかを明確にすることです。

第三に、リリースが学習の機会ではなく、完了の儀式になっていることです。機能を公開した時点を成功とみなし、その後に顧客の行動がどう変わったかを確認しない。これでは、行動しているだけで経験から学んでいないシステムになります。

機械学習では、データが増えるにつれて特定のタスクの性能が向上します。ただし、データを集めるだけでは学習になりません。どの結果を評価するのか、どの行動を改善するのか、データを次の判断へどう反映するのかが必要です。プロダクト組織でも、顧客の声を集めること自体に価値があるのではありません。観測、判断、行動、結果の評価が反復されるときに初めて、組織は学習します。

最大の問題は、役割の兼任ではなく、時間軸の断絶である

現実には、一人がPMとPOを兼任することも珍しくありません。小さなチームでは合理的な選択です。問題は、兼任そのものではありません。問題は、中長期の問いと短期の問いを、同じ会話の中で切り替えられなくなることです。

PMが考えるのは、四半期や半年の視点です。どの顧客問題を選ぶのか。どの市場で勝負するのか。製品の成功を何で測るのか。POが扱うのは、数週間単位の視点です。次のスプリントで何を作るのか。どの仕様を明確にするのか。どの技術的制約を先に解消するのか。

この二つを同じ人物が担う場合、短期の緊急性が中長期の重要性を食い尽くしやすくなります。朝から仕様確認、午後は進捗調整、夕方は障害対応という日々を過ごしていると、顧客と話す時間が最初に削られます。するとセンサーが鈍り、開発チームへの指示だけが精密になります。

逆の問題もあります。顧客の課題や市場の話ばかりをして、開発チームが実際に何週間で何を作れるのかを理解しない状態です。この場合、戦略は魅力的でも、アクチュエーターに過大な命令を送ることになります。チームは要求の意味を理解できず、手戻りと疲弊が増えます。

兼任を前提にするなら、個人の能力に頼るのではなく、二つの時間軸を意図的に分ける必要があります。たとえば、毎週のバックログ会議では実装可能性と優先順位を扱い、隔週の顧客レビューでは問題の重要性と仮説の妥当性を扱う。会議を増やすことが目的ではありません。異なる問いを混ぜないことが目的です。

実務では、次の四つの問いを一枚の表に置くと役割の混線が見えやすくなります。

1. 顧客にとって、どの問題が最も重要か。
2. その問題が重要だと判断した根拠は何か。
3. 次の数週間で、どの行動を実行できるか。
4. 実行後、何が変われば仮説を更新するのか。

一番上の問いが曖昧なまま、三番目だけを細かくしてはいけません。一方で、一番目の問いに答え続けて、三番目を先送りしてもいけません。プロダクト開発の成熟度は、戦略の壮大さでも、開発速度だけでもなく、この四つの問いを短い周期で接続できるかによって決まります。

「正しい仕様」より、修正可能な循環を設計する

多くの組織は、開発の前に正解を確定しようとします。要件を詳細に書き、承認を重ね、変更を減らそうとする。しかし、不確実性の高いプロダクトでは、これは安心感を増やしても正確さを増やしません。現実についての知識が少ない段階で細かく決めるほど、誤りを高いコストで実装する危険があります。

ここで重要なのは、最初から完璧なセンサーを作ることではありません。誤った感知を、早く安く訂正できる循環を作ることです。

たとえば、オンライン学習サービスが「受講者は進捗を可視化したい」という仮説を持ったとします。いきなり複雑なダッシュボードを作るのではなく、まず簡単な進捗表示を公開し、表示を見た人が継続率や学習時間にどのような変化を示すかを見る。結果が弱ければ、必要なのは色やグラフの改善ではなく、そもそも受講者が求めていたのは進捗ではなく、次に何をすべきかの明確さだったと理解することかもしれません。

このときPMは、結果を事業上の意味に戻します。仮説は支持されたのか。問題の定義を変えるべきか。POは、次の実験をどの小さな単位で実装できるかに変換します。開発チームは、単に要求を消化するのではなく、学習のための行動を実行します。

この構造では、リリースの価値は機能の完成ではなく、不確実性の削減にあります。完成したものが大きいほど価値が高いとは限りません。顧客の反応を通じて、次の意思決定を明確にできるなら、小さなリリースにも大きな価値があります。

もちろん、すべてを実験扱いすればよいわけではありません。決済、個人情報、医療、安全に関わる機能では、検証の速度より信頼性や規制遵守が優先されます。重要なのは、どの領域でどの程度の誤りが許されるかを明示することです。学習速度とは、無謀に作る速度ではなく、許容できるリスクの範囲で観測と修正を繰り返す速度です。

強い組織を作るための実践原則

PMとPOの関係を改善するには、肩書きを整理するだけでは足りません。組織の情報が、顧客から開発へ、開発から顧客へ循環する設計に変える必要があります。

まず、成果物ではなく判断を管理することです。ロードマップに機能名だけを書くのではなく、その機能によって何を学びたいのかを記載します。バックログの項目にも、実装内容だけでなく、解決したい顧客問題と成功指標を含めます。

次に、顧客接点をPMだけの仕事にしないことです。POやエンジニアが顧客の言葉を直接聞くと、仕様の背後にある状況を理解しやすくなります。反対に、PMが開発の議論に参加すれば、顧客価値を実装可能な単位に落とす難しさを理解できます。役割を分けても、知識を分断してはいけません。

さらに、観測可能性をプロダクトの一部として設計することです。機能を作るなら、利用されたか、どこで離脱したか、誰に価値があったかを確認できる状態まで作る。測定できない機能は、完成していても学習装置としては不完全です。

そして最後に、優先順位の変更を失敗の証拠とみなさないことです。新しいデータによって順番が変わるなら、それはセンサーが働いた結果かもしれません。変更を嫌う文化では、人々は間違いを隠し、古い計画を守るために新しい現実を無視します。

良い計画とは、変更されない計画ではない。変更すべき条件が、あらかじめ見える計画である。

Key Takeaways

1. PMとPOを肩書きではなく、学習ループ上の役割として定義する。PMは外部世界の変化と顧客価値を捉え、POはそれを開発チームの具体的な行動へ変換する。
2. すべての優先順位に根拠と検証方法を添える。「重要だから作る」ではなく、何が重要なのか、なぜそう言えるのか、作った後に何を見て判断を更新するのかを書く。
3. リリースを完了ではなく観測の開始と捉える。公開後に顧客行動を確認できない機能は、組織に学習をもたらさない。
4. 中長期の問いと短期の問いを分けて扱う。方向性を決める場と、次の数週間の実装を決める場を混ぜない。それぞれの結論が相互に更新される構造を作る。
5. 小さく作る目的を、開発速度ではなく不確実性の削減に置く。小さな実装で重要な仮説を検証できるなら、それは単なる最小機能ではなく、学習のためのセンサー付きアクションである。

プロダクト開発を、機能を作る仕事だと考えると、PMは要求を集め、POは仕様を整理し、エンジニアは実装するという分業に見えます。しかし、プロダクトを学習するシステムだと考えると、別の景色が見えてきます。

PMは組織の目や耳です。POは、知覚を行動に変える神経系に近い存在です。開発チームはアクチュエーターであり、リリースは環境に働きかける動作です。そして顧客の反応は、次の判断を変えるためのフィードバックです。

この見方に立てば、優れたプロダクト組織の問いも変わります。「誰がPMで、誰がPOか」ではなく、「私たちは現実をどこで感じ、誰がどのように行動へ変え、結果から何を学んでいるか」と問うべきです。

最も危険な組織は、動いていない組織ではありません。正確なセンサーを持たないまま、強力なアクチュエーターで走り続ける組織です。反対に、未来を作れる組織とは、現実をよく観測し、小さく作用し、結果によって自分の考えを変えられる組織です。プロダクトの知性は、個人の頭脳だけに宿るのではありません。観測と行動の間に、どれほど質の高い学習の循環を設計できるかに宿るのです。