『LeanとDevOpsの科学』まとめ

以前からAmazonの欲しいものリストにはあったのですが、なかなか読みたい気持ちにならずリストを整理するときに削除しちゃっていたのですが
2月ぐらいからTwitterでこの本についての言及が増えたし、ちょうどそのころ開発生産性とは何か、について一考していたこともあったので、読んでみました。

LeanとDevOpsの科学

一旦さらっと読んで、面白いなー、やっぱデリバリ大事だなーと思って読了したんですが
先日texta.fmでこの本のことが取り上げられており、あー、そんな読み方があったかーと思って改めてちゃんと読み直してみました。

構成

• 第一部: 調査結果から見えてきたもの(パフォーマンスを向上させるケイパビリティとは何かの話。特にデリバリを中心に多面的に検討している)
• 第二部: 調査・分析方法
• 第三部: 改善努力の実際(いろんな会社の取り組みの事例)

読み方

常に付録Aの図A.1を開いておくと良い。
この本では組織のパフォーマンスに影響のあるケイパビリティが24個も登場し、それぞれに影響があるので迷子になりやすい。
この図を地図として読むと吉。ってtexta.fmでも言ってた。
たしかにそうなんですよね。私も最後に気づきました。

言葉の定義・前提

組織のパフォーマンス(p31)

• 収益性
• 市場占有率
• 生産性

本著で言う「組織のパフォーマンスが高い」というのは上記の3つが高い、優れているということを示す。とは言うものの、特に詳しく書いてない。ちなみにこれらの指標は外部環境からの影響を受けにくいというのが選定の理由とのこと。ここでいう生産性が何を指すのかはもうちょっと知りたい。

デリバリのパフォーマンスの尺度・指標

本著では「パフォーマンス」といっても「組織のパフォーマンス」と「デリバリパフォーマンス」の両方のパフォーマンスがあるので混乱しないように注意！

「デリバリのパフォーマンス」といったときには下記のことを指す

• リードタイム
• デプロイ頻度
  • 本来はバッチサイズの小ささで測るべきだが、ソフトウェアは目に見えるものがなく測りにくいため、細かくデプロイしていればバッチサイズは小さくなることに依拠している
  • 実際にデプロイ頻度が上がるとバッチサイズが小さくなるという研究もあるとのこと(p23)
  • デプロイ回数ではなく頻度であることに注意(1時間につき1回とか)
• MTTR
  • 「パフォーマンスを改善したチームが、作業中にシステムの安定性を犠牲にして改善を実現したのかどうか」を調べるため(p24)」、とのことだがよく分からん
  • 「信頼性」を測りたいみたいな書き方をしている
  • 「現代では失敗するのが当たり前だから、失敗を避けるのではなく、失敗をいかに早く復旧させるのかが大事」みたいなことが書かれている
  • まあ、要は信頼性や安定性を指していると思われる
• 変更失敗率
  • 品質要求基準として
  • p47では「変更失敗率をカウントすると統計的に有効な仮説にならないので、原則上３つの尺度のみを適用する」という謎の記述がある。「強い相関はある」と言ってもいるが。

議論のポイント

本論

デリバリパフォーマンスが良好な組織は、そうでない組織と比べると

• デプロイ頻度は46倍
• リードタイムは1/440
• MTTRは1/170
• 変更失敗率は1/5

とのこと(p14)。

ハイパフォーマーは４つの全ての尺度でローパフォーマーを圧倒しているとのこと(p27)。
一般的には品質とスピードはトレードオフの関係にあると思われがちだが、そうではない。

さらに、デリバリパフォーマンスの高い組織は、組織のパフォーマンスも高いとのこと。２倍を超える程度(p31)。つまり技術的なケイパビリティは企業の業績に直結し、かつかなりの影響力を持っているということである。和田卓人さんもおっしゃっていたが、長らくエンジニアリングの現場では「なんとなくそうだろうな」と思っていたことが客観的な数字によって強い相関関係があることが証明されたということが画期的。

組織文化

• 創造的な組織（使命や任務の遂行、成果に焦点を絞るパフォーマンス志向の組織で協力関係や信頼関係を重んじる）はデリバリパフォーマンスが高い
• 創造的な組織文化は職務満足度を向上させる(p45)
• リーン(アジャイル)のプラクティスと継続的デリバリと併用することで、創造的な組織文化に近づくことができる(p48)。

逆にデリバリーパフォーマンスが低いと、組織が創造的になることを阻害する要因にもなり得るということ。

継続的デリバリ

継続的デリバリが本著において中心的なケイパビリティになっている。継続的デリバリとは具体的に下記のようなものを指す

• バージョン管理
• デプロイ自動化
• 継続的インテグレーション
• トランクベース開発(なるべくmain branch、またはそれに近いところで開発する)
• テスト自動化
• テストデータの整備
• セキュリティのシフトレフト
• 疎結合なアーキテクチャ
• チームに権限があること
• モニタリング
• プロアクティブ(予防的な)通知

継続的デリバリを実施している組織は当然デリバリパフォーマンスが向上するが、それ以外にも強い相関関係を持っているケイパビリティとや効果としては以下のようなものが挙げられていた(p60)。

• 帰属意識が強い
  • 一見継続的デリバリと帰属意識に何の関係があるのか想像しにくいし、明確に書かれているわけではないので予測にすぎないが、継続的デリバリを実現する条件や価値観として、「必要な権限があること」や「全員が責任を負う」、「改善努力を継続的に行う」があるので、それが影響しているものと思われる。
• 創造的な組織文化が浸透している
• デプロイ負荷の軽減
• チームのバーンアウト（疲弊）の軽減
  • 後ほど出てくることになるが、リリースのたびに承認申請などの手続きがあり、かつバグや障害が発生しないことを祈る
  • そのことによって、「あ〜リリースできた〜」となり、疲れがどっと溜まり、それによって次の仕事への切り替えがしにくくなることを指して「燃え尽きた状態(バーンアウト)」と言っていると思われる。

アーキテクチャ

ハイパフォーマーとの相関関係が強い事実とのこと(p75)

• テストの大半を統合環境を必要とせずに実施できる＝テスト容易性
• アプリケーションを、それが依存する他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできる=デプロイ容易性

テスト容易性とデプロイ容易性を成立させるためにはシステムが疎結合である必要がある。テストとデプロイの自動化よりも大事なこと＝チームとアーキテクチャが疎結合であること(p76)。具体的には以下のような状態。

• チーム外の許可を得なくてもリリースできる
• チームが自分たちの裁量と権限においてリリースできる(リリースにおいて他チームへの依存度が低い)
• 他のチームとやり取りすることなくリリースできる
• リリースの対象となるサービスが依存するサービスを気にすることなくリリースできる
• リリースの対象となるサービスが依存するサービスを気にすることなくテストできる
• 最小限のダウンタイムのみでデプロイできる

そして疎結合なアーキテクチャだと技術系部署をかなりの規模までスケールでき、生産性が格段に向上することができているとのこと。一般的にはチームの開発者数を増やすと、コミュニケーション量のオーバーヘッドが増えるため、開発者一人あたりの1日のデプロイ件数は減るというのが主流な見方だがハイパフォーマーな組織だと、開発者数に対して2次関数的に開発者一人あたりの1日のデプロイ件数は増えるとのこと(p78)

その他

他にもセキュリティのシフトレフトやリーンとの関係性、従業員満足度やリーダーシップとの関係性の話も展開されていて非常に勉強になった。特にシングルポイントとして、リーダーシップ・マネジメントがDevOpsを理解し、支援できていないとうまくいかない、という話は最もだと思った。

その他の気づき/得たこと

成熟度とケイパビリティ(p9-10)

• ソフトウェアを迅速かつ確実にデリバリするためには、成熟度(matuarity models)が使われることが多かった
• しかし、成熟度モデルは組織やエンジニア個人が段階的に成熟していく前提に立っているが、開発チームの置かれている状況は刻一刻と変化し、要求されるものも変わるため柔軟に対応ができない
• ケイパビリティモデルは「多次元かつ動的」であるため、チームの状況によって柔軟に必要なケイパビリティを組み合わせて取り入れることができる
• 成熟度モデルは成熟することが目的化してしまうが、ケイパビリティモデルは成果を上げることを目的としている

texta.fmで言ってたこと

• 著者のGene KimとJez HumbleはDevOpsの重鎮
• 和田卓人氏曰く、2000年代の巨人がKent BeckやMartin Fowlerならば、2010年代の代表選手は彼らと言っても過言ではない
• 具体的には下記の書籍が紹介されていた
  • 継続的デリバリー
  • The DevOps ハンドブック 理論・原則・実践のすべて
• 2000年代はアジャイルのなかでは、ビジネス寄りがスクラム、技術寄りがXPみたいな構図だった
• その後、スクラムの人口がどんどん増えていき、継続的デリバリのようなXPのプラクティスはやや下火になってしまった
  • 私見だとスクラムの方がとっつきやすかったのかな
  • XPだと「顧客が開発現場に毎日同席していること」みたいな厳しめの原則もあったし
  • でも今考えるとXPのほうがよっぽど分かりやすい。技術的なプラクティスが多いから、スクラムよりも出来てる/出来てないが明確。
  • スクラムは振り返り会とかスプリント計画をやってても、「そのやり方じゃダメだ」みたいのが多すぎる
• XPも「まあ継続的デリバリとかTDDやったほうがいいよね。効率的だし、エンジニアも開発に専念できるし」というスタンスだったが、根拠に乏しく、「やってる人にしか旨味が分からないプラクティス」みたいになってしまっていた
• ところがAmazonのようなクラウドプラットフォームが台頭し、DevOpsの概念が生まれた。(ちなみにどこかで見たけどDevOps以前にGoogleはSREを提唱してた気がする？)
• DevOpsは開発者とシステム運用者の利害(開発者は新しいもの作りたい。運用者はシステムが不安定になるからあんまり新しいことやって欲しくない)の対立を解決する概念として発明される
• DevOpsはXP的価値観を推進させたが、この本はそういったアジャイルの技術的な側面が直接ビジネスや業績にインパクトを与えていることを客観的な事実によって示された
• XPとビジネスをつなぐ回路を作った。スクラム以外で(今となってはスクラムとビジネスの関係性も甚だ怪しくなってきてしまったが)。そういう意味で革新的な著作とのこと。

Jez HumbleはThoughtworksにいたことがあって(つまりKent Beckの元同僚)、今はGoogleでSREやってるんですね。他にも面白そうな本書いてますね。The Agile RevolutionというPodCastでJez Humbleが喋っている回があるので今度聞いてみよう。

その他メモ的なこと

• 本書はPuppet社によるState of DevOps Reportが元になっているとのことですが2020年版も公開されていました。
• DX Criteriaも見てみよう