AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ？

Developers Summit 2025 FUKUOKA（2025.09.26）の登壇資料です。
https://event.shoeisha.jp/devsumi/20250926/

Transcript

1. 1 AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ？ ロリポップ‧ムームードメイン事業部 ⻄⽥貴之 Developers Summit 2025 FUKUOKA（2025.09.26）
2. 2 ⾃⼰紹介 ロリポップ‧ムームードメイン事業部 事業開発チーム 2020年 中途⼊社 ⻄⽥ 貴之 Nishida Takayuki • Webアプリケーションエンジニア • 主に新規事業開発を担当 • エンジニア組織におけるAI活⽤の推進や 開発⽣産性向上への取り組みも⾏っている。 • X : @kinosuke01
3. 3 アジェンダ 1. はじめに：本セッションのゴール 2. AI活⽤の現在地：どんな活⽤事例があるか？ 3. 開発⽣産性のリアル：どの程度変わったのか？ 4. 課題分析：ボトルネックはどこにあるのか？ 5. まとめ
4. はじめに 4 ‧AIコーディングエージェントの活⽤事例 ‧開発⽣産性における課題の事例 をお伝えすることで ‧開発におけるAI活⽤の解像度向上 ‧未来像を描くヒントにつなげる ことを⽬指します。 このセッションのゴール
5. 1. AI活⽤の現在地 どんな活⽤事例があるか？ 5
6. AI活⽤の現在地 6 • AIによるコードの⼤量⽣成は、既存の開発プロセスを崩壊に導く可能性。 • 物量を抑えるのではなく、 物量に耐えうる仕組みづくりが、エンジニアリングの本質。 これらを視野に⼊れつつ 前提：まずは物量を増やすことから まずは物量を増やす活動から着⼿
7. AI活⽤の現在地 7 • Claude Code • CLIベースのAIコーディングエージェント • Anthropic社提供 • Claude Code Action • Claude Code を GitHub Actions で実⾏できるカスタムアクション • GitHubのissueでの実装依頼も可能になる • Cursor • VSCodeからフォークされたAIコードエディタ • Anysphere社提供 登場するAIコーディングエージェント
8. AI活⽤の現在地 8 • ⽚⼿間でソフトウェアアップデート • コードを⾒ずにプロダクト改善 • ほしいツールはその場で⽣成 他にも事例はたくさんあるが、今回はこの3点をピックアップ。 今回ピックアップする活⽤事例
9. AI活⽤の現在地 9 • 状況と課題 • 本番稼働中の Next.js アプリケーションあり。 • 歴史的な経緯から⾃動テストがなく、ソフトウェアアップデートが困難。 • やったこと • Claude Code でテストコードを⼤量⽣成。 • 数時間連続稼働で、ブランチカバレッジ 70%程度まで実現。 • そのうえでソフトウェアアップデート対応。 • Claude Code にアップデートさせる。 • Claude Code にテストコードが通るまで修正をさせる。 [事例1] ⽚⼿間でソフトウェアアップデート
10. AI活⽤の現在地 10 • 結果 • ソフトウェアアップデート作業の⼤半が⾃動で完了した 👏👏 • (レビューはやや⼤変だったものの) • メインの業務の⽚⼿間で実現できた 👏👏 [事例1] ⽚⼿間でソフトウェアアップデート
11. AI活⽤の現在地 11 • 状況と課題 • 社内向けの Streamlit 製のWebサービスあり。 • 専任のチームで運⽤保守。 • 改善要望や不具合調査は専任チームに依頼する必要があり 敷居が⾼かった。 • やったこと • Claude Code Action の導⼊。 • issueで調査や実装の指⽰をあたえられるように設定。 [事例2] コードを⾒ずにプロダクト改善
12. AI活⽤の現在地 12 • Claude Code Action 導⼊後の体験 • GitHubのissueに改善要望や不具合報告を登録。 • それをもとに、Claudeが⾃動で改修PR作成。 • CIと専任チームのレビューが通ればマージ‧リリース。 • 効果 • 改善や不具合修正の敷居が⼤きく下がり、 希望する改善がどんどん進むようになった 👏👏 [事例2] コードを⾒ずにプロダクト改善
13. AI活⽤の現在地 13 • 同じことが、お客様向けのWebサービスでも実現。 • 新たな体験 • ビジネス職やカスタマーサポートがissueに改善要望や不具合報告を登録。 • Claudeが実装してPR作成。 • CIとエンジニアのレビューが通ればマージ‧リリース。 • 効果 • 従来より早く価値提供ができるようになった 👏👏 • 対応可能な範囲はまだ限られているものの、ちょっとしたUI修正は実現できている。 [事例2] コードを⾒ずにプロダクト改善：補⾜
14. AI活⽤の現在地 14 • 状況と課題 • あるWebサイトの実⾏基盤を更新する事案。 • 更新後に、数百ページ以上で崩れがないかチェックする必要あり。 • やったこと • VRT(※) ツールをClaude Codeで1分程度で⽣成した。 • そのツールを⽤いて⾃動チェックを⾏った。 • 結果 • 従来だったら、VRTツールの調査や実装を⾏う必要があったところ、 調査と実装の⼿間を削減することができた 👏👏 [事例3] ほしいツールはその場で⽣成 ※ VRT(Visual Regression Test): スクリーンショットの画像を⽐較して意図しない変更がないかチェックするテスト。
15. AI活⽤の現在地 15 • 同じことをエンジニアではないメンバーも実現。 • 下地：社内で Vibe Coding (※) 研修を実施。 • 主にCursorを⽤いた研修。 • ビジネス職やカスタマーサポートも参加。 • その知⾒をもとに、ほしいツールをその場で⽣成 👏👏 • テックブログでも情報公開。 [事例3] ほしいツールはその場で⽣成：補⾜ ※ Vibe Coding: ⾃然⾔語でAIに「雰囲気」や「ノリ」で指⽰を出すだけで、 AIが機能やアプリケーションを⾃動⽣成してくれるソフトウェア開発⼿法。
16. 2. 開発⽣産性のリアル どの程度変わったのか？ 16
17. 開発⽣産性のリアル 17 開発⽣産性の指標のひとつとして「Four Keys」があげられる。 • デプロイ頻度 • どれくらいの頻度で本番にデプロイできているか • 変更のリードタイム • コードのコミットから本番反映までの時間 • 変更失敗率 • デプロイに伴う失敗の割合 • サービス復旧時間 • 障害から回復するまでの時間 開発⽣産性指標：Four Keys
18. 開発⽣産性のリアル 18 Four Keys を踏まえて、 最初に変化があると思われる、デプロイ頻度の先⾏指標に着⽬。 • PRマージ頻度：１⽇あたりの Pull Request がマージされる回数 • PR作成頻度：１⽇あたりの Pull Request が作成される回数 デプロイ頻度の先⾏指標 に着⽬
19. 開発⽣産性のリアル 19 • 社内にある、GitHubでの活動を集計する分析基盤を⽤いて集計。 • 集計対象は、 私が所属するロリポップ‧ムームードメイン事業部の アプリケーションエンジニア(⼗数名)における PRマージ頻度とPR作成頻度。 • メンバー増減やプロダクトの開発状況もあるので、 ⼀概にAIコーディングエージェントのみの影響とは⾔えない数字になるが、 ある程度の傾向は⾒れるだろう。 GitHubで発⽣したデータをもとに集計
20. 開発⽣産性のリアル 20 2024年前半と⽐較して、2025年05⽉以降のPRマージ頻度は、約4倍となった。 PRマージ頻度は約4倍に増加 Claude Code 導入 Cursor導入
21. 開発⽣産性のリアル 21 増加率は⼤きく⾒えるが、 値としては 1⼈1⽇あたり1マージ に増えた程度。 増加後のPRマージ頻度は、1⼈1⽇あたり1マージ
22. 開発⽣産性のリアル 22 2024年前半と⽐較して、2025年05⽉以降のPR作成頻度も、約4倍となった。 PR作成頻度も約4倍に増加 Claude Code 導入 Cursor導入
23. 開発⽣産性のリアル 23 増加率は⼤きいものの、PRマージ頻度と同じ程度。 値としては 1⼈1⽇あたり1.1PR作成 に増えた程度。 増加後のPR作成頻度は、1⼈1⽇あたり1.1PR作成 コードレビューで詰まってしまうほどの ⼤量のPRが作成されているわけではない。
24. 開発⽣産性のリアル 24 我々が⾒据えているのは • 既存の開発プロセスでは耐えきれない物量の産出 • その物量に耐える仕組みづくり たとえば、1⼈あたり1⽇100PRを作るような世界。 その世界には程遠い。開発⽣産性は"爆増"していない。 我々の⾒据える世界には程遠い
25. 3. 課題分析 ボトルネックはどこにあるのか？ 25
26. 課題分析 26 • 組織や仕事のプロセスにおける全体のパフォーマンスは、 他の部分がどれだけ優れていても、 最も処理能⼒が低い部分（＝ボトルネック）に制限される。 • そのため、ボトルネックを特定して改善することが重要。 前提：制約条件の理論
27. 課題分析 27 • アンケートやヒアリングを重ねメンバーの声を集める。 • 全体の傾向をみて、ボトルネックと疑わしき箇所を洗い出す。 ボトルネック特定のため情報収集
28. 課題分析 28 • CIの実⾏時間が⾮常に⻑い • 品質保証に時間を要している • 要件定義に時間を要している 他にも疑わしき点はあるが、今回はこの3点をピックアップ。 少し⾒えてきたボトルネック
29. 課題分析 29 • 状況 • あるタスクのCI完了待ちで、後続タスクの着⼿が滞留してしまう。 • 調査 • GitHub Actions の実⾏時間を集計した。 [1] CIの実⾏時間が⾮常に⻑い
30. 課題分析 30 • CIの実⾏時間集計は、GitHubのAPIから値を取得して⾏った。 • 従来： • APIの仕様を調べて、集計処理を⾃分で書く必要があった。 • 現在： • 要件を決めたら、APIからデータ取得して集計する処理は⾃動実装。 • 所感： • レビューは必要なものの、書き捨ての集計処理を⼿軽に作れる。 • ⼤きな⼿間削減。 • 定量評価がやりやすくなった。 [1] CIの実⾏時間が⾮常に⻑い：調査⽤の集計処理は⾃動実装
31. 課題分析 31 ⼀部のプロダクトで、明らかに遅いCIがあることが特定された。 [1] CIの実⾏時間が⾮常に⻑い：集計結果から遅いCIが特定 ※ 集計結果を抜粋したもの プロダクト A プロダクト B
32. 課題分析 32 • ⼀部のプロダクトで顕著に遅いものがあった。 • 改善ポイントが特定できたので、メンバーがCIの改善を実施。 • プロダクトBにおいては、約30分 → 約5分に改善。 [1] CIの実⾏時間が⾮常に⻑い：CIの改善を実施
33. 課題分析 33 • プロダクトBにおける、CI改善後のマージ頻度の変化は、現時点ではわからず。 • ただ、プロダクトの開発状況にも左右されるので、引き続き観測する。 [1] CIの実⾏時間が⾮常に⻑い：マージ頻度の変化はわからず CI改善 ※ プロダクトBの  マージ頻度の変化
34. 課題分析 34 • 品質保証：仕様通りであることの保証 • 状況と課題 • プロダクトは、複数のシステムの連携が求められるユースケースが多い。 • そのため、リリース前にE2Eテストが必要なことが多い。 • このE2Eテストに⼈⼿を要していた。 • 対応 • E2Eテストに割かれていた時間の計測は困難だったものの、 ボトルネックの可能性があると判断。 • Playwright を⽤いた⾃動テストを導⼊開始。 • このお話は別の機会に共有したい。 [2] 品質保証に時間がかかっている
35. 課題分析 35 • 「作るもの」を決めるのに時間がかかっている。 • 状況 • アンケート結果「やりたいこと、開発したいものはたくさんある」 • 要件を整理、合意形成して、実装着⼿できる状態にするまでが重い。 • 対応 • まだ対応できていない。 • 業務の棚卸しと、AIによる⾃動化を視野。 [3] 要件定義に時間を要している
36. まとめ 36
37. まとめ 37 • AI活⽤の現在地：活⽤事例のご紹介 • ⽚⼿間でソフトウェアアップデート • コードを⾒ずにプロダクト改善 • ほしいツールはその場で⽣成 • 開発⽣産性のリアル： • 増加しているものの頭打ち。物量が⾜りていない。 • 課題分析：ボトルネックの疑いのあるもの • CI / 品質保証 / 要件定義 に時間がかかっている。 アジェンダの答え合わせ
38. 38 まとめ • AIコーディングエージェントの活⽤で 開発⽣産性は向上するが、早期に頭打ちになる。 • ボトルネックを特定し、解消していきましょう。 以上になります。ありがとうございました！