プレゼンテーション：摩擦から流れへ：優れた開発者体験がいかにすべてを素晴らしくするか
ニコール・フォースグレンは、AIによるコード生成の加速がデプロイのボトルネックを高コスト化する「AI生産性パラドックス」を説明し、DORAメトリクスとRICE優先順位付けを用いたデータ駆動型のDevExフレームワークを共有した。
キーポイント
AI生産性パラドックスの説明
AIツールによるコード生成の高速化が、デプロイパイプラインのボトルネックをより高コストなものにする逆説的な現象について説明している。
DevExフレームワークの共有
開発者体験（DevEx）を向上させるための体系的フレームワークを提示し、アーキテクトやリーダーが摩擦を除去する方法を示した。
データ駆動型アプローチの提案
DORAメトリクス（デプロイ頻度、リードタイムなど）とRICE優先順位付けモデルを用いて、プラットフォーム健全性への投資根拠をデータで示す方法を提案している。
影響分析・編集コメントを表示
影響分析
この発表は、AIツール導入の盲点である「生産性パラドックス」に警鐘を鳴らし、DevOps成熟度の測定と改善に実践的なフレームワークを提供する点で意義がある。特に、DORAメトリクスとRICE優先順位付けの組み合わせは、多くの組織で応用可能なデータ駆動型アプローチを示している。
編集コメント
AIツール導入の「見えないコスト」に焦点を当てた現実的な視点が評価できる。理論ではなく実践的なフレームワークを提供している点で、現場のエンジニアリングリーダーに直接役立つ内容と言える。
InfoQ ホームページ
プレゼンテーション
摩擦からフローへ：優れた DevEx がすべてを素晴らしいものにする方法
プレゼンテーションを見る
所要時間：37:33
概要
ニコル・フォアグレン氏は「AI 生産性のパラドックス」について議論し、コード生成が速くなるほどデプロイのボトルネックのコストが高くなる理由を説明します。彼女はアーキテクトやリーダーが体系的に摩擦を取り除くための DevEx フレームワークを紹介します。DORA メトリクス（DevOps Research and Assessment metrics）と RICE 優先順位付け（Reach, Impact, Confidence, Effort）を活用して、プラットフォームの健全性に対するデータ駆動型の主張を行う方法を学びます。
バイオ
Dr. ニコール・フォアグレンは、マイクロソフト、GitHub、Google などの企業で生産性向上の取り組みを率いており、『Accelerate』および『DevOps ハンドブック 第 2 版 (The DevOps Handbook 2e)』という 2 冊のベストセラーかつ受賞歴のある書籍の著者です。彼女は技術プロセスの測定における業績と、主要調査員としての役割で最もよく知られています。彼女は起業家、教授、開発者、システム管理者、そしてパフォーマンスエンジニアとしても活動してきました。
カンファレンスについて
ソフトウェアは世界を変えています。QCon サンフランシスコは、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践者主導のカンファレンスである QCon は、チーム内でイノベーションに影響を与える技術チームリーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。
INFOQ EVENTS
2026 年 5 月 28 日 午後 1 時 EDT (東部標準時)
AI の時代における配送システムの再考：より迅速なリリースと、より多くの破壊
発表者: エリック・ミニック - ハーネス社 DevOps ソリューションシニアディレクター、アロン・ニューカム - ハーネス社シニアプロダクトマーケティングマネージャー
通訳テキスト
Nicole Forsgren: ここで AI を触っている方はいますか？今や生産性は解決済み、すべて完了したと聞いているのでしょうか？もしそう思う方がいたら、私にダイエトコークを買いに行ってもらいましょう。1 分後に外で会いましょう。しかし実際に見えているのは、AI が一部のことは助けてくれているものの、むしろ多くのことをより困難にし、経営層に対してこれまで私たちがずっと知っていたことを突きつけているということです。「そう言ったでしょう」という瞬間です。なぜなら、時には摩擦があったり、物事が難しかったり、多くの苦労や手作業を伴う場合、AI はそれを解決していないからです。少なくともまだ解決していません。会社にとって良いだけでなく、私たち自身にとっても本当に良いソフトウェアの書き方をどう改善できるか考えましょう。私は燃え尽き症候群になりたくありません。二度経験しました。T シャツも持っていますが、お勧めはしません。どのように持続可能な形で物事を構築できるでしょうか？どの摩擦点が正しいのかを特定して、より速く進むにはどうすればよいのでしょうか。それが今日お話しすることです。なぜなら私たちは今、数分、あるいは数秒であらゆる種類のコードを生成できるというパラドックスに陥っているからです。
ビジネスユニットや背景を問わず、誰もがコードを書いてアプリを作成し、デプロイして、少なくとも少しの間はそれを使うことができます。しかし、デプロイにはしばしば時間がかかります。ここでは数日と言いましたが、私は楽観的すぎました。実際には通常は数ヶ月かかります。ここで、非常に速くコーディングできる友人がいて、それでもデプロイに 3 ヶ月以上かかるという方はいらっしゃいますか？ただの友人の話です。セッション後にダイエットコーラを待っているだけで、デプロイにそんなに時間がかかると言いたくないので嘘をついている方は誰ですか？大丈夫です、その気持ちはわかります。現在、多くの大手企業は、コードを作成できるにもかかわらず他のすべての問題が解決されないため、依然としてデプロイに数ヶ月かかっていると発見しています。
デプロイチェーンやこの外側のループについて考えるとき、古いものが再び新しいものになります。2012 年のナイトキャピタルでは、あるエンジニアがコードをデプロイしました。それは非常に日常的で標準的な作業でした。問題は、デプロイスクリプトが古い機能フラグ（feature flag）を再活性化してしまったことです。これは手動でのデプロイであり、自動化されたテストは存在しませんでした。45 分間で 4 億 6000 万ドルが消滅しました。彼らがそれを遡って検証し、事後レビュー（retro）を行った際、日々の開発者体験（developer experience）がそこに潜むすべてのリスクを浮き彫りにしていたことに気づきました。そこから学んだことは、二度とこのようなことがあってはならないということです。決して再び起こってはなりません。
今年初め、ジェイソンは Replit の AI コーディングアシスタントを使ってデータベースを構築していました。彼は明確に「生データへの変更は禁止」と指示し、コードの凍結（code freeze）を設定しました。つまり、YOLO（若者特有の無謀な行動）ですね。構いません。新しいツールですが、多くの問題は以前と同じです。むしろ、今ではより速くなっただけのことです。AI は、私たちが以前に見つけたのと同じ問題を増幅させています。
「どうすれば生産性を高められるか？」と問うのではなく、「ここでソフトウェアを構築し、リリースする実際の体験はどうなのか？」「どのようにして価値をより早く提供できるのか？」「また、これは持続可能なのか？」といった問いを立てるべきでしょう。なぜなら、この古い格言は古くても真実だからです。すべての企業はソフトウェア企業です。ある意味では、「自分はソフトウェア企業ではない」と主張し続ける企業が最大の機会となります。彼らはソフトウェアを書かないと頑なに主張しているからです。
皆さんはどうでしょうか？私は最近、全資産を金塊で保有する銀行には行っていません。
摩擦がどのようなものか
摩擦について話すとき、それは多くの形をとります。おそらく私たち自身や私たちのチームがこの一部に当てはまることに気づくでしょう。新入社員がまだ 3 週目にデータベースアクセスを待っている。プルリクエストが数日間放置されている。誤って担当者に割り当てられたためかもしれないし、キューで止まっているのかもしれないし、誰かが休暇中なのかもしれない。ビルドパイプラインが再びクラッシュし、廊下にまた xkcd の剣を置く時間だ。あるいはデプロイには複数のチームやツールにわたる手動調整が必要で、リスクに関するグループでの意思決定も必要となる。これは決して安価なものではない。上司やマネージャー、リーダーに対してこれが重要だと説得しようとする人のために、このスライドを写真に撮って持ち帰ってください。これはいくつかの異なる研究にまたがるデータです。マッキンゼーは、開発予算の 40% が回避可能な手戻りに費やされていると発見しました。別の研究では、開発者の生産性は約 68.5% だと感じられており、その不足分である 31% を計算すると、それは GDP で 3,000 億ドルの損失に相当します。
別の研究では、技術的負債（technical debt）によって 1.52 兆ドルを失っていると推定されています。これが見える摩擦の一部に過ぎません。もはや単なる快適さの問題ではなく、競争上の生存そのものに関わる問題です。心配している企業にとって、私の開発者が幸せかどうかは実はどうでもよいことです。
まず第一に、これは重要です。なぜなら、幸せな開発者が幸せなソフトウェアを生み出すからです。また、ビジネスと顧客を維持したいのであれば、私たちは迅速に開発し、デプロイする必要があります。ここではほんのいくつかの例を示します。オンボーディング、コードベース、統合、プロセス、レビュー、私たちの開発における摩擦すべて、デプロイにおける摩擦すべてです。これらの技術的解決策の一部は知っていますが、私たちを本当に遅らせたり、ボトルネックや課題、疑問、問題を引き起こしたりする要因が、実は私の仕事外の摩擦であるプロセスや承認の仕組みである場合もあるため、改めて目を向ける必要があります。
今再び、AI がこれを増幅している様子が見て取れます。かつてはコードを書くことがボトルネックでした。しかし、コードを書くことはもはやボトルネックではありません。あらゆる種類のコードを生成できるようになりました。その結果、残りの摩擦がより高価なものとなり、より目立つようになっています。テストスイートがこの負荷に耐えられるでしょうか？ビルドパイプラインはこの負荷に耐えられるでしょうか？私のシステムに流れ込むゴミのような PR をすべてレビューしきれるでしょうか？必ずしもそうとは限りません。
DevEx フレームワーク
これを改善する際、生産性について話すのは必ずしも最善ではないと気づきました。なぜなら、それでは私たちが議論したいべき点が常に明確にならないからです。私たちは単にシステムを通じてより多くのコード行を流そうとしているわけではありません。開発者体験が容易でシームレスかつ心地よいものであることを目指しています。そうすれば障害を取り除くことができるからです。開発者体験について考えるためのフレームワークが存在します。これについて考える方法は数多くありますが、私は以下のアプローチが好きです。一つ目はフィードバックループです。質問から回答に至るまでにどれくらいの時間がかかるでしょうか？それは内部コードベースの検索かもしれませんし、レビューを受けることかもしれません。あるいはビルドからのフィードバックを待つことも含まれます。ビルドは成功したのか、失敗したのでしょうか。二つ目の概念はフロー状態です。私は集中して難しい問題について考えることができるでしょうか。
AI はまさにこの状況を根本から変えています。かつては、時間を数時間確保して深く没頭し、コードを完成させることができました。AI コードアシスタントを活用している方はいますか？職場ではなくても、趣味で使っている人は？もうただ座ってコードを書くだけではいられません。プロンプトを入力すると、すぐにフィードバックが返ってくるからです。そのフローは全く異なるものになっています。私はコードを受け取り、レビューし、書き直す必要があります。これはステロイド剤を投与された Stack Overflow のようなものです。そこでは多くのことが起こり、認知負荷に繋がります。私が集中している作業を行うために、どれだけの精神的な余力があるのか？そのプロセスは状況を悪化させているのでしょうか？デプロイメントツールが状況を悪化させているのでしょうか？テストスイートは答えも示さずに単に失敗を報告するだけではないでしょうか？これは非常に困難なことです。私は限られた認知能力を、本当に難しい問題の解決に充てたいのです。これは人間の限界によるものです。グロリア・マーク氏によるある研究では、人間が本当に難しく深い作業に費やせる最大時間は、1 日約 4 時間であると示されています。もし私が 4 時間の時間を持っていたとしたら、その時間を何に使うべきでしょうか？
先ほどお話しした通り、アクションと結果までの時間はどれくらいでしょうか。AI においては、コード生成の速度を上げるためには検証の高速化が必要です。フィードバックループがここでの影響を決めます。ビルドに 10 分かかれば、フロー状態を維持できます。素早く実験でき、迅速な意思決定が可能になり、常に学習を進められます。このフィードバックループは素晴らしいものですが、もし時間が長くかかってしまうと、コンテキストスイッチ（文脈の切り替え）が発生してしまいます。別のタスクのために別のリポジトリで作業するには、新しい環境をプロビジョニング（準備・構築）する必要があり、意思決定を遅らせることになります。実験の回数も減らざるを得ず、学習速度は大幅に低下します。これは 2 時間のビルドの場合でもそうなのです。30 時間かかるビルドを持つ方々と一緒に働いた経験もありますが、そこで何が起きるでしょうか？さらに、それらをどのように間隔をあけて、いつ実行すべきかという問題さえあります。フロー状態について再度考えましょう。本当にどれくらい集中し続けられるのでしょうか。ここでの中断は単に数分を失うことではなく、文脈と、私たちが行っていたことの深さを失うことを意味するからです。
私が今、話をする際に人々からよく聞かれるもう一つの点は、AI によってマスターすべきツールが増え、明らかにそれらを統合して取り組む必要があるということです。プロンプト作成に取り組んだり、異なる AI コーディングエージェント（AI coding agents）を扱ったり、MCP やエージェント型ワークフロー（agentic workflows）に取り組んでいます。コードを生成し、抱えている問題を最も効果的に解決するために、私たちはこれをどう捉えるべきでしょうか？これらはすべて互いに補強し合っています。
迅速なフィードバックはフロー状態を保ち、負荷を軽減します。負荷が軽減されることで集中力が高まり、意思決定の速度も向上します。守られたフロー状態によって学習を加速させ、時間をかけて複利効果を生み出せます。そうすれば新しいコードやアイデアを生み出し、それが再び迅速なフィードバックループへとつながります。
ビルドに時間がかかるという問題がある場合、例えば 2 時間のビルド時間が学習の遅れにつながります。フィードバックを得るまでに数時間かかり、自分のコードが機能しているか、意図した通りに動作しているかがわかるまで待たなければなりません。その間、私たちはコンテキストスイッチ（context-switch）を繰り返します。マルチタスクが得意ではないため、多くの並行するタスクを記憶しておく必要があります。この問題に対する一つの解決策は、インクリメンタルビルドや並列化されたビルドを行うことです。明確な所有権を持ち、それを支援する自動化を導入することが重要です。
What Good Looks Like
良い状態とは何かについて、いくつかのアイデアがあります。ここで皆さんは DORA メトリクスという言葉を聞いたことがありますか？DORA は、パフォーマンスと非常に高い相関関係があることがわかった 4 つのメトリクスからなるフレームワークです。私たちはスピードに関する指標を 2 つ、安定性に関する指標を 2 つ持っています。スピード指標とは、デプロイ頻度（どれほど頻繁にデプロイできるか）とリードタイム（コードがコミットされてから本番環境で実行されるまでにかかる時間）です。一方、安定性指標は、変更失敗率（本番環境に導入された変更のうち、どの程度が介入を必要とするか）と MTTR（平均修復時間：これらの障害に対して対応し、緩和するまでにどれほどかかるか）です。
高パフォーマンスな DORA チームは、1 日に複数回デプロイすることができます。ここに少し注釈を加えます。あるいは、ビジネスのニーズに応じていつでもデプロイできる場合もあります。App Store への投稿などを行う環境では、毎時間デプロイできないこともあります。これは技術的な制約ではなく、ビジネス上の判断です。彼らは通常、1 時間以内に復旧できます。変更失敗率は私が示した 15% よりもはるかに低く、実際には約 5% 程度です。リードタイムも 1 日未満です。
では、彼らはいかにしてこれを実現しているのでしょうか。多くの人々にこの方法について尋ねると、技術的な解決策について語ることがよくあります。それは非常に重要です。
その技術的ソリューションは、認知負荷を低減し、機能します。私は重要なことに集中でき、エンジニアリングによって排除されるべきものに時間を割く必要がありません。私のフロー状態を守り、迅速なフィードバックを得ています。これらのチームが単に幸運なだけではありません。彼らは体系的に摩擦を取り除きました。これは誰にでも可能です。私はよく大企業から「その話は聞く。その数字も見る。しかし、それは現実的ではない。なぜなら、あれはスタートアップだからだ。スタートアップは非常に速く動ける。規制が少なく、承認プロセスもないからだ」と言われることがあります。すると、一週間後に別のスタートアップに話を聞くと、「それは私には当てはまらない。あれは大企業の特徴だ。大企業には資金もリソースもすべてある。私は小さなチームしか持っていない」と言うのです。私たちは、企業の規模や業界を問わず、これが真実であることを確認しています。
むしろ、数年前まで、一つの産業において顕著な違いが見られました。それは小売業です。彼らはより良い成果を出しました。なぜでしょうか？長年極めて競争の激しい環境に置かれていたため、改善せざるを得なかったからです。そうでなければ、おそらく事業を継続できなくなっていたでしょう。小売企業やプラットフォーム、ウェブサイトはあまりにも多くあり、すべてを整えられない場合、特に実店舗を併設しているビジネスの場合、非常に困難になります。
ある人々がようやくこれが重要だと納得したとき、「でも、これに時間を割く余裕がない。最新のアプリを構築しなければならない。次世代の最良のプロダクトを生み出さなければならない。何か他のものを改善しなければならない」と言うようになります。年間約 260,000 ドルが浪費されていることがわかります。これは私の簡易計算によるものです。開発者が 20 人いると仮定しましょう。それぞれが単一の摩擦ポイントに毎日 30 分を失うとすると、1 日あたり 10 時間、年間 2,600 時間になります。時給を 100 ドル（※原文の「$100 a year」は文脈上「$100/hour」の誤記と推測され、計算に整合させるため時給として解釈）とすると、これは非常に明確な計算です。時には、すでに時間を費やしているが、それを摩擦との戦いに使っているだけで、除去したり改善したりしていないことに気づくために、簡単な計算をするのに数分かかることもあります。
ビジネスケース構築のための 3 つの戦略
ここで、技術変革（tech transformation）、DevOps、ツールの改善に関するビジネスケースを提示した経験がある方はいますか？それが大成功だったという方は？興味深いことに、私が大企業に引き込まれて支援する際、通常は 2 つの質問が浮上します。「どうすればビジネスケースを構築できるのか」「どうすれば文化を変えられるのか」です。技術については解決済みだと思っていますが、実際にはそうではありません。しかし、その方法を知っています。私たちは非常に賢い人々の集まりです。これをどのようにビジネス側に説明すればよいのでしょうか？私が非常に効果的だと見つけた 3 つの戦略があります：可視性と責任の明確化、明確なアクションを伴うシンプルなデータ（それが実行可能であることを確認）、そして金銭的なインパクトです。これについて先ほど 1 つ例を紹介しました。ここで私が特に気に入っている例をいくつか挙げます。可視性と責任の明確化に関するものです。
Three Strategies for Making the Business Case
Has anyone here tried to make a business case for tech transformation, DevOps, making the tools better? It was a rousing success? It's interesting because I get pulled in to help large companies and it's usually about two questions. It's about, how do I make the business case, and how do I change the culture? We've got the tech figured out. We don't, but we know how to. We're a bunch of very smart people. How can I explain this to the business? There are three strategies that I've found are very good: visibility and accountability, simple data with clear action, make sure it's actionable, and then dollar impact. We just walked through one example of that. Here are some examples that I love here, for visibility and accountability.
Dave Anderson は Amazon に在籍し、プラットフォームのエラー率改善を担当していました。しかし、ロードマップに対して直接的な権限は全く持っていませんでした。この状況は少し行き詰まっているように感じられます。私も同様の立場にいたことがあります。皆さんの中にも同じ経験がある方がいるかもしれません。彼には素晴らしい戦略がありました。それは「S-チームレポート」を作成したことです。これは経営陣（エグゼクティブチーム）向けの報告書で、CEO の直属のメンバーが対象です。このレポートは毎月 S-チームに提出されていました。チーム別のエラー率が記載され、順位付け（スタックランク）が行われていました。その分野を所管する VP が特定され、強調表示されました。約 1 週間も経たないうちに、ディレクターたちはリストから外れるために彼のオフィスへ殺到しました。時には、単に起きていることを可視化し、注目を集めるだけで十分なのです。なぜなら、人々がシステム改善を望まないわけではなく、むしろやるべきことが多すぎるからです。もしそれがリーダーやエグゼクティブの優先事項でなければ、正直なところ、それはあなたの優先事項にもならないでしょう。どうすればその優先順位を作れるのでしょうか？
もう一つの例として、Max Kanat-Alexander が LinkedIn から共有した事例があります。皆さんもご存知のように、私たちはすべてダッシュボードを持っていますね。すべてのダッシュボードです。私は良い指標（メトリクス）やデータが大好きですが、データが多すぎると、文脈を理解することが人々にとって非常に難しくなることがあります。Max たちが行ったのは、「Developer Insights Hub」と呼ばれるものを構築することでした。彼らは膨大な数のデータポイントを持っていましたが、最初は非常にシンプルに始めました。
例えば、プラットフォームにアクセスしてビルド時間が 20% 増加していることが強調表示された場合、自分自身に「なぜビルド時間が悪化したのか？」と問いかけることができます。詳細を掘り下げれば、例えばシンガポールにいるモバイル開発者だけが特定のリポジトリで作業していた際にこの大きな問題が発生し、その影響があまりにも甚大で全体に影響を及ぼしたことがわかります。これは具体的なアクションにつながります。もしすべてのリポジトリ、すべての地理的領域におけるすべてのビルド時間を個別に表示し、万が一のために集計しないとしたら、それは単なるデータの洪水に過ぎず、実際に行動を起こすのは非常に困難になります。
3 つ目の例は Block 社からのものです。彼らがビジネスケースを構築する際、開発者の満足度や開発者体験（Developer Experience）に本当に注力していました。これを共感させることは非常に難しいため、彼らは摩擦による金銭的インパクトに焦点を当てました。具体的には2つの数値に分解しました。
1 つ目は、容易に特定できる摩擦の規模とそのコストであり、もう1つは回避可能なインシデントを特定し、その金額も算出しました。その結果、わずか 12 ヶ月で文書化された数百万ドルの節約と開発者満足度の向上を実現しました。なぜなら、システムが使いやすくなれば、作業体験自体が格段に良くなるからです。
ここで素晴らしい点は、プラットフォームを改善し、開発者のための内部システムを改善すると、多くの場合ウィンウィンの結果になることです。課題は、それを適切な方法で伝えることにあるのです。
開始するための 7 つのステップ
これで合意が得られました。おめでとうございます、皆さん。合意が得られました。さあ進めと指示が出ました。では、どこから始めればよいのでしょうか？私は過去1〜2年間、アビ・ノダ氏と共に働いてきました。彼はDXの共同創設者兼CEOです。私たちは、企業がたどるステップはおよそ7つあることを発見しました。これは数百ものチーム、大企業、中小企業、小さなスタートアップ、そして複数の異なる業界分野との対話に基づいています。これらすべてが同じ一般的なパターンに従っています。
ステップ1：誰かと話すことです。データを収集したいのですが、しばしば良質なデータを入手する最善かつ最も迅速で安価な方法は、数人の関係者と直接話し合うことです。
次に、小さく始めてすぐに成果を出すことです。ステップ3はデータを活用することです。
ある時点で、より多くのシグナルとデータが必要になるでしょう。そうしたら、改善すべき事項のリストが山積みになったデータ収集活動から得た知見に基づいて、戦略と優先順位を決定することになります。優先順位の付け方にはいくつかのアプローチがありますので、それについてお話します。次に、その戦略を関係者に納得させる必要があります。これが正しい選択だと人々を説得し、変革を推進していかなければなりません。
「あなたの規模において」とおっしゃる理由は、それがあなた自身の会社での仕事になり得るからです。あなたはディレクターや VP（バイスプレジデント）かもしれませんし、「これはひどい。もっと良くしたい。自分がいる場所でどう変化を生み出せるか？」と決意したエンジニアかもしれません。その中間の立場にある方ももちろんいます。
いくつかの変更を加えた後は、評価を行い、その価値を示す必要があります。このフレームワークの良い点は、現在どこにいてもそこから始められることです。何も行われていない状況で入ってきた場合はステップ 1 から始めるのが適切でしょう。すでに数年続いている継続的なイニシアチブに参加する場合は、戦略と優先順位の決定から参加することも可能です。
私たちは常に聴くことから始めたいと思います。どのステップから始めても、数人の関係者に話を聞きに行くことをお勧めします。そうすれば、その状況がどのようなものか、彼らの現在の課題は何で、何に直面しているのかを、はるかに良く理解できるようになります。アンケートを行う前でも、指標を集める前でも、何が彼らの邪魔になっているかをただ聞いてみてください。毎日誰に対して怒っているかを尋ねてください。彼らは教えてくれます。何がひどいのかを話してくれます。そして、いくつかのパターンを収集し始めます。ワークフローをマッピングできます。プロセスを見直すこともできます。多くの場合、ハンドオフポイントやシステム間の接点で摩擦が生じていることがわかります。
次に重要なステップは、最初の勝利を慎重に選ぶことです。ここでは迅速な成果を得たいと考えています。これに対する私の簡単なヒューリスティックがあります。それは目に見えることです。十分に重要で、視認性があり、誰もがそれを見ることができます。私が「誰でも見ることができる」と言うとき、開発者も気づき、経営層にも意味のある形で伝えることができます。次に、すぐに達成可能である必要があります。ここでは月ではなく週単位で考えています。最長でも四半期程度です。複数のチームに利益をもたらす可能性があります。おそらく最初は一つのチームから始めて深く掘り下げることになりますが、問題は十分に大きく、一つか二つのチームで成果が見つかれば、それを多くの異なるグループに一般化できるようなものであるべきです。これが迅速な成果を得るための素晴らしい方法です。
その後、多くのチームが戻ってきて、「次に何をすべきか分からない」と言うことがあります。目に見える低垂れ果実（low-hanging fruit）は片付けましたし、明白な短期成果（quick wins）も達成しました。今度はデータを収集したいと考えています。ここではさまざまな種類のデータがあります。システムに関するもの、保有しているあらゆるテレメトリ（telemetry）、ログなどです。また、アウトカム（outcomes）にも目を向ける必要があります。開発者が何を実現したのか？生産性、リードタイム、欠陥率、そしてインパクトです。これはビジネスにとって本当に重要なことです。収益が上がるか、満足度が向上するか、価値提供までの時間が短縮されるかどうかが問われます。これらは特に扱いが難しい項目です。少なくとも最初の 2 つのカテゴリーから始めるべきでしょう。アンケート調査のようなものを軽視してはいけません。数千名のエンジニアや数百名のエンジニアにわたって信頼性の高いアンケートデータを収集する方が、すべてのシステムを計測（instrumenting）するよりもはるかに迅速で安価な場合があります。計測にはコストがかかります。もし間違ったものを計測してしまったらどうなるでしょうか？
すべてのデータを揃えた後は、優先順位をつける必要があります。私は RICE フレームワークを使用するのが好きです。ここではリーチ（到達範囲）を見ます。この取り組みによって影響を受ける人はどれくらいいるでしょうか？インパクト（影響度）は、彼らの仕事をどれだけ改善できるかです。数時間の短縮につながるかもしれません。コンフィデンス（確信度）は、これが実現可能かどうか、あるいは実行可能であるという確信がどの程度あるかを問います。これら 3 つの要素については、すべて高い値を望みます。高いほうが良いのです。一方、エフォート（労力）は低くしたいものです。これはどれほど困難でしょうか？これにはどれだけの時間がかかるのでしょうか？どれほどの人員が必要になるのでしょうか？エンジニアリングのリソースとしてどれだけの時間を要するのでしょうか？
ここに一つの例を示します。3 つの可能性があると仮定しましょう。不安定なテスト自動化、コードレビュープロセスの合理化、そしてモニタリングダッシュボードです。最初の 2 つのリーチは高いです。一方、モニタリングダッシュボードについては中程度です。
インパクトについても同様に、最初の 2 つは高いです。モニタリングダッシュボードについては中程度です。さて、不安定なテスト自動化に目を向けると、私たちはこれを達成できるという確信がかなりあります。コードレビュープロセスも実行可能であることを知っています。モニタリングダッシュボードに関しても、これを解決できることはわかっています。次にエフォートについてです。不安定なテスト自動化は非常に高い労力を要します。多くの場合、これには多大な努力が必要です。ここで AI が役立っています。コードレビュープロセスの合理化については、労力は低く済む可能性があります。これは非常にシンプルで straightforward かもしれません。一方、モニタリングダッシュボードについては中程度の労力です。
この例では、コードレビュープロセスから始めることにします。これは広範な影響があり、信頼性が高く、短期間で成果を得られ、過度な労力を要さないからです。また、このアプローチの素晴らしい点は、ローカル環境で実験できることです。何が機能しているかを確認し、数チームに展開して検証できます。これにより、素早く簡単に参画し、改善点を見つけることができます。
RICE 評価モデルだけでなく、一歩引いて自社の文脈に特有な他の要素も考慮することが非常に役立ちます。すでに「リーチ」について言及しましたが、「頻度」も重要です。この問題はどのくらいの頻度で発生するのか？また、「痛み」の深刻度も確認しましょう。これは単なるわずかな不快感なのか、それとも完全なブロック（阻害要因）なのか？これらは頻度とインパクトの一部です。
多くの場合、人々は毎月行う必要がある作業を強く嫌う一方で、毎日発生するわずかな不快感には比較的耐えられることがあります。このように、頻度と影響の組み合わせが重要になります。
戦略的整合性も確認しましょう。これはビジネス上の優先事項に合致していますか？あるいは、すでにこの分野で進行中の取り組みがあり、その追い風に乗れる余地はないでしょうか？ゼロから始めるのではなく、既存の取り組みに自らの活動を合わせることができないでしょうか？
依存関係も考慮すべき点です。他の機能やプロジェクトを解放する可能性があります。以前、非常に明白に見える課題がいくつかありましたが、その中で上位 2 つのうち、2 番目の課題が解決されれば他すべてが解放されるというケースがありました。これが私たちが取り組もうとするすべてのことのブロックとなっていたため、まずそこから着手しました。
改善においてよく見られる共通の間違いがいくつかあります。最初の間違いは、単にデータから始めて指標をぶつけることです。これにはいくつかの理由で課題があります。一つ目は、データは人々と直接対話しないからです。一部の人は指標を本当に愛していますが、もしあなたがデータポイントに愛着を持っているなら、それには必ず物語を伴わせる必要があります。もう一つの課題は、指標から始めようとした場合です。もし測定プログラムが成熟していないのであれば、単に都合よく利用可能なあらゆるデータポイントを採取することになり、おそらく私たちが伝えたいことを測定したり伝達したりするために設計されたものではないでしょう。
二つ目の間違いは、一度に絶対にすべてをしようとすることです。私たちはすべてを行うことはできません。一つのことを選んでそれをうまく行う方がはるかに良いのです。三つ目は、経営層のみを対象とした最適化です。「木が森で倒れても誰も聞かなければ、音はするのでしょうか？」開発者が気づかないなら、これは本当に困難になります。そして四つ目の間違いは、これを単なるプロジェクトとして扱うことです。一つのことを実行して終わりと考えてしまうのです。ここでは持続可能な改善について考え、システムにエンジニアリングの改善を組み込んでいくことが真に重要です。
DevEx のスケーリング：3 つのパターン
私たちは、自社の規模に合わせて共有することも目指しています。ローカルスコープであれば、どの個人貢献者（IC）でも実施可能です。チーム内のどの IC でも、小さな課題を一つ選んでください。チームにとって明白な課題を選ぶこともできます。あるいは、自分自身で取り組むか、マネージャーに「金曜日のハックデー」の提案をすることもできます。価値を実証し、学びを文書化できれば、それは非常に影響力があります。なぜなら、その後それを社内外や組織全体で共有し始めることができるからです。
次に、中間的なアプローチです。もしあなたがエンジニアリングマネージャーやセカンドライン（管理職）であれば、共通の課題を探してください。連合を築き、この問題に深く関心を持つ人々を集めてください。あなたのチャンピオンを見つけてください。そして、他の人が再利用できるソリューション、ツール、ランブックを作成し始めましょう。
そして、最後に、これがあなたの本業であり、組織に組み込まれている場合、取り組むプロジェクトの範囲について異なる視点を持つことができます。リソースの割り当てや、リソースを往復させながら柔軟に調整することについても考えられます。より体系的な測定も可能になります。再びローカルスコープに戻りましょう。自分たちのプロセスやツールについて考えてみてください。現在のチームは何を使っていますか？自分で何を改善できるでしょうか。ここが、あなたが実際に需要を生み出す模範となる場所です。なぜなら、良いニュースは非常に速く広がるからです。1 つのチーム、あるいは数人のチームで状況が大きく改善されれば、それは非常に効果的です。中程度の範囲では、さらにいくつかの実証事例を提示し、ややスケーラブルなソリューションを作成する必要があります。自分自身と自分のチームだけの場合は、カスタムワークから始めることができます。ここではまだ強制力のある命令はありません。グローバルスコープでは、これはすでに戦略的インフラストラクチャです。より大規模なインフラストラクチャの取り組みという観点で考え始めます。
The Impact of AI
AI はこれらすべてをどのように変えるのでしょうか。いくつかの点は全く変わりません。依然として基本は存在します。SPACE フレームワークは、測定したいデータポイントを考える際に役立ちます。S は満足度（satisfaction）です。開発者は自分が使用するツールやプロセスに満足しているでしょうか。P はパフォーマンス（performance）です。結果はどうですか？品質の結果とは何ですか？テストのパス率やビルドの失敗率はどれくらいでしょうか。A はアクティビティ指標（activity metrics）です。これらは数値化できるものです。これが、データについて考える際に多くの人々が思い浮かべるものです。これはコード行数です。これはプルリクエストの数です。数えられるものは何でも含まれます。C はコミュニケーションとコラボレーション（communication and collaboration）です。これはプルリクエストかもしれません。API 呼び出しかもしれません。開発者が会議に出席する頻度かもしれません。
そして E は効率性とフロー（efficiency and flow）です。何かを完了させるのにどれくらい時間がかかるのでしょうか。これらは AI の時代でも依然として適用されます。特定の焦点は異なる可能性があります。一般的なワークフローではなく、AI ツールについて質問しているかもしれません。ここでは多くの例があります。DORA メトリクスは、エンドツーエンドを捉えるものだと述べましたが、これは AI においても非常に重要です。むしろ、多くの人が以前以上にインナーループ（inner loop）に注力している様子が見られます。単にコードを書いて提出するだけでなく、コードレビューまで行うという文脈でです。
その後、それ以降のことはすべて私の問題ではなくなりました。DORA はこれに焦点を当てています。なぜなら、内部ループが高速化している一方で、外部ループは依然として同じように遅く、むしろ苦労している状況が見られるからです。ワークロードの変化も確認されています。今や、単にコード行数や PR に対するフィードバックループを測定するだけでなく、プロンプトについても目を向けるべきです。プロンプトへの回答を得るまでにどれくらいの時間がかかるのか？前進するために数個のプロンプトで進捗を得るまでにどれくらいの時間がかかるのか？エージェントワークフローを検討する際、開発者はそこに存在するエージェントのステアリングや作成についてどのように考えているのでしょうか。そして、AI 生成コードのレビューと検証が必要です。今や、レビュープロセスが AI 生成コードを捉え、歴史的にそうであったように AI 生成コードを改善できているかという問いを立てるべきでしょう。AI が記述したコードの生存率はどうでしょうか。依然としてパイプラインを通過できるのでしょうか？セキュリティは異なるのでしょうか？信頼性は異なるのでしょうか？ここで何が変わるのでしょうか？コード行数は常に悪い指標でした。誰かがコード行数を測定したいと主張する会議に参加したことはありますか？
そうでない場合は、ご健闘を祈ります、純粋な夏の子どもよ。これは常に話題になります。私が気に入っているのは、AI がコード行数が全く無意味な指標であることを非常に明白にしてくれた点です。なぜなら、今やコード行数が多すぎるからです。あまりにも冗長で、コメントも多すぎます。時にはコードを削除することが最善の策であることも分かっています。では、私たちはこれをどう捉えればよいのでしょうか？再び、プロンプト効率について考えましょう。生き残る提案を得るまでにどれくらい時間がかかるのか？検証はどの程度難しいのか？AI を使って検証できるか？人々は今や、作業の質が低い成果物（slop）を受け取っているため、コードレビューにすべての時間を費やしているのだろうか？私たちは信頼の較正についてどう考えるべきでしょうか。これは非常に重要です。なぜなら、あまりにも多くを信頼すればバグをリリースしてしまうからです。逆に、あまりにも信頼しなければ、AI を使う意味がなくなります。三重チェックに時間を浪費してしまっています。
ワークフローの委任とは、どの作業を AI に任せ、どの作業を人間が行うのか？その影響は何か？それが私たちの認知負荷をどう変えるのか？システムの理解やメンタルモデル（心のモデル）をどう変化させるのか？速度にはどのような影響を与えるのか？
ここで私が特に強調したいのは、研究において「混合手法（mixed methods）」と呼ばれるアプローチを活用することです。システムからのデータと、人々からのデータの両方を収集する必要があります。システムデータは「何が起きているか」、あるいは「どこが間違っているのか」を教えてくれますが、「なぜそうなるのか」という理由までは説明できないことが多いのです。
この事例は、数ヶ月前に私が話したチームで実際に発生しました。認証機能に関するコード提案に対して、極めて高い拒否率が生じていたのです。担当チームはなぜそうなったのか理解できず、「これはうまくいっていない」「ひどい状態だ」と困り果てていました。その答えは、AI がセキュリティ上の脆弱性を多数架空（ハルシネーション）していたことでした。この発見により、彼らは具体的な行動を起こすことができました。具体的には、セキュリティ上極めて重要なコードに対して AI の使用を制限したのです。その結果、チームの時間を大幅に節約することができました。
さて、彼らはまだこの分野における道筋や解決策を探求中です。これにより、人々が費やしていた時間が大幅に解放されました。しかし、コードを読み込んで却下するには依然として時間がかかります。ただし、一部の人は自動で却下しているのかもしれません。なぜなら、AI によるコードには「コードスメル」が存在することは私たちが知っているからです。今ではその理由も明確になりました。
私は皆さんにも、自分自身でこれらを実践してみることをお勧めします。何を待っているのでしょうか？ 私たちが作成しているコードやコードベースには、膨大な機会が眠っています。現在 AI で成功を収めている組織は、単に新しいツールを導入しただけではありません。全員に Gemini CLI や GitHub Copilot、Cursor を与えただけでもありません。今週お好みのコード生成ツールを選んでください。少なくとも dozen 以上の優れた選択肢があります。
彼らが行っているのは、開発者がそのコードを顧客の前に提示できるように、摩擦を徹底的に取り除くことです。実験を実行できますし、実際にスピードを上げることができます。私が目にする大手企業はすべて、現在この摩擦を取り除く方法を積極的に模索しています。皆さんも各自の業務においてこれを考えるべきだと私は提案します。
アクションアイテム
もし一つだけ行うなら、以下を提案します。個人貢献者（IC）の場合は、一週間自分のワークフローをマッピングしてください。30 分も無駄に費やしてしまうような、本来あるべきではないナンセンスな時間があるのはいつですか？どこに課題がありますか？インタビュー対象者の一人は「チームの他の人と話してみましょう」と言っています。他のメンバーと対話し、あなたが感じている摩擦ポイントが彼らにも同じように見えるかどうか確認してください。
もしあなたがチームリーダーなら、30 分程度の簡単な振り返り（レトロスペクティブ）を行ってください。「今週、作業そのもの以外で何が進みを遅らせましたか？」あるいは「なぜまた、本来それほど時間がかからないはずのことが進みを遅らせたのでしょうか？」と自問してください。コードレビューは作業の一部ですが、そのプロセスの中で本当に難しい部分はありますか？法務審査に長い時間がかかっていて、いつもそうなのか、と問いかけてみてください。繰り返しになりますが、私たちが足踏みしている原因や最大の摩擦ポイントは、多くの場合「プロセス」にあるからです。
リーダーの場合は、少なくとも三人の人々と話してください。一部の摩擦ポイントについては簡易的な計算（ナプキン・マス）を行ってみるのも良いでしょう。組織内でどこに摩擦が生じているのか、その概要と実感を掴むことが重要です。小さな変化が積み重なることで大きな変革へとつながることを忘れないでください。一つだけ行うべきことを見つけたら、「この摩擦ポイントを除去するために、私が今すぐできる最も小さなことは何か？最も簡単で最速の方法は何か？」と自問してください。
リソース
新しい本を出版します。興味のある方のために、これらのステップの詳細をカバーしています。この QR コードは、約 100 ページの無料ワークブックが用意されたウェブサイトへ案内します。ここには非常に多くの無料ワークブックがあります。テンプレートやフレームワークも用意されています。RICE 優先順位付けフレームワーク（RICE prioritization framework）の例付きバージョンもあります。ヒューリスティックに基づく「Quick RICE」や、より詳細な RICE も用意しています。また、インタビューガイドも提供しています。サンプル調査票や追加の質問項目もあります。なぜなら、あえて摩擦を生じさせたい場合でも、3〜4 問程度の質問を用意すれば十分だからです。これらもすべて含まれています。評価基準（rubrics）やスプレッドシートも多数用意されています。
字幕付きの他のプレゼンテーションをもっと見る
録画日:
2026 年 3 月 24 日
原文を表示
InfoQ Homepage
Presentations
From Friction to Flow: How Great DevEx Makes Everything Awesome
View Presentation
Speed:
37:33
Summary
Nicole Forsgren discusses the "AI Productivity Paradox", explaining why generating code faster often makes deployment bottlenecks more expensive. She shares the DevEx framework to help architects and leaders systematically remove friction. Learn how to use DORA metrics and RICE prioritization to make a data-driven case for platform health.
Bio
Dr. Nicole Forsgren has led productivity efforts at companies like Microsoft, GitHub, and Google, and is author of two best-selling, award-winning books: Accelerate, and The DevOps Handbook 2e. She is best known for her work measuring the technology process and as the lead investigator. She has been an entrepreneur, professor, developer, sysadmin, and performance engineer.
About the conference
Software is changing the world. QCon San Francisco empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
INFOQ EVENTS
May 28th, 2026, 1 PM EDT
Shipping Faster, Breaking More: Rethinking Delivery Systems in the Age of AI
Presented by: Eric Minick - Sr. Director of DevOps Solutions at Harness, and Aaron Newcomb - Senior Product Marketing Manager at Harness
Transcript
Nicole Forsgren: Who here has been playing with AI? Are we hearing that now productivity is solved? Everything is done? Perfect. If that's you, go grab me a Diet Coke and we'll meet outside in just a minute. What we're really seeing, though, is AI is helping some things, but it's really making a lot of things more challenging, or it's showing to the executives all the stuff that we've known all the time. Very I told you so moment. Because sometimes when we have friction or if things are difficult or it's a lot of toil and it's a lot of manual work, AI isn't solving it, or at least it hasn't solved it yet. How can we think about improving the way we write software so that it's good for the company, but it's also really good for us. I don't want to burn out, I've done it twice. We've got the T-shirts, would not recommend. How can we build things sustainably? How can we identify the correct friction point so that we can move faster? That's what we'll talk about today. Because we're stuck in this paradox now, where we can generate all kinds of code in minutes, seconds.
People across any business unit and background can vibe code an app and push it and probably use it for at least a bit amount of time. Deployment is often taking longer. I said days here, I was optimistic. It's usually months. Does anyone here have a friend who can code really quickly and deployments take more than three months? Just your friend. Who here is just waiting for the Diet Coke after the session and lied because they didn't want to get caught saying deployments take so long? That's ok, I feel you. A lot of the biggest companies right now are finding that their deployment times are still several months because we can create code but that doesn't fix everything else.
When we think about the deployment chain and that outer loop, what's old is new again. At Knight Capital in 2012, an engineer deployed some code. It was very routine, very standard. The problem is that the deployment script reactivated an old feature flag. It was a manual deployment. There were no automated tests. In 45 minutes, $460 million was gone. When they went back through it and they did the retro, they realized that the daily developer experience really highlighted all of the risk there. What we've learned from that, that can never happen again. It would never happen again.
Earlier this year, Jason was using a Replit AI coding assistant to build a database. He explicitly told it, no changes to live data. He set a code freeze. I mean, YOLO. It's fine. New tools, but a lot of the same problems. If anything, it was just faster now. AI is amplifying a lot of the same problems that we found before. Instead of asking, how do we improve productivity? We should probably ask questions like, what is it actually like to build and ship software here? How can I deliver value faster? Also, how can this be sustainable? Because this old cliche is old but true. Every company is a software company. In some ways, the companies that insist they're not software companies are the biggest opportunity because they keep insisting that they don't write software. I don't know about you all, I haven't been to a bank holding all of my money in gold bars lately.
What Friction Looks Like
When we talk about friction, it can look like a lot of things. I assume we'll probably recognize ourselves or our teams in some of this. New hire is still waiting for database access on week 3. A pull request just sits for days. Could be because it's been assigned to the wrong person, it's stuck in a queue, someone's out on leave. The build pipeline crashes, again, time for more xkcd swords in the hallway. Or a deploy requires manual coordination across several teams, several tools, group decision-making about risk. This is not inexpensive. For anyone who's trying to convince a boss or a manager or a leader that this is important, here's your slide to take a good picture of. This is across a handful of different studies. McKinsey found that 40% of dev budgets are spent on avoidable rework. Another study said that developers feel about 68.5% productive, and then they calculated that missing 31%, that's $300 billion in lost GDP.
Another study is estimating that we're losing $1.52 trillion to technical debt. That's just some of the friction that we can see. It's no longer just about comfort, it really is about competitive survival. For any company that's worried, I don't really care if my developers are happy.
First of all, it matters, because happy developers make happy software. Also, if you want to retain your business and your customer, we have to be developing and deploying quickly. Here's just a handful of examples. Onboarding, codebase, integration, process, review, all of our development friction, all of our deployment friction. We know some of these technical solutions, but we should also take a look, because sometimes it's actually process or approvals or things that are not my job friction that really slow us down or really cause bottlenecks and challenges and questions and problems. Now, again, we're seeing that AI is just amplifying this. It used to be writing code. Writing code is no longer the bottleneck. We can come up with all sorts of code. It's making the rest of our friction much more expensive, and it's making it stand out more. Can our test suites handle that load? Can our build pipelines handle that? Can I review enough PRs for all of the trash that is coming across my system? Not always.
The DevEx Framework
When we talk about improving this, I have found that talking about productivity is not great, because it doesn't always highlight the things that we want to talk about. We're not just trying to push more lines of code through the system. We want a developer experience that is easy and seamless and delightful, because then we can remove obstacles. There's a framework to help us think about developer experience. There are a handful of different ways to think about it. I like these. One is feedback loops. How long does it take me to get the question to an answer? It could be searching an internal codebase. It could be getting a review. It could be getting input back from a build. Did the build pass or no? Next is flow state. Can I focus and think about hard problems?
AI is really changing this, because we used to be able to block out hours of time to really dig in and get some code done. Is anyone working with an AI code assistant? Maybe not at work, but for fun? You don't just sit and write code anymore, because we're prompting, and then we're immediately getting feedback. That flow looks very different. I have to accept code, review, rewrite. It's like Stack Overflow on steroids. There's a lot happening there, which feeds into cognitive load. How much mental capacity do I have to do the work that I'm focusing on? Is the process making it worse? Are the deployment tools making it worse? Are the test suites just throwing a failure with no answers? That can be really challenging. I would rather dedicate my limited cognitive capacity on the really hard problems. This is a human limitation. Some studies by Gloria Mark put the maximum time that a human can spend on really hard, deep work at about four hours a day. If I have four hours, what am I spending those four hours on?
We just talked about this. How long between action and outcome? In AI, faster code generation just needs faster validation. Feedback loops, the impact here. If we have a 10-minute build, we stay in the flow. We can experiment quickly. We can make decisions quickly. We can learn all of the time. That feedback loop is great, but if it takes a long time, we're context switching. I might have to set up a provision, a brand-new environment to work on a different task in a different repo. I have to delay my decisions. I can't take as many experiments. I'm going to learn much slower. This is just for a two-hour build. I've worked with folks that have 30-hour builds. What happens there? Even how do we space them and how do we time them? Flow state, again, how long can we really focus? Because here, the interruptions just aren't about lost minutes. It's about losing the context and losing the depth of what we were doing.
Another thing that is really coming up for folks that I see now when I talk is that with AI, we just have more tools to master. We have more things we're apparently pulling together. We're working on prompting. We're working on different AI coding agents. We're working on MCP. We're working on agentic workflows. How should we be thinking about this so that we can generate the code and answer the problems that we have the best way? They all reinforce each other. Fast feedback preserves our flow state and it reduces load. Reduced load lets us focus and improves our decision speed. Our protected flow lets us accelerate learning and compound over time. Then we can create new code, new ideas, which then takes us back to that fast feedback loop.
If we have slow builds, the problem, we have two-hour build times that delay our learning. Feedback, it's going to take me a couple hours to know if my code worked or if it does what I think it's supposed to do. We context-switch while we wait. We have to remember a lot of parallel tasks because we're not very good at multitasking. One solution here is that we can do incremental or parallelized builds. We have clear ownership and we have some automation that can help.
What Good Looks Like
We have a few ideas of what good looks like. Have folks here ever heard of DORA metrics? DORA is a framework of four metrics that we found to be very highly correlated with performance. We have two speed metrics and two stability metrics. The speed metrics are deployment frequency, how often can we deploy? Lead time, how long does it take to go from code committed to code running in production? Our stability metrics are change fail rate, of those changes that are introduced into production, how many of them require intervention? MTTR, how long does it take us to act on and mitigate any of those failures? The high-performing DORA teams can deploy multiple times per day. I'll add a little asterisk here. Or they can deploy whenever the business needs. Sometimes we work on an environment where we can't just deploy every hour, if we're going to the App Store or something. It's a business decision, it's not a technical constraint. They can often restore in under an hour. Their change fail rate is typically much less than the 15% I put here. It's often around about 5%. The lead time is under one day. Now, how they do this. Many times, when you ask people how they do this, they will talk about a technical solution. That is very important.
That technical solution enables and it provides low cognitive load. I can focus on the things that matter and not the things that should be engineered away. I've protected my flow state and I have fast feedback. These teams aren't just lucky. They systematically removed friction. Anyone can do this. I often hear large companies come to me and say, "I hear you. I see these numbers. That can't be real though, because that's just a startup. They can move really quickly. They don't have all of this regulation. They don't have these approvals". Then, I'll turn around and a week later I'll talk to a startup and they'll say, "That can't be me. That's just really big companies because they have all the funding. They have all of the resources. I just have a tiny team". We see that this is true across all sizes of companies, all industries.
If anything, a few years ago, we did see one significant difference for one industry and it was retail. They did better. Why? Because they had been in such a competitive environment for so long, they had to get better. Otherwise, they were probably out of business. There are too many retail companies and platforms and websites that if we don't have everything together, it's really difficult, particularly if you have a brick-and-mortar aspect to your business.
Once people are sometimes finally convinced that this is important, they'll say, but I don't have time for this. I have to build the latest app. I have to create the next best product. I have to improve something else. We see that about $260,000 can be wasted annually. Here's my back of the napkin math. Let's say you have 20 devs. Each loses 30 minutes a day to just a single friction point, 10 hours a day, 2,600 hours a year at $100 a year. That's pretty straightforward. Sometimes it just takes a minute for us to do some quick, easy math because we're already spending time, we're just spending it on fighting the friction instead of removing it and improving it.
Three Strategies for Making the Business Case
Has anyone here tried to make a business case for tech transformation, DevOps, making the tools better? It was a rousing success? It's interesting because I get pulled in to help large companies and it's usually about two questions. It's about, how do I make the business case, and how do I change the culture? We've got the tech figured out. We don't, but we know how to. We're a bunch of very smart people. How can I explain this to the business? There are three strategies that I've found are very good: visibility and accountability, simple data with clear action, make sure it's actionable, and then dollar impact. We just walked through one example of that. Here are some examples that I love here, for visibility and accountability.
Dave Anderson was at Amazon and he was responsible for improving platform error rates. He also had zero direct authority over any roadmaps. That feels a little stuck. I've been in this position. I'm guessing some of you have too. He had this great strategy where he created an S-Team Report, so this is the executive team. This is the CEO's direct. It went up to the S-Team every single month. There were error rates by team. They were stack ranked. The VP that owned that area was identified and highlighted. Within about a week, directors were rushing to his office to get off the list. Sometimes we can just surface what is happening in ways that can bring attention, because it's not that people don't want to improve systems, it's that they have a lot to do. If it's not a leader or executive's priority, frankly, it's probably not your priority. How can we help create that priority?
Another one, Max Kanat-Alexander shared this example from LinkedIn. I assume we've all seen, we have all the dashboards? All the dashboards. I love me a good metric. I love some data. Too much data can be really challenging for folks to just get context in. What Max did is they built out what they call the Developer Insights Hub. They had a ton of data points, but they started very simply.
For example, if you went to the platform and it highlighted, build times increased by 20%, you could then ask yourself a question. Say, why did build times get worse? You can drill down, and you could find, for example, mobile devs in Singapore only working on this particular repo saw this big problem, and it was so outsized that it impacted everything. That's actionable. If I show every single build time across every single repo and every single geo and not aggregate it just in case, that's just a flood of data, and it's really hard to act on. The third example comes from Block. When they were making the business case, they really cared about developer satisfaction, developer experience. That is really difficult to have it resonate, and so what they did is they focused on dollar impact of friction. They broke it down into two numbers.
One was how much friction they could easily identify and how much was that costing, and then they identified avoidable incidents and calculated that dollar amount too. The result was that in just 12 months, they had millions in documented savings and an increase in developer satisfaction numbers, because when your systems are easier to use, they're a lot nicer to work with. The nice thing here is that when we improve our platforms and when we improve our internal systems for developers, it's often a win-win. The challenge is making sure that we communicate it the right way.
The 7-Step Process to Start
Now we have buy-in. Congrats, everyone. We got buy-in. We said go forth. Now where do I start? I've been working with Abi Noda for the last year or two. He's the co-founder and CEO of DX. We found that there are about seven steps that companies walk through, so this is based on conversations with hundreds of teams, large companies, small companies, tiny startups, several different industry verticals, and they all follow the same general pattern. Step one, just talk to someone. We want to collect some data, but often the best way to get good data and the fastest and cheapest is just go talk to a handful of folks. Next is to start small and get a quick win. Step three is to use data.
At some point, you'll probably need some more signal and some more data. Then you'll decide strategy and priority because you will probably walk away from your data collection efforts with a laundry list of things that need improved. We can think about prioritizing a couple different ways. I'll talk about that. Then we need to sell the strategy. We need to convince people that this is the right move. We need to drive change. I say at your scale because it could be your job at your company. You could be a director or a VP. You could be an engineer who's just decided, "This sucks. I want things to be better. How can I create change where I am?" Then there's also some middle ground in between there. After you've made some changes, evaluate and show value. The nice thing about this framework is you can start anywhere you are now. If you're walking in and nothing's been done, you might want to start at step one. If you're walking in to an ongoing initiative that's been happening for a couple of years, you might want to jump in to decide strategy and priority.
We always want to start with listening. I will recommend that whichever step you start at, go talk to a handful of folks. It'll give you a much better idea of what it's like, what their current challenges are, what they're facing. Before any surveys, before any metrics, just ask what's getting in their way. Ask what they swear at every day. They will tell you. We'll tell you what sucks. Then we start collecting some patterns. We can map the workflow. We can take a look at the processes. Often, we see friction in handoff points, points between systems.
Then the next step is to pick a first win carefully. This is where we want to have a quick win. Here's my quick heuristic for this, it's visible. It matters enough that you can see it and it's visible. When I say everyone can see it, a developer will notice it, and an executive, we can communicate it to them in a way that is meaningful. Next is that it's achievable quickly. We want to be thinking about weeks here, not months, like a quarter at the most. It can benefit multiple teams. Here you will probably start with one team and do a deep dive, but the problem should be big enough that once you find a win in one or two teams, you can generalize it across many different groups. This is great for a quick win.
After that, I often see teams come back and they say, now I don't know what to do next. I did the obvious low-hanging fruit. I did the obvious quick wins. Now we want to capture some data. There are lots of different kinds of data here. System, any kind of telemetry that we have, any logs. We also want to look at outcomes. What do developers achieve? Productivity, lead time, defect rates, and then impact. This is really what matters to the business. Do we see revenue, satisfaction, time to value? These are the trickier ones. I would at least start with those first two categories. Don't count out things like surveys. It can be a lot faster and a lot cheaper to get some pretty reliable survey data across thousands of engineers or hundreds of engineers versus instrumenting all of the systems. Instrumentation is expensive. What if we've instrumented the wrong thing?
Once we have all that data, we should prioritize. I like to use the RICE framework. We're looking at reach. How many people will be affected by this? Impact, how much will it improve their work? It could be hours saved. Confidence, how certain are we that this is possible or doable? All of those three we want to have higher. Higher is better. Then, effort, we want to be low. How difficult is this? How much time will this take? How much headcount will this take? How much engineering time will this take? Here's one example. Let's say we have three possibilities. We have flaky test automation, streamlining a code review process, and monitoring dashboards. The reach on the first two is high. On monitoring dashboards, it's about medium.
The impact, similarly for the first two, is high. For monitoring dashboards, it's a medium. Now when we get to flaky test automation, we're fairly confident that we can do this. We know we can do the code review process. Monitoring dashboards, we also know we can figure this out. Now, effort. Flaky test automation is very high. A lot of times, this takes a lot of effort. AI is helping here. Streamline code review process, effort could be low. This could be super straightforward. Then monitoring dashboards is about a medium.
In this example, I would start with the code review process: broad impact, high confidence, quick wins, not too much effort. The other nice thing about this is we can experiment locally. We can see what's working, roll it out across a couple other teams. It's a quick and easy way to jump in and find improvements. Beyond just RICE, it's really helpful to take a step back and consider a few other things that are specific to your context. I had already mentioned reach, but frequency. How often does it occur? Pain severity. Is this a minor annoyance or a complete blocker? That's part of frequency and impact. Many times, people will absolutely hate something that they have to do, but they only have to do it monthly, versus something that's a slight annoyance, but it's every single day.
Strategic alignment, does this support business priorities? Maybe even, is there already an ongoing effort in this area that we can catch a tailwind from? Can we align ourselves to something that's already ongoing so we're not starting from scratch? Dependencies would unlock other things. There have been a couple times where I saw something look like it's pretty obvious. There was like a top two, but the second one would unlock everything else. It was a blocker for everything else that we wanted to do, so we started there.
There are some common mistakes that we often see in improvement. The first one is just starting with data, throwing metrics at a thing. This can be challenging for a couple of reasons. One is because data just doesn't talk to people. Some people really love metrics, but if you love a data point, you always want a story to go with it. The other challenge here is if you're starting with metrics, and this is not a very mature measurement program, you're just taking whatever data points are already conveniently available that are probably not meant to measure or communicate the thing that we're trying to communicate.
The second mistake is trying to do absolutely everything at once. We can't do everything. It's much better if we can pick one thing and do it well. The third is optimizing only for execs. If a tree falls in the wood and no one hears it, does it make a sound? If developers don't notice, this is going to be really challenging. Then the fourth is just treating it like a project, where we'll kick one thing out and we'll be done. We really want to be thinking about sustainable improvement here, and engineering improvements into our system as we go on.
Scaling DevEx: Three Patterns
I said we then also want to be sharing at our scale. Local scope, any IC can do this. Any IC on a team, you can pick something small. You can pick something that's obvious to your team. Maybe you can pick your own or suggest a Friday hack day to your manager. If we can prove value and document learnings, that's really impactful, because then you can also start sharing it across the company and across the organization. Next is middle ground. If you're maybe an engineering manager or a second line, again, look for those common challenges. Build a coalition. Get folks who really care deeply about this. Find your champions. Start creating more reusable solutions that other folks can use, tooling, runbooks.
Then, finally, if this is your day job, if you're embedded in the org, you can think differently about the scope of projects that you tackle. You can think about resource allocation and flexing resources back and forth. We can measure a little more systemically. Again, local scope, think about our own processes and tools. What does my team use now? What can I improve myself? Here is where you really are the example that creates the demand, because good news tends to travel pretty fast. If things are a lot better on a team or a couple of teams, that works really well. For middle ground, this is where we want a few more proof points, and create slightly more scalable solutions. When it's just you and your team, you can start just by doing custom work. We still don't have mandates here. At global scope, this is now strategic infrastructure. We start thinking about it in terms of larger scale infrastructure efforts.
The Impact of AI
How does all of this change with AI? Some things don't change at all. We still have the fundamentals. The SPACE framework helps us think about the data points we want to measure. S is for satisfaction. Are developers satisfied with the tools or the processes they have? P is performance. What's the outcome? Quality outcomes. What's our test pass rate, or what's our build fail rate? A is activity metrics. These are the ones that can be counted. This is what most people think about when we think about data. This is lines of code. This is the number of pull requests. Anything that can be counted. C is communication and collaboration. This could be PRs. This could be API calls. This could be how often developers are taking meetings.
Then E is efficiency and flow. How long does it take to get something done? These still apply in AI. The specific focus might be different. We might be asking about an AI tool instead of a generalized workflow. We have tons of examples here. DORA metrics, I mentioned they capture end to end. This is still super important with AI. If anything, we're seeing that a lot of folks are doubling down on inner loop even more than they had before, just writing the code and submitting it, to doing code review.
Then everything past there was just not my problem. DORA focuses on that because we're seeing that while the inner loop is speeding up, the outer loop is still just as slow and maybe even struggling. We do see that workloads have changed. Now instead of just measuring lines of code or a feedback loop on a PR, we should also be looking at prompting. How long does it take to get an answer to a prompt? How long does it take to get progress on a handful of prompts so that we can move forward? When we're looking at agentic workflows, how are developers thinking about steering and creating the agents that are there? Then we have to review and validate AI generated code. Now we probably want to ask questions like, do our review processes capture AI generated code and improve AI generated code as well as they did historically? What is our code survivability of code that was written by AI? Does it still make it through the pipeline? Is security different? Is reliability different? What things change here? Lines of code was always a bad metric. Has anyone been in a meeting where someone wanted to measure lines of code?
If not, bless you, sweet summer child. This comes up all the time. I will say one thing I like is that AI has made it fairly obvious that lines of code is an absolute nonsense metric, because now we're getting way too many lines of code. It's just so verbose. We have so many comments. We know that sometimes the best thing you can do is delete code. How do we want to think about this now? Again, prompting efficiency. How long does it take to get a suggestion that lives? How hard is it to validate? Can we use AI to validate? Are people just spending all of their time in code reviews now because they're getting work slop? How do we want to think about trust calibration? This is super important. Because if we trust too much, we're shipping bugs. If we trust too little, just don't use AI. We're wasting so much time triple checking. Workflow delegation, what work goes to AI and what work goes to humans? What are the implications of that? How does that change our cognitive load? How does it change our understanding of the system and our mental models? How does it impact speed?
The most important thing here that I would say is to use, in research, what we call mixed methods. We want data from systems and we also want data from people. The system data can tell us what is happening, maybe what is going wrong. It often can't tell you why it's like that. This example came up in a team that I was chatting with a couple of months ago, actually. There was a huge rejection rate on any kind of code suggestions for an auth aspect. The owning team just couldn't figure out why. They're like, this isn't working. Is it awful? The answer happened to be that AI was hallucinating a lot of security vulnerabilities. That gave them some action. They just constrained AI on a lot of security-critical code, which ended up saving the team a lot of time.
Now, they're still exploring avenues and solutions in this space. It freed up so much time that folks were spending. It still takes time to have to jump in and read code and reject it. Although I think some folks were just auto-rejecting, because we know there's code smells for AI code. Now we knew why. I would invite folks to think about doing some of this yourself. What are we waiting for? We have so much opportunity in the code and the codebases that we're writing. The organizations that are winning with AI right now, they're not just adopting new tools. They haven't just given everyone Gemini CLI, or GitHub Copilot, or Cursor. Pick your code of choice this week. There are at least a dozen good ones. What they're doing is they're really removing the friction so that developers can get that code in front of a customer. They can run an experiment. They can actually move faster. All of the big companies that I'm seeing are actively trying to find ways to remove that friction now. I would suggest we all think about this in our own work.
Action ItemsIf you wanted to do just one thing, here's one suggestion. For ICs, map your workflow for a week. What are the times when you lose 30 minutes to just nonsense that shouldn't be a thing? Where is there a challenge? Chat with someone else on your team, says interview one peer. Chat with someone else. See if they see the same friction points that you do. If you're a team lead, do a quick 30-minute retro. What slowed us down this week that wasn't the work? Or maybe, what slowed us down, again, that shouldn't have taken that long? Because code review is work, but is something in that process really difficult? Was a legal review taking a long time, and it always takes a long time? Because again, a lot of times, what's holding us back and what the biggest points of friction are is a process. For leaders, go talk to at least three people. Maybe do some napkin math for some of the friction points. Just get an idea and a feel for where the friction is in the organization. Remember that small changes really compound into transformation. Once you identify that one thing, then ask yourself, what is the smallest thing I can do? What is the easiest and the quickest thing I can do to remove this friction point?Resources
I have a new book coming out. It covers a lot of these steps in detail if anyone is interested. This QR code will point you to a website where we have about 100 pages of free workbooks. There are so many free workbooks here. We have templates and frameworks. I have the RICE prioritization framework with examples. I have Quick RICE, which is heuristics, and I have more detailed RICE. We have interview guides. I have example surveys and extra survey questions. Because sometimes if we want friction, there's about three or four questions you can ask. That's in there. Tons of rubrics and spreadsheets.
See more presentations with transcripts
Recorded at:
Mar 24, 2026
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み