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エージェント投資効果 / pm...
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Masato Ishigaki / 石垣雅人
December 04, 2025
Technology
2
1.4k
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pmconf2025
2025/12/04 pmcon 2025 登壇資料
Masato Ishigaki / 石垣雅人
December 04, 2025
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
5
390
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
8
1.2k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
9
23k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.3k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
4
370
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
730
【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
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
13k
Oracle Cloud Observability and Management Platform - OCI 運用監視サービス概要 -
oracle4engineer
PRO
2
14k
SREが向き合う大規模リアーキテクチャ 〜信頼性とアジリティの両立〜
zepprix
0
350
プロダクト成長を支える開発基盤とスケールに伴う課題
yuu26
1
600
2026年、サーバーレスの現在地 -「制約と戦う技術」から「当たり前の実行基盤」へ- /serverless2026
slsops
2
170
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
3.8k
Data Hubグループ 紹介資料
sansan33
PRO
0
2.7k
30万人の同時アクセスに耐えたい!新サービスの盤石なリリースを支える負荷試験 / SRE Kaigi 2026
genda
1
130
SREのプラクティスを用いた3領域同時 マネジメントへの挑戦 〜SRE・情シス・セキュリティを統合した チーム運営術〜
coconala_engineer
2
500
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
17k
Amazon ElastiCacheのコスト最適化を考える/Elasticache Cost Optimization
quiver
0
400
AIと新時代を切り拓く。これからのSREとメルカリIBISの挑戦
0gm
0
600
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Optimising Largest Contentful Paint
csswizardry
37
3.6k
How To Stay Up To Date on Web Technology
chriscoyier
791
250k
Producing Creativity
orderedlist
PRO
348
40k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
53
Build your cross-platform service in a week with App Engine
jlugia
234
18k
From π to Pie charts
rasagy
0
120
Facilitating Awesome Meetings
lara
57
6.7k
We Are The Robots
honzajavorek
0
160
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
0
1.1k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
0
270
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Transcript
1 Masato Ishigaki Dec. 4, 2025 プロダクトマネージャーが押さえておくべき ソフトウェア資産とAIエージェント投資効果
2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム開発本部 副本部長
/ 第1開発部部長 VPoE室 / アルファ室 / PF-AX戦略 マネージャー ・連載中 : 『開発生産性の多角的視点』(CodeZine) ・連載中 : 『スモールチームが武器になる時代へ』(ProductZine) ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』(NewsPicks) 2
None
None
5 話すこと / ペイン - 視野を広げる入口のきっかけに - 施策効果だけではない“お金の構造” - 経営層と多角的な視点でプロダクトを語れるPdMになる
- └ 施策によるKPI改善やユーザー体験向上だけではなく - └ 財務につながるストーリーを持つ - PdM観点でのAI投資をどこに張るか
6 Table of Contents - PdMに欠けがちな「財務諸表の視点」とは何か - ソフトウェアを資産として見るということ - AIエージェント投資の構造を理解する
7 Table of Contents - PdMに欠けがちな「財務諸表の視点」とは何か - ソフトウェアを資産として見るということ - AIエージェント投資の構造を理解する
前提知識としての「ソフトウェア資産」とは - ソフトウェア資産の判断基準 - 判断基準は「将来の収益獲得または費用削減が確実と認められるか」 - 資産化すると:今年の費用が減る →
利益が増える → 法人税が増える - 費用化すると:今年の費用が増える → 利益が減る → 法人税が減る 価値 時間 ソフトウェア 仮勘定 開発中 1年 2年 3年 資産計上 → 減価償却 残存価値 価値 時間 ソフトウェア 仮勘定 開発中 1年 2年 3年 費用化(経費) 残存価値 なし 8
ソフトウェア資産に関する参考資料 9
10 PdMに欠けがちな「財務諸表の視点」とは何か - PdMが普段扱う視点(顧客・UX・KPI) - └ 外向きの価値は強いが、内部の財務構造は捉えにくい - └
価値の尺度が短期に寄りがちで、資産や税率といった長期が抜ける - └ 経営と話がズレる背景になる - 経営が見ている視点(資産・費用・投資・回収) - └ 単年P/Lだけではく、B/SやC/Fや企業価値の部分
11 抜けがちな視点。例えば、 1,000万で、A機能を作ろう!(工数10人月×単価100万) • PdM的な視点 - 1,000万に対してのROI(狙ったKPIの%)
- ユーザー価値は? - 機能の優先順位はあがった? 主に“価値対コスト(効率)”で判断する世界。 • B/Sな視点 - 資産化なら: - └ 1,000万円を5年で回収する前提で、毎年200万円の 償却負担が続く(利益が増えるから) - └ → 価値がなければ“5年間の財務負債”になる - 費用化なら: - └ 今年の利益を1,000万圧縮し、来年以降には負担が 残らない ※ C/F観点だと実際にキャッシュは1,000万出ていくので注意 PdMに欠けがちな「財務諸表の視点」とは何か
-200万 12 - “作る前 → 作り中 → 作った後” でお金は変化する
- └ 投資 → 資産計上 → 減価償却という流れが生まれる - └ 膨大が額になると回収期間(Payback Period)の意味が変わる 計画→開発 -500万 -1,000万 企画 -500万 単年施策効果 1,000万 費用 償却 費用 資産 release コストは1,500万ではなく700 万という見方もできる 単年 PdMに欠けがちな「財務諸表の視点」とは何か
13 Table of Contents - PdMに欠けがちな「財務諸表の視点」とは何か - ソフトウェアを資産として見るということ - AIエージェント投資の構造を理解する
14 ソフトウェアを資産として見るということ ソフトウェアは価値を回収していく“資源” - └ 費用化はその年で経費/資産化は価値が積み上がる - └ プロダクト寿命と資産寿命は一致しない
- プロダクトとしては 2年で終了したいのに、資産寿命は 5 年残っている等 - └ テクニック : - テストマーケ的にPoCを作ってマーケして駄目だったら撤回だと資産化ではなく費用化 にする - 資産対象でも少額(20万)だと費用化できる (国税庁 : No.5403 : 少額の減価償却資産になるかど うかの判定の例示)
15 ソフトウェアを資産として見るということ - 意味のないものを作ると“B/Sを圧迫する”リスク - └ 機能過多はUXだけでなく“財務負債”でもある - └
不要な減価償却が増えて成果のない負債を生む - └ 使われない機能や停止サービスもB/Sに乗り続ける
16 ソフトウェア資産の蓄積と売上の時間軸の難しさ 資産 負債 純資産 売上 費用 利益 資産の蓄積
(時間軸が長い) (売上へ間接的) cash in (時間軸が短い) (売上に直接的) 積分(数年先に必要なことを今やってる.ex.バージョンアップやリファクタリング ) 微分 開発 資産→売上 開発→資産 作る 減らす (資産を作っている段階では売れるかわからない)
17 Table of Contents - PdMに欠けがちな「財務諸表の視点」とは何か - ソフトウェアを資産として見るということ - AIエージェント投資の構造を理解する
18 AIエージェント投資の構造を理解する - 人件費モデル vs 開発AIエージェント - └ 人でスケールして生産量を確保する時代の終わり
- └ 人件費は固定費. AIは利用量による変動構造 - └ 投資と回収の仕組みが異なる - └ 一方、開発AIエージェント = 人の代わりならば、改めて人件費の投資コストを考 える必要が出てきている。(900万の人が900万の価値があるか) 人材関連費 ・給与手当 / 賞与 ・法定福利費 ・福利厚生費 ・採用費 ・販管費 / 支払い手数料 販管費/支払手数料 (ライセンス料) + + +700万 +700万 +700万 +700万 +700万 +20万 +20万 +20万
19 19 投資対効果を測る上での生産性構造例 Budget -> Labor cost 新規開発 ‧‧‧ 運⽤
‧‧‧ 新規開発 10⼈⽉ / 5ヶ⽉ 1⼈⽉ / 0.5⼈⽉ 3⼈⽉ / 1⼈⽉ 20% 40% 30% PR In-Review Approve Commit ① 投資⼯数分布 (Bigquery→Looker) ② 施策⼯数‧⼯期 (Bigquery→Looker) ③ バリューストリーム (Bigquery→Looker) ④ 開発ライフサイクル (Findy Team+) Design UI Dev 施 策 ⽣産性ツリー ⽣産性ビジュアライズ QA
20 Agent Spec 新規 enhance 100⼈⽉ 保守開発 運⽤ 管理 Enhance
Ops 障害対応 ⽬標設定 ⼀次対応 ポストモーテム n… 評価起案 n… 50⼈⽉ 50⼈⽉ ValueStream Requirement Task lists Task lists Task lists UI Test Cases select pattern BE FE PRD DD impl impl n… E2E Start Orchestration goal Increment ⽬標 : Capacity(投⼊⼯数)に対して、Imcrementの量を現状を100%だとして、150%にする 1. ValueStream(⼯数‧⼯期)をAIネイティブなプロセスで⾼速化し、Incrementを1.5倍にする 中⻑期的なメリット⼤ 2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回して、Incrementを1.5倍にする 短期的なメリット⼤ Capacity (投⼊⼯数) ⼈同⼠が泥臭く合意するところ 意思決定を加速するためにAIを使う ⼈がPilot、AIがCopilot 作業はAI。品質は⼈が担保 ⼈がCopilot、AIがPilot 問題を定義するところ 問題を解くところ 20
21 2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回して、Incrementを1.5倍にする 短期的なメリット⼤ 保守開発 運⽤ 管理 Ops 障害対応 ⽬標設定
⼀次対応 ポストモーテム n… 評価起案 n… 共通して抱えている業務をAIで置き換えて⼯数を捻出していく 開発区分における(保守開発〜管理業務)までの部分の ⼯数はおおよそ40%ある。ここで改善インパクトがある 部分をプロセスから探す 新しい価値への工数 既存価値への工数(Ops) グループ名 / 開発区分 新規開発 エンハンス 開発 保守開発 運用 管理業務 1 Aグループ 43% 12% 13% 1% 31% 2 Bグループ 20% 25% 31% 12% 12% 3 Cグループ 44% 12% 22% 11% 11% 4 Dグループ 43% 6% 7% 3% 39% 5 Eグループ 40% 32% 3% 0% 25% 6 Fグループ 45% 16% 24% 3% 10%
22 まとめ - 視野を広げる入口のきっかけに - 施策効果だけではない“お金の構造” - 経営層と多角的な視点でプロダクトを語れるPdMになる - └
施策によるKPI改善やユーザー体験向上だけではなく - └ 財務につながるストーリーを持つ - PdM観点でのAI投資をどこに張るか