---
title: AI駆動開発のその先へ ~仮説検証型アジャイル開発へたちかえる~
tags: 
author: [もっくま](https://image.docswell.com/user/mot0aki)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L71Y2LXVJG.jpg?width=480
description: https://redjourney.connpass.com/event/398024/ 登壇資料です。   本セッションでは、AI駆動開発で実装は速くなったものの、"何を作るべきか"の意思決定が自動的には進まないことを指摘しています。そのため、単に機能を量産するのではなく、価値提供のサイクルを加速させるために「つくる」工程と「まなぶ」工程を同時に回す重要性を説明します。具体的には、顧客課題や期待する行動変化を仮説として設定し、小規模な実験やプロトタイプで検証し、得られたデータから学びを言語化して次の仮説へつなげるプロセスを紹介します。インセプションデッキや仮説キャンバス、ABテストなどのツール例も示し、生成AIがこれらの仮説検証を支援する方法をEQの実例を交えて説明しています。最終的に、価値が本当に届いたかを確認し、事業成果につなげるまでの学習サイクルを回すことが、開発と価値提供のスピードを同時に向上させる鍵であることをまとめています。  おすすめタグ：AI,アジャイル,プロダクト開発,仮説検証,学習サイクル
published: July 22, 26
canonical: https://image.docswell.com/s/mot0aki/57N1VD-2026-07-22-214303
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L71Y2LXVJG.jpg)

AI駆動開発のその先へ
RED JOURNEY MEETUP ・ 2026. 07.21
〜「つくる速度」の次に「まなぶ速度」をどう高めるか 〜
Motoaki Tanaka @mot0aki


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G7WGRVN3E2.jpg)

自己紹介
Motoaki Tanaka X: @mot0aki
▸ 株式会社レッドジャーニー
ソフトウェアエンジニア
アジャイル開発推進
新規プロダクト開発・プロダクトマネジメント
生成AI開発・導入支援
AIカタリスト
@mot0aki ・ Red Journey Meetup
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JZLR43GE3.jpg)

本日の流れ
1 開発は速くなった — 前回のおさらい
2 けれど「何をつくるべきか」は速くならない
3 「つくる」と「まなぶ」両方を回す
4 「何をつくるか」をどう決めるのか
5 EQでの具体例 — 実物でお見せします
6 まとめ
@mot0aki ・ Red Journey Meetup
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE6WR3XQEV.jpg)

質問・感想をこちらにご記入ください！
EQ: イベント中のQ&A受付サービス
(前回、みなさんに使っていただきました)
▶ 質問・感想などを
投稿してみてください!
https://eventquestions.aicron.workers.dev/TQI
CB1
code: TQICB1
@mot0aki ・ Red Journey Meetup
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE5M8LX2E4.jpg)

01
開発は速くなった
前回のおさらい ──「AI駆動開発 × アジャイル開発」


# Page. 6

![Page Image](https://bcdn.docswell.com/page/9729KLX1JR.jpg)

前回:開発プロセスはこう変わる
01 要求内容を確認する
02 どのように作るべきかを考える
03 実際にプログラムを書く
04 自動テストを書く
05 想定通り動作していることを確認する
06 成果物をレビューする
07 CI/CD パイプラインで、チェックとリリースが完了する
人/AI
人/AI
AI
AI
AI
人/AI
自動
→ 人に残るのは 01・02・06。インプットとアウトプットの確認、責任の引受。
@mot0aki ・ Red Journey Meetup
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/DJY4NQ847M.jpg)

…これで、いいのか？
バックログの消化スピードは、速くなった
どんどんバックログが完了になっている
なんだったら、次のバックログが枯渇していく
じゃあ、次に何をつくる？
@mot0aki ・ Red Journey Meetup
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V7NYXKQ6E8.jpg)

02
「何をつくるべきか」は自然には速くならな
い


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YJ9P8VDR73.jpg)

ボトルネックが変わる
これまで
これから
状態 作りたいものはたくさんあるが、開発が追いつかな
状態 作ることはできる。
作れないことが問題
い。
@mot0aki ・ Red Journey Meetup
何をつくるべきか分からないことが問題
しかし、次に何に着手すべきかが分からない。
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJ8D8P3GJD.jpg)

開発が速くなっても意思決定は自動的に速くならない
次は何をつくればよいのか?
どんな機能に価値があるのか?
どの顧客課題を優先すべきなのか?
判断するための材料が不足していれば、何度ミーティングを重ねても結論は出ない。
@mot0aki ・ Red Journey Meetup
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LJLMR1VXER.jpg)

「とにかく速く作り続けること」自体には意味がない
バックログが空になりそうだから、新しい要望を追加する
あったらなんとなく便利そうだから、思いついた機能を実装する
利用されるかは分からないが、競合にある機能を追加する
(極論ですが)利用者にとって意味のない機能、課題を解決しない機能、誰にも使われない機能を大量に作っても、価
値は生まれない。
@mot0aki ・ Red Journey Meetup
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/47MYRWG37W.jpg)

AIは "良いもの" だけを
速く作れるようにする技術ではない。
良いものも、悪いものも、同じように速く作れるようにする。
@mot0aki ・ Red Journey Meetup
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/P7R9RYZRE9.jpg)

03
「つくる」と「まなぶ」
両方を回す
価値提供のサイクルを本当に速くするために


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PJXQRG9Y7X.jpg)

目的は誰かに価値を届けること
たくさんの機能を作ることではない
@mot0aki ・ Red Journey Meetup
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/3JK9R4P4JD.jpg)

開発・リリースした時点で仕事が終わるわけではない
1. 狙っていた価値が、本当に相手に届いたのか
2. 期待していた行動変化が、起きたのか
3. その結果、事業上の成果にどうつながったのか
そこまで確かめて、初めて「価値を届けた」と言える。
@mot0aki ・ Red Journey Meetup
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LE3W8LXDE5.jpg)

「価値があるものを作ればよい」── 言うは易し、行うは難し
十分に分析してから作ったのに、実際に提供すると使われないことがある
反対に、想定していなかった使い方や価値が見つかることもある
事前の予測精度を高めることより、
実際の反応から学ぶ能力が重要になる。
@mot0aki ・ Red Journey Meetup
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/8EDKMN227G.jpg)

今日の中心メッセージ
「つくる」と「まなぶ」
両方のサイクルを回してはじめて
価値提供は速くなる
@mot0aki ・ Red Journey Meetup
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/V7PKR51LJ8.jpg)

04
「何をつくるか」を、どう決めるのか
仮説を立て、小さく試し、結果から学ぶ、仮説検証のサイクル


# Page. 19

![Page Image](https://bcdn.docswell.com/page/2JVVRPY6JQ.jpg)

仮説検証のサイクル
顧客・課題についての仮説
小さな実験・提供
反応・データを観察
仮説を評価し、学びを言語化
▼
▼
▼
▼ 再び、次の仮説へ
プロダクト開発とは、機能や価値を積み上げる活動であると同時に、不確実性を減らしていく学習活動でもある。
@mot0aki ・ Red Journey Meetup
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/5EGLMP92JL.jpg)

① 仮説を立てる
顧客やユーザーについての見立てを置く。
この顧客は、このような課題を持っているのではないか
この課題は、本人にとって十分に重要なのではないか
この機能や提供方法であれば、課題を解決できるのではないか
課題が解決されれば、このような行動変化が起きるのではないか
その行動変化が、事業上の成果につながるのではないか
「この機能を作りたい」ではなく、誰に、どのような変化を起こしたいのかまで言語化する。
@mot0aki ・ Red Journey Meetup
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/4JQYR2W97P.jpg)

② 検証のために行動する
ユーザーに
話を聞く
プロトタイプを
見せる
小規模な対象に
だけ提供する
手作業で
サービスを試す
LPで
反応を見る
最小限の機能だけ
実装する
目的は「機能を完成させること」ではなく、仮説を確かめるための情報を得ること。
必ずしも完成した機能としてすべて実装する必要はない。
@mot0aki ・ Red Journey Meetup
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/K74W8L1RE1.jpg)

③ 結果を見て、次の仮説につなげる
単にリリースできたかではなく、仮説に対してどのような結果が得られ
たかを見る。
うまくいった場合
うまくいかなかった場合
・なぜ価値が生まれたのか
・どの顧客に特に効果があったのか
・さらに価値を高めるには何が必要か
・別の場面や顧客にも展開できるか
・顧客課題の理解が間違っていたのか
・課題はあったが重要度が低かったのか
・解決策が適切でなかったのか
・対象とした顧客が違っていたのか
・価値はあったが、測り方が悪かったのか
検証結果は、成功か失敗かを判定して終わるものではない。
@mot0aki ・ Red Journey Meetup
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LJ1Y2LGVEG.jpg)

失敗した機能を作ったこと自体が
問題なのではない。
問題はActionから学ばずに、同じ前提のまま作り続けること
@mot0aki ・ Red Journey Meetup
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GJWGRVK372.jpg)

何をつくるのか、仮説検証のための道具
具体的なHow To
@mot0aki ・ Red Journey Meetup
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/4EZLR4ZG73.jpg)

仮説検証の道具例
インセプションデッキ
仮説キャンバス
検証キャンバス
インタビュー / プロト / ABテスト…
インタビュー分析 / KA法・KJ法…
バックログ追加 → 機能開発へ
※詳細は後述します。
@mot0aki ・ Red Journey Meetup
なぜ作るのか
▼
▼
▼
▼
誰の何を解くのか
どう確かめるのか
実際の検証活動
検証結果の分析 → 学びの言語化
▼
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/Y76WR3ZQ7V.jpg)

これらを地道に進めていく
…これがこれまでのやり方でした
@mot0aki ・ Red Journey Meetup
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/G75M8LW274.jpg)

これらがまた
生成AIで変わってきつつある。
@mot0aki ・ Red Journey Meetup
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/9J29KLQ1ER.jpg)

05
「何をつくるのか」仮説検証を
実際にEQでやってみる
仮説検証の道具の実践例をお見せします


# Page. 29

![Page Image](https://bcdn.docswell.com/page/DEY4NQW4JM.jpg)

前回、EQに「いいね機能」を足しました
…で、次に何をつくればいいのか？
この状態から、仮説検証の道具をAIと一緒に使ってみます。
@mot0aki ・ Red Journey Meetup
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VJNYXK9678.jpg)

インセプションデッキ
インセプションデッキ
仮説キャンバス
検証キャンバス
インタビュー / プロト / ABテスト…
インタビュー分析 / KA法・KJ法…
バックログ追加 → 機能開発へ
@mot0aki ・ Red Journey Meetup
なぜ作るのか
▼
▼
▼
▼
誰の何を解くのか
どう確かめるのか
実際の検証活動
検証結果の分析 → 学びの言語化
▼
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/YE9P8V2RJ3.jpg)

インセプションデッキとは
作り始める前に、「なぜ作るのか」をチーム全員で言語化する道具。
「われわれはなぜここにいるのか」「エレベーターピッチ」など、10の質問に答えていく
資料を作ること自体が目的ではなく、答える過程でプロジェクト・プロダクトへの認識のズレを
あぶり出すことに価値がある
出典: Jonathan Rasmusson 著、西村直人・角谷信太郎 監訳『アジャイルサムライ――達人開発者への道』オーム
社、2011年（原著 The Agile Samurai, Pragmatic Bookshelf, 2010）。原案は ThoughtWorks 社の Robin
Gibson。
@mot0aki ・ Red Journey Meetup
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/GE8D8P5GED.jpg)

インセプションデッキ: われわれはなぜここにいるのか
イベントで「質問ある人？」と聞いても、手は挙がらない。
でも、聞きたいことが無いわけではない。
こんな初歩的なことを聞いていいのか
場の空気を止めたくない / 目立ちたくない
質問を考えているうちに、次の話題に行ってしまった
一方、登壇者は聴衆が何に引っかかっているのか分からないまま話し続ける。
→ この断絶をなくすために、EQはここにいる。
@mot0aki ・ Red Journey Meetup
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/LELMR1YX7R.jpg)

※潜在的なねらいとして、AI駆動開発によって変わるはずの開発のあり方について、それが実
際にどのように変わるのかを、EQを題材にして実際に体験してもらうこともある。
@mot0aki ・ Red Journey Meetup
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/4JMYRWN3JW.jpg)

インセプションデッキ:エレベーターピッチ
[聞きたいことがあるのに、手を挙げられない参加者] 向けの、
[EQ] というプロダクトは、[イベント中のQ&A受付サービス] です。
これは [匿名で質問を投げられ、良い質問に投票が集まると上位に浮かび上がる] ことができ、
[Sli.doなどの競合サービス] とは違って、
[アカウント登録もインストールも不要。6桁のコードだけで速攻で利用できる]
が備わっている。
→AIに「プロダクトの概要」を渡して、たたき台を起こしてもらう。
埋まらない箇所が、考えられていない箇所。AIとの壁打ちで充実化させることも可能。
@mot0aki ・ Red Journey Meetup
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/PJR9RYDR79.jpg)

仮説キャンバス
インセプションデッキ
仮説キャンバス
検証キャンバス
インタビュー / プロト / ABテスト…
インタビュー分析 / KA法・KJ法…
バックログ追加 → 機能開発へ
@mot0aki ・ Red Journey Meetup
なぜ作るのか
▼
▼
▼
▼
誰の何を解くのか
どう確かめるのか
実際の検証活動
検証結果の分析 → 学びの言語化
▼
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/PEXQRG1YJX.jpg)

仮説キャンバスとは
誰の、どんな課題を、なぜ自分たちが解くのか ── 事業の仮説を1枚
に構造化する道具。
目的・ビジョンから課題・提案価値・評価指標まで、14の項目で仮説を言語化する。
顧客が気づいている顕在課題と、気づいていない・諦めている潜在課題を分けて見立てる。
課題に対する不満や、解消のための価値や施策を整理・構造化できる。
出典: 市谷聡啓『正しいものを正しくつくる ― プロダクトをつくるとはどういうことなのか、あるいはアジャイルのそ
の先について』ビー・エヌ・エヌ新社 2019年
@mot0aki ・ Red Journey Meetup
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/3EK9R424ED.jpg)

EQ の仮説キャンバス（AIとの壁打ちで作成）
目的
ビジョン
▪「聞かれないまま終わる」をなくす
▪「聞き手」を「参加者」に変える
優位性
▪登録・インスト
ール不要・無
料
▪主催者が自分
で立てられる
実現手段
▪匿名投稿・投
票・票順表示
のWebアプリ
▪6桁コード /
QRで即参加
▪良い質問が上
位に浮かぶ
▪質問のハードルを限りなくゼロに ▪匿名で安心して問いを出せる場 ▪「参加している」というワクワク
提案価値
▪参加者: 挙手
せず聞ける
▪登壇者: 引っ
かかりが見え
る
▪主催者: 沈黙
で終わらない
▪生成AIとの協
働体験
不満不足
▪Sli.doは登
録・準備が要
る
▪挙手は目立つ
ので使われな
い
▪Formsは即時
性・一体感が
ない
評価指標
チャネル
ビジネスモデル
市場規模
▪投稿質問数 / 投票数 ▪取り上げられた割合
▪主催者のリピート率
▪現状なし（個人開発） ▪要検証: 主催者向け有料プラン
代替手段
▪Sli.do /
Google
Forms
▪チャット欄 / X
タグ / 挙手
▪何もしない
（最大の競合）
顕在課題
▪「質問ありますか？」で沈黙
▪Q&Aが余る・盛り上がらない
▪登壇者は引っかかり所が見えない
潜在課題
▪目立ちたくない・的外れが怖い
▪考えがまとまる前に次の話題へ
▪＝「無い」のでなく「出せない」
状況
▪聞きたいのに手を挙げられない参
加者
▪オンライン・ハイブリッドが常態化
▪カメラオフ・ミュート既定で発話コス
ト高
▪登壇者が自分のイベントで使う → 参加者が体験する → 自分のイベントでも使う（登壇者経由の伝播）
▪未検討 / 要検証
＝ AIの壁打ちで増えた検証仮説（次のスライド）
@mot0aki ・ Red Journey Meetup
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/L73W8L4D75.jpg)

壁打ちのツッコミで、仮説が5つ増えた
仮説 ①
仮説 ②
仮説 ③
質問が出るようになると、今度は限られた時間
で捌ききれない。「回答済み」1タップで済みを
畳み、未回答の上位を浮かせる。指標は消化
率。
質問文だけでは「どの話への問いか」が分から
ない。投稿時に“今の話題”を紐付けて、登壇者
の理解速度を上げる。
匿名・登録不要という優位性が、そのまま荒ら
しリスクの源。非表示・ピン留めの主催者権限
で、“出た後”の場だけ整える。
「出ない」の次は「捌けない」
質問に文脈がない
軽さと荒らしは表裏一体
仮説 ④
仮説 ⑤
溜まった質問はイベントと共に消える。要約＋
エクスポートで再利用できる資産に。有料プラ
ン仮説の前提条件。
空のタイムラインでは誰も“最初の一人”になり
たくない。種質問・呼び水で最初の1票を作る。
指標は最初の1問までの時間。
Q&Aが揮発する
最初の1問が出ない
観点の深堀り/一貫性の確認/壁打ちが、簡単にできるようになった。
@mot0aki ・ Red Journey Meetup
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/87DKMNQ2JG.jpg)

検証キャンバス
インセプションデッキ
仮説キャンバス
検証キャンバス
インタビュー / プロト / ABテスト…
インタビュー分析 / KA法・KJ法…
バックログ追加 → 機能開発へ
@mot0aki ・ Red Journey Meetup
なぜ作るのか
▼
▼
▼
▼
誰の何を解くのか
どう確かめるのか
実際の検証活動
検証結果の分析 → 学びの言語化
▼
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/VJPKR5LLE8.jpg)

検証キャンバス:今回のイベントで確かめる仮説
仮説④ 溜まった質問はイベントと共に消える。要約＋エクスポートで再利用できる資産に。
溜まったQ&Aはイベントと共に消えて終わるのではなく、
要約して持ち帰れるなら、あとから再利用される資産になる。
@mot0aki ・ Red Journey Meetup
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/2EVVRPQ6EQ.jpg)

どうやって確かめるか？
―――確かめる場は、今日この場にある。
@mot0aki ・ Red Journey Meetup
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/57GLMPW2EL.jpg)

EQ の検証キャンバス（仮説④の検証計画）
検証の目的
学びを残せる体験の価値検証
検証したい仮説 溜まったQ&Aは、要約して持ち帰れるならあとから再利用される資産になる（仮説④）
指標・事前期待 アンケート自由記述に「あとで見返したい・チームに共有したい」の声が出る → 仮説は支持
「その場で完結、見返さない」が大半 → Q&Aは資産ではなく消耗品。
検証方法・MVP MVPは実装済みの要約＋エクスポート機能そのもの。実際に使ってもらい、イベント終了後のアンケート（自由記述を1問追加）で反応をもらう
検証環境・時期 今日、この場 ── 本イベントの参加者のみなさん。回答が届くのはイベント終了後
結果・学び
検証後に結果（事実）→ わかったこと → ネクストアクションをここへ書き足す（→ 次のスライド）
検証キャンバスは Why（何のために）→ How（どうやって）→ What（何がわかったか）の3段で書き、What は検証
後に埋める。検証計画に沿った線表・バックログ・タスクの整理も、AIと一緒にできる。
@mot0aki ・ Red Journey Meetup
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/4EQYR239JP.jpg)

検証と、インサイト分析
※アンケートの回答が届くのはイベント後なのでサンプル
ポジ ── 仮説を支持する反応
「Q&Aを持ち帰って社内で共有したい」
「自分が聞かなかった質問こそ、あとで読み返したい」
「次のイベント企画のネタ帳になる」（主催者）
ネガ ── 仮説を崩す反応
「その場で解決したので、見返すことはない」
「要約よりも、結局スライド資料のほうを見る」
「エクスポートしたこと自体を忘れそう」
ユーザーの反応から得た学びやインサイトを、バックログ へ落とし込んでいく。
── この発散も、AIと一緒にできる。
@mot0aki ・ Red Journey Meetup
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/KJ4W8LNR71.jpg)

そして、機能開発へ
インセプションデッキ
仮説キャンバス
検証キャンバス
インタビュー / プロト / ABテスト…
インタビュー分析 / KA法・KJ法…
バックログ（＝開発要件）
機能開発へ ── ここから先が、前回の話
@mot0aki ・ Red Journey Meetup
▼
▼
▼
▼
▼
▼
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/LE1Y2L5V7G.jpg)

※ ただし
最終的に狙いに沿った仮説・成果物になっているかどうかは
必ず確認してください。
AIが出した下書きは、もっともらしく見える。
もっともらしさは、正しさではない。自分の意志と責任を反映させよう。
@mot0aki ・ Red Journey Meetup
45


# Page. 46

![Page Image](https://bcdn.docswell.com/page/GEWGRV53J2.jpg)

これからの、仮説検証プロセス
01 インセプションデッキのたたき台を起こす
02 プロダクトの狙いを肉付けする
03 仮説キャンバスの観点を深堀り・ツッコミを入れる
04 誰の何を解くのかを、決める
05 検証計画・線表・インタビュー台本を整理する
06 実際に、顧客に会って確かめる
07 インサイト分析を手伝う
08 学びを言語化し、次に何をつくるかを決める
AI
人/AI
AI
人/AI
AI
人
AI
人/AI
前回と同じ構図。人に残るのは インプットとアウトプットの確認/引き受け、そして 現実に触れること/人に会うこと。
@mot0aki ・ Red Journey Meetup
46


# Page. 47

![Page Image](https://bcdn.docswell.com/page/47ZLR4NGJ3.jpg)

06
まとめ


# Page. 48

![Page Image](https://bcdn.docswell.com/page/YJ6WR38QJV.jpg)

前回、この円を描きました
仮説を立て、つくり、まなび、また次の仮説へ。
@mot0aki ・ Red Journey Meetup
48


# Page. 49

![Page Image](https://bcdn.docswell.com/page/GJ5M8L92J4.jpg)

この円に、時間軸を足すと
同じところを回っているのではない。回るたびにより高く、より良い方向へ。
@mot0aki ・ Red Journey Meetup
49


# Page. 50

![Page Image](https://bcdn.docswell.com/page/LE3W8LY1E5.jpg)

「つくる」の開発サイクルをAI駆動開発が速めていくように、
「なにをつくるか」の仮説検証サイクルも
生成AIを使って カイテン を速めていく。
@mot0aki ・ Red Journey Meetup
50


# Page. 51

![Page Image](https://bcdn.docswell.com/page/8EDKMN5K7G.jpg)

この カイテン の連続の螺旋構造を作り出すことで、
より良い 価値 / 仕事 / 世界 へ
つなげていくことができるはずです。
長く長く続く、カイテンの旅(=ジャーニー)へ
@mot0aki ・ Red Journey Meetup
51


# Page. 52

![Page Image](https://bcdn.docswell.com/page/V7PKR5G3J8.jpg)

まとめ
AIでつくる速度は上がった。だが、「何をつくるべきか」はそのままでは速くならない。
「つくる」と「まなぶ」の両輪を回してはじめて、価値提供のサイクルは速くなる。
価値は事前に完全予測できない。だから仮説を立て、小さく試し、結果から学ぶ。
そのための道具（インセプションデッキ / 仮説キャンバス / 検証キャンバス）も、生成AIでカイテン
を上げられる。
ただし、現実・人に触れることとねらいと責任の引き受けは、人に残る。
@mot0aki ・ Red Journey Meetup
52


# Page. 53

![Page Image](https://bcdn.docswell.com/page/2JVVRP6NJQ.jpg)

Q&A・ディスカッション
たとえば、、、
B2B・社内システムでも検証を回せる？
まずはどこから始める？
AIが出す仮説、信じていいの？
生成AIがなくても、検証は回せる？
生成AIで、検証の質は上がる？
@mot0aki ・ Red Journey Meetup
53


# Page. 54

![Page Image](https://bcdn.docswell.com/page/5EGLMPN5JL.jpg)

参加後アンケートにご協力ください
今日の内容はいかがでしたか？
みなさんの声が、この勉強会の次の仮説になります。
▶ 1〜2分で終わります。率直な感想をぜ
ひ!
https://forms.gle/Yw3W9aamdgqs
PSry7
右の QR からどうぞ。
@mot0aki ・ Red Journey Meetup
54


# Page. 55

![Page Image](https://bcdn.docswell.com/page/4JQYR2QL7P.jpg)

ありがとうございました
THANK YOU
Motoaki Tanaka @mot0aki