AI x 開発生産性を取り巻く予算戦略と投資対効果

2026年7月22日 AI DevEX Conference 2026 登壇資料

Transcript

1. AI × 開発生産性を取り巻く 予算戦略と投資対効果 Masato Ishigaki July. 22, 2026 1
2. About me 石垣 雅人 合同会社 DMM.com プラットフォーム開発本部 副本部長 第4開発部 部長 / VPoE室 / アルファ室 兼務 新刊 2
4. outline 1. AI × 開発生産性 × 予算としたときに従来の開発生産性・会計からの変化 2. それに対応する戦略・戦術をどう立てて投資対効果をどう測るか 4
5. outline 1. AI × 開発生産性 × 予算としたときに従来の開発生産性・会計からの変化 2. それに対応する戦略・戦術をどう立てて投資対効果をどう測るか 5
6. AI× 開発生産性 × 予算を立てるうえでの外的要因 - プロンプト → コンテキスト → ハーネス → ループへ - トークンコストについても定額制から従量課金が世界的にトレンドへ - トークンマキシングからトークンマネジメント、FinOps / 人材関連費の見直しへ - 去年までは何ができるかの仮説期間だったが、今年度の予算策定では明確に費用対効果が求めら れる状況（1億円つかったら1億円の投資対効果はどこに表れるのか） 管掌部門も、1年間で5倍へ 6
7. 人によるスケーリングから、AIによるスケーリング 主に3パターンの推移的変化 人を増やして、 スケール + 個の生産性をAI上げて スケール + + ハーネスをつけながら AIエージェントを増やして、 スケール + + + 7
8. 人件費 < ソフトウェアへの投資増加 P/L スケール方法 +700万 +700万 +700万 + +700万 人材関連費 ・給与手当 / 賞与 ・法定福利費 / 福利厚生費 ・地代家賃 / 採用費 ・販管費 / 支払い手数料 +700万 + + +20万 +20万 販管費 / 支払手数料 +700万 +20万 （ライセンス料） + + + +20万 +20万 8
9. AIエージェント投資の会計的処理 - AIで作ったソフトウェアは、 資産化するのかどうか の議論がある - 資産化→ソフトウェア仮勘定として扱うのは人件費がほとんど。 ソフトウェア資産にかかるツール費用は、通常費用化されコストへ 資産化→償却で5年(60ヶ月)で分割されるため営業利益は改善して見える（ただし税率は多くか かるので結果としては多くかかる） 逆に費用化 = コスト増に見えるので営業利益は悪化して見える 9
10. AI × 人（目標設定・評価）の変化
11. AI投資を加味した、人事評価の必要性 新しい価値観の醸成 - 従来 : (年収800万) = 800万 - これから : (年収500万) → (年収500万) + (AIエージェント500万) = 1,000万 の価値を出せているかで評価しないといけない（福利厚生とか地代家賃除く） 11
12. AI投資を加味した、人事評価の必要性 判断軸 元々「この人が年収800万の価値があるか」を以下などの判断軸で決定 - 等級（グレード）、期待値マネジメント、市場価値・環境を定量的・定性的に見て判断 - 上記にプラスして、期待値を超える活動を「AIコスト 」「AI活用のスキル 」で判断 - ex. 年収500万の人がめちゃくちゃ成果がでた！ - - → ただしAIコストを500万を使ってやった or AIの使い方のレベルは高くない これをどう評価して昇給させるべきか を考える必要がある - （サーバーコストを5,000万削減しました→スペックを下げただけで作業難易度は高くないので 能力給は上がっていないときに、評価するかしないかかと同義） - ただし以前より技術スキルは「人→人」への育成よりも、AI時代になると「スキル→スキル」でチームに 技術スキルがスケールしやすい 12
13. AI × 開発生産性の変化
14. 開発生産性の前提と変化 - - 測るのが可能なもの - プロジェクトの進捗遅れ / 見積もりと実際かかった工数との差分 - Four keys / SPACEのデータ / AIエージェントの投資額 測るのが難しいもの - 「技術的負債（保守性観点）」の深さ - 「認知的負債（Cognitive Debt ）」の深さ（AI駆動開発でより顕著に） 「測れる数字 = 正しい生産性」 とは限らない 14
15. 認知的負債について 認知的負債 • 「動いている／テストも通る」でも、理解が追いつかないと負債は加速する 速度が理解力を上回るとき 技術的負債はシステム障害や保守コストとして顕在化する のに対し、認知的負債は開発速度の指標には現れませ ん。 コードは正常に動作し、テストもパスし、機能もリリースされま す。しかし、この負債はシステムを構築したエンジニアの心 の中にのみ存在し、彼ら自身の仕事に対する不安として現 れます。 15
16. 開発生産性ツリーの構造的理解 <開発生産性の構造的理解> 「開発生産性」が経営層に伝わらない理由は、 “言語”が違うから
17. “開発生産性”の恩恵はレイヤーごとに意味が違う 経営 経営層 CxO・役員 （経営企画 / 経理） 数値の流れ B/S P/L 資産 / 減価償却 販管費 経理 BM BM cost（⾦額） 事業責任者 PdM cost（⾦額） PdM PdM man-month（⼯数） man-month（⼯数） EM 横断 組織 PM/Dir 財務諸表 ・P/L : 販管費への影響度合い ・B/S : 資産、償却、税負担への影響 金額 ・販管費の最適化 ※ 同じ単価でも、施策回数と質が違う ※ 生産性が落ちてくると、追加投資額が必要 工数・工期（計画・ロードマップ） ・生産性が高くなると当初計画よりも短くなる ・もしくは類推見積もりの角度が上がる スループット（1⼈⽉あたりの⽣産性） 開発組織 Eng Eng Des Eng Eng Des 開発チーム内の向き合い ・ソフトウェアの内部品質、エコシステム ・Four keys, テストカバレッジ 17
18. 立体感 プロセスは 上から下へ 予算権限 ▼ P/L（予算が操作可能変数） 経営層 経営 生産性の価値 CxO・役員 （経営企画 / 経理） ┗ 人件費（ソフトウェア仮勘定） ┗ 減価償却費 ┗ 採用費（フィー） ┗ 通信費（サーバー費用等） ┗ ライセンス費,etc.. 経理 cost（⾦額） BM BM ▼ 個・チームの生産性 接続箇所 事業責任者 PdM PdM PdM man-month（⼯数） EM ┗ コード ┗ チームパフォーマンス ┗ バックログ ┗ フロー状態 横断 組織 PM/Dir 使 っ て い る 武 器 ▼オブザーバビリティー ┗ n ... スループット（1⼈⽉あたりの⽣産性） 開発組織 Eng Eng Des Eng Eng Des 人数サイズ 18
19. 立体感 プロセスは 上から下へ 予算権限 経営層 経営 生産性の価値 CxO・役員 （経営企画 / 経理） 無理に飛躍して、 現場の指標を 管理会計に繋げない。 机上の空論になる 経理 cost（⾦額） BM BM 接続箇所 事業責任者 PdM PdM PdM man-month（⼯数） EM 横断 組織 PM/Dir スループット（1⼈⽉あたりの⽣産性） 開発組織 Eng Eng Des Eng Eng Des 人数サイズ 19
20. オーバーラップさせる箇所の意味を変換すればいい 経営 経営層 CxO・役員 （経営企画 / 経理） 資産価値 / 減価償却 モニタリング基盤を構築して、 正しくレポーティング Sales Mktg BM 経理 BM cost（⾦額） 事業責任者 PdM PdM BigQuery PdM man-month （⼯数） EM 開発組織 スループット （1⼈⽉あたりの⽣産性） Eng Eng 横断 組織 PM/Dir Des Eng Eng Des 20
21. ヘルスチェックレポートの運用 1. 管理会計 / 財務会計の数値 2. 人員構成（雇用形態 / 等級） 3. 採用計画・育成計画 4. 開発生産性（投入工数の内訳） a. 開発 / 運用の割合 b. AIコスト（トークンマネジメント） 5. プロジェクト BigQuery 点と点を繋げて、未来を語れる部門運営へ 21
22. 人件費が何に使われているかを徹底的に分解する 生産性ツリー Budget - 見えるデータ ① 財務指標（予算） 開発 Capex Opex 運用 ② 投資工数分布 (Bigquery→Looker) 開発 ③ 施策工数・工期 10⼈⽉ / 5ヶ⽉ 施 策 1⼈⽉ / 0.5ヶ⽉ 3⼈⽉ / 1ヶ⽉ Commit Design UI Dev 20% 40% 30% PR In-Review Approve 人件費 : 1億円 └ 人件費 : 1億円 └ 開発工数（Capex） : 4,000万（4人月） └ Aプロジェクト（3.5人月） └ Bプロジェクト （0.5人月） └ 運用工数（Opex） : 6,000万（6人月） └ 障害対応 （2人月） └ 目標設定/評価（4人月） (Bigquery→Looker) └ 開発工数 : 4,000万（4人月） └ Aプロジェクト（3.5人月 / 1ヶ月） └ Bプロジェクト（0.5人月 / 10日） ④ バリューストリーム ( Bigquery→Looker ) └ Aプロジェクト（3.5人月 / 1ヶ月） └ 設計（20%） └ 開発（30%）...etc ⑤ 開発ライフサイクル └ 開発（30%） └ プルリクエストA └ PR - Approve : 20h └ プルリクエストB └ PR - Approve : 5h …etc (GitHubのライフサイクル) （Findy Team+）
23. 例 : Cursor Dashboardを使ったリードタイム（VSM）の計測も盛んに ・勤怠工数 / Slack / GitHub / 会議..etcをもとに生成 ・さらに細かく知りたくなったらCursorに追加で質問できた
24. AIによる変化をまとめると 以下が変化 - 予算の投資比率が、人件費からソフトウェア利用料やクラウド利用料へ - 測れない生産性として「認知的負債」が増加 - 人員構成比率の変化として採用計画 / 育成計画の見直し 24
25. outline 1. AI × 開発生産性 × 予算としたときに従来の開発生産性・会計からの変化 2. それに対応する戦略・戦術をどう立てて投資対効果をどう測るか 25
26. 生産性ツリーにAIよる変化量をプロットしていく 生産性ツリー Budget - AIによる変化量をプロットしていく ① 財務指標（予算） # 開発 Capex Opex 運用 ② 投資工数分布 ③ 施策工数・工期 10⼈⽉ / 5ヶ⽉ 1⼈⽉ / 0.5ヶ⽉ (Bigquery→Looker) 3⼈⽉ / 1ヶ⽉ Design 20% UI 40% Dev ④ バリューストリーム ( Bigquery→Looker ) 30% ⑤ 開発ライフサイクル Commit PR In-Review Approve 目標値/ベ ンチマーク 1 財務指標 AIエージェントコスト x グループ毎 - 2 財務指標 投資回収率 投資額（ 25/3~26/2） / FY25効果額 （25/3~26/2） 6ヶ月以内 3 財務指標 来期の採⽤予定⼈数 従来の採⽤ 予定⼈数 x 0.7 4 開発（Capex） (新規開発⼯数) /（各グループの総⼯数） (エンハンス開発⼯数) /（各グループの総⼯ 数） (保守開発⼯数) /（各グループの総⼯数） ＋30% 5 運⽤（Opex） （運⽤）/ （各グループの総⼯数） （管理、その他）/ （各グループの総⼯数） −50% (Bigquery→Looker) 開発 施 策 測定方法 指標分類 (GitHubのライフサイクル) （Findy Team+） (類推⾒積もり群A~Z) × ⼯数 施策⼯数‧⼯期 6 バリューストリーム ▼ 特徴量 ‧⼯数の類似性 ‧PRD/DDの有無 ‧かけた⼈数 新規 −30% 既存 −20% 7 開発ライフサイクル 1⼈あたりの⽣産量伸⻑率 ＋50%
27. 戦略 ①財務指標 + ② 投資工数分布ごとに戦術を作り込み 投資⼯数区分 開発（Capex） 運⽤（Opex） 開発区分 ⼯数（⼈⽉） ⼯数（割合） KPI 金額 戦略 施策 1. 新規開発 57.38 28.38% 10,000円 → xx% 戦略1 戦術A 2. エンハンス開発 30.29 14.98% 10,000円 → xx% 戦略1 戦術B 3. 保守開発 24.40 12.07% 10,000円 → xx% 戦略2 戦術C 4. 運⽤ 35.89 17.75% 10,000円 → xx% 戦略2 戦術D 5. 管理業務、その他 50.65 25.06% 10,000円 → xx% 戦略2 戦術E 6. - 3.55 1.76% 10,000円 → xx% 戦略2 戦術G 総計 202.17 100.00% ⽬標KPIは チームごとに変化
28. 戦略1. 戦略2. ⽬的 : Capacity（投⼊⼯数）に対して、Imcrement（物的/付加価値⽣産性）の現状を100%だとして、150%にする 戦略1. 開発プロセス（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする 戦略2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回して、Capacity（⼊⼝）を1.5倍にする 問題を定義するところ Capacity （投⼊⼯数） 戦 略 1 ⼈同⼠が泥臭く合意するところ 意思決定を加速するためにAIを使う ⼈がPilot、AIがCopilot /goal 作業はAI。品質は⼈が担保 ⼈がCopilot、AIがPilot Enhance 200⼈⽉ Orchestration select skills 90⼈⽉ 新規 Requirement Enhance PRD DD Ops 戦 略 2 問題を解くところ 保守開発 運⽤ 110⼈⽉ Task lists UI Task lists Test Cases Task lists n… FE impl BE impl Agent Spec E2E リファクタ AIに置き換えられるか EOL 障害対応 ⼀次対応 評価起案 ポストモーテム 管理 会議 Increment （物的/付加価値⽣産 性）
29. 戦略を満たす、戦術的な目標設定
30. 戦略1の現状 戦略1. 開発プロセス（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする 戦略2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回して、Capacity（⼊⼝）を1.5倍にする
31. 戦略1. ValueStream（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする - ボトルネックが前にいったり（企画〜要件）、後ろにいったり（レビュー）にいったり - 相対的には、リードタイムが短縮しているとはまだ言えない（成果にブレがある） - 最後に人がやるべき部分は、入口（何を作るかのコンテキスト）と出口（成果物の品質とセキュリティ）になるだ ろう
32. 戦略1. ValueStream（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする PF-Spec-Kit（仕様駆動・目的駆動開発） の提供開始
33. 戦略1. ValueStream（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする チーム開発 × AIの同期方法の模索 - 個とチーム、個とAI、チームとAI、AIとAI、環境ごとでのAIエージェントを介した同期方法は模 索中 - 大事なのは、過程を透明性とプロダクトコンテキストの品質（AIリーダブルな状態） 個とチーム （オンサイト/同期・非同期） チームとAI （オンサイト/同期・非同期） チームとAI （リモート/同期） 個とAI / チームとAI （リモート/非同期） オンラインツール Devin
34. ValueStream（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする 戦略1. スピードと品質 : 先行指標（品質）と遅行指標（スピード）の意識付け - AI活用によって、まずスピードを求めない。品質を先行指標とする。遅行指標としてスピードは勝手についてく る - スピードを先行指標とするとグッドハートの法則になる - トライアルを進めながら特に悩んでいるチーム・伸ばしたいチームをメインに一緒に行っていく - 品質としては品質特性（ISO/IEC 25010）をAIエージェントを使う際の成果として目標に組み込む 一時的にリードタイムは沈むが損益分岐点を超えると リードタイムは速くなるはず
35. 戦略1. ValueStream（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする プロダクトごとにPdM・エンジニア・デザイナーが大事にし ている品質を入れてもらう
36. 戦略2の現状 戦略1. 開発プロセス（⼯数‧⼯期）をAIネイティブなプロセスで⾼速化し、Increment（出⼝）を1.5倍にする 戦略2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回して、Capacity（⼊⼝）を1.5倍にする
37. 戦略2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回してCapacity（⼊⼝）を1.5倍にする 投資工数区分の明確化 開発区分における（保守開発〜管理業務）までの の工数 の洗い出し 徹底的な業務分析 部分 共通して抱えている業務をAIで置き換えて工数を捻 出していく
38. 戦略2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数をxx⼈⽉分新規に回してCapacity（⼊⼝）を1.5倍にする Modifius / Modifius CI pf-axg-performance-evaluation 技術的負債の分析や設計提案などの機能 を提供およびGHAでの提供 Slack・Google Meet・GitHub の履歴から評価参考情報を自動生成し、1on1面 談や定期評価の補助ツールとして活用します Aさん
39. 戦略2. Opsの⼯数をAIに置き換え(or協働)し余剰⼯数を25⼈⽉分新規に回してCapacity（⼊⼝）を1.5倍にする 「保守開発へのAI投資」と同時に「設計スキルの向上」を行う - コンテキストウィンドウ拡大とモデルの進化によって並列に長時間動くエージェント設計が可能になっ た。1人で。 - 設計スキルの向上としては、ボトムアップもやりつつも、テックリードを中心に対象ドメインの知識がある & 設計できる人（か見込みがある方）人が、今のシステムで古いテクノロジースタックのものを新しいものに 少人数で実行し完遂させる体験を作っていく - その結果、設計として現時点で優れているものができるはずなので、それを見ながら 設計スキルを伸ば していったほうが早いのでは？ というイメージで推進 Stripeの事例 >5,000万行のRubyコードベースにおいて従来であればチーム全体で2ヶ月 以上かけて手作業で行う必要があったコードベース全体の移行を1日で完了 しました
40. まとめ
41. 「我々の存在意義」を探す - 現状AIによって、楽になる未来ではなく、大変な未来が待っていた - 最後に人がやるべき部分は、入口（何を作るかのコンテキスト）と出口（成果物の品質とセキュリティ）とな ると、ドメイン知識 とエンジニアリングの 基礎能力 が今よりも必要になる - 設計・アーキテクトは育成と成長をバックアップしていきたい 「攻めのAI活用から、守りのAI活用までスキルを伸ばす」 - これからは、攻撃する側もAIを使って脆弱性を探し、攻撃の精度と速度を上げてくる前提で考える必要 がある - だからこそ私たちも、AIを使って自分たちのプロダクトや運用の弱さを早く見つけ、先に塞いでいく - 検知するだけでなく、脆弱性の発見、設定の見直し、被害を広げないための備えまで含めて、守る力を 強くしていく
42. 余談 : 業務の改善→問題点の分析→AI関係ないよねの問題にぶち当たる - AIでコード改善する前に、AIリーダブルにしておかないとリファクタリングができなくない？ - AIで開発生産性が改善するか考える前に、そもそも開発生産性の定量化できてなくない？ - AIの成果やトークンマネジメントを考える前に、AI-Readyなデータ基盤を整備しないといけないとか それをAIを使ってちゃんとやる、AI-BPRで再構築し直すでもよいが、 人でどうにかしないといけない壁にあたるので愚直にやったほうが早いし、人が理解していないと評価ができない
43. まとめ 1. AI × 開発生産性 × 予算としたときに従来の開発生産性・会計からの変化 2. それに対応する戦略・戦術をどう立てているか 43