AIで開発は速くなったのに、なぜ現場は楽にならないのか 〜あなたの組織のボトルネックを突き止めるワークショップ〜

DXシステム開発Expo 2026で発表した資料です。
AIで開発は高速化したが組織のアウトプットにはつながっていないことと、その原因。そして解消するためのDevOps, SRE, プラットフォームエンジニアリング、インシデント管理について説明します。

Transcript

1. AIで開発は速くなったのに、 なぜ現場は楽にならないのか 〜あなたの組織のボトルネックを突き止めるワークショップ〜
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan 代表理事 @一般社団法人クラウドネイティブイノベーターズ協会 理事 @一般社団法人SREコネクト
3. いま、世界の開発者はどうなっているか 90% 2時間 80%超 業務でAIを使っている開発者 (前年から +14ポイント) 1⽇あたりの利⽤時間 (中央値) ⽣産性が上がったと 感じている 新しいコードを書く 71% ただし、AIが書いたコードを 技術⽂献を調べる 68% 「ほとんど信頼していない」⼈が 30% 既存コードを直す 66% DORA 2025 State of AI-assisted Software Development(世界の技術専⾨職 約5,000⼈)
4. 作り手が変化した いま これまで ソフトウェアエンジニア ↓ アプリケーション エンジニア / 企画 / デザイナー/ 情シス ↓ アプリケーション
5. 作り手が変化した いま これまで ソフトウェアエンジニア ↓ アプリケーション エンジニア / 企画 / デザイナー/ 情シス ↓ ※ただし、増えたのは「作る⼈」だけ。 レビューする⼈も、運⽤し続ける⼈も増えていない アプリケーション
6. 作れることと、ビジネスになることは違う 企画 開発 レビュー テスト AIが⾼速化しているのは、この6分の1だけ PR数 +98% レビュー所要時間 中央値 5倍 PRあたりインシデント +243%(3.4倍) 週あたりデプロイ −11.7% 「作ること」はできても、「作り続けること」ができない Faros AI, AI Engineering Report 2026(2.2万⼈‧4,000チームのテレメトリ) リリース 運⽤
7. スループットは向上していない 1⽇あたりワークフロー実⾏数の前年⽐(チームの階層別) 上位 5% +97% 上位 10% +47% 上位 25% +25% 中央値 +4% 下位 25% ±0% フィーチャーブランチ main ブランチ +7.7% 完全に横ばい ⼿元は速くなったが、本番に出ていく量はあまり増えていない CircleCI 2026 State of Software Delivery(2,800万ワークフロー / 22,000組織 / 149か国)、Q2 Pulse
8. シミュレーションしてみよう
9. この問題を実証するためのシミュレーターを作りました。 AI開発をしない状態だと、リードタイム17.5日、フロー効率23% 開発がボトルネックとなっています。
10. AI開発を導入すると、開発が高速になりボトルネックではなくなりました。 一方で、テストやデプロイ、本番運用がボトルネックとなり、リードタイムは 26.4日と悪化してしまいました。
11. AI開発は組織を楽にしない AIコーディング 0% → 100% で何が変わったか 開発の実作業時間 2.0⽇ → 0.5⽇ リードタイム 17.5 ⽇ → XX ⽇ フロー効率 23 % → XX % ボトルネック 開発 → テスト / リリース / 運⽤ 開発だけが速くなった。そして、誰も楽になっていない
12. AIで開発を高速化しても、他の部分がボトルネックとなる 企画 開発 レビュー AIを⼊れると 開発 → テストへ テストを⾃動化すると テスト → レビューへ レビューを軽くすると レビュー → 運⽤へ ‧ボトルネック以外の改善は、全体の改善にならない(制約理論) ‧終着点は運⽤。出し続けたときに現れる テスト リリース 運⽤
13. ボトルネックを解消する案①: DevOps 開発と運⽤の分断をなくし、⼩さく‧速く‧繰り返し出せるようにする ⾃動化する ⼩さく出す 速く返す ⼿でやっていた 2週間分をまとめず、 壊れたことが テストとデプロイを パイプラインへ 変更1件ずつ 本番へ運ぶ 数分でわかる 状態をつくる Create Plan Release Dev Verify Package Configure Ops Plan Monitor 速く出すより先に、⼩さく出す
14. シミュレーションしてみよう
15. DevOpsを実践すると、毎回14日かかっていたデプロイが0.1日に短縮。 即座にリリース出来るようになり、デプロイ頻度が7倍になりました。 一方でリードタイムは18日と、まだ長いなと感じられます
16. 本番で起こる障害が、開発を阻害する デプロイ頻度が上がったあとに、何が起きたか デプロイが増える 本番の変更が 積み上がる インシデントが起きる インシデント 1件で 開発の能⼒が 半分に インシデント 2件で 開発の能⼒が 3分の1に 計画作業に使えた割合 下がり続ける ボトルネックの位置 テスト → 運⽤ へ移動 AIで空けたはずの時間を、計画外の割り込みが消費していく Faros AI 2026: PRあたりインシデント +243% / DORA 2025: AI採⽤はスループットと正、安定性とは負の関係 対応が開発リソースを 消費
17. 信頼性を上げる 最も効率のいい方法
18. なにもしないこと
19. 障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。したがって、デ プロイが増えると障害も増え、結果としてインシデント管理、軽減策、ポ ストモーテムが必要となる” エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか より引用 https://www.amazon.co.jp/dp/4296070916 ⇨ 開発が高速化するとデプロイも増え、インシデントが増える
20. だからデプロイ減らしましょ ･･･とはならない (ですよね？) 今の世の中勝ち残るには、素早く開発して素早く市場に投入するという取り組みが必須。 だからこそ、アジャイル開発やDevOpsが必要とされる でもそれだとインシデントが増えるので、SREが必要となる
21. ボトルネックを解消する案②: SRE Site Reliability Engineering Googleが提唱した、信頼性の高いシステム運用のアプローチ 「ソフトウェアエンジニアリングの手法で運用課題を解決する」 • • • 手作業の自動化 システムの信頼性を定量的に管理 障害は学習の機会 主要な概念 • • • SLI/SLO/エラーバジェット：信頼性の数値化と管理 Toil（無駄な作業）の削減：繰り返し作業の自動化 ポストモーテム：障害から学ぶ文化
22. SREが行うこと SLI/SLO‧Toil‧ポストモーテムを、⽇々の⾏為に置き換えると 測る ユーザー体験に関わる信頼性を数値にする(SLI / SLO) 守る 出す速さと安定性の配分を、エラーバジェットで決める 減らす ⼿順書どおりの繰り返し作業(Toil)をコードにする 学ぶ ポストモーテムで、⼈ではなく仕組みを直す 4つとも、本番で起きたことを設計に返す⾏為
23. アジャイルやDevOpsは左から右の流れ を 継続的に改善 SREは右から左 のアプローチで改善し、信頼 性を高めていく
24. なぜ右から左の流れが重要なのか 左から右 開発 → 運用だけの世界 • • • • 開発は本番の実態を知らない 同じ障害の繰り返し 運用チームの疲弊（Toilの増大） 「動けばOK」からの脱却不可 右から左 🔄 プロダクションからのフィードバック 運用の知見を開発に還元 • • • • 実際のパフォーマンスデータ 障害パターンの分析結果 ユーザーの使用実態 インフラのボトルネック情報 📊 データドリブンな改善 測定可能な指標で判断 • • • SLI/SLOに基づく優先順位付け エラーバジェットでの開発速度調整 根本原因の設計レベルでの解決
25. シミュレーションしてみよう
26. SREを実践することで、変更失敗率の低下や復旧時間が短縮。 リードタイムは13.6日になりました。デプロイ頻度も上がっていますね 本番の負担が減った結果、今度はレビューがボトルネックになりました。
27. プラットフォーム エンジニアリング
28. プラットフォームとは 開発者や運用者に役立つ機能、たとえば • • • • • セルフサービスのAPI ツール サービス ナレッジ サポート を「魅力的な社内プロダクト」として整備した基盤のこと。 共通の機能を提供し管理することで、開発者やオペレーターがアプリケーションやサービスを迅速に提供 することを可能にする。 プラットフォームは、プラットフォームチームによって構築・維持される。
29. 空港でたとえると 空港には多くのエアラインが就航しており、それを 旅客が利用している。 空港のチェックインカウンターや保安検査、ショッ ピング、その他様々な施設 滑走路や管制塔、給油設備などの航空機向け施設 これらは、エアラインが運営しているわけではな い。空港という共通インフラを提供する管理会社 が、各エアラインに提供している。
30. プラットフォームとは 開発者や運用者に役立つ機能、たとえば • • • • • セルフサービスのAPI ツール サービス ナレッジ サポート を「魅力的な社内プロダクト」として整備した基盤のこと。 共通の機能を提供し管理することで、開発者やオペレーターがアプリケーションやサービスを迅速に提供 することを可能にする。 プラットフォームは、プラットフォームチームによって構築・維持される。
31. 便利！ 便利！ 開発者 運用者 App Platform
32. プラットフォームエンジニアリング とは この定義に該当するプラットフォームを設計・構築する分野
33. 90 2025年現在、 90%の組織が少なくと も1つの内部プラットフォームを採用。 組織の76%が少なくとも 1つの専任プ ラットフォームチームを擁する % 出典: 2025 DORA Report: State of AI-Assisted Software Development
34. なぜ今注目されているのか
35. やることが多い！ なにかひとつアプリケーションを開発したいと思ったと き、開発する言語やフレームワーク以外にも考えるべき 要素がとても多い。 • • • • • • • • • CI CD Dockerfile k8sマニフェスト オブザーバビリティ IaC セキュリティ データベース etc…
36. 認知負荷の増大が問題に https://www.infoq.com/articles/platform-engineering-primer/ より引用 クラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、 エンジニアの責任範囲の拡大により認知負荷が大変なことに
37. 認知負荷の増大による生産性の低下が 無視出来なくなりつつある
38. 2つのIDP Internal Developer Platform Internal Developer Portal 開発チームがインフラやツールを効率的に 利用できるようにするための内部向けプ ラットフォーム 開発者向けのインターフェース。 Internal Developer Platformに 含まれることも多い インフラ、CI/CD、監視、認証などを抽象 化し、開発チームがアプリ開発に集中でき るようにする。 自社のサービスやインフラ、ツールの情 報を一元化し、開発者が必要なリソース や情報に簡単にアクセスできるようにし たもの。 インフラやサービスの自己管理を支援し、 「セルフサービス」で素早く安全に操作で きるように設計する。 ドキュメントやAPI仕様、サービスの稼 働状況をカタログ形式で表示したり、検 索可能にしたりする。
39. ゴールデンパス ベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安全にアプリケーション を開発・運用できるようにした一連のルートや仕組みのこと • • • 開発者の認知負荷を減らす セキュリティやコンプライアンスを自然と担保する 開発チームがビジネス価値の創出に集中できるよう支援する 例えば • • • 新規サービス生成時に使えるテンプレート テストやCI/CDパイプラインのセットアップスクリプト モニタリングやログ収集などの運用機能のガイド
40. こういう要素が入ってきます
41. シミュレーションしてみよう
42. プラットフォームエンジニアリングを実践したことで、 リードタイムは3.4日と劇的に短縮。デプロイ頻度も爆増しています。 レビューだけでなく、開発、テスト、リリースへの 流れがスムーズになった効果です。
43. プラットフォームエンジニアリングやれば劇的に変わるなら、 他は要らないじゃん？と勘違いしないように注意です。 SREをやめたら、リードタイムが激しく悪化しました。 決して銀の弾丸ではなく、開発・運用の文化を変えてこそ効果が出るのです。
44. インシデント管理
45. あなたは人気ECサイトのエンジニアです。 ある日、サイトが突然重くなり、監視アラートが飛びました。 「DBのCPU使用率95%超」 調査を始めると、営業から電話が入ります。 「クライアントが注文できないって言ってる。いつ直る？」 今度はカスタマーサポートからチャットが来ます 「問い合わせ急増中。お客様に何と説明すれば？」 SNSでは「またこのサイト落ちてる」と拡散が始まっています。 システムからはアラートが次々と発報され、チャットには「状況報告 まだ？」が積み上がる。焦るほど、ミスしそうになります。
46. ここで起きた問題は、「システム障害」だけ？ 確かに障害がトリガー、でも組織の混乱の本当の原因は 📡 不十分な情報連携 💬 コミュニケーションの不足 📋 対応ルールの欠如 障害の復旧だけでは根本解決にならず システム障害がもたらすビジネスへの影響という問題は 残ったまま。
47. ステークホルダーごとの「恐れ」 👔 経営層(エグゼクティブ ) 💼 セールス・営業 必要なのは「ビジネスインパクト」 商談中の顧客から「御社のサービス大丈夫？」 と言われたら･･･ • • • いくらの損失が出るのか 法的リスクはあるのか メディア発表は必要か たった一度の障害が、数ヶ月かけて築いた 信頼関係を崩壊させ、契約を白紙に戻す可能性があ る。 情報がなければ、適切な判断を下せない 📣 広報・マーケティング 🎧 カスタマーサポート SNSでの炎上は秒単位で拡散する。 沈黙は「隠蔽」と受け取られかねない。 顧客との最前線にいる人たち。システムが止まると、 怒った顧客からの電話やチャットが殺到。 適切なタイミングでの発信が、ブランドイメージを守る 鍵。 彼らにとって凄まじいストレスであり、 離職の原因にもなり得る。 技術面だけでなく、各ステークホルダーの不安を解消しなくてはいけない
48. インシデントを「管理」することが重要 技術的な対応を行う障害対応だけでなく、組織やビジネスの視点を含めて問題を解決していくた めのインシデント管理が、今後の世の中では必要不可欠。 障害対応 インシデント管理 🔧 視点： システム（技術） 🏢 視点： 組織（ビジネス） 🎯 目的： 壊れたものを直す（復旧） 👥 主語： 組織全体 🎯 目的： ビジネスへの影響を最小化し、信頼を維持する ⚡ アクション： • • • • サーバーの再起動 コードのロールバック ログの調査 データベースのフェイルオーバー など。 ⚡ アクション： • • • • • 状況の指揮 ステークホルダーへの報告 役割分担 顧客対応 再発防止策の策定 など。
49. まずは基本をしっかりと オブザーバビリティ メトリクス、ログ、トレース が整備され、異常の検知 と原因追跡が可能な状態 Proprietary & Confidential インシデント対応 プロセス構築 情報共有と 連絡手段 初動対応から復旧、事後 分析までの標準化された フロー コミュニケーションチャネ ル整備、ステークホル ダーとの定期報告や広報 プロトコル
50. インシデントが起きたときには 一次対応者 (応答がなければ) 二次対応者 Observability 必要なアラートだけに絞り込み 電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知 オンコールの ローテーション
51. インシデント対応プロセスの確立 責任の所在 と 意思決定の経路 を明確にし 情報の流れ をコントロールする インシデントコマンダー (IC)を 中心とした命令指揮系統を構築 ICはインシデント対応の指揮者。 重大インシデントを解決に導く ことを目的とし、 意思決定 を行う。 このフローがない場合 アラート検知 → ？？？ AIは「次に何をすべきか」を提案できず、 各人がバラバラに動く CIO ユーザー ユーザー担当 インシデントコマンダー 別チーム �� �� 作業担当
52. 適切なコミュニケーション インシデント対応チーム内 ICを中心とした、意思決定と指揮を 行う密な連携 ステークホルダーとのコミュニケーション CIO インシデントコマンダー Sales Support リエゾン 書記 レスポンダー Dev
53. ステークホルダーと のコミュニケーション 経営的な意思決定、対外的な情報発信のために 重要。3つの「適切」を意識 • CIO 適切な粒度 ◦ 技術的な詳細までは不要 ◦ 何が起きているか 、今何をしているか 、今後 の見通し を伝える • 適切な方法 ◦ ブロードキャスト型 を徹底 ◦ 戦時における1:1のコミュニケーションは、 Sales Support 取り返しの付かない遅延を招く • 適切なタイミング ◦ 定期的 (1時間おき、など) ◦ ステータスに変化があったとき Dev
54. シミュレーションしてみよう
55. インシデント管理を実施することで本番での変更失敗率や 復旧時間が大きく改善。結果としてリードタイムが安定して1.6日、頻度が 14.5/週になりました。こうしてはじめて AI開発による効果を最大化できたのです。
56. AIは、いいところも悪いところも 増幅する
57. AIは、いいところも悪いところも増幅する すでに流れている組織 すでに詰まっている組織 AIを入れると もっと速くなる AIを入れると 詰まりがもっと大きくなる ・AIはチームを直さない。すでにそこにあるものを大きくする ・スループットは正に転じた。ただし安定性は負のまま ・増幅を正に向ける条件は、質の高い社内プラットフォーム・明確なワークフロー・強い自動テストと速い フィードバック AIを⼊れる前に、増幅されて困るものがないかを知っておくことが⼤事 DORA 2025 State of AI-assisted Software Development
58. Value Stream Mapping リリース アイディア LT(リードタイム): 31日 PT(プロセスタイム): 8.75日 Production 分析 デプロイ LT: 2d / PT: 1d LT: 1d / PT: 2h 設計 リリース 判定会議 LT: 3d / PT: 2d LT: 10d / PT: 1h 開発 コード レビュー LT: 4d / PT: 3d LT: 1d / PT: 4h Staging デプロイ テスト UAT 品質判定 会議 LT: 1d / PT: 2h LT: 1d / PT: 6h LT: 7d / PT: 1h パフォーマ ンステスト LT: 1d / PT: 6h
59. Value Stream Mapping リリース アイディア LT(リードタイム): 31日 ⇨ 14日 PT(プロセスタイム): 8.75日 ⇨ 8.5日 Production 分析 AIより先に この会議を何とか すべきでは？ LT: 2d / PT: 1d デプロイ LT: 1d / PT: 2h 設計 リリース 判定会議 LT: 3d / PT: 2d LT: 10d / PT: 1h 開発 コード レビュー LT: 4d / PT: 3d LT: 1d / PT: 4h Staging デプロイ テスト UAT 品質判定 会議 LT: 1d / PT: 2h LT: 1d / PT: 6h LT: 7d / PT: 1h パフォーマ ンステスト LT: 1d / PT: 6h
60. おわりに ・AIで速くなったのは開発だけ。その速さを組織で活かそうとすると、他の場所がボトルネック ・AIは増幅器。組織のいいところも、悪いところも大きくする ・開発・運用両面で良いプラクティスを取り入れ、よりよい開発文化を作ることが大事 DevOps SRE インシデント管理 Platform Engineering 流れを速く、 小さく出す 燃えにくく する 燃えても 早く消す 認知負荷を下げ、 詰まりと事故を防ぐ まずは、自分の組織のボトルネックがどこにあるか見つけるところから始めよう
61. ボトルネックシミュレータ 本発表で利用したボトルネックシミュレータをこちら のURLで公開しています。 DevOps, プラットフォームエンジニアリング、SRE、 インシデント管理などの効果を説明するのに活用して ください。 もちろんこれもAIフル活用で作っています。 こういうちょっとしたアプリ作るだけなら何も気にし なくていいんですけどねー。 こいつにバックエンド付けて、有料化して、サービスと して細かくリリースして･･･とビジネスにすると、本稿 で解説したような問題に当たっちゃうんですよね。 https://bottleneck-simulator.paas.jp/