[読書] リーンとDevOpsの科学

リーンソフトウェア開発 DevOps

読んだ本


LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加速する

モチベーション

texta.fm #5 で紹介されていて、かなり評価されている本として有名、ということで知りました。
t-wadaさんの「質とスピード」という有名なスライドがありますが、その裏付けのもととなる内容がまとめられているという位置づけでこの本を捉えていました。

理解メモ(復習)

クイックリファレンス：パフォーマンスを改善する効果の高い24のケイパビリティ

#	カテゴリ	ケイパビリティ
1	継続的デリバリー	バージョン管理
2.	^	デプロイの自動化
3.	^	継続的インテグレーション
4.	^	トランクベースの開発
5.	^	テストの自動化
6.	^	テストデータの管理
7.	^	情報セキュリティのシフトレフト
8.	^	継続的デリバリ
9.	アーキテクチャ	疎結合のアーキテクチャ
10.	^	チームへの権限の付与
11.	製品とプロセス	顧客フィードバック
12.	^	業務プロセスの可視化
13.	^	作業の細分化
14.	^	チームによる実験
15.	リーン思考に即した管理と監視	負担の軽い変更承認プロセス
16.	^	事業上の意思決定における、アプリケーションとインフラの監視結果の活用
17.	^	システムの健全性のプロアクティブなチェック
18.	^	WIP制限によるプロセス改善と作業管理
19.	^	作業の可視化によるプロセス改善と作業管理
20.	組織文化	Westrum推奨の創造的な組織文化
21.	^	学びの支援
22.	^	チーム間の協働
23.	^	職務満足度
24.	^	改善を促進するリーダーシップ

はじめに

2013年にデリバリの継続の効果を測りはじめた。
慣例上、学問の世界しか用いられてこなかった厳格な研究手法を用いて、ソフトウェア開発への効果を証明することを目標にした
適用したのはクロスセクション分析法
アンケート
- 23000件
- 2000社=スタートアップから先端IT企業まで
- 規制の厳しい業界〜レガシーコードを保守する企業も対象
2つの目的
- ハイパフォーマンスな技術組織を生み出す原因は何か
- ソフトウェアは組織をどのような形で改善しうるのか
執筆の4年間の進捗
- 2014年：デリバリおよび組織のパフォーマンスを把握するための基盤づくり
- 2015年：調査研究の分析の深化と拡充
- 2016年：新たな技術プラクティスの分析の拡充、アップストリーム側への拡張
- 2017年：アーキテクチャ、指導者の役割、非営利組織の成功度

第一部.調査結果から見えてきたもの

第1章. 業務を加速させるということ

リードタイムの長い開発は敬遠され、小規模なチームで短期開発、サイクルを回すようになった
以下のようなことが背景であり、どの会社にも当てはまる
- 顧客を満足させる
- マーケットとのエンゲージメントの強化、顧客理解の促進
- コンプライアンス、倫理規制の対処
- セキュリティ、政治経済情勢などの潜在リスク
ソフトウェアはその中核を担う。現在はテクノロジーの活用のほうがビジネスに影響を及ぼす
DevOpsは、上記を背景に生まれ、プラクティスやケイパビリティで構成される
成熟度ではなく、ケイパビリティに焦点を
- 以前は、目標設定に成熟度モデル=CMMIが使われていた。これをケイパビリティに置き換えたい
- ケイパビリティは、世の中が絶えず変化していくことを前提に、継続的な改善を行って進歩していくことを考える
ケイパビリティモデルでは、焦点を当てるべきケイパビリティをどうするかが問題になる
- ケイパビリティを選定するためにはエビデンスが必要。本書はそのエビデンスを上げるために作った
DevOps採用の価値
- プロセスが重要であり、プロセスを良くできれば、ソフトウェア開発の速度も質も高められる

第2章. 開発組織のパフォーマンスを計測

従来の指標には以下のようなものがあった
- 書いたコードの量
- 速度
- 利用量(稼働率のこと？)
書いたコードの量ではなく、質を測りたい
アジャイル開発ではベロシティを使うが、これをチームの生産性として評価すると良くない。本来のベロシティの目的にフォーカスできなくなる
ソフトウェアデリバリの尺度に必要なもの
- チーム同士の競争や対立を助長しない
- 生産量ではなく、成果に焦点を当てる
以下の尺度が望ましい
- リードタイム
- デプロイ頻度
- サービス復旧の所要時間
- 変更失敗率
リードタイム(顧客からリクエストが来た時刻から、その機能を実際に提供するまでの時間 by リーン開発手法)には2つ要素に分解できる
- 製品の設計と開発
- 納品にまつわる作業
製品の設計と開発は、粒度の統一が難しく不確実性も大きいので、測るのが難しい。今回は、コードのコミットからデプロイまでの時間をアンケートで測った。
もう一つ測りたい尺度にバッチサイズ(一度に進める作業のサイズ)という尺度があり、これもリーン手法の目玉
バッチサイズを小さくすると、さまざまな指標も合わせて小さくできる
バッチサイズを直接測るのは難しいので、「デプロイ頻度」を使って、それを間接的に測った
品質を犠牲に速度をとったのか、実際の品質を測るために、MTTRと失敗率を使った
これらをクラスター分析によってグループ分け
ハイパフォーマは、速度も品質も良いと言う結果になった

第3章. 組織文化のモデル化と測定、改善の方法

統計的な検証をもとに文化とパフォーマンスの相関を立証した → 13章を参照
情報の流れがスムーズな組織がハイパフォーマンスだとWestrumで断言している
それに必要な文化は以下
- すべての構成員の間で信頼関係と協力関係がある
- 質の高い意思決定が下せる組織であること
  - より良い選択をするだけでなく、悪かったときに簡単にそれを覆せる
- チーム内外で協働体制が整っている
Google2015
- 変化の時代の中で革新力と柔軟な弾性力が必要
- Googleの調査結果では、個々の能力よりもチームワークがパフォーマンスに大きな影響を及ぼすという結果に
- パフォーマンスの良い組織は、誰か一人の失敗によりインシデントが起きるという考えをせず、組織全体の仕組みに原因があるという風に考える文化があった
Shook2010:関係者の思考方法ではなく、関係者の行動を変えることで文化を根付かせる。
5つの基本原則を柱とする
1. 品質の概念を生産工程の最初から組み込んでいく。（Wエドワーズハミングは品質向上実現を検査に依存するのをやめよと説いている）
2. 作業はバッチ処理で進める。継続的デリバリに必要なコストを抑えて、小さく素早く検証できるようにする
3. 反復作業はコンピュータに任せて人間は問題解決にあたる。
4. 徹底した改善努力を継続的に行う。
5. 全員が責任を負う。

第4章. 技術的プラクティス

継続的デリバリには3種の基盤が必要
- 包括的な構成管理:CM。バージョン管理で収集した情報のみを使い、完全に自動化
- 継続的インテグレーション:CI。
- 継続的テスト。早さを支える上では必要不可欠
継続的デリバリの効果（リッカート尺度で以下のケイパビリティを測定）
- バージョン管理:アプリケーションコード、システムコンフィグレーション、ビルドスクリプト、コンフィグレーションスクリプト
- 質の高いテストの自動化
- デプロイの自動化
- 継続的インテグレーション
- 情報セキュリテイの早い段階からの実施(シフトレフト)
- ブランチの寿命
- テストデータの効果的管理
問題発生を察知するためのツールの導入、またはそのツールを開発するための時間と資源を開発者に与えること
以下の2つの効果により、さらに品質が高まり、良い文化も形成されることがわかった
- デプロイ関連の負荷を軽減する
- チームのバーンアウトを軽減する効果
品質は主観的なので、測定しづらいが、以下には継続的デリバリに高い相関性が見られた
- 変更失敗率
- 質とパフォーマンスに対する知見
- 修正作業と予定外の作業にかかる時間
- 不具合の修正にかかった時間の割合
そもそもやるべきことに集中できるというのは、品質を高める
継続的デリバリのプラクティス
- バージョン管理
- テストの自動化
- テストデータの管理
- トランクベースの開発
- 情報セキュリテイ

第5章. アーキテクチャのキーポイント

アーキテクチャがもつ2つの特性に注目すべき：デプロイとテストの容易性
- テストの大半を、統合環境と必要とせずに実施できる
- アプリケーションを、それが依存する他のアプリケーションからは独立した形で、デプロイまたはリリースできる
これを満たすには、システムが疎結合でなければならない
- チーム外の人物の許可がなくても、対象システムに大幅な変更を加えられる
- 対象システムの変更作業で他チームに頼ったり、他チームに相当量の作業を課したりすることなく、対象のシステムに大きな変更を加えられる
- それにはチーム内でシステムの設計、開発、テスト、デプロイ、運用を行うスキルがないといけない
逆コンウェイの法則。システムを疎結合にしたいので、組織を疎結合にする
テストダブル=モックにより、サービスやコンポーネントを独立した形でテストできる
疎結合のアーキテクチャにはスケーリング促進効果も
- 作業のテンポと安定性が向上し、バーンアウトやデプロイ関連の負荷が軽減されてデリバリーのパフォーマンスが向上する
- 技術系部署をかなりの規模まで拡大でき、生産性も規模に応じて高められる
- ハイパフォーマーでは規模が大きくなるとデプロイ頻度が上がる
効果的なアーキテクチャを生み出す要因
- 必要なツールをチーム自らが選択できる
- 使い手が使う気にならないツールやテクノロジーを使わせるのは不適切
- より良い結果を出せるツールやテクノロジーをエンジニアに提供すべき

第6章. 情報セキュリティのシフトレフト

DevOpsムーブメントの本来の目的は、開発チームと運用チームがサイロ化して非難し合うのを避けること
特に情報セキュリティの担当のチームは距離感が浮き彫りになりがち
始めから情報セキュリティの対策を入れておくとデリバリーのパフォーマンスが向上するだけでなく、セキュリティの質もあがる

第7章. ソフトウェア管理のプラクティス

リーンマネジメントのプラクティス
- WIPの制限
- 数値指標の一覧の可視化と目標
- データに基づく意思決定
負担の高い変更管理プロセス
- CABなどの承認プロセスが常に必要な組織はパフォーマンスが悪かった。
- 変更管理プロセスと変更失敗率の相関性はなく、むしろ向上しないことが判明
- 細かいコードの修正を見ても、CABなどチーム外の人にはわからない
- この結果を踏まえて、コードレビューやペアプロによる軽い承認プロセスと、デプロイメントパイプラインによるハレーションの探知をすべき

第8章. 製品開発のプラクティス

リーン製品開発のプラクティスのパフォーマンスの相関性など。

第9章. 作業を持続可能にする

デプロイ関連の負荷
- 本番環境にプッシュするときの恐怖感=デプロイ関連の負荷(ペイン)
- 迅速かつ安定的にソフトウェアをデリバリーできるようなれば、本番環境へのプッシュにともなうストレスや不安を減らせる
- 要因1：環境に依存しており、容易性が考慮されていない
- 要因2：手作業が多い
- 要因3：引き継ぎが大変
バーンアウト
- 単なる燃え尽きではなく、学習性無気力
- 個人の是正に取り組むのが大半だが、環境を是正する方がはるかに楽
バーンアウトの対処方法
- 組織文化=非難や責任追及ではなく、失敗を奨励する
- デプロイ関連の負荷を軽減
- 指導力の影響力
- 組織レベルの投資=スキル習得を推奨
- 組織のパフォーマンス=時間的余裕

第10章. 従業員の満足度、アイデンティティ、コミットメント

従業員ロイヤルティ
- eNPS: employee NetPromoter Score:推奨者正味比率
- NPSの測定方法は、「アンケート:あなたが自分たちの会社・製品・サービスを友人や同僚に推奨する可能性はどの程度ですか」
IT業界における多様性
- マイノリティがいる割合の高いチームほど、パフォーマンスに優れている
- 女性や少数人種がとても良い影響を与えている統計がでた

第11章. 変革型リーダーシップとマネジメントの役割

Rafferty and Griffin 2004の変革型リーダーモデル
- ビジョン形成力
- 心に響くコミュニケーション能力
- 知的刺激
- 支援的リーダーシップ
- 個人に対する評価
デリバリーパフォーマンスとの相関性が高い
リーダーシップは間接的な影響力がある
部門横断型の協働、学習環境、ツールを促すとハイパフォーマンスにつながる

第二部.調査・分析方法

分析法の種類
- 本書は、記述論的分析、探索的分析、推計予測的分析 + 多変量解析で実施
計量心理学入門
アンケート調査を採用する理由
- データの収集と分析を素早く行える
- システムデータを用いたシステム全体の測定は困難である
- システムデータによる完全な測定は困難である
- アンケート調査によるデータは信頼できる
- アンケート調査によってしか得られないデータがある
データの収集方法
- サンプルの母集団をDevOpsに関心のあるユーザーにした
- CIやIaCという用語はバイアスや社内文化の違いが起きるので、あえてつかわなかった
- カンファレンスなどでレビューしてもらい、公正におこなった

第三部.改善努力の実際

ハイパフォーマンスを実現するリーダーシップとマネジメント
- オランダのINGのケーススタディ
高いパフォーマンスを生むプラクティスの一覧
これが高いパフォーマンスをうむ文化なのではなく、自分たちで作り上げていくことが大事
- 自分自身も変革していくこと
- 自己管理を徹底すること
- 忍耐をいとわないこと
- プラクティスを実践すること

感想

正直にいってしまうと、あまりよくわからなかったですw。
- そもそもリーンもDevOpsもよくわかっていないので、まずはそこからスタディしていかないとダメかなと。
- いろいろと一通りスタディしたあと、もう一度あとで読み直したいと思います。
ざっくりと、理解したところだとこんなところでしょうか。
- ハイパフォーマは、速度も品質も良い
- この状態になるためにとるべき指標は、24のケイパビリティ
- なぜこのケイパビリティが重要なのか科学的な根拠は、ゴニョゴニョ...
先日資格をとったITIL4は、従来のITIL3からDevOpsの影響を大きく受けているとのことでしたが、たしかに矛盾する点は少ないように感じました
- ただし、「変更実現」のプラクティスには、CABなどの話があり、やはりITIL4では厳格に管理する印象がありました。
- DevOpsの「細かいコードの修正を見ても、CABなどチーム外の人にはわからない」→ 「変更失敗率との相関性はなく、むしろ向上しない」というのは競合する部分になりそうかなと。
24のケイパビリティは、この本の出版後も更新が続いているようです。詳しくは、 texta.fm 11. Favorite Technology Surveys。
参考にしつつ、チームでもこの辺の指標をみながら進めていく必要がありそうですね。

今後の展望

リーン開発について、きちんとスタディしたいと思いました。この辺の書籍はすでに積んでいます。
- リーンソフトウェア開発
- リーン開発の現場
DevOps関連ももう少しスタディしたいですね。オライリーのSREの本とか、DevelopersIOのこちらのブログも参考に、いくつか本を読んでいきたいところです。

最終更新日: May 24, 2024