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

by Masato Ishigaki / 石垣雅人

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 About me  石垣雅人  合同会社 DMM.com    プラットフォーム開発本部副本部長 / 第1開発部部長  VPoE室 / アルファ室    ・連載中 : 『開発生産性の多角的視点』（CodeZine）   ・連載中 : 『スモールチームが武器になる時代へ』（ProductZine）   ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方』（NewsPicks）    2

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  (類推見積もり)  バックログ  アイテムに分解した  結果、倍ぐらいかかった  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り  予測（見積もり）  コミットメント（約束）  実績  15

Slide 16

Slide 16 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  (類推見積もり)  バックログ  アイテムに分解した  結果、倍ぐらいかかった  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り  ここのズレが大きいと予兆あり  色んな原因が混在  16

Slide 17

Slide 17 text

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  障害件数だけではなく   再発防止策が完了できているか   その分、新規開発リソースを圧迫する。   ただし、スケジュールはそのままなことが多い   ポストモーテムを分析し、だいたい同じ箇所・プロセスで障害になっていないか   設計ミスでバグ混入 / デプロイ周辺で障害 / 特定のメンバー作業

Slide 18

Slide 18 text

18 投資している開発区分で予兆検知  で予兆検知する  A A 正しいプロダクトに正しい工数を部門として投資できているか  （運用コストが大きくなっていないか、リファクタリングなどに工数をかけているか）  

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

予兆検知の閾値を組織で決める  SLOを決めるように  20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

23 Claude Codeの90-95%は、Claude Codeが書いている 

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

プロセスを"AI"に置き換えるのではなく、   "AI"前提のプロセスに作り変える       AI - BPR （Business Process Re-engineering) を前提に作り直す     ゼロベースで業務を作り直すアプローチ   既存業務の「延命」や「部分改良」ではなく、白紙から再構築する   居所的なプロセスでのAI導入による効率化ではなくプロセス全体を見る     1. 現状分析（As-Is）   2. コアプロセス抽出  3. 理想設計（To-Be）   4. IT・組織・人材を再配置   5. 移行計画・実装    → ECRSの原則（イクルス）でプロセスを見直すのがおすすめ   28

Slide 29

Slide 29 text

業務プロセスを洗い出し  約200名の業務プロセス ※ 詳細はいらずにボリュームを測るため、概略・傾向値で良い   29

Slide 30

Slide 30 text

≈ 制約投資の判断  - 課題の共通性・隔たり  - 課題のボリューム感（工数）  - AIプロセスの投資対効果  業務プロセス区分 1. 運用工数  a. 問い合せ・顧客対応   b. 障害対応・ルーチンワーク   2. 組織管理工数   a. 組織管理のルーチンワーク   b. プロジェクトルーチンワーク   3. 新規開発工数   a. 要件定義・企画フェーズ   b. 設計フェーズ   c. 実装フェーズ   d. テストフェーズ   e. デプロイ  4. 保守開発  a. リファクタリング     業務プロセス抽出 - プロセス / 目的 / 課題  30

Slide 31

Slide 31 text

1Qが終わったタイミングでのアンケート実施結果  ▼ 依頼事項   1. グループごとの業務プロセスを可視化しました。   2. 自分が所属するグループのC列の業務プロセスにおいて「AIエージェントの利用率」を回答してください     業務プロセスのカテゴリー   1. 障害対応・ルーチンワーク   2. 組織管理のルーチンワーク   3. プロダクト、プロジェクトルーチンワーク   4. 要件定義・企画フェーズ   5. 設計フェーズ   6. 実装フェーズ   7. テストフェーズ   8. リリースフェーズ   9. 保守開発    有効回答率 : 93%（180名回答）   31

Slide 32

Slide 32 text

aグループ bグループ cグループ dグループ eグループ fグループ gグループ hグループ rグループ jグループ kグループ lグループ mグループ nグループ oグループ業務プロセスごとのAIエージェント利用率の結果  「すべてのプロセスをAI前提で作っていく」  32

Slide 33

Slide 33 text

aグループ bグループ cグループ dグループ eグループ fグループ gグループ hグループ rグループ jグループ kグループ lグループ mグループ nグループ oグループ業務プロセスごとのAIエージェント利用率の結果  「弱い部分に対してAI全体のプロセスを作っていく」  33 AIエージェントの介在によって、  エンジニア領域だけが開発生産性の議論をする時代から、  職種関係なく全プロセスをAIによって、  プロセス短縮が議題に上がる時代へ     = 全員が開発生産性（リードタイム）の当事者へ  すべてのプロセスが開発生産性の議論へ  33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

  人材関連費  ・給与手当  ・賞与  ・法定福利費  ・福利厚生費  ・地代家賃  ・採用費  販管費/支払手数料  （ライセンス料） P/L  + + + + 人にかかるお金とAIにかけるお金による変化

Slide 37

Slide 37 text

AIへの投資対効果について AIはツールなので投資対効果を出したいが、  リソースという観点で  人を増やしたときはそれを求めるのが難しい。  その前提に立ったときに今考えていること   

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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