そもそもDevOpsの手法は「安全で障害耐性が高く、急速に進化できるスケーラブルな分散型システムを構築するためにはどうしたらよいの？」という難題を抱えた、少数の組織から生まれてきた手法である。
競争力の維持を望む組織は、この難題の解決法を習得しなければならない。

第2章

ベロシティは絶対的ではなく、チーム依存の相対的な尺度であるため、生産性の測定基準にする手法としては難点がある。
また、ストーリーの完了に要する時間や人数の見積もりを水増しすることでベロシティを悪用することができる。

混乱の壁：開発チームは質の悪い行動をこの壁越しに運用チームに丸投げし、運用チームは運用チームで修正を阻む手立てとして、手間のかかる変更管理プロセスを打ち立てる。つまり、組織間で足を引っ張っている状態のことを指す。

リードタイムの削減とデプロイの頻度は共にリーン手法の文脈である。
主にこの2つの指標はフィードバックサイクルを高速化させるためのものである。

第3章

組織文化のモデル化にはWestrumモデルが利用されているが、この中で必ずしも全ての場合で「創造的な組織」が正しい、とはならないことに留意する。
例えば、官僚的な文化が強固な画一性を生み、状況によってはそれが良い方向に流れることもあるからだ。

Googleでの広範的なインタビューの結果、「 チームの個々のメンバーの素養よりも、各メンバーが他の関係者と如何にやりとりし、作業をどう構成し、チームに対する自身の貢献をどう捉えるかの方が重要」とあり、"個人力"よりも"チーム力"が有能なチームになるためには必要ということがわかった。

第5章

疎結合アーキテクチャを実施することで、開発者の人数と比例してデプロイ頻度が上がり、チーム全体の作業速度が加速される（一般的にはコミュニケーションコストが増えて鈍化する）

第8章

ソフトウェアデリバリーのパフォーマンス向上が行われることで、ユーザリサーチの実施が促進され、リーン製品開発のプラクティスとの好循環が生まれる。そして組織の成果も向上される。

第9章

「技術的プラクティスとリーン思考プラクティスが出来ているとバーンアウトが緩和する」とあるが、そもそもそれらを実践できる土壌がバーンアウトを緩和させているのでは？と思ったりした

リーンマネジメントの一つに「作業担当者の自身の作業を改善するためのリソースも提供する」というものがあり、これにより自身の作業に対して意思決定がなされ、作業に対しての付加価値を見出すことができる。Googleの20%ルールもバーンアウトを緩和させる施策の一つと言える。

第10章

従業員の忠誠心と帰属意識は収益性・生産性・市場占有率などのアウトカムの底上げ要因となる。

第11章

変革型リーダーシップはテクノロジーによる変革をもたらすリーダーを指し、チーム能力に影響を及ぼし、組織へのアウトカムへも多大な影響を与える。
サーバント型リーダーシップと違い、部下と組織をフィットさせることに重きを置く。