Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
Search
kinosuke01
September 26, 2025
Technology
4
4k
AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ?
Developers Summit 2025 FUKUOKA(2025.09.26)の登壇資料です。
https://event.shoeisha.jp/devsumi/20250926/
kinosuke01
September 26, 2025
Tweet
Share
More Decks by kinosuke01
See All by kinosuke01
長年続く手動E2Eテストを自動化で救いたい
kinosuke01
0
81
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
1.2k
生成AIで加速するテスト実装 - ロリポップ for Gamersの事例と 生成AIエディタの活用
kinosuke01
0
280
カンファレンス登壇資料を毎日読む習慣
kinosuke01
0
190
Notionで作るWebサイト「MuuMuu Sites」の裏側
kinosuke01
0
2.4k
Other Decks in Technology
See All in Technology
[OCI Skill Mapping] AWSユーザーのためのOCI – IaaS編(Compute/Storage/Networking) (2025年10月8日開催)
oracle4engineer
PRO
1
180
現場データから見える、開発生産性の変化コード生成AI導入・運用のリアル〜 / Changes in Development Productivity and Operational Challenges Following the Introduction of Code Generation AI
nttcom
1
440
Node.js 2025: What's new and what's next
ruyadorno
0
1k
AI時代、“平均値”ではいられない
uhyo
8
2.2k
GraphRAG グラフDBを使ったLLM生成(自作漫画DBを用いた具体例を用いて)
seaturt1e
1
100
個人でデジタル庁の デザインシステムをVue.jsで 作っている話
nishiharatsubasa
2
2.6k
OpenTelemetry が拡げる Gemini CLI の可観測性
phaya72
2
1.7k
All About Sansan – for New Global Engineers
sansan33
PRO
1
1.2k
AI時代の開発を加速する組織づくり - ブログでは書けなかったリアル
hiro8ma
1
250
それでも私が品質保証プロセスを作り続ける理由 #テストラジオ / Why I still continue to create QA process
pineapplecandy
0
160
Wasmの気になる最新情報
askua
0
180
CREが作る自己解決サイクルSlackワークフローに組み込んだAIによる社内ヘルプデスク改革 #cre_meetup
bengo4com
0
280
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
The Power of CSS Pseudo Elements
geoffreycrofte
79
6k
RailsConf 2023
tenderlove
30
1.3k
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
990
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.5k
Mobile First: as difficult as doing things right
swwweet
225
10k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Become a Pro
speakerdeck
PRO
29
5.6k
Transcript
1 AIを導⼊しても、 開発⽣産性は"爆増"していない なぜ? ロリポップ‧ムームードメイン事業部 ⻄⽥貴之 Developers Summit 2025 FUKUOKA(2025.09.26)
2 ⾃⼰紹介 ロリポップ‧ムームードメイン事業部 事業開発チーム 2020年 中途⼊社 ⻄⽥ 貴之 Nishida Takayuki
• Webアプリケーションエンジニア • 主に新規事業開発を担当 • エンジニア組織におけるAI活⽤の推進や 開発⽣産性向上への取り組みも⾏っている。 • X : @kinosuke01
3 アジェンダ 1. はじめに:本セッションのゴール 2. AI活⽤の現在地:どんな活⽤事例があるか? 3. 開発⽣産性のリアル:どの程度変わったのか? 4. 課題分析:ボトルネックはどこにあるのか?
5. まとめ
はじめに 4 ‧AIコーディングエージェントの活⽤事例 ‧開発⽣産性における課題の事例 をお伝えすることで ‧開発におけるAI活⽤の解像度向上 ‧未来像を描くヒントにつなげる ことを⽬指します。 このセッションのゴール
1. AI活⽤の現在地 どんな活⽤事例があるか? 5
AI活⽤の現在地 6 • AIによるコードの⼤量⽣成は、既存の開発プロセスを崩壊に導く可能性。 • 物量を抑えるのではなく、 物量に耐えうる仕組みづくりが、エンジニアリングの本質。 これらを視野に⼊れつつ 前提:まずは物量を増やすことから まずは物量を増やす活動から着⼿
AI活⽤の現在地 7 • Claude Code • CLIベースのAIコーディングエージェント • Anthropic社提供 •
Claude Code Action • Claude Code を GitHub Actions で実⾏できるカスタムアクション • GitHubのissueでの実装依頼も可能になる • Cursor • VSCodeからフォークされたAIコードエディタ • Anysphere社提供 登場するAIコーディングエージェント
AI活⽤の現在地 8 • ⽚⼿間でソフトウェアアップデート • コードを⾒ずにプロダクト改善 • ほしいツールはその場で⽣成 他にも事例はたくさんあるが、今回はこの3点をピックアップ。 今回ピックアップする活⽤事例
AI活⽤の現在地 9 • 状況と課題 • 本番稼働中の Next.js アプリケーションあり。 • 歴史的な経緯から⾃動テストがなく、ソフトウェアアップデートが困難。
• やったこと • Claude Code でテストコードを⼤量⽣成。 • 数時間連続稼働で、ブランチカバレッジ 70%程度まで実現。 • そのうえでソフトウェアアップデート対応。 • Claude Code にアップデートさせる。 • Claude Code にテストコードが通るまで修正をさせる。 [事例1] ⽚⼿間でソフトウェアアップデート
AI活⽤の現在地 10 • 結果 • ソフトウェアアップデート作業の⼤半が⾃動で完了した 👏👏 • (レビューはやや⼤変だったものの) •
メインの業務の⽚⼿間で実現できた 👏👏 [事例1] ⽚⼿間でソフトウェアアップデート
AI活⽤の現在地 11 • 状況と課題 • 社内向けの Streamlit 製のWebサービスあり。 • 専任のチームで運⽤保守。
• 改善要望や不具合調査は専任チームに依頼する必要があり 敷居が⾼かった。 • やったこと • Claude Code Action の導⼊。 • issueで調査や実装の指⽰をあたえられるように設定。 [事例2] コードを⾒ずにプロダクト改善
AI活⽤の現在地 12 • Claude Code Action 導⼊後の体験 • GitHubのissueに改善要望や不具合報告を登録。 •
それをもとに、Claudeが⾃動で改修PR作成。 • CIと専任チームのレビューが通ればマージ‧リリース。 • 効果 • 改善や不具合修正の敷居が⼤きく下がり、 希望する改善がどんどん進むようになった 👏👏 [事例2] コードを⾒ずにプロダクト改善
AI活⽤の現在地 13 • 同じことが、お客様向けのWebサービスでも実現。 • 新たな体験 • ビジネス職やカスタマーサポートがissueに改善要望や不具合報告を登録。 • Claudeが実装してPR作成。
• CIとエンジニアのレビューが通ればマージ‧リリース。 • 効果 • 従来より早く価値提供ができるようになった 👏👏 • 対応可能な範囲はまだ限られているものの、ちょっとしたUI修正は実現できている。 [事例2] コードを⾒ずにプロダクト改善:補⾜
AI活⽤の現在地 14 • 状況と課題 • あるWebサイトの実⾏基盤を更新する事案。 • 更新後に、数百ページ以上で崩れがないかチェックする必要あり。 • やったこと
• VRT(※) ツールをClaude Codeで1分程度で⽣成した。 • そのツールを⽤いて⾃動チェックを⾏った。 • 結果 • 従来だったら、VRTツールの調査や実装を⾏う必要があったところ、 調査と実装の⼿間を削減することができた 👏👏 [事例3] ほしいツールはその場で⽣成 ※ VRT(Visual Regression Test): スクリーンショットの画像を⽐較して意図しない変更がないかチェックするテスト。
AI活⽤の現在地 15 • 同じことをエンジニアではないメンバーも実現。 • 下地:社内で Vibe Coding (※) 研修を実施。
• 主にCursorを⽤いた研修。 • ビジネス職やカスタマーサポートも参加。 • その知⾒をもとに、ほしいツールをその場で⽣成 👏👏 • テックブログでも情報公開。 [事例3] ほしいツールはその場で⽣成:補⾜ ※ Vibe Coding: ⾃然⾔語でAIに「雰囲気」や「ノリ」で指⽰を出すだけで、 AIが機能やアプリケーションを⾃動⽣成してくれるソフトウェア開発⼿法。
2. 開発⽣産性のリアル どの程度変わったのか? 16
開発⽣産性のリアル 17 開発⽣産性の指標のひとつとして「Four Keys」があげられる。 • デプロイ頻度 • どれくらいの頻度で本番にデプロイできているか • 変更のリードタイム
• コードのコミットから本番反映までの時間 • 変更失敗率 • デプロイに伴う失敗の割合 • サービス復旧時間 • 障害から回復するまでの時間 開発⽣産性指標:Four Keys
開発⽣産性のリアル 18 Four Keys を踏まえて、 最初に変化があると思われる、デプロイ頻度の先⾏指標に着⽬。 • PRマージ頻度:1⽇あたりの Pull Request
がマージされる回数 • PR作成頻度:1⽇あたりの Pull Request が作成される回数 デプロイ頻度の先⾏指標 に着⽬
開発⽣産性のリアル 19 • 社内にある、GitHubでの活動を集計する分析基盤を⽤いて集計。 • 集計対象は、 私が所属するロリポップ‧ムームードメイン事業部の アプリケーションエンジニア(⼗数名)における PRマージ頻度とPR作成頻度。 •
メンバー増減やプロダクトの開発状況もあるので、 ⼀概にAIコーディングエージェントのみの影響とは⾔えない数字になるが、 ある程度の傾向は⾒れるだろう。 GitHubで発⽣したデータをもとに集計
開発⽣産性のリアル 20 2024年前半と⽐較して、2025年05⽉以降のPRマージ頻度は、約4倍となった。 PRマージ頻度は約4倍に増加 Claude Code 導入 Cursor導入
開発⽣産性のリアル 21 増加率は⼤きく⾒えるが、 値としては 1⼈1⽇あたり1マージ に増えた程度。 増加後のPRマージ頻度は、1⼈1⽇あたり1マージ
開発⽣産性のリアル 22 2024年前半と⽐較して、2025年05⽉以降のPR作成頻度も、約4倍となった。 PR作成頻度も約4倍に増加 Claude Code 導入 Cursor導入
開発⽣産性のリアル 23 増加率は⼤きいものの、PRマージ頻度と同じ程度。 値としては 1⼈1⽇あたり1.1PR作成 に増えた程度。 増加後のPR作成頻度は、1⼈1⽇あたり1.1PR作成 コードレビューで詰まってしまうほどの ⼤量のPRが作成されているわけではない。
開発⽣産性のリアル 24 我々が⾒据えているのは • 既存の開発プロセスでは耐えきれない物量の産出 • その物量に耐える仕組みづくり たとえば、1⼈あたり1⽇100PRを作るような世界。 その世界には程遠い。開発⽣産性は"爆増"していない。 我々の⾒据える世界には程遠い
3. 課題分析 ボトルネックはどこにあるのか? 25
課題分析 26 • 組織や仕事のプロセスにおける全体のパフォーマンスは、 他の部分がどれだけ優れていても、 最も処理能⼒が低い部分(=ボトルネック)に制限される。 • そのため、ボトルネックを特定して改善することが重要。 前提:制約条件の理論
課題分析 27 • アンケートやヒアリングを重ねメンバーの声を集める。 • 全体の傾向をみて、ボトルネックと疑わしき箇所を洗い出す。 ボトルネック特定のため情報収集
課題分析 28 • CIの実⾏時間が⾮常に⻑い • 品質保証に時間を要している • 要件定義に時間を要している 他にも疑わしき点はあるが、今回はこの3点をピックアップ。 少し⾒えてきたボトルネック
課題分析 29 • 状況 • あるタスクのCI完了待ちで、後続タスクの着⼿が滞留してしまう。 • 調査 • GitHub
Actions の実⾏時間を集計した。 [1] CIの実⾏時間が⾮常に⻑い
課題分析 30 • CIの実⾏時間集計は、GitHubのAPIから値を取得して⾏った。 • 従来: • APIの仕様を調べて、集計処理を⾃分で書く必要があった。 • 現在:
• 要件を決めたら、APIからデータ取得して集計する処理は⾃動実装。 • 所感: • レビューは必要なものの、書き捨ての集計処理を⼿軽に作れる。 • ⼤きな⼿間削減。 • 定量評価がやりやすくなった。 [1] CIの実⾏時間が⾮常に⻑い:調査⽤の集計処理は⾃動実装
課題分析 31 ⼀部のプロダクトで、明らかに遅いCIがあることが特定された。 [1] CIの実⾏時間が⾮常に⻑い:集計結果から遅いCIが特定 ※ 集計結果を抜粋したもの プロダクト A プロダクト
B
課題分析 32 • ⼀部のプロダクトで顕著に遅いものがあった。 • 改善ポイントが特定できたので、メンバーがCIの改善を実施。 • プロダクトBにおいては、約30分 → 約5分に改善。
[1] CIの実⾏時間が⾮常に⻑い:CIの改善を実施
課題分析 33 • プロダクトBにおける、CI改善後のマージ頻度の変化は、現時点ではわからず。 • ただ、プロダクトの開発状況にも左右されるので、引き続き観測する。 [1] CIの実⾏時間が⾮常に⻑い:マージ頻度の変化はわからず CI改善 ※
プロダクトBの マージ頻度の変化
課題分析 34 • 品質保証:仕様通りであることの保証 • 状況と課題 • プロダクトは、複数のシステムの連携が求められるユースケースが多い。 • そのため、リリース前にE2Eテストが必要なことが多い。
• このE2Eテストに⼈⼿を要していた。 • 対応 • E2Eテストに割かれていた時間の計測は困難だったものの、 ボトルネックの可能性があると判断。 • Playwright を⽤いた⾃動テストを導⼊開始。 • このお話は別の機会に共有したい。 [2] 品質保証に時間がかかっている
課題分析 35 • 「作るもの」を決めるのに時間がかかっている。 • 状況 • アンケート結果「やりたいこと、開発したいものはたくさんある」 • 要件を整理、合意形成して、実装着⼿できる状態にするまでが重い。
• 対応 • まだ対応できていない。 • 業務の棚卸しと、AIによる⾃動化を視野。 [3] 要件定義に時間を要している
まとめ 36
まとめ 37 • AI活⽤の現在地:活⽤事例のご紹介 • ⽚⼿間でソフトウェアアップデート • コードを⾒ずにプロダクト改善 • ほしいツールはその場で⽣成
• 開発⽣産性のリアル: • 増加しているものの頭打ち。物量が⾜りていない。 • 課題分析:ボトルネックの疑いのあるもの • CI / 品質保証 / 要件定義 に時間がかかっている。 アジェンダの答え合わせ
38 まとめ • AIコーディングエージェントの活⽤で 開発⽣産性は向上するが、早期に頭打ちになる。 • ボトルネックを特定し、解消していきましょう。 以上になります。ありがとうございました!