ポッドキャスト: [ビデオポッドキャスト] ニコール・フォーシュグレンと考える摩擦のない開発者体験
InfoQのポッドキャストで、トーマス・ベッツが『Accelerate』の著者でDevOpsと開発者生産性の専門家であるニコール・フォーシュグレン博士と、彼女の新著『Frictionless』の主題である開発者の摩擦の特定と解消について議論している。
キーポイント
開発者体験（DevEx）の重要性
開発者の生産性とソフトウェアデリバリーの成功には、開発プロセスにおける摩擦の特定と解消が重要であると議論されている。
『Frictionless』の主題
ニコール・フォーシュグレン博士の新著は、開発者が直面する摩擦を体系的に取り除く方法に焦点を当てている。
『Accelerate』からの継続
DevOpsと開発者生産性に関する先駆的な研究を基に、実践的な改善アプローチが提示されている。
影響分析・編集コメントを表示
影響分析
この議論は、ソフトウェア開発組織が開発者体験を体系的に改善するための実践的な洞察を提供する。DevOpsと開発者生産性の分野における継続的な進化を示しており、技術リーダーやエンジニアリングマネージャーにとって重要な参考資料となる。
編集コメント
開発者体験の改善は、AIシステムの開発・運用においても重要な基盤となるテーマであり、技術組織のリーダー層に広く参考になる内容だ。
ビデオを見る:
文字起こし
トーマス・ベッツ: こんにちは、InfoQ ポッドキャストへようこそ。私はトーマス・ベッツです。今日は、DevOps および開発者生産性において最も著名で重要な人物の一人である、ニコル・フォアグレン博士にお話しできる光栄があります。彼女はマイクロソフト、GitHub、Google といった企業で生産性の向上を主導し、『Accelerate』や『DevOps ハンドブック（第 2 版）』というベストセラー書籍の著者でもあります。彼女の最新作『Frictionless』では、開発者の摩擦（friction）を特定し除去することについて論じています。昨年 11 月には、サンフランシスコで開催された QCon の基調講演でこのテーマについてお話しされており、本日はその内容について議論してまいります。ニコルさん、InfoQ ポッドキャストへようこそ。
ニコル・フォアグレン: ご招待いただき、ありがとうございます。
開発者体験（DevEx）における摩擦の有用性 [01:07]
トーマス・ベッツ: QCon でのお話しの中で印象に残っているのは、開発者生産性は単にビルド時間の短縮やツール性の向上だけではないという点でした。私たちは、常に私たちを遅らせているこれらの摩擦ポイント（friction points）に目を向ける必要があります。なぜ「摩擦」という概念が DevEx に関する議論を枠組みづけるのに有用なのか、また、あなたが言うところの「摩擦」の具体例をいくつか教えていただけますか？
Nicole Forsgren: はい、もちろんその通りです。摩擦という概念は、開発を改善するための最良の領域を探し、どのように改善できるかを考える上で非常に役立つと思います。従来、多くのプロセスが手作業に依存していたり、過度な手順を必要としたりするケースがありましたが、それらはしばしば脆く、すぐに破綻してしまう傾向がありました。現在も AI においては同じことが言えますね。AI はさまざまな形で現れます。
今私たちが目にするコード生成の自動補完機能などは、まるで魔法のように突然現れることもあります。しかし、それが逆に、リリースやデプロイといった以前は手作業で行われていたプロセス（多くの企業で一般的です）におけるビルドアップの過程で、追加的な摩擦ポイントを生み出す結果にもなり得ます。現在、多くの企業が膨大なバックログを抱えていますね。つまり、摩擦が生じている箇所は、負荷と速度が増加し始めた際に、システムがどこで脆くなり、ひび割れを起こす可能性があるかを示す重要な指標となるのです。
DevEx に注目すべきは誰？ [02:16]
トーマス・ベッツ: 脆くて崩れそうなものについて話すとき、それは開発者のマシンや特定のサービスだけの問題ではなく、会社全体の課題になり得ます。それがすべてにどう影響するか？誰が DevEx（開発者体験）に関心を持つべきでしょうか？ソフトウェアにおける最も難しい問題の一つは名付けですが、「DevEx」という言葉は「ああ、あれはコーディング担当者が対処しなければならないことだ」のように聞こえがちです。しかし実際にはより大きな問題であり、他の人々にもこの問題を認識させ、それが会社全体として私たちにどう影響するかをどうやって示せばよいのでしょうか？
ニコル・フォアグレン: それは非常に良いご指摘です。DevEx はそこにおいて少し挑戦的な側面があるかもしれませんね。開発上の摩擦や価値の提供といった文脈で捉えられることもあります。しかし、人々が関心を持つべき理由は、私たちが経営陣に繰り返し伝えたり、リーダーシップ層がこれらの派手な見出しを読み進める中で理解している通りです。「1 時間で新しい製品や機能を立ち上げ、デプロイできる」といった内容の headlines です。それは確かに興奮を呼びます。
完全に現実的な話ではありませんが、そのような状況において、リーダーシップに対して非常に洞察に富み、有益な情報を提供できるのは、この高速な道筋に乗りたいと願う場合や、AI を活用してこれらの素晴らしいことをすべて実現したいと考える場合です。そのためには、いくつかのシステムやプロセスを見直す必要があります。なぜなら、現状では多くの部分が開発者や開発パイプライン、つまり開発体験に集中しているからです。しかし、あなたが指摘されたように、必ずしも開発者だけとは限りません。セキュリティおよびコンプライアンスレビューの場合もあり、歴史的には大きな行き来があり、時には「セキュリティ・シアター」と呼ばれるような状況で、数週間にわたって交渉が行われたこともあります。
これは今や非常に難しく、すでに人手不足に陥っているセキュリティおよびコンプライアンスチームにとって圧倒的な負担となっています。また、リリースやローンチがどのようなものかについても考える必要があります。現在、多くの大企業が候補となるビルドを手動で選択し、それをテストに通し、さらにカナリア展開を行うというプロセスを踏んでいます。手作業が多く、引き継ぎが発生し、独自の判断ポイントが存在する限り、負荷と摩擦が増えるほど、そのようなプロセスが破綻するリスクが高まります。あなたが言われたように、それはビルドだけのことではありません。脆く、破綻しやすい承認プロセスである可能性もあり、その場合、ビジネス側は影響を受けます。なぜなら、状況の変化があまりにも急速だからです。
つまり、今朝の最新のモデルは、3 ヶ月前や 2 ヶ月前にはできなかったことを実行しています。したがって、競争のペースや業界のペースに追いつこうとする場合、たとえ機能開発の一部を加速させるだけであっても、追加されるあらゆる摩擦が、私たちの作業を遅らせている要因や、潜在的な脆弱な分岐点を浮き彫りにすることになります。
迅速なフィードバックによる摩擦の可視化 [04:42]
Thomas Betts: はい、人間が動く速度とコンピュータが動く速度の違いという考え方に通じるものがあると思います。長年にわたり、人間の速度であれば問題なく機能する多くのプロセスが開発されてきました。メールのプロセスを完了するには数日かかることがありますが、それは構いません。その間、私は他のより速い作業に集中できます。
AI やその他の自動化があらゆる分野に浸透するにつれ、単にコードを高速で記述できるようになるだけでなく、ユーザーストーリーも迅速に作成できるようになります。
これらすべてが圧縮され、結果としてプロセス全体がコンピュータの速度で動作し始めます。その時こそが摩擦が生じる瞬間であり、私たちはより速く、さらに速く、そしてさらに速く摩擦とぶつかり合い、それが火を起こすことになります。
Nicole Forsgren: その通りです。特に今、エージェント型ワークフローにおいて非常に興味深く刺激的な開発が進んでいる最中ですからね。かつてビルドが遅かったためにビルドを高速化し、さらに並列化して同時に実行できるようにしたのと同じことが、今起こっていますよね。もはや一人の開発者と一つのエージェント、あるいは数人のエージェントという関係ではありません。ある開発者が多数のエージェントをオーケストレーションし、それらのエージェントが自ら仕事をオーケストレートし、自らの問題を解決するという形になっています。そのため、あらゆる摩擦点は増幅されてしまいます。
DevEx の指標 [05:52]
Thomas Betts: はい。では、どのようにしてこれを測定すればよいのでしょうか？過去に用いられてきた指標にはどのようなものがあり、AI 時代へと移行し自動化がさらに進む中で、それらは依然として機能するのでしょうか？同じ指標を使い続けるべきなのか、それとも指標自体が変わる必要があるのでしょうか。
Nicole Forsgren: これが大きな問いですね。一部の指標はそのまま残るでしょう。一方で、一部の指標は確実に変わるはずです。例えば、コード行数（Lines of Code）は、もともと良い指標ではありませんでした。
Thomas Betts: 確かにひどいものでした。
Nicole Forsgren: しかし、それは常に指摘されていました。現在、私たちはある意味ではコード行数という指標は完全に無意味なものであるという空間にいます。なぜなら、適切なプロンプトがあれば、私は数百行のコードを生成できるからです。他方、これは非常に特定の文脈においてのみ有用である可能性があります。例えば、私たちのコードベースがどのように見えるか、時間が経つにつれてそれがどのように進化しているか、そしてそれが現在のモデル調整やモデルトレーニングに何を意味するかといった文脈です。
なぜなら、私たちが特定の方式でアーキテクチャ設計し、設計し、コーディングした歴史的なコードベースでモデルを調整する場合、あるいはそれについて仮定を持っている場合、まもなく私たちのコードベースの少なくとも 1% が機械によって書かれたものになるという、ゼロではない非常に大きな割合になったときに、それが何を意味するのか。そのループにフィードすることに対して何が言えるのか。ML や AI の多くの専門家にとって、私たちが知っているのは、投入されるデータは単に増幅されるだけだということです。そのため、初期のデータやトレーニング、推論セットで捉えきれない何かが、予期せぬものに変化してしまう可能性があります。これが指標の一つの例ですが、重要な指標は一つしかないという考え方はなく、状況によって異なる指標が重要になるのです。
私たちが以前から持っている多くのフレームワークは、今日でも非常に重要です。例えば DORA を見ると、これはパイプラインに焦点を当てています。リードタイムの速度、つまり完了までにどれくらい時間がかかるか、デプロイ頻度、つまり一定期間におけるボリュームです。また、変更失敗率という品質指標や、MTTR（平均復旧時間）といった回復に関する指標も含まれています。私がこれらの活動を開始した当時は、ソフトウェア開発パイプラインを徹底的に計測・設計することが、私たちが行える最良の取り組みの一つでした。
これにより変動性を低減し予測可能性を高めることができますが、これらのフレームワークは、アイデア創出から実装・コーディング、そして本番環境に至るまでの製品開発全体、ソフトウェアデリバリー、機能開発のすべての分野で依然として適用可能です。なぜなら、スピードもスループットも品質も重要であり、これらを通じてプロセスを評価できるからです。
開発者や開発者の生産性を考える際、SPACE というフレームワークもここでは有効ですね。満足度を見ることができます。開発者は自分が持っているツールやパイプラインに満足しているでしょうか。パフォーマンスは、再び品質の成果物に関わるものです。プロセスの結果は何でしょうか。A は活動です。すべてのカウント、コード行数はどうでしょうか？あまり良いものではありません。コミット数、PR 数、一定期間内のレビュー数などです。コミュニケーションとコラボレーションでは、人々は情報の大部分をどこから得ているのか、あるいはシステムはどのように通信できるのでしょうか。API は比較的うまく機能しているでしょうか。そして完全な効率性として、どれくらいの時間がかかるでしょうか。
これらのいくつかを拡張する機会があると思います。一つには、これらはエージェントについても同様に当てはまる可能性があります。エージェントにとって使いやすさはどの程度でしょうか？エージェントの満足度はどうでしょうか？直接尋ねることはしないかもしれませんが、そうする場合もあるでしょう。しかし、それは異なる種類の摩擦として表面化するかもしれません。
いくつかの次元を追加することも検討すべきかもしれません。ここでは「信頼」が思い浮かびますね。信頼は…常に重要視されてきました。システム管理者コミュニティでは、私たちは常に信頼を中心に据えてきたはずです。システム管理者や SRE（Site Reliability Engineer）のことです。しかし今、開発者たちはそれをより意識し始めています。なぜなら、彼らは以前から比較的予測可能なシステムの中で働いてきたからです。
次に「コスト」について。コストは昔から存在する要素ですが、現在では計算リソースのコストがどれくらいか、キャパシティ（容量）はどうなるかといった点で、明確なトレードオフを迫られています。例えば、「100 のタスクをこなすために 1,000 個のエージェントを展開し、人間 1 人を置き換えるべきか？もしそうすれば、すべてのシステムがダウンしてしまうのではないか？」という問いに直面しています。
この話題には多くの指標がありますが、これはその長編版のようなものです。特定の指標に対する答えは持っていません。なぜなら、それは環境や文脈、利用可能なデータ、そして何を明らかにしようとしているかによって大きく異なるからです。
DevEx とシステム思考 [09:46]
Thomas Betts: はい、あなたが言おうとしているのは、生産性を測定しようとしているということだと思います。再び「開発者体験（Developer Experience）」という言葉に戻りますが、より良い開発者体験があれば、あなたの基調講演のタイトルであった「摩擦からフローへ」のように、DevEx がすべてを素晴らしいものにするのです。「そうだね、それはそうだが」と思いつつも、「開発者」と「開発者体験」という名前のせいか、私たちは改善しようとしているのはそれだけだと考えがちです。しかし、常に大きな視点で捉えるべきなのです。それは常にソフトウェアのデリバリー（提供）に関わることであり、まさに私たちが目指していることです。
Nicole Forsgren: その点は非常に重要だと思います。システム全体の視点を持つことで、何が起きているのかをより深く理解できます。確かに初期段階では、早期のシグナルが得られる開発者に焦点を当てることもありますが、常に重要なのはシステム全体です。開発者は常に何らかのシステムの中で作業を行っています。それが手動プロセスのみからなるシステムであっても、メインフレームに依存したシステムであっても、クラウド上で高度に自動化されたシステムであっても、あるいは最近では多数の AI エージェントや AI ツールを活用するシステムであっても、すべてはシステムの一部として機能しています。
Thomas Betts: はい。コード行数が極めて不適切な指標であるというあなたの例についてですが、これはかつて生産性の代用指標として使われていたことがあります。「1 日に 100 行のコードを書ける versus 10 行しか書けない」といった比較です。しかし、私は実際に使用される 10 行の完璧なコードの方が、100 行のゴミのようなコードよりもはるかに価値があると思います。
Nicole Forsgren: その通りです。時にはコードを削除することが正解となることもあります。では、それをどう測定すればよいのでしょうか？
AI エージェント、コード品質、開発者ワークフロー [11:08]
Thomas Betts: しかし、システムが正常に納品され、安定して稼働し、ダウンタイムが発生せず、かつ迅速に多くの小さな変更を加えられるという目標を達成できている場合、その測定可能性はやはり「デベロッパーエクスペリエンス（Developer Experience）」と呼ばれるものに戻ってきます。しかし、それは単なる一つの要素ではなく、これらすべての他の要因を含んだものです。そこで私が指摘したいのは、あなたが最近おっしゃったアイデアについてです。つまり、「エージェントにデベロッパーエクスペリエンスについて尋ねる」という発想ですね。コーディングエージェントを持っている場合、そのエージェントに対して「進捗はどうですか？」と尋ねるのか、それとも「私の指標を要約してほしい」「DORA（Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Restore）などのデータを要約してほしい」と依頼するのでしょうか。
Nicole Forsgren: 現時点では私はエージェントにそのような質問はしていませんが、近い将来それが実現する世界も来るかもしれません。この内容が公開される頃には、すでにその世界にいる可能性もありますね。しかし、言葉で問いかけたり、エージェントが開発・コードを納品する様子を示すいくつかのデータポイントを眺めたりすることで、機会があると考えます。私たちは人々に話を聞く際に探しているような要素を検出できるはずです。例えば、「あなたの業務の中で本当に難しいことは何ですか？」「いつもイライラして怒鳴ってしまうのはどんな時ですか？」といった問いです。また、エージェントが何度も同じプロセスをやり直さなければならない特定の工程や問題がないか、どこかで摩擦が生じていないかを観察することもできます。あるいは、直接エージェントに尋ねることも可能です。その結果として何が得られるのかを確認できるのです。
彼らの仕事の下流への影響、あるいは彼らが実現できる成果を見ることができます。そこで私は、エージェントや AI が働く文脈を問い直す機会があると考えます。これにより、エージェントがどれだけよく機能するか、またシステム内でそれらをどのように準備しているかが明らかになります。同時に、コンピュータはまだ対応できていない困難で創造的な課題に答えるために、開発者をより良く準備し支援する方法について考え直すきっかけにもなります。
Thomas Betts: はい。そしてそれは、ワークフローがどのように進化しているかという点に戻ります。私たちは往々にして AI コーディングエージェントに焦点を当てがちです。それが最も簡単な部分でしょう。GitHub Copilot や Claude Code がありますね。これらは私のためにコードを書き、「この関数を書いて」という指示から、エージェントに作業を任せて考えさせ、解決させる段階へと進化しています。このエージェントモデルはソフトウェア開発ライフサイクル全体で展開されています。製品管理の分野では PM の隣に座って支援する製品管理エージェントも登場し、スクラムマスターやバックログ管理、ストーリー作成、タスク分解を助ける人々も、言語を扱うという根本的な性質ゆえに、さまざまな形で現れています。
大規模言語モデルは言語を生成する際に優れています。私が話した「C」の概念、つまりコミュニケーションとコラボレーションについてですが、私が問いたいのは、人間がより良くコミュニケーションを取るためにこれまで取り組んできたことをどう活かすか、そしてループ内にエージェントが存在する場合や、効果的なコミュニケーションパターンがあればこれらのエージェントツールの活用を支援できるかどうかです。
AI 時代におけるコミュニケーション、ドキュメンテーション、コンウェイの法則 [14:02]
Nicole Forsgren: そうなる可能性が高いと思います。あなたが触れられた例の一つとして、作業を細分化し、エンジニアが実装できるように非常に明確で構造化された要件を提供することが挙げられます。私たちは、非常に明確な要件と明確な設計ドキュメントの間には違いがあることを知っています。また、どのレベルのエンジニアがそれを処理できるか、あるいはどのレベルのエンジニアに任せるべきかについて、より曖昧なドキュメントが存在することや、ドキュメントにおける不明確さという課題にも直面しています。
では、設計ドキュメントや機能ドキュメント、機能仕様書が非常に明確であれば、そのコミュニケーションは人間との間でも高忠実度であるのと同様に、エージェントとの間でも高忠実度になります。おっしゃる通り、それは言語の問題に帰着するからです。したがって、私たちがよりよくコミュニケーションし、仕様が明確になるほど良いのです。これも一つの例です。
また、API をより明確に定義して文書化することも重要です。つまり、エージェントがそれを使用する場合や、社内で頻繁に使われるものの外部には文書化されていない内部ライブラリ（ある企業内での一時的な使い捨て的なもの）の場合などです。確かに、多くの開発者は、もし自分がそれを数回使用し、そのエッジケースを知り、どこに「ドラゴン」が潜んでいるかを知っていれば、それで十分だったかもしれません。
しかし今、シニアレベルのタスクをある程度こなせるジュニアレベルの開発者がいますが、多くのガイダンスが必要です。これは API や、私たちのシステムがどのように通信するかについても言及できることです。
AI をファーストラインサポートとして活用することのメリットとリスク [15:23]
トーマス・ベッツ: はい。はい、システム境界が適切であれば、システム同士がどのように対話するかは、チーム間や組織の構造とソフトウェアの構造が同じように対応しているはずです。コンウェイの法則がこの文脈で適用されます。まだ AI 版の補遺を記した人はいないと思いますが、もし複数のエージェントがチームをサポートする形で組織を分割・再編成した場合でも、この法則は依然として当てはまります。つまり、「私たちはこれらの人材を抱えており、それぞれに役割を支援するエージェントを配置している」という考え方が、アーキテクチャにも反映されるはずです。
ニコル・フォアグレン: はい。ここ数年、AI がチーム内およびチーム間のコミュニケーションに与える影響について、またそれをどう捉えればよいか、何が良く何が良くないかについて議論してきました。歴史的には、若手開発者が新人研修中や新しいコードベースの学習時、あるいは新規プロジェクトを引き継ぐ際に、チーム内のシニアエンジニアに多くの質問をするケースが多く見られます。これは素晴らしいことです。シニアエンジニアが最も効果的にできることのひとつは、チームメンバーの詰まりを解消することです。しかし、これもまた課題となります。
私のチームには、それこそが彼らの全てであり、そこに誇りを感じているシニアエンジニアもいました。しかし、彼らは多くのブロック解除作業に追われ、自分自身の技術的な仕事をする時間がほとんどありません。それはある意味で難しい状況です。一つのことに非常に誇りを持っている一方で、別のことができないことに対して少し悲しんでいるからです。
さて、今では多くのエンジニアが「AI ファースト」へと移行しており、質問を投げかけています。これは私たちの時間を解放する良い側面があるかもしれませんが、同時に奇妙な道やラビットホール（脱線）、あるいは「亀の背にまた亀」というように、思いもよらない奇妙な場所に導いてしまう可能性もあります。
そこで考えなければならないのは、コードベースをよく知る AI エージェントに質問したり、会話したりする際に、どのような適切なチェックポイントがあるのかということです。そして、自分の計画や発見をチーム内でそのコードベースを本当に熟知している誰かと確認・検証するのは、いつが適切なのでしょうか？
トーマス・ベッツ: そして、チームや企業に新しく加わった人にとって、それは出発点によって異なります。スタートアップでゼロから始める場合、コードがまだ存在しないこともありますよね。すべてを一から構築する必要があります。頼れる例もありません。もし頼れる例があれば、「ああ、こうすればいいんだ」と言えるでしょう。「エージェントに聞いて、読んでいるコードを説明してもらおう」などです。しかし、レガシーコードもあり、これが望ましいやり方ではないと知りつつ、より良いものに移行したいと考えているが、より良いものの具体的な例がまだ示されていない場合、「いつもそうやってきたのだから、そのまま続けなさい」といったフィードバックを得るかもしれません。
ニコル・フォアグレン: それは私たちのパターンに合致しています。
トーマス・ベッツ: はい。一方、シニアエンジニアは「昔はこうしていた」と言うでしょう。私たちはそれをやめたいのです。新しいことをしたいと考えていますが、それがまだエージェントが参照するドキュメントや、新しく入った開発者が参照する資料のいずれにも記録されていない可能性があります。そのため、やはりこれらの人々を関与させる必要があります。
ドキュメンテーション、RAG モデル（Retrieval-Augmented Generation）、そして持続可能なプラクティス [18:06]
ニコル・フォアグレン: はい、その通りです。文脈に即した方法で働く必要があるという点にも少し立ち返ると思います。小規模で機敏なスタートアップと大企業では状況が全く異なります。一方で、10 年後には撤回されるかもしれませんが、普遍的に真実であり続ける要素もあります。例えば、良質なドキュメントはそうですよね。どんなに機敏なスタートアップであっても、README や基本的なドキュメントがなければ、それは一定期間しか持続できません。いずれ限界が来て破綻します。コードベースが作成されてからの時間が経てば、必ずそのドキュメントが必要になります。
そして現在、AI にはコードを分析し、少なくともコードのドキュメント化を支援してくれる非常に興味深く有望なツールが多くあります。これは今後もしばらく真実であり続けるでしょう。なぜなら、私たちがプロンプトを入力したりフィードバックを求めたり、エージェントに作業を依頼する際、それらは私たちが持つコードやドキュメントを参照するからです。RAG（Retrieval-Augmented Generation：検索拡張生成）モデルを構築する場合、人間にとってもエージェントにとっても作業結果がより明確になるよう、彼らに対して何を明確化したいのかを考える必要があります。
開発者体験（DevEx: Developer Experience）に対するステークホルダーの合意形成 [19:11]
トーマス・ベッツ: 少し方向を変えてお話ししましょう。これはあなたが基調講演や『Frictionless』という書籍でお話されていた内容の一部ですが、どうすればこれを会社全体が納得して受け入れるものに変えられるか、つまり、「この摩擦を取り除きたい」というアイデアから、「これに焦点を当てよう」「これに投資すべきだ」という合意形成へと至り、これらの課題を改善しなければならないという認識に至るプロセスについてです。ステークホルダーの合意形成はどのように変化しているのでしょうか？あるいは、AI を導入する前の状態からどう始まるのか、そこから話を始めることもできます。つまり、単に指標を持っている、あるいは指標の収集を開始できる段階から、CEO や CTO が納得して信じるようなストーリーを語れる段階へとどう移行していくのかについてです。
ニコル・フォアグレン: いくつかの点は、依然として概ね真実であり続けるでしょう。つまり、私たちは自社のビジネスや組織の優先事項と整合性を持たせたいと考えています。また、彼らが抱えている問題を理解し、その問題を解決したいとも考えています。そのため、多くの場合、私たちが持っているデータを文脈化し、それらの問題を解決するために提案するものや、確実に最優先課題であるとわかっているものに合致させることが重要になります。ただし、この戦略の姿は、組織内のあなたの位置や、組織自体が置かれている状況によって少し異なる可能性があります。
したがって、組織内でこの課題が認識されておらず、関心がなく、他の緊急事態に対処する必要がある場合、あなたが個人貢献者（IC）または1 線管理職であるなら、現地で一定の影響を与えるためにできることはありますし、それを上位に持ち上げることを考え始めることもできます。一方の極端なケースでは、CTO またはインフラ担当副社長が、「ソフトウェアをより迅速かつ高品質・高信頼性・高安定性で開発・提供すること」が最優先事項であると宣言している場合もあります。
そして、その取り組みを主導するために雇われることになります。それが DevEx の改善なのか測定手法の改善なのかによって多少の違いはありますが、対象となる聴衆が少し異なる可能性があります。展開戦略も若干変わるかもしれません。チームとの連携は引き続き行いますが、どのチームと協力したいかを考えることができます。引き続き情報発信を行いますが、ステークホルダーは1 線管理職や個人貢献者である場合とは少し変化するでしょう。例えば、私が個人貢献者として最初の報告先を選ぶ際、CTO に直接報告することはまずないでしょう。
どちらの場合でも、ビジネスの優先事項やニーズ、解決可能な課題と整合させることが重要です。そうすれば共感を得られ、会議の参加者も頷きながら「なるほど、確かにそうだ」と理解し、「これが私の必要とする形で整合している理由がわかった」と納得するからです。
DevEx を活用して製品品質を向上させる [21:40]
Thomas Betts: 例を挙げると、企業から「顧客からバグの報告が多く、多くのリリースが行われた結果、顧客によって問題が検出され、品質スコアに影響している。これに焦点を当てたい」という声が上がることがあります。これが最優先事項となります。そして、「バグを書かないようにする」のではなく、DevEx（開発者体験）を見直し、どう改善するかを考えるのが一つの手段ではないかと言えば、それが「どれくらいの頻度でリリースを行っているか」「デイリービルドはあるか」といったAccelerateやDORA指標に関連する項目に結びつきます。より速く行えば、その分上達します。
もし「壊すことが多いから、6 ヶ月間はリリースすべきではない」と言うなら、それは根本的に正しくありませんよね？
Nicole Forsgren: その通りです。そして、それは重要な指摘ですね。つまり、製品や機能の信頼性が低く、バグが多い状況では、顧客エンゲージメントや顧客フィードバックは非常に低くなるはずです。そのような場合、所属する組織のリーダーシップ層、あるいは適切なステークホルダーに対して、「これは私たちにとって大きな問題だと理解しています。現在対応が進められており、これが優先事項であることも承知しています。この問題をどう解決するかを検討中です」と伝えることができます。
その一つの方法として、開発者体験（Developer Experience）に目を向けることができます。その場合、相手は「えっ？」と思うかもしれません。しかし、「はい」とお答えできます。なぜなら、私は従来のソフトウェア開発ライフサイクルがどのようなものか大まかに理解しており、これらの問題が本来検出されるべき主要な領域を特定できるからです。さっそく確認してきます。私の直感では、これらの中には非常に手作業に依存したプロセスや、優先度が低かったために整理されずに残された古びたテストスイート、あるいは不安定なテストが含まれているはずです。
そのため、経営層にとっては、これらの課題を優先事項として結びつけることが自明ではないことが多いのです。
システム開発に従事している私たちには、少数のプロセスやゲートがこれらと直接関連していることがわかります。しかし、常にソフトウェアの世界に浸っているわけではない人々にとって、それはあまり明確ではありません。そのため、そのような文脈で説明することは非常に役立つことがあります。
セキュリティ、コンプライアンス、リスクに基づくアプローチ [23:40]
トーマス・ベッツ: はい、これはまさに摩擦点に関する考え方につながりますね。セキュリティやレビュー、安全性といったものをすべて撤廃しろと言っているわけではありません。それらがブロックとならないようにする方法を見つけるのです。時には、セキュリティレビューという追加ステップを設けることが、別のバックログの発生を引き起こしている可能性にも気づく必要があります。
ニコル・フォアグレン: その通りです。まさにその通りです。
トーマス・ベッツ: ああ、そうですね。手動テストが必要なので、2 週間に一度だけテストを行うことにします。突然、多くの項目が追加され、コードの 2 行を変更しただけで「チェックしたか？壊していないか？」と確認できるような細かな変更をすべてテストできなくなります。
ニコル・フォアグレン: はい、まさにその通りです。セキュリティやコンプライアンスレビューの観点でも、長年見てきたように「古いものが再び新しいもの」となる現象が起きます。リスクベースのアプローチを採用し、低リスクとみなされる変更については、アテステーションモデル（保証モデル）を経由させ、規定されたテストモデルに従わせることができます。これは非常に軽量で監査可能であり、追跡され、遵守されますが、実際には多くの大企業や小企業ではこれが実施されておらず、高リスクの変更とは明確に区別されるべきです。高リスクの変更には、人の目を通す必要があり、議論が必要であり、多くの人を巻き込む必要があります。
しかし、すべてを同じように扱うと、高リスクの変更は本来そのために設計されていないプロセスを高速で通過してしまったり、自動化によって問題ないはずの低リスク変更が、不適切な目のチェックや議論、長時間の会議に晒されたりします。そうすると、いずれ人々は飽きてしまい、結果として高リスクリリースにおいて質の低い判断を下すことになります。
トーマス・ベッツ: はい、はい。繰り返しになりますが、答えは常に「状況による」ですよね？文脈に応じた回答が必要です。ある種のトリガーで、「これはリスクが高いので追加のプロセスを経てください」とか、「閾値に達していないので、これは簡単なゴム印処理で通過します」と言える仕組みが必要なのです。
ニコル・フォアグレン: はい、まさにその通りです。
定性的データと定量的データの比較 [25:27]
トーマス・ベッツ: つまり、データを収集し、アンケートを実施した上で、どのようにアプローチすべきかという点について、まだ議論の余地があると思います。あなたの著書では、定性的（qualitative）および定量的（quantitative）な測定について言及されていましたね。システムから指標を取得できる場合もありますが、それが必ずしも有用とは限りません。単に入手可能なデータが得られるだけかもしれません。コード行数も取得できますが、それが何を示すのでしょうか？あるいは、ソフトウェアのリリース頻度はどうでしょうか？これらのデータは、おそらく計測機能（instrumentation）によって収集されているはずです。一方、アンケートはより定性的なフィードバックを集めるために実施されます。開発者に「何が問題か」を尋ねれば、彼らは問題を明確に教えてくれます。
Nicole Forsgren: 彼らは何がダメなのかを告げます。そして今、特に AI が多くのことを変え、人々に SDLC（ソフトウェア開発ライフサイクル）のあり方を再考し、再発明するよう促しているこの時期において、私はそう思います。数年前には、外側のループを圧縮する世界が来るかもしれないと述べました。まだそこまでは到達していないと思いますが、おそらく近づきつつあるでしょう。プロトタイプから直接本番環境へ進む世界では、「信頼できるのはシステムデータだけだ」と言いながら一歩引いて考えることは本当に難しくなります。なぜなら、新しいツールやシステムを非常に速く作っているため、それらを計測（インストゥメンテーション）していないからです。
これは通常、新規開発者や内部製品、さらには外部製品のビルダーにとって最優先事項ではありません。計測（インストゥメンテーション）、テレメトリー、観測可能性（オバザビリティ）です。もう一つの問題は、変化があまりにも急速であるため、計測手段を構築し、データウェアハウスやデータレイク、データファブリックに投入してすべての計算を行うまでに数週間かかることがあるということです。そして、物がこれほど急速に変化する中で、開発者数名に直接聞き、あるいは開発者数名を観察して、「現在の開発ワークフローはどのようなものですか？今、最大のボトルネックは何ですか？」と尋ねることは、非常に強力であり、少なくとも何もしないよりは遥かに良いことです。場合によってはプロセスが原因となることもあれば、システムが原因となることもあります。
時には、それは単なるメンタルモデルに過ぎないかもしれません。彼らは全く異なる物事について考えることに慣れていないのですから、システムデータがそれを表面化させることはできませんよね？なぜそうなのかを私たちに教えてくれるわけではありません。したがって、特に状況が急速に変化する際には、これを省略することもあります。もしデータがないのであれば、アンケートやインタビュー、観察があなたの味方になるでしょう。
Thomas Betts: はい。これは「一つのことだけやる」か「すべてやる」かの二択ではなく、優先順位をつける問題ですよね？
Nicole Forsgren: はい、そうです。ポートフォリオアプローチを持つことですね。
着手点：クイックウィンとローカルの勢い [27:42]
Thomas Betts: はい。実際に努力を払うなら、どこから始めるべきかどうやって特定すればよいのでしょうか？大きな課題に取り組むのか、小さなことから始めるのか、確実に成功するものに焦点を当てるのか。どこへ向かうべきでしょうか？
Nicole Forsgren: 一部は状況次第ですが、いくつかの比較的耐久性のある指針原則がありますよね？まず着手点については、常に多くの開発者に話を聞くことです。たとえ指標やデータ、数値を持つある程度成熟したプログラムに参入する場合でも、数人の開発者と話すことで最低限の文脈が得られます。そして多くの場合、計測機能が備わっていないために見過ごしていたであろう追加的な洞察や要素を表面化させることができますよね？したがって、これは非常に役立ちます。
また、まずはQuick Win（短期間で達成できる成果）から始めるべきでしょう。そこには手頃な果実（低垂れ枝の果物）が転がっていることが多いのです。問題に対する理解を検証するために何ができるでしょうか？アプローチの一つを試して勢いをつけ、チーム内で共通の勝利を築くことです。歴史的に、社内インフラに関する作業は必ずしも称賛されるものではありません。それを評価する企業文化も存在し、私はそのような環境を愛しています。しかし、すべての人がそれに慣れているわけではありません。なぜなら、それは顧客に直接届くものではないからです。したがって、チーム内でその勢いを築きつつ、他の場所でもこれらの成果を紹介し、目を細めて見ても何が開かれたのか、あるいは年末までに以前は不可能だと思っていたことを達成するためにどのように役立つかを示すことができれば、それは素晴らしいことです。では、人々と話し合い、Quick Winを手にした後、次は何が来るのでしょうか？
それは組織内のどこにいるかによって大きく異なると思います。私は先ほどこれに言及しました。もしあなたが自分自身でこの取り組みを行い、草の根運動として行うのであれば、間違いなく自分のコントロール範囲内で始めるべきです。誰と話すことができますか？チームと連携できますか？ハックウィークを開催できますか？単に少し面倒なだけでなく、それが複数の開発者にどのように影響するかを明確に見通せるような「ペーパーカット（小さな不便さ）」を取り除くことはできますか？それがどのように摩擦や混乱、そして遅延を生み出しているのかを理解することはできますか？
もし CEO からこれを改善するために雇われたのであれば、あなたのスコープは少し異なるものになるかもしれませんね。ステークホルダーも少し異なります。チームと連携してパイロットを実施することは依然として非常に可能性が高いですが、これは同時に、内部のビルドおよびリリースシステムが IC（Individual Contributor）として完全に破綻している場合、それが最善の出発点ではないという機会でもありますよね？エグゼクティブであっても、やはり最善の出発点ではありませんが、組織全体にわたるスコープとコントロールを持っているため、プロジェクトの初期段階で非常に現実的な候補となり得ます。
DevEx の拡大：チーム、部門、および組織レベルのパターン [30:08]
Thomas Betts: はい、これもまた状況によります。私は、1 人の開発者が 1 日かけて行うものから、ハック・ザ・スデ（Hack Thursday）として木曜日を休みにし、技術の木曜日として独自の小プロジェクトに取り組むケースから、チーム全体が「1 日または 1 週間を割いて取り組む」というケース、さらには「1 週間を専用に充てる。ChatGPT を全社員に配布し、エンタープライズライセンスを取得して学習する時間を設ける」と宣言した企業全体に至るまで、あらゆる事例を見てきました。プログラミング部門からマーケティング部門に至るまで、各部署がそれぞれのやり方でこれらのツールを活用する方法に取り組んでいました。これは、「小規模なグループでこれが機能することが分かったなら、それをやや大規模なグループに広げられるか？会社全体に展開できるか？そのような普及があるのか？」という問いに関わる事柄です。しかし、これもまた、誰がどのようなことを目指しているかによって結果は異なる可能性があります。
Nicole Forsgren: チームや企業文化についてもですね。これも「場合による」という難しい質問ですが、この分野の多くの人々、エンジニアやプロダクトマネージャーは非常に賢明です。組織の脈拍を測り、何がフィットすると思うかを判断するのは私たちが得意とするところです。だからこそ、時々振り返って、本書でもそうしていますが、「これらはいくつかの実践可能なこと」をお伝えしています。あなたの会社の中で最も共感を得られるものを選んでください。文化と完全に相反するようなものではなく、良いフィット感があるものを見つけてください。それが勢いを築く手助けにもなるからです。
Quick RICE を用いた改善の優先順位付け [31:23]
Thomas Betts: あなただけでなく、私も略語がお好きですね。本書から学んだ「RICE」や、改善の優先順位付けのためのクイック RICE テクニックについて、もう少し詳しくお話しいただけますか？
Nicole Forsgren: もちろんです。RICE は優先順位付けを考えるための手法です。プロダクトマネージャーは製品開発において常にこれを用いています。実際に RICE を適用する際は、以下の要素を検討します：Reach（到達範囲）：総獲得可能市場規模はいくらか？つまり、この特定のプロジェクトや摩擦ポイントによって影響を受ける社内の開発者数はどれくらいか？Impact（インパクト）：その影響の大きさはどの程度と予想されるか？秒単位、分単位、それとも週単位か？Confidence（信頼度）：解決しようとしている課題、あるいは排除しようとしている問題を達成できるという確信度はどれほどか？そして Effort（労力）：これにはどれほどの困難が伴うのか？また、どの程度の期間が必要となるか？
さて、従来の RICE では、人々が数値を使用していることがわかります。これは本書の後半でも概説した通りです。つまり、数値を算出し、計算を行うのです。RIC を E で割ることを目指します。なぜなら、最小限の労力で最大の成果を得たいからです。ただし、Quick RICE は、プロジェクトを開始する段階では少なくとも役立ちます。私たちはすぐに成果を出せるものを探しており、直感で判断することもできます。それは高、中、低のどれでしょうか？多くの場合、候補となるプロジェクトが三つ、四つ、あるいは五つあるはずです。誰かが「これは知っているから直す」と言うでしょう。素晴らしいですね。その候補をリストに追加してください。インタビューを行い、データを分析すると、おそらく数件の候補が残るでしょう。
Quick RICE はこれに役立ちます。「この項目は高で、あの項目は…」と簡単に言えるからです。RIC が高くて E が低い場合、これは開始の候補として非常に適していると言えます。一方、到達範囲が低く、インパクトが低く、自信も低く、かつ努力が必要度が極めて高い場合は、文脈によっては別ですが、通常は最良のスタート地点とは言えません。もしかすると、研究機関に所属しているのかもしれませんね。あるいは R&D を行っており、人々が不可能だと考えることを実現するために、1 ヶ月や 1 クォーターといった時間枠を設けて取り組む必要がある場合もあるでしょう。
トーマス・ベッツ: はい。Quick RICE は直感によるチェックですが、私はここで単純な数学のアルゴリズムに到達したことを思い出しました。ただし、数値を自分で算出する必要があります。それは、「よし、すべての項目にもっと重み付けをする必要があるな」と思わせました。5 分で終わる話ではありません。これには数日かけるつもりです。
ニコル・フォアグレン: その通り、まさにそうです。これも文脈に大きく依存します。組織によっては数値が必要で、計算過程や数学的な根拠を見たいというところもあります。しかし一方で、「私が評価したいのはこれらの要素だ」と述べるだけで済む場合もあります。そして後ほど、より詳細な RICE（Reach, Impact, Confidence, Effort）分析を行う際には、考慮すべき追加の要素をいくつか含めることがあります。例えば、それが組織目標とどのように整合しているかです？また、リーチやインパクトだけでなく、DevEx の概念の中で他にどのような要素を検討すべきでしょうか？これらは、モメンタム（勢い）を得る能力にも言及するからです。
それは継続的で十分な資金が投入されている取り組みに密接に関連していますか？それを把握しておくのは良いことです。なぜなら、それが境界線上にある場合、その判断を後押しする要因になる可能性があるからです。
LLM をコミュニケーション、正当化、および盲点の発見に活用する [34:09]
トーマス・ベッツ: 各種ステークホルダーへの説明やコミュニケーション文書の作成、あるいは適切な質問を投げかけるために、LLM（大規模言語モデル）を活用した経験はありますか？
ニコル・フォアグレン: はいといいえです。私は、まずしっかりとした箇条書きリスト、少なくとも下書きから始めるのが最善だと気づいています。その後、それを自分の声に合うように調整し、見落としている点や、言葉は使っているが意図とは全く異なる部分を補うよう努めています。そして、いくつかの作業を行うことが非常に役立つことも発見しました。つまり、自分が気に入ったメッセージを確立したら、それをもとに草案を作成できるようになり、さらに質問を投げかけることができます。「何を考慮し忘れたのか？」「どこに穴があるのか？」「どのような批判に備えるべきか？」「私の支持者となりそうな人は誰で、反対者となりそうな人は誰か？」
そして、それをコミュニケーション戦略の構築にも活用できます。私たちは歴史的にコミュニケーションが苦手ですが、これを製品として扱う必要があります。『フィールド・オブ・ドリームス』のように「作ればみんな来る」という考えは通用しません。また、無理やり使わせることもできません。開発者は強制されたものは使いません。CI/CD ツールでも同じことが起こりました。誰もが自分たちの Jenkins を立ち上げてしまったのです。そこで私はこう言います。「この内容をエグゼクティブ層向けにどう枠組み立てればよいか？彼らの主要な課題はこれです。彼らが関心を持つのはこれです。エンジニアリングディレクター層向けにはどう枠組み直せばよいでしょうか？個人貢献者（IC）向けには、彼らが何を重視するかを踏まえて再構成してください」
したがって、これは異なる聴衆にどのように伝えるかを考える際に役立ちます。私は過去にもこの手法を行ってきました。ツールとして愛用しているのは、多くの場合、私の考えと合致するからです。しかし、たまに私が気づかなかった何かを拾い上げたり、新しいアイデアを提案したりすることもあります。その点で、非常にスピードアップできます。
トーマス・ベッツ: はい、LLM（大規模言語モデル）が私の盲点を特定してくれるときは特に役立ちます。そして、それを記録し続けることで追跡可能にし、「ああ、確かに X についてや誰かの視点について考えるのを忘れがちだ」と言われると、本当に「これも話す必要があることを忘れないでね」と教えてくれるのが素晴らしいです。
ニコル・フォアグレン: はい、ここで一つ付け加えるなら、数回反復するうちに、少し混乱し始める傾向があります。たとえ「いや、戻って」「いいえ、それは私が求めたことではない」と指示しても、あるいは順調に進んでいる場合でも、基本的にはキャッシュをクリアして、そのチャットを終了し、新しいチャットを開始するのが非常に役立つことがあります。現在、多くの世代が文脈の一部を追跡していますが、もし文脈をリセットしたいのであれば、新鮮な視点を得ることができます。
即座に DevEx（開発者体験）への影響を与えるための実践的な出発点 [36:31]
トーマス・ベッツ: はい、その忘却の力を借りてリセットして始めるのは素晴らしいですね。では、即座にインパクトを与えたいリスナーの方のために、個人貢献者（IC）でもチームリーダーでも組織内の上位リーダーでも、すぐに始められる小さな変化として、複合的な開発者体験（DevEx）の改善につながるものをお勧めしますか？
ニコル・フォアグレン: もちろんです。ほぼ誰でもできる最善の方法は、開発者に直接声をかけることです。同僚でもよいですし、優先度の高いチームのメンバーに「仕事はどうですか？」と聞いてみてください。あるいは、もう少し焦点を絞った質問も効果的です。「あなたの仕事の最も難しい部分はどこですか？」「いつもイライラして怒っているのはどんなことですか？」「あなたにとって多くの作業を可能にする鍵となるものは何ですか？」。これだけで、現状についてのイメージが得られ、さらに他の 2〜3 人に同じように聞いて、共通点がないか確認できます。また、これまでに行われた作業や既存のドキュメントがあるかも確認してみましょう。大規模言語モデル（LLM）もこの目的に非常に役立ちます。
大量の情報を入力させて要約させることで、過去に何が行われ、何が試され、何が成功し、何が失敗したかを浮き彫りにできます。また、「これまでそう言われてきたが、一度も成功したことがない」という暗黙の前提がある場合もあります。「だからやめよう、うまくいかないだろう」となるかもしれませんが、実はそれが真の問題であり、人々が過去の成果に固定観念を持っているため、別の表現方法で捉え直す必要があるのかもしれません。
DevEx の未来：進化し続ける開発者の役割 [37:47]
トーマス・ベッツ: さて、これはあなたが何冊も著書を書かれているほど熱心に語られるテーマですが、DevEx の未来について何があなたを興奮させるのでしょうか？今後数年間でこの分野がどのように進化していくとお考えですか？
ニコル・フォアグレン: ああ、ここには素晴らしいことがたくさんあります。正直に言って、私が最も興奮するのは、エンジニアや開発者の役割が進化している姿を見ることです。私たちは長年にわたりその変化を目にしてきました。アセンブリ言語を記述していた初期の時代にはメインフレームがあり、その後クラウドが登場しました。多くの波が押し寄せましたが、新しい技術が登場するたびに、歴史的に行ってきた作業の多くが自動化されるようになります。しかし、それがもたらしたのは、私たちが解決できる新たな問題や、取り組むことができる新たな創造的なアプローチについて考えるための扉を開いたことです。そこで、この変化が再び起こるのを観察することに興奮を覚えていますし、私の職業人生の中で少なくとも数回のそのような転換点を目にすることができたのは、とても幸運だったと感じています。
トーマス・ベッツ: はい、その枠組みは素晴らしいと思います。アセンブリ言語を書いたりパンチカードを使ったりしないことを嬉しく思いますが、私が高レベルで作業できる基盤を築いてくれた人々には感謝しています。つまり、私はあなたのビジネス課題を解決しているのですから。
Nicole Forsgren: 私の最初の仕事はメインフレームでした。その仕事をとても愛していました。その一部も特に好きでした。私が携わっていた言語の一つでは、テキストレイアウトがまだパンチカードに収まるように非常に制限されていました。なぜなら、それが始まりだったからです。そのため、時々あの頃の作業を懐かしんで冗談めかして言うこともありますが、楽しかったし、グリーンスクリーンはいつも最高でした。私たちが成し遂げてきた進歩と、これから向かう先について本当に興奮しています。
Closing [39:20]
Thomas Betts: はい。では、これで締めくくりましょう。あなたの新書『Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era』ですね。共著者はアビ・ノダさんですか？
Nicole Forsgren: はい。私のウェブサイトと彼のウェブサイトの両方に、書籍または書籍サイトへのリンクがあります。そこには約 100 ページのワークブックがリンクされており、それらは無料です。これらは書籍に付随するものです。私たちは、できるだけ多くの人にツールを提供しようと思いました。もし今すぐ書籍を購入できない場合や、購入したくない場合は、ぜひワークブックを試し始めてください。すでにそこに十分な文脈があるため、そこから多くのことを実現できます。
Thomas Betts: 素晴らしいですね。では、ニコールさん、今日お越しいただき改めてありがとうございます。非常に素晴らしい議論でした。
Nicole Forsgren: すばらしいです。本当にありがとうございました。お会いできて嬉しいです。
Thomas Betts: そしてリスナーの皆さん、またすぐに InfoQ ポッドキャストの別のエピソードでお会いできることを願っています。
About the Author
ニコール・フォアスゲン
ドクター、ニコール・フォアスゲンは Google Cloud で研究と戦略に従事しています。彼女は「Shingo Publication Award」を受賞した書籍『Accelerate: The Science of Lean Software and DevOps』の共著者であり、これまでに実施された最も大規模な DevOps 調査の主要研究者として知られています。彼女は Google への売却を含む成功した起業家、教授、パフォーマンスエンジニア、そしてシステム管理者としても活躍してきました。彼女の業績は複数の査読付き学術誌に掲載されています。
さらに表示する表示を消す
ポッドキャストの最新情報は、当社の RSS フィード を通じてご確認いただけます。また、以下のプラットフォームでもご利用可能です。
そして YouTube。
このページからは、録音されたショーノートにもアクセスできます。すべてにクリック可能なリンクが含まれており、そこからオーディオの該当部分へ直接移動することができます。
原文を表示
Watch the video:
Transcript
Thomas Betts: Hello and welcome to the InfoQ podcast. I'm Thomas Betts. And today, I have the privilege of speaking with one of the most prominent and important minds in DevOps and developer productivity, Dr. Nicole Forsgren. She has led productivity efforts at companies like Microsoft, GitHub, and Google is the author of two bestselling books, Accelerate in the second edition of the DevOps Handbook. Her newest book, Frictionless, talks about identifying and removing developer friction. Now, back in November, she spoke about that subject during a keynote at QCon San Francisco, and so that's what we're going to be discussing today. Nicole, welcome to the InfoQ podcast.
Nicole Forsgren: Thanks so much for having me.
Why Friction is a Useful Lens for DevEx [01:07]
Thomas Betts: Now at QCon, one of the things I remember you talked about was this emphasis that developer productivity is about more than just faster builds or better tooling. We need to look at those friction points that constantly are slowing us down. Can you explain why talking about friction is a useful way to frame the conversation about DevEx and maybe give us some examples of what you mean by friction?
Nicole Forsgren: Yes, absolutely. So, I think friction can really help us think about how to improve and look for the best areas we can improve development, right? Traditionally, you could look at processes that were very manual or required a lot of process because many times, those are very fragile and they're going to break. The same holds true right now with AI, right? It can surface in different ways, right?
Some things just show up like magic, all of the code generation completion that we're seeing right now. But that can also end up creating additional friction points in buildup, whether that's through launch processes or code review or things that used to be manual around release and deploy, which is common in many companies. Now we have this massive backlog, right? And so, things that are friction are often good indications of where things are brittle and possibly about to break as we start to increase load and speed.
Who Should Care About DevEx? [02:16]
Thomas Betts: When you talk about things that are brittle and about to break, that's not just on the developer's machine or that one service, it can be like a company-wide problem. How does it affect everything? Who needs to care about DevEx? I think there's one of those the hardest problems in software is naming things and developer experience sounds like, "Oh, it's just what that coder has to deal with", but it's a bigger problem, so how do we make the other people see this problem and how does it affect us as a company more broadly?
Nicole Forsgren: That's a really good point, and I think DevEx can be a little challenging there, right? It can be development friction, it can be value delivery, but the reason where people should care is as we keep telling executives or as they keep reading as leadership is reading all of these bombastic headlines saying that we can spin up entire new products and features in an hour and deploy them out. That's exciting.
Not entirely real, but where that's the case, I think that's where it can be really insightful and informative to leadership is if we want to get on this fast path, if we want to be able to leverage AI to do all of these incredible things, we need to look at some of our systems and processes because right now a lot of that is centered around developers or that development pipeline, that development experience, but like you point out, it's not always developers. It could be a security and compliance review where historically, there was a big back and forth, maybe there's a little bit of security theater where you said no and you negotiated for a few weeks.
That's really, really tough now and now overwhelming, already understaffed many times security and compliance teams or what does release and launch look like, right? I know many large companies right now that manually select a candidate build and then run it through test and run it through canary. And anytime you have a bunch of manual work and handoffs and unique decision points, the more you increase load and friction, the more something like that can break. Like you said, it's not just a build. It could be an approval process that is brittle and breaks and then the business cares because we're seeing things change so rapidly.
I mean, some of the latest models this morning are doing things that they couldn't do three months ago, two months ago, and so if we're trying to keep up with the pace of competition and the pace of the industry, even if it's just accelerating some of our feature development, any additional friction highlights things that are slowing us down from our work, but also these kind of potential fragile breakpoints.
Exposing Friction Through Faster Feedback [04:42]
Thomas Betts: Yes, I think it goes to the idea of things that move at the speed of humans versus the speed of computers, and we've had a lot of processes developed over the years that work fine at the speed of humans. It takes a few days to go through the email process and that's fine, and I can concentrate on other faster things over here while I'm waiting for that to go in the background. As AI and other automation is permeating everything, it's not just I can write code faster, but I can create user stories faster.
All of that gets compressed and now the whole process starts working at the speed of computers, if you will, and that's where that friction, you rub against it faster and faster and faster and that starts a fire.
Nicole Forsgren: Exactly, and especially now that we're seeing so much interesting and exciting development in agentic workflows, right? It's sort of like builds used to be slow, so we sped up the builds and then we parallelize the builds so that they could kind of be running concurrently. We're seeing the same thing, right? It's no longer one person and an agent or one person and a couple of agents. It can be a developer orchestrating a bunch of agents that are then kind of orchestrating their own work and solving their own problems, and so any friction point really is amplified.
Metrics for DevEx [05:52]
Thomas Betts: Yes. How do we start measuring this stuff? What are some of the metrics that we've had in the past and do they still work with all this changing to go to an age of AI where there's just more automation? Do we have the same metrics, or do they change?
Nicole Forsgren: This is the big question, right? I think some of the metrics will remain the same. Some of the metrics will definitely change, right? Lines of code is a good example of a metric that was never good.
Thomas Betts: And it was awful.
Nicole Forsgren: But it was always brought up. Now, we're in a space where on the one hand lines of code is a complete nonsense metric, right? Because with a reasonable prompt, I can generate hundreds of lines of code. On the other hand, it might be useful, but only in very certain contexts such as what does our code base look like and how is that evolving over time and what does that mean for current and future model tuning and model training, right?
Because if we're tuning models on historical code bases that we're architected and designed and coded a certain way or we have assumptions about that, what does that mean when maybe soon, much bigger proportion than zero, at least a percent of our code bases was machine written, right? What's that mean for feeding that loop? And for a bunch of folks in ML and AI, we know that the data that you put in is just amplified, and so something that we might not catch in our initial data and training and inference set can turn into something kind of unexpected. So, that's one example of a metric, and I think there's no one metric that matters, right?
A lot of the frameworks that we have from before are still quite relevant today. So, if we look at DORA, DORA focused on the pipeline. It was speed lead time, how long it takes to get through. It was deployment frequency. It's kind of the volume for set period of time. We're looking at change fail rate, which is a quality metric. MTTR, which is recovery now. So, back in the day when I started a bunch of that work, that was one of the best things we could do is really instrument and engineer the pipeline, the software development pipeline.
We could reduce variability, increase predictability, but many of these frameworks still apply across all of our product development work, our software delivery and feature work because we can go back up into ideation, we can go into implementation and coding, we can go into production and speed matters and throughput matters and quality matters, and that can help us evaluate our process.
If we're looking at developers or developer productivity, SPACE is a good framework here as well, right? We can look at satisfaction. Is the developer satisfied with the tools that they have and the pipelines that they have? Performance, that's our quality outcomes again, right?What's the outcome of a process? A is activity. What are all of our counts, lines of code? It’s not great. Number of commits, number of PRs, number of reviews at a time period, right? Communication and collaboration. Where are people getting most of their information from, or how can our systems communicate? Are APIs holding up fairly well? And then efficiency in full, how long does it take?
I think there's probably an opportunity to extend a couple of these. One is some of this may be true for agents as well, right? How easy is it to use for an agent? What's an agent's satisfaction? We might not ask them, although we might, but that might surface through different types of friction, right?
We may also want to add a couple dimensions. Trust comes to mind here, right? Trust is…it's always been important. I know in the sysadmin community, we have always centered on trust, right? Sysadmins and SREs. Now developers are thinking about it more, because they used to be working in fairly deterministic systems. And then cost, which cost has always been a thing, but now we're having to make real explicit trade-offs between what's our compute cost? What's our capacity? Do we want to deploy a thousand agents to do a hundred things to replace a person if then all of our systems fall down?
There are a lot of metrics that I guess this is a long version of, I don't have an answer for a specific metric because it will really depend on your environment and your context and what data you have available, but also what questions you're trying to answer.
DevEx and Systems Thinking [09:46]
Thomas Betts: Yes, I think what you're getting to is we're trying to measure productivity. Again, we go back to, we call it developer experience, and if we have better developer experience, and I think your keynote was called from friction to flow, how great DevEx makes everything awesome. It's like, okay, we have this, but with the developer and the developer experience in the name, you keep thinking that's the thing we're trying to improve, and it's always been about the bigger picture. It's always been about software delivery, and that's what we're trying to do.
Nicole Forsgren: And I think that's a good point, right? The systems view gives us better insight into what's happening. Even if when we start, we might focus on developers because that's where we can get some early signal, but it's always about a system. A developer is always working within a system, whether that's a manual system, a purely manual system, a system built on mainframes, a system that's highly automated in the cloud or now a system that uses possibly a bunch of AI agents and AI tooling.
Thomas Betts: Yes. Well, going into your example of lines of code being a horrible metric, it was sometimes used as that stand in proxy for productivity. Like, "Oh, he's able to write a hundred lines of code a day versus 10 lines of code". I'd rather have 10 perfect lines of code that we actually use versus a hundred lines of crap.
Nicole Forsgren: Right. And sometimes, the right thing to do is to delete code, right? How do you measure that?
AI Agents, Code Quality, and Developer workflows [11:08]
Thomas Betts: But if you're looking at the goal of the system got delivered and the system remained stable and didn't have downtime and we're able to make changes, lots of little changes very quickly, being able to measure that comes back to, well, it's still called developer experience, but it's all of these other factors, and I want to poke on your idea that I think you just kind of sussed out was asking the agent about their developer experience. The agent, if you have a coding agent, you ask them how do you think it's going or are you asking them to help me summarize my metrics and help me summarize DORA or whatever else?
Nicole Forsgren: Well, I will say right now, I'm not asking agents, but there might be a world where we do that quickly, right? By the time this gets released, we may be in that world, but I do think there's an opportunity to ask whether in words or take a look at some of the data points that speak to how agents are developing and delivering code to look for the things we look for when we talk to people like, right? What's really difficult with what you do? What do you swear at all the time, right? Do we see a particular process or something that agents keep having to retry several times, right? Do we see friction showing up somewhere or we can ask them, right? We can find out what the outcomes are, right?
We can see the downstream impacts of their work, or what they're able to deliver. And so, I think there's an opportunity to maybe interrogate the context of agents and AI in which they work, which will speak to both how well the agents can do things and how well we're equipping them in our systems and also let us ask and think about better ways to equip and enable devs to answer these hard, creative, challenging problems that computers aren't ready for yet.
Thomas Betts: Yes. And I think that gets back to, I wanted to ask about just how workflows are evolving. I think we tend to focus on the AI coding agent. That's the easiest thing. I've got GitHub Copilot, there’s Claude Code. Like, this writes code for me and it moved from write this function to I ask the agent to do the work and it thinks about it and then solves it. That agent model is moving throughout the software development life cycle. We've got product management agents that sit next to the PM to help do that. The scrum masters or other people that are helping to manage the backlog or write the stories or break things down, they're showing up in all these different ways because it is fundamentally just talking about language.
Large language models are good with coming up with the language. I think it was the C in space you talked about, it was communication and collaboration. That's what I want to ask about is how do we take what we've been trying to do with getting humans to communicate better, and does that naturally just move to if there's an agent in the loop, if you have a good communication pattern that's going to help you use these agent tools.
Communication, Documentation, and Conway’s Law in the AI Era [14:02]
Nicole Forsgren: I suspect it will. And here's one example you touched on, which is breaking down work, providing very well, clearly-structured requirements to engineers for engineers to implement. And we know there are differences between very clear requirements and clearly design docs. And then there's much more ambiguous docs on what level of an engineer can handle that and what level of engineer we would hand that to also, or just the challenge of having a lack of clarity in docs.
Well now if we have very, very clear design docs and feature docs and feature specifications, that communication just like it was higher fidelity with a person is now also higher fidelity with an agent because like you said, it comes down to language, right? So, the better we can communicate and specify, and that's one example. It can also be having more clearly defined and documented APIs. So, when an agent needs to use it, or internal libraries that aren't really externally documented, a very kind of one-off thing inside of a company. Sure, a lot of devs were probably kind of fine with it if they used it several times, if they knew its edge cases, if they knew where the dragons were.
But now you've got a junior level dev who can kind of do senior level things, but needs a lot of guidance, and so this can also speak to APIs and how our systems communicate.
Benefits and Risks of AI as First-Line Support [15:23]
Thomas Betts: Yes. Yes, I think if you had good system boundaries, how do the systems talk to each other are the same ways the teams talk to each other the same way that the organization is structured is the way your software is structured. Conway's law comes into this, I don't think anyone's written the AI corollary to Conway's law yet, but it still applies if you break up and have a bunch of agents helping your teams, and that's how you're structuring your organization. It's like, "Oh, we have these people and they each have this agent that sits down and helps their role". That's going to show up in your architecture, I think.
Nicole Forsgren: Yes. And for a couple of years now, we've been talking about how on the communication side, how AI is impacting communication within and among teams and how we want to think about that and what is good and what is not so good. There are a lot of cases where we see that a junior dev would historically go to the senior on the team and ask lots and lots of questions, especially when they're onboarding or when they're learning a new code base or picking up a new project, and that's great, right? I think one of the best things a senior engineer can do is unblock people on the team. That's also a challenge.
I've had senior engineers on my team that that's all they can do and they feel a sense of pride in it, but they're doing so much unblocking, they don't get to do much of their own technical work, and it's like that's kind of tough because very proud of one thing and a little sad that they can't do another. Well, now we're seeing that a lot of engineers are going to AI first, they're asking questions, and this can be good because it can free up some of our time, but it can also end up leading you down weird trails and rabbit holes and turtles all the way down and you end up in a weird spot where you never thought you'd be, right.
And so, we can also think about are there good checkpoints for asking an agent or having a conversation with an AI chatbot for long enough who knows your code base, and then when do you pop up and confirm and verify your plan and your findings with someone on your team who really knows the code base?
Thomas Betts: And I think that that new person on the team, new person at a company, it depends where you're starting off. If you're starting off at a startup and there's no code, right? You've got to build everything from scratch. There's no examples to lean on. If there are examples to lean on, you're like, "Oh, well, here's what you can do. You can ask the agent, well, help me explain the code that I'm reading". But if you also have legacy code and you know this isn't how you want to do stuff and you want to move to something better, but there isn't that next example of here's what better looks like, you might get the feedback like, well, this is how it's always done. Just keep doing that.
Nicole Forsgren: This matches our pattern.
Thomas Betts: Yes. Whereas the senior is going to say, that's how we did it. We want to stop that. We want to do something new, and that might not be captured yet in any kind of documentation that the agent's going to pick up or the new dev's going to pick up. So, you still need those people involved.
Documentation, RAG Models, and Sustainable Practices [18:06]
Nicole Forsgren: You do, you do. I think it also kind of spins back a little bit to we need to work in ways that are appropriate to our context, right? It's very different to being a tiny sprinty startup and a larger company. There are also things that will for, I'll say universally, I may take this back in 10 years, universally remain true, like good docs, right? You can be at a sprinty startup, but without a README or basic docs, that is only sustainable for a certain amount of time. At some point, that is going to break, right? You'll get enough time from when the code base was started. You'll need those docs.
And so, AI right now, there's a lot of really interesting and promising AI tools that can take a look at your code and at least help document your code. That'll remain true moving forward because as we are prompting or asking for feedback or asking for agents to do work for us, they will reference the code that we have. They'll reference the documentation that we have. If we're building a RAG model, what do we want to be clarifying for them so that when they do work, it's more clear either for a human or for an agent.
Building Stakeholder Buy-In for DevEx [19:11]
Thomas Betts: I wanted to take us in a little bit of a different direction. This is some of the stuff you talked about in your keynote and it was also in Frictionless the book, that how do you get this to be something the whole company is going to buy into, right? Taking it from the idea of I want to remove this friction to getting the buy-in to say, we should focus on this, we should invest in this. We have to make it better because these are the things. How has that stakeholder buy-in changed, if at all? Or maybe you just start with how does it start without the AI? How do you go from, I have some metrics or I can start capturing metrics to, I can tell a story that my CEO and CTO are going to believe?
Nicole Forsgren: There are a few things that are going to remain fairly true, which is we want to align with the priorities of our business and of our company and our organization. We want to align with and understand the problems that they have so we can solve those problems. And so, a lot of the time, it's about contextualizing the data that we have and the things that we propose to solve those problems or to align to something that we know is definitely top of mind. Now, that strategy might look a little different depending on where you are in the org and where your org is.
So, if you're in an org that this is not on the radar, they don't care, there are other fires to put out and you're an IC or you're a manager, kind of a first line manager, then there are certain things that you can do locally to kind of have an impact and that you could start thinking about bubbling that up. At the other side of the spectrum, there's also the case where the CTO or the VP of infrastructure has declared developing, delivering software faster and with greater quality and more reliability and stability is top of mind.
And then you're hired to lead that effort, whether it's a DevEx improvement or a measurement improvement, that is a little different in some ways in that your audience will be slightly different. Likesome of your rollout strategies may be a little different. You'll still partner with teams, but you can think about what teams you want to be with your work. You'll still be communicating out. Your stakeholders might change a little bit as a first line manager, as an IC, I'm probably not going to have one of my first readouts be to the CTO.
But in both cases, we want to align with the business priorities, the business needs, the problems that we can solve because then it resonates and people, they're in a meeting and they're nodding their head saying, okay, I see this. I understand why this aligns the way that I need it to.
Using DevEx to Improve Product Quality [21:40]
Thomas Betts: And just to give an example, what have you had companies saying, oh, our customers are reporting a lot of bugs. There've been, a lot of releases have gone out and issues have been detected by our customers, and that's affecting our quality scores. We want to focus on that. It becomes that top level thing. And if you can say, "Well, I think one of the ways we can do this instead of like, well, just don't write bugs, we should look at DevEx and how do we improve that", you can tie that back to, well, how often do we release? Do we have daily builds? Going to things that are in Accelerate and the DORA metrics. If you do it faster, you get better at it.
If you say, "Oh, we break stuff; we shouldn't release for six months", it's just fundamentally not true. Right?
Nicole Forsgren: Right. Well, and that's a good point. So, if you're in a situation where your products and your features, they're not very reliable or they have a lot of bugs, your customer engagement and your customer feedback is quite low, right? That is something where you could go to leadership wherever it is you are to that appropriate level of stakeholder and say, I understand that this is a big problem for us. I understand that there are some things being worked on. This is a high priority. We're trying to figure out how to address this problem.
One of those ways we can do that is to look at the developer experience, in which case they're like, “What?” We can say yes, because I can roughly look at, I understand traditionally what our software development lifecycle looks like, and I can identify some of the key areas where these should have been caught. Let me go take a look, because my hunch is that some of these, and you'll probably find this right, are very manual processes or they're very, very old test suites and flaky tests that have not been cleaned up because it hasn't been a priority. And so, many times for an executive, linking those things as a priority isn't obvious, right?
For those of us working in systems, we can see how a handful of processes or gates are directly linked to that, but if you're not swimming in software all the time, it's not very obvious, and so just kind of couching it in that way can be super helpful.
Security, Compliance, and Risk-Informed Approaches [23:40]
Thomas Betts: Yes, I think that goes to the idea that these are friction points, right? We're not saying get rid of security and reviews and safety and all that stuff. Just figure out how to make them not block. And sometimes, recognizing that by adding that extra step that's a security review, you might also be causing this other backlog to come up. And so...
Nicole Forsgren: Right, exactly.
Thomas Betts: Oh, well, we're going to wait and only test every two weeks because we have to do a manual test. All of a sudden, a lot more stuff gets in there and you aren't able to test every little change versus I changed two lines of code. Check that, I didn't break that.
Nicole Forsgren: Yes, exactly. Exactly. And in terms of security and compliance review, we can also take, and we've seen this for years, what old is new, again. We could take a risk informed approach where for things that qualify as kind of low risk changes, those can go through an attestation model, they can follow regular, the prescribed testing model, and that can be very lightweight and it's auditable. It'll be tracked, it'll be followed, but that should be, and surprisingly in many large companies it's not and small companies that should be very different from a high risk change that we need to make. That really requires eyes on it. It requires a discussion. It requires a lot of people involved.
But if you treat everything the same way, then either your high risk changes are zipping through a process that wasn't designed for them, or your low risk changes that are probably fine with some automation are now getting eyeballs and discussions and hours of meetings that aren't appropriate, and at some point, people are going to glaze over, so we will make lower quality decisions for those high risk releases.
Thomas Betts: Yes, yes. Again, the answer is always, it depends, right? You need context-specific responses. Some way to trip and say, "Hey, this is a high risk. Go through the extra process, or this hasn't met the threshold. This is an easy, rubber stamp it goes through.
Nicole Forsgren: Yes, exactly.
Qualitative vs. Quantitative DevEx Data [25:27]
Thomas Betts: So, I think there's still something to be said of how do you go in and say, we've captured the data, we've done surveys. I think your book talked about qualitative and quantitative measurements. You can get metrics out of the system sometimes, but they might not be useful. It might just be the things you can get. Lines of code, you can get lines of code. Does it tell you anything? Or you can get, how often do we release software because we've got those things hopefully are instrumented. And the surveys were to gather more of the qualitative feedback. If you ask developers what sucks, they will tell you what sucks.
Nicole Forsgren: They will tell you what sucks. And I think right now, especially as AI is changing so many things and it's inviting so many people to rethink and reinvent what the SDLC looks like, right? In some cases, a couple years ago I said, there will be a world where we might collapse the outer loop, right? I don't think we're quite there yet, but we are probably getting close. In a world where we're going straight from prototype to prod, it's really hard to step back and say, "Well, I'm going to only trust system data because that's what is reliable when for the most part, we're creating our new tools and systems so quickly that we're not instrumenting them", right?
That is usually not highest on a new developer and internal product or even external product builder’s list is instrumentation, telemetry, and observability. The other thing is it's changing so rapidly that by the time you build the instrumentation and get it into the data warehouse or the data lake or the data fabric and do all the calculations, it could be weeks. And when things are changing that rapidly, it can be very powerful and at least better than nothing to ask a handful of developers or observe a handful of developers, what is your development workflow like now? What are the biggest blockers that you have right now? And sometimes it'll be a process, sometimes it'll be a system.
Sometimes, it'll just be a mental model. They're not used to thinking about things totally differently, but system data can't surface that, right? It can't tell us the why. So, sometimes we can skip, especially when things are rapidly, rapidly changing. If we have no data, surveys and interviews and observations are going to be your friend.
Thomas Betts: Yes. And this isn't a do one thing or do all the things, it's a matter of getting prioritization, right?
Nicole Forsgren: Yes, yes. It's having a portfolio approach, right?
Where to Start: Quick Wins and Local Momentum [27:42]
Thomas Betts: Yes. How do you identify where should we get started if we're going to actually make an effort, do you tackle a big thing? Do you take a small thing? Do you focus on something that you're sure is going to work? Where do you go?
Nicole Forsgren: I would say some of this is, it depends, but there are some fairly durable guiding principles here, right? Where to start, talk to a bunch of developers always, right? Because even if you're stepping into a fairly mature program that has metrics and data and numbers, chatting with a few developers will at minimum give you context. And many times, you'll surface additional insights and additional pieces that don't have instrumentation that you would've missed, right? So, that is super helpful.
We also probably want to start with a quick win, right? There's often low-hanging fruit. What can we do to test our understanding of the problem?Test one of our approaches, build momentum, get a shared win among the team. Historically, internal infrastructure work isn't always celebrated. There are some company cultures that do, and I love it there. Not everyone else is used to that because it's not something that goes to a customer. So, if we can start building that momentum within the team, but also kind of showcasing those wins other places and showing even if we kind of squint what it unlocked or what it will likely help us achieve by the end of year that we thought was going to be impossible before, that's good. So, once I've talked to people, I've gotten that quick win, what comes next?
I think it really depends on where you are in the org. I kind of alluded to this earlier. If you're doing this yourself, and this is a grassroots effort, for sure, start within your scope of control. Who can you talk to? Can you partner with your team? Can you do a hack week? Can you clear up some paper cuts that are not just mildly annoying, but also you can see, you have a line of sight to how that impacts several developers? How does that create friction and confusion and slowness?
If you were hired in by the CEO to fix this, then your scope can look a little bit different, right? Your stakeholders are a little bit different.You'll still be partnering with teams to pilot very, very likely, but that's also an opportunity where if the whole internal build and release system is broken as an IC, that's probably not the best place to start, right? As an executive, still not the best place to start, but could be a very real candidate earlier on in the project because you have that scope and control across much more of the org.
Scaling DevEx: Team, Department, and Org-Level Patterns [30:08]
Thomas Betts: Yes, I think, again, it depends. I've seen everything from one developer taking one day for their, it's hack Thursday, we just take Thursday off and we do tech Thursday, and we do a little project on their own to a whole team saying, we're going to take a day or a week to actually an entire company that said, "We're going to dedicate a week. We gave ChatGPT to everyone. We got an enterprise license, take the time to learn it". And every department from programming to marketing was working on their own way to leverage these tools. It's one of those things, if you figure out this worked for a small group, can we make it a slightly larger group? Can we make it company-wide? Is there that type of adoption? But again, your mileage may vary based on who you are and what you're trying to do.
Nicole Forsgren: And the team and the company culture, right? So, again, it's a tough one of those, “It depends.” But, most people in the space, engineers, PMs were very smart, right? We're pretty good at taking the pulse of the org and what we think is going to fit. And so, that's why sometimes I'll reflect back and we do in the book, right? Here's a handful of things you can do. Pick the one that is going to resonate with the most within your company. Pick the one that won't be just a complete opposite of what the culture says, right? Find one that's a good fit because that will also help build that momentum.
Prioritizing Improvements with Quick RICE [31:23]
Thomas Betts: I know you like your acronyms, and one that I learned from the book was RICE or the quick RICE technique for how to prioritize improvements. Can you talk about that a little bit?
Nicole Forsgren: Yes, absolutely. So, RICE is a way to think about prioritizations. PMs use it all the time in product, and we do this when we do RICE. We'll do: Reach: What's your total addressable market? So, how many developers inside the company are impacted by this particular project or friction point? Impact: How big do we think that impact will be, right? Will it be on the order of seconds or minutes or weeks? Confidence: How confident are we that we can achieve this thing that we're trying to fix, or we're trying to remove? And effort: How hard will this be? How long will it take?
Now, in traditional RICE, what we see is people using, and we outlined this later in the book as well, numbers, right? So, come up with numbers, do a calculation. We want RIC divided by E, right? Because you want the highest payoff for the lowest amount of effort. Quick RICE though can at least be helpful when we're just getting started, we're kind of looking for a quick win and we can just hunch it. Is it high, medium, or low? Because many times we probably have three or four or five candidate projects, right? I'm sure someone will say, “I know this, will fix it.” Cool. Right? Go ahead and throw it on the list. When you have your interviews, when you look at the data, you'll probably have a couple of candidates.
Quick RICE can help with that because we can just say, "Okay, this one's high, this one's..". If you're high across RIC and low on E, that is probably a pretty good candidate for starting. If you're low on reach, low on impact, low on confidence, and super high on effort, probably not the best place to start unless again, context. Maybe you're in a research org, right? Maybe you're doing R and D and you're supposed to time box something for a month or a quarter to try to do things that people think are impossible.
Thomas Betts: Yes. Quick RICE is the gut check, but I did remember getting to the algorithm of here's the simple math, but you have to come up with numbers. And that did seem like, okay, I've got to do a lot more weighting of everything. I'm not going to finish that in five minutes. I'm going to spend a couple days on it.
Nicole Forsgren: Right, exactly. And again, very contextual. Some organizations, they need the number. They want to see the calculation, they want the math. Sometimes though, you can say, these are the things that I wanted to evaluate. And sometimes and later, when we do kind of the more detailed RICE, we include a handful of additional factors you might want to consider, which is how is it aligned with the organizational goals? What other type of a handful of DevEx concepts do we want to think of in addition to just reach and impact? Because that can also speak to the ability to get momentum, right?
Is it closely aligned with an ongoing, well-funded effort? That's good to know, right? Because if it's kind of on the borderline, that would probably nudge you over.
Using LLMs for Communication, Justification, and Blind Spots [34:09]
Thomas Betts: Have you had any good luck with using LLMs to help you write these justifications and write that communication to the various stakeholders, or help you ask the right questions?
Nicole Forsgren: Yes and no. I will say that I have found it best if I start with a pretty solid bullet point list, at least a rough draft, and then I try to nudge it to fit my voice and pick up things that it kind of missed or it said the thing and it used the word, but that's not what I meant at all, right? And then I found it really useful to do a couple things, right? So, once I have the message that I know I like, maybe it can help me draft it, then I can ask it questions. What have I not considered? What are the holes? What are the criticisms I should be ready for? Who will be my likely supporters and who will be my likely detractors?
And then I can take it and I can ask it to help me with comms, which we are historically bad at comms, but we need to treat this like a product, right? We can't Field of Dreams it. We can't just build it and everyone will come. We can't force them to use it. Developers aren't going to use anything they've been forced to do, right? We tried that with CI/CD tools and everyone just spun up their own Jenkins, right? So, then what I'll say is, "Okay, help me frame this for an executive audience. These are their key pain points. This is what they care about. Frame this for an engineering director audience. Reframe this for ICs and what they care about".
And so, then it can help me think through how I want to communicate this to different audiences. Now, I have done this historically in the past. I love this as a tool because many times, it kind of aligns with what I'm thinking. But every once in a while, it'll pick up something or it'll suggest an idea that I probably hadn't thought of. So, it helps me move a lot faster that way.
Thomas Betts: Yes, I do when the LLMs help identify my blind spots. And if I can start keeping things written down so that it keeps track of that, and then they're like, "Oh yes, I always forget to think about X or somebody's viewpoint". It's really good at saying, "Remember, you need to talk about this too". Okay.
Nicole Forsgren: Yes. I will say one thing here as well is if I go a few iterations down, it tends to go a little haywire. Even if I tell it like, "No, go back, or, no, that wasn't what I asked for". Or even if it's going well, it can be really helpful to basically clear my cache, right? Stop that chat, start a new one. And many, many of our ages right now keep track of some of our context. But if we want to wipe context, then you've got a fresh pair of eyes, right?
Practical Starting Points for Immediate DevEx Impact [36:31]
Thomas Betts: Yes, it's great to give it that amnesia and just start over. So, for listeners who want to make an immediate impact, what's one small change, whether that's for an IC or a team lead or a higher leader in the organization that you think they can start with that might lead to some compounding DevEx improvements?
Nicole Forsgren: Sure. I think the best thing that almost anyone can do is reach out to a developer. It can be a peer. It can be someone in one of the teams that's high priority and ask them what's it like? Or sometimes I like a slightly more targeted question, which is, what's the hardest part about your job? What do you swear at all the time? What's the thing that is unlocking a bunch of stuff for you? Because that can at least give you an idea of what you're saying, and then you can ask two or three others and see if there's any similarity at all. You can also reach out and see what work has been done, see if there's any existing docs. LLMs are also great for this.
You can feed them a whole bunch of information, ask them to synthesize, because that can surface both what has been done in the past or tried in the past, what worked, what didn't work. There can also be an implied, this is how it's always been talked about and it's never worked before. So, maybe we don't do that, it's not going to work. Or maybe that really is the problem, but we need to phrase it differently because people have anchored on that prior performance.
The Future of DevEx: Evolving Developer Roles [37:47]
Thomas Betts: Now, I know this is a topic that you just get really excited about having written several books on it, but what excites you about the future of DevEx? How do you see the field evolving over the next few years?
Nicole Forsgren: Oh, there's so many good things here. Honestly, I think the thing that excites me the most is to see the evolving role of engineers and developers. And we've seen it over years. The earliest years when we're writing assembly code, we saw mainframes, we saw cloud. We've seen so many waves, and I think when we come up with a new technology, it automates away a lot of the work that we've done historically. But what it's done is it's opened new doors for us to think about new problems we can solve and new creative approaches we can take. And so, I'm kind of excited to watch that shift happen again, and I feel like I'm pretty lucky to have seen at least a couple of those shifts in my professional lifetime.
Thomas Betts: Yes, I like that framing. I think I'm glad I don't write assembly code or do punch cards, but I'm grateful for the people that did that and built the foundation that I get to work on at a much higher level, like I'm solving your business problem.
Nicole Forsgren: My first job was on mainframes and I loved it. I loved pieces of it. One of the languages that I was in, the text layout was still very constrained to fit punch cards because that was how it started. And so, while sometimes I'll joke longingly about missing some of that work, it was fun, and a green screen is always great. I'm really excited at all of the progress that we've made and where we're headed.
Closing [39:20]
Thomas Betts: Yes. Well, I think that's going to wrap it up. So, your new book is called Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era. Your co-writer was Abi Noda?
Nicole Forsgren: Yes, and I will mention there's on my website and on his, there's a link to a book or the book site where we have about a hundred pages of workbooks linked, and those are free. They accompany the book. So, we tried to give everyone as many tools as possible, or if you can't afford the book right now or don't want to get it, jump in and start trying out the workbooks. There's enough context there that you can do a lot with what's already there.
Thomas Betts: Sounds great. Well, Nicole, thank you again for joining me today. It's been a fantastic discussion.
Nicole Forsgren: Awesome. Thanks so much. Good to see you.
Thomas Betts: And listeners, we hope you'll join us again soon for another episode of the InfoQ podcast.
About the Author
Nicole Forsgren
Dr. Nicole Forsgren does research and strategy at Google Cloud. She is co-author of the Shingo Publication Award winning book Accelerate: The Science of Lean Software and DevOps and is best known as lead investigator on the largest DevOps studies to date. She has been a successful entrepreneur (with an exit to Google), professor, performance engineer and sysadmin. Her work has been published in several peer-reviewed journals.
Show moreShow less
You can keep up-to-date with the podcasts via our RSS Feed, and they are available via
and YouTube.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み