『Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era』は、ソフトウェア開発における摩擦（フリクション）をテーマにした書籍です。AIによってコードは数分で書けるようになりました。それでも、多くの組織ではリリースが遅く、開発はつらいままです。本書は、その原因が目に見えにくい摩擦にあると指摘します。
ここでいう摩擦とは、壊れたツール、不安定なビルド、面倒な手作業、分断されたプロセスなど、開発者が日常的に直面する障害のことです。これらは一つひとつは小さな問題に見えますが、積み重なることで開発速度を落とし、開発者を疲弊させ、最終的にはビジネスの成長を止めてしまいます。本書が明らかにするのは、摩擦の解消が開発者の満足度向上にとどまらず、企業が競争に勝ち続けるための条件であるという点です。
著者の一人である Nicole Forsgren は、『Accelerate』の著者として知られ、DevOpsやDevEx分野で世界的に影響力のある研究者です。もう一人の著者である Abi Noda は、Developer Experienceの計測と改善を支援する企業DXの創業者であり、GitHubに買収されたPull Pandaの創業者でもあります。本書は、両者が数百のソフトウェアチームを対象に行ってきた研究と実践をもとに書かれています。
本書の特徴は、摩擦の問題を精神論や理想論で終わらせず、特定し、測定し、取り除くための7つのステップとして整理している点にあります。AIを使った開発であっても、従来型のワークフローであっても、エンジニアリング組織の潜在能力を引き出すための具体的な道筋が示されています。さまざまなテック企業が、どのように開発者の摩擦に向き合い、ビジネスを変えていったのかも、実例として紹介されています。
なぜ DevEx が重要なのか？
本書の中核にある概念が、Developer Experience（DevEx）です。DevExとは、開発者が日々の仕事の中で感じる摩擦や、作業の流れ、受けている支援の状態をまとめて捉える考え方です。本書は、このDevExを意図的に測定し、改善することで、エンジニアリング組織の潜在能力を引き出し、ビジネス成果を加速させる方法を示します。
DevExという言葉は、「開発者の満足度を上げる話」と誤解されがちです。しかし本書が一貫して主張しているのは、DevExの改善は福利厚生でも現場改善でもなく、はっきりとした経営課題だという点です。なぜなら、DevExの良し悪しは、経営層が重視するコスト、成長速度、リスクという指標に直接影響するからです。
この影響は感覚的なものではありません。たとえば、技術的負債は米国企業に年間1.52兆ドルものコストをかけており、開発者の生産性は平均して31.6パーセントも失われています。さらに、DevExの低さは、壊滅的なビジネスリスクを見えにくい形で抱え込む原因にもなります。2012年にKnight Capital社で起きた事故では、日常的なアップデートをきっかけに、わずか45分で4億6000万ドルの損失が発生しました。このとき問題だったのは単なるバグではなく、自動テストや安全なデプロイ、即時に異常を止める仕組みがない環境で開発が行われていたことです。この事例は、開発者体験の弱さが、日常的な変更を会社の存続を脅かす事故に変えることを示しています。
DevEx改善を推進するための7ステップ
本書の最大の価値は、DevExをどう進めればよいのかを、具体的な7つのステップとして示している点にあります。DevExを「大事だよね」で終わらせず、「何から始め、どう続けるのか」まで落とし込んでいる点が、この本を実践的な一冊にしています。
DevEx改善の出発点として、本書はツールや指標ではなく、開発者との対話を置きます。いわゆるリスニングツアーです。開発者がどこで止まり、どこで迷い、どこで疲れているのかを、フィードバックループ、フロー状態、認知負荷という3つの観点から丁寧に聞き出します。こうした対話は、組織に長くいると見落とされがちな問題を、具体的な事例として可視化するために欠かせません。なお、問題のパターンは 12〜15人程度 に聞き取りを行うと出そろうとされています。
次に本書は、小さく始めて、早く成果を出すことを重視します。すべてを一度に変えようとすると、組織は動きません。そこでQuick RICE（Reach, Impact, Confidence, Effort）を使い、影響が大きく、労力が少ない改善に絞ります。「コードレビューを3日から1日に短縮する」「ビルド時間を30分から5分に短縮する」といった、開発者がすぐに実感できる改善を積み重ねることで、信頼と勢いを作ります。
そのうえで、本書はデータの活用に踏み込みます。インタビューなどの定性データに加え、ビルド時間やデプロイ頻度といったシステムデータ、満足度などの自己申告データを組み合わせて摩擦を測定します。感覚ではなく数字を使うことで、「声の大きい問題」ではなく、本当に影響の大きい問題に集中できるようになります。
続くステップでは、集めたデータをもとに 戦略と優先順位を明確にします。RICEフレームワークを用いて、どこから手を付けるのか、なぜそこなのかを説明できる状態を作ります。DevExを「良さそうな改善」ではなく、合理的でデータに基づいた投資判断として扱える点は、経営課題として語るうえで重要です。
印象的なのは、改善策そのものだけでなく、それをどう売り込むかまでがステップとして含まれていることです。本書は、DevExの改善を、収益成長、コスト削減、リスク軽減といったビジネスの言葉に翻訳する方法を示します。たとえば、ビルド遅延による時間損失を「年間130万ドルの生産性損失」や「無償の追加人員（free headcount）」として示すことで、経営層の理解を得やすくします。
実装の段階では、スコープ・オブ・コントロールに応じて進めることが勧められます。全社を一気に変える必要はありません。パイロットチームで価値を示し、段階的に広げていくことで、DevExは現実的な取り組みになります。
最後に本書は、進捗を評価し、価値を示すことを欠かさないことの重要性を訴えます。改善が本当に効果を出しているのかを測定データで確認し、その結果をビジネス価値として説明します。これにより、DevExは一度きりの施策ではなく、継続的な改善サイクルとして組織に根づいていきます。
DevExをROIで語ろう
本書のもう一つの大きな価値は、DevExをROI（投資収益率）で説明できる形にまで落とし込んでいる点にあります。この点は、第III部「ビジネスケースの作成」で詳しく論じられており、本書を単なるエンジニア向けの書籍ではなく、経営と対話できる実務書にしています。
本書は、開発者の摩擦を「不満」ではなく、コスト、成長、リスクに直結する測定可能なビジネスの非効率性として捉えます。そして、その解消を戦略的な投資として提示します。これは、CTOやエグゼクティブが評価される財務指標と、DevExを直接結びつけるための重要な視点です。
最も分かりやすいROIの説明が、失われている生産性を金額に換算するという考え方です。ビルド待ちや不安定なテスト、不要な手作業によって失われている時間を測定し、それを開発者の完全雇用コストで換算します。たとえば、50人の開発者が毎週5時間をビルド関連の遅延で失っている場合、その損失は年間で130万ドルに相当します。DevExの改善は、この時間を「回収された生産性（Recaptured Productivity）」として取り戻す投資だと説明できます。
この効果は、「無償の追加人員（free headcount）」という表現に置き換えることもできます。追加の採用や予算なしで開発キャパシティを増やせるという説明は、採用が難しい局面やコスト制約のある状況で特に説得力を持ちます。
本書は、DevExを収益成長を加速させる「力の乗数（force multiplier）」としても位置づけます。摩擦が取り除かれることで、組織はより速く作り、試し、直し、市場に届けられるようになります。実際に、LinkedInやCapital Oneの事例では、DevExの改善によってリリース頻度が大きく向上し、製品改善のスピードそのものが変わりました。
さらに、DevExへの投資は、リスク軽減のための投資でもあります。自動テストや安全なデプロイ、十分な監視といったDevExの基盤は、本番インシデントやセキュリティ事故の発生確率と影響範囲を下げます。Knight Capital社の事例が示すように、DevExへの投資は、ビジネスの存続を守るための保険でもあります。
直接的なROIの算出が難しい場合でも、本書は相関関係を使った説明を提示します。たとえば、開発者経験指数（DXI）のスコアが1ポイント上がると、開発者一人あたり週に約13分の時間が節約されるという相関が示されています。このように、技術的な指標と金銭的価値を結びつける方法まで示している点も、本書の実務的な強さです。
最終的に本書が示しているのは、DevExをコストセンターではなく、既存の経営目標を加速させるイネーブラーとして語ることの重要性です。DevExの取り組みを、「開発者満足度の向上」ではなく、「エンジニアリング速度」や「市場投入能力」の改善として再構成することで、経営層との共通言語が生まれます。
まとめ
本書の価値は大きく二つあります。一つは、Developer Experience（DevEx）をROIと論理的に結び付け、経営課題として説明可能にしたことです。開発者の摩擦を感情や満足度の問題としてではなく、コスト、成長、リスクに直結する測定可能な非効率として捉え、その改善を投資判断の文脈で語れるようにしています。これにより、DevExは現場の話から、経営と対話できるテーマへと引き上げられます。
もう一つは、DevExの改善を理念で終わらせず、実行に向けた具体的な7つのステップとして示している点です。開発者との対話から始まり、小さな成功を積み重ね、データで優先順位を決め、価値を示しながら改善を継続する。この道筋が明確だからこそ、DevExは「分かっているけれど進まない課題」ではなく、「実際に動かせる取り組み」になります。
DevExを語れるようになるだけでなく、実際に前に進められるようになること。それが、この本の最大の価値だと感じました。