要約
- 新規プロダクトの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と一緒につくるようにした
どんなツールを採用するかと同じくらい、
開発の進め方や役割の持ち方をどう変えるか が重要だと感じた経験でした。
少しでも読んだ方の学びになれると幸いです。