読みにくい本だ…。それほど目からウロコでもないような話題をタラタラタラタラ、翻訳書独特のの長ったらしい文章で説明し、「章タイトルは【最初に手をつけるバリューストリームの選択方法】なんだけど、バリューストリームのカテゴリの話ばかりして選択方法の話が出てこないぞ…」こんなのばっかりで、「これ何の話だったっけ？」と戻り読みすることが多くなかなか先へ進まない。
理想はそうなんだけどさー、どうやって実現にこぎつけりゃいいのよ？ケーススタディとやらも「日常業務の一部として問題を見つけ、修正していくことで、技術的に負債をマネジメントしていった」みたいな抽象的記述ばっかりで、いやいやクソ忙してくてそれどころじゃない職場で具体的にどうやってそれ進めたのか知りたいんだけど、という気持ちになりイライラして読むのが止まる。全然先に進まない。
p. 167 【第9章 デプロイパイプラインの基礎の構築】ほとんどすべての場合において、コードよりも環境のほうが帰られる設定が何桁分も多いからである。そのため、もっともバージョン管理システムが必要なのは環境なのだ。
→「修理するよりも再構築するほうが簡単なインフラストラクチャを作る」につながる。
“イミュータブルインフラストラクチャ”＝本番環境に対する手作業の変更はもはや認められない。本番環境に変更を加えるときは、変更をバージョン管理システムに格納し、ゼロからコードと環境を作り直す以外の方法は許されない。そうすれば、本番環境に差異が紛れ込むことは絶対になくなる。
p.181 【第9章 デプロイパイプラインの基礎の構築】継続的インテグレーションの実践に必要な3つ
・デプロイできる状態になっていることをチェックする包括的で信頼性の高い自動テストセット
・チェックのためのテストが失敗したときには「生産ラインを全面ストップする」文化（＝アンドン）
・寿命の長い機能ブランチではなく、トランクに小規模な変更を加えていくデベロッパー
p.185 【第10章 高速で信頼性の高い自動テストの実現】理想的な自動テストピラミッドは、大半のエラーをユニットテストで見つけられることである。インテグレーションテストや受入テストでエラーを見つけた場合、デベロッパーに返すフィードバックは桁違いに遅くなる。そして、インテグレーションテストは希少で複雑なインテグレーションテスト環境を使うため、この環境を同時に使えるチームは1つだけに限られたりして、フィードバックはさらに遅くなってしまう。
しかし、多くのテストプログラムは、マニュアルテストやインテグレーションテストに重点を置いており、これとは逆になっている。
p.237 【第12章 自動化とローリスクリリースの実現】「継続的インテグレーション ⊃ 継続的デリバリー ⊃ 継続的デプロイメント」
・継続的インテグレーション： ビルドが成功したら自動的にインテグレーションテストが実行される状態
・継続的デリバリー： トランクがいつでもオンデマンドでデプロイ可能な状態
・継続的デプロイメント： 以上に加え、最後のステップ（本番環境へのデプロイ）まで定期的に行っている状態
p.309 【第16章 フィードバックループおｗ実現して開発と運用が安全にコードをデプロイできるようにする】最初の段階では本番サービスをデベロッパーに管理させる。運用エンジニアに移管後、本番サービスが十分脆弱になってきたら、運用は本番サポートの職務を開発に返上（サービスハンドバック）できるようにする。
こうしたフィードバックループを作ると、本番環境へのデプロイが安全になり、開発が作るコードが本番環境により適したものになる。そして、共通の目標や責任を強化し、共感を強めるように仕向けていけば、開発と運用の間により協力的な関係を築くことができる。
p.336 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】テストが失敗すると、私たちはとかくもっとテストをしようとする。しかし、プロジェクトの終わりの時期にただテストを増やすようなことをすると、かえって結果が悪くなることがある。特に、増やしたのがマニュアルテストだと弊害が起きやすい。デプロイのバッチサイズが大きくなり、変更の成功率が下がり、インシデントの数が増え、MTTRが長くなる。つまり望んでいるのと逆の結果になるということは、理論からも実践からもわかっていることである。
変更凍結期間を設定してバッチサイズの大きい変更をじっくりテストするよりも、スムースで継続出来な本番デプロイのフローの一部としてテストを日常業務に完全に組み込み、デプロイの頻度を上げるようにしよう。そうすれば、作業に品質を組み込み、もっとバッチサイズの小さい変更をテスト、デプロイ、リリースできる。
p.333 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】ピアレビューでもバッチサイズは小さく保つ。変更のサイズが大きくなると、変更に対して意味のある批評を加える能力は下がっていく。「プログラマーに10行のコードのレビューを頼むと10個の問題点を見つけてきますが、500行のコードのレビューを頼むと、まあいいんじゃないと言われるでしょう」
p.342 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】官僚主義的なプロセスを大胆に取り除く。終わるまで何ヶ月もかかる承認プロセス＝ウォーターフォールのこと。
p.355 【第19章 日常業務での学習の実現と日常業務への学習の注入】 避難なしのポストモーテムイーティングにおいて「もっと注意する」「もっと愚かでないようにする」という対応策は認められない。この種のエラーが再び起きるのを妨げる本物の対応策を生み出さなければならないのである。
そのような対応策として考えられるのは、デプロイパイプラインの危険な条件を検出する新しい自動テストの導入、遠隔測定の追加、ピアレビューを追加しなければならない変更タイプの確定、定期的に設定されたGame Dayに実施される同じタイプのエラーのリハーサルなどがある。
