要約

新規プロダクトのAI駆動開発において、「AIにコードを書かせる」だけではなく、開発の進め方そのものを見直した話
見直したのは下記3つ
① 開発手法の変化：「アジャイル型」から「スカルプト型」
② ミッション設計の変化：「分業体制」から「オーバーラップ体制」へ
③ 判断軸の変化：「制約ベース」から「目的ベース」へ
どんなAIツールを使ったかというより、PdMとして何をどう考え、チームにどう関わったか、どうプロセスを組み替えたかをまとめている

前提となる状況

まずは、置かれていた状況を簡単に。

新規のAIプロダクトを立ち上げる少人数チーム
既存事業とは少し距離のあるドメイン
PdM・デザイナー・エンジニアが同じテーブルで動く構成

生成AI（LLM）は主に、

アイデアやメモを「構造化された文章」にする
「体験の流れ」や「業務のステップ」を整理する
資料や仕様の「たたき台」を高速で出す

といった用途で使っていました。

とはいえ、「ツールとして便利」どまりにせず、開発プロセスそのものも変えられないか？ という問題意識があり、そこにトライしたのが今回の話です。

① 開発手法の変化：「アジャイル型」から「スカルプト型」

これまで：小さなストーリーを積み上げる

関わってきたプロダクトの多くは、いわゆるアジャイルな進め方でした。

ユーザーストーリーに分解する
優先度の高いものから実装する
小さくリリースして学びを得る

このやり方は今でも有効ですが、新規AIプロダクトでは次のような難しさがありました。

そもそもの完成イメージが人によってバラバラ
文章だけのストーリーでは、ユーザー体験の温度感が共有しづらい
この機能の先に、どんな世界をつくりたいのかが見えにくい

そこで、進め方をひっくり返してみました。

スカルプト型：まずAIで「全体像の塊」を出し、そこから削る

この記事では、次のような進め方を便宜上「スカルプト型」と呼びます。

AIでプロダクトの「全体像の塊」を一気に出す

人間がそこから削って、最初に取り組む範囲を決める

ステップ1：「こうなっていてほしい世界」を文章にする

最初にやるのは、機能のリストアップではなく、世界観の文章化です。

どんなユーザーが
どんな状況で
どういう状態になっていたら「変わった」と言えるのか

を、文章で書き出します。
この時点では、画面・API・テーブル設計といった単位にはまだ分解しません。

ステップ2：AIで「全体像の塊」を出してもらう

その文章と周辺メモを、ほぼそのままAIに渡し、

ユーザーが最初に接点を持ってから価値を受け取るまでの大まかな流れ
途中で発生する主なやりとりや意思決定のポイント
関係者ごとの役割や動き方のイメージ

といった、「プロダクト全体のストーリー」を文章ベースでまとめてもらいます。

ここでほしいのは、細かい仕様ではなく“全体像の塊” です。

ステップ3：どこを削るか・どこから始めるかに集中する

AIが出してくる全体像は、基本的に“盛り盛りの理想像”になります。
そこから人間側は、削ることと順番を決めること に集中しました。

例えば次のような観点です。

今期（あるいはこの期間）で本当に向き合う範囲はどこか
後ろに回しても学びが失われにくい部分はどこか
ユーザーヒアリングや利用ログで、反応が強かったポイントはどこか

ヒアリングの結果や、実際に触ってもらったときの反応も踏まえつつ、

まずはここだけやる
ここは一旦やめる
これは別プロダクトとして切り出すかもしれない

といった切り分けをしていきます。

ステップ4：残した部分だけを、チームで具体化する

削って残した部分についてだけ、チームで具体化を進めます。

ユーザーにどう触れてもらうか
どんな単位で画面やフローをまとめるか
裏側でどんな情報が行き来している必要があるか

より細かい仕様やドキュメントの初稿はAIに任せて、
人間側は 「何を採用して、何を変えるか」に集中する 形にしました。

② ミッション設計の変化：「分業体制」から「オーバーラップ体制」へ

職種ごとのミッションがバラバラに走る問題

よくある構造だと、

PdM：課題整理・要件定義・優先順位付け
デザイナー：体験設計・UIデザイン
エンジニア：設計・実装・運用

のように、ミッションが職種ごとに分かれます。

ただ、新規AIプロダクトのように、

ユーザーの使い方も仮説だらけ
AIの振る舞いも、動かしながら調整していく

という性質のプロダクトでは、「ここからは◯◯の仕事」という線引きがむしろボトルネック になる場面が増えました。

オーバーラップ体制：ユーザー体験に向かって、役割を重ねる

そこで意識したのは、

「自分の専門領域を守る」
というよりも、
「ユーザー体験に向かって、専門領域を少しずつ重ねていく」

という方向へ寄せることでした。
これをここでは「オーバーラップ体制」と呼んでいます。

ポイントは、「職種をなくす」ことではなく、

PdM・デザイナー・エンジニアそれぞれが
AIを使いながら
お互いの領域の“手前”まで踏み込む

状態を意図的につくることです。

実際にどんなオーバーラップをしたか

いくつか例を挙げると、こんな感じです。

PdMのオーバーラップ
- 画面やフローのラフを、自分で（AIの補助を使いながら）作って共有する
- 顧客に当てる用のLPや、デモ用プロトタイプのたたきをまず自分で作ってみる
エンジニアのオーバーラップ
- ユーザーヒアリングに同席してその場で要求を収集し、解決案まで出して仕様に反映する
- AIを使って業務フローや情報の流れを図解し、「こういう形ならもっとシンプルに実現できる」という提案をする
デザイナーのオーバーラップ
- 画面単体ではなく、体験全体のストーリーや「裏側で起きていること」の整理にも関わる
- AIにコピー案やレイアウト案を大量に出してもらい、プロダクトの方向性に合うものを選びながら調整する

生成AIがあることで、

ラフなメモから、構造化された図や文章を起こせる
LPやデモのたたきをすぐに用意できる

ようになり、専門外の作業にも一歩踏み込みやすくなった という実感があります。

結果として、

「これは誰の仕事か？」よりも
「この体験を良くするために、今誰が一番早く動けるか？」

という基準でタスクを拾いやすくなっていきました。

③ 判断軸の変化：「制約ベース」から「目的ベース」へ

ありがちな判断：工数・リソースから入る

日々の判断の場面を振り返ると、ついこうなりがちです。

これは何人日かかりそうか
今のスケジュールに入るのか
他の案件との優先度はどうか

もちろん必要な観点ですが、ここから入ると、

「やる／やらない」の二択で議論が止まりやすい
そもそもの目的や、変えたい体験がぼやける

という問題も出てきました。

目的ベース：変えたい体験から逆算する

そこで、判断の順番を意識的に変えました。

どんなユーザーの、どの瞬間の体験を変えたいのかを言葉にする
それが本当に変わりそうかを確かめるための 一番軽い手段は何か を考える
その上で、工数・リソース・スケジュールとすり合わせる

この「一番軽い手段」をつくるところで、AI駆動の開発が効いてきます。

簡易的なフローや画面イメージをAIに出してもらう
ヒアリング用の質問案や説明テキストをAIに書かせる
検証に必要なダミー情報やケースをAIに用意させる

といったことがしやすくなった結果、

まずは軽い形で体験の一部を具現化し、ユーザーに当ててから判断する

という選択肢を取りやすくなりました。

まとめ：プロセスをどう組み替えたか

AI駆動で新規プロダクトをつくる中でやったことを、改めて整理すると次の3つです。

開発手法の変化：「アジャイル型」から「スカルプト型」へ
- 小さなストーリーを積む前に、AIで「全体像の塊」を出してから削る進め方にした
ミッション設計の変化：「分業体制」から「オーバーラップ体制」へ
- PdM・デザイナー・エンジニアそれぞれが、AIを使ってお互いの領域に一歩踏み込むようにした
判断軸の変化：「制約ベース」から「目的ベース」へ
- 工数やリソースより前に、「変えたい体験」から入り、最小の検証手段をAIと一緒につくるようにした

どんなツールを採用するかと同じくらい、
開発の進め方や役割の持ち方をどう変えるか が重要だと感じた経験でした。

少しでも読んだ方の学びになれると幸いです。