AI に仕事を奪われるのはエンジニアではなくプロダクトマネージャーの方だった

生成 AI が人間の仕事を奪っていくという話が様々なところでなされている。ソフトウェア開発の現場で AI にジョブセキュリティを脅かされるのはエンジニアやデザイナーなどの作り手の方で、何を・なぜ作るべきか考えるプロダクトマネージャーに関しては AI に置き換えられにくい職業だと思っていた。

しかし実際に勤務先で起こったことは、 AI の活用でエンジニアやデザイナーのコーディングやデザインの負荷が軽くなったため、彼らがプロダクトマネジメントの領域も担当するようになるというものだった。

プロダクトマネージャーがエンジニアリングも兼務し（プロダクトマネージャーは全員エンジニア出身だった）、逆にエンジニアやデザイナーもプロダクトマネジメントを担う。勤務先では一時期、職種の垣根をなくし、全員が作ることにも何を作るかを考えることにも関わる体制を目指した。

この出来事により、プロダクトマネージャーの存在意義とは何だろうかととても深く考えさせられた。

プロダクトマネジメントは何のためにあるか

プロダクトマネジメントの定義は様々あるが、何を作るべきかがわからないときに、何を作るか（どんな課題を解決するか）を定め、それに取り組む理由をつまびらかにしていくのがプロダクトマネージャーの役割だと考えている。

なぜこの役割が必要とされるのか。間違ったものを作って時間とお金を無駄にしないためだ。施策の精度を上げて無駄打ちをせずにユーザーに価値を提供する、というのがプロダクトマネジメントだ。

しかし、生成 AI の登場により作るためのコストが劇的に下がってしまったので、作る前に吟味するより、とりあえず作ってしまった方が早いし安いということになってしまった。生成 AI という機関銃の登場により、狙いを定めて撃つ必要がなくなり、下手な鉄砲も数撃ちゃ当たるの精神で、むやみやたらにバンバン撃ちまくる方が効率的になってしまった（少なくともそう見えるようになってしまった）。

Build のコストが劇的に下がった

エリック・リースの『リーン・スタートアップ』には、不確実性の高い環境で成長しなければならないスタートアップは Build / Measure / Learn のサイクルを回せと書かれている。『リーン・スタートアップ』が書かれた時代には、Build には相応の時間とコストがかかっていた。そのため、最初から完成品を作るのではなく、紙芝居や簡単なプロトタイプなど、最小限のコストで仮説を検証できる MVP を用意することが推奨された。いかに少ない Build で多くの学びを得るかが、プロダクトマネージャーの腕の見せ所という側面もあったと思う。

しかし AI 登場後の今日では、 Build は AI が超低コストで高速にやってくれるので、 Build にかかる時間とコストを節約するために事前の仮説検証に多くの労力を割く合理性が薄れた。

エンジニアがプロダクトマネジメントをするようになる

一日、場合によっては数時間で機能を作れるのであれば、「こうした方がよい」とエンジニアが思ったとき、その場で AI と相談し、データを確認し、 UI を考え、実装してユーザーに出すことができる。アイディアからリリースまでの間にプロダクトマネージャーは不要になる。

デザイナーにも同じことが言える。デザイナーが AI を使ってプロトタイプを作り、ユーザーインタビューの記録を要約し、データを分析して改善案を考えるようになれば、従来プロダクトマネージャーが担っていた領域をデザイナーがこなせるようになる。

AI によって手が空くようになったエンジニアやデザイナーに押し出されるかたちでプロダクトマネージャーが仕事を失いつつあるのだ。

Build が高速化しても Measure と Learn がボトルネックになる

生成 AI によって Build のコストが下がると、機能がどんどん作られるようになる。しかしリーンスタートアップでは Build / Measure / Learn の仮説検証サイクルを回すことが重要で、 Build がたくさん行われたならそれだけ Measure と Learn もたくさん行う必要がある。

Measure について、データ分析そのものは AI が高速化してくれるが、ユーザーの実際の行動を観測し、仮説を検証するための情報を集めるには、依然として時間がかかる。

Learn についても AI は分析結果の解釈や次の仮説づくりを支援してくれるが、何を学びと定義し、次にどの方向へ進むかは人間が決めなければならない。

どれだけ Build が高速になっても、 Measure と Learn は同じようには速くならない。弾を撃つコストがいくら安くなっても、着弾した場所を確認し、何が起きたのかを理解するコストまでゼロになるわけではないのだ。

プロセス	AIによって変わること	依然として残る制約
Build	実装・デザイン・プロトタイピングが高速化	品質保証、セキュリティ、運用など
Measure	分析作業やレポーティングが高速化	ユーザーの実際の行動、データの蓄積、観測期間
Learn	分析結果の解釈や仮説生成を支援	何を学びと捉え、次に何をするかという判断

プロダクトディスカバリーとセンスメイキング

ユーザーが欲しいと言っている機能を作ることと、ユーザーが本当に困っていることを解決することは違う。ユーザーの発言や行動の背後にある課題を探り、本当に解くべき問題を明らかにするのがプロダクトディスカバリーだ。

一方、解くべき課題がわかったとしても、なぜいま自分たちがそれに取り組むのかは別の問題だ。事業戦略やプロダクトの目指す姿と結びつけ、チームがその仕事に取り組む意味を見いだし、共通認識を得ること。これがセンスメイキングだ。

	プロダクトディスカバリー	センスメイキング
中心的な問い	何が本当の課題なのか	なぜ自分たちが取り組むのか
具体例	ユーザーの行動や発言の背後にある課題を発見する	事業戦略・顧客価値・組織の目標と結びつける
成果	解くべき課題の定義	取り組む理由や優先順位についての共通認識

プロダクトディスカバリーやセンスメイキングは Build の前に一度だけ行う仕事ではない。 Build / Measure / Learn を回すたびに得られる情報をもとに、そもそも解くべき課題は何なのか、なぜそれに取り組むのかを更新し続ける必要がある。

AI によって Build が高速化すれば、この問い直しの回数も増える。作れるものが増えても作るべきものが増えたわけではない。計測や検証、学習まで含めてサイクルを回すために、選球眼はある程度必要だし、戦略として定めた方向性と個々の施策が一致していなければ意味がない。

専任のプロダクトマネージャーを残した理由

勤務先ではプロダクトマネージャーを全員エンジニアに戻そうという動きもあったが、議論を重ねた結果、プロダクトマネジメントを職能として残すところに落ち着いた。

大きめのプロジェクトをプロダクトマネージャーが関与せずに進めたことがあったが、様々な局面で難儀した。検証すべき価値仮説が曖昧だったため、「軽い」とされていたプロジェクトの規模はどんどん大きくなり、仕様に関して共通認識を醸成するのにも難儀した。ビジネス側からの要求をそのまま通せば「 UX が悪すぎでは？」と開発チームが疑問を持つし、開発チームの考える通りに作れば施策で検証したいことが検証できなくなってしまう。

開発、ビジネス両方に対して、こういう部分に未検証の仮説があって、新しい価値提案ができるかもしれない、という風に腹落ち感の醸成を行う担当者が必要なのだ。単なる調整役のようで異なる、腹落ち醸成の担当者（センスメイカー）としてのプロダクトマネージャーが必要で、この役割は AI や兼務でプロダクトマネジメントを行うエンジニアやデザイナーで担当するのは難しい。

これからのプロダクトマネジメント

個々の施策について仮説を立て、実装して検証することは、エンジニアやデザイナーが AI と一緒にどんどん進められるようになるだろう。プロダクトマネージャーが一つひとつの施策に介在して、事前に命中精度を高める必要性は以前より小さくなった。

しかし、たくさん作れるようになったからといって、何を・なぜ作るべきかを考える必要がなくなるわけではない。個々の施策から得られた学びを束ね、プロダクト全体として何を学んだのか、次にどこへ向かうべきかを考える役割が重要になる。

アイディアを具現化することに特化したプロダクトマネージャーは AI とエンジニアやデザイナーに仕事を奪われて失業し、戦略性が高い意思決定を担えるプロダクトマネージャーでないと生き残れないだろう。残酷な現実だが、適応して生き残るしかない。