AIはプロダクトチームに、うらやましい問題をもたらした。ほぼ何でも作れるようになった一方で、あまりにも多くを作れてしまうのだ。
かつては議論やデザイン、エンジニアリングに何週間もかかっていたプロトタイプが、今では昼食前に完成することもある。要件定義書や顧客フィードバックの要約、利用状況の分析データなども、はるかに迅速に届くようになった。これは一見、純粋な恩恵のように思えるが、優れたアイデアを加速させるツールは、悪いアイデアも同じスピードで加速させる。しかも、悪いアイデアが洗練された形で提示されるようになるのだ。
これにより、プロダクトマネジメントの重心が変化する。かつては、開発リソースの限界という「制約」が、粗削りながらも有用な規律として機能していた。ウィッシュリストがどれほど膨らんでも、実際に開発されるのはそのほんの一部にすぎなかったからだ。しかし現在、その制約はより上流のプロセス、すなわち「そもそも何を作る価値があるのか」という判断へと移行している。
その影響はプロダクト部門にとどまらず、はるかに広範囲に及ぶ。
変わるプロダクトマネジャーの立ち位置
ソフトウェアにおいて、プロダクトマネジャーの仕事は顧客、事業、エンジニアリングが交差する場所にある。ユーザーが何を必要としているのかを見極め、それを優先順位に落とし込み、チームが一貫性のあるものを出荷できるよう支援する役割である。
筆者と同僚は、銀行、決済、ライブエンターテインメント、物流、テクノロジー分野のソフトウェアプロダクトマネジャーに取材した。その中には、JPモルガン・チェース、ビザ（Visa）、Cashea、ハイネケン、TKO、Super Dispatchの関係者も含まれる。各社は規模、規制上の負担、AI成熟度の面で大きく異なるが、1つの点では一致していた。AIはプロダクトマネジャーが「できること」を広げ続けており、それによって「何をすべきか」を決めることの価値が高まっている、という点である。
スポーツ・エンターテインメント企業TKOのプロダクトマネジャーであるジェニファー・ジェームズは、発見から初期デザインまでの1週間分の作業を、プロンプト入力とプロトタイピングにより約5時間に圧縮したと語る。自動車輸送管理プラットフォームのSuper Dispatchでは、クリスティーナ・ロドリゲス・グティエレスがAIを使ってプロダクトデータを分析し、要件を可視化し、コードベースに直接クエリを実行している。JPモルガン・チェースのスレヤ・カタバトゥーニは、Figmaファイルからドキュメントを生成するワークフローを構築した。チームが先にデザインし、要件を後から書くことが増えているためだ。
職種の境界線はあらゆる場所で曖昧になっている。OpenAIがChatGPT上の仕事関連のメッセージ80万件以上を分析したところ、特定の職種に関するメッセージの43.5%が、従来は別の職種に関連付けられていたタスクに関するものであることが分かった。プロダクトマネジャーは、かつてデザイナー、アナリスト、エンジニアを必要とした仕事に取り組めるようになり、他部門のメンバーも同じくらい容易にプロダクト業務に踏み込んでくる。
可能性が増えるほど、選択は難しくなる
個人の生産性向上は大きい。だが、戦略上の成果ははるかに不確実である。
ProductPlanが約250人のプロダクト専門家を対象に実施した2026年の調査によると、AIの利用は顧客フィードバックの要約や調査結果の生成に集中している。顧客の課題解決やロードマップ作成といった上流工程の作業にAIを活用している人は極めて少なかった。AIはシグナルの処理能力においては非常に優れているが、どのシグナルに資金やエンジニアを投入すべきかを選択するのは、依然として主に人間の判断に委ねられている。
ベネズエラのフィンテック企業Casheaのプロダクトマネジャー、リカルド・ブランチは、重要なリスクを指摘する。機能の追加が容易になると、機能の肥大化を招きやすくなるということだ。彼の見解では、今後勝ち残る企業は、顧客を最も深く理解している企業である。なぜなら、誰もが迅速に機能をリリースできる環境においては、「そもそもどの顧客の課題を解決する価値があるのか」を知ることこそが、優位性につながるからだ。
したがって、実行スピードが加速するにつれて、深い顧客理解の重要性は下がるどころか、むしろ増している。大量のフィードバックが寄せられたとしても、何を作るべきかを教えてくれるわけではない。顧客は自らの現在の体験に基づいて、機能の要望、不満の表明、改善案の提案を行うが、それは限られた視野での話にすぎない。チームは依然として、顧客が本当に実現しようとしている進歩、すなわち「片づけたい用事（Jobs to be Done）」を見極め、真の未充足ニーズと、単に魅力的に見えるだけの提案とを区別しなければならない。また、顧客が要求することすら思いつかなかった潜在的なニーズを見つけ出す必要もある。
例えば、ある顧客が新しいダッシュボードを求めているとしよう。言葉通りに受け取れば、それは機能の要望である。しかし、その根底にある「片づけたい用事」は、深刻な問題になる前に例外を検知することかもしれないし、不安を抱く経営陣を安心させることかもしれない。あるいは、週次レポートの作成に奪われている時間を削減することかもしれない。これらはそれぞれ、異なる解決策を指し示している。チームがその要望の背景にある真の課題を誤解していれば、どれほど素早くダッシュボードを構築したところで、何も解決しないのだ。
競合は目に見える機能をコピーできる。しかし、顧客がなぜ選び、苦しみ、乗り換え、あるいは単に使わずにいるのかについてのより優れた理解をコピーすることは、はるかに難しい。
意思決定の滞留を管理する
多くのプロダクト組織は、サイクルタイムやエンジニアリングリソース、仕掛品などを通じて、開発のスループット（処理能力）を注意深く監視している。しかし、意思決定のスループットを同じように厳格に監視している組織はほとんどない。
意思決定の滞留（キュー）は、不可視化されがちだ。それは、隔週で繰り返される優先順位決定会議や、経営幹部の承認待ちとなっているプロトタイプ、あるいは根拠が記録されていなかったために決定事項を何度も蒸し返すチームの姿に現れる。AIはこの滞留に、さらに多くの選択肢を注ぎ込む。これを解消するための優れた仕組みがなければ、開発の初期プロセスにおけるスピードは、後段のプロセスの大渋滞を引き起こすだけに終わる。
これを防ぐには、以下の3つの規律が役立つ。
第1に、重要な提案には必ず、それが応える顧客の「片づけたい用事」を明記させることだ。誰が、どのような状況で苦しみ、どのような進歩を望んでいるのか。機能要望の山は、調査すべき証拠（エビデンス）であって、戦略ではない。
第2に、次の段階への投資を進めるために必要な「証拠」を明確に定義すること。大まかなプロトタイプは顧客テストを行う根拠にはなるが、大規模なシステム設計の変更を決定する根拠にはなり得ない。後戻りできる実験と、規制、データ、ブランド、あるいはプラットフォームに影響を及ぼすような、重大な決断とを区別する必要がある。
第3に、意思決定の権限と撤退条件（エグジット条件）を事前に設定しておくこと。多くの役割が混在するチームであっても、最終的な決定権は1人が持つ。どのような証拠があればアイデアを進め、どのような検証結果が出ればそれを却下するのかを、全員が把握しておく必要がある。そうでなければ、安価に作られたプロトタイプが、根底にある課題が本当に解決に値するものか誰も検証しないまま、社内の一部の支持を集めて暴走してしまいかねない。
これらの規律は、チームのスピードを落とすものではない。むしろ、議論すべき価値のある論点に議論を集中させ、その意思決定の経緯を記録として残すことで、チームは決定事項を蒸し返すことなく、学びを得ることができるようになる。
AIは、相互に結びついた一連の変化を通じてプロダクトマネジメントを変えている。ボトルネックは「判断力」へと移り、プロトタイプは部門横断の合意形成における主要な手段となり、役割そのものは分野をまたいで広がっている。
これは、勝つプロダクト組織が、単に多くのアイデアを持つことによって勝つわけではないことを意味する。むしろ優位性は、集中的に追求する価値のある少数のアイデアを見抜き、なぜそれが重要なのかを説明できるほど顧客を深く理解することから生まれる。
