O’REILLY Learning「Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス」4章〜8章
4章 公正のためのエンジニアリング
卓越したエンジニアであるためには、製品の設計と実装に多様な観点を持ち込むことにも気を配らなければならないということ。
バイアスこそがデフォルト状態である。
5章 チームリーダー入門
Googleでは、2種の異なるリーダーシップ役職が認知されている。
マネージャー（Manager：管理者）は人員のリーダーであり、他方でテックリード（Tech Lead）は技術的取り組みを主導する。
これら2つの役職は、職責は相当異なるが、非常に似たスキルを要する。
エンジニアリングマネージャー
テックリード（TL）
テックリードマネージャー（TLM）
サーバント（servant：下僕）リーダーシップ
「マネージする（manage：管理する）者＝マネージャー」
伝統的なマネージャーは物事をやり遂げる方法を気にする一方で、優れたマネージャーはどんな物事がやり遂げられるのかを気にする（そして、やる方法を見つけるのはチームに任せる）。
移譲する、しかし手は動かす
自分の代わりを探す
波風を立てるべきときを心得る
チームを混沌から守る
チームの上空援護をする
チームがうまくやっているときはそれをチームに知らせる
元に戻すのが簡単なものに「イエス」と言うのはたやすい
6章 スケールするリーダー
全てのトレードオフをより深く理解することより、新しいバランスの取り方の実験を開始できるようになったということ。
アンチパターンは、自分を単一障害点に仕立て上げてしまうこと。
優れたマネジメントの何たるか、つまり、95%は観察と傾聴で、5%はちょうど正しい場所に決定的に重要な調整を加えること。
7章 エンジニアリング生産性の計測
『人月の神話 新装版』より
組織が線形に規模を拡大するにつれて、コミュニケーションのコストは二次関数的に増大する。
Googleでは、メトリクス作成の指針としてGSM（Goals/Signals/Metrics：ゴール／シグナル／メトリクス）フレームワークを用いている。
QUANTS
コード品質（Quality of the code）
エンジニアの注意（Attention from engineers）
知的複雑性（Intellectual complexity）
テンポと速度（Tempo and velocity）
満足（Satisfaction）
第3部 プロセス
8章 スタイルガイドとルール
ルールは法である。ルールは単なる提案や推奨ではなく、厳密で強制的な法だ。
Google Style Guide
https://google.github.io/styleguide/
ルールを設置することのゴールは、「良い」行動を促し、「悪い」行動を思いとどまらせること。
一貫性の優位性