毎日同じシャツを着よう〜AI駆動開発における決定負荷について〜

by Kazuki Sakamoto/ikki0006

Embed

Start on current slide

Slide 1

Slide 1 text

株式会社Algomatic 毎日同じシャツを着よう〜AI駆動開発における決定負荷について〜 conﬁdential ©Algomatic 1

Slide 2

Slide 2 text

会社紹介/自己紹介 ©Algomatic

Slide 3

Slide 3 text

WHO WE ARE conﬁdential ©Algomatic 3

Slide 4

Slide 4 text

©Algomatic 4

Slide 5

Slide 5 text

自己紹介株式会社 Algomatic 執⾏役員技術責任者（VPoE）坂本⼀樹 / Kazuki Sakamoto 携帯電話のネットワーク弄ってた元々は⽣粋のインフラ屋です。 SaaS会社、データ分析会社と転々としていましたが⽣成AIに挑戦したくてAlgomaticにJoinしました。プライベート - 直近の関⼼はマイホームです。 - 家買えるかの瀬⼾際です - 申告漏れで購⼊10⽇前ですがローン通ってません - 通らなければウン千万の罰⾦です - 家買うだけじゃなくて保険‧ローン⾊々決めなきゃいけない事が多い ©Algomatic

Slide 6

Slide 6 text

今日話すこと ©Algomatic

Slide 7

Slide 7 text

©Algomatic

Slide 8

Slide 8 text

©Algomatic

Slide 9

Slide 9 text

人生には意思決定が多すぎる!!!! ©Algomatic

Slide 10

Slide 10 text

今日話すこと今日持ち帰ってほしいこと 1.決定負荷を分散しよう 2.決めないことはAIに任せよう conﬁdential ©Algomatic 10

Slide 11

Slide 11 text

何があったのか ©Algomatic

Slide 12

Slide 12 text

Algomaticで取り組んでいる AI駆動開発 ©Algomatic

Slide 13

Slide 13 text

Algomaticで取り組んでいるAI駆動開発要件定義時段階でモックを作る意思決定 ©Algomatic

Slide 14

Slide 14 text

Algomaticで取り組んでいるAI駆動開発要件定義時段階でモックを作る意思決定 ©Algomatic

Slide 15

Slide 15 text

何故このパターンにしたか ©Algomatic

Slide 16

Slide 16 text

何故このパターンにしたかシステム開発最大の問題は今も昔も認識がズレること考慮が漏れてる業務フローこうなってない要件定義通りのはず。。。ありえない組み合わせがあるモノができて初めて認識ズレが発覚する conﬁdential ©Algomatic 16

Slide 17

Slide 17 text

そうです ©Algomatic

Slide 18

Slide 18 text

かの有名なあの木の絵です ©Algomatic

Slide 19

Slide 19 text

何故このパターンにしたかあの木の絵(Tree Swing Cartoons) https://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%93%E3%81%AB%E 5%BF%85%E8%A6%81%E3%81%A0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE ©Algomatic

Slide 20

Slide 20 text

何故このパターンにしたか開発手法は常に認識ズレ/価値のズレとの戦いだった WF開発要件定義書をズレないようにたくさんのドキュメントで担保 - 新旧業務フローシステム関連図システム間IF定義書機能一覧概念ERD データ項目定義帳票レイアウト conﬁdential アジャイル開発細かいリリースと仕様変更への強さでそもそも変化を前提とする - 継続的なリリース要求の変化に対応ユーザーストーリーでの要件整理プロセスより対話 ©Algomatic 20

Slide 21

Slide 21 text

何故このパターンにしたか開発手法は常に認識ズレ/価値のズレとの戦いだった価値を提供するために細かく定義するから早く触るへ WF開発要件定義書をズレないようにたくさんのドキュメントで担保 - 新旧業務フローシステム関連図システム間IF定義書機能一覧概念ERD データ項目定義帳票レイアウト ….. conﬁdential アジャイル開発細かいリリースと仕様変更の強さでそもそも変化を受け入れる - 継続的なリリース要求の変化に対応ユーザーストーリーでの要件整理プロセスより対話 ©Algomatic 21

Slide 22

Slide 22 text

じゃあもっと早く作ればいいじゃん ©Algomatic

Slide 23

Slide 23 text

何故このパターンにしたか今回挑戦したこと仕様駆動開発仕様書記述‧ 修正（設計書）記述‧ 修正 Algomaticの挑戦仕様‧ FB フロントソースコードコーディング仕様書記述‧ 修正バックエンドソースコードソースコードソースコードコーディング仕様を元にソースコードを自動で生成 conﬁdential コーディングフロントを先に作ることで全員がモノで確認できる ©Algomatic 23

Slide 24

Slide 24 text

何故このパターンにしたか今回挑戦したこと仕様駆動開発仕様書記述‧ 修正 Algomaticの挑戦フロントソースコード AI時代ならではの方法記述‧ 修正（設計書）仕様‧ FB コーディング仕様書記述‧ 修正バックエンドソースコードソースコードソースコードコーディング仕様を元にソースコードを自動で生成 conﬁdential コーディングフロントを先に作ることで全員がモノで確認できる ©Algomatic 24

Slide 25

Slide 25 text

勝ったな ©Algomatic

Slide 26

Slide 26 text

結果 ©Algomatic

Slide 27

Slide 27 text

課題管理に200個超の決定事項発生.... ©Algomatic

Slide 28

Slide 28 text

何が起きたか ©Algomatic

Slide 29

Slide 29 text

何が起きたか今までは意図せず決定が分散されてた既存開発要件定義開発テストリリース 100個くらいの決定事項 50個くらいの決定事項 20個くらいの決定事項 30個くらいの決定事項作ってわかるいじってわかる沢山いじってわかる各Phで初めてわかることが多かった conﬁdential ©Algomatic 29

Slide 30

Slide 30 text

何が起きたか初めてわかることが寄ってしまった新規開発要件定義開発テストリリース 200個くらいの決定事項 10個くらいの決定事項 10個くらいの決定事項 10個くらいの決定事項作ってわかる作ってわかるいじってわかる沢山いじってわかるいじってわかる conﬁdential 沢山いじってわかる ©Algomatic 30

Slide 31

Slide 31 text

クライアントが価値を考え、FBしてくれる ©Algomatic

Slide 32

Slide 32 text

上手くいってるのに要件定義の工数が跳ね上がる ©Algomatic

Slide 33

Slide 33 text

当時のPdMのSlack ©Algomatic

Slide 34

Slide 34 text

©Algomatic

Slide 35

Slide 35 text

気合いとしか言わなくなってしまった ©Algomatic

Slide 36

Slide 36 text

ホント、すいません。 ©Algomatic

Slide 37

Slide 37 text

どうやって解決したか ©Algomatic

Slide 38

Slide 38 text

どうやって解決したか (再掲)今日持ち帰ってほしいこと 1.決定負荷を分散しよう 2.決めないことはAIに任せよう conﬁdential ©Algomatic 38

Slide 39

Slide 39 text

決定負荷を分散しよう ©Algomatic

Slide 40

Slide 40 text

どうやって解決したか仮に以前の開発で全員が越境しようとすると。。。 A画面は〜整合性とれてる? 要件出して欲しい B機能は〜 Cモジュールは〜デザイナーエンジニアエンジニア PdM 元々はみんながバラバラに意思決定できなかった conﬁdential ©Algomatic 40

Slide 41

Slide 41 text

どうやって解決したか全員が価値に向けて意思決定ができる A画面作ってみました B機能作ってみましたいじって違和感ないか見ます Cモジュール作ってみましたデザイナーエンジニアエンジニア PdM バラバラに決定してもモックの動作で最終決定ができる conﬁdential ©Algomatic 41

Slide 42

Slide 42 text

どうやって解決したか全員が価値に向けて意思決定をする A画面作ってみましたこれには全員の業務理解・オーナーシップが必要 B機能作ってみましたいじって違和感ないか見ます Cモジュール作ってみましたデザイナーエンジニアエンジニア PdM バラバラに決定してもモックの動作で最終決定ができる conﬁdential ©Algomatic 42

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

どうやって解決したか決めないことはAIに任せようボタンの配置どうしようスキーマどうしよう。。。。他の画面と整合してる? デザイナーエンジニアエンジニア PdM 分散しても決めなきゃいけないことは山積み conﬁdential ©Algomatic 45

Slide 46

Slide 46 text

どうやって解決したか決めないことはAIに任せようボタンの配置どうしようスキーマどうしよう気合!!!! 他の画面と整合してる? デザイナーエンジニアエンジニア PdM 分散しても決めなきゃいけないことは山積み conﬁdential ©Algomatic 46

Slide 47

Slide 47 text

どうやって解決したか決めないことはAIに任せようボタンの配置どうしようスキーマどうしよう気合!!!! こうならないために他の画面と整合してる? デザイナーエンジニアエンジニア PdM 分散しても決めなきゃいけないことは山積み conﬁdential ©Algomatic 47

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

どうやって解決したか決めないことはAIに任せよう既存機能以前作った別システム世の中のベストプラクティス任せるものは任せる今までの判断記録デザインパターン etc…. 既存を参考にするはAIの得意パターン conﬁdential ©Algomatic 51