プレゼンテーション：摩擦から流れへ：優れた開発者体験がいかにすべてを素晴らしくするか

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 日

プレゼンテーション：摩擦から流れへ：優れた開発者体験がいかにすべてを素晴らしくするか

背景や根拠まで確認しますか？

調べる

選ぶ

サイト