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
Masato Ishigaki / 石垣雅人
December 04, 2025
Technology
2.3k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
プロダクトマネージャーが押さえておくべき、ソフトウェア資産とAIエージェント投資効果 / pmconf2025
2025/12/04 pmcon 2025 登壇資料
Masato Ishigaki / 石垣雅人
December 04, 2025
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
AI x 開発生産性を取り巻く予算戦略と投資対効果
i35_267
8
4k
誤解だらけの開発生産性 / Myths and Misconceptions about Developer Productivity
i35_267
2
1.2k
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
5
520
大規模組織にAIエージェントを迅速に導入するためのセキュリティの勘所 / AI agents for large-scale organizations
i35_267
8
1.4k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
8
26k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
6
2.5k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
4
480
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
6
840
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
9
2.2k
Other Decks in Technology
See All in Technology
20260801_スクフェス大阪
kgnkhkr
1
1.1k
TypeScript入門 2026
recruitengineers
PRO
1
260
モバイルアプリ開発概論2026
recruitengineers
PRO
1
300
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
19k
[MIRU26] Open-Vocabulary Intention-Guided Object Detection in Diverse Scenes
keio_smilab
PRO
0
140
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
1.2k
JavaScript 研修 (2026)
recruitengineers
PRO
0
260
AIエージェントの知識表現と推論に なぜグラフが使われるのか - 記号的AIの復権とニューラルAIとの統合
yohei1126
1
280
研究開発部の紹介 / Sansan R&D Profile
sansan33
PRO
4
24k
AIがコードを書く時代、人間は何を保証するのか———馬場さんと考える、開発者に求められる新しい責任と価値 - TECH PLAY
netmarkjp
0
1.3k
Amazon Bedrock Managed Knowledge BaseDive Deep
ren8k
0
400
AIQAのナレッジ構築について
qatonchan
1
160
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Balancing Empowerment & Direction
lara
6
1.2k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.1k
Claude Code のすすめ
schroneko
67
230k
Tell your own story through comics
letsgokoyo
1
1k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
The Limits of Empathy - UXLibs8
cassininazir
1
580
The untapped power of vector embeddings
frankvandijk
2
1.8k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
480
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
The Cult of Friendly URLs
andyhume
79
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投資をどこに張るか