AIやローコードツールの普及によってソフトウェア開発のコストが激減し、誰もが簡単にプロトタイプを作れる時代が到来している。しかし、この「ソフトウェアの過剰供給」はプロダクトマネジメントの仕事を容易にするどころか、かえって複雑にしている。従来のPMは限られた開発リソースをいかに配分するかという「希少性の管理」を担っていたが、これからのPMは、社内に溢れ返る無数のツールやプロトタイプを分類し、どれを公式に採用し、どれを削除すべきかを見極める「過剰性の管理」と「プロダクトの判断力」が求められる。本内容では、AI時代における新たなPMの役割と、混沌とした開発環境を整理するための実践的なフレームワークについて解説する。
プロトタイピングの先にあるプロダクトマネジメントの本質
今日は皆さんにこの話ができるのを本当に楽しみにしていました。なぜなら、私自身が長年プロダクトマネージャー（PM）を務めてきた中で、現在のプロダクトマネジメントの現状についてどうしても伝えたいことがあるからです。最近の研修講座などを見ていると、その多くが「これからのPMはプロトタイプを作る存在になる」という考え方に終始しています。PMがLovableを使い、Clawdbotを使い、各種コーデックを使ってプロトタイプを自作する、といった話ばかりです。もちろんそれは素晴らしいことですし、否定するつもりはありません。しかし、それがプロダクト管理の本質的な未来だとは思いません。そんなものは、現時点ではできて当たり前の最低条件に過ぎないのです。
だからこそ、同じPMの仲間たちと、私たちの専門領域で今何が起きているのか、そしてAI時代に私たちはどのように変化し進化していくべきなのかについて、もっと深い議論をしたいと考えています。プロトタイプを作ればいいというアドバイスは、少し過大評価されすぎているように感じます。私たちは自分たちの行動をもっと意図的にコントロールしなければなりません。これは、私が最近ずっと深く考えている「AIは生成を容易にする」という概念に帰結します。生成が簡単になればボトルネックは別の場所に移動します。そのため、限られた人間の希少な知性をいかに有効に活用し、ビジネスにとって本当に重要な成果を生み出すかについて、私たちは非常に意図的である必要があるのです。
もし大企業においてAIの活用がどのような姿をしているかを知りたければ、マイクロソフトが良い例を示してくれています。彼らは社内で100万以上のPower Platform資産を構築しました。Power Platformとは、彼らが提供しているAIツール群のことですね。その中には、1万8000を超える異なるロボット環境やエージェント環境、17万のPower Apps、5万のPower Automateのフロー、そして1200のチャットボットが含まれています。これを見て多くの人が受ける印象は、ローコードとAIによって、より多くの人がソフトウェアを構築できるようになったという話でしょう。しかし、その裏にある本当のストーリーは、プロダクトマネジメントの役割が「希少なエンジニアリングリソースを配分する仕事」から、「過剰に存在するソフトウェアを分類し、戦略を立てる仕事」へと移行しているということなのです。
これがなぜ重要かというと、プロダクトに関する議論の場に持ち込まれるものが、もはや単なるアイデアや要望ではなくなっているからです。多くの場合、それはすでに動いている成果物なのです。ダッシュボードであったり、ワークフローであったり、軽量なアプリやローカルな自動化ツール、顧客向けのプロトタイプ、あるいはすでに基幹システムに接続されているエージェントかもしれません。つまり、従来のプロダクトにおける問いは「これをそもそも作るべきか」でしたが、新しいプロダクトにおける問いは、そこから一歩進んだ段階から始まります。「誰かがすでに何かを作ってしまった。では、会社としてそれに価値を持たせるべきか、そしてそれをどう解釈すべきか」という問いです。
これこそが、今日お話ししたいPMの役割のシフトです。これからのプロダクトマネジメントは、過剰に生み出されるソフトウェアを市場価値のあるものや有用な社内ツールへと分類し、あるいはそれを削除することを決める規律へと変貌しつつあります。これは以前よりもはるかに戦略的な仕事であり、同時に技術的な仕事でもあります。今後数年間で生き残る優れたPMは、単にチケットを仲介して進捗を管理するだけの人ではありません。市場、ユーザー、ワークフロー、技術システム、データ、評価、権限管理、コスト、信頼性、そしてセキュリティを十分に理解し、過剰なソフトウェアをどこに向けるべきかを判断できる人材です。
非技術的なPMの居場所はもうほとんど残されていません。これはすべてのPMがフルタイムのエンジニアにならなければならないという意味ではありません。AIプロダクトの本質は技術的なシステムであり、AIの技術的な側面がその全体的な挙動を決定づけるからです。だからこそ、私たちはそれらを正しく理解し、うまく付き合っていく必要があります。現在のプロダクト決定には、モデルの挙動、エージェントのループ、データアクセス、ワークフローの境界、データ検索、評価、遅延、コスト、権限、そして障害モードなどが絡み合っています。これらの要素について論理的に思考できないPMは、プロダクトそのものを見失っていると言えます。
同時に、AIがプロダクトの仕事から人間の価値を奪い去るわけではありません。実際にはボトルネックが移動しただけなのです。ソフトウェアの生産コストが下がったとき、希少になるのは最初のバージョンや最初のプロトタイプではありません。希少になるのは、何が存在すべきで、何が削除されるべきか、そのプロダクトは誰のためのもので、どの基準を満たすべきで、会社が何に賭けるべきかを見極める優れた判断力です。
ソフトウェアの過剰供給がもたらすカオスとガバナンス
従来のPMの仕事は、まさに希少性を前提に構築されていました。ソフトウェア開発が高価だったからこそ、プロダクトの儀式が意味を持っていたのです。PRD（製品要求仕様書）やロードマップのレビュー、計画サイクル、リリースのチェックリスト、優先順位付けのミーティングなど、これらすべてはエンジニアリングの時間を慎重に消費するために、あえて作業を遅く進めるよう設計されていました。それがすべての目的だったのです。ソフトウェアが高価だった時代、企業にはフィルターが必要であり、PMがそのフィルターの役割を果たしていました。思いつきのアイデアをすべて形にする余裕はありませんし、あらゆる部署が勝手にプロダクトのコピーを作ることも許されませんでした。そのため、PMがフィルターを運用しなければならなかったのです。
しかし、AIはそのフィルターを破壊しつつあります。なぜなら、人々がプロダクトやエンジニアリングの部門に相談する前に、自分たちで成果物を作れるようになってしまったからです。かつて提案の入り口にあったのは、言葉やモックアップ、スプレッドシート、そして説得の技術でした。しかし今や、そこにあるのは実際に動作するツールやダッシュボード、自動化、エージェント、そして半分本物のようなゾンビプロダクトです。プロダクトのリーダーは、もはや洗練されたビジネスケースが提出されるのをただ受動的に待っているわけにはいきません。そのような世界では、役に立つシグナルが、多くの役に立たないノイズと共に、すでにチームの内部で走り始めているかもしれないからです。
そこで必要なのは、そうした動きを完全にシャットダウンすることではありません。多くのPMは、自分たちの仕事はプロトタイプを作ることであり、他の誰にもやらせないという防衛的な本能を働かせがちですが、それは間違いです。これからは全員の仕事がプロトタイプ作りになります。ローカルな自動化ツールがプラットフォームの欠陥を露呈させることもあれば、未完成のエージェントが、公式プロダクトが対応していない顧客の真のニーズを示していることもあります。そして、それを構築したのはPMではなく、カスタマーサービスの担当者かもしれません。ですから、組織内の優れたアイデアが、どのような成果物やプロトタイプの形で生まれているのかを把握する必要があります。企業には幅広い構築の機会が必要です。なぜなら、そこから新しい需要が見えてくるからです。
しかし、判断力のない無秩序な構築は、ただの乱開発へとつながります。有用な成果が埋もれてしまい、リスクのある作業がサポートのないまま広がり、ビジネスが今どのツールに依存しているのか誰も分からなくなってしまいます。プロダクト機能は、より多くの人に構築を許可することと、ビジネスが何に依存するかを慎重に決定することという、二つの相反する概念を同時に維持しなければなりません。現在の世界は、これまでのプロダクト組織が評価できるように設計されていた量をはるかに超える、ソフトウェア化された成果物を生み出しています。
このパターンは企業内部でも起きています。マイクロソフトの社内Power Platformのエコシステムはその素晴らしい例です。一つの会社の中に100万以上の社員開発資産が存在し、そのガバナンスはインベントリ、テレメトリ、権限レビュー、環境管理、データポリシーを中心に構築されています。マイクロソフトがこの事例を共有したのは、従業員に開発をやめさせるためではありません。むしろ、会社を保護しながら従業員に自由に開発をさせるための手段としてガバナンスを提示したのです。
GitGuardianの2026年版秘密情報漏洩に関する報告書によると、公開されたGitHub上で露出したAIサービスのシークレット（秘密鍵等）の数は、2025年に120万件に達しました。現在はさらに増加しており、2025年には前年比で81%も増加しています。今年もさらに80%から100%は上昇するでしょう。作成のスピードが上がれば、それだけミスも増えます。より多くの資格情報、より多くのローカルワークフロー、より多くの統合が生じ、アクセス権が漏洩する場所が増えることを意味します。有用なツールが、それがどのようなクラスのものか定義される前に拡散してしまうと、プロダクトリーダーはその問題をそのまま引き継ぐことになります。問いは、そのプロトタイプが便利そうに見えるかどうかだけではありません。それがどのデータに触れているのか、どのシステムに書き込みを行っているのか、誰がそれを所有しているのか。これらは今やエンジニアリングだけの問題ではなく、プロダクトの問題なのです。そして、これまで以上に私たちの技術的、市場的な判断力が求められています。
これらすべての話を、単なる社内ツールの管理問題として片付けてしまうのは簡単ですが、それでは役割を矮小化しすぎてしまいます。ソフトウェアが安価になることで、PMは市場の判断に対してより重い責任を負うことになります。これには、ビジネスの内外にあるすべてのツールに対する市場からの評価も含まれます。今や最初のバージョンを作るのは非常に安価であるため、私たちへの問いは極めて鋭いものになります。そもそも、なぜ私たちはこれを作っているのでしょうか。PMは生産を成功に導くために、市場を十分に理解していなければなりません。ここで本当に解決する価値のある顧客の問題はどれか。売上や継続率、信頼に直結し、顧客にとって本当に良い習慣を形成しているワークフローはどれか。競合他社のどの機能が単なるノイズに過ぎないのか。顧客のどの要望が、より深い根本的な課題の兆候なのか。どの社内プロトタイプが本物の需要を示しており、どれが単に特定チームの一時的な利便性に過ぎないのか。それはもはや単純なプロダクト管理ではなく、プロダクトに対する審美眼、つまり判断力そのものなのです。
新しいPMの仕事：プロトタイプ・コモンズと本番階層の構築
では、実際の業務において新しい仕事はどのような姿をしているのでしょうか。まずはプロトタイプ・コモンズから始めましょう。プロトタイプ・コモンズとは、企業がまだ分類を終えていない、新しいツールが登場する非公式な共有スペースのことです。ロードマップに載ることのなかった課題を従業員がようやく自力で解決できるようになり、スクリプトやダッシュボード、エージェント、自動化、半分実用化されたプロダクトなどが一斉に芽吹く場所です。その空間は雑然としていますが、非常に価値があります。そこには隠れた需要や、不足しているプラットフォームの構成要素、顧客の痛み、そして公式のプロダクトプロセスがまだ把握していない社内ワークフローが顕在化しているからです。
しかし、共有地には管理が必要です。誰もそれを所有しなければ、有用な成果は目に見えないままになり、リスクのある作業が適切なサポートなしに拡散してしまいます。もしプロダクト部門が単にダメ出しをするためだけに登場するなら、従業員は何か問題が発生するまで便利なツールを隠すようになるでしょう。このような文脈において、PMが取るべきより良い姿勢は「オープンな探索」です。何を作ったのか見せてください、それが解決する問題は何ですか、誰が使っていますか、どのデータに触れていますか、そこから何を学びましたか、と問いかけるのです。
その上で、本番クラスのラダー（階層）を活用します。本番クラスのラダーには、この雑然としたプロトタイプ・コモンズを整理し、イノベーションを阻害するのではなく促進する形でPMの判断力を適用するためのいくつかの段が存在します。
まずは個人用ツールから始めましょう。個人用ツールは1人の人間のためのものです。作りは粗削りでも構いません。会社がローカルでの取り扱いに関するルールを定めていない限り、機密データからは遠ざけるべきです。また、これに関しては多くの標準規格を設ける必要はありません。
一段上に上がってみましょう。チーム向けベータは小規模なグループで使用されるものです。これには所有者と、そのバックアップとなる担当者が必要になります。短い説明文を用意し、それが触れるシステムやチームにもたらすメリットを明記し、障害発生時の対応プランを策定しておくべきです。
さらに一段上がります。サポート対象の社内プロダクトは、会社が実際に依存しているソフトウェアです。これにはプロダクトの所有権、プラットフォーム部門との連携、アクセス管理、監視が必要です。ドキュメント、サポート、監査可能性、そして変更プロセスが必要になり、一気に本格的なものになります。
そして4段目が、顧客向けプロダクトまたは機能であり、会社の外部プロセスの一部となるものです。これには通常のプロダクト基準に加えて、AI特有の評価や、必要に応じたガバナンスが求められます。
重要な点は、これらが全く異なるクラスであり、混同してはならないということです。あるものの最初のバージョンと、サポートされるバージョンが同じである必要はありません。古いモデルでは、PMがエンジニアリングに投入するものを決定し、それがサポート対象となり、公式なソフトウェアになっていました。新しいモデルでは、PMはプロトタイプ・コモンズから何を昇格させるかも決定します。
そして、ここでは昇格と同じくらい、降格させることも重要です。上に向かってしか進まないラダーは、最終的にガラクタ置き場になってしまいます。あらゆるものが最終的に本番環境やサポートレベルに到達してしまえば、誰も引き取りたがらない古い義務の山ができあがるだけです。そのため、本番環境でどのような顧客への約束をしたいのか、社内でどのような約束をしたいのか、そしてどれを意図的に降格させるか、あるいは個人用ソフトウェアのレベルに留めておくかを考える必要があります。これこそが本質的なPMの転換であり、これを行わなければ、企業は死んだソフトウェアのサポートコストを、その名前すら把握できないほどのスピードで支払い続けることになります。これこそが新しい技術的負債です。
プロダクトの議論では、AIがアイデアをどれだけ早くプロトタイプにできるかという点に多くの時間が費やされてきました。私もPMの仲間から何度もその話を耳にします。それは最初のバージョンのコストが崩壊したことを示し、私たちPMもそのプロセスに関与できるという意味で有用な視点でした。しかし、私は次の問いの方が重要だと考えています。プロトタイプが存在した後に何が起きるのか、という問いです。
もしその答えが「分からない、計画はない」であれば、会社はデモの墓場と化すでしょう。もし答えが「すべてを本番環境に投入する」であれば、会社はカオスに陥ります。もし答えが「中央のプロダクトとエンジニアリング部門だけが構築を許される」であれば、会社はAIが解放した莫大な創造的キャパシティをドブに捨てることになります。
より優れた答えは、実験については原則として許可するシステムを敷きつつ、ビジネスが依存する成果物に対しては、プロダクト部門が管理する非常に意図的な昇格パスを用意することです。これこそが私が推奨する意思決定のルールです。
PMの皆さん、自分のチームがより速く構築できるかどうかだけを問うのはやめましょう。自分が目にしているソフトウェアがどのクラスのものなのかを問いかけてください。それは個人用ツールですか、チーム向けベータですか、サポート対象の社内プロダクトですか、それとも顧客への約束ですか。その上で、さらに難しい問いを投げかけるのです。これは存在するべきなのか、誰のためのものなのか、どの基準を満たすべきなのか、そして私たちは何に依存することを許容するのか。これが、新しいプロダクトマネジメントの仕事です。
それまでの間、PMとして顔を上げて進んでいきましょう。今はプロダクトの領域にいる人間にとって、信じられないほどエキサイティングな時代です。長い間、私たちは「すべてを作ることはできない」と言い続けなければなりませんでした。しかし今、私たちはついにゲーム盤の反対側でプレイできるようになりました。「私たちは何でも作ることができる。では、何を作るべきか」と言えるようになったのです。そして、私は自分たちの判断力を試されるこの挑戦が大好きです。ですから、プロトタイプの段階を超えた先にあるPMになってください。自身の判断力を活かして本物の本番クラスのラダーを構築し、組織の創造的なエネルギーを、顧客にとって本当に重要なものを構築するために導いていきましょう。それではまた次回お会いしましょう。応援しています。
コメント