【イベントレポート】プロダクトマネージャー勉強会~各社の取り組みや課題から学ぶ会~

こんにちは、TECH Street編集部です!

この記事では、2026年2月26日(木)に開催した「プロダクトマネージャー勉強会〜各社の取り組みや課題から学ぶ会〜」の登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。

 

登壇者はこちらの方々!

*

椙浦 弘之

パーソルキャリア株式会社
ゼネラルマネジャー

Webディレクターとして、キャリアをスタート。Eコマース、SNS、メディアの新規開発や運用を経験。2024年よりパーソルキャリアにて「dodaダイレクト」のPdMグループのマネジャーを務める。

*

増井悠太

Thinkings株式会社
PdM

新卒でThinkings株式会社に入社し、エンジニアとして採用管理ツールsonar ATSの連携機能開発を担当。その後、2024年よりプロダクトマネージャーを務める。

 

LLMを利用した開発、はじめの一歩!〜PdMが直面する課題と解決のプラクティス〜

ない業務を作るということ〜採用管理システムの提供機能拡大への挑戦〜

Q&Aコーナー

(Q)生成AI開発への移行(兼務)は色んな企業で始まっているかと思いますが、一番大きかった壁(本当につらかったこと、スライドでも書けなかったこと)を聞いてみたいです。 
 
椙浦:最初の一歩を踏み出すこと自体が大きな壁でした。「本当に成果が出るのか」という懸念が、足踏みしてしまう理由になっていました。チームとして「やらなければならない」という機運を醸成すること自体が非常に大きなハードルであり、技術的な課題というよりも、最初のマインドセットをどう構築するかが最大のネックだったと感じています。 
 
増井:AIを使えば「それらしいもの」はすぐに作れてしまうという点が、逆に難しさでもありました。それを実際のプロダクトとしてどのように設計し、どのような価値として顧客に届けるのかという全体像を描くことに非常に苦労しました。 


 
(Q)生成AIの出力に正解がない状況で、プロダクトとしての評価指標(KPI)はどのように定義したかについてぜひお聞かせください。 
 
椙浦:当社の場合は、比較的KPIを設計しやすい環境にありました。というのも、既存の「検索機能」をAIで代替するという明確な目的があったためです。具体的には、ユーザーが入力した条件に対して、AIが出力する検索結果が、従来の検索で得られる「現時点で正解に近い結果」とどの程度一致しているかを、定量的な指標として評価しました。この一致率を追うことで、KPI設計は比較的スムーズに進めることができました。 
 
増井:出力自体の評価は定性評価をしつつ、その後の過程(採用など)への活用率などを軸に検討しています。 


 
(Q)dodaは有名なシステムだと思いますが、同じ界隈や同様のサービスの中でも生成AI開発は早い方でしたか?参考にされた他のサービスや企業の取り組みなどはありましたか? 
 
椙浦:着手は早い方ではなく、どちらかといえば遅い方でした。著名な企業が次々と生成AI関連のリリースを発表していくなかで、その動向は継続的にウォッチしていましたが、なかなか自社として一歩を踏み出せない状況が続いていました。今回は「検索機能」に特化していたので、同じように検索領域で生成AIを活用している企業の事例は積極的に参考にさせていただきました。 


 
(Q)LLMを利用するにあたって、参照する情報(既存システム)のデータ構造が、そもそもAI対応に耐えられない状態にある場合があるかと思います。そのような場合、各工程はどのように変容しますか? 
 
椙浦:当社の場合、まさに既存のデータ構造がそのままでは耐えられないので外部の仕組みによって補完するアプローチを取りました。「非構造化データをそのまま扱うのではなく、生成AIを活用して一定の構造を持たせる」、ということで生成AIに頼りました。 
 
増井:現時点では既存システムのなるべく外側でやろうとしているので、この課題にはまだぶつかっていません。ただし、今後プロダクトへの本格的な組み込みを進める段階では、必ず向き合うべき課題になると考えています。 


 
(Q)エンジニア層とビジネス層ではAIへの理解度が異なると思いますが、PdMの立場でエンジニアに対して指示や指摘をするのは、エンジニア出身でないと厳しいと感じています。PdMとしてどの程度AI開発の勉強をされていますか? 
 
椙浦:私自身もエンジニア出身ではありません。実装の詳細についてはエンジニアの方が当然詳しいという前提でコミュニケーションを取っています。意識しているのは、断定的に指示を出すのではなく、「こう考えているのですが、どうでしょうか?」という相談ベースで議論することです。一方で自分自身の勉強も一生懸命頑張ってます。社内でもAIリテラシーを底上げしようという機運があり、例えばG検定レベルの知識を身につけることを目標に、資格取得に向けた勉強なども行っています。 
 
増井:私は元々エンジニアなのと、プライベートでもバイブコーディングをしている立場です。そのため「生成AI時代の開発体制のあり方」についても、積極的にキャッチアップして取り組んでいるところです。 


 
(Q)LLMをプロダクト適用させる場合、実際の開発体制(人数と役割)はどうだったのか、また、理想の開発体制(本当はこんな布陣が必要だったという感触)について伺いたいです。 
 
椙浦:比較的理想に近い形でスタートできたと感じています。ミニマムな構成として、PdMが3名、デザイナー1名、エンジニア4名という小規模チームで取り組みました。自走できるメンバーを寄せて作ったので、かなり良かったと感じています。 

一方で、理想でいうと、NG率などのテスト要員やQAメンバーがいるとより良かったかなと思っています。生成AIの特性上、評価軸を巡って議論が生じる場面も多くあったので、最初は小さなチームで素早く試行錯誤を重ねる形で進めたことは、結果的に適切だったのではないかと考えています。 
 
増井:PoCフェーズなので、PdM1名、エンジニア1名、デザイナー1名です。もう少しエンジニアがいても良かったのですが、試行錯誤や探索部分が多いため、コミュニケーションのしやすさとしても、やりやすい人数ではありました。 


 
(Q)今後、プロンプトの調整では挙動を制御できなくなることも想定されるかと思います。その場合、LLMモデルの切り替えが選択肢に入ると思いますが、その際の切り替えフローを作成されておりますでしょうか。されていたら、どのようにフローを作成したか伺いたいです。 
 
椙浦:現時点で、フローが完全にできてるわけではありません。ただし、LLMのモデル自体が使えなくなったり、バージョンアップでの切り替えの発生は絶対条件だとは認識しています。現段階では準備途上ですが、継続的に整備していくテーマだと捉えています。 
 
増井:当社でも、明確なフローが確立しているわけではありません。ただし、すでにリリースしているプロダクトにおいて、モデルのバージョン変更による挙動の変化や、それに伴う調整の必要性が発生しているという話は把握しています。そのため、将来的なモデル切り替えを想定した仕組みも検討している段階です。 


 
(Q)従来開発と異なるポイント〇選!のようなまとめをお願いします。 
 
椙浦:100%の回答はない、揺らぎがあるということを踏まえて開発すること。許容範囲を決めながら進めるのが重要だなと思っています。 
 
増井:事前にすべてを考えきる、という姿勢はいったん手放して、「とりあえずやってみよう!」も大事だと思っています。ただ、何でもかんでも試していると時間がかかりすぎてしまうので、やはりバランスが大事かなと感じています。 


 
(Q)LLM実装で一番難しかったポイントは? 
 
椙浦:品質です。本質的に出力に“揺らぎ”があるため、どこまでを許容範囲とし、どこからをNGとするのか、その線引きを決めることが非常に難しかったです。一定の基準を設けたとしても、想定していなかった外れ値が突然出てくることがありました。 
 
増井:アウトプットを制御しきれないので、「終わりが見えないこと」です。どこでストップするかが難しいです。ある時点で「これでOKだろう」と判断しても、思わぬところに抜けや想定外の挙動が見つかることもありました。 


 
(Q)プロンプトの設計のマニュアルは社員(パーソル社員)向けですか?クライアント向けのマニュアルですか? 
 
椙浦:マニュアルは社員向けです。 


 
(Q)アウトプットそのものは検索条件だったという認識ですが、実際に利用する企業の採用担当からの反応としては肯定的なものばかりでしたか?スカウト候補者をアウトプットとして直接返すほうが助かるという反応も少なからずあるのかなと思いまして。 
 
椙浦:現時点では、まだ改善の余地があると認識しています。賛否両論の反応があるのが事実です。どちらがより価値を提供できるのかについては、チーム内でも議論が分かれるポイントでした。そのため、最終的な判断はユーザーの反応を重視しました。 


 
(Q)PoCにて品質の評価とありましたが、数値化しての評価が難しいと推測します。具体的にどのような評価をしたのか、お聞かせいただける範囲でお話いただけるとです。 
 
椙浦:検索項目として含まれるべき要素に“揺れ”があります。NG率を一定の基準以下に抑えること、アウトプットとして出てきてはいけない言葉がきちんとはじかれていること、というのを評価項目に何度も繰り返してデータを取って、検証しました。 


 
(Q)解くべき課題はLLMで何か作ろうと動き出してから定義されたのか、元々存在していた課題(問題)がフィットしそうだから検討してみようとなったのかでいうと、どちらでしょうか?LLMでできることはたくさんありそうなため、多数ある課題の中でもこの課題にしようとなった経緯や決め手をお伺いしたいです。 
 
椙浦:課題としては「検索」にボトルネックがあるということ。「検索条件を入れる」というのが構造化されていないデータ。そこで、非構造化データをうまく整理し、検索条件として活用できる形に変換できれば、体験を改善できるのではないかという仮説が生まれました。LLMはその解決手段としてフィットする可能性があると感じていた、というのが当時の状態です。 


 
(Q)従来の開発に比べて、開発コストはかかる印象です。得られたものもあると思うのですが、導入効果はいかがでしょうか。話せる範囲で構いません。 
 
椙浦:チーム自体は小さく、少数精鋭でやっているのでコストはそこまで大きくないです。LLMでプロンプトを叩くので、そういった面ではランニングコストがかかっています。現時点での効果はまだ限定的ではありますが、「確実に手応えはある」という感触を得られています。実際に改善につながる可能性が見え始めたことで、プロジェクトの方向性に対する確信も強まりました。また、チームメンバーの中に「やれる」という自信が生まれたことも、大きな副次的効果だと感じています。 
 
増井:費用的で見ると、一定のコストはかかっていますが、開発スピードという観点では効果を感じています。生成AIを活用することで、試作や検証を短期間で回せるため、ゴールに到達するまでの時間は短縮できています。

 
 
(Q)市場にも正解がない中で、情報収集や参考情報とかはどんな感じで、どんな体制で進められましたか? 
 
増井:具体的には、ターゲット層としているメンバーにヒアリングしたり、各社の課題をヒアリングしたりしました。また、生成AI領域は海外での進展が早いため、海外の動向も調べて自社の方向性を検討しました。 


 
(Q)高速で検証している中で、新しいツールが出てきたときにはすぐ試しましたか? 
 
増井:途中まではある程度取り組んでいたのですが、だんだんしんどくなってきたので、手を広げすぎずにバランスを取って進めることが大事だと思います。 


 
(Q)発想ファーストで始まったのですか?何か明確に問題や課題があったのでしょうか? 
 
増井:明確に業務課題があるというよりは、ユーザーのペインに対し、AIを使ったソリューションが考えられるのではないかという起点です。 


 
(Q)PdMがCJMやNSMなどの全体像を立ち上げても、エンジニアがそれについてこれないケースがあるなと往々にして感じます。全体が同じ目線にする為に工夫されている事はありますか? 
 
増井:既存の状態だと起こりやすいと感じています。要件をがっちり決めすぎると辛いです。今のプロジェクトは、まずプロトタイプを早い段階で作成し、具体的なイメージを共有するようにしています。また、ユーザージャーニーも明確に言語化し、「どの体験を実現したいのか」という目的を共通認識として持つことを重視しています。 


 
(Q)利用するツールは、どのような観点を持って選定されましたか? 
 
増井:開発ツールの選定においては、「自分たちの手にできる範囲で」ということになります。あとは、機密情報に触れない形で検証できるものであれば、ライトに試して選びました。 


 
(Q)開発タスクに追われてPRのレビューが滞ることがよく起こっており、どのように回避されているか教えてください。 
 
椙浦:アジャイル開発で進めています。スプリントごとに明確なゴールを設定しているため、多少の遅れが出たとしても、最終的にはそのゴールに合わせて帳尻を合わせる形で運用しています。スプリント内であれば一定の遅れは許容範囲としています。 
 
増井:スクラムを採用しており、スプリントを区切ったうえで進めています。特に意識しているのは、あらかじめバッファを確保することです。計画段階でレビュー時間を織り込んでおくことで、突発的なタスクに追われてもPRが滞らないようにしています。

 
 
(Q)開発速度が上がったことにより、ストーリーポイント等の見積もり精度の振れ幅が大きくなり、ビジネス側に実装スケジュール感を伝えるのが難しくなったなと感じています。同様の経験がありましたら、どんな対応を行なったかご教授いただけると幸いです。 
 
椙浦:生成AIを活用する開発では、従来の前提で設定していたストーリーポイントが必ずしも当てはまらない場面が増えています。そのため、見積もり精度が高くないことを前提として、あらかじめビジネス側に共有しています。特に意識しているのは、スケジュールに一定の幅を持たせて伝えることです。 
 
増井:見積もり精度は大きくずれる前提で、最初から余裕を持ったスケジュール設計を行い、途中で軌道修正しやすい形にしています。 


 
(Q)エンジニアがAIを駆使して高速に開発できてしまうので、要件定義に追われることが増えてきました。今回ご紹介いただいた事例ふくめ、要件定義はどの程度AIに任せていますか? 
 
増井:PRDなどはAIに整理・発散・レビューさせることも多いです。ただ、今後はむしろ細かい要件は定義せずに、仮説の根拠をあつめることやプロトタイプを作りに行ってしまう方がよいのかなと感じ、徐々にそちらに移行しようとしています。 

イベント中にあがったQ&Aは以上です。

今回の登壇レポート一覧

LLMを利用した開発、はじめの一歩!〜PdMが直面する課題と解決のプラクティス〜

ない業務を作るということ〜採用管理システムの提供機能拡大への挑戦〜

Community Members

さまざまなテーマで事例や知見を学ぶ
IT・テクノロジー人材のための勉強会コミュニティ

①上記ボタンをクリックするとTECH PLAY(外部サイト)へ遷移します。

②TECH PLAYへ遷移後、アカウントをお持ちでない方は、新規会員登録をお願いいたします。

③TECH PlAY会員登録後、TECH Streetページよりグループフォローをしてください。

今後のイベント参加・メンバー登録に関する重要なお知らせはこちら