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

Transcript

1. 2026.07.23 AI DevEx Conference 2026 ⽣成AI導⼊の「期待外れ」を乗り越える ー 開発フロー改⾰が⽬指す、真の組織変⾰ ファインディ株式会社 プリンシパルエンジニア ⼾⽥ 千隼 @starfish0206 © Findy Inc. 1
2. 本⽇の内容 • • • • • AI導⼊の「落とし⽳」 開発フロー改⾰ AI推進 可視化と改善のサイクルで真の組織変⾰へ まとめ © Findy Inc. 2
3. ⼼当たりありませんか？ 🎲 活⽤レベルの個⼈差 🔍 AIエージェントの使いこなし度に メンバー間で⼤きなばらつき 特にジュニアほど使えていない 📉 AIを使えば開発が速くなる？ 実際は⾔うほど変わっていない AI出⼒の合否判断ができない 理解せずに AI の出⼒を そのままレビューに回している 😩 AI推進の役割 AI推進って⾔っても何をしたらいいのか わからない © Findy Inc. 3
4. AI導⼊の「落とし⽳」 © Findy Inc. 4
5. Pull requestの量は増えたように感じたが 😊 現場の体感 🤔 でも実は… ✓ AI導⼊後、効率が上がったように感じた × リリースや価値提供は増えていない ✓ 開発スピード感は上がっているはず × アウトプットもアウトカムも 本当に増えている？ → 体感と現実がズレているのでは？ 各種メトリクスの計測結果から深堀って原因を探す © Findy Inc. 5
6. 可視化 軸 ツール 何を⾒るか 開発⽣産性 Findy Team+ 開発組織の健康状態‧ボトルネックの場所 AI活⽤ Findy AI+ 誰が/どこで/どうAIを使っているか © Findy Inc. 6
7. 可視化① Findy Team+（開発⽣産性） 指標 中⾝ Four Keys デプロイ頻度∕変更リードタイム∕変更失敗率∕復旧時間 サイクルタイム コミット→オープン→レビュー→マージの各区間で掛かった時間 各種メトリクス Pull requestの作成数、コメント数、Issue数 etc → どこに問題があるのか、事実ベースで捉える © Findy Inc. 7
8. 全体のPull request作成数 © Findy Inc. 8
9. 1⼈あたりのPull request作成数 © Findy Inc. 9
10. 各種メトリクス⽐較 © Findy Inc. 10
11. ファインディで実際に起きていたこと 計測したら、AIを導⼊しても⽣産性は変わらなかった 👥 コミットからオープンまでの平均時間 -10% ⏱ レビュー→Approve時間 +50% 📦 1⼈あたりPR作成数 横ばい 💬 平均コメント数 +30% © Findy Inc. 11
12. 可視化② Findy AI+（AI活⽤の可視化） ⾒る観点 内容 活⽤の広がり 利⽤率‧頻度‧どのフローで使っているか 使い⽅の偏り ⼀部の⼈だけ∕特定⼯程に偏っていないか メトリクスと突合 ⽣産性指標と照合し"効いた活⽤"を⾒極める → AI活⽤の現状から打ち⼿を考える © Findy Inc. 12
13. © Findy Inc. 13
14. 数値からわかった「AIに使われている」 ⚡ AIが速くしたのは「コード⽣成」の⼀⼯程だけ → ボトルネックが別の⼯程に移っただけ ⚡ コードを書く 🔴 新たなボトルネック AIで⼀気に⾼速化 開発全体の スループットは横ばい A作業を⾃動化しただけではAIによる恩恵を受けることができない © Findy Inc. 14
15. 開発フロー改⾰ © Findy Inc. 15
16. 前提 ✅ コード設計‧規約‧テストコード • アーキテクチャ‧命名規則‧型定義 • ⼗分なテストカバレッジ • ⼀貫した設計パターン → AI 以前から、品質を保つには必須 🌿 開発⽂化（プロセス） • Pull requestの粒度 • レビュー⽂化 • タスク分解の習慣 • etc → AI 以前から、開発を回すには必須 🏗 AIを活⽤する前に、これらはAI関係なく重要 © Findy Inc. 16
17. AIは増幅器である ⼟台が無いと 増幅される弱さ 規約がない ⽣成されるコードの出⼒内容がバラつく テストがない 安全性を担保できず、不具合や障害が増える タスクの粒度が荒い 巨⼤PRを量産し、レビューが破綻する → AIは⽣産性も負債も増幅する。だからレベルを追う前に「⼟台」から © Findy Inc. 17
18. AI活⽤レベルで「現在地」を捉える レベル1 レベル2 レベル3 「速く作る」 「正しく作る」 「必要なものを作る」 コード⽣成の⾃動化 モノ作り全体の再設計 他領域への越境 ⾃分たちの現状がどのレベルなのかを⾒極める © Findy Inc. 18
19. AI活⽤レベル1: AIエージェントでコード⽣成 VibeCodingでコード⽣成して、Pull requestを作成してレビュー依頼を投げる 📍 🤖 👤 対象⼯程 AIの役割 ⼈間の役割 コード変更‧PR作成 セルフレビュー コード⽣成〜PR作成〜 セルフレビューを実⾏ コード⽣成のハンドリング セルフレビュー結果の判断 © Findy Inc. 19
20. AI活⽤レベル2: AIエージェントでモノを作る 正しい⽅法と⼿順を⽤意して、AgenticWorkflowに委任する 📍 🤖 👤 対象⼯程 AIの役割 ⼈間の役割 タスク分解‧Issue作成 レビュー タスク分解‧構造化Issue 並列実装‧レビュー観点の抽出 タスクとIssueの⽅向性を決定 レビュー © Findy Inc. 20
21. AI活⽤レベル3: AIで価値を⽣み出す 必要なモノを作る 📍 🤖 👤 対象⼯程 AIの役割 ⼈間の役割 要件定義‧QA エンジニアリングからの越境 現状把握‧要件構造化 QA観点/実⾏を⽀援 何を作るかの意思決定 品質の最終保証 © Findy Inc. 21
22. ロードマップ AIがサポート出来る AIエージェント コード変更 要件定義 タスク分解 Issue作成 Pull request 作成 AIで代替できる セルフ レビュー AIで代替しづらい マージ レビュー QA リリース © Findy Inc. 22
23. ロードマップ ①AIエージェントでコード⽣成 AIがサポート出来る AIエージェント コード変更 要件定義 タスク分解 Issue作成 Pull request 作成 AIで代替できる セルフ レビュー AIで代替しづらい マージ レビュー QA リリース © Findy Inc. 23
24. ロードマップ ②AIエージェントでモノを作る ①AIエージェントでコード⽣成 AIがサポート出来る AIエージェント コード変更 要件定義 タスク分解 Issue作成 Pull request 作成 AIで代替できる セルフ レビュー AIで代替しづらい マージ レビュー QA リリース © Findy Inc. 24
25. ロードマップ ③AIで価値を⽣み出す ②AIエージェントでモノを作る ①AIエージェントでコード⽣成 AIがサポート出来る AIエージェント コード変更 要件定義 タスク分解 Issue作成 Pull request 作成 AIで代替できる セルフ レビュー AIで代替しづらい マージ レビュー QA リリース © Findy Inc. 25
26. AI活⽤レベル1 AIエージェントでコード⽣成 © Findy Inc. 26
27. 「速く作る」フェーズと現状課題 ⚡ レベル1の⽬的：コード変更 + Pull request作成をAIで⾃動化 ⚠ 現場で起きている課題 🎲 🔍 活⽤レベルの個⼈差 若⼿ほど使えていない∕メンバー間でばらつき⼤ 📉 理解せずにAI出⼒をレビュー依頼 😩 Pull requestの質が低下 リードクラスのレビュー負担が増加 AI出⼒の合否判断ができない 「AI に使われている」状態 AI主導になり、⼈間側の理解が追いつかない 理解と責任の所在を再設計する必要がある © Findy Inc. 27
28. AIが出⼒したコードの責任は「⼈間」にある 🛡 ⾃動化されても、品質と判断の最終責任は⼈間が引き受ける ⼯程 担当 責任の対象 コード変更 🤖 AI コード変更 Pull request作成 🤖 AI コード変更 セルフレビュー 🤖 AI コード変更 レビュー 👤 ⼈間 作っているモノ レビュー依頼を出すまでがPull request作成 セルフレビューはレビュー依頼を出す前に⾏うべき © Findy Inc. 28
29. AIのガードレール整備 AI が参照するドキュメント‧ルールを整える 📘 📐 📋 README / プロジェクトドキュメント AGENT.md / rules カスタムコマンド / プロンプトのテンプレ 🛠 やること 🛠 やること 🛠 やること 前提‧運⽤ルールなどを記述 コード規約‧命名規則‧ テスト⽅針をAIが参照 依頼タスクの規格化 （よくある作業をコマンド化） ✨ 効果 ✨ 効果 ✨ 効果 AIが⽂脈を理解 初期質問の往復が減る 出⼒されるコードの ⼀貫性が担保される 同じ品質のアウトプットが 繰り返し得られる ガードレールがあって初めて、AIが「使い物になるコード」を出す © Findy Inc. 29
30. AI活⽤レベル2 AIエージェントでモノを作る © Findy Inc. 30
31. 「正しく作る」フェーズと現状課題 ⚠ 課題：要件を実現する⼿順がAIフレンドリーではない ❓ 実現⽅法がわからない タスクの粒度や⼿順を 誰も決めていない 📭 依頼内容を作れない ⽣成 AI へ何を渡せば 精度よく動くかが 属⼈化している 💡 明確で簡潔なステップ構造 = AI に渡す「設計図」が必要 © Findy Inc. 31
32. 「正しく作る」フェーズ 🎯 レベル2の⽬的：AIに「正しく作らせる」仕組みを整える 🧩 📝 🔍 タスク分解 Issue 作成 コードレビューの再定義 AIが処理しやすい 単位に分割する 構造化された設計図を 親⼦Issueで表現 AIと⼈間で レビュー領域を分割 © Findy Inc. 32
33. 「どうやって作るか」を AI に渡す 💭 作りたいもの (Why / What) ➜ 🛠 作り⽅の設計図 (How) タスク分解で表現 ➜ 🤖 AI が実装 ステップ通りに ⽣成 ↻ 🔎 レビュー：作り⽅と実現⽅法が合っているかを検証 → 設計図にフィードバック ✨ タスク分解の品質が、そのままアウトプットの品質を決める © Findy Inc. 33
34. 協働から委任 へ 「協働」 して書くVibe Coding、「委任」 して任せるAgentic Workflow 観点 🤝 AI との協働 (レベル1 Vibe Coding) 🎯 AI への委任 (レベル2 Agentic Workflow) 関係性 隣で並⾛するパートナー タスクを任せる実⾏者 ⼈間の役割 ハンドルを握る運転⼿ ⾏き先を決める指揮者 AI の役割 助⼿席のナビゲーター ⾃⾛する実⾏エージェント 任せる粒度 1 ⾏〜1 関数 タスク / PR / フロー全体 ──── 協働 から 委任 へ ─ スケールさせたい領域から、任せる範囲を広げていく ────▶ © Findy Inc. 34
35. Agentic Workflow ─ 定義と4つの⾃律性 ⼈間がゴールと制約を与え、AIエージェントが計画‧実⾏‧⾃⼰検証までを⾃律的に進める開発スタイル 👤 ⼈間 ─ゴール ＋ 制約 ──▶ 🤖 AIエージェント 計画 → ツール実⾏ → ⾃⼰検証 ─ 成果物 ────▶ 👤 ⼈間レビュー 🎯 ゴール指向 🧭 計画と分解 「何を」を与え、「どう実現するか」はAIが組み⽴てる ⼤きなタスクをサブタスクに分解して順序付けて実⾏ 🛠 ツール使⽤ 🔁 ⾃⼰検証ループ ファイル / Skill / コマンド / 検索 / MCP を能動的に使う テスト失敗 → 修正 → 再実⾏ を⾃律的に繰り返す © Findy Inc. 35
36. ターミナルへの回帰 ─ AI委任が変えた開発の作業環境 2026年〜 ファインディはメインツールがIDE → ターミナルへ AI 委任の並列性が開発環境そのものを変えた ⌨ メインツールの移⾏ 🪟 並列委任の前提 🔍 IDE の役割変化 IDEで編集‧実⾏ ↓ 1 ウインドウで1タスクずつ ↓ すべての開発作業 ↓ ターミナルで作業 （使うものは個⼈の⾃由） 複数ウインドウ‧ペインで 同時にAIへ委任 広域に渡るコードリーディング 理解を深めるとき AIに並列で任せる前提に合わせて、開発環境そのものが「並列委任しやすいもの」 へ変化 © Findy Inc. 36
37. AI活⽤レベル3 AIで価値を⽣み出す © Findy Inc. 37
38. 「必要なものを作る」フェーズと現状課題 ⚠ 「速く正しく作る」をクリアすると上流⼯程が詰まる 🔍 要件の実現可能性の調査が エンジニアだけ PdM がシステムを把握できれば、 施策作成までのスピードは上がる ↔ システムとプロダクトの 概念が離れている お互いを知らない状態で 施策や検証が進む 何を作るかが決まらないと、開発スピードを活かせない © Findy Inc. 38
39. 「必要なものを作る」フェーズ 🎯 レベル3の⽬的：AIで価値を⽣み出すところまで踏み込む 📋 ✅ 要件定義 → PdM領域への越境 QA 領域への挑戦 エンジニアリングのスピードを プロダクト企画にまで広げる 「AI で代替しづらい」とされた 品質保証も AI ⽀援で進める エンジニアリングの越境がレベル3の鍵 © Findy Inc. 39
40. 「現状把握」が出発点 🧭 システム + プロダクトの 現状把握 🔎 現状把握 システムと プロダクトの両⽅を 計測 / 取得 ➜ 🛠 現状から何がどう変わるか 施策を検討 ➜ 🚀 価値提供 PDCA 実装 → 検証 → 計測 再現性⾼く回す © Findy Inc. 40
41. AI推進 © Findy Inc. 41
42. 兼務の限界 ① 物量 ② 兼務 ③ オーナー不在 AI アップデートが 毎週次々と発⽣ 検証 / 展開 / 教育が 同時並⾏で発⽣ 誰が責任を持つか 曖昧なまま進⾏ ⽚⼿間ではキャッチ アップが追いつかない 兼務だと優先度が 下がる悪循環に 社内展開が遅れ やがて使われなくなる → 物量的に⽇々の業務との両⽴は不可能。組織構造を変える決断が必要 © Findy Inc. 42
43. 下した決断 ❌ Before：兼務 5 ⼈ × 20% 20% 20% 20% 20% 20% ⭕ After：専任 1 ⼈ × 100% 100% オーナー不明 / 優先度低下 情報集約‧展開が分散して遅い AI推進専任のポジション 情報集約‧検証‧展開を⼀気通貫 📊 専任化の前後でFindy Team+ で計測すると、AI推進のアクティビティが 10倍以上 に 同じ⼈⽉でも、構造を変えるだけで施策の速度は劇的に変わる © Findy Inc. 43
44. AI推進に求める⼈物像 🌐 幅広い知識 🔥 AIへの熱量 ジェネラリスト 三度の飯よりAIが好き 特定領域の専⾨家より、広く全体を掴む 誰よりAIを触り、追い続けられる 🚀 推進⼒ 🌟 影響⼒ やり切る ⾃ら動かし、定着までやり切る 巻き込む 周囲を動かし、全社に広げる 幅広い知識 × AIへの愛 × 推進⼒ × 影響⼒ が、組織を動かす © Findy Inc. 44
45. 可視化は「内製」から⽣まれた 再現性⾼く改善のサイクルを回すために 可視化は「必要不可⽋」 Findy AI+ の可視化機能 ⟳ 改善のサイクル ⟳ 改善のサイクル ファインディの内製ツール 内製ツールを⼟台に、改善のサイクルが積み重なって Findy AI+ の可視化機能になった © Findy Inc. 45
46. Plugin で簡単展開 📦 👥 Plugin Repository 全メンバー Skill / Sub Agent / MCP を 1 リポジトリで管理 /plugin install で ワンコマンド配布∕更新 全員がcontributeできる 改善が組織全体に即反映 © Findy Inc. 46
47. 浸透させる仕組み 🔔 📣 アップデートを⾃動通知 ⽉1のエンジニア定例 前⽇マージのPRをサマリして Slackに⾃動で通知 全社へAI推進の活動を 定期的にアナウンス 作って終わりでは、やがて使われなくなる → 「浸透」させ続けることが重要 © Findy Inc. 47
48. 育成 👥 💬 📚 ペアプロ 画⾯垂れ流し 基礎⼒ © Findy Inc. 48
49. VibeCodingペアプロ 👥 🎯 📈 やること ねらい 効果 若⼿とAI対話でペア実装 当て⽅‧使い⽅を体得 若⼿の底上げに直結 「使い⽅」は教えるより、⼀緒に⼿を動かす⽅が早い © Findy Inc. 49
50. AI活⽤を画⾯共有で「垂れ流し」 🖥 🎯 📈 やること ねらい 効果 画⾯をライブ共有 ⽣の使い⽅を⾒て学ぶ 利活⽤の解像度が上がる 背中を⾒せる ― ⼀番のリアル教材は「実際の使い⽅」 © Findy Inc. 50
51. 基礎⼒強化 📚 🎯 📈 やること ねらい 効果 資格取得を推奨‧⽀援 基礎固め AI出⼒の合否を判断 ソフトウェアエンジニアリングやコンピューターサイエンスの知識が重要 基礎⼒はAI時代の最も協⼒な武器の1つ © Findy Inc. 51
52. AI推進のサイクル ① 可視化 ② 配布 可視化からの気づき Claude Code Plugins で全社に⼀⻫配布 気づきをSkill化 SkillやAgentを 組織共通資産に ③ 浸透 アプデ内容の共有 育成 AI利⽤を当たり前に 「可視化 → 配布 → 浸透」をワンサイクルとして回し続ける © Findy Inc. 52
53. 再現性⾼く 可視化と改善のサイクルを回し続ける © Findy Inc. 53
54. 再現性は「数字を読み解く」で決まる PDCAの P（計画）と C（評価）の両⽅で「可視化して数字を読み解く」ことが必要 📊P D 📊C A 計画‧仮説 実⾏ 評価 改善アクション 読み解く精度で仮説（P）も評価（C）も変わり、再現性を左右する → 再現性⾼く回すには、可視化から数字を読み解くことが必要不可⽋ © Findy Inc. 54
55. ファインディで実際に起きていたこと 計測したら、AIを導⼊しても⽣産性は変わらなかった 👥 コミットからオープンまでの平均時間 📦 1⼈あたりPR作成数 -10% 横ばい コードを書く速度は上がった １⼈あたりのアウトプット量は変化なし ⏱ レビュー→Approve時間 💬 平均コメント数 +50% レビューからのやり取り +30% 指摘量が増加 コード⽣成は速くなったが、レビュー⼯程で詰まっている？ © Findy Inc. 55
56. セルフレビュー：6 観点並列分析 🔒 セキュリティ ✨ コード品質 📐 規約準拠 ▼ ▼ ▼ Pull request ▼ ▼ ▼ 🧹 simplify観点 🎯 要件検証 ☑ チェックリスト 照合 → 複数エージェントが並列で動き、信頼度の⼀定以上の指摘のみ報告 ⚡ 実績：2000以上のPRで運⽤中（2026年5⽉時点） © Findy Inc. 56
57. © Findy Inc. 57
58. © Findy Inc. 58
59. © Findy Inc. 59
60. AI活⽤は組織に定着し、増え続けている 🖥 セッション数 🛠 Skill 実⾏回数 約3倍 🔤 累計トークン 約6倍 🎯 キャッシュヒット率 約5倍 93.5% 配布した仕組みが、組織に定着し使われ続けている © Findy Inc. 60
61. © Findy Inc. 61
62. 1⼈あたりPR作成数が1.5倍に 測って改善を回し続けた結果 🚀 1⼈あたりのPR作成数 約1.5倍 ✅ レビュー指摘数 横ばい 質を維持したまま量を増やした ⏱ レビュー→Approve時間 横ばい 💬 平均コメント数 横ばい プルリクエストの質を落とさず、数を増やすことに成功 各種リードタイムと向き合うのが、次の改善のサイクル © Findy Inc. 62
63. まとめ © Findy Inc. 63
64. AI活⽤レベル レベル1 レベル2 ➜ 「速く作る」 コード⽣成の⾃動化 「正しく作る」 レベル3 ➜ 「必要なものを作る」 モノ作り全体の再設計 他領域への越境 どれか1つではなく、段階的に積み上げることで初めて成⽴する © Findy Inc. 64
65. ⚠ 順番を間違えない：基本が先、AI活⽤は後 ⚠ ⼟台が弱いと、ガードレールもAIも成果を出せない 4. 🤖 AI Skill / Plugin 横展開 — 組織全体で AI 活⽤を加速させる 3. 🛡 ガードレール‧ハーネス整備 — AI が出⼒するコードのガードを敷く （README / AGENT.md / rules / 規約） 2. 🌿 PR 粒度‧レビュー⽂化 — 開発⽂化を育てる 1. ✅ コード品質‧テストコード — 統⼀規約 / 型定義 / テストコード — まず ここを充実させる 💡 順番を間違えない：基本が固まってからAI活⽤を載せる AIは銀の弾丸ではない © Findy Inc. 65
66. まとめ 🏗 基本の徹底が重要 🎯 兼務ではなく専任 ⼟台と改善を段階的に積み重ねて、 基礎を固めることで、初めてAIは効果を発揮する 通常業務とAI推進の兼務は不可能 AI推進専⾨ポジションが必要 📈 組織全体でContribute 🔍 可視化は必要不可⽋ AI推進が全部やるのではなく、 組織全体で改善できる仕組み作り 再現性⾼く改善のサイクルを回し続けるために 可視化は必要不可⽋ 「これで⽣産性が⼀気に上がる」という決定打は無く、⼩さいことの積み重ねの結果 ⽬の前の課題と向き合い続ける姿勢が、AI推進が⾒せるべき姿であり、その先に真の組織改⾰がある © Findy Inc. 66
67. ご清聴ありがとうございました Ask the Speakerで会いましょう © Findy Inc. 67