generated at
Lean と DevOps の科学 Accelerate

Amazon で購入 : https://amzn.to/2LRWWFk
読書開始 : 2019-10-07
読書終了 : 2019-10-23

本書の目的 : 研究結果を共有することで、組織がより高品質なソフトウェアをより迅速にデリバリできるようにすること、より健全なチームを育成して他者の追随を許さない存在に成長することを支援すること、そして組織全体とその構成員の幸福繁栄の後押しをすること
Martin Fowler 氏の寄稿
本書は素晴らしいものではあるが、読むうえで注意を要する点もある :
確証バイアスではないか? というのはある (あくまで現時点では)
本書が対象にしているのは、ソフトウェア開発のうちデリバリに限られている (コミットから本番稼働まで)
Courtney Kissler 氏の序文
技術変革を 「学びを重視する組織の育成」 ではなくてプログラムの一種とみなしてしまったというような落とし穴
首脳陣の支援の重要性。 最高幹部は学びを重視する姿勢を前面に打ち出して模範行動を率先して取る必要がある

1 部 調査結果から見えてきたもの
1 章 業務を加速させるということ

2 章 開発組織のパフォーマンスを測定
> 「ソフトウェアデリバリのパフォーマンスは組織全体の業績に重要な影響を及ぼす」 という事実は、自組織の事業にとって戦略上重要なソフトウェアの開発能力を自組織の中核的要素として位置付けずに外部委託することへの強力な反証となる。
ソフトウェアデリバリのパフォーマンスを計測できる尺度が持つべき 2 つの特徴
グローバルな成果に焦点を当て、チーム同士の競争や対立といった状況を防ぐ機能
従来の古典的なやり方 : 処理量の多い開発者と安定性向上に寄与した運用担当者を褒賞 → 混乱の壁 (wall of confusion)
生産量ではなく成果に焦点を当てる
組織レベルの目標達成に役立たない 「忙しいが価値のない見せかけの作業」 をやめるべき

3 章 組織文化のモデル化と測定、改善の方法
文化 (カルチャー) は重要だが、形のないものなので定義やモデルが様々
本書では、明確に定義され、有効に測定でき、予測効果を発揮できるモデルとして Ron Westrum が定義したモデルを採用

4 章 技術的プラクティス

5 章 アーキテクチャのキーポイント
重要なのは、デプロイテストの容易性 (これらを実現しているチームはハイパフォーマーである可能性が高かった)
これらの特性を持たせるには、システムが疎結合である必要
2017 年の調査では、担当チームが他チームへの依存なしにテスト・デプロイ・変更を行えることが重要だとわかった
チームとアーキテクチャが疎結合 → 逆 Conway 戦略

6 章 デリバリライフサイクルに情報セキュリティを組み込む
DevOps という言葉にはテストや製品管理やセキュリティが含まれていないが、それらの考慮も必要
特にセキュリティ
名称を変える動きもある → DevSecOpsRugged DevOps

7 章 ソフトウェア管理のプラクティス
リーンマネジメントのプラクティス

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

9 章 作業を持続可能にする
継続的デリバリーデプロイ関連の負荷を軽減

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

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

2 部 調査・分析方法
第 1 部の研究結果を出すための調査や分析の方法について

3 部 改善努力の実際
16 章 ハイパフォーマンスを実現するリーダーシップとマネジメント (Steve BellKaren Whitley Bell)
オランダING の例
事業部門ごとの多次元的なマトリックス組織に移行
バリューストリームを把握しやすくなった
構成
関連する製品やサービスを提供するトライブ
トライブを構成する、自律的に業務を遂行するスクワッド
各スクワッドはプロダクトオーナーが主導
IT 関連のスクワッドであれば、IT 分野のリードが主導
スクワッドには “two-pizza team” ルールを適用
多くの場合、スクワッドにはマーケティング担当者も含まれる
BizDevOps と呼ぶ
同じ専門分野のヨコの繋がり : チャプター
専門人材センターもある
「文化をどう変革するか?」 ではなく 「どのように学ぶか? どう確立すればよいか?」 を考えるべき