「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革のロードマップと実行 ─

by starfish719

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© Findy Inc. 🎲 活⽤レベルの個⼈差 AIエージェントの使いこなし度にメンバー間で⼤きなばらつき特にジュニアほど使えていない 🔍 AI出⼒の合否判断ができない理解せずに AI の出⼒をそのままレビューに回している 📉 Pull requestの質が低下コードの⼀貫性‧正確性が落ち⼿戻りが増えている 😩 リードクラスのレビュー負担増指摘の量が増え、本来注⼒すべきレビューに時間が割けない組織全体が「AI に使われている」状態に陥っている⼼当たりありませんか？ 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© Findy Inc. 8 計測したら、AIを導⼊しても⽣産性は変わらなかった 👥 稼働⼈数 1.5 倍メンバー数は増加 📤 1 ⼈あたりのPull request作成数横ばい 1⼈あたりのアウトプットは変化無し ⏱ レビュー → Approve 時間 +20 分昨年⽐で延伸 💬 平均コメント数‧レビュー数 +30% 指摘量が増加 AIを導⼊したのに、⽣産性は伸びていないファインディで実際に起きていたこと

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© Findy Inc. 🏗 AIを活⽤する前に、これらはAI関係なく重要 ✅ コード設計‧規約‧テストコード • アーキテクチャ‧命名規則‧型定義 • ⼗分なテストカバレッジ • ⼀貫した設計パターン → AI 以前から、品質を保つには必須 🌿 開発⽂化（プロセス） • Pull requestの粒度 • レビュー⽂化 • タスク分解の習慣 • etc → AI 以前から、開発を回すには必須この基盤の上にこそ、ガードレールもAIも活きる前提 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© Findy Inc. 🗺 ⼯程ごとに、AIの主体性と⼈間の役割は変わる⼯程 🤖 AIの役割 👤 ⼈間の役割要件定義‧タスク分解壁打ち‧たたき台⽣成意思決定‧スコープ確定 Issue / コード / PR ⽣成〜PRを⾃律実⾏分解されたタスクを渡すセルフ / レビュー複数観点でチェック設計‧要件適合の判断 QA‧マージ‧リリーステスト⽣成‧実⾏⽀援品質保証‧リリース判断⼯程 × 役割：AIと⼈間の分担 17

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© Findy Inc. ⚡ レベル1の⽬的：コード変更 + Pull request作成をAIで⾃動化 ⚠ 現場で起きている課題 🎲 活⽤レベルの個⼈差若⼿ほど使えていない∕メンバー間でばらつき⼤ 🔍 AI出⼒の合否判断ができない理解せずにAI出⼒をレビュー依頼 📉 Pull requestの質が低下リードクラスのレビュー負担が増加 😩 「AI に使われている」状態 AI主導になり、⼈間側の理解が追いつかない理解と責任の所在を再設計する必要がある「速く作る」フェーズと現状課題 27

Slide 28

Slide 28 text

© Findy Inc. 🛡 ⾃動化されても、品質と判断の最終責任は⼈間が引き受ける⼯程担当責任の対象コード変更 🤖 AI コード変更 Pull request作成 🤖 AI コード変更セルフレビュー 🤖 AI コード変更レビュー 👤 ⼈間作っているモノレビュー依頼を出すまでがPull request作成セルフレビューはレビュー依頼を出す前に⾏うべき AIが出⼒したコードの責任は「⼈間」にある 28

Slide 29

Slide 29 text

© Findy Inc. AI が参照するドキュメント‧ルールを整える 📘 README / プロジェクトドキュメント 🛠 やること前提‧運⽤ルールなどを記述 ✨ 効果 AIが⽂脈を理解初期質問の往復が減る 📐 AGENT.md / rules 🛠 やることコード規約‧命名規則‧ テスト⽅針をAIが参照 ✨ 効果出⼒されるコードの⼀貫性が担保される 📋 カスタムコマンド / プロンプトのテンプレ 🛠 やること依頼タスクの規格化（よくある作業をコマンド化） ✨ 効果同じ品質のアウトプットが繰り返し得られるガードレールがあって初めて、AIが「使い物になるコード」を出す AIのガードレール整備 29

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© Findy Inc. 🚢 Pull request作成 Pull request作成を⾃動化品質チェック内蔵 🤖 セルフレビュー複数エージェントを並列で実⾏複数の観点からチェック 🔄 外部AI併⽤レビュー Codex CLI と並⾏運⽤レビュー精度UP ⏰ 定期セルフレビュー⾃動化平⽇朝⽅にCI 実⾏ 📋 チェックリスト⾃動更新過去レビューを学習指摘観点を継続改善 AI活⽤レベル1を⽀えるSkill 31

Slide 32

Slide 32 text

© Findy Inc. ➜ ⼊⼒コード変更（ローカル） Pull request作成Skill 品質チェックと同時にPR作成を⾃動化 ➜ 出⼒ PR + レビューコメント（GitHub） ✅ 品質チェック⾃動実⾏ typecheck / lint / test / build を READMEに従って実⾏ 🌿 ブランチ、コミット戦略の検証 feature / ﬁx / refactor / chore の命名と分岐を強制 🔍 セルフレビュー Skill と統合 PR 作成前にセルフレビュー → 修正コミット → 結果をコメントで⾃動投稿 📝 PR テンプレート⾃動読込 .github/PULL_REQUEST_TEMPLATE.md をもとに body を⽣成 Pull request作成 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© Findy Inc. 1 過去レビューを収集 GitHub API で直近 1 ヶ⽉のコメントを取得 2 LLM で傾向分析よくある指摘パターンを抽出‧分類 3 チェックリスト更新個⼈別 / チーム別にカスタマイズして反映 4 セルフレビューのSkillに反映 Skillの精度が継続向上 ↻ レビュアーの暗黙知が、Skillに組み込まれて形式知として継続的に改善されるチェックリスト⾃動更新 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© Findy Inc. 協働から委任へ「協働」して書くVibe Coding、「委任」して任せるAgentic Workﬂow ──── 協働から委任へ ─ スケールさせたい領域から、任せる範囲を広げていく ────▶ 観点 🤝 AI との協働 (レベル1 Vibe Coding) 🎯 AI への委任 (レベル2 Agentic Workﬂow) 関係性隣で並⾛するパートナータスクを任せる実⾏者⼈間の役割ハンドルを握る運転⼿⾏き先を決める指揮者 AI の役割助⼿席のナビゲーター⾃⾛する実⾏エージェント任せる粒度 1 ⾏〜1 関数タスク / PR / フロー全体 42

Slide 43

Slide 43 text

© Findy Inc. Agentic Workﬂow ─ 定義と4つの⾃律性⼈間がゴールと制約を与え、AIエージェントが計画‧実⾏‧⾃⼰検証までを⾃律的に進める開発スタイル 👤 ⼈間 ─ゴール＋制約 ──▶ 🤖 AIエージェント計画 → ツール実⾏ → ⾃⼰検証 ─ 成果物 ────▶ 👤 ⼈間レビュー 🎯 ゴール指向「何を」を与え、「どう実現するか」はAIが組み⽴てる 🧭 計画と分解⼤きなタスクをサブタスクに分解して順序付けて実⾏ 🛠 ツール使⽤ファイル / Skill / コマンド / 検索 / MCP を能動的に使う 🔁 ⾃⼰検証ループテスト失敗 → 修正 → 再実⾏を⾃律的に繰り返す 43

Slide 44

Slide 44 text

© Findy Inc. ターミナルへの回帰 ─ AI委任が変えた開発の作業環境 2026年〜ファインディはメインツールがIDE → ターミナルへ AI 委任の並列性が開発環境そのものを変えた ⌨ メインツールの移⾏ IDEで編集‧実⾏ ↓ ターミナルで作業（使うものは個⼈の⾃由） 🪟 並列委任の前提 1 ウインドウで1タスクずつ ↓ 複数ウインドウ‧ペインで同時にAIへ委任 🔍 IDE の役割変化すべての開発作業 ↓ 広域に渡るコードリーディング理解を深めるとき AIに並列で任せる前提に合わせて、開発環境そのものが「並列委任しやすいもの」へ変化 44

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© Findy Inc. 1 要件理解 — インタラクティブな質問で曖昧さを解消 ↓ 2 コード探索 — 並列の探索 Agent が複数観点で同時調査 ↓ 3 要件明確化 — 不⾜情報を補完しスコープを定義 ↓ 4 設計提案 — 実装⽅針のドラフトを⽣成 ↓ 5 タスク分解 — 実装単位に分解（粒度判定 Skill 連携） ↓ 6 Issue 作成 — Sub Issue / relationship を含む構造化 Issue ⚡ 4000個以上のIssueを⽣成開発Issue作成 46

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© Findy Inc. ⑤ タスク分解 51 📥 設計案（設計提案） 🧩 タスク分解 Skill PR単位に分解 🔍 タスクレビュー Agent 粒度‧独⽴性を検証 📋 確定 & 選択 Issue化対象を選ぶ ➡ ➡ ➡ ↺ 要調整なら Skill へ戻して再分解すべてのタスク = 独⽴して revert できる「完結した作業単位」 1 独⽴性チェック ❓ Task A なしで Task B は機能する？ YES → Step 2 へ NO → 同じ PR ➜ 2 完結性チェック ❓ Task A 単独で意味のある完結した機能になる？ YES → Step 3 へ NO → 同じ PR ➜ 3 revert 影響チェック ❓ Task A を revert したら Task B が壊れる？ YES → 同じ PR NO → 別 PR に分割

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© Findy Inc. 🎩 Team Lead Agent — Layer ごとに Worker を起動‧同期 🎯 親 Issue (Feature)：ユーザー通知機能の追加 ▼ Layer 0 #1 DB層通知テーブル追加 🌿 worktree-1 🤖 Worker Agent ▼ ▼ Layer 1 #2 API層 POST API 追加 🌿 worktree-2 🤖 Worker Agent #3 API層 DELETE API 追加 🌿 worktree-3 🤖 Worker Agent blocked_byに従ってLayer 単位で同期同Layer内は worktree + Agent で完全並列並列実装：Issue × Worktree × Agent ▼ ▼ ▼ ▼ 53

Slide 54

Slide 54 text

© Findy Inc. 🤖 AI に任せる ✓ コード規約‧命名 ✓ 型定義 ✓ テストコード‧テストケース 👤 ⼈間が確認する ✓ ビジネスロジックが要件をクリアするか ✓ アーキテクチャ‧データベース設計 ✓ 明確なセキュリティリスク → コードそのものから脱却視点がより抽象的にレビュー＝抽出された観点を⼈間が確認‧判断することコードレビューの再定義 54 🤖 セルフレビューをAI に任せ、"⼈間が⾒るべき観点" を抽出‧提⽰

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

© Findy Inc. 💻 システム情報 📁 リポジトリコード / アーキテクチャ実装パターン 📊 運⽤メトリクス Datadog / ログ → システムの「いま」を AI に渡せる 📦 プロダクト情報 📈 Google Analytics ユーザー⾏動 / KPI 📚 Notion 仕様 / プロダクト⽅針 🗂 各種プロダクトデータ売上 / 顧客など → プロダクトの「いま」を AI に渡せる ✨ 「数値を⾒ながら AI と壁打ち」が標準動作にシステム & プロダクトの現状把握 62

Slide 63

Slide 63 text

© Findy Inc. 要件定義の出発点は「現状把握」広い範囲のコンテキストを必要な分だけ収集する 💻 コードベースリポジトリの構造実装制約‧パターン 📊 Google Analytics ユーザー⾏動離脱率‧遷移パターン 📚 プロダクト⽂書 KPI 定義 / ポリシー Notion‧docs/ 🐙 GitHub Issues / PR 過去の議論‧経緯類似施策の結果 🔍 Datadog 運⽤メトリクス障害‧パフォーマンス 💼 各種指標顧客‧売上‧KPIデータビジネス指標専⾨Agentチームが、各ソースから「必要な分だけ」を⾃動収集現状把握 63 各観点の専⾨家が並列で動くことで、要件定義の質と速度を両⽴ Agent Teamsを使い、お互いが会話できる

Slide 64

Slide 64 text

© Findy Inc. 要件Issueを作成し、そのまま実装へ 64 🔍 複数視点で並列チェック価値‧論理‧充⾜度を 5観点で同時に検証 📋 MVP / エンハンスに分割要件Issueを分けて作成 🤖 開発Issue作成スキルへそのまま連携できる ➡ ➡ 🎯 親Issue （施策全体） ➡ 🚀 MVP Issue ✨ エンハンスIssue① ✨ エンハンスIssue② 🔀 要件定義で作ったIssueは、そのまま開発Issue作成スキルへ → タスク分解‧⼦Issue化まで、要件から実装まで⼀気通貫

Slide 65

Slide 65 text

© Findy Inc. ➜ ➜ ➜ 🤔 従来の認識 × ユーザビリティ × アクセシビリティ × UI / UX これらのテストは AI 単独では難しい → 「QA は AI で代替しづらい」 💡 ファインディの仮説 ✓ 「代替」ではなく「⽀援」する ✓ AI が QA エンジニアの判断を最⼤化する形 → ⼈間 × AI の協働モデル 🔧 AI ⽀援の 4 ステップ 📥 仕様の⾃動構造化 🔍 観点抽出 📋 テストケース⽣成 🎭 ⾃動実⾏ QA領域への挑戦：「代替」ではなく「⽀援」 65

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

© Findy Inc. 🤖 ⾃動実⾏できる ✓ 機能要件 / 画⾯操作で確認 ✓ 画⾯ポチポチで再現できる検証 → Playwright で⾃動実⾏ 👤 ⼈間が確認する ✓ UI / UX‧操作感 ✓ アクセシビリティ等の⾮機能 ✓ ⾃動で完全網羅が難しい領域 → ⼈間がチェックする項⽬としてテストケースを作成 → AIに任せる領域と⼈間が責任を持つ領域を分けて運⽤ QAテストケースを "⾃動 / ⼈間" で分けて⽣成 69 🤖 ⾃動でチェックできる項⽬と 👤 ⼈間が確認すべき項⽬を、分けて抽出する

Slide 70

Slide 70 text

Slide 71

Slide 71 text

© Findy Inc. 😩 Before：⼿動 QA × 同じケースを毎回⼿で繰り返す × 退⾏テストに時間が取られ新規ケースの検証が遅延 × ヒューマンエラー、再現できないバグ × ⼯数が機能数に⽐例して膨らむ 🤖 After：AI ⽀援 QA ✓ 反復可能なケースはAI が淡々と実⾏ ✓ 同じテストを何度でも再現可能 ✓ スクショ付きレポート ✓ ⼈間は「判断が必要な領域」に集中 🎯 ⼈間が集中すべき：ユーザビリティ評価 / 例外シナリオ / クライアント要件確認 QA⾃動実⾏Skill 71 🎭 Playwright MCP を介して、Claude Code から直接ブラウザを操作

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

© Findy Inc. ⚠ ⼟台が弱いと、ガードレールもAIも成果を出せない 4. 🤖 AI Skill / Plugin 横展開 — 組織全体で AI 活⽤を加速させる 3. 🛡 ガードレール‧ハーネス整備 — AI が出⼒するコードのガードを敷く（README / AGENT.md / rules / 規約） 2. 🌿 PR 粒度‧レビュー⽂化 — 開発⽂化を育てる 1. ✅ コード品質‧テストコード — 統⼀規約 / 型定義 / テストコード — まずここを充実させる 💡 順番を間違えない：基本が固まってからAI活⽤を載せる ⚠ 順番を間違えない：基本が先、AI活⽤は後 74

Slide 75

Slide 75 text

© Findy Inc. 🧭 ⼈間の役割が上流へコードの読み書きから何をどう作るかの判断へ変化より抽象的で上流の仕事に集中 🌱 やるべきことは変わらない統⼀規約 / コード品質 / テストコード PR 粒度 / レビュー / ⽂化 AI時代の本丸は「速く作る」ではなく「正しく作る」「必要なものを作る」への段階的越境まとめ 75 基本の徹底こそがAI活⽤の⼤前提基本の⼟台の上に、段階を踏んでAI活⽤を進めることが⼤事

Slide 76

Slide 76 text