勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

State of DevOps Reportより踏み込んだ考察本「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」が面白い

大分周回遅れなのだけれども、最近読んでいる「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」がめっぽう面白い。なお以下にKindle本へのリンクを示すが、私はここに書いた手法で定額制の範囲内で読んでる。

Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

まだ途中までしか読んでいないのだけれども、物凄く雑に例えると「DevOps白書」みたいな本。DevOps白書としてはState of DevOps Reportというものが従来から存在するのだけれども、本書はそこから踏み込んだ分析と考察した結果が書かれている本である。なおState of DevOps Reportの分析メンバーと著者は一緒。

Puppet LabsのState of DevOps Report 2017が報告され、ハイパフォーマンスなITチームはより頻繁にデプロイメントを行い、より高速に障害のリカバリーを行なっていることが明らかになった。自動化、疎結合アーキテクチャ、継続的デリバリーを促進するチームにより焦点が当てられている。変革的なリーダーシップとリーンな製品管理のプラクティスもハイパフォーマンスなチームの背後にある重要な鍵である。

で、Martin Fowlerが推薦文書いてるが、ベタ褒め。

So, as you may expect, I’m delighted that they’ve put this book into production, and I will be recommending it willy-nilly over the next few years.

基本的には「どうやったら開発パフォーマンスが向上するか」「(DevOps文脈における)どのような取り組みが開発パフォーマンス向上に意味があるのか」といったテーマについて書かれている本である。さまざまなファクター間の相関モデルはここ(注:PDF)などでも閲覧できるので、まずはちょっとチラ見してみると良いかもしれない。馴染みのある概念もあれば、ちょっと目新しいキーワードも現れている(例えば自分が不勉強なだけかもしれないが、Westrum Organization Cultureといった考え方は初見だった)。

この本の一番シビれるところは、ソフトウェア開発における開発パフォーマンスの定義、かもしれない。本書では、コード量やヴェロシティやソフトウェアの使用率といった、従来的な(アウトプットベースの)パフォーマンス測定方法は一切無視して、

  • デリバリの頻度
  • 修正のリードタイム
  • MTTR
  • 修正失敗率

という4つの指標を開発パフォーマンスのKPIとしているという点かもしれない。この指標についてはState of DevOps Report 2017のP.20~ IT performance & organizational performanceに書かれているものと一緒。もし興味があれば改めてReportを読んでみてもよいかも。この4つの指標は一見するとものすごい割り切りのような気もしたけれど、よく考えるとけっこう味のある組み合わせだ。4つの指標それぞれを同時に向上させるのはけっこう難しそうである。

そういえば小ネタとして、コード修正量が生産性指標として無意味である証明として1982年のApple Lisaの話がさらっと紹介されていて笑った。この話、前にどっかで読んだんだけど思い出せない。