開発のボトルネックが実装から「仕様検討」へ。プロダクトマネージャーに求められる動き方

2026/07/29

生成AIやコーディングエージェントの登場により、開発における「実装（デリバリー）」は劇的に高速化しました。開発プロセス全体のボトルネックは、実装そのものから「要件定義や仕様検討」へと移行しつつあります。

これに伴い、プロダクトマネージャーとエンジニアの役割分担も、見直す必要が生じています。現代のプロダクト開発において、両者の役割はどのように再定義すべきなのでしょうか。今回は、LayerXのAI-BPOチームのプロダクトマネージャーである加藤（@michiru_da）さんにインタビュー。現在実践している開発体制と、これからのプロダクトマネージャーのあり方について詳しくお話を伺いました。

株式会社LayerX プロダクト企画統括部

加藤みちる

ベンチャー企業にてエンタープライズ向け受託システム開発の営業・プロジェクトマネージャー、新規事業の企画・立ち上げに従事。2021年11月に株式会社LayerXに入社し、バクラクシリーズのカスタマーサクセスとして100社以上のお客様運用を支援した後、2023年5月よりプロダクトマネージャーへ転向。2025年10月からAIエージェントの企画・開発を担当。

X：@applism118

AIの実装スピードを活かしきる。エンジニアが仕様策定を主導する体制へ

――生成AIの影響で、旧来と比較して開発プロセスにどのような変化がありましたか？

加藤：一般論として、これまでは「なぜつくるのか」という「Why」をプロダクトマネージャーが主導し、決定した方針を「何をどう設計し、どう実装するか」という「What」や「How」としてエンジニアがリードする、という明確な役割分担がありました。

ですが現在、私のチームでは役割の境界線を大きく見直しています。

具体的には、プロダクトの大方針や半年〜1年単位のロードマップを定め、「やるべきことと、やらないこと」を判断する大局的な意思決定は、引き続きプロダクトマネージャーが責任を持っています。一方で、大方針が決まった後の「この顧客課題を解決するために、どのような仕様で開発すべきか」という検討フェーズからは、エンジニアが主導する形へと移行しました。つまり、プロダクトマネージャーが仕様を細かく固めてエンジニアにパスするのではなく、大枠の方針をもとに、エンジニアが自ら機能を考えて実装まで推進する体制になっています。

――なぜ、機能を考える役割がエンジニア側へシフトしていったのでしょうか？

加藤：これは私たちのチームに限らず、今後の開発現場において「そうせざるを得ない」という側面があると考えています。

プロダクト開発は、課題を特定して解決策を決める「ディスカバリー」と、実際に実装して価値を届ける「デリバリー」のサイクルで回ります。生成AIやコーディングエージェントの登場によって、デリバリーのプロセスが一気に高速化しました。

その結果、開発プロセスにおけるボトルネックの位置が変わりました。これまでは実装そのものに時間がかかっていましたが、今ではその前段階にある「要件定義や仕様検討」をプロダクトマネージャーが一人で抱え込むことや、実装後の「品質確認やリリース可否の判断」に時間がかかることのほうが、全体のリードタイムを延ばす要因になっています。

従来型の体制のままでは、AIによる実装の高速化を活かしきれず、結果として顧客に価値を届けるスピードが上がらなくなってしまいます。そのため、役割分担を変化させていく必要がありました。

生成AIは「デリバリー速度の向上」と「不要な機能をつくるリスク」の両方をもたらした

――仕様検討をエンジニア主導にし、AIエージェントをフルに活用する体制へ変えたことで、生じた変化について教えてください。

加藤：ポジティブな変化としては、大きく2つあります。

1つ目は、価値を顧客に届けるデリバリーのスピードが向上したことです。大枠の正しい意思決定さえできれば、相当な速さでプロダクトをつくれるようになりました。

実例として、私が現在のチームへ移ったのは新規事業の立ち上げだったのですが、ユーザーニーズの探索からサービスのリリースまで、わずか3か月で実現できました。半年はかかると想定していたため、想像以上の速さでした。

2つ目は、プロダクトマネージャーが開発チームの内側に閉じず、より広い視野で動けるようになったことです。これまでは仕様検討に多くのリソースを割いていましたが、そこをエンジニアに任せられるようになったことで、プロダクトをどう市場に届けるか（Go-To-Market）に、より深くコミットできるようになりました。

私自身、数年前と比べてお客様と直接対話する時間がとても増えています。以前は多くて月に10〜15社程度の打ち合わせだったのが、今では毎日のように複数社とお会いしています。時には自分自身が営業担当として商談に立ち、お客様に直接プロダクトを提案することもあります。

――その逆に、新たに生じている課題はありますか？

加藤：「深く考えなくても、簡単に機能がつくれてしまうこと」です。

これまでは、実装の難易度や工数が自然とフィルターの役割を果たし、本当につくるべき機能の取捨選択を促していました。しかし、AIによって開発コストが極めて低くなった現在では、「本来はつくらなくてもいい機能」や「多くのユーザーにとって優先度が低い機能」まで簡単に実装できてしまいます。

機能が増えることは一見ポジティブに思えますが、裏を返せば、ユーザーに強いる認知コストが増えることでもあります。機能が乱立した結果、かえってプロダクトが使いづらくなっていないか、これまで以上に厳しく目を光らせる必要があると感じています。

仕様が複雑になってきたら一度立ち止まる。小手先で解決せず「課題の整理」を重視

――確かに今は「何をつくらないか」「途中までつくったものをいかに勇気を持ってやめるか」の決断がより重要になっています。加藤さんが大事にされている判断基準はありますか？

加藤：「仕様が複雑になってきたら、一度立ち止まる」という判断基準を大切にしています。要するに、「複雑になっているときは、そもそもアプローチの何かがおかしい」というのが、社内の共通認識です。その場合は、作業の手を止め、私たちが本当に解決したかった課題は何だったのか、という原点に立ち返るようにしています。

――仕様に複雑さが生じてしまうとき、何が原因のケースが多いのでしょうか？

加藤：大きく分けて2つの原因があると考えています。

1つ目は、広すぎるユースケースを一気に解決しようとしすぎていること。ターゲットを絞り込めず、あれもこれもと欲張って要素を詰め込んでしまうと、結果として仕様はどんどん肥大化します。

2つ目は、解きたい課題が十分にクリアになっていないこと。プロダクトで何を解消したいのかという問題の解像度や、解決すべき優先度が曖昧なままだと、「あれもこれも必要だ」という思考に陥りがちです。

こうした複雑さに陥ってしまったときは、仕様の調整で小手先の解決を図るのではなく、開発のフェーズを「課題の整理」まで戻すようにしています。プロダクトを開発しようと考えた背景にある顧客の事象を、もう一度洗い出し、整理し直しています。

――その上で、どのようにして優先順位を決め、意思決定するのでしょうか？

加藤：私自身は「課題の優先度」と「ソリューションの優先度」の掛け合わせで判断しています。

まず「課題の優先度」は、事業の状況に応じて複合的に決めます。たとえば「今のフェーズは新規のターゲット層を獲得したいから、その特定の業界で直面している課題を最優先にしよう」という事業戦略的な判断もあれば、「多くのユーザーが直面している不便な業務フローを優先して解消しよう」という実用性重視の判断もあります。

次に「ソリューションの優先度」ですが、ここでは基本的に投資対効果を重視します。たとえば、「1つのシンプルな機能を追加するだけで、ユーザーが抱える3つの課題を一気に解消できる」といった、最小の投資で最大の効果を得られるソリューションを優先します。

また、「機能のコスパが良さそうか」「ユーザーにとってどんなUIが最も刺さりそうか」を判断する際にも、AIが役立ちます。私の場合は、AIエージェントによって画面のモックを複数パターンつくり、比較しながらどれが適切かを判断しています。

顧客理解が仕様策定の鍵。ドメイン知識を向上させる「2つの地道なアプローチ」

――冒頭で「エンジニアが自ら仕様を考える」というお話がありました。とはいえ、エンジニアの中には「ドメイン知識が不足しているため、仕様策定に関わることが難しい」という方もいると思うのですが、その場合はどうすべきでしょうか？

加藤：おっしゃる通りで、専門性の高いビジネスドメインを扱う場合、戸惑うメンバーは当然出てきます。

以前、私が社内で別のプロダクトを担当していた際、チームのエンジニアが急遽入れ替わり、メンバーの大半が入社したばかりという状況に直面したことがありました。ドメイン知識がゼロに近い状態から、自律的に動けるチームをつくる必要があったんです。その時に、地道に取り組んだことが2つあります。

1つ目は、エンジニアに「顧客の商談へ同席してもらうこと」です。時には、エンジニア自身から直接お客様に質問を投げかけてもらいました。顧客とのやり取りを直接目にすることで、「お客様はここで困っているんだ」「なぜ既存のやり方や代替手段では解決にならないのか」などを、肌感覚で深く理解できるようになります。

2つ目は、プロダクトの「全機能を使い倒し、ユースケースを言語化してもらうこと」です。すでに実装されている機能をエンジニアやデザイナー自身に触ってもらい、「これはどういう業務の、どんな課題を解決するためにつくられた機能か」を自分たちの言葉で言語化してもらいました。この際、プロダクトマネージャーはあえて最初から詳しくは説明しませんでした。自分たちで触り、仮説を立てて理解してもらうプロセスを泥臭く積み重ねました。

また、それ以外にもLayerXでは、データを蓄積してメンバーがいつでも顧客のリアルな声にアクセスできる環境を整えています。そうした情報をもとに、ドメインや顧客への理解を深められるのも大きいです。

たとえば、お客様に許可をいただいた上で、オンライン商談の動画や電話の録音データを保存しています。これらは自動的に文字起こしされ、テキストデータとして一元管理されています。

さらに、内製の社内ポータルを用意しており、「特定のお客様が、ある課題について話しているシーンを抽出してほしい」と検索をかけると、該当する箇所の動画や文字起こしテキストがすぐに提示される仕組みになっています。

今後求められる3つの専門性。変化の激しい時代を、前向きに乗りこなす

――プロダクトマネージャーの役割が変化していく中で、今後はどのようなスキルがより重要になっていくでしょうか？

加藤：大前提として「ユーザー体験を磨くこと」や「何をつくり、何をつくらないかを決めること」は、これまでもこれからも、プロダクトマネージャーにとって必須の土台です。その上で、より高い価値を発揮するためのスキルセットは、大きく3つのタイプに分かれていくと考えています。

1つ目は、ビジネスに強いタイプ。自ら営業ができ、事業の戦略や成果を引っ張っていける人です。2つ目は、技術がわかるタイプ。エンジニア出身などで、技術の詳細を理解した上で、自らプロダクトづくりを主導できる人です。3つ目は、ドメインエキスパートタイプ。経理や金融といった特定ドメインの知識があり、業務の課題や現場への解像度が圧倒的に高い人です。これらのいずれかの強みを持つ人の価値が、今後より高まっていくと思います。

――まだどの領域にも自信を持てないプロダクトマネージャーが、顧客や事業、ひいては経営への理解を深めていくために、日々の業務でできるトレーニングはありますか？

加藤：顧客理解を深める上での近道は、「自分で営業をしてみること」です。

プロダクトマネージャーは、営業に向いていると私は思っています。なぜなら、顧客の困りごとを言語化し、納得感のある解決策を提示していく営業のプロセスは、私たちが普段行っているユーザーヒアリングや仕様検討の本質とまったく同じだからです。

また、経営目線を養うためには、「自分で数値を背負うこと」が大事です。私も現在のプロジェクトに移ってから、事業の数値を特に細かく追うようになりました。そこで初めて見えてきた世界がたくさんあります。業務の中に「この数値をどう動かすか」というミッションを組み込み、当事者として数字に向き合う機会を意図的につくることが重要です。