$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pm...
Search
Masato Ishigaki / 石垣雅人
December 04, 2025
Technology
1
150
プロダクトマネージャーが押さえておくべき、ソフトウェア資産と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
340
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
8
1.1k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
9
22k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.2k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
4
330
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
690
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
9
2k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.5k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.7k
Other Decks in Technology
See All in Technology
インフラ室事例集
mixi_engineers
PRO
2
200
こがヘンだよ!Snowflake?サービス名称へのこだわり
tarotaro0129
0
110
How native lazy objects will change Doctrine and Symfony forever
beberlei
1
360
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
37k
Dify on AWS の選択肢
ysekiy
0
130
Eight Engineering Unit 紹介資料
sansan33
PRO
0
5.7k
ページの可視領域を算出する方法について整理する
yamatai1212
0
160
シンプルを極める。アンチパターンなDB設計の本質
facilo_inc
1
980
MAP-7thplaceSolution
yukichi0403
2
240
GitHub を組織的に使いこなすために ソニーが実践した全社展開のプラクティス
sony
21
11k
OpenShiftのBGPサポート - MetalLB+FRR-k8s編
orimanabu
0
140
Introduction to Bill One Development Engineer
sansan33
PRO
0
320
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
3k
How STYLIGHT went responsive
nonsquared
100
5.9k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
1.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
Site-Speed That Sticks
csswizardry
13
980
Designing for humans not robots
tammielis
254
26k
Practical Orchestrator
shlominoach
190
11k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
196
69k
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投資をどこに張るか