AI時代の企画と開発：役割が溶けるチームで価値を最大化させるために

Transcript

1. AI 時代の企画と開発：役割が溶けるチーム で価値を最大化させるために 大西 貴也 2025/12/14 【モバイル】学生エンジニア3 団体合同× ディップLT 会（大阪会場）
2. 目次 はじめに 1 「いい企画」を考えるために 2 「はやく開発」をするために 3 「ずっと改善」し続けるために 4 まとめ 5 2 / 35
3. はじめに
4. 自己紹介 おおにしたかや（@takayaso ） プロダクト企画職として24 新卒で入社 今はバイトルアプリのディレクター 大学院までの24 年間は関西在住でした 学生時代は理学（宇宙の研究）をしてお り、今も非エンジニアです 4 / 35
5. ほなワイ 何喋ったらええかな… ？
6. そういえば… 個人開発はじめてみました ぼく「ユニクロ来たけどサイズ迷う… 」 →持ってる服のサイズや買い替え時期が 分かるデジタルクローゼットアプリ。ユ ニクロ・GU のタグをOCR で読み解析。 バイブコーディングでMVP 完成 アイデアが形にできる時代←面白い！ 6 / 35
7. 会社のプロダクト開発と 考え方・進め方が 「ぜんぜん違う」かも？
8. 今日のLT のゴール 学生の皆さんに持って返ってほしいもの 「いい企画」を考えるために…        個人開発と事業会社の企画の考え方の違いを知ってもらう 1 「はやく開発」をするために…         AI 時代の事業会社の企画と開発の協業を知ってもらう 2 「ずっと改善」し続けるために…          バイトルをグロースさせるアプローチを知ってもらう 3 8 / 35
9. 01 いい企画を考えるために 個人開発と事業会社の企画の考え方の違い
10. 項目 個人開発 事業会社での開発 ターゲット 身の回りの課題 市場・顧客 リソース 自分次第 人件費・納期・予算は有限 ゴール・ミッション 技術習得・自己満足 事業成長・利益創出 なぜ「いい企画」が重要か？ 個人開発と事業会社での開発の違い 10 / 35
11. リソースが有限な中で 成果を上げ続けないといけない だからこそ 「発明家」ではなく「企画者」として 責任を持って「判断」と「決断」をする
12. 要素 意味合い 例 Core 何を目指すか。ビジョンやミッション。 初めてでも迷わず使えるアプリ Why なぜやるか。誰の何の課題を解決するか 新規の60% が3 分で離脱している What 何を作るか。具体的な解決策。 登録直後にチュートリアルを表示 How どうやって作るか。実現方法・手段。 ステップ形式で3 画面を追加 ①考える：Core →Why →What →How 改めておさらい 12 / 35
13. 要素 意味合い 例：新規ユーザー向け改善 ペルソナ 誰のために？ 登録後1 週間の未着手ユーザー ペイン 何に困ってる？ 初期設定が複雑で理解できない 想定リスク 実行に伴う懸念点はある？ 案内が煩雑で、逆に離脱を招く 目標の数値 どのKPI をどのくらい改善 初回継続率を20% →30% に向上 観察指標 成否を見るための補助指標 チュートリアルの完走率、再訪率 想定売上効果 企画の価値を定量的にする 月間売上500 万円増加を想定 ②計画する：企画書を書く 13 / 35
14. ③評価する：想定売上効果を算出する 前提情報 改善目標：初回継続率を20% →30% 新規ユーザー：10000 人/ 月 1 人あたりの平均収益：5000 円/ 月 想定効果を算出 継続率の改善で増えるユーザー： 10000 人 × (30%-20%) = 1000 人/ 月 想定売上効果： 1000 人× 5000 円 = 500 万円/ 月 14 / 35
15. ④実行する：優先順位を付ける 今年2 月のとあるアプリにて プロダクトオーナーとしてロードマップをゼロから作成することに 課題は山積みなので、どこから手を付けても一定の改善は見込そう… 先輩にロードマップのFB をもらってみた 先輩「なんでこの施策からやろうとしたの？」 僕「どの競合もやってるので、僕らも早めにやったほうがいいと思うんです」 15 / 35
16. 「やったほうがいい」ではなく 「やるべき」だからやる
17. 要素 意味合い 「ミス」は存在するのか   判断  これが正解であると見抜くこと 「判断ミス」は存在する   決断  どちらかを自分のリスクで選ぶこと 「決断ミス」は存在しない やるべきことを「判断する」 ・ 「決断する」 「やったほうがいい」 （Nice to have ） くらいならやらないほうがいい 「やるべき」 （Must have ） 順に並べれば、 「やらないこと」 も判断できる ただ、考え抜いても、すべてのものごとを「判断」できるわけではない →企画者は、自分や承認者が最小限のリスクで 「決断」 できるようにする 17 / 35
18. ここまでの話は 企画者だけの話ではありません
19. AI の台頭による変化：役割の境界線が溶ける 企画者にとって 実装のハードルが下がり、プロトタイプ 検証の機会が大幅に増加 →「何が本当に価値があるか」 という 判断に集中できるようになった 開発者にとって コーディングの負荷が減り、企画の領域 （Why/What ） にも踏み込むように →役割の境界線が溶け、 「共通のゴール」 へのコミットが求められるようになった 19 / 35
20. 02 はやく開発をするために AI 時代の事業会社の企画と開発の協業
21. いち早く価値を届けるための開発手法 アジャイルとは 変化に素早く適応しながら、価値を継続 的に届けるための開発手法 「動くもの」が、企画者と開発者が最も 対話すべき共通言語 ディップもアジャイルの手法の一つであ るスクラムが中心 21 / 35
22. 今日話すのはココの部分 22 / 35
23. インセプションデッキ 共通認識を持つための手段 チームメンバー全員で、プロジェクトの ビジョン、スコープ、リスクを定義する プロジェクトのWhy とHow を明確にし、 プロジェクトの土台を作る対話の場 適宜見直すことで生きた共通認識にする 23 / 35
24. インセプションデッキのよくある例 我々はなぜここにいるのか（ひとことでこのプロジェクトの意義を表すなら？） 1 エレベータピッチを作る（知らない人向けに30 秒以内説明するなら？） 2 パッケージデザインを作る（イラストやキャッチコピーで魅力を伝えるなら？） 3 やらないことリストを作る（重要なことにフォーカスするために諦めることは？） 4 「ご近所さん」を探せ（周囲の関係者とその関係性を特定しておくなら？） 5 夜も眠れなくなるような問題はなんだろう？（進捗を妨げるリスクはなに？） 6 などなど 7 24 / 35
25. デリバリーが加速するAI 時代だからこそ 企画者と開発者が目線を揃え 的確な価値提供サイクルを実現する
26. 03 ずっと改善し続けるために バイトルをグロースさせるアプローチ
27. 作ったプロダクトをどう成長させるか？ バイトルは2002 年生まれの老舗プロダクト おそらく皆さんより先輩かもしれない… ？ PC サイト、スマホ対応、アプリ開発と時代に合わせて進化してきた 個人開発・ハッカソンだと0 →1 のフェーズが多いはず 1 →10 （新規機能開発）や10 →100 （グロース）の改善事例を紹介します！ 27 / 35
28. 事例①：1 つのフィードバックから不具合検知 ユーザーフィードバックは宝の山 日々、問い合わせフォームやアプリレビ ューからユーザーの声が届く ある特定の条件下でのみクラッシュ発生 →行動履歴をイベント単位で分析 →早期に原因を特定し修正 28 / 35
29. 事例②：大量のフィードバックから仮説検証 精度の高い仮説検証を高速で回せる トラフィックが多いので、短期間で検証 サイクルを回せる 複数パターンでも、約2 週間ほどで十分 な有意差を検出 →次の施策に繋げられる 29 / 35
30. 事例③：マジックナンバー分析で成功行動を再現 成功ユーザーの無意識の行動を、再現性の高い施策にする 「応募したユーザーの行動」と「応募してないユーザーの行動」の境界線を見つける 例：応募してるユーザーは 「5 件キープ」 「3 日に1 回訪問」 など →未応募ユーザーに対し、その行動をさせるよう行動変容を促す 有名な他社事例 Twitter ： 「登録直後に5 人フォロー」→オンボーディングに強制フォロー機能 Uber ： 「最初の30 日で2 回以上乗車」→2 回分クーポン発行 30 / 35
31. 事例③：マジックナンバー分析で成功行動を再現 身近なところにもマジックナンバーとその施策がが潜んでいるかも？ 31 / 35
32. バイトルをグロースさせるために フィードバックを最大限活かす
33. まとめ
34. まとめ 役割が溶けるチームで価値を最大化するために「3 つ」のこと いい企画を考えるために…                 やるべきことに集中する 1 いい開発をするために…                  目線を揃えて協業する 2 いい改善をし続けるために…               ユーザーフィードバックを活かす 3 34 / 35
35. ありがとうございました