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

新規事業と生成AIがもたらす不確実性を乗り越えるため、イベントを待たずに即時フィードバックをしたいと考え、あえてタイムボックスを意識しない開発プロセスを試みました。どのように開発プロセスを考え進めてきたのか、現在どのような状況にあるのかについてお話しします。

Transcript

1. 不確実性を乗り越える 開発プロセス id:noy72/@noynote 1 新規事業 ✖ 生成 AI の 2024/10/24 はてな 生成AI×新規事業 の挑戦
2. id:noy72 (のい) • 2021 入社 ➡ 社内向けプロダクト開発 　データ基盤 ➡ 新規事業 2
3. 話すこと • toitta の開発にあたり ◦ 何を考えて ◦ どのように開発を進めることにしたのか ◦ その結果どうだったのか ◦ 今はどうなのか 3
4. 当時の状況 • βリリース前の検証段階 • 以下を知りたい ◦ 開発しているプロダクトに需要があるかどうか ◦ AI の生成物が受け入れられるかどうか 4
5. 5 新規事業 ✖ 生成 AI の 不確実性には何があるの か
6. 6 不確実性は山ほどある
7. 新規事業で問題になりそうな点 • ユーザーの欲しいものがわからない • チーム内でプロダクトや機能に対する 理解が一致していない ◦ 手戻りが発生するかも 7
8. 新規事業だからなおさら 問題になりそうな点 • ユーザーの欲しいものがわからない • チーム内でプロダクトや機能に対する 理解が一致していない ◦ 手戻りが発生するかも 8
9. 生成 AI で問題になりそうな点 • 生成物の品質の評価が難しい ◦ 改善できているかどうかの判断が難しい ◦ 「どこまで」改善すればよいのかわからない • 生成物の品質を上げるためのコストを 予測しにくい ◦ 計画が立てにくい 9
10. これらをうまく扱いたい • ユーザーの欲しい ものがわからない • チーム内でプロダ クトや機能に 対する理解が一致 していない • 生成物の品質の評価が 難しい • 生成物の品質を上げる ためのコストを予測し にくい 10
11. 11 どんな開発プロセスが 良いのか
12. これらをうまく扱いたい • ユーザーの欲しい ものがわからない • チーム内でプロダ クトや機能に 対する理解が一致 していない • 生成物の品質の評価が 難しい • 生成物の品質を上げる ためのコストを予測し にくい 12 再掲
13. 13 どのような対策がある？
14. (1) ユーザーの欲しいものがわからな い • ユーザーに話を聞きに行く ◦ 考えていること、作ろうとしているもの、 実際にできているものを見せる 14
15. (2) チーム内でプロダクトや機能に 対する理解が一致していない • 「作りたい機能」と「作った機能」が 一致しているか確認する 15
16. (3) 生成物の品質の評価が難しい • 人力で評価する ◦ 生成物を見比べて、どちらがより良いか選ぶ • 確認する頻度を上げる 16
17. (4) 生成物の品質を上げるためのコス トを予測しにくい • 現時点でどのくらいの品質なのか、 他に考えられる品質向上の案があるかを 定期的に伝える 17
18. 18 →フィードバックが重要
19. 19 開発する人たち プロダクトオーナー （ディレクター） フィードバックが重要
20. 20 開発する人たち プロダクトオーナー （ディレクター） フィードバックが重要
21. 21 開発する人たち プロダクトオーナー （ディレクター） 方法不確実性 ⬇ 通信不確実性 ⬇ フィードバックが重要
22. 22 開発する人たち プロダクトオーナー （ディレクター） 方法不確実性 ⬇ 通信不確実性 ⬇ ユーザー フィードバックが重要
23. 23 開発する人たち プロダクトオーナー （ディレクター） 方法不確実性 ⬇ 通信不確実性 ⬇ ユーザー フィードバックが重要
24. 24 開発する人たち プロダクトオーナー （ディレクター） 方法不確実性 ⬇ 通信不確実性 ⬇ ユーザー 目的不確実性 ⬇ に貢献 フィードバックが重要
25. 25 🤔
26. 26 1週間スプリントの スクラムをやる？
27. 27 🤔🤔
28. 28 ユーザーに話を 聞きに行くのは 週に一度だけ？
29. 29 「生成物の品質を上げ る」 は見積もれる？
30. 30 🤔🤔 🤔
31. 31 フィードバックはすぐにもら う やることは柔軟に決める
32. 32 スプリント期間 固定しなくてよいかも
33. toitta の開発プロセス 1. 達成したいこと・実装したい機能を決める 2. タスクを列挙して見積もり、 完了予測日を出す 3. 「いつまでに何を達成するのか」を決める 4. タスクが完了したら できるだけ早くフィードバックをもらう 33
34. toitta の開発プロセス • タスクの差し込みは「いつまでに」を 調整して対応する ◦ フィードバックの対応 ◦ AI 生成物の品質を上げる 34
35. toitta の開発プロセス • できるだけ早くレビューを受ける ◦ 「スプリントレビュー」という名前のイベントはない • ふりかえりは週ごとに行う 35
36. 36 実際にやってみて どうだったか
37. よかったこと • 開発の進め方で迷うことはなかった • 新規機能はすぐにチーム内に共有、 ユーザーに紹介できる状態にできた • 大きな手戻りは起こらなかった • AI 周りのタスクで過剰に時間を使ってしまう ことはなかった 37
38. 38 現在の様子
39. 現在のチーム • 開発プロセスは大きく変わってない • レビューの頻度を落とした ◦ プロダクトに機能が増えた ◦ 人が増えた 39
40. 40 スプリント期間 固定してもよいかも
41. なぜそう思ったのか • 「新規度」はどんどん減っていく ◦ プロダクトは大きく、機能は増えていく ◦ プロダクトへの理解が深まっていく • AI タスク専任エンジニアの存在 ◦ AI と web アプリケーションを 分けられるようになってきた 41
42. 42 まとめ
43. まとめ • タイムボックスの期間を決めず、 フィードバックを素早く受け取る 開発プロセスを紹介した • 事業の状態やチームの人員によって適切な 開発プロセスは変わる 43