生成AI導入の「期待外れ」を乗り越えるー開発フロー改革が目指す、真の組織変革

Embed

Start on current slide

Slide 1

Slide 1 text

2026.07.23 AI DevEx Conference 2026 ⽣成AI導⼊の「期待外れ」を乗り越えるー開発フロー改⾰が⽬指す、真の組織変⾰ファインディ株式会社プリンシパルエンジニア⼾⽥千隼 @starﬁsh0206 © Findy Inc. 1

Slide 2

Slide 2 text

本⽇の内容 ● ● ● ● ● AI導⼊の「落とし⽳」開発フロー改⾰ AI推進可視化と改善のサイクルで真の組織変⾰へまとめ © Findy Inc. 2

Slide 3

Slide 3 text

⼼当たりありませんか？ 🎲 活⽤レベルの個⼈差 🔍 AIエージェントの使いこなし度にメンバー間で⼤きなばらつき特にジュニアほど使えていない 📉 AIを使えば開発が速くなる？実際は⾔うほど変わっていない AI出⼒の合否判断ができない理解せずに AI の出⼒をそのままレビューに回している 😩 AI推進の役割 AI推進って⾔っても何をしたらいいのかわからない © Findy Inc. 3

Slide 4

Slide 4 text

AI導⼊の「落とし⽳」 © Findy Inc. 4

Slide 5

Slide 5 text

Pull requestの量は増えたように感じたが 😊 現場の体感 🤔 でも実は… ✓ AI導⼊後、効率が上がったように感じた × リリースや価値提供は増えていない ✓ 開発スピード感は上がっているはず × アウトプットもアウトカムも本当に増えている？ → 体感と現実がズレているのでは？各種メトリクスの計測結果から深堀って原因を探す © Findy Inc. 5

Slide 6

Slide 6 text

可視化軸ツール何を⾒るか開発⽣産性 Findy Team+ 開発組織の健康状態‧ボトルネックの場所 AI活⽤ Findy AI+ 誰が/どこで/どうAIを使っているか © Findy Inc. 6

Slide 7

Slide 7 text

可視化① Findy Team+（開発⽣産性）指標中⾝ Four Keys デプロイ頻度∕変更リードタイム∕変更失敗率∕復旧時間サイクルタイムコミット→オープン→レビュー→マージの各区間で掛かった時間各種メトリクス Pull requestの作成数、コメント数、Issue数 etc → どこに問題があるのか、事実ベースで捉える © Findy Inc. 7

Slide 8

Slide 8 text

全体のPull request作成数 © Findy Inc. 8

Slide 9

Slide 9 text

1⼈あたりのPull request作成数 © Findy Inc. 9

Slide 10

Slide 10 text

各種メトリクス⽐較 © Findy Inc. 10

Slide 11

Slide 11 text

ファインディで実際に起きていたこと計測したら、AIを導⼊しても⽣産性は変わらなかった 👥 コミットからオープンまでの平均時間 -10% ⏱ レビュー→Approve時間 +50% 📦 1⼈あたりPR作成数横ばい 💬 平均コメント数 +30% © Findy Inc. 11

Slide 12

Slide 12 text

可視化② Findy AI+（AI活⽤の可視化）⾒る観点内容活⽤の広がり利⽤率‧頻度‧どのフローで使っているか使い⽅の偏り⼀部の⼈だけ∕特定⼯程に偏っていないかメトリクスと突合⽣産性指標と照合し"効いた活⽤"を⾒極める → AI活⽤の現状から打ち⼿を考える © Findy Inc. 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

数値からわかった「AIに使われている」 ⚡ AIが速くしたのは「コード⽣成」の⼀⼯程だけ → ボトルネックが別の⼯程に移っただけ ⚡ コードを書く 🔴 新たなボトルネック AIで⼀気に⾼速化開発全体のスループットは横ばい A作業を⾃動化しただけではAIによる恩恵を受けることができない © Findy Inc. 14

Slide 15

Slide 15 text

開発フロー改⾰ © Findy Inc. 15

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

AIは増幅器である⼟台が無いと増幅される弱さ規約がない⽣成されるコードの出⼒内容がバラつくテストがない安全性を担保できず、不具合や障害が増えるタスクの粒度が荒い巨⼤PRを量産し、レビューが破綻する → AIは⽣産性も負債も増幅する。だからレベルを追う前に「⼟台」から © Findy Inc. 17

Slide 18

Slide 18 text

AI活⽤レベルで「現在地」を捉えるレベル1 レベル2 レベル3 「速く作る」「正しく作る」「必要なものを作る」コード⽣成の⾃動化モノ作り全体の再設計他領域への越境⾃分たちの現状がどのレベルなのかを⾒極める © Findy Inc. 18

Slide 19

Slide 19 text

AI活⽤レベル1: AIエージェントでコード⽣成 VibeCodingでコード⽣成して、Pull requestを作成してレビュー依頼を投げる 📍 🤖 👤 対象⼯程 AIの役割⼈間の役割コード変更‧PR作成セルフレビューコード⽣成〜PR作成〜セルフレビューを実⾏コード⽣成のハンドリングセルフレビュー結果の判断 © Findy Inc. 19

Slide 20

Slide 20 text

AI活⽤レベル2: AIエージェントでモノを作る正しい⽅法と⼿順を⽤意して、AgenticWorkﬂowに委任する 📍 🤖 👤 対象⼯程 AIの役割⼈間の役割タスク分解‧Issue作成レビュータスク分解‧構造化Issue 並列実装‧レビュー観点の抽出タスクとIssueの⽅向性を決定レビュー © Findy Inc. 20

Slide 21

Slide 21 text

AI活⽤レベル3: AIで価値を⽣み出す必要なモノを作る 📍 🤖 👤 対象⼯程 AIの役割⼈間の役割要件定義‧QA エンジニアリングからの越境現状把握‧要件構造化 QA観点/実⾏を⽀援何を作るかの意思決定品質の最終保証 © Findy Inc. 21

Slide 22

Slide 22 text

ロードマップ AIがサポート出来る AIエージェントコード変更要件定義タスク分解 Issue作成 Pull request 作成 AIで代替できるセルフレビュー AIで代替しづらいマージレビュー QA リリース © Findy Inc. 22

Slide 23

Slide 23 text

ロードマップ ①AIエージェントでコード⽣成 AIがサポート出来る AIエージェントコード変更要件定義タスク分解 Issue作成 Pull request 作成 AIで代替できるセルフレビュー AIで代替しづらいマージレビュー QA リリース © Findy Inc. 23

Slide 24

Slide 24 text

ロードマップ ②AIエージェントでモノを作る ①AIエージェントでコード⽣成 AIがサポート出来る AIエージェントコード変更要件定義タスク分解 Issue作成 Pull request 作成 AIで代替できるセルフレビュー AIで代替しづらいマージレビュー QA リリース © Findy Inc. 24

Slide 25

Slide 25 text

ロードマップ ③AIで価値を⽣み出す ②AIエージェントでモノを作る ①AIエージェントでコード⽣成 AIがサポート出来る AIエージェントコード変更要件定義タスク分解 Issue作成 Pull request 作成 AIで代替できるセルフレビュー AIで代替しづらいマージレビュー QA リリース © Findy Inc. 25

Slide 26

Slide 26 text

AI活⽤レベル1 AIエージェントでコード⽣成 © Findy Inc. 26

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

AI活⽤レベル2 AIエージェントでモノを作る © Findy Inc. 30

Slide 31

Slide 31 text

「正しく作る」フェーズと現状課題 ⚠ 課題：要件を実現する⼿順がAIフレンドリーではない ❓ 実現⽅法がわからないタスクの粒度や⼿順を誰も決めていない 📭 依頼内容を作れない⽣成 AI へ何を渡せば精度よく動くかが属⼈化している 💡 明確で簡潔なステップ構造 = AI に渡す「設計図」が必要 © Findy Inc. 31

Slide 32

Slide 32 text

「正しく作る」フェーズ 🎯 レベル2の⽬的：AIに「正しく作らせる」仕組みを整える 🧩 📝 🔍 タスク分解 Issue 作成コードレビューの再定義 AIが処理しやすい単位に分割する構造化された設計図を親⼦Issueで表現 AIと⼈間でレビュー領域を分割 © Findy Inc. 32

Slide 33

Slide 33 text

「どうやって作るか」を AI に渡す 💭 作りたいもの (Why / What) ➜ 🛠 作り⽅の設計図 (How) タスク分解で表現 ➜ 🤖 AI が実装ステップ通りに⽣成 ↻ 🔎 レビュー：作り⽅と実現⽅法が合っているかを検証 → 設計図にフィードバック ✨ タスク分解の品質が、そのままアウトプットの品質を決める © Findy Inc. 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

AI活⽤レベル3 AIで価値を⽣み出す © Findy Inc. 37

Slide 38

Slide 38 text

「必要なものを作る」フェーズと現状課題 ⚠ 「速く正しく作る」をクリアすると上流⼯程が詰まる 🔍 要件の実現可能性の調査がエンジニアだけ PdM がシステムを把握できれば、施策作成までのスピードは上がる ↔ システムとプロダクトの概念が離れているお互いを知らない状態で施策や検証が進む何を作るかが決まらないと、開発スピードを活かせない © Findy Inc. 38

Slide 39

Slide 39 text

「必要なものを作る」フェーズ 🎯 レベル3の⽬的：AIで価値を⽣み出すところまで踏み込む 📋 ✅ 要件定義 → PdM領域への越境 QA 領域への挑戦エンジニアリングのスピードをプロダクト企画にまで広げる「AI で代替しづらい」とされた品質保証も AI ⽀援で進めるエンジニアリングの越境がレベル3の鍵 © Findy Inc. 39

Slide 40

Slide 40 text

「現状把握」が出発点 🧭 システム + プロダクトの現状把握 🔎 現状把握システムとプロダクトの両⽅を計測 / 取得 ➜ 🛠 現状から何がどう変わるか施策を検討 ➜ 🚀 価値提供 PDCA 実装 → 検証 → 計測再現性⾼く回す © Findy Inc. 40

Slide 41

Slide 41 text

AI推進 © Findy Inc. 41

Slide 42

Slide 42 text

兼務の限界 ① 物量 ② 兼務 ③ オーナー不在 AI アップデートが毎週次々と発⽣検証 / 展開 / 教育が同時並⾏で発⽣誰が責任を持つか曖昧なまま進⾏⽚⼿間ではキャッチアップが追いつかない兼務だと優先度が下がる悪循環に社内展開が遅れやがて使われなくなる → 物量的に⽇々の業務との両⽴は不可能。組織構造を変える決断が必要 © Findy Inc. 42

Slide 43

Slide 43 text

下した決断 ❌ Before：兼務 5 ⼈ × 20% 20% 20% 20% 20% 20% ⭕ After：専任 1 ⼈ × 100% 100% オーナー不明 / 優先度低下情報集約‧展開が分散して遅い AI推進専任のポジション情報集約‧検証‧展開を⼀気通貫 📊 専任化の前後でFindy Team+ で計測すると、AI推進のアクティビティが 10倍以上に同じ⼈⽉でも、構造を変えるだけで施策の速度は劇的に変わる © Findy Inc. 43

Slide 44

Slide 44 text

AI推進に求める⼈物像 🌐 幅広い知識 🔥 AIへの熱量ジェネラリスト三度の飯よりAIが好き特定領域の専⾨家より、広く全体を掴む誰よりAIを触り、追い続けられる 🚀 推進⼒ 🌟 影響⼒やり切る⾃ら動かし、定着までやり切る巻き込む周囲を動かし、全社に広げる幅広い知識 × AIへの愛 × 推進⼒ × 影響⼒が、組織を動かす © Findy Inc. 44

Slide 45

Slide 45 text

可視化は「内製」から⽣まれた再現性⾼く改善のサイクルを回すために可視化は「必要不可⽋」 Findy AI+ の可視化機能 ⟳ 改善のサイクル ⟳ 改善のサイクルファインディの内製ツール内製ツールを⼟台に、改善のサイクルが積み重なって Findy AI+ の可視化機能になった © Findy Inc. 45

Slide 46

Slide 46 text

Plugin で簡単展開 📦 👥 Plugin Repository 全メンバー Skill / Sub Agent / MCP を 1 リポジトリで管理 /plugin install でワンコマンド配布∕更新全員がcontributeできる改善が組織全体に即反映 © Findy Inc. 46

Slide 47

Slide 47 text

浸透させる仕組み 🔔 📣 アップデートを⾃動通知⽉1のエンジニア定例前⽇マージのPRをサマリして Slackに⾃動で通知全社へAI推進の活動を定期的にアナウンス作って終わりでは、やがて使われなくなる → 「浸透」させ続けることが重要 © Findy Inc. 47

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

AI推進のサイクル ① 可視化 ② 配布可視化からの気づき Claude Code Plugins で全社に⼀⻫配布気づきをSkill化 SkillやAgentを組織共通資産に ③ 浸透アプデ内容の共有育成 AI利⽤を当たり前に「可視化 → 配布 → 浸透」をワンサイクルとして回し続ける © Findy Inc. 52

Slide 53

Slide 53 text

Slide 54

Slide 54 text

再現性は「数字を読み解く」で決まる PDCAの P（計画）と C（評価）の両⽅で「可視化して数字を読み解く」ことが必要 📊P D 📊C A 計画‧仮説実⾏評価改善アクション読み解く精度で仮説（P）も評価（C）も変わり、再現性を左右する → 再現性⾼く回すには、可視化から数字を読み解くことが必要不可⽋ © Findy Inc. 54

Slide 55

Slide 55 text

ファインディで実際に起きていたこと計測したら、AIを導⼊しても⽣産性は変わらなかった 👥 コミットからオープンまでの平均時間 📦 1⼈あたりPR作成数 -10% 横ばいコードを書く速度は上がった１⼈あたりのアウトプット量は変化なし ⏱ レビュー→Approve時間 💬 平均コメント数 +50% レビューからのやり取り +30% 指摘量が増加コード⽣成は速くなったが、レビュー⼯程で詰まっている？ © Findy Inc. 55

Slide 56

Slide 56 text

セルフレビュー：6 観点並列分析 🔒 セキュリティ ✨ コード品質 📐 規約準拠 ▼ ▼ ▼ Pull request ▼ ▼ ▼ 🧹 simplify観点 🎯 要件検証 ☑ チェックリスト照合 → 複数エージェントが並列で動き、信頼度の⼀定以上の指摘のみ報告 ⚡ 実績：2000以上のPRで運⽤中（2026年5⽉時点） © Findy Inc. 56

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

1⼈あたりPR作成数が1.5倍に測って改善を回し続けた結果 🚀 1⼈あたりのPR作成数約1.5倍 ✅ レビュー指摘数横ばい質を維持したまま量を増やした ⏱ レビュー→Approve時間横ばい 💬 平均コメント数横ばいプルリクエストの質を落とさず、数を増やすことに成功各種リードタイムと向き合うのが、次の改善のサイクル © Findy Inc. 62

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

まとめ 🏗 基本の徹底が重要 🎯 兼務ではなく専任⼟台と改善を段階的に積み重ねて、基礎を固めることで、初めてAIは効果を発揮する通常業務とAI推進の兼務は不可能 AI推進専⾨ポジションが必要 📈 組織全体でContribute 🔍 可視化は必要不可⽋ AI推進が全部やるのではなく、組織全体で改善できる仕組み作り再現性⾼く改善のサイクルを回し続けるために可視化は必要不可⽋「これで⽣産性が⼀気に上がる」という決定打は無く、⼩さいことの積み重ねの結果⽬の前の課題と向き合い続ける姿勢が、AI推進が⾒せるべき姿であり、その先に真の組織改⾰がある © Findy Inc. 66