「いつか使う」の「いつか」は来ない 〜AI駆動開発における「作らない」判断について〜

Transcript

1. AI駆動開発のループに⼈はどう関わるか 「いつか使う」の「いつか」は来ない 〜AI駆動開発の「作らない」判断〜 2026.11.04 v1 株式会社Algomatic 執⾏役員 VPoE 坂本 ⼀樹 ©Algomatic
2. 会社紹介/自己紹介 ©Algomatic
3. 会社紹介 Confidential ©Algomatic 2
4. 会社紹介 Confidential ©Algomatic 2
5. ⾃⼰紹介 株式会社 Algomatic 執⾏役員 技術責任者（VPoE） 坂本 ⼀樹 / Kazuki Sakamoto 携帯電話ネットワーク弄ってた元々は⽣粋のインフラ屋です。 SaaS会社、データ分析会社と転々としていましたが ⽣成AIに挑戦したくてAlgomaticにJoinしました。 組織作り‧採⽤がメインミッションです。 プライベート - 最近の興味はAI駆動(家族)経営です - ⾷べるのが好きすぎて、エンゲル係数⾼すぎとAIに怒られてます ©Algomatic
6. 導⼊ AI駆動(家族)経営用AIエージェント作ってます。 Loopで自己改善できます LINEで指⽰すると機能追加できるように 作ってます これは嫁⽒が事故った時に先にエージェントに相談された図 ©Algomatic
7. 質問です 楽しいらしく、 機能作りまくって全体像把握できてません ©Algomatic
8. 質問です いつか使うで機能を作るな 💢 ©Algomatic
9. 質問です なんか聞いたことあるかも。。。 ©Algomatic
10. 本題 ©Algomatic
11. 質問です YAGNI、知っている方？ ✋ ©Algomatic
12. YAGNI 必要になるまで作らない、という原則 YAGNI ― You Aren't Gonna Need It 必要になったときに作れ。 必要になりそうだと思ったときには作るな。 ― Ron Jeffries（XP） アジャイル‧マニフェストの最初の17⼈の署名者の1⼈ 使われない機能にも、作る‧テストする‧保守するコストがかかるから、というのが理由でした。 ©Algomatic
13. AIで変わったこと AIで大きく下がった「作るコスト」 Algomaticでの実装期間 4ヶ月 → 2ヶ月 4ヶ⽉かかると⾒ていた開発が、2ヶ⽉で終わりました ©Algomatic
14. これまでとの違い 作るのが安くなると、どんどん増える機能 以前：⼯数が絞っていた いま：絞るものがない 優先度の低い要望は、⾃然に後回しになっていた 「いつか使うかも」という機能も、後回しにする理由がない ©Algomatic
15. 機能がどんどん⼊る それで、いいんだっけ？ 作るのが安いなら、YAGNIはもう要らない？ ©Algomatic
16. それで、いいんだっけ？ 大抵の人は、 「No」と答えると思います ©Algomatic
17. なぜか 機能は、洗練されているほど良いという考え Less, but better より少なく、しかし、より良く ― ディーター‧ラムス（Dieter Rams） ドイツの伝説的なインダストリアルデザイナー。 iPhoneやMacなど、いまのApple製品のデザインにも⼤きな影響を与えた⼈物です。 ©Algomatic
18. なぜか 機能は、洗練されているほど良いという考え TVのリモコンだと。。。 物理ボタンだと左が決して悪いわけではない ⼀⽅でやることが千差万別なITシステムは右を⽬指 しがち ©Algomatic
19. それで、いいんだっけ？ とはいえ。。。 ©Algomatic
20. それでも、実際に起きました 分かっていても、要らない機能は作られかける 実際にあったこと でも 「CSVでダウンロードしたい」 同じことは、 あったら便利で、作るのも簡単。 BigQueryですでにできる 4か所で作られかけた BigQuery使えない⼈は AIでを使えるようになってもらえばよい ©Algomatic
21. 今⽇の話 作れるからこそ、 作らない判断をループに入れる ⼯数が⽌めてくれない以上、作らない判断もループの中に置く必要があります。 その判断をどこで、誰がしているかを話します。 ©Algomatic
22. じゃあ、どうやってループを作っているか ©Algomatic
23. 全体像 要件・実装・運用の3つのループで回す開発 要望を集める（AI） AIが実装 外側：要件 AIが材料と案を作り、PdMとエンジニア が判断する 要件の案を バグ‧不具合 作る（AI） 内側：実装 OKが出たものは、AIが実装し⾃動で チケット マージ。⼈はコードをなるべく⾒ない 運⽤ ⾃動マージ‧リリース 運用 リリース後に分かったことを、外側へ戻 す ヘルスチェック PdMとエンジニアが判断（⼈） ©Algomatic
24. 全体像：いまどこの話か まずは、外側のループ 要望を集める（AI） AIが実装 要件の案を バグ‧不具合 作る（AI） 外側：要件のループ 要件の材料集めと案づくりは チケット AIに任せ、最後の判断は⼈が 運⽤ します。 ⾃動マージ‧リリース ヘルスチェック PdMとエンジニアが判断（⼈） ©Algomatic
25. 外側のループ｜要件づくりはAI 要件の材料集めと案づくりは、AIの仕事 AI AI ⼈ 集める 照らし合わせる 決める Slack‧Linear‧会議の録画か 他の要望や既存の機能と⽐べ PdMとエンジニアが⾒て、作る ら要望を抜き出して、同じ要望 て、どう解決するかの案を出す かどうかを決める。通ったもの が何件来ているかを数える だけをチケットにする ©Algomatic
26. 外側のループ｜実際の出⼒ AIが出してくる要件の整理 [ AIの出⼒画⾯のスクリーンショット ] 社名‧顧客名‧⼈名‧チャンネル名は伏せる ※実際に過去AIに要望を整理させた画⾯です ©Algomatic
27. 外側のループ｜実際の出⼒ AIが出してくる要件の整理 [ AIの出⼒画⾯のスクリーンショット ] 社名‧顧客名‧⼈名‧チャンネル名は伏せる ※実際に過去AIに要望を整理させた画⾯です ©Algomatic
28. 外側のループ｜実際の出⼒ AIが出してくる要件の整理 [ AIの出⼒画⾯のスクリーンショット ] 社名‧顧客名‧⼈名‧チャンネル名は伏せる ※実際に過去AIに要望を整理させた画⾯です ©Algomatic
29. 外側のループ｜実際の出⼒ AIが出してくる要件の整理 [ AIの出⼒画⾯のスクリーンショット ] 社名‧顧客名‧⼈名‧チャンネル名は伏せる ※実際に過去AIに要望を整理させた画⾯です ©Algomatic
30. 外側のループ｜AIをPdMの基準に合わせる PdMの判断とのズレを修正 PdMの考えを最初に全部書き出すのではなく、出⼒を⾒てNGの理由を潰していきました 1. AI 2. PdM 要望の整理と案を出す 出力を見て OK / NG をつける 4. 直す プロンプトを調整する。入れるデータに漏れがな いか確かめ、コンテキスト元を調整する 3. NGだったら なぜその判断になったかを洗う ©Algomatic
31. 外側のループ｜最後の判断は⼈ 最後の判断は、PdMとエンジニアの両方で 使う⼈にとっての価値と、プロダクトを持ち続ける側にとっての価値の両⽅を⾒ます エンジニア PdM 使う人にとって価値があるか AIの案を⼀度⾒て、作るかどうかを判断する 作っても負債にならないか 本当に意味のあるものか。意味があっても、その作りが 今後のアーキテクチャや技術負債の⾯で問題にならない か。エンジニアが判断すべき作らない理由がある 例 CSVダウンロードは、⽬的のデータ参照がBigQueryで⾜りると判断して、作らなかった ©Algomatic
32. 今⽇いちばん⾔いたいこと 「何を作るか」ではなく、 「何を作らないか」を考える 作るのは早くなりましたが、何もかも作るべきというわけではありません。 要らないものを⽌めるには、「何を作らないべきか」を意識する必要があります。 ©Algomatic
33. 全体像：いまどこの話か 次に、内側のループ 要望を集める（AI） AIが実装 要件の案を バグ‧不具合 作る（AI） 内側：実装のループ 要件がOKになったら、⼈は チケット コードを⾒ずに⾃動で回しま 運⽤ す。 ⾃動マージ‧リリース ヘルスチェック PdMとエンジニアが判断（⼈） ©Algomatic
34. 以前のやり⽅ 以前は、AIのすべてのコードを人がレビュー AIはすぐ書く PRはどんどん出てくる 人のレビュー待ち まとめて出す ⾒る⼈の時間は増えないので、 いくつもの機能を混ぜて、2週 ここで詰まる 間に1回のリリース ⼈の⽬をコードに使うと、要件を⾒る時間がなくなります。 ©Algomatic
35. 今⽇いちばん⾔いたいこと よし!自動化だ。 オートマージだ! ほんまか? ©Algomatic
36. 全体像：いまどこの話か 当たり前の品質を提供する必要がある 内側のループは当たり前品質を 担保する 何を持って品質を担保するか ⼈がレビューするから安全なのか AIが作るから不安なのか ©Algomatic
37. 内側のループ｜要件に問題がなければ、⾃動化する 先に決めておく、自動マージの条件 1つでも満たさなければ⾃動マージしません。結果が出るまでは保留にします 01 E2Eのテストが存在している 02 DB定義など承認無しでは危険なファイルに触れていない 03 AIのコードレビューで、critical‧high の指摘がない 04 CIがすべて通っている（Lint‧型‧セキュリティ‧E2E） 05 developと衝突していない ©Algomatic 22
38. 内側のループ｜条件02：触ってはいけない場所 触れたら自動マージしない場所 AIは、⾃分のルールも、⾃分を採点する基準も書き換えられません データベース インフラ 認証 schema‧migration、Repository の実装 infra、Dockerfile、compose middleware、webhook、ログインガード 品質チェックの設定 依存関係 biome、tsconfig、vitest‧playwright の設定 package.json、lockfile AIとCIの設定 .github、.claude、CLAUDE.md、AGENTS.md ©Algomatic
39. 今⽇いちばん⾔いたいこと テストで品質を保証し、 危険なファイルは人の目を入れる DBのマイグレーションなど、取り返しのつかない変更は⼈が確認する ©Algomatic
40. 全体像：いまどこの話か 最後に、運用のループ 要望を集める（AI） AIが実装 要件の案を バグ‧不具合 作る（AI） 運用のループ リリースした後に分かったこ チケット とを、外側のループへ戻しま 運⽤ す。 ⾃動マージ‧リリース ヘルスチェック PdMとエンジニアが判断（⼈） ©Algomatic
41. 今⽇いちばん⾔いたいこと 自動化はズレていく 運用との戦い ⾃動化するということは、違和感での検知が難しくなるということ。 ループを回して適切に対応を取り出せるようにすべき。 ©Algomatic
42. ループを閉じる｜運⽤から次の要望へ 運用のループから、すべて外側に戻す 要望を集める（AI） AIが実装 運用で見つかったもの すべて バグ‧不具合も、ヘルスチェック の結果も、すべて要件のループに戻 要件の案を 内側 す バグ‧不具合 作る（AI） チケット 運⽤のループ 人が判断してから PdMとエンジニアが判断したもの ⾃動マージ‧リリース ヘルスチェック だけが、チケットになって実装へ PdMとエンジニアが判断（⼈） ©Algomatic
43. やってみて 速く出せて、要らないものは止まるループ コードを⾒なくなって 作るものが使われるか改めて⾒るようになって 2週間に1回 使う人にとって → 週2回のときも 価値のないものを止めた 機能をまとめず、できたものから出せるようになりまし すでに別の⼿段でできることや、あったら便利なだけの た。 機能を、出さずに済みました。 ©Algomatic
44. 今後の展望/まとめ ©Algomatic
45. 今後の展望 内側のループのやり方を、外側にも 内側：実装のループ（いま） 外側：要件のループ（これから） 人は条件を決め、 人は判断の基準を決め、 判定は機械がする 判断はAIがする ⾃動マージの条件を先に決めたので、⼈はコードを⾒な PdMとエンジニアがしている「作るかどうか」の判断 くてよくなった。 も、基準を決めてAIに任せていきたい。 ©Algomatic
46. 「いつか使う」の「いつか」は、 たいてい来ません だから、作らない判断がループに必要です ©Algomatic
47. 最後に 作るのが簡単になった分、 作らない判断をloopに入れてみませんか? 速く作れるループができたら、次は止める場所をループの中に作りましょう! ©Algomatic