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
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
開発フェーズだけではない 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
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
なぜ今、コスト最適化(倹約)が必要なのか? ~AWSでのコスト最適化の進め方「目的編」~
htan
1
110
Bedrock PolicyでAmazon Bedrock Guardrails利用を強制してみた
yuu551
0
190
Azure Durable Functions で作った NL2SQL Agent の精度向上に取り組んだ話/jat08
thara0402
0
160
Context Engineeringの取り組み
nutslove
0
320
2人で作ったAIダッシュボードが、開発組織の次の一手を照らした話― Cursor × SpecKit × 可視化の実践 ― Qiita AI Summit
noalisaai
1
380
Context Engineeringが企業で不可欠になる理由
hirosatogamo
PRO
3
530
Cosmos World Foundation Model Platform for Physical AI
takmin
0
710
入社1ヶ月でデータパイプライン講座を作った話
waiwai2111
1
270
Introduction to Bill One Development Engineer
sansan33
PRO
0
360
Data Hubグループ 紹介資料
sansan33
PRO
0
2.7k
M&A 後の統合をどう進めるか ─ ナレッジワーク × Poetics が実践した組織とシステムの融合
kworkdev
PRO
1
420
Amazon Bedrock Knowledge Basesチャンキング解説!
aoinoguchi
0
130
Featured
See All Featured
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
53
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.8k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
1
99
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.7k
GraphQLとの向き合い方2022年版
quramy
50
14k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8.6k
Into the Great Unknown - MozCon
thekraken
40
2.3k
Between Models and Reality
mayunak
1
180
Game over? The fight for quality and originality in the time of robots
wayneb77
1
110
WCS-LA-2024
lcolladotor
0
450
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
280
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
280
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投資をどこに張るか