AI時代のプロダクトマネージャーになる 02｜技術がわからないことが、なぜかえって優位なのか

まず、コードが書けない人が作ったものを見てほしい。

Marcus Rushは住宅仲介の会社を経営しているが、自身はプログラマーではない。彼はClaudeとZapierを使って、Russという名のAI agentを組み上げた。毎朝11,000件以上の連絡先からリードに点数をつけ、配下の各エージェントにその日のフォローアップ計画を書き上げ、ついでに自分のスケジュールまで管理する。一人の仲介会社の社長が、日々の運営を回す社内システムを作り上げてしまった。しかも、手書きのコードは一行も書いていない。

これは特殊な例ではない。2026年のある統計では、vibe codingのアクティブユーザーのうち63%は開発者ではなかった。プログラミングの経歴がないデザイナーが、ReplitとAIだけで自分のプロダクトをローンチし、月収2万ドルを達成した。元の給料の2倍以上だ。

これらを並べてみると、直感に反する事実が見えてくる。「アイデアを動くものに変える」という道では、技術がわからない人のほうがエンジニアよりスムーズに進むことがあるのだ。

エンジニアはまず一つ、下ろさねばならない

ベテランエンジニアがAIで仕事をする様子を観察した人がいる。彼らはあらゆる実装の細部にこだわる習慣があり、「なぜXを使わないのか」「Yは検討したか」と問い返す。一方でモデルのデフォルトの反応は「はい、では追加します」だ。二十年かけて身についた、一行一行のコードに責任を負う本能は、AIとの協働の場ではまず下ろさねばならない。

これが彼らには難しい。下ろすべきは、「一行残らず自分の手で書き、自分の目で見て確かめなければ」というあの執着だ。METRのあの実験では、16人のベテランプログラマーが、自分が長年メンテしてきたプロジェクトでAIを使ったところ、実際には19%遅くなった。それでいて自分は20%速くなったと思い込んでいた。熟練している人ほど、ツールと噛み合わずにこじれやすい。

技術がわからない人には、この荷物がない。下ろすべきものを、そもそも持っていないのだ。

「これは難しすぎる」、技術がわからない人は言えない

かつてプロダクトマネージャーの判断の一部は、「この機能は実装上どれだけ難しいか」から来ていた。この知識には副作用がある。あるアイデアの裏でどれだけのものを書き換え、どれだけの落とし穴を踏むかが見えているほど、口に出して提案する前に自分でそれを没にしてしまいやすい。わかっている人ほど、自己検閲が厳しいのだ。

技術がわからない人は、自分にこのハードルを設けない。難しさを知らないからこそ、まず欲しいものを明確に語り、実装の難しさの部分はAIに食わせる。doaipmの言う言出法随とはまさにこれだ――明確に語れば、AIがその通りに作ってくれる。Marcusは、11,000件の連絡先をまたぐ点数付けロジックを書くことが「どれだけ難しいか」を知らなかった。彼はただ自分が何を欲しいかを知っていて、それを口にしただけだ。

希少なのはアイデアを明確に語ることで、コードを書くことではない

RussというagentがちゃんとできあがったのはMarcusがPythonを書けるからではなく、彼が事業を理解しているからだ。リードを何で点数づけするか、フォローアップ計画にどの項目を書くべきか、どの連絡先を上位に並べるか。これらは判断であって、技術ではない。

AIは省略から推論してくれない。明確に語らなければ、デフォルトで一版を出してくるが、それはたいていあなたが欲しいものではない。ルールも境界も状態もはっきり語れる人は、産出物が他人と一桁違う。この能力は、プログラミングができるかどうかとは関係がない。a16zがプロダクトマネージャーに与えた助言の一条にこうある。純粋なプロセス管理者は淘汰される、「建てる側のマインド」を持つ人だけがレバレッジを持つ、と。いわゆる建てる側のマインドとは、自分で手を動かしてアイデアを形にし、検証しに行く意志のことで、コードが書けるかどうかはそこに含まれない。

優位はただで手に入るわけではない

技術がわからないというのは、何もわからなくていいという意味ではない。Marcusが使ったZapier、あのデザイナーが使ったReplit、その裏にはどれも習熟すべき一つの手技がある。要求をAIが一口で受け止められる小さなステップにどう分解するか、出してきたものが正しいかどうかをどう判断するか、どこで止めて本物の人間に引き継がせるか。

技術がわからない人が最も漏らしやすいのは安全網だ。プロトタイプには本物の顧客データを置かないこと。公開、削除、支払いといった、押したら取り返しのつかないボタンは、人間が押すために残しておくこと。MarcusのRussはエージェントにフォローアップ計画を「書く」が、誰かに代わって「送信」させはしなかった――その一押しは、やはり人間がクリックするのだ。

今日できることが一つある。ずっと「これはエンジニアを探さないと」と思ってきた小さなアイデアを一つ選び、まず難しいかどうかを問わずに、欲しいものを一条ずつ明確に書き出して、AIに投げて第一版を作らせてみる。まずどこまでできるかを見てから、判断を下せばいい。

関連記事

• Zapier『Vibe coding examples: Real projects from non-developers』(Marcus Rush / Rush Home の事例)：https://zapier.com/blog/vibe-coding-examples/
• a16z『5 Principles for PMs in the AI Era』(建てる側のマインド vs プロセス管理者)：https://a16z.com/stay-relevant-in-ai/
• 本シリーズ第01回『PMのどの仕事がAIに奪われ、どの仕事がかえって高く売れるのか』：/ja/blog/ai-pm-what-changed/