AIと要求・要件を整理してアプリを作るための考え方_AIもくもく会_20260823

本気のAIもくもく会 #1
https://yanagawa.connpass.com/event/400392/

での資料です

Transcript

1. AIもくもく会 #1 要求・要件を整理して、小さく作る AIと要求・要件を整理して アプリを作るための考え方 機能ではなく、現在地と目的地から始める。 2026年8月23日 1
2. この資料の役割 最初に決めるのは、機能ではなく「誰の何が変わるか」 欲しい機能だけをAIへ渡すと、足りない前提をAIが推測で埋めます。 01 機能から渡す 例：自動で要約する画面がほしい 02 → AIが前提を推測する 03 → 誰が・いつ・何のためかを補う 動くが、変化を測れない 誰の何も変わらない成果物になる As-IsとGoalのギャップを埋めるTo-Beを、小さく試す。 AIに推測させる前に、体験・前提・判断基準・実現したい変化を言葉にします。 AIもくもく会 #1 2
3. 第1章｜現在地と目的地を描く 開発の「種（アイデア）」は直近の出来事に落ちている 作りたいものが明確でなくても、最近の実話から始められます。 1 最近、面倒だった 時間がかかった／往復した／迷った 2 後回しにしている 繰り返すのが億劫／判断材料が散らばる 3 抽象的な理想より 直近の実話。 面白そう、試したい AIは、具体的な出来事から 現在地を一緒に描けます。 まだ答えがなくても、体験を確かめたい 問い：直近24時間で、一度でも「面倒だな」と思ったのはどこ？ AIもくもく会 #1 3
4. 第1章｜全体の地図 現在地とゴールの差を「アプリ」で埋める 01 02 As-Is いまの流れ 事実から現在地を描く → 03 Goal 実現したい状態 誰の何が変われば前進か → Gap Goalを阻む差 影響が大きい差を選ぶ 04 → To-Be 差を埋める新しい流れ 人の判断点も残す 種を見つける → As-Is → Goal → Gap → To-Be → 8観点 → 小さく作る 機能一覧は、この地図ができてから。 AIもくもく会 #1 4
5. As-Is｜現在地 As-Is：事実・推測・未知を、分けて書く 直近の具体例から、いま実際にどう行っているかを描きます。 事実 推測 未知 実際に見た・したこと 理由や原因の仮説 まだ分からないこと 人、ツール、情報、判断、待ち、 事実と混ぜず、検証できる形で残 AIに埋めさせず、質問として残す 手戻り す 曖昧さをAIに推測させると、その先の設計が歪みます。 AIもくもく会 #1 5
6. Goal｜目的地 Goal：欲しい機能ではなく、欲しい「変化」で書く 何が変われば前進かを、誰・行動・質や速さで言葉にします。 × 機能の言い方 ◦ 変化の言い方 自動で要約したい 要約のあと、誰が何を 早く・確かにできるか 手段だけでは、前進を判定できない 観察できる変化なら、試した結果を話せる 機能はGoalではなく、手段である。 AIもくもく会 #1 6
7. Gap｜差を選ぶ Gap：全部解かない。Goalへの影響が大きいものを選ぶ 1 対応づける As-Isの詰まりと、Goalまでに足りないものを並べる 2 代替を疑う ルール変更や説明だけで解けるものがないかを見る 3 アプリを 作らなくても 解けるGapはある 困りごとを全部、 影響で選ぶ 実装に変換しない。 解消した後に、Goalへ大きく効く差を一つ選ぶ 選ぶ基準は、機能の派手さではなく、Goalへの影響。 AIもくもく会 #1 7
8. To-Be｜新しい流れ To-Be：機能一覧ではなく「新しい流れ」 誰が何をするかを先に置き、AIやアプリの役割を途中へ配置します。 01 人が始める 02 → アプリへ渡す 目的と入力を選ぶ 03 → 整理・提示 必要な情報だけ 判断材料を作る 04 → 人が確認 05 → 次の行動 修正・承認する 結果を使う 人の確認点を残す 失敗時の戻り方を決める 削除・上書き・共有・重要な判断は、人が決める。 失敗や情報不足のとき、どこへ戻るかを決める。 AIもくもく会 #1 8
9. 最小範囲｜欲張らない 「最小」は、機能が少ないことではない 一度、通せる。 ✓ Goalに近づく変化を試せる ✓ 入力から結果まで一度通せる ✓ 人の確認点が含まれる ✓ 今回の時間で動作確認できる ✓ 代替データ、または使える連携で確かめられる 入力から結果まで 人の確認点を含めて 今回の時間で確かめる。 To-Be全体ではなく、変化を検証できる最小の縦切りを作る。 AIもくもく会 #1 9
10. 第2章 要件へ落とすための 8つの観点 To-Beを、実装の判断に使える要件へ変換する。 抜けを見つけるために、AIを活用する。 AIもくもく会 #1 10
11. 8つの観点｜1—4 価値と設計の核を固める 1 2 3 4 前提定義 型化 リスク検証 言語化 AIもくもく会 #1 誰が、いつ、どこで、なぜ使うか。今回扱わないこと 入力・処理・出力。必須と任意、正常系と例外系 使われない理由、誤解、完成しない原因。削る機能 一言説明、作りたい理由、価値の核、残す言葉 11
12. 8つの観点｜5—8 安全に試し、観察できる形へ 5 6 7 8 委譲 データ・安全 体験設計 公開・運用 AIもくもく会 #1 アプリへ任せる作業と、人が確認・承認する作業 機密性、保存と削除、外部送信、秘密情報 初見で迷わない画面、状態表示、完成判定 誰に試すか、公開構成、公開後に観察すること 12
13. データ・安全 実装前に気にしよう：公開可能情報 vs 秘匿情報 公開URLから見られて困る情報がないかを、先に確認します。 01 個人情報・社外秘 02 そもそも扱う必要がある？ 03 外部API どの情報を外部へ送る？ 保存と削除 どこへ保存し、いつ消す？ 04 秘密情報 成果物に含めず、どこで管理する？ 秘密情報を成果物へ含めない。 AIもくもく会 #1 13
14. 公開・運用 公開はゴールではなく、観察のスタート 動くものができた後で慌てないよう、公開後に何を見るかも先に決めます。 01 最初の相手 誰に試してもらう？ 02 → 公開の準備 構成・環境変数は？ 03 → 制約の説明 04 → 何ができない？ 観察と改善 どこで迷った？ 公開後に何を見るかが、次の改善を決める。 AIもくもく会 #1 14
15. 第3章 対話を通して要件を定める AIへの聞き方と、人が判断する場所を固める。 質問・回答は、1つずつ。 AIもくもく会 #1 15
16. 対話設計 慣れないうちは「1問1答」を心がける まとめて聞くと、答えが雑になり、要件も雑になります。何よりレビュー量が膨大に！ 1問 → 1答 咀嚼 → → 次の1問 レビュー 既に出た答えは 聞き直さない。 そこからまた推論が始まっ てややこしくなる可能性も AIが提示する「選択肢」は、正解へ誘導するためではなく、人の思考のきっかけとして使う 選択肢だけにとらわれず、自由記述も積極的に使いましょう AIもくもく会 #1 16
17. 対話をメモへ 会話の流れを、要件へ変える・整える 今日のもくもくで使うキットは、会話をそのまま要件へ整理する仕組みになってます 01 02 03 04 05 入口 具体例 構造化 判断 整理 → 直近の出来事を → AIが整理して → 人が修正・ → 次の段階へ 思い出す 見せる 答えやすい質問の 提示 選択する 渡せる形に整える 会話で出た答えを、要件メモへ。 AIもくもく会 #1 17
18. AIと人の境界 AIに任せること、人が承認すること 人が決める AIへ任せられる • Goalと今回作る範囲 • 会話の構造化と要件メモ化 • 成果物の確認・修正 • 抜けや矛盾の発見 • 削除、上書き、共有 • Goalを変えない軽い判断 • 個人情報や機密を扱ってよいか • 選択肢や代替案の提示 AIもくもく会 #1 18
19. よくある失敗 作ること自体が目的にならないこと！（自戒 — 作りたいものが曖昧なまま、AIにテーマを決めさせる — As-Is・Goal・To-Beを飛ばして、実装から始める 動く ≠ 前進 — 合意しないまま、制作範囲が少しずつ確定する 作る前に、 — 個人情報や事実を、AIの推測で補ってしまう 何を確かめたいか 1行で決める。 — 困りごと全部を解こうとして、最小範囲を見失う AIもくもく会 #1 19
20. 今日、最低限持って帰って欲しいこと 作る前に、「状態変化（ゴール）」を。 誰の？ 何が変わる？ どこまで試す？ 使う人を一人にする 観察できる行動・状態で 今回の時間で一周できる範囲 アイデア → As-Is → Goal → Gap → To-Be → 8観点 → 小さく作る まず、直近の出来事を1つ話してください。 20