AI時代のプロダクトマネージャー 04｜「作るべきか」の判断が、初めて「作れるか」より高くつく

まず、最も信じてよさそうで、しかし逆に判断された一つの判断を見てみよう。

METRは2025年2月から6月にかけて、薬の臨床試験と同じ水準の方法で、ランダム化対照実験を行った。ベテラン開発者16人――平均五年の経験を持ち、自分が保守しているプロジェクトに何千回もコミットしてきた人たち――が、当時最強のAIツールを使って246件の実タスクをこなす。事前、彼らはAIで24%速くなると思っていた。終えた後も、20%速くなったと感じた。実際に測ってみると――19%遅くなっていた。

ここで判断を誤ったのが何だったかに注目してほしい。複雑な戦略などではない。「AIは結局、自分自身を速くしたのか」という、最も単純な一つの判断だ。しかもそれが、彼らが最もよく知っているコード、最もよく知っているプロジェクトの上で起きた。最も腕の立つ人たちが、なんとなくの感覚で、逆に判断した。

これはAIが速いか遅いかの話とはあまり関係がない。本当に刺さるのはこの点だ。「作る」ことが速く安くなったとき、いちばん信じてはいけないのが「感覚」だ。そしてプロダクトマネージャーは毎日、もっと高くつく判断を感覚でやっている――この物、作るべきか否か。

一、「これは作るのが難しいか」を門にするのをやめる

かつてアイデアをふるいにかけるとき、あなたの代わりに見張ってくれる自然な門が一つあった。エンジニアが「これは三イテレーションかかる」と言う。あなたは投入と産出を量り、たいていはそれを下ろした。実装の難しさが、「作りたいが作る価値はない」物を大量に没にしてくれていた――あなたは自分が判断していたつもりだが、実は半分は難しさが代わりに判断していたのだ。

いまAIは「これ、今日の午後には出せます」と言う。門がなくなった。その結果はというと、あなたが正しいことをより多く成し遂げたのではなく、五つの機能を一気にリリースし、そのうち四つは誰にも使われない、という事態だ。Marty Caganは2026年にこう端的に言った。AIは「何を作るべきか」の問題を解いていない。会社が誰も欲しがらない物をより速く量産できるようにしただけだ――同じく出来の悪いロードマップが、ただ速く走るようになった、と。

だから最初の動作は直感に反する。「作れるか、どれくらいで作れるか」を、あなたの意思決定の根拠から消す。その答えはいまや常に「作れる、すぐに」であり、アイデアをふるいにかけるうえで、もはやいかなる情報も与えてくれない。

二、手を動かす前に、まず「やらないとどうなるか」を問う

実装がタダになったあと、最も漏らしやすい問いは、逆向きのものだ。この物をやらないと、どうなるのか?

仮にこのイテレーションで、この「スマート推薦」をやらないとしたら、何が起きる? 誰がそれで本当に影響を受け、どの程度影響するのか? それがないせいで去っていく人はいるか?

正直に答え終えて、「やらなくても別に何も起きない」と気づいたなら、それが答えだ――それはこのイテレーションに入れるべきではない。この問いが効くのは、「作っていて気持ちいい、AIが午後の半日で出してくれる」という誘惑を迂回し、価値そのものに直接向き合わせてくれるからだ。ある機能が「やらないと困ったことになる」で支えられるかどうかは、それを作るのがどれだけ速いかよりも、はるかに重要だ。

三、手を動かす前に、「作り終えたあと、何が本当になるか」を書く

Caganは言う。プロダクトマネージャーが本当に持っているのは二つだ。why(なぜこの問題が解く価値を持つのか)と、what(作り終えたあと、私たちは何が本当になることを期待するのか)。二つ目は、コードを書く前に、反証できる一文へと落とし込まなければならない。

この新規ユーザー向けオンボーディングをリリースしたあと、私たちは期待する。新規ユーザーの一週目の継続率を35%から45%超へ引き上げる。もし二週間後に動かなければ、私たちの判断が間違っていたということだ、削る。

この一文が書けないなら、自分がなぜそれを作りたいのか、実は分かっていないということだ。書けたなら、あなたは一本の物差しを手にする。自分が事前に立てた、引っぱたかれうる期待で測るのだ。「上司が好むか」「同業がやっているか」を物差しにしてはいけない。この物差しはAIには渡せない。あなたの商売で何が成功と見なされるのかを、AIは知らないからだ。

四、AIに選択肢を並べさせ、判断はあなたに残す――ただし「なんとなく正しい」を信じるな

AIが最も得意なのは、可能性を広げて並べることだ。同じ問題に対して三つ五つの解法、それぞれの代償、他人はどうやっているか。Caganの言い方では、AIが選択肢を surface し、人がどれに価値があるかを判断する。この一歩は、遠慮なくAIを使えばいい。

ただし選ぶときは、冒頭のあの実験に戻る。「なんとなく正しい」を信じるな。あの16人の専門家は、感覚で「速くなった」と判断し、集団で逆に判断した。あなたが感覚で「この案のほうが良い」と判断するのも、同じように当てにならない。それを第三歩のあの物差しに当てる――どの選択肢が、あなたの書いたあの期待を本当にする可能性が最も高いか、そして本物の証拠(ユーザーが言っていた、データで見た)はあるか。どれが読んでいて最も滑らかか、ではない。

今日できることが一つある。あなたが作ろうとしていて、しかも「AIならすぐに作れる」機能を一つ選び、まだ何も書かずに、二つの文を書き出す――やらないとどうなるか、作り終えたあと何が本当になるか。どちらか書けない一文があれば、それが今日、あなたが最も低いコストで拾い上げた一つの判断だ。

関連記事

• METR『Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity』(19%遅く、20%速いと思い込んでいた一次報告)：https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• Marty Cagan / SVPG によるAI時代のプロダクトマネージャーが持つ why と what：https://www.svpg.com/
• 本シリーズ第03回『AIを「道具」ではなく「同僚」として扱う』：/ja/blog/ai-as-colleague/
• 本シリーズ第01回『PMのどの仕事がAIに奪われ、どの仕事がかえって高く売れるのか』：/ja/blog/ai-pm-what-changed/