こんにちは。ソフトウェアプロセス改善コーチでFindy Tech Blog編集長の高橋（@Taka_bow）です。
さて、前回の続きです。
順調に行っていたかに見えたState of Devops Reportですが、ここにきて大きな壁が立ちふさがります。それが、ソフトウェア界の巨匠Martin Fowler（マーティン・ファウラー）でした。
- Martin Fowler氏とは
- 巨匠の不満
- 2015 State of Devops Report
- DORAの設立へ
- 2016 - 2017 State of DevOps Report
- DORA激動の年
- Puppet版State of DevOps Report
- GoogleになってからのState of DevOps Report
- ソフトウェア開発は、今も昔も、どこか実験的である
Martin Fowler氏とは
（良くご存じの方は飛ばしてください） Martin Fowlerを知らない方向けに簡単に紹介すると、ソフトウェア設計やアジャイル開発の分野で世界的に影響力を持つスーパーエンジニアです。「マイクロサービス」の提唱者であり、彼の著書『リファクタリング』は、コードの品質を向上させる方法論としてエンジニアのバイブルとなりました。
個人的な印象は、最初は「UMLモデリング」に長けた方という印象だったのですが、徐々に「パターン」の話が多くなり、最終形態として「アジャイル」に話題が移っていった気がします。
また、この写真、エンジニアだったら見たことありますよね？
アジャイルマニフェスト（アジャイルソフトウェア開発宣言）の背景画になってるアレですね。 この、ホワイトボードを指さしている人物こそMartin Fowlerそのひとです。（と、言われています）
アジャイルマニフェストの署名者の一人であり、ブログや講演を通じてアジャイルを実践的に解説してくれる重要な立役者です。
巨匠の不満
さて、State of DevOps Reportの話に戻しましょう。Martin Fowler 本人によって、書籍「LeanとDevOpsの科学[Accelerate] 」*1の冒頭では、次のようなエピソードが寄稿されています。
本書に寄せて
2、3年前、あるレポートを読んでいたら、こんな文に出くわしたーー「今や我々は自信をもって断言できる。IT部門のパフォーマンスの高さには、生産性、収益性、そして市場占有率を高める効果があり、組織全体の業績と高い相関をもつ」。この手のレポートは即、ゴミ箱に投げ捨てるのが私の通常の反応である。大抵は「科学」を装ったたわごとにすぎないからだ。しかしそのとき読んでいたのは『2014 State of DevOps Report （DevOpsの現況に関するレポート2014年版）』であったため、私はためらった。著者の1人が私の同僚であり友人でもあるJez Humble氏で、私に負けず劣らずこの種のたわごとを嫌う人物であることを知っていたからだ（もっとも、正直言ってゴミ箱に投げ捨てなかった理由はもう1つある。あのレポートはiPadで読んでいたのだった）。
苛烈な文章です。紙だったら捨てられていたのでしょうか！Martinは、さっそくNicole ForsgrenとJez Humbleと3人で話す機会（電話会議）を作ります。
Forsgren氏は根気強く丁寧に研究の論拠を説明してくれた。その説明は、そういった調査・分析方法には詳しくない私にとっても十分な説得力があり、通常をはるかに上回るレベルの（学術論文で発表される研究さえ凌ぐ）厳密な分析が行われている、ということが理解できた。
実際に書籍が出版されるのは、この会議から4年後（2018年）になるのですが……2014年時点で、まずは一旦は納得したようです。
しかし……
そのため、私はその後もState of DevOpsレポートを興味深く読み続けていたが、その一方で不満も募ってきた。どの年度のレポートも研究の成果を公表するばかりで、Forsgren氏が電話で私にしてくれたような説明が一切ないのである。おかげでレポートの信頼性が大きく損なわれていた。推測だけに基づいた研究ではないことを示す根拠がほぼ皆無なのだ。
Martin Fowlerはレポートの方針に納得がいっていないようです。
そこで私も含めて内情を知る者が3人を説得し、研究の調査・分析手法を紹介・解説する本を執筆してもらった。
このように、Martin Fowlerの不満があったからこそ「LeanとDevOpsの科学[Accelerate] 」が存在すると言っても過言ではありません。
「LeanとDevOpsの科学[Accelerate] 」が技術者からすると慣れない文体で書かれているのは、あれが技術書ではなく「研究の調査・分析手法を紹介・解説する本」だからだと思われます。統計手法の解説本ですものね。
2015 State of Devops Report
Martin Fowlerから「根拠の提示がない」と言われた2015 State of DevOps Report ですが、前年と比べ分析に苦慮していた様子が伺えます。
まず、Change Failure Rate（変更失敗率）は、あいかわらずITパフォーマンスの主要な構成要素（construct）からは除外されています。レポートには具体的な事に触れられていませんでしたが、後日出版された「LeanとDevOpsの科学[Accelerate] 」には次のような記述がありました。
クラスター分析では「ハイパフォーマー」「ローパフォーマー」「ミディアムパフォーマー」のいずれの集団についても、この4つの尺度で有意な分類と差別化（チームのカテゴリー化）が行えた。ところが、この4つの尺度で1つの構成概念を得ようとすると問題が生じた。妥当性と信頼性を検証するための統計的仮説検定にパスしないのである。分析の結果、リードタイム、リリース頻度、サービス復旧までの所要時間の3つの尺度だけを使えば、妥当で信頼性のある構成概念が得られることが判明した。
ちょっと分かりにくい文章なので整理すると、ソフトウェアデリバリーのパフォーマンスを正確に測定するには、
- 「リードタイム」「リリース頻度」「サービス復旧までの所要時間」の3つの尺度だけなら信頼性高く妥当な評価ができる。
- 変更失敗率も重要な指標であり、これら3つの尺度と強い相関はある。が、独立した構成概念として扱うには適していない。
「変更失敗率」は予測しずらい異質な指標であり、分析や予測の際には補足的な要素として考慮する必要がありそうです。最新の2024 DORA Reportでも「変更失敗率」はイレギュラーな結果を残しています（別ブログで詳しく触れたいと思います）。
2015年のパフォーマンス・クラスターはSuper High、High、Medium、Lowに分けられ、それぞれ「4段階のスピード」で集計されました。
しかし、パフォーマンスの傾向を特定するまでには至っていません。かろうじて、高パフォーマンスチームと低パフォーマンスチームの間には、明らかに大きな差がある、ということを突き止めたに過ぎませんでした。
DORAの設立へ
翌年2016年10月、Nicole ForsgrenとJez HumbleはDevOps Research and Assessment (DORA)を立ち上げます。これは、誰からの支援（投資）を受けずに立ち上げた会社だったそうです。そもそも、なぜ会社設立に至ったのか？
後日書かれたJez Humbleのブログをもとに解き明かしたいと思います。
State of DevOps Reportの研究は地道に成果を上げ始め、その取り組みが実際のビジネス成果を改善することも証明し、多くの企業からデータを集めることにも成功していました。
一方で、組織が抱える2つの大きな問題も見えてきたそうです。その2つとは……
特に大きな問題は、現場で働く実務者の関与が不足していたことでした。日常業務の中で原則や実践を少しずつ試しながら改善していくプロセスが欠如しており、このことが変革の成功率を大きく下げる要因となっていました。
実は、このやり方はコンサルティング会社にとっても理想的なビジネスモデルとは言えませんでした。なぜなら、優秀な人材を現場に配置しなければならないにもかかわらず、継続的な仕事が保証されているわけではなかったからです。また、このアプローチは規模の拡大も難しく、ビジネスとしての成長にも限界がありました。
これらの問題認識から、NicoleとJezは、アルゴリズムを活用して組織の改善領域を特定し、具体的な改善戦略を提案できるプラットフォームの必要性を認識しました。
特に注目すべきは、変革や改善を「どこから始めるべきか？」という組織からの本質的な問いに、データとアルゴリズムを用いて客観的に答えられる仕組みを作ろうとした点です。
この話題が出た時、Nicoleの目が輝きました。「ねえ、もしソフトウェアデリバリーのプロセス全体から何十人もの人々のデータがあれば、その質問に答えることができる。どのアルゴリズムを使うべきか、そしてそれをどのように修正すべきかも分かっている。これは制約理論（TOC）の問題に過ぎないのよ！最も賢く、効率的な方法で戦略を立てる方法を伝えることができるわ。」
私は一瞬考えて言いました。「待って、本当に？それならば作ってみよう！」そして、そこからDORAは誕生したのです。私たちは翌日からモックアップの作成に取り掛かりました。
Jez Humbleのブログから
2016年にDORAは設立されました。同年10月にはNicoleがフルタイムでの経営を開始し、DevOps Enterprise Summitでは最初の顧客となったCapital Oneとともに、DORAの正式な「お披露目」が行われています。
2016 - 2017 State of DevOps Report
かくして、Puppet + DORA の連名で発表された2016年と2017年のState of DevOps Reportは、制約理論をベースにしたアルゴリズムを活用し、数千の組織から得られたデータを統計的に分析することでDevOpsの実践と組織のパフォーマンスの関係性を客観的に実証しました。
これらの結果を元に読み取った洞察が、あの有名な
「パフォーマンスの改善と、安定性と品質の向上との間に、トレードオフの関係はない」
というものです。
さらに、統計的に有意な形で改善できるケイパビリティ（組織全体やグループとして保持する機能や能力）を24個特定したのです。このケイパビリティモデルは、研究の進展とともに進化し続けています。
これこそが、DORA設立の背景にあった「どこから始めるべきか？」の答えでありFour Keysのパフォーマンス・スコアと、この相関図を見比べながら改革や改善の戦略を立てられるようしたことがDORA研究のもたらした最大の成果と言えます。
また同じ年2016年に、Gene KimとJez Humbleは他の著者とともに"The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations"（邦題：The DevOps ハンドブック 理論・原則・実践のすべて）を刊行します。 bookplus.nikkei.com
この本の内容は、DORAが提唱したケーパビリティモデルを補完する内容であり、DevOpsに必要な実践内容が書かれた本です。
2021年には2nd Editionが刊行されているのですが、残念ながら日本語訳はありません。
なお、2nd Edition ではDr. Nicole Forsgrenも新たに参加し、加筆しているという個人的には胸熱な展開になっています。
DORA激動の年
2018年は、DORAにとって激動の年でした。
まず、2018年3月27日、かねてより進めていた新しい書籍が発売となります。
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations（邦題「LeanとDevOpsの科学」）です。
この本の出版でMartin Fowlerと約束を果たしたことになります。冒頭で述べた通り、この本はDORAの「研究の調査・分析手法を紹介・解説する本」として生まれました。
発行はIT Revolution Pressで、DORAの二人Nicole Forsgren、Jez Humble、そしてIT RevolutionのGene Kimの名前で発行されました。 ここにPuppet Labsのメンバーはいません。（謝辞の中には出てきますが）
そして「LeanとDevOpsの科学」が出版された翌月、書籍名（原題"Accelerate"）を冠した
Accelerate State of DevOps Report
という、新しいプログラムを発表します。
これは、長年共に歩んできたPuppet社とのパートナーシップ解消を意味しました。DORAは、次のパートナーとしてGoogle Cloudを選択したのです。当時のインタビュー記事があります。
新しい Accelerate State of DevOps Reportは2018年8月29日にリリースされます。 筆者としてクレジットされたメンバーは3人だけでした。
- Nicole Forsgren PhD（ニコール・フォースグレン博士）
- Gene Kim（ジーン・キム）
- Jez Humble（ジェズ・ハンブル）
パートナーであるGoogle Cloudがダイヤモンドスポンサーであることはもとより、ゴールドスポンサーがAmazon Web Services、CA Technologies、CloudBees、Datical、Deloitte、Electric Cloud、GitLab、IT Revolution、Microsoft、PagerDuty、Pivotal、Redgate、Sumo Logic、Tricentis、XebiaLabsであり、非常に豪華です。
肝心の中身ですが、2018年のパフォーマンスの指標とレベルにはちょっとした変化が生じます。
それは、MTTRが"Time to restore service"という言い方に変わったことと、レベルに初めてEliteが登場したことです。
このように、リサーチは順調であったようですがDORAのCEO兼主任研究員であったDr. Nicole Forsgrenには大きな重圧がかかっていたようです。
この頃のことをJez Humbleはブログで次のように振り返っています。
経費を抑えた自力での会社運営には大きな代償がありました：それは燃え尽き症候群です。スタートアップは創業者を疲弊させることで有名ですが、私たちも例外ではありませんでした。特に最も大きな負担を背負っていたのはNicoleでした。CEOとして彼女は、会社の戦略、財務、そして事業運営全般に責任を負っていました。それだけではありません。CEOとして市場戦略の立案と実行をほぼ一人で担うだけでなく、State of DevOpsレポートの主任研究者、『Accelerate』の主執筆者、そして買収交渉の責任者も務めていました。彼女が言うように、これらの成果はすべて何年もかけて築き上げたものですが、驚くべき仕事の処理能力を持っていた彼女でさえ、膨大な時間の労働なしにはこれらを実現することはできなかったでしょう。これこそが投資を受けなかったことの代償でした - より大きなチームを雇って、この重荷を分散することができなかったのです。
Jez Humbleのブログから
2018年12月、Nicole ForsgrenはDORAをGoogleに売却する決断をしたのでした。
Puppet版State of DevOps Report
一方、Puppet社も2018年は独自のState of DevOps Reportを発行します。
しかし、これはDORA版とは異なるポリシーで編集されたものでした。2013年版に原点回帰するかの如く、DevOpsの進化の段階を特定し、DevOpsへの変革プロセスの定量化に舵を切っています。
Puppet版 2018 State of DevOps Reportについて語る人物は、あのAlanna Brownでした。
その後、Puppet社は、2022年4月にソフトウェア開発ツール大手Perforce Software, Inc. に買収されましたが、現在もState of DevOps Reportはシリーズを継続中であり、主にDevOpsに取り組む現場での実用性に重点を置いています。
GoogleになってからのState of DevOps Report
Googleの一員となったことで、安定した環境、持続可能な研究環境を手に入れたDORAは、途中COVID-19による2020 DORA Reportの中止もありましたが、晴れて今回で10冊10年目を迎えることができました。
ここでは2019年〜2023年までのトピックを駆け足で紹介します。
入れ替わる著者陣
2019年にGene Kim、2021年にはDr.Nicole ForsgrenとJez HumbleがDORAを去ります。現在は、他のDORAメンバーやGoogleのリサーチャーを中心に研究が引き継がれています。
Gene Kim は現在もIT Revolutionの代表であり、執筆活動や講演を精力的にこなしています。2019年に来日しており、DevOpsDays Tokyo 2019のキーノートセッションに登壇しています。（私は現地で拝聴できました！）
Jez Humble は現在もGoogleに席を置きSRE(Site Reliability Engineering)のエンジニアとして活躍する傍ら、カリフォルニア大学バークレー校（UC Berkeley）の教員も続けているようです。
Dr.Nicole Forsgrenは現在Microsoft Research のパートナーとして Developer Experience Lab を率いており、ACM Queue の取締役も務めています。最近は、科学を活用しソフトウェア開発者をより楽しくする研究を実践しています。DevExやSPACEフレームワークに関する研究論文を発表し、精力的に活動中です。
彼女の最近の論文について、以前解説ブログを書いたので貼っておきます。
また、今年の6月に来日しファインディ主催の「開発生産性Conference 2024」にて基調講演をご担当頂きました。
David Farleyの登場
2022年と2023年の2年間だけ、著名なエンジニアDavid(Dave) Farley（デイビッド（デイブ）・ファーリー）が関わりました。
彼は、Jez Humbleと共にベストセラー「Continuous Delivery」を書いた人物です。 www.kadokawa.co.jp
書籍「Modern Software Engineering」の筆者でもあり、文中、Dr. Nicole ForsgrenにまつわるエピソードやDORAの研究成果が引用されており、非常に参考になる本です。
Eliteレベルがまた消える
2022年の分析では、パフォーマンスレベルからEliteが消滅します。これは、最もパフォーマンスの高いクラスタが、2021年のEliteの特徴を示していなかったためと述べられています。翌年2023年は復活しました。
これは、クラスター分析の特性として仕方のない現象でもあります。クラスター分析は、データの分布やその年の回答者の特性に基づいて自然に分類を形成する手法であり、事前にクラスター数やその特徴を固定するものではありません。
そのため、特定のパフォーマンス層が少数であったり、他の層と重なりがある場合、ある年には明確なクラスターとして現れず、翌年に再び明確化することがあります。この柔軟性こそがクラスター分析の利点であり、データに忠実であることを意味しています。
Four Keysの定義が変更
2023年から、Four Key Metricsの一部名称と定義が変更され、より簡潔かつ実務的な表現に更新されました。次の表に、2022年までの定義と2023年の定義、および具体的な変更点をまとめています。
| 指標 | 2023年の定義 | 2022年までの定義 | 変更点 |
|---|---|---|---|
| Deployment frequency (デプロイ頻度) | 変更を本番環境に push する頻度。 | 主なアプリケーションまたはサービスで、組織が本番環境にコードをデプロイする頻度、またはエンドユーザーにリリースする頻度はどのくらいか。 | 定義が簡潔化され、本番環境への変更適用に焦点が絞られています。 |
| Lead time for changes (変更のリードタイム) | コードの変更を commit してからデプロイするまでの時間。 | 主なアプリケーションまたはサービスで、変更のリードタイム（commit されたコードが本番環境で正常に実行されるまでの時間）はどのくらいか。 | 定義が簡潔化され、コミットからデプロイまでの具体的な工程に限定。「本番環境で正常に実行される」という表現が省かれています。 |
| Change failure rate (変更失敗率) | デプロイにより障害が発生し、すぐに対処する必要が生じる頻度。 | 主なアプリケーションまたはサービスで、本番環境に変更を加えた、またはユーザーに変更をリリースしたとき、サービスの低下（サービス障害、サービスの停止など）が発生して、対策（修正プログラム、ロールバック、フィックス フォワード、パッチなど）が必要になった割合はどのくらいか。 | 「デプロイにより障害が発生し」という表現に変更され、障害の発生原因がデプロイに限定。具体的な対策例が削除されました。 |
| Failed deployment recovery time (失敗デプロイの復旧時間) (旧名称: Time to restore service (サービス復旧時間)) |
デプロイの失敗時に復旧にかかる時間。 | 主なアプリケーションまたはサービスで、サービスのインシデントや、ユーザーに影響を与える障害（計画外のサービス停止やサービス障害など）が発生した場合、サービスの復旧に通常どれくらいの時間がかかるか。 | 指標名が変更され、定義が「デプロイの失敗」に絞られました。例として挙げられていた「計画外のサービス停止やサービス障害」が削除されました。 |
ソフトウェア開発は、今も昔も、どこか実験的である
ここまでが去年までの振り返りとなります。
前回のブログで、Tom DeMarco はのIEEE Software誌を引用し「ソフトウェアの力で世界を変えるようなプロダクトを生み出すことの方が重要」というDeMarco自身の「気づき」について引用しました。実は、彼はその記事の最後で、こう締めくくっています。
ソフトウェア開発は、今も昔も、どこか実験的である。 実際のソフトウェアの構築はそれほど実験的ではありませんが、その構想は実験的です。そして、この点にこそ私たちの焦点が当てられるべきでしょう。私たちは常にここに焦点を当てるべきでした。
(Tom DeMarco, 2009)
DORAの10年は、まさにDeMarcoが語った「ここに焦点」を当て続けた挑戦そのものだと感じます。日々の実践と実験の中から何が本当にチームを強くし、ソフトウェアをより良いものにするのかを探求し続けたその姿勢こそ、彼の言葉を現実のものとし未来を照らし出す希望そのものだと私は信じたいのです。
では、いよいよ2024 DORA Report の中身を見ていきましょう！
次回に続きます。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
*1:Forsgren, N., Humble, J., & Kim, G. (2018). LeanとDevOpsの科学 [Accelerate]: テクノロジーの戦略的活用が組織変革を加速する. インプレス.
