Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pm...
Search
Masato Ishigaki / 石垣雅人
December 04, 2025
Technology
1
74
プロダクトマネージャーが押さえておくべき、ソフトウェア資産と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
Databricksによるエージェント構築
taka_aki
1
110
こがヘンだよ!Snowflake?サービス名称へのこだわり
tarotaro0129
0
100
AI時代のインシデント対応 〜時代を切り抜ける、組織アーキテクチャ〜
jacopen
4
190
Ryzen NPUにおけるAI Engineプログラミング
anjn
0
150
段階的に進める、 挫折しない自宅サーバ入門
yu_kod
5
2.2k
2025 DORA Reportから読み解く!AIが映し出す、成果を出し続ける組織の共通点 #開発生産性_findy
takabow
2
1k
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
2.9k
進化の早すぎる生成 AI と向き合う
satohjohn
0
500
MS Ignite 2025で発表されたFoundry IQをRecap
satodayo
3
220
生成AIシステムとAIエージェントに関する性能や安全性の評価
shibuiwilliam
2
310
AI開発の定着を推進するために揃えるべき前提
suguruooki
1
470
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
21k
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
60
9.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.8k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.3k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
54k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
119
20k
The Cult of Friendly URLs
andyhume
79
6.7k
Site-Speed That Sticks
csswizardry
13
980
Building Adaptive Systems
keathley
44
2.9k
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.2k
Fireside Chat
paigeccino
41
3.7k
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投資をどこに張るか