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導入はどのように進めていくべきか / How should we...
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Masato Ishigaki / 石垣雅人
June 09, 2025
Technology
4
370
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
2025/06/09 AIコーディングの次の世界へ!AIが導く未来の開発プロセス
https://globis.connpass.com/event/353967/
Masato Ishigaki / 石垣雅人
June 09, 2025
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pmconf2025
i35_267
2
1.5k
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
5
400
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
8
1.2k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
9
24k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.3k
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
740
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
9
2.1k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.6k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.8k
Other Decks in Technology
See All in Technology
MCPでつなぐElasticsearchとLLM - 深夜の障害対応を楽にしたい / Bridging Elasticsearch and LLMs with MCP
sashimimochi
0
150
小さく始めるBCP ― 多プロダクト環境で始める最初の一歩
kekke_n
1
380
SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント
rvirus0817
0
130
AI駆動PjMの理想像 と現在地 -実践例を添えて-
masahiro_okamura
1
110
AI駆動開発を事業のコアに置く
tasukuonizawa
1
130
レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み
tatsukoni
0
210
日本の85%が使う公共SaaSは、どう育ったのか
taketakekaho
1
150
[CV勉強会@関東 World Model 読み会] Orbis: Overcoming Challenges of Long-Horizon Prediction in Driving World Models (Mousakhan+, NeurIPS 2025)
abemii
0
110
今日から始めるAmazon Bedrock AgentCore
har1101
4
400
Tebiki Engineering Team Deck
tebiki
0
24k
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3.8k
変化するコーディングエージェントとの現実的な付き合い方 〜Cursor安定択説と、ツールに依存しない「資産」〜
empitsu
4
1.3k
Featured
See All Featured
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
0
270
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.3k
Tell your own story through comics
letsgokoyo
1
810
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
730
Making Projects Easy
brettharned
120
6.6k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Become a Pro
speakerdeck
PRO
31
5.8k
How to Think Like a Performance Engineer
csswizardry
28
2.4k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
200
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
0
140
Ruling the World: When Life Gets Gamed
codingconduct
0
140
The Curse of the Amulet
leimatthew05
1
8.4k
Transcript
1 Masato Ishigaki June. 9, 2025 開発フェーズだけではない AI導入はどのように進めていくべきか
2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム開発本部 副本部長
/ 第1開発部部長 VPoE室 / アルファ室 ・連載中 : 『開発生産性の多角的視点』(CodeZine) ・連載中 : 『スモールチームが武器になる時代へ』(ProductZine) ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』(NewsPicks) 2
3 Table of Contents - DMM.comのクリエイター組織のAI導入の現状 - スピード感もあり筋が良い「AI導入」 - 業務プロセスをTOC理論・BPRで洗い出し
- 25年6月時点での3つの力点と課題
4 Table of Contents - DMM.comのクリエイター組織のAI導入の現状 - スピード感もあり筋が良い「AI導入」 - 業務プロセスをTOC理論・BPRで洗い出し
- 25年6月時点での3つの力点と課題
5 DMM.comのクリエイター組織のAI導入の現状 5 - 承認済みツール - GitHub Copilot / CodeRabbit
/ Cline / Devin / Cursor - PoC中(予定含む) - Junie / Jules / Claude Code(トライアル→FB→承認の流れ) - 開発組織内で専門組織を持たずに全員が主体的に取り組むスタイル
6 6 - 今日のテーマ : プラットフォーム開発本部(約200名)のAI導入の事例紹介 - DMM.com 全体だと約1,200〜1,300名が所属
- 開発フェーズだけではないAI導入はどのように進めていくべきか DMM.comのクリエイター組織のAI導入の現状
リードタイムを見ると 開発フェーズ以外のほうが時間がかかっていることが多い
それにより開発作業に工数が避けていない 新規開発 エンハンス開発 保守開発 運用 管理業務、その他 現状システムの維持 費用 新しい価値を作れる
費用 【開発区分の構造】 ・約48%が「新しい価値を作れる費用」 ・約15%が「現状システムの維持費用」 ・約37%が「開発以外の費用」 ※サンプルデータ
9 Table of Contents - DMM.comのクリエイター組織のAI導入の現状 - スピード感もあり筋が良い「AI導入」 - 業務プロセスをTOC理論・BPRで洗い出し
- 25年6月時点での3つの力点と課題
スピード感もあり筋が良い「AI導入」 プロセスを"AI"に置き換えるのではなく、"AI"前提のプロセスに作り変える 以下2つの組み合わせで考える 1.TOC理論(制約理論)
制約(ボトルネック)の解消に集中する考え方 目的は「部分最適」ではなく「全体最適」。 常に“制約に投資してボトルネックを解く” 1. 制約を特定 2. 制約を最大限活用 3. 他プロセスを制約に従属させる 4. 制約を強化・拡張 5. 新たな制約を探す 2. BPR (Business Process Re-engineering) ゼロベースで業務を作り直すアプローチ 既存業務の「延命」や「部分改良」ではなく、 白紙から再構築する 1. 現状分析(As-Is) 2. コアプロセス抽出 3. 理想設計(To-Be) 4. IT・組織・人材を再配置 5. 移行計画・実装
業務 洗い出し スピード感もあり筋が良い「AI導入」 制約と ペイン プロジェ クト化 アサイン メント TOC理論でいう
→ 「制約の特定」 TOC理論でいう → 「制約への投資」 コアプロ セス抽出 レポート ライン 実行 業務 設計 予算・工数・効果 リードの選定 → やれる人がいるか BPRでいう → As-Is → 抽出 → To-Be start BPRでいう ゼロベースでAIプロセスを設計 報連相の設計
業務 洗い出し スピード感もあり筋が良い「AI導入」 制約と ペイン プロジェ クト化 アサイン メント TOC理論でいう
→ 「制約の特定」 TOC理論でいう → 「制約への投資」 コアプロ セス抽出 実行 リードの選定 → やれる人がいるか BPRでいう → As-Is → 抽出 → To-Be start BPRでいう ゼロベースでAIプロセスを設計 報連相の設計 レポート ライン 業務 設計 予算・工数・効果 今は投資対効果はそこまで意識せずに AIへの理解度と利用率を上げる方向性の方が良い
13 Table of Contents - DMM.comのクリエイター組織のAI導入の現状 - スピード感もあり筋が良い「AI導入」 - 業務プロセスをTOC理論・BPRで洗い出し
- 25年6月時点での3つの力点と課題
業務プロセスをTOC理論・BPRで洗い出し 15グループ, 約200名の業務プロセス ※ 詳細はいらずにボリュームを測るため、概略・傾向値で良い
≈ 制約投資の判断 - 課題の共通性・隔たり - 課題のボリューム感(工数) - AIプロセスの投資対効果 業務プロセス区分 1.
運用工数 a. 問い合せ・顧客対応 b. 障害対応・ルーチンワーク 2. 組織管理工数 a. 組織管理のルーチンワーク b. プロジェクトルーチンワーク 3. 新規開発工数 a. 要件定義・企画フェーズ b. 設計フェーズ c. 実装フェーズ d. テストフェーズ e. デプロイ 4. 保守開発 a. リファクタリング 業務プロセス抽出 - プロセス / 目的 / 課題
立ち上げっているプロジェクト prj名 目的・ゴール prj-inq-automation 機能への質問や要望がSlack経由で月130件ほど来ます。これを現在はすべて人が対応し ているため、AIを使い自動で振り分け、評価、返信を自動にする
prj-vibe_coding AIエージェントを活用した開発プロセスを確立させる 生成AIの活用におけるノウハウの分散やスキルのばらつきを防ぎ、無駄な検証やコストの発 生を抑える prj-ai_cost 正しくAIにコスト投資できているかをコスト面で予実の把握及び計画を実行 prj-doc_as_code コードとドキュメントの距離を近くし、AIリーティングしやすい状態にする。 ドキュメントの形骸化 及び 運用コストを限りなくゼロに近づける prj-ai-pdm_pm_mg PdM/PM/開発マネージャー領域のAI活用 要件定義、書類選考、競合調査、進捗報告(prj doc as code)
25年6月時点での3つの力点と課題 doc as code 既存業務プロセスの しがらみ AIへの投資対効果
AIに置き換えと AIとの協働 開発者以外 PdM/PM/開発マネージャー への活用促進
doc as code - コードとドキュメントの距離を近くしてAIリーディングしやすいように - これがあれば、不要なドキュメント更新論がなくなる - かつユーザー体験が作りやすくなる(AI Assistant
/ MCP Server)
AIへの投資対効果のあり方 - 他社事例を分析しつつも、模索中 - 定量で言えば「AIに置き換え」と「AIとの協働」で難易度は違う - AIに置き換え → ヒトでやっていたものを削減時間とする -
AI協働→ヒトの場合/AI協働の予測実績であれば簡単だが本質的ではない
PdM/PM/開発マネージャーへのAI活用
PdM/PM/開発マネージャーへのAI活用
PdM/PM/開発マネージャーへのAI活用 ワークフロー化するべきではないアンチパターン チームの暗黙知や集合知に基づいて運営されている場合が挙げられる。 例えば、以下のケースはワークフロー化に適していません。 • ストーリーポイントや詳細な見積もりなど、チームの経験や知見に基づく判断が必要 な数値の算出
• 1on1ミーティングなど、ピープルマネジメントに関わる重要な対話の場
PdM/PM/開発マネージャーへのAI活用 〜エンジニアが開発に集中してもらうためにできること〜 類推見積もりによる超概算見積もり コードベースからの仕様自動抽出 ※ Devin wikiでも可
24 まとめ - DMM.comのクリエイター組織のAI導入の現状 - スピード感もあり筋が良い「AI導入」 - 業務プロセスをTOC理論・BPRで洗い出し - 25年6月時点での3つの力点と課題