このブログの内容をポッドキャストでも配信中！
こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋（@Taka_bow）です。
2024 DORA Reportについての連載も、今回で最終回です。
今回はDORA Reportの中から、前回取り上げたAI関連以外で個人的に気になったトピックをまとめました。
DORA Reportのライセンスは次の通りです。
“Accelerate State of DevOps 2024” by Google LLC is licensed under [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)
なお、DORA Report原文はGoogle Cloudのこちらのページからダウンロードできるので、ぜひ一次情報に触れてみてください。
Software delivery performance
DORAは、ソフトウェアデリバリープロセスのアウトカムを効果的に測定する手法として、4つの重要指標（Four Keys）と呼ばれるソフトウェアデリバリーの指標を継続的に検証してきたことは御存知の通りです。
2024 DORA Reportの結論としては、
最高パフォーマンスのチームは、Four Keys（変更リードタイム、デプロイ頻度、デプロイ失敗時の復旧までの時間、変更失敗率）すべてで優れた結果を出している一方、最低パフォーマンスのチームはこれらFour Keysすべてで低い結果となっています。
パフォーマンスの高低は業種に関係なく、あらゆる産業分野のチームが各パフォーマンスグループに存在しています。(p6)
と、いつも通りです。
しかし、パフォーマンスレベル表が提示される直前、次のような注目すべき一文が添えられていました。
私たちは、前年のクラスター分析との一貫性を保つため、元の4つのソフトウェアデリバリー指標に対してクラスター分析を実施しました。(p13)
「一貫性を保つため」とはどういう事でしょうか？
実は、今回のレポートでDORAはソフトウェアデリバリーパフォーマンスの測定指標を再定義しています。 DORAはこの変更を「Evolving（進化）」と表現しています。
本当に優れたチームとは「Eliteな改善」を実現するチーム
まず、この新しい指標の説明に入る前にFour Keysベースの、いつものクラスター分析の結果を見てみましょう。
集計では、Change failure rate (変更失敗率)に特異な傾向が見られます。 この特徴は次のグラフを見るとより明確です。
なんと、変更失敗率のHighレベルとMediumレベルが逆転しているのです。
私は、この決定をDORAからの強いメッセージと捉えました。それは、次の解説に表れています。
私たちは、より高速なチームを「High パフォーマー」、より遅いが安定しているチームを「Medium パフォーマー」と呼ぶことにしました。この決定は、これらのパフォーマンスレベルを使用する際の潜在的な落とし穴の一つを浮き彫りにしています。つまり、特定のパフォーマンスレベルに到達することよりも、改善を続けることの方がチームにとって重要であるという点です。
本当に優れたチームとは、「Eliteなパフォーマンス」を達成するチームではなく、「Eliteな改善(elite improvement)」を実現するチームなのです。(p14)
「パフォーマンスレベルを上げましょう」「Eliteを目指しましょう」といったスローガンは、本質的な目的を見失わせる危険性をはらんでいます。真に重要なのは、品質とスピードを同時に追求するマインドです。この両立を実現するためには継続的な改善活動が不可欠だと言えます。
さて、変更失敗率ですがDORA Reportの歴史においては当初から予測しづらい異質な指標として認識されてきました（第2回のブログで触れています）。
2024年でもその影響が現れてしまったわけですが、一方で、DORAは変更失敗率に関して大きな実験をしています。それは、変更失敗率に関するアンケートの質問の追加と、新たな計測指標の仮説検証です。
私たちは、変更失敗率という指標がチームに求められる手戻り作業量の代替指標として機能するという長年の仮説を持っています。デリバリーが失敗すると、チームはその変更を修正する必要があり、おそらく別の変更（修正コミット）を加えることになります。
この理論を検証するため、今年はアプリケーションの手戻り率に関する別の質問を追加しました。
「あなたが主に担当しているアプリケーションやサービスにおいて、過去6ヶ月間に計画されていなかったものの、アプリケーション内のユーザーに影響するバグに対処するために実施されたデプロイは約何回ありましたか？」
私たちのデータ分析により、手戻りと変更失敗率が関連しているという仮説が確認されました。(p11)
「手戻り率」の登場
そこでDORAは、長年の仮説であった「手戻り率」を追加することにしました。 しかし、具体的にどう影響を与えているのかの明確なデータは提示されていません（「仮説が確認された」という明言のみ）。
従来のFour Keysとの関係を整理すると次のようになります。
ポイントは、ソフトウェアデリバリーに関連するメトリクスを「スループット」と「安定性」を明確に分けたことだと思います。（個人的には「デプロイ失敗時の復旧までの時間」は「安定性」を測る指標だと思っていましたが、今回は明確に「スループット」であると提案されました。）
つまり、指標として不安定な「変更失敗率」は新たな「手戻り率」というパートナーを迎え、新ユニットを結成したのです。
従来所属していたグループ「Four Keys」（変更リードタイム、デプロイ頻度、デプロイ失敗時の復旧までの時間、変更失敗率の4つの主要メトリクス）に籍を置くものの、メンバー同士の関係性は変わった……と言ったところでしょうか。
今後の関係性も含め継続的な分析を期待したいところです。私達も実験してみる必要性を感じています。
Reliability（信頼性）は引退？
なお、今回のDORA Reportではパフォーマンス指標としてのReliability（信頼性）についての言及は限定的であり、「A decade with DORA（DORAと共に過ごした10年）」という章で少し紹介されただけでした。
Reliability（信頼性）はこのままひっそりと引退するのか、それとも重要な指標として再評価されるか、今後も注目していきたいと思います。
なお、あくまでソフトウェアデリバリーパフォーマンスの指標として有意なのか？という視点の話であって、信頼性が重要なメトリクスであることには変わりないことを申し添えておきます。
Platform engineering
2024 DORA Reportは、基本的にソフトウェアデリバリーに焦点を当てたレポートですが、今回はプラットフォームエンジニアリングについてかなりの紙面を割いています。このレポートでは、プラットフォームの活用が、ソフトウェアのデリバリーと運用面のパフォーマンスにどのように関係しているのかを詳細に検証しています。
プラットフォームエンジニアリングとパフォーマンスの関係
まだ日本国内では聞き慣れない言葉かもしれませんので、最初にプラットフォームエンジニアリングの解説をしておきます。
ご存じの方は読み飛ばしてください。
Internal Developer Platform（IDP）を利用している開発者は、次のような結果が分かったそうです。いくつかのポジティブな結果と共に、欠点も見えています。
| ポジティブ | ネガティブ |
|---|---|
| 個人の生産性が8%向上 | スループットが8%低下 |
| チームのパフォーマンスが10%向上 | 変更の安定性が14%低下 |
| 組織全体のソフトウェアデリバリーおよび運用のパフォーマンスが6%向上 |
プラットフォームエンジニアリングがもたらす可能性
プラットフォームの使用期間と生産性*1の関係を見ると、プラットフォームエンジニアリングの取り組み開始時に初期の成果が得られ、その後プラットフォームが年数を重ね成熟するにつれて一旦低下し、その後回復するというパターンが見られました。
このパターンは、変革の取り組みにおいてよく見られるもので、初期の成果を上げた後に困難に直面するケースを指します。しかし、長期的には生産性の向上が維持されており、ソフトウェアデリバリーと運用プロセスにおける内部開発者プラットフォームの重要性とその潜在的な価値を示しています。
意外な落とし穴
上記で書いた通り、スループットの8%低下や変更の安定性の14%低下といった欠点も確認されています。DORAとしても明確な分析はできておらず、次のような仮説を提示しています。
| # | 仮説 | 詳細 |
|---|---|---|
| 1 | プロセスの複雑化 | コードが本番環境に到達するまでの「引き継ぎ」段階が増え、各段階で時間が追加される |
| 2 | プラットフォーム強制利用の問題 | アプリ開発の全工程でプラットフォームの使用が義務付けられる場合、さらに6%のスループット低下 |
| 3 | 実験の促進 | プラットフォームが開発者に変更を自信を持って行う環境を提供し、より多くの変更を可能にする |
| 4 | 品質保証の課題 | プラットフォームが変更の品質を十分に保証できていない、またはチームがスループットを優先して自動テスト機能を活用していない |
また、プラットフォームエンジニアリングとバーンアウト*2の関係性に関する調査では、変更の不安定性とプラットフォーム利用の組み合わせによってバーンアウトリスクが高まることが明らかになりました。
この興味深い関連性について、DORAは3つの仮説シナリオを提示していますが、本ブログで取り上げるのは止めます。詳しく知りたい方は原著をお読みください。
プラットフォームエンジニアリングの章は全体的に具体性が欠けており、個人的には科学的ではないと感じた章です。
今後の研究成果に期待したいと思います。
Developer experience
2024 DORA Reportでは、デベロッパーエクスペリエンス*3（以降、DevEx）に関して多くの誌面を割いています。このセクションでは、DevExが組織の成功に直結するという重要な発見と、それを改善するための具体的な方法について掘り下げています。
AIの時代においても、最終的にソフトウェアを構築するのは人間です。DevExがいかに製品品質と組織のパフォーマンスに影響するのか、DORAレポートに基づいて解説します。
なお、私は以前DevExの科学的な研究について解説したブログを書いておりますので、合わせてお読み頂ければと思います。
ユーザー中心の開発がDevExを向上させる
レポートでは、DevExを向上させるにはまず、エンドユーザーエクスペリエンス（UX）を向上させることが重要であるという点が強調されています。エンドユーザーのニーズを深く理解し、それを開発プロセスの中核に据える組織では、開発者の生産性が向上するとともに、組織全体の成長が促進されることが調査で示されています。
ユーザーのニーズを軸に開発を行うことで、開発者の仕事の満足度が高まり、結果的に組織全体のパフォーマンス向上につながる可能性があります。ユーザー中心（User-Centric）のマインドセットを実践している開発者には、次のような特徴が見られます。
- より高い生産性を発揮する（目的意識が明確になり、不要な作業が減る）
- バーンアウトのリスクが低下する（仕事の意義を感じやすく、ストレスが軽減される）
- より高品質な製品を生み出す（ユーザーの課題に直結したソリューションを提供できる）
また、ユーザーエクスペリエンス（UX）を最優先する組織では、ソフトウェアデリバリーの安定性やスループットが必ずしも品質の前提条件とはならないという点が指摘されています。 その理由として、最終的な製品の品質は「迅速なデリバリー」ではなく、「ユーザーにとっての価値」によって決まる可能性があるからです。
このレポートの知見を踏まえると、ユーザー価値の創出に組織的に取り組むことの重要性が浮かび上がります。ファインディでは幸いなことに、専門のデザインチームがありエンジニアと共にユーザーエクスペリエンス（UX）に力を入れているため、この課題への取り組みはすでに進んでいると言えるでしょう。今後もさらなる進化を目指して努力を続けていきたいです。
一方で、ユーザーフィードバックを十分に取り入れない組織では、安定したデリバリー速度が品質を確保する唯一の手段になりがちであるとも述べられています。
これは本来「ユーザー価値の創出」が目的であるべきところ、「安定したデリバリー」という手段が目的化してしまう典型的な例といえるでしょう。その結果、ユーザーの実際のニーズとはズレた機能や、見た目は魅力的でも実際にはほとんど使われない機能（"shiny but hardly used"）が生まれるリスクが高まるという考察がされています。
最終的な目標は、私たちが作る製品をユーザーに愛してもらうことです。「デベロッパーエクスペリエンス」の章で述べているように、ユーザーに焦点を当てることで、製品の機能に存在意義が生まれます。開発者は、これらの機能がユーザーエクスペリエンスの向上に役立つことを確信して、自信を持って開発を進めることができます。(p73)
これは非常に興味深い考察です。シンプルに言い換えれば「エンジニアもお客様の喜ぶ顔を見れば生産性は上がり組織も成長する」ということなので、商売の基本みたいな話だなと思いました。
質の高いドキュメントがユーザー中心開発を増幅する
2021年からドキュメントの調査を開始したDORAですが、2024年のレポートでは、質の高いドキュメントとユーザー中心のアプローチを組み合わせると、製品パフォーマンスが向上することが明らかになりました。
質の高いドキュメントの評価には、内容の見つけやすさや信頼性といった要素が含まれます。
DORAは、アジャイルマニフェスト（アジャイルソフトウェア開発宣言）を引用して次のように述べています。
アジャイルマニフェストは「包括的なドキュメントよりも動くソフトウェアを」*4を提唱しています。しかし、私たちは依然として、質の高いドキュメントが動くソフトウェアの重要な構成要素であることを認識しています。「包括的なドキュメント」という表現は、ドキュメントを含む不健全な慣行を表しているのかもしれません。
問題のあるドキュメントには、官僚的な目的だけのために作成されたドキュメントや、経営陣と従業員の間の不信感を取り繕うためのドキュメントが含まれます。不健全なドキュメント文化には、ドキュメントを作成するものの、維持や整理を行わないことも含まれます。
アジャイルマニフェストが宣言された2001年頃は、「ドキュメント作成に時間を取られすぎる問題」が開発現場の切実な課題でした。
当時の多くの開発では詳細な仕様書作成が前提とされ、要件変更が発生するたびに仕様書の修正に追われ、実際の開発よりもドキュメント管理に多大な時間を費やしていました。大量の紙にプリントして製本、そのドキュメントを納品、といった風習もまだ残っていた時代です。
また、現代に生きる私たちは忘れがちですが、2001年頃の技術的な制約も大きく影響していました。
ツールはWordやWiki、Lotus Notes/Domino*5が主流でしたが、当時のツールはバージョン管理機能が貧弱で、複数人での同時編集が不可能、変更履歴の追跡も困難でした。
また、大きなドキュメントは頻繁にクラッシュし、図や表の扱いも現在より遥かに制限されていました。さらに、ストレージは現在と比べて容量が小さく高価であり、ネットワーク速度も遅いという環境でした。
一方、クラウド中心の現代ではNotionやConfluence、GitHub Wikiなど、協働作業に適したドキュメント管理ツールが普及し、リアルタイム共同編集や変更履歴の自動管理が当たり前となっています。
DORAレポートによれば、現代におけるドキュメントの役割は「ユーザーの声やフィードバックをチーム全体に共有し、それを製品に反映させる」という、より価値創造に直結したものへと進化しています。
DORAレポートは、健全なドキュメント文化を構築するための具体的な実践方法も提示しています：
- 重要なユースケースの文書化
- テクニカルライティングの研修
- 明確な責任者と更新プロセスの定義
- チーム内でのドキュメント作業の分担
- 開発ライフサイクルの一部としてのドキュメント維持
- 古いドキュメントの削除
- 業績評価における文書作成貢献の認識
さらに、詳しく知りたい方は原著をお読みください。
常に変わる優先事項の危険性
DORAの調査で最も注目すべき発見の1つは、組織の優先事項が頻繁に変わることによる悪影響です。
エンジニアであれば直感的に「危険」と思える現象です。
この感覚は誰もが経験したことがあるでしょう。数か月かけて新しい機能の開発に取り組んできて、それがユーザーにとって必要なものであると確信し、集中し、モチベーションも高い状態です。ところが、突然、あるいは突然のように感じるほど急に、経営陣が組織の優先事項を変更します。すると、あなたのプロジェクトが一時停止されるのか、中止されるのか、別の形に変わるのか、それとも全く違うものになるのかが分からなくなります。
データによれば、優先事項が不安定な組織では、
- 生産性に小さいながらも確実な低下が見られる
- バーンアウトが大幅に増加する
興味深いことに、強力なリーダーシップや質の高いドキュメント、ユーザー中心のアプローチがあっても、優先事項が不安定であれば従業員はバーンアウトのリスクにさらされ続けることが明らかになりました。DORAは、これが慢性的なストレスによるものと推測しています。
一方で興味深いことに、優先事項が安定すると、逆にソフトウェアデリバリーのスピードと安定性が低下するという予想外の結果も報告されています。これについてDORAは、安定した組織では変更が少なくなるか、推奨されるよりも大きなバッチでの出荷が行われるためではないかと仮説を立てています。
おわりに
さて、全4回にわたってお届けしたDORAレポートに関するブログも一旦終わりにし、2025年のDORAレポートを待ちたいと思います。
皆様におかれましてはDORAレポートを参考にしながら、ぜひ自組織についての仮説や理論を組み立てるのに役立ててください。独自の実験に取り組むことで、より実践的な知見が得られるでしょう。
今回のブログを書きながら改めて感じたのは、ソフトウェア開発の複雑さです。
クネビン(Cynefin)フレームワークで例えると「Complicated」ではなく、「Complex」の領域に位置します。
| 領域 | 特徴 | 対応方法 | 例 |
|---|---|---|---|
| 明確（Clear） | 因果関係が明確であり、誰が見ても同じ答えが得られる領域。ルールやベストプラクティスが効果的。（2014年までは単純（simple）、その後明白（obvious）と呼ばれ、最近の名称に変更） | 「分類し、対応する」(Sense — Categorize — Respond) | マニュアル化された業務、明確な手順がある問題 |
| 煩雑（Complicated） | 因果関係が理解できるが、専門知識や分析が必要。答えが複数存在する可能性もある。理論的に解決可能。 | 「分析し、対応する」(Sense — Analyze — Respond) | エンジニアリング、法律の専門的問題、データ分析が必要な業務 |
| 複雑（Complex） | 因果関係が曖昧で、試行錯誤を通じてパターンが見えてくる。予測が困難で、正しい答えが最初からわからない。 | 「試し、理解し、対応する」(Probe — Sense — Respond) | 新製品開発、文化変革プロジェクト、組織変革 |
| 混沌（Chaotic） | 因果関係がなく、予測不可能な状況。迅速な介入が必要で、秩序を取り戻すことが優先される。 | 「即座に行動し、理解し、対応する」(Act — Sense — Respond) | 自然災害、事故発生直後の対応、緊急事態 |
| 混乱（Confusion） | どの領域にも属さない、または適用領域が不確かな状況。複数の視点が入り乱れ、争いが発生することも。 | 状況を分解し、他の4領域に割り当てることで解決の糸口を見つける | 情報が混乱していて、どの領域に該当するか判断が難しい場合 |
様々な要因が絡み合いComplexになりやすいソフトウェア開発ですが、パターンは存在します。
まず「試し、理解し、対応する」（Probe — Sense — Respond）というアプローチで小さな実験を繰り返し、そこから学んでいく。この積み重ねが、ソフトウェア開発では大事なのだと、改めてDORAレポートを熟読して実感しました。
そして、この複雑さ（Complexity）こそが、ソフトウェア開発の魅力であり、日々新たな発見と創造の喜びをもたらしてくれるのだと実感しています。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
*1:DORAの生産性(Productivity)の定義：個人が自身の仕事において、どれだけ効果的かつ効率的であると感じているか、価値を生み出し、タスクを達成できているかを測るもの。
*2:バーンアウト（Burnout）とは、長期間のストレスや過重な業務負担によって、心身ともに疲弊し、モチベーションや集中力が低下する状態を指します。特にソフトウェアエンジニアのように、高い認知負荷や締切に追われる職種では発生しやすく、「燃え尽き症候群」とも呼ばれます。主な症状には、慢性的な疲労、仕事への意欲の低下、感情の枯渇などがあり、生産性の低下や離職の要因にもなります。DORAは10年に渡り、このようなバーンアウトのリスクを考慮した調査を数多く実施しています。
*3:私は頑なに「開発者体験」とは訳しません。正しいニュアンスを伝えるなら「開発者が快適かつ効果的に働ける環境全般」とするべきで、でもこれだと面倒なのでそのままの言葉で良いかなと思っています。
*4:「包括的なドキュメントよりも使い物になるソフトウェアを」と訳したほうが良い説を支持しています。 https://x.com/t_wada/status/1848630196775346294
*5:Lotus Notes/Dominoとは、IBMが1995年にLotus Development社を買収して獲得した企業向けグループウェア・情報共有プラットフォームです。1990年代から2000年代初頭にかけて多くの企業で導入され、メール、カレンダー、文書管理、ワークフロー機能などを統合した先進的なシステムでしたが、操作の複雑さやカスタマイズの難しさも指摘されていました。
