こんにちは。askenでシニアテックリードをしている岩間です。
2月に開催された Developers Summit 2026 に、シニアPdMの伊藤拓哉と2人で登壇しました。
また、後日発表されたアワードにて、
- 「Developers Summit 2026」ベストスピーカー賞 7位
- 公募賞 1位（同率）
をいただきました！！当日セッションを聞きに来てくださった皆さま、SNSなどで反応をくださった皆さま、本当にありがとうございました！！！
▶︎【Developers Summit 2026 ベストスピーカー発表】参加エンジニアの心を掴んだ必見セッションを一挙紹介！
登壇テーマは、AIを活用したプロトタイピングを起点に、PdMとエンジニアがどのように協働し、価値検証から商用リリースまでのプロセスを再設計していくかです。
AIによってプロトタイプを作るハードルが下がった一方で、価値検証したものをどう本番品質まで持っていくかは、別の難しさがあると感じているからこそのテーマ選定でした。
本記事では、デブサミでお話しした内容を振り返りながら、askenで実践しているPdMとエンジニアの共創プロセスについて紹介します。
セッションの要旨
セッションタイトル：「Vibe Coding起点での新機能開発で『あすけん』が乗り越えた壁 ～PdM&エンジニアの新たな共創プロセス～」
テーマ：AIを活用したプロトタイピング（Vibe Coding）を起点に、PdMとエンジニアがどのように協働し、プロダクト開発のプロセスを再設計していったのか
ポイント：PdMである伊藤が「価値の定義と検証」を、エンジニアの私が「技術設計と実装」を担当し、それぞれの専門性を最大限に発揮するための順序と境界をどのように設計したかを、両者の視点からお話ししました。
▼スライド
今回、一番伝えたかったのは
Vibe Codingは起点にすぎない。本質は、PdMとエンジニアが最大の専門性を発揮できる「順序」と「境界」を設計しようということでした。
もう少し噛み砕くと、PdMが価値検証をできるだけ早く回し、価値が確認できたものをエンジニアができるだけ早く商用環境へ届ける。
そのための分業と連携のプロセス設計です。
具体的には、次の2点を軸に取り組みを進めました。
- AIによってプロトタイピングがやりやすくなったことを活かし、プロトタイプを実際にユーザーへ公開して価値検証できる環境（あすけんラボ）を整える
- 価値が確認できたものを、商用環境へ素早くリリースするためのプロセスを構築し、運用する
価値検証を加速するための「あすけんラボ」
1.で登場するあすけんラボとは、新機能をプロトタイプとして実装した際に、限定したユーザーへ公開するための専用環境です。
私が入社した当時（2024年1月）は、大きめの機能開発を伴う仮説検証を進めにくい状況がありました。
理由は明確で、既存のソースコードに手を入れる負荷が高いうえに、時間をかけて開発しても、ユーザー評価が低ければ機能を取り下げる可能性があるためです。これでは、仮説検証のサイクルを回しづらくなります。
あすけんラボは、この課題を解決するために作ったものです。
使い捨てることを前提に、フロントエンドはWebベース、バックエンドはサーバレスの簡易構成と割り切ってプロトタイプを実装し、限定したユーザーに公開してフィードバックを得るための基盤として2025年2月に作りました。限定公開といっても、対象ユーザーが1万人を超えることもあります。
ちょうどこの時期からVibe Codingも広がり始め、PdMが自らプロトタイプを作り、公開して価値検証を進める場としても、この基盤を活用できるように構築しました。
発表で取り上げた「AIおまかせ記録」の開発もその一例ですが、最近ではLLMを組み込んだプロトタイプ開発の用途も増えています。
価値検証済みのものを商用環境へ素早くつなぐプロセス
2.で取り上げた商用環境へ素早くリリースするためのプロセスとは、PdMが作ったプロトタイプ（資料内では「動くPRD」と表現）をAI（Claude Code）でリバースエンジニアリングし、商用開発に向けた要件定義や基本設計のインプットとして活用する取り組みです。
ここで目指したのは、プロトタイプのコードや実装をそのまま本番に持ち込むことではありません。
プロトタイプから、商用開発に必要な情報を抽出し、要件定義と基本設計の初速を上げることです。
具体的には、プロトタイプの振る舞いやソースコードからユースケース、機能要件、データ項目、外部連携の論点などをリバースエンジニアリングすることで抽出・整理し、商用開発の材料として再利用していきます。
一方で、品質特性や運用設計、アーキテクチャ設計といった非機能面については、従来通りエンジニアが中心となって設計・判断します。
当初は、リバースエンジニアリングの結果精度が十分ではなく、思うように効率化できませんでした。
そこで、Claude Code plugin を用意するなど、プロトタイプから情報を抽出しやすくする工夫や試行錯誤を重ねました。その結果、要件定義や基本設計のたたき台を作る工程において、一定の手応えを得られるようになってきています。
なお、この時期は Claude Code のモデル性能（opus 4.5, opus 4.6）が上がってきたタイミングでもあり、LLM自体の進化による効果も大きかったと考えています。
※ 資料中の「リファインメント」は、要件定義＋基本設計を指しています。
理想を先取りしすぎない、という判断
最近は、PdMとエンジニアの境界が曖昧になっていく、AIによってPdMが開発できるようになる、エンジニアにはPdM的なスキルも必要になる、といった議論をよく見かけます。
私自身も、もともとはその方向にかなり期待していました。
本当は分業せず、PdMが自らコーディングまで担えるようになれば、それが一番速いのではないか。そう考えていた側でもあります。
ただ、今回の取り組みを通じて、その変化を前提に進めるにはまだ早いと感じました。
確かに大きな方向性としては、PdMとエンジニアの境界はこれから少しずつ変わっていくと思います。一方で、今このタイミングで開発を速くし、成果につなげるためには、理想を先取りしすぎないことも重要でした。
その中で私たちがたどり着いたのは、あえてPdMとエンジニアの間に境界を置き、それぞれが専門性を発揮しやすい順序でプロセスを組み立てる、という考え方です。
PdMが価値の定義と検証を素早く進める。
エンジニアがその結果を受け取り、商用開発に必要な設計と実装を進める。
境界をなくすことではなく、いま必要な境界を適切に設計することのほうが、現時点では結果的に速い。これが今回の大きな学びでした。
今後AIがさらに進化すれば、この境界の引き方も変わっていくはずです。
だからこそ固定的に考えるのではなく、その時点で何が人に向いていて、何がAIで前倒しできるのかを見極めながら、プロダクト開発全体の進め方を継続的にアップデートしていきたいと考えています。
さいごに
登壇後、Xなどでもいくつか感想をいただきました。
特に嬉しかったのは、技術そのものだけでなく、PdMとエンジニアの共創の進め方や、「順序と境界」という整理に反応してもらえたことです。
「これから同じような取り組みを始めるにあたって参考になった」という声も多くいただきました。各社で似たような課題感があるのだと実感しています。私たちとは異なる考え方や進め方の事例もあると思うので、ぜひ共有していただけると嬉しいです。
また、セッションでは、話すのに少し勇気が必要な失敗も包み隠さず紹介しました。
意外にもこのパートへの反応が大きく、キラキラした成功事例だけでなく、泥臭い失敗や学びを求めている方も多いのだと感じました。これから似たような挑戦をする方にとって、先に地雷を踏んだ事例として役立ててもらえたなら、発表した意味があったと思っています。
Special Thanks !
こちらの写真は登壇を終えて打ち上げをした時のものです。
写真の左側にいるEM達（手間から羽鳥、西、村上）には、時間が限られる中でスライドレビューや発表リハーサルに何度も付き合ってもらいました。めっちゃ感謝です。みんないい顔してます！
興味を持ってくれた方
askenは、AIを全力で活用しながら、プロダクトも組織も個人も成長し続けている場です。
もし興味を持っていただけたら、ぜひカジュアル面談でお話しましょう。
