LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report
「LeanとDevOpsの科学」が2018年に出版されてから今年2024年で6年が経った。この書籍のもとになった「State of DevOps Report」という技術レポートが最初に発行されたのは2013年なので、それから数えるとなんと11年目である。
今でもたびたび参照される書籍ではあるが、本書が提案している内容はほぼその有効性を失っていると言っていいのではないだろうか。
特に「フォーキーズ」と呼ばれる４つの生産性の指標で組織全体の生産性が判断できるという部分は、他でもない本書の序文でマーティン・ファウラー氏が疑問を呈しているように、本書の出版直後から様々な指摘がされており、当初からシリアスな現場への影響力は限定的だったように思う。
DevOpsのような新しい技術分野が生み出される過程においては、時には荒唐無稽な思いつきであったり、乱暴な仮説であったり、偶然に支配された様々な試行錯誤があるわけだが、本書はそうした部分も含めて、2013年から2017年までの間にDevOpsという技術分野がどのように発展してきたのかを記録したユニークな得難い時代のスナップショットになっている。
同時代をリアルタイムで経験した身として、改めて本書とそのもとになった「State of DevOps Report」を振り返ってみたい。
技術レポート(Tech Report)とは
State of DevOps Reportの始まりは2013年にPuppet社が発行した技術レポートである。
技術レポート(Tech Report)というものについては少し説明が必要かもしれない。皆さんもよくご存知の通り、過去も現在も数多くの技術書が出版されており、さらにネットでもBlogや記事で大量の文章が生み出されている。
その中でも技術レポート(Tech Report)というのは少し特殊な位置付けの文章だ。
その多くは営利企業が自社のセールスやマーケティング目的のために発行するもので、大抵の場合企業のホームページに、自分の氏名や勤めている会社名、会社でのポジション、メールアドレス、電話番号などを記入するとダウンロードできる形を取っている。
当然その会社の製品やサービスに関わるポジショントークが含まれているわけだけれども、それだけではターゲットの顧客層、その中でも特にエンジニアを説得できることはできないので、しっかりとしたマーケットの分析や、現在の顧客の利用状況のサーベイがされていることが多い。
ポジショントークであることは重々承知の上で、分析やサーベイを読み解くというのが技術レポートの楽しみ方になっているのだ。その時事性の強さから新聞に近い性質のものと言えるかもしれない。そのため、技術レポートはアーカイブされないことも多く、通常は最新の技術レポートだけがダウンロードできる形になっている。
State of DevOps Reportの歴史
State of DevOps Reportもそうした技術レポートの一つである。
最初のState of DevOps Reportは先ほど触れたように2013年にPuppet社から発行されたが、その翌年2014年からは本書「LeanとDevOpsの科学」の著者である３名が発行に加わり。本書が出版された2018年まで毎年発行された。
その後、2018年に本書の出版と同時期に、著者３名が立ち上げたDORAという会社がGoogleに買収される。ここからがちょっと面白いのだが、もともとPuppet社から発行されていたState of DevOps Reportとは別にGoogle(に買収されたDORA社)からもState of DevOps Reportが並行して発行されたのだ。結果として２種類のState of DevOps Reportが同時に存在することになった。Googleから発行されたレポートは本家と区別するためか「Accelerate State of DevOps Report」というように「LeanとDevOpsの科学」の原題である「Accelerate」が頭についている。
Puppet社側のレポートは以前と変わりなく2021年まで毎年発行されたのち、Puppet社がPerforce社に買収された影響か2022年版は発行されず、2023年からは末尾に「Platform Engineering Edition」という名前が付いて発行が継続されている。
Google側のレポートは2018年、2019年とDORA社とGoogle Cloudの連名で発行されたのち、2020年には発行されず2021年以降はもともとのDORAのメンバーが著者から外れて発行されている。
こうした経緯があるので、2018年以降のState of DevOps Reportを参照する際には、どちらの技術レポートかを明示しないとわけがわからなくなってしまう。
Google DORA史観
こうした経緯を知らない方がState of DevOps Reportで検索すると、多くの場合Google CloudのDORAチームのページに行き着くのではないだろうか。
このGoogle DORAのページには過去のState of DevOps Reportのアーカイブが載っているが少し注意が必要である。
まず最初の2013年のState of DevOps Reportが無かったことにされている。さらに2018年以降のPuppet社のState of DevOps Reportも載っていない。
Puppet社のものは競合ということで理解できなくもないが、2013年版が載っていないのはかなり残念である、なぜなら次の項で述べるが、2013年版が本書のメインの主張である「フォーキーズ」の初出だからだ。
またState of DevOps Reportを出版するにあたって尽力したPuppet社の社員の労力を近くで見ていたものとしては、フェアな扱いではないように思える。
時折Google DORA史観のものだけを参照して、State of DevOps Reportに触れている記事があるが、是非2013年版のものも含めPuppet社版の本家State of DevOps Reportも参照していただきたい。
特に同じ年のものを比較すると、いかに同時代で精度の高い仮説を立てることが困難なことなのかということがよく分かるだろう。
「フォーキーズ」の検証と2013年の「State of DevOps Report」
さて、では本書のメインの「フォーキーズ」の内容に触れていこう。
本書の「はじめに」の中で本書は2014年から2017年にかけての「State of DevOps Report」をベースにしたものであるとしている。
2013年末、著者３人はPuppert社のチームとともに『2014 State of DevOps Report(DevOpsの現況に関するレポート2014年版)』の作業を始めた。<中略>、2017年版までに4回にわたってPuppet社のチームとともにアンケート調査を繰り返してはレポートを作成・公表してきた。本書はこの4年間の研究成果をまとめたものである。
本書は著者３名とPuppet社のチームが共同で行なった2014年から2017年にかけての４年間の研究成果の集大成であるとしている。そして「開発組織のパフォーマンスを測定」と題した第2章では、いよいよ「フォーキーズ」が登場する。
ソフトウェアデリバリのパフォーマンスを的確に計測できる尺度は２つの特徴をもっていなければならい。<中略>
以上のような基準を満たす計測尺度を探した結果、我々は次の４つを選び出した。デリバリのリードタイム、デプロイの頻度、サービス復旧の所要時間、変更失敗率である。この４つを選んだ理由を説明しよう。
ここで以下の４つの指標が提示される。
デリバリのリードタイム
デプロイの頻度
サービス復旧の所要時間
変更失敗率
これがいわゆる「フォーキーズ」である。さらに本書は組織のパフォーマンスとデリバリのパフォーマンスは強固な関連性があると主張しており、デリバリのパフォーマンスを見ることで、組織全体のパフォーマンスが測定できるとしている。
本書だけを読むと、あたかも４年間の試行錯誤の結果この４つの指標を選び出したかのように記述されている。先ほどの引用を繰り返そう。
以上のような基準を満たす計測尺度を探した結果、我々は次の４つを選び出した。
しかしこれは、かなりミスリーディングな記述だと思う。なぜなら「フォーキーズ」の初出は本書が対象としている2014年から2017年の研究が始まるその前年、一番最初の2013年のState of DevOps Reportだからだ。
このように2013年の時点で既に「フォーキーズ」の４つの指標が記載されている。さらに各指標と組織のパフォーマンスに関する考察も５年後に出版される本書のものとほとんど同じなのである。しかも、その後の2014年から2017年の調査においても、この４つの指標以外の指標の検討や比較などは一切行われていない。
あたかも複数の指標から選び出したかのような説明を書籍ではしているが、調査の最初の段階で、恣意的に選んだ指標に結果を当てはめているだけなのではないかと感じてしまうのも無理はないだろう。
誤解しないで欲しいのだが、開発の生産性の指標について仮説を立てることには徹頭徹尾価値があると考えている。しかしその結果については、論理的な裏付けと、再現性の検証、統計学的な推測が必要だと考えるが、本書の記述にはそうした検証がすっぽり抜け落ちている。
序文におけるマーティン・ファウラー氏の指摘
本書に対する最も痛烈な批評はマーティン・ファウラー氏による本書の序文だろう。マーティン・ファウラー氏は、自身も名作「リファクタリング」の著者であり、さらには彼の名前を冠した「マーティン・ファウラー・シグニチャーシリーズ」という技術選書でも有名である。この選書は質の高さと、その技術的な先見性から高い評価を受けている。私もこの選書の大ファンである。おそらく、本書の著者の一人であるジェズ ・ハンブル氏がかつて、同選書で「継続的デリバリー」という書籍を出版していたことから声がかかったのだろう。本書の序文において、マーティン・ファウラー氏は、
本書が晴れて出版の運びとなったことは大変に喜ばしく私としてはもちろん今後大いに推薦していくつもりだ<中略>。とはいえ、あえて２つの点に注意を促しておきたい。
として本書について２点指摘する。
まず、この研究が採用したアンケート調査で、なぜ信頼性の高いデータを得られるのか、<中略>主観的な感覚に関わる回答を求める調査であるため、この研究のサンプル集団が、広く一般のIT業界の実態を正しく反映しえているのか、との疑問が残る。
今後、この種のさらなる裏付けが重ねられれば、「この調査結果は、自分たちが支持し推奨している理論や運動を追認する結論をだしているだけではないか？」との私の懸念も薄らいでいくと思う。
残念ながら、私が読んだ限りでは、本書がやっていることは、まさに「自分たちが支持し推奨している理論や運動を追認する結論をだしている」ことのように思える。そしてもう一点、
本書の焦点の当て所がIT分野におけるデリバリにかぎられる、ということーつまり、ソフトウェア開発の全工程ではなく、コミットから本番かどうの段階までにしか目を向けていない、という点ーにも注意が必要である。
ソフトウェアの全工程のうち、あくまでもその一部であるDevOpsの生産性を測定できたとしても、それだけで会社全体のパフォーマンスを測定できるとはならないだろうとの指摘である。
どちらの指摘についても本書は十分に答えられていないように思える。
根拠論文に関する疑問
DevOpsのパフォーマンスが組織全体のパフォーマンスに影響を及ぼすということを説明するために、本書では組織のパフォーマンスの測定指標についてこのように述べている。
組織のパフォーマンスに関しては、自組織のパフォーマンスを「収益性」「市場占有率」「生産性」の３つの基準で判断してもらい、リッカート尺度の複数の選択肢から１つを選んで回答してもらった。この３つの基準は、すでに過去の調査研究[Widener 2007]で複数回にわたり有効性が立証されている上に、投資利益率（ROI）との高い相関も判明している。
ここで根拠論文として、[Widener 2007]が挙げられている。正確にはWidener, Sally K. "An Empirical Analysis of the Levers of Control Framework." Accounting, Organization and Society 32, no. 7 (2007):757-788.というものだ。サマリーがこちらにあるので興味がある方は参照いただきたい。
この部分を素直に読むと、挙げられている３つの基準により、組織のパフォーマンスが測定できることが立証されている論文だと思うだろうが、実はこの論文の中でそんなことは一切証明されていないのである。
この論文は、企業における意思決定の仕組み(Management Control Systems: MCS)を解明するうえでのフレームワークの一つとして提案されているLOC(Levers of Control: LOC)の実証研究の一例にすぎない。
論文では122人のCFOにアンケートを行い、その結果からLOCの補強をしているが、決して「３つの基準」の有効性を立証してもいないし、ましてや「投資利益率（ROI）との高い相関も判明」していない。
(以下2024/2/19追記)それどころか、むしろこの論文の内容はまさに「LeanとDevOpsの科学」と同じく、初めに立てた仮説にアンケートの内容を当てはめていくというもので、その検証の過程でサンプリングの基準を変更しないと期待の結果が出なかったと述べている、もはや何をかいわんやという論文である。こんな論文を読まされて、いったい我々は何を納得すればいいのだろうか。
次項「LeanとDevOps生産性の神話(2) - 数えられるものは全て数えろ」に続く