無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI

2025年7月3日 開発生産性カンファレンス2025 登壇資料
https://dev-productivity-con.findy-code.io/2025

Transcript

1. 1 Masato Ishigaki
 July. 3, 2025
 無意味な開発生産性の議論から抜け出すための 
 予兆検知とお金とAI 

2. 2 About me
 石垣 雅人
 合同会社 DMM.com
 
 プラットフォーム開発本部 副本部長 / 第1開発部部長
 VPoE室 / アルファ室
 
 ・連載中 : 『開発生産性の多角的視点』（CodeZine） 
 ・連載中 : 『スモールチームが武器になる時代へ』（ProductZine） 
 ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』（NewsPicks）
 
 2
5. 5 Table of Contents
 - 無意味な開発生産性の議論、開発生産性という重圧
 - 感覚に頼らない開発生産性低下の予兆検知
 - AIによって開発生産性はどう変化したのか
 - AIへの投資と人への投資によるお金の変化

6. 6 Table of Contents
 - 無意味な開発生産性の議論、開発生産性という重圧
 - 感覚に頼らない開発生産性低下の予兆検知
 - AIによって開発生産性はどう変化したのか
 - AIへの投資と人への投資によるお金の変化

7. 無意味な開発生産性の議論、開発生産性という重圧
 よくある開発生産性の議論と重圧 
 - すぐに改善して！と言われる重圧
 - 突然「うちの開発、遅くないか？生産性上げてほしい」と言われる 
 - 重要プロジェクトで「とにかく早く」という重圧の中、要件定義が不十分なまま開発が進む 
 - 仕様変更が相次ぎリリース後にバグが多発し、サポート対応に追われる事態に発展する 

8. 無意味な開発生産性の議論、開発生産性という重圧
 よくある開発生産性の議論と重圧 
 - 重圧から生み出される小手先の指標へ
 - すぐに出せる数値に飛びついてしまう
 - 数値を目標をするとハックする。グットハートの法則 
 - 測れない生産性を説明しなければいけない重圧
 - 測りづらい生産性（技術負債やリファクタリングなど）を説明しないと工数が避けない 
 「コスト」ではなく、将来への「投資」であることを伝える 
 実際リファクタリングに否定的な事業サイドの人はおらず、「なぜか」を説明できないエンジニアが多い。 

9. 無意味な開発生産性の議論、開発生産性という重圧
 よくある開発生産性の議論と重圧 
 - エンジニアだけが生産性を求められる重圧
 - 後ろの工程に行けば行くほど、遅さが”見つかりやすい” 
 3人月 1人月 2人月 0.2 1人月 要求・要件定義 設計 開発 QA リリース なんか遅くない？ このままだと間に合わなくない？ Lead Time

10. 10 Table of Contents
 - 無意味な開発生産性の議論、開発生産性という重圧
 - 感覚に頼らない開発生産性低下の予兆検知
 - AIによって開発生産性はどう変化したのか
 - AIへの投資と人への投資によるお金の変化

11. 11 開発生産性”低下”の構造と解消
 開発
 0→1
 健全な
 ソフトウェア
 変更容易性が低い
 ソフトウェア
 t 健全な
 ソフトウェア
 【抑制】
 負債の進行をできるだけ遅らせる
 【解消】
 負債の解消を早める
 【予兆検知】
 予兆をモニタリングし、アラートをかける

12. 12 開発
 0→1
 健全な
 ソフトウェア
 変更容易性が低い
 ソフトウェア
 どのプロセスで保守性が悪いソフトウェアができて、
 開発生産性が下がっていくかの予兆検知する
 仕様書
 開発環境
 バージョン管理・CI/CD 
 テスト・静的解析 
 CI/CD
 RC / STG / PRD
 ・コードの複雑性
 ┗ クラス・モジュール設計 
 ┗ SOLID原則 
 ・〇〇図の欠如による仕 様漏れの手戻り
 
 ・環境差異による障害 
 ・可観測性の欠如
 ・テストケース漏れ
 ・リリース作業の属人化 
 開発生産性”低下”の構造と解消

13. 感覚に頼らない開発生産性低下の4つの予測検知
 - 計画見積もりと実績値の差分で予兆検知
 - ブラックボックステスト
 
 - 障害件数の再発防止策完了件数で予兆検知
 - ポストモーテム分析
 
 - 投資している開発区分で予兆検知
 - 新規での開発
 
 - エンゲージメントスコアの低下で予兆検知
 - 社員モチベーションの移動平均 
 
 

14. 14 計画見積もりと実績値の差分（ブラックボックステスト）
 で予兆検知する
 引用: IPA 「IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 最新定量データと分析結果」 
 計画より上回っている
 計画より下回っている

15. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 
 リリース
 （実績）
 
 1人月
 10人月
 一般的に
 このぐらいだろう
 (類推見積もり)
 バックログ
 アイテムに分解した
 結果、倍ぐらいか かった
 PRD / DD
 書いた
 企画
 設計→Ready
 開発中
 振り返り
 予測（見積もり）
 コミットメント（約束）
 実績
 15
16. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 
 リリース
 （実績）
 
 1人月
 10人月
 一般的に
 このぐらいだろう
 (類推見積もり)
 バックログ
 アイテムに分解した
 結果、倍ぐらいか かった
 PRD / DD
 書いた
 企画
 設計→Ready
 開発中
 振り返り
 ここのズレが大きいと予 兆あり
 色んな原因が混在
 16
17. 17 障害件数の再発防止策完了件数
 で予兆検知する
 
 1月
 2月
 3月
 4月
 5月
 6月
 発生件数
 +3
 +2
 +4
 0
 +1
 +3
 再発防止策完了件数 
 +1
 +2
 +0
 +1
 +3
 +2
 残 : 再発防止策完了件数 
 2
 2
 6
 5
 3
 2
 障害件数だけではなく 
 再発防止策が完了できているか 
 その分、新規開発リソースを圧迫する。 
 ただし、スケジュールはそのままなことが多い 
 ポストモーテムを分析し、だいたい同じ箇所・プロセスで障害になっていないか 
 設計ミスでバグ混入 / デプロイ周辺で障害 / 特定のメンバー作業
18. 18 投資している開発区分で予兆検知
 で予兆検知する
 A A 正しいプロダクトに正しい工数を部門として投資できているか
 （運用コストが大きくなっていないか、リファクタリングなどに工数をかけているか） 

19. 19 エンゲージメントスコアの低下
 で予兆検知する
 
 モチベーションサーベイでの変化
 wevox / SPACE / 社内アンケート...etc 

20. 予兆検知の閾値を組織で決める
 SLOを決めるように
 20
21. 21 Table of Contents
 - 無意味な開発生産性の議論、開発生産性という重圧
 - 感覚に頼らない開発生産性低下の予兆検知
 - AIによって開発生産性はどう変化したのか
 - AIへの投資と人への投資によるお金の変化

22. AIエージェントによる働き方の変化
 過去 現在 成果物は物理的な時間と人が 同 期していた
 ガードレール役に徹する （CodeRabbit等で短縮） 人の物理的な時間と成果物が 
 非同期で出てくる
 いまから 成果物の担保もほぼAIへ （生産量に対してレビューがしんどくなる） 人は問いと出口の判断へ
 （作業からの脱却）
 22 問いと判断
23. 23 Claude Codeの90-95%は、Claude Codeが書いている

24. 1. AIが生成したコードを読み取り・修正できる能力は必須 
 「CopilotなどがPRを投げてくるワークフローは便利だが、開発者が自分の手で数秒で直 せなければ、逆に 3 秒の作業が 3 分に延びる」と警告 
 
 
 2. “コードを書く力”は依然としてエンジニアリングの基礎 
 AIに仕事の一部を委ねる時代でも大規模システムを設計し進化させるには手動コーディン グのクラフト（モノづくりの能力）が欠かせない 
 
 
 3. AIは置き換えではなく“拡張” 
 AIエージェントが単純作業を肩代わりすることで、エンジニアは問題分割・仕様策定・シス テム全体設計といった創造的タスクに集中できる 
 GitHub CEOによるAIコーディング

25. 1. AIが生成したコードを読み取り・修正できる能力は必須 
 「CopilotなどがPRを投げてくるワークフローは便利だが、開発者が自分の手で数秒で直 せなければ、逆に 3 秒の作業が 3 分に延びる」と警告 
 
 
 2. “コードを書く力”は依然としてエンジニアリングの基礎 
 AIに仕事の一部を委ねる時代でも大規模システムを設計し進化させるには手動コーディン グのクラフト（モノづくりの能力）が欠かせない 
 
 
 3. AIは置き換えではなく“拡張” 
 AIエージェントが単純作業を肩代わりすることで、エンジニアは問題分割・仕様策定・シス テム全体設計といった創造的タスクに集中できる 
 GitHub CEOによるAIコーディング
 開発生産性という観点から見ると、品質を伴った 生産量が爆増し 、
 無意味な開発生産性の議論は姿を消すでしょう 
 
 一方、AIを巧みに活用できている組織とそうではない組織の 差が
 かつでないほど鮮明になる 
 
 逆に活用できていない組織は、より開発生産性の 重圧を受けることにな る

26. 26 AI活用は開発フェーズだけに留まらせてはいけない 
 
 プロセスを"AI"に置き換えるのではなく、 
 "AI"前提のプロセスに作り変えること で
 開発生産性の勘所を変える 

27. プロセスを"AI"に置き換えるのではなく、 
 "AI"前提のプロセスに作り変える 
 
 
 “コード行数やAI提案承認率など単純な生産性指標 は技術的負債や品質低下を見逃す”
 
 “AI導入の本質的効果は、リードタイム・サイクルタ イム・デプロイ頻度・欠陥数・顧客満足などビジネス 成果指標で測るべき”
 
 “AIで生成されたコードもレビュー・テスト・保守に時 間がかかるため、エンドツーエンドの観点で定量・ 定性評価を行う必要がある”
 

28. プロセスを"AI"に置き換えるのではなく、 
 "AI"前提のプロセスに作り変える 
 
 
 AI - BPR （Business Process Re-engineering) を前提に作り直す 
 
 ゼロベースで業務を作り直すアプローチ 
 既存業務の「延命」や「部分改良」ではなく、白紙から再構築する 
 居所的なプロセスでのAI導入 による効率化ではなくプロセス全体を見る 
 
 1. 現状分析（As-Is） 
 2. コアプロセス抽出
 3. 理想設計（To-Be） 
 4. IT・組織・人材を再配置 
 5. 移行計画・実装
 
 → ECRSの原則（イクルス）でプロセスを見直すのがおすすめ 
 28
29. 業務プロセスを洗い出し
 約200名の業務プロセス ※ 詳細はいらずにボリュームを測るため、概略・傾向値で良い 
 29
30. ≈ 制約投資の判断
 - 課題の共通性・隔たり
 - 課題のボリューム感（工数）
 - AIプロセスの投資対効果
 業務プロセス区分 1. 運用工数
 a. 問い合せ・顧客対応 
 b. 障害対応・ルーチンワーク 
 2. 組織管理工数 
 a. 組織管理のルーチンワーク 
 b. プロジェクトルーチンワーク 
 3. 新規開発工数 
 a. 要件定義・企画フェーズ 
 b. 設計フェーズ 
 c. 実装フェーズ 
 d. テストフェーズ 
 e. デプロイ
 4. 保守開発
 a. リファクタリング 
 
 業務プロセス抽出 - プロセス / 目的 / 課題
 30
31. 1Qが終わったタイミングでのアンケート実施結果
 ▼ 依頼事項 
 1. グループごとの業務プロセスを可視化しました。 
 2. 自分が所属するグループのC列の業務プロセスにおいて「AIエージェントの利用率」を回答してください 
 
 業務プロセスのカテゴリー 
 1. 障害対応・ルーチンワーク 
 2. 組織管理のルーチンワーク 
 3. プロダクト、プロジェクトルーチンワーク 
 4. 要件定義・企画フェーズ 
 5. 設計フェーズ 
 6. 実装フェーズ 
 7. テストフェーズ 
 8. リリースフェーズ 
 9. 保守開発
 
 有効回答率 : 93%（180名回答） 
 31
32. aグループ bグループ cグループ dグループ eグループ fグループ gグループ hグループ rグループ jグループ kグループ lグループ mグループ nグループ oグループ 業務プロセスごとのAIエージェント利用率の結果
 「すべてのプロセスをAI前提で作っていく」
 32
33. aグループ bグループ cグループ dグループ eグループ fグループ gグループ hグループ rグループ jグループ kグループ lグループ mグループ nグループ oグループ 業務プロセスごとのAIエージェント利用率の結果
 「弱い部分に対してAI全体のプロセスを作っていく」
 33 AIエージェントの介在によって、
 エンジニア領域だけが開発生産性の議論をする時代から、
 職種関係なく全プロセスをAIによって、
 プロセス短縮が議題に上がる時代へ 
 
 = 全員が開発生産性（リードタイム）の当事者へ
 すべてのプロセスが開発生産性の議論へ
 33
34. 34 Table of Contents
 - 無意味な開発生産性の議論、開発生産性という重圧
 - 感覚に頼らない開発生産性低下の予兆検知
 - AIによって開発生産性はどう変化したのか
 - AIへの投資と人への投資によるお金の変化

35. 人によるスケーリングから、AIによるスケーリング
 + + + 人を増やして、スケール
 
 個の生産性を上げて、スケール
 
 個とAIを増やして、スケール
 
 + Lead Time
 早

36. 
 人材関連費
 ・給与手当
 ・賞与
 ・法定福利費
 ・福利厚生費
 ・地代家賃
 ・採用費
 販管費/支払手数料
 （ライセンス料） P/L
 + + + + 人にかかるお金とAIにかけるお金による変化
37. AIへの投資対効果について AIはツールなので投資対効果を出したいが、
 リソースという観点で
 人を増やしたときはそれを求めるのが難しい。
 その前提に立ったときに今考えていること
 

38. AIへの投資対効果の観点
 - 「感覚的には早くなっている」をどう自分たちの行動ログとして表出化させるか
 - 定量データで言えば「AIに置き換え」と「AIとの協働」で難易度は違う
 - └ AIに置き換え → 人でやっていたものを丸々削減時間とする
 - └ AI協働→人でやったときの予測とAI協働での実績比較であれば簡単に出せるが、 それでよいかはわからない
 - 他社事例を分析しつつも、模索中
 

39. AIへの投資対効果の観点
 - スピード（生産性）と品質の両方を考慮する
 - → 品質を落として量産しても意味がない。逆に負荷がかかるだけになる 
 - 単一プロセスの最適化ではなく、バリューストリーム全体を見る
 - → 生産量が多くなっても、変更障害率が多くなっている等 
 - 多元的な評価で投資対効果を見る（今のところ筋が良さそう）
 - → 単一的な評価の積み重ねで「1人がAIエージェント活用で生産量が n倍になる傾向があ る」と言いたい
 - それを人材関連費とAIへの外注加工費の比較しながら組織投資を考えたい 
 - ex. ノイズを取り除いた状態で理想の動き方をしているメンバーのPR数の推移をAI活用 前後で見るところからスタート。その他、SPACEなどの定性評価や 筋が良さそうな指標 を組み合わせて生産活動の変化傾向 を見ていく

40. 40 まとめ
 - 無意味な開発生産性の議論、開発生産性という重圧
 - 感覚に頼らない開発生産性低下の予兆検知
 - AIによって開発生産性はどう変化したのか
 - AIへの投資と人への投資によるお金の変化