AI駆動開発のその先へ ~仮説検証型アジャイル開発へたちかえる~
-- Views
July 22, 26
スライド概要
https://redjourney.connpass.com/event/398024/
登壇資料です。
本セッションでは、AI駆動開発で実装は速くなったものの、"何を作るべきか"の意思決定が自動的には進まないことを指摘しています。そのため、単に機能を量産するのではなく、価値提供のサイクルを加速させるために「つくる」工程と「まなぶ」工程を同時に回す重要性を説明します。具体的には、顧客課題や期待する行動変化を仮説として設定し、小規模な実験やプロトタイプで検証し、得られたデータから学びを言語化して次の仮説へつなげるプロセスを紹介します。インセプションデッキや仮説キャンバス、ABテストなどのツール例も示し、生成AIがこれらの仮説検証を支援する方法をEQの実例を交えて説明しています。最終的に、価値が本当に届いたかを確認し、事業成果につなげるまでの学習サイクルを回すことが、開発と価値提供のスピードを同時に向上させる鍵であることをまとめています。
おすすめタグ：AI,アジャイル,プロダクト開発,仮説検証,学習サイクル
関連スライド
各ページのテキスト
AI駆動開発のその先へ RED JOURNEY MEETUP ・ 2026. 07.21 〜「つくる速度」の次に「まなぶ速度」をどう高めるか 〜 Motoaki Tanaka @mot0aki
自己紹介 Motoaki Tanaka X: @mot0aki ▸ 株式会社レッドジャーニー ソフトウェアエンジニア アジャイル開発推進 新規プロダクト開発・プロダクトマネジメント 生成AI開発・導入支援 AIカタリスト @mot0aki ・ Red Journey Meetup 2
本日の流れ 1 開発は速くなった — 前回のおさらい 2 けれど「何をつくるべきか」は速くならない 3 「つくる」と「まなぶ」両方を回す 4 「何をつくるか」をどう決めるのか 5 EQでの具体例 — 実物でお見せします 6 まとめ @mot0aki ・ Red Journey Meetup 3
質問・感想をこちらにご記入ください！ EQ: イベント中のQ&A受付サービス (前回、みなさんに使っていただきました) ▶ 質問・感想などを 投稿してみてください! https://eventquestions.aicron.workers.dev/TQI CB1 code: TQICB1 @mot0aki ・ Red Journey Meetup 4
01 開発は速くなった 前回のおさらい ──「AI駆動開発 × アジャイル開発」
前回:開発プロセスはこう変わる 01 要求内容を確認する 02 どのように作るべきかを考える 03 実際にプログラムを書く 04 自動テストを書く 05 想定通り動作していることを確認する 06 成果物をレビューする 07 CI/CD パイプラインで、チェックとリリースが完了する 人/AI 人/AI AI AI AI 人/AI 自動 → 人に残るのは 01・02・06。インプットとアウトプットの確認、責任の引受。 @mot0aki ・ Red Journey Meetup 6
…これで、いいのか？ バックログの消化スピードは、速くなった どんどんバックログが完了になっている なんだったら、次のバックログが枯渇していく じゃあ、次に何をつくる？ @mot0aki ・ Red Journey Meetup 7
02 「何をつくるべきか」は自然には速くならな い
ボトルネックが変わる これまで これから 状態 作りたいものはたくさんあるが、開発が追いつかな 状態 作ることはできる。 作れないことが問題 い。 @mot0aki ・ Red Journey Meetup 何をつくるべきか分からないことが問題 しかし、次に何に着手すべきかが分からない。 9
開発が速くなっても意思決定は自動的に速くならない 次は何をつくればよいのか? どんな機能に価値があるのか? どの顧客課題を優先すべきなのか? 判断するための材料が不足していれば、何度ミーティングを重ねても結論は出ない。 @mot0aki ・ Red Journey Meetup 10
「とにかく速く作り続けること」自体には意味がない バックログが空になりそうだから、新しい要望を追加する あったらなんとなく便利そうだから、思いついた機能を実装する 利用されるかは分からないが、競合にある機能を追加する (極論ですが)利用者にとって意味のない機能、課題を解決しない機能、誰にも使われない機能を大量に作っても、価 値は生まれない。 @mot0aki ・ Red Journey Meetup 11
AIは "良いもの" だけを 速く作れるようにする技術ではない。 良いものも、悪いものも、同じように速く作れるようにする。 @mot0aki ・ Red Journey Meetup 12
03 「つくる」と「まなぶ」 両方を回す 価値提供のサイクルを本当に速くするために
目的は誰かに価値を届けること たくさんの機能を作ることではない @mot0aki ・ Red Journey Meetup 14
開発・リリースした時点で仕事が終わるわけではない 1. 狙っていた価値が、本当に相手に届いたのか 2. 期待していた行動変化が、起きたのか 3. その結果、事業上の成果にどうつながったのか そこまで確かめて、初めて「価値を届けた」と言える。 @mot0aki ・ Red Journey Meetup 15
「価値があるものを作ればよい」── 言うは易し、行うは難し 十分に分析してから作ったのに、実際に提供すると使われないことがある 反対に、想定していなかった使い方や価値が見つかることもある 事前の予測精度を高めることより、 実際の反応から学ぶ能力が重要になる。 @mot0aki ・ Red Journey Meetup 16
今日の中心メッセージ 「つくる」と「まなぶ」 両方のサイクルを回してはじめて 価値提供は速くなる @mot0aki ・ Red Journey Meetup 17
04 「何をつくるか」を、どう決めるのか 仮説を立て、小さく試し、結果から学ぶ、仮説検証のサイクル
仮説検証のサイクル 顧客・課題についての仮説 小さな実験・提供 反応・データを観察 仮説を評価し、学びを言語化 ▼ ▼ ▼ ▼ 再び、次の仮説へ プロダクト開発とは、機能や価値を積み上げる活動であると同時に、不確実性を減らしていく学習活動でもある。 @mot0aki ・ Red Journey Meetup 19
① 仮説を立てる 顧客やユーザーについての見立てを置く。 この顧客は、このような課題を持っているのではないか この課題は、本人にとって十分に重要なのではないか この機能や提供方法であれば、課題を解決できるのではないか 課題が解決されれば、このような行動変化が起きるのではないか その行動変化が、事業上の成果につながるのではないか 「この機能を作りたい」ではなく、誰に、どのような変化を起こしたいのかまで言語化する。 @mot0aki ・ Red Journey Meetup 20
② 検証のために行動する ユーザーに 話を聞く プロトタイプを 見せる 小規模な対象に だけ提供する 手作業で サービスを試す LPで 反応を見る 最小限の機能だけ 実装する 目的は「機能を完成させること」ではなく、仮説を確かめるための情報を得ること。 必ずしも完成した機能としてすべて実装する必要はない。 @mot0aki ・ Red Journey Meetup 21
③ 結果を見て、次の仮説につなげる 単にリリースできたかではなく、仮説に対してどのような結果が得られ たかを見る。 うまくいった場合 うまくいかなかった場合 ・なぜ価値が生まれたのか ・どの顧客に特に効果があったのか ・さらに価値を高めるには何が必要か ・別の場面や顧客にも展開できるか ・顧客課題の理解が間違っていたのか ・課題はあったが重要度が低かったのか ・解決策が適切でなかったのか ・対象とした顧客が違っていたのか ・価値はあったが、測り方が悪かったのか 検証結果は、成功か失敗かを判定して終わるものではない。 @mot0aki ・ Red Journey Meetup 22
失敗した機能を作ったこと自体が 問題なのではない。 問題はActionから学ばずに、同じ前提のまま作り続けること @mot0aki ・ Red Journey Meetup 23
何をつくるのか、仮説検証のための道具 具体的なHow To @mot0aki ・ Red Journey Meetup 24
仮説検証の道具例 インセプションデッキ 仮説キャンバス 検証キャンバス インタビュー / プロト / ABテスト… インタビュー分析 / KA法・KJ法… バックログ追加 → 機能開発へ ※詳細は後述します。 @mot0aki ・ Red Journey Meetup なぜ作るのか ▼ ▼ ▼ ▼ 誰の何を解くのか どう確かめるのか 実際の検証活動 検証結果の分析 → 学びの言語化 ▼ 25
これらを地道に進めていく …これがこれまでのやり方でした @mot0aki ・ Red Journey Meetup 26
これらがまた 生成AIで変わってきつつある。 @mot0aki ・ Red Journey Meetup 27
05 「何をつくるのか」仮説検証を 実際にEQでやってみる 仮説検証の道具の実践例をお見せします
前回、EQに「いいね機能」を足しました …で、次に何をつくればいいのか？ この状態から、仮説検証の道具をAIと一緒に使ってみます。 @mot0aki ・ Red Journey Meetup 29
インセプションデッキ インセプションデッキ 仮説キャンバス 検証キャンバス インタビュー / プロト / ABテスト… インタビュー分析 / KA法・KJ法… バックログ追加 → 機能開発へ @mot0aki ・ Red Journey Meetup なぜ作るのか ▼ ▼ ▼ ▼ 誰の何を解くのか どう確かめるのか 実際の検証活動 検証結果の分析 → 学びの言語化 ▼ 30
インセプションデッキとは 作り始める前に、「なぜ作るのか」をチーム全員で言語化する道具。 「われわれはなぜここにいるのか」「エレベーターピッチ」など、10の質問に答えていく 資料を作ること自体が目的ではなく、答える過程でプロジェクト・プロダクトへの認識のズレを あぶり出すことに価値がある 出典: Jonathan Rasmusson 著、西村直人・角谷信太郎 監訳『アジャイルサムライ――達人開発者への道』オーム 社、2011年（原著 The Agile Samurai, Pragmatic Bookshelf, 2010）。原案は ThoughtWorks 社の Robin Gibson。 @mot0aki ・ Red Journey Meetup 31
インセプションデッキ: われわれはなぜここにいるのか イベントで「質問ある人？」と聞いても、手は挙がらない。 でも、聞きたいことが無いわけではない。 こんな初歩的なことを聞いていいのか 場の空気を止めたくない / 目立ちたくない 質問を考えているうちに、次の話題に行ってしまった 一方、登壇者は聴衆が何に引っかかっているのか分からないまま話し続ける。 → この断絶をなくすために、EQはここにいる。 @mot0aki ・ Red Journey Meetup 32
※潜在的なねらいとして、AI駆動開発によって変わるはずの開発のあり方について、それが実 際にどのように変わるのかを、EQを題材にして実際に体験してもらうこともある。 @mot0aki ・ Red Journey Meetup 33
インセプションデッキ:エレベーターピッチ [聞きたいことがあるのに、手を挙げられない参加者] 向けの、 [EQ] というプロダクトは、[イベント中のQ&A受付サービス] です。 これは [匿名で質問を投げられ、良い質問に投票が集まると上位に浮かび上がる] ことができ、 [Sli.doなどの競合サービス] とは違って、 [アカウント登録もインストールも不要。6桁のコードだけで速攻で利用できる] が備わっている。 →AIに「プロダクトの概要」を渡して、たたき台を起こしてもらう。 埋まらない箇所が、考えられていない箇所。AIとの壁打ちで充実化させることも可能。 @mot0aki ・ Red Journey Meetup 34
仮説キャンバス インセプションデッキ 仮説キャンバス 検証キャンバス インタビュー / プロト / ABテスト… インタビュー分析 / KA法・KJ法… バックログ追加 → 機能開発へ @mot0aki ・ Red Journey Meetup なぜ作るのか ▼ ▼ ▼ ▼ 誰の何を解くのか どう確かめるのか 実際の検証活動 検証結果の分析 → 学びの言語化 ▼ 35
仮説キャンバスとは 誰の、どんな課題を、なぜ自分たちが解くのか ── 事業の仮説を1枚 に構造化する道具。 目的・ビジョンから課題・提案価値・評価指標まで、14の項目で仮説を言語化する。 顧客が気づいている顕在課題と、気づいていない・諦めている潜在課題を分けて見立てる。 課題に対する不満や、解消のための価値や施策を整理・構造化できる。 出典: 市谷聡啓『正しいものを正しくつくる ― プロダクトをつくるとはどういうことなのか、あるいはアジャイルのそ の先について』ビー・エヌ・エヌ新社 2019年 @mot0aki ・ Red Journey Meetup 36
EQ の仮説キャンバス（AIとの壁打ちで作成） 目的 ビジョン ▪「聞かれないまま終わる」をなくす ▪「聞き手」を「参加者」に変える 優位性 ▪登録・インスト ール不要・無 料 ▪主催者が自分 で立てられる 実現手段 ▪匿名投稿・投 票・票順表示 のWebアプリ ▪6桁コード / QRで即参加 ▪良い質問が上 位に浮かぶ ▪質問のハードルを限りなくゼロに ▪匿名で安心して問いを出せる場 ▪「参加している」というワクワク 提案価値 ▪参加者: 挙手 せず聞ける ▪登壇者: 引っ かかりが見え る ▪主催者: 沈黙 で終わらない ▪生成AIとの協 働体験 不満不足 ▪Sli.doは登 録・準備が要 る ▪挙手は目立つ ので使われな い ▪Formsは即時 性・一体感が ない 評価指標 チャネル ビジネスモデル 市場規模 ▪投稿質問数 / 投票数 ▪取り上げられた割合 ▪主催者のリピート率 ▪現状なし（個人開発） ▪要検証: 主催者向け有料プラン 代替手段 ▪Sli.do / Google Forms ▪チャット欄 / X タグ / 挙手 ▪何もしない （最大の競合） 顕在課題 ▪「質問ありますか？」で沈黙 ▪Q&Aが余る・盛り上がらない ▪登壇者は引っかかり所が見えない 潜在課題 ▪目立ちたくない・的外れが怖い ▪考えがまとまる前に次の話題へ ▪＝「無い」のでなく「出せない」 状況 ▪聞きたいのに手を挙げられない参 加者 ▪オンライン・ハイブリッドが常態化 ▪カメラオフ・ミュート既定で発話コス ト高 ▪登壇者が自分のイベントで使う → 参加者が体験する → 自分のイベントでも使う（登壇者経由の伝播） ▪未検討 / 要検証 ＝ AIの壁打ちで増えた検証仮説（次のスライド） @mot0aki ・ Red Journey Meetup 37
壁打ちのツッコミで、仮説が5つ増えた 仮説 ① 仮説 ② 仮説 ③ 質問が出るようになると、今度は限られた時間 で捌ききれない。「回答済み」1タップで済みを 畳み、未回答の上位を浮かせる。指標は消化 率。 質問文だけでは「どの話への問いか」が分から ない。投稿時に“今の話題”を紐付けて、登壇者 の理解速度を上げる。 匿名・登録不要という優位性が、そのまま荒ら しリスクの源。非表示・ピン留めの主催者権限 で、“出た後”の場だけ整える。 「出ない」の次は「捌けない」 質問に文脈がない 軽さと荒らしは表裏一体 仮説 ④ 仮説 ⑤ 溜まった質問はイベントと共に消える。要約＋ エクスポートで再利用できる資産に。有料プラ ン仮説の前提条件。 空のタイムラインでは誰も“最初の一人”になり たくない。種質問・呼び水で最初の1票を作る。 指標は最初の1問までの時間。 Q&Aが揮発する 最初の1問が出ない 観点の深堀り/一貫性の確認/壁打ちが、簡単にできるようになった。 @mot0aki ・ Red Journey Meetup 38
検証キャンバス インセプションデッキ 仮説キャンバス 検証キャンバス インタビュー / プロト / ABテスト… インタビュー分析 / KA法・KJ法… バックログ追加 → 機能開発へ @mot0aki ・ Red Journey Meetup なぜ作るのか ▼ ▼ ▼ ▼ 誰の何を解くのか どう確かめるのか 実際の検証活動 検証結果の分析 → 学びの言語化 ▼ 39
検証キャンバス:今回のイベントで確かめる仮説 仮説④ 溜まった質問はイベントと共に消える。要約＋エクスポートで再利用できる資産に。 溜まったQ&Aはイベントと共に消えて終わるのではなく、 要約して持ち帰れるなら、あとから再利用される資産になる。 @mot0aki ・ Red Journey Meetup 40
どうやって確かめるか？ ―――確かめる場は、今日この場にある。 @mot0aki ・ Red Journey Meetup 41
EQ の検証キャンバス（仮説④の検証計画） 検証の目的 学びを残せる体験の価値検証 検証したい仮説 溜まったQ&Aは、要約して持ち帰れるならあとから再利用される資産になる（仮説④） 指標・事前期待 アンケート自由記述に「あとで見返したい・チームに共有したい」の声が出る → 仮説は支持 「その場で完結、見返さない」が大半 → Q&Aは資産ではなく消耗品。 検証方法・MVP MVPは実装済みの要約＋エクスポート機能そのもの。実際に使ってもらい、イベント終了後のアンケート（自由記述を1問追加）で反応をもらう 検証環境・時期 今日、この場 ── 本イベントの参加者のみなさん。回答が届くのはイベント終了後 結果・学び 検証後に結果（事実）→ わかったこと → ネクストアクションをここへ書き足す（→ 次のスライド） 検証キャンバスは Why（何のために）→ How（どうやって）→ What（何がわかったか）の3段で書き、What は検証 後に埋める。検証計画に沿った線表・バックログ・タスクの整理も、AIと一緒にできる。 @mot0aki ・ Red Journey Meetup 42
検証と、インサイト分析 ※アンケートの回答が届くのはイベント後なのでサンプル ポジ ── 仮説を支持する反応 「Q&Aを持ち帰って社内で共有したい」 「自分が聞かなかった質問こそ、あとで読み返したい」 「次のイベント企画のネタ帳になる」（主催者） ネガ ── 仮説を崩す反応 「その場で解決したので、見返すことはない」 「要約よりも、結局スライド資料のほうを見る」 「エクスポートしたこと自体を忘れそう」 ユーザーの反応から得た学びやインサイトを、バックログ へ落とし込んでいく。 ── この発散も、AIと一緒にできる。 @mot0aki ・ Red Journey Meetup 43
そして、機能開発へ インセプションデッキ 仮説キャンバス 検証キャンバス インタビュー / プロト / ABテスト… インタビュー分析 / KA法・KJ法… バックログ（＝開発要件） 機能開発へ ── ここから先が、前回の話 @mot0aki ・ Red Journey Meetup ▼ ▼ ▼ ▼ ▼ ▼ 44
※ ただし 最終的に狙いに沿った仮説・成果物になっているかどうかは 必ず確認してください。 AIが出した下書きは、もっともらしく見える。 もっともらしさは、正しさではない。自分の意志と責任を反映させよう。 @mot0aki ・ Red Journey Meetup 45
これからの、仮説検証プロセス 01 インセプションデッキのたたき台を起こす 02 プロダクトの狙いを肉付けする 03 仮説キャンバスの観点を深堀り・ツッコミを入れる 04 誰の何を解くのかを、決める 05 検証計画・線表・インタビュー台本を整理する 06 実際に、顧客に会って確かめる 07 インサイト分析を手伝う 08 学びを言語化し、次に何をつくるかを決める AI 人/AI AI 人/AI AI 人 AI 人/AI 前回と同じ構図。人に残るのは インプットとアウトプットの確認/引き受け、そして 現実に触れること/人に会うこと。 @mot0aki ・ Red Journey Meetup 46
06 まとめ
前回、この円を描きました 仮説を立て、つくり、まなび、また次の仮説へ。 @mot0aki ・ Red Journey Meetup 48
この円に、時間軸を足すと 同じところを回っているのではない。回るたびにより高く、より良い方向へ。 @mot0aki ・ Red Journey Meetup 49
「つくる」の開発サイクルをAI駆動開発が速めていくように、 「なにをつくるか」の仮説検証サイクルも 生成AIを使って カイテン を速めていく。 @mot0aki ・ Red Journey Meetup 50
この カイテン の連続の螺旋構造を作り出すことで、 より良い 価値 / 仕事 / 世界 へ つなげていくことができるはずです。 長く長く続く、カイテンの旅(=ジャーニー)へ @mot0aki ・ Red Journey Meetup 51
まとめ AIでつくる速度は上がった。だが、「何をつくるべきか」はそのままでは速くならない。 「つくる」と「まなぶ」の両輪を回してはじめて、価値提供のサイクルは速くなる。 価値は事前に完全予測できない。だから仮説を立て、小さく試し、結果から学ぶ。 そのための道具（インセプションデッキ / 仮説キャンバス / 検証キャンバス）も、生成AIでカイテン を上げられる。 ただし、現実・人に触れることとねらいと責任の引き受けは、人に残る。 @mot0aki ・ Red Journey Meetup 52
Q&A・ディスカッション たとえば、、、 B2B・社内システムでも検証を回せる？ まずはどこから始める？ AIが出す仮説、信じていいの？ 生成AIがなくても、検証は回せる？ 生成AIで、検証の質は上がる？ @mot0aki ・ Red Journey Meetup 53
参加後アンケートにご協力ください 今日の内容はいかがでしたか？ みなさんの声が、この勉強会の次の仮説になります。 ▶ 1〜2分で終わります。率直な感想をぜ ひ! https://forms.gle/Yw3W9aamdgqs PSry7 右の QR からどうぞ。 @mot0aki ・ Red Journey Meetup 54
ありがとうございました THANK YOU Motoaki Tanaka @mot0aki