はじめに
生成AIの登場により、プロトタイプ作成や仕様の叩き台、リサーチの要約といった実務コストは、この1〜2年で桁違いに下がりました。その結果、「プロダクトマネージャーは不要になるのではないか」という問いが突きつけられています。
しかし、ARR500億円を超えるラクスの現場にいる私の実感は、むしろ逆です。AIが作業を巻き取るほど、作業に埋もれて見えにくかった「判断」というプロダクトマネージャーの不変の核が、くっきりと浮かび上がってきました。
とはいえ、何も変わらないわけではありません。むしろ変化は激しい。だからこそ、切り分けが必要です。「時代が変わったから全部変える」という過剰反応にも、「本質は不変だ」という思考停止にも転ばないために。本稿では、プロダクトマネージャーが持つべき「変わらない1本の軸」と「変えるべき3つのこと」、そしてそれを組織に実装する仕組みをお伝えします。
変わらないこと：ブレないプロダクトマネージャーの「1本の軸」
私が「これは変わらない」と考えているものは、突きつめると一本に束ねられます。「作れること」ではなく「判断できること」です。AIは作業を肩代わりしますが、判断は肩代わりしません。この判断を支えるのが、次の3つの要素です。
①製品解像度
製品解像度とは、開発プロセス、組織、市場、ドメイン、いまのお客さま、そしてまだ見えていない未来のお客さま。それらを一本の文脈として束ねて捉える力です。個々の情報の整理や要約はAIの得意分野ですが、統合された文脈は分割できません。分割して渡した瞬間に、統合そのものが失われる。だから、そのままではAIに渡せないのです。なお製品解像度は、プロダクト仕様（エンジニア・デザイナーが強い）、STP（プロダクトマネージャーが強い）、ドメイン理解（全職種に必要で、一次情報からしか埋まらない）の3層で捉えています。
②覚悟
プロダクトづくりはトレードオフの連続であり、何かを選び、何かを捨てる痛みを伴います。その結果への責任を負うことが「覚悟」です。AIはもっともらしい推奨案を出すのは得意ですが、失注や社内の不満といった結果の責任までは取れません。優秀な提案が大量に出る時代だからこそ、最後に引き受ける人間の役割は、軽くなるどころか重くなっています。
③判断のOS
複雑にからまった事象を整理して構造を見抜く力、制約の中で最適解に近づこうとする力、不確実でも仮説を立てて一歩を踏み出す力。私はこれを「判断のOS」と呼んでいます。技術やツールの知識は役割が変わるたびに入れ替わりますが、このOSはエンジニアからプロダクトマネージャー、マネジメントへと、役割を越えて再利用できます。
実際、AIと開発を進めると、AIが止まる場面は決まって3つに集約されます。トレードオフの引き受け、ドメイン（各社の暗黙ルール）への当てはめ、そして品質基準の判断。いずれも「作業」ではなく「判断」であり、少なくとも当面は、ここが人の側に残る核だと考えています。
変わること：プロダクトマネージャーが変える「3つのこと」
軸がブレない一方で、その軸を「どこに、どう当てるか」は大きく変わります。
①分業線の引き直し
仕事の分担はいま、人間、システム（ルールベース）、AIの三者間で引き直されています。すべてをAIに置き換えるのではなく、確実性が求められる部分はシステムに、揺らぎを許容できる部分はAIに任せ、最後の判断を人が担う。ラクスではこれを「協働型AI」と呼び、推進しています。
世間では「AIが人の仕事を奪う」という崩壊の物語で語られがちです。しかし現場で起きているのは、分業の「崩壊」ではなく「再編成」です。そして、分業線の最適な位置は、まだ誰も正解を持っていません。業務やAIの進化に合わせて分業線を引き直し続けること自体が、これからのプロダクトマネージャーの新たな役割です。
②AIに「任せる／任せない」の線引きの設計
<どこまでAIに任せるかは、AIの能力ではなく「間違えた場合の影響と責任の所在」で決まります。80点で許される仕事か、100点が求められる仕事か。一円のミスも許されない経理業務では、自動化に慎重な姿勢が必要です。実際、当社の公開調査（n=755）では、AIを主軸に業務を再設計した企業は13％にとどまり、8割近くが再設計に踏み切れていません。私はこれを「遅れ」ではなく「合理」だと捉えています。この慎重さに応える安全な線引きを設計することが、プロダクトマネージャーの新たな中核業務になります。
③職能の壁を超えた守備範囲の拡大
AIにより職能の壁が溶け、プロダクトマネージャーの守備範囲は確実に広がります。たとえばプロダクトマネージャー自らがAIでデザインの叩き台を作り、それを基にデザイナーと会話を始められます。「広げたら専門性が薄まるのではないか」という懸念はもっともで、広げすぎて何者でもなくなる危険は確かにあります。それでも私は、深さと広さは対立しないと考えています。本物の深さは、広さの上にしか立たない。80点までの深さは自分の専門で掘り、残りの20点は隣接領域への広さで埋める。市場やお客さまの全体像が見えているからこそ、自分の専門領域の掘り方が的確になるのです。
ラクスの組織づくり：大規模・複数プロダクトでどう実装するか
「楽楽クラウド」のように複数の独立したプロダクトを抱える組織では、プロダクトのライフステージに合わせた柔軟なAI実装が求められます。立ち上げ期のプロダクトは最初からAI前提の業務フローを設計し、成熟したプロダクトには、長年培った業務ロジックやお客さまが使い慣れた画面という「資産」を損なわないよう、裏側から静かにAIを溶かし込んでいく。どちらのステージにいるかを見極めること自体、製品解像度が問われる領域です。
加えて、私たちが扱う経費精算のような領域は「正解が動く」ドメインです。税制、電子帳簿保存法、インボイス制度と、ルールが毎年のように変わる。だからこそ、既存の業務フローを壊さず、人とAIで変化に追従し続ける協働型AIのアプローチが活きてきます。
組織面では、ラクスはプロダクトマネージャーとデザイナーを同じ「プロダクト部」に配置しています。職能だけで組織を完全に分けると、解像度も職能ごとに分断され、部分最適と縦割りが起きやすいからです。組織が仕組みとして越境を後押しするのか、個人の頑張りに丸投げするのか。この組織設計の差が、AI時代のプロダクトの成長スピードを大きく左右すると考えています。
