新規事業×生成 AI の不確実性を乗り越える開発プロセス

by noy

Slide 1

Slide 1 text

不確実性を乗り越える開発プロセス id:noy72/@noynote 1 新規事業 ✖ 生成 AI の 2024/10/24 はてな生成AI×新規事業の挑戦

Slide 2

Slide 2 text

id:noy72 (のい) ● 2021 入社 ➡ 社内向けプロダクト開発　データ基盤 ➡ 新規事業 2

Slide 3

Slide 3 text

話すこと ● toitta の開発にあたり ○ 何を考えて ○ どのように開発を進めることにしたのか ○ その結果どうだったのか ○ 今はどうなのか 3

Slide 4

Slide 4 text

当時の状況 ● βリリース前の検証段階 ● 以下を知りたい ○ 開発しているプロダクトに需要があるかどうか ○ AI の生成物が受け入れられるかどうか 4

Slide 5

Slide 5 text

5 新規事業 ✖ 生成 AI の不確実性には何があるのか

Slide 6

Slide 6 text

6 不確実性は山ほどある

Slide 7

Slide 7 text

新規事業で問題になりそうな点 ● ユーザーの欲しいものがわからない ● チーム内でプロダクトや機能に対する理解が一致していない ○ 手戻りが発生するかも 7

Slide 8

Slide 8 text

新規事業だからなおさら問題になりそうな点 ● ユーザーの欲しいものがわからない ● チーム内でプロダクトや機能に対する理解が一致していない ○ 手戻りが発生するかも 8

Slide 9

Slide 9 text

生成 AI で問題になりそうな点 ● 生成物の品質の評価が難しい ○ 改善できているかどうかの判断が難しい ○ 「どこまで」改善すればよいのかわからない ● 生成物の品質を上げるためのコストを予測しにくい ○ 計画が立てにくい 9

Slide 10

Slide 10 text

これらをうまく扱いたい ● ユーザーの欲しいものがわからない ● チーム内でプロダクトや機能に対する理解が一致していない ● 生成物の品質の評価が難しい ● 生成物の品質を上げるためのコストを予測しにくい 10

Slide 11

Slide 11 text

11 どんな開発プロセスが良いのか

Slide 12

Slide 12 text

これらをうまく扱いたい ● ユーザーの欲しいものがわからない ● チーム内でプロダクトや機能に対する理解が一致していない ● 生成物の品質の評価が難しい ● 生成物の品質を上げるためのコストを予測しにくい 12 再掲

Slide 13

Slide 13 text

13 どのような対策がある？

Slide 14

Slide 14 text

(1) ユーザーの欲しいものがわからない ● ユーザーに話を聞きに行く ○ 考えていること、作ろうとしているもの、実際にできているものを見せる 14

Slide 15

Slide 15 text

(2) チーム内でプロダクトや機能に対する理解が一致していない ● 「作りたい機能」と「作った機能」が一致しているか確認する 15

Slide 16

Slide 16 text

(3) 生成物の品質の評価が難しい ● 人力で評価する ○ 生成物を見比べて、どちらがより良いか選ぶ ● 確認する頻度を上げる 16

Slide 17

Slide 17 text

(4) 生成物の品質を上げるためのコストを予測しにくい ● 現時点でどのくらいの品質なのか、他に考えられる品質向上の案があるかを定期的に伝える 17

Slide 18

Slide 18 text

18 →フィードバックが重要

Slide 19

Slide 19 text

19 開発する人たちプロダクトオーナー（ディレクター）フィードバックが重要

Slide 20

Slide 20 text

20 開発する人たちプロダクトオーナー（ディレクター）フィードバックが重要

Slide 21

Slide 21 text

21 開発する人たちプロダクトオーナー（ディレクター）方法不確実性 ⬇ 通信不確実性 ⬇ フィードバックが重要

Slide 22

Slide 22 text

22 開発する人たちプロダクトオーナー（ディレクター）方法不確実性 ⬇ 通信不確実性 ⬇ ユーザーフィードバックが重要

Slide 23

Slide 23 text

23 開発する人たちプロダクトオーナー（ディレクター）方法不確実性 ⬇ 通信不確実性 ⬇ ユーザーフィードバックが重要

Slide 24

Slide 24 text

24 開発する人たちプロダクトオーナー（ディレクター）方法不確実性 ⬇ 通信不確実性 ⬇ ユーザー目的不確実性 ⬇ に貢献フィードバックが重要

Slide 25

Slide 25 text

25 🤔

Slide 26

Slide 26 text

26 1週間スプリントのスクラムをやる？

Slide 27

Slide 27 text

27 🤔🤔

Slide 28

Slide 28 text

28 ユーザーに話を聞きに行くのは週に一度だけ？

Slide 29

Slide 29 text

29 「生成物の品質を上げる」は見積もれる？

Slide 30

Slide 30 text

30 🤔🤔 🤔

Slide 31

Slide 31 text

31 フィードバックはすぐにもらうやることは柔軟に決める

Slide 32

Slide 32 text

32 スプリント期間固定しなくてよいかも

Slide 33

Slide 33 text

toitta の開発プロセス 1. 達成したいこと・実装したい機能を決める 2. タスクを列挙して見積もり、完了予測日を出す 3. 「いつまでに何を達成するのか」を決める 4. タスクが完了したらできるだけ早くフィードバックをもらう 33

Slide 34

Slide 34 text

toitta の開発プロセス ● タスクの差し込みは「いつまでに」を調整して対応する ○ フィードバックの対応 ○ AI 生成物の品質を上げる 34

Slide 35

Slide 35 text

toitta の開発プロセス ● できるだけ早くレビューを受ける ○ 「スプリントレビュー」という名前のイベントはない ● ふりかえりは週ごとに行う 35

Slide 36

Slide 36 text

36 実際にやってみてどうだったか

Slide 37

Slide 37 text

よかったこと ● 開発の進め方で迷うことはなかった ● 新規機能はすぐにチーム内に共有、ユーザーに紹介できる状態にできた ● 大きな手戻りは起こらなかった ● AI 周りのタスクで過剰に時間を使ってしまうことはなかった 37

Slide 38

Slide 38 text

38 現在の様子

Slide 39

Slide 39 text

現在のチーム ● 開発プロセスは大きく変わってない ● レビューの頻度を落とした ○ プロダクトに機能が増えた ○ 人が増えた 39

Slide 40

Slide 40 text

40 スプリント期間固定してもよいかも

Slide 41

Slide 41 text

なぜそう思ったのか ● 「新規度」はどんどん減っていく ○ プロダクトは大きく、機能は増えていく ○ プロダクトへの理解が深まっていく ● AI タスク専任エンジニアの存在 ○ AI と web アプリケーションを分けられるようになってきた 41

Slide 42

Slide 42 text

42 まとめ

Slide 43

Slide 43 text

まとめ ● タイムボックスの期間を決めず、フィードバックを素早く受け取る開発プロセスを紹介した ● 事業の状態やチームの人員によって適切な開発プロセスは変わる 43