AIが自らコードを書いてプロダクトを開発できるようになったとき、プロダクトマネージャーには何が残るのか？

大規模言語モデルやAIプログラミングツールの普及に伴い、ソフトウェアのプロトタイプを開発するハードルは劇的に下がった。エンジニアは自然言語を用いて、実際に動作するインターフェースやロジックを素早く生成できるようになり、多くの人が次のような疑問を抱くようになった。コード生成がこれほど安価になった今、従来の意味でのプロダクトマネージャー（PM）は存在意義を失いつつあるのではないか、と。

a16zのJosh Elmanは、これに対して真っ向から反対の判断を下している。彼の中心的な観察は極めて明快だ。コードを構築するコストは確かに大幅に下落したが、正しいプロダクトの判断を下すコストは、一円たりとも下がっていないのである。

これは抽象的な論議ではない。JoshがかつてRealNetworksでRealPlayerのプロダクトおよびエンジニアリングチームを率いていた頃、ビジネスチームから「プレイヤーが起動するたびに広告を表示すべきだ」と提案され、どれほど儲かるかを示すExcelシートを提示されたことがあった。彼はそれがプロダクトを損なうと分かっていたものの、財務予測に対してプロダクトの判断をどう論拠として反論すべきか、うまく言葉にできなかった。

その後、Reid HoffmanによるLinkedInの面接で、彼は「プロダクトマネージャーが生み出す成果物（artifact）とは一体何か？」と問われた。Joshは当時、仕様書（spec）だと答えた。LinkedInに入社後、彼は「ソーシャルネットワーク内の採用プラットフォーム」のために120ページに及ぶ仕様書を書き上げ、体験と要件を詳細に定義した。

しかし仕様書は、システムが何をすべきか、完了時にどのチェック項目に印をつけるべきかを記述できるに過ぎない。何年も経ってからJoshは、PMの真のartifactとは「ストーリー（story）」であると気づいた。誰がプロダクトを使い、なぜそれがその人たちの人生に影響を与えるのかというストーリーだ。このストーリーはマーケティング用の宣伝文句ではなく、チームが共通して理解する情景である。誰もが即座に理解でき、PMが不在の場でも正確に復唱できなければならない。そして、なぜユーザーがやって来るのか、各ステップで何をどう感じるのか、どこで驚きや喜びを与えるべきか、どこはあえて平淡に保つべきか、という問いに答えるものでなければならない。

ここから、筆者によるプロダクトマネージャーの中核的な定義が導き出される。チーム（そして会社）が正しいプロダクトをユーザーに届けるのを助けることだ。PMはチームの上に君臨するリーダーではなく、自身のチームと会社全体の目標におけるその位置付けを理解し、チームがプロダクトを真にリリース（ship）するのを支援し、ユーザーにとって何が真に「正しい（right）」のかを継続的に判断する存在なのである。

モノを作ることが極めて容易になったとき、チームが直面する最大の危機は「機能を作れないこと」ではなくなった。誰にも必要とされず、論理が破綻し、一度使われただけで捨てられる凡庸な機能を、猛烈なスピードで大量生産してしまうことなのだ。AI時代のプロダクト開発を考察する鍵は、開発サイクルに生じた逆転現象を理解し、いかにしてユーザー価値を真の中核に据えた判断フレームワークを構築するかにかかっている。

開発サイクルの逆転：長時間の机上検討からプロトタイプ先行へ

従来のソフトウェア開発体制において、エンジニアリングの時間は極めて高価だった。高価なエンジニアリングリソースが誤った方向に投じられるのを防ぐため、チームは実際にコードを書く前に、機能仕様書（spec）の作成、コスト試算（costing）、スコープ定義（scoping）、そして設計（design）に多大な労力を費やす必要があった。このように厳密な事前の机上検討を行う体制下では、チームが1年間に回せる完全な開発サイクルはせいぜい6〜8回程度だった。

AIプログラミングツールを導入したことで、この開発サイクルには根本的な逆転が起きた。かつての机上の推論から、アイデアを出す（idea）→ まずAIで構築する（build）→ 実際に手で触って動かしてみる（play with it）→ その後にビジュアル/UXおよびエンジニアリング設計を行う（visual/UX & engineering design）→ リリースする（ship）→ フィードバックから学ぶ（learn）というプロセスへと変わったのだ。

実際に操作できるプロトタイプ（prototype）は、口頭やドキュメント上の仮定の議論（what-if）にとどまるよりも、はるかに直感的な判断を下しやすい。自ら直接操作し、インタラクションの引っかかりを体感することで、アイデアが成り立つかどうかを早期に検証できる。

開発サイクルの逆転のもう一つの側面として、AIはプロダクトの形態に対するユーザーの期待をも変えつつある。ユーザーは複雑なインターフェースをわざわざ学ぶことなく、求めているものを言葉で伝えるだけでプロダクトが結果を返してくれること、さらにはバックグラウンドのエージェントが作業を完了させてくれることを期待し始めている。ただし、これはあらゆるプロダクトがすでにこの形態を実現していることを意味するわけではない。

しかし、ここには明確な現実の境界線がある。デモプロトタイプ（demo）がほぼ無料で作れるからといって、実際に使えるプロダクト（working product）までもが無料になるわけではないということだ。ツールを用いて数分でプロトタイプを組み上げることと、それを安定性、安全性、スケーラビリティを備えた本物のプロダクトへと磨き上げることとの間には、依然として堅実なエンジニアリング作業が横たわっており、十分な時間と労力を注ぎ込む必要がある。

真の利用を検証する：Vision フレームワークと対話ログ

プロトタイプ構築の摩擦が解消された今、プロダクトマネージャーには「ユーザーは本当にプロダクトを使っているのか？」という明確な判断が一段と求められる。筆者は明快な「Visionフレームワーク」を提示している。ここでのVisionとは、スローガンのようなミッションステートメント（mission statement）ではなく、ユーザーに対するプロダクトのエンドツーエンドの存在理由を指す。このフレームワークは、以下の3つの核心的な次元で構成される。

• 根本目的（Purpose）：プロダクトがなぜ存在するのか、どの中心的な問題を解決するのか。例えばLinkedInの根本目的は、「探す、そして見つけてもらう」（find and be found）ことである。
• コアアクション（Core actions）：ユーザーがプロダクトの中で実際に何を行うのか。LinkedInを例に取ると、一部のユーザーは届いた連絡に返信するだけである。チームはすべてのユーザーに毎日のアクティブな利用を強制するのではなく、プロフィールの正確さを維持することに多大な注力を注いだ。たとえ年に1、2回しか見つけられなかったとしても、その瞬間に価値が成立していればプロダクトは機能しており、それも立派な「真の利用」に該当する。
• 利用サイクル（Cycle）：それぞれのコアアクションがどのような頻度で発生すると想定されているか。

筆者は、「本当に使われているかどうか」を、登録ユーザー数、ウェイティングリストの人数、ARR、消費トークン数、App Storeのランキングといった表面的な指標で代替しては絶対にならないと強く強調している。ユーザーがアプリを一瞬開いただけで利用したとみなすことには何の意味もない。チームが観察しなければならないのは、自らの意思で直接プロダクトを訪れた人々が、コアアクションを一貫して完結させたかどうかである。

AIプロダクトにおいては、この真の利用を検証するための窓口がより直接的になった。ユーザーとプロダクトの対話履歴そのものが、ユーザージャーニーの逐語記録となるのだ。それは抽象的な統計レポートではなく、以下の生々しい記録である。

• 案内がない状態で、ユーザーが自発的に何を語りかけたか：何の手がかりもないとき、彼らがまず最初に表現しようとしたニーズは何だったのか。
• どの瞬間にユーザーが諦め、言い換えを試みたか：彼らはどこで行き詰まり、どのようにニーズを再表現したのか。
• ユーザーはプロダクトに何を期待し、プロダクトは何を達成できなかったのか：どの満たされなかった期待が、プロダクトの機能とユーザーの期待とのギャップを浮き彫りにしたのか。

真の利用とユーザージャーニーの本質を理解して初めて、チームはデータに異常が生じた際、プロダクトがユーザーの実際の生活のどこから乖離してしまったのかを正確に診断できるのである。

Twitterの継続率危機：ユーザーを空き部屋に放り込んでもストーリーは伝わらない

プロダクトのナラティブを修正することで、いかにして重要指標を救い出すのか？ 初期Twitterが爆発的な急成長期に直面した実際の危機は、極めて説得力のある解剖事例を提供してくれる。

しかし、具体例に踏み込む前に、新規ユーザーの導入（onboarding）が本来誰に向けて行われるべきかを整理しておく必要がある。ユーザーの分布の両端には、2つの極端なグループが存在する。一方の端にいるのは「熱狂的ユーザー（eagers）」だ。彼らは極めて強い明確な目的意識を持ってやって来るため、導入フローがどれほど煩雑でインターフェースが使いにくくても、自力で何とか理解して使いこなす。もう一方の端にいるのは「気まぐれな通りすがり（fly-bys）」だ。彼らは偶然立ち寄っただけであり、どれほど手厚く案内しても定着する可能性はほとんどない。onboardingが真に転換をもたらすことができるのは、その中間に位置する、好奇心を持って価値を確かめに来た人々である。致命的な盲点は、企業の従業員全員が「熱狂者の島（eager-land）」に暮らしているということだ。彼らはすでにプロダクトのコア価値や内部ロジックを熟知しているため、新規ユーザーのリアルな視点を決して代表することはできない。

この好奇心旺盛なユーザー層に対して、onboardingはいかに設計されるべきなのだろうか？ 筆者は、onboardingこそがユーザーの注意力が最も集中する「ストーリーを語る瞬間」であると指摘する。ユーザーはこのときプロダクトの存在を知り、試してみようという意思を持っている。これほど高い集中力を得られる機会は、後からでは二度と得難い。したがって、メールアドレス、パスワード、電話番号といった基本情報以外に何らかの入力を求める場合、チームはなぜそれを尋ねるのか、それがユーザーの得る価値とどう結びついているのかを明確に説明しなければならない。その上で筆者は、複数の企業でA/Bテストを実施してきた経験に基づく持論を展開している（一次資料には具体的な実験データは示されておらず、これは筆者の経験則に基づく結論である）。画面数が少なく情報密度の高い複雑な大画面よりも、シンプルで個別的かつ各ステップの目的が極めて明確な細かいステップを多く設けた方が、往々にして優れた導入効果が得られるという。ステップ数を増やせば途中で離脱する人数は必然的に増えるが、チームはフローの完了率だけで成否を判断してはならない。真に有効な評価基準は、最終的にどれだけの人が翌日や翌週に自発的に戻ってきてコアアクションを完結させたか、そして彼らが他の人に対してこのプロダクトが何であるかを正確に説明できるようになったかどうかである。

この洞察は、現代のAIプロダクトにとってとりわけ痛烈である。多くのAIアプリは、ユーザーが初めてアクセスした際に空のプロンプト入力欄を表示し、「何でも聞いてください（Ask me anything）」という一言を添えるのが常態化している。これは本質的に、プロダクトの能力を理解する責任を丸ごとユーザーに押し付けているに等しい。何もない入力欄を前にして、好奇心を持ってやって来た新規ユーザーは途方に暮れ、行動停止に陥ってしまう。効果的なonboardingとは、具体的な機能を一つずつ教え、ユーザー自らの手で少なくとも一つの価値ある（できれば自分自身の実際のデータに基づいた）ユースケースを完結させ、能力の限界と得られる価値を実感してもらうことである。

これこそまさに、Josh Elmanが2009年末にTwitterに加わったときに直面した継続率（リテンション）の苦境であった。当時、大手メディアによる大々的な報道や著名人による推薦によって数百万人もの新規登録者が集まっていたが、その多くは二度と戻ってこなかった。問題の根源は極めて根本的なところにあった。人々が「Twitterとは一体何なのか」を説明できなかったのである。

当時のGoogle検索サジェストで「i don't get...」と入力すると、「i don't get twitter」が表示された。この歴史的なスクリーンショットは、大衆の理解の断絶を生々しく記録したものであり、ユーザーがプロダクトを何であるか説明できなかった証拠として提示されているのであって、登録後に表示される検索画面のことではない。

旧バージョンのonboardingでは、登録後に「Find your friends」（友だちを探す）や「Follow 20 random people」（ランダムに20人をフォローする）といった選択肢が表示されていた。多くの新規ユーザーはこれらをそのままスキップし、その結果、完全に空白のタイムラインへと足を踏み入れることになった。彼らは「What's happening?」という入力欄に向き合っても、流れてくる投稿は何一つ見えず、自分自身が何を呟けばよいかも分からず、ただ困惑して立ち去るしかなかった。

プロダクトのナラティブを整理するため、チームは「Learn Flow」と呼ばれる導入フローを再構築し、浅い理解から深い理解へと進む認知の法則に沿ってユーザーを導いた。

ステップ1：プロダクトの約束を明示する。ウェルカムページでは冒頭で「Find out what's happening right now with the people and organizations you care about」（あなたにとって大切な人々や組織の“いま”を見つけよう）と明確に伝え、最初の画面で認識をすり合わせ、プロダクトの根本的な価値を提示した。

ステップ2：プロダクトの基本単位を理解させる。画面上でTweetとは何かを詳細に解説し、最大140文字でリンクも含められる短いメッセージであることを明確に伝えることで、コンテンツを構成する基本単位を直感的に理解させた。

ステップ3：単一のアクションでタイムラインのメカニズムを体験させる。導入画面には2カラムのタイムラインが表示される。ユーザーが左側で「Follow」をクリックしてアカウントをフォローすると、右側には即座にそのアカウントによるTweetがリアルタイムで現れる。この一連の動作を通じて、ユーザーはその場で「アカウントをフォローする → そのアカウントのTweetが現れる → 集約されて自分のタイムラインになる」というコアロジックを体得した。導入が終了したとき、ユーザーが正式に入室するホーム画面は、もはやがらんとした空き部屋ではなく、いま自分がフォローしたばかりの人々で満たされたタイムラインとなっていたのだ。

筆者は、この「Learn Flow」がもたらしたユーザー継続率（retention）の改善は、Twitterがその年にローンチしたあらゆる施策を上回っていたと明言している。ユーザーのマインドセットを揃えることに重点を置き、目標が明確な連続したステップを通じて、好奇心を持ったユーザーがプロダクトの約束を理解し、基本概念を認識し、自らの手で価値のループを完結できるよう手助けしたのである。

ユーザー自身の言葉を自ら読む：AIはパターンを発見するが、判断を外注することはできない

真の利用に関する前述の考察で触れたように、AIプロダクトと従来のソフトウェアとの最大の相違点の一つは、ユーザーとシステムとの対話ログそのものがユーザージャーニーの逐語記録を形成している点にある（前述の対話転記フレームワークの通りである）。ユーザーがインタラクションの中でプロダクトに向かって投げかけた言葉の一つひとつが、飾られていない真の意図を直接反映している。

これら生の言葉の記録の中で、チームは3つの極めて重要な断面を直感的に目の当たりにできる。案内がない状態でユーザーが自発的に求めたニーズは何だったのか、どのプロセスで行き詰まって諦め、言い換えを選んだのか、そして、ユーザーがプロダクトに強く期待していたにもかかわらずシステムが満たせなかった落差はどこにあったのかである。こうした生々しい体験を理解するための大前提は、プロダクトマネージャーとチーム自身が、高度に抽象化されたデータ指標越しではなく、直接ユーザーの生の言葉を読みに行くことだ。

この過程において、AIはチームがこれまで見落としていた現象を浮き彫りにする支援ができる。しかし、チームはすべての対話ログをAIに要約させたり、ましてやAIにPMの意見形成を代行させたりしては絶対にならない。

これら生の表現を自ら読み、自身の判断を形成し、プロダクトの背後にあるストーリーが一体何であるべきかを決めることこそ、プロダクトマネジメントが果たすべき不変の仕事であり、技芸（クラフト）なのだ。

インパクトの取捨選択：コード過剰の時代に完全なプロダクトを守り抜く

誰もが優れたアイデアを持ち、傍らにコードを書けるエージェントを従えている時代において、「何をすべきか」を巡る議論の重心は根本的にシフトした。それはもはやエンジニアリングリソースや開発スケジュールを巡る議論ではなく、優先順位におけるインパクトの取捨選択である。意思決定の構図は、リソースが乏しかった時代の「これを作るか、それとも何も作れないか」（this or nothing）から、「これを作るか、それともあれを作るか」（this or that）へと変わった。チームは「スケジュールに収まるかどうか」という慣性を捨て去り、まず「それはこのプロダクトにふさわしいものか」を問わなければならない。

機能を作り出すハードルが極限まで下がった今、プロダクトが直面する最大の危機はAI slop（AIによる粗製濫造）に堕することだ。技術的に実装が容易だから、コードが手軽に手に入るからという理由だけで、思いついた機能、インターフェース、インタラクションを手当たり次第にプロダクトに詰め込み、全体としての体験を肥大化させ、破綻させてしまうのである。機能の供給が過剰になった時代だからこそ、プロダクトの品位（taste）、機能に対する厳格な選定とキュレーション（curation）、そしてシンプルで調和のとれた完全なプロダクトに対する大局観が、かつてないほど決定的な重要性を持つようになった。

これはプロダクトチームに対し、仕事のテンポにおいて冷静さを保つことを求めている。私たちはAIを使ってプロトタイプ構築を劇的に加速させることができるが、判断を急いで飛び越えてはならず、判断を放棄することなど決してあってはならない。

方向性に意見の対立が生じたとき、プロダクトマネージャーはただ「テストして結果を見てみよう」と言って、決断の責任を実験データに丸投げしてはならない。PMは依然として創造性とデータの間でバランスを取り続け、取捨選択のための自身の判断を下さなければならないのである。

AIがプロトタイプを組み立てる障壁を大幅に引き下げたとはいえ、それがエンジニアリングのすべての労働を肩代わりしたわけでは決してない。デモを実際に使える本物のプロダクトへと仕上げていくには、今なお時間とエンジニアリングの投入、そしてプロダクトとしての綿密な推敲が不可欠である。

Josh Elmanが強調するように、プロダクトマネージャーの中核的な使命が揺らいだことは一度もない。チーム（そして会社）が真に正しいプロダクトをユーザーに届けるのを助けることである。コードを書くコストがますます安価になっていく中で、あらゆるものを作り出してしまう誘惑に抗い、無数の可能性の中から明確な取捨選択を行い、チームのために正しいストーリーを守り抜く判断力こそが、プロダクトの命運を決する最も希少な資産なのである。