工程A、Bがあった場合、Aの生産性が上がってもBの速度が律速になることがある。
工程のクリティカルパスの生産性の向上が必要
一方で、全体のプロセスの見直しによってA,Bの依存関係を解消する効率化も可能
多能工化・多工程持ちにすることで、エンジニアを様々な工程に自由に再配置することで全体の効率を上げることも論理的には可能だが、学習曲線を考えると再配置による効率の低下は一定レベル起きる。
一定規模を超えた組織生産(たぶん50〜100以上)において、単工程の改善の占める効果割合は下がっていく
この工程上の複雑度がいわゆる「技術負債」の根底にある

Googleの収益源の多くはインターネット広告によっており、Googleにとってより多くの情報がインターネット上で行われる未来は都合が良い。それがGoogleプラットフォーム上であればなお良い。（今後どうかはなんとも言えないけど）
Googleが開発するChrome、Android、Pixel、GSuiteのすべては、インターネット上により多くの情報を集中させる未来をつくることにつながる戦略投資であるとも言える。
Googleのインフラへの投資は、世界中のデータをインターネットにあげて参照可能にすることで、よりインターネット市場を拡大させることに寄与している。それは、巡り巡って自社の利益に還元される。（情けは人のためならず）
AI技術はGoogleにとっては大量のデータを人間が参照可能なように検索・要約・提示するための不可欠な技術であり、投資するのは妥当であった。IT企業がGoogleと同様の投資をAIにすべきかはそれほど明らかではない。
5年〜10年をかけた戦略投資をするのであれば、市場へのインパクトを前提とし、インパクトを与えた市場が自社にとって都合が良い未来になっているという絵を書く必要がある。

Googleのソフトウェア・エンジニアリング

Goal：望ましい結果。特定の指標に結びつかないようにする。街頭効果（見える範囲を探しても望む結果は得られない）を防ぐ。トレードオフを入れる。（速さと品質、など）
Signal：ゴールを達成したことを知る手段。
Metrics：シグナルをどう計測するかを決定する。シグナルと同じではない。計測できる代用品である。

SignalとMetricsの違いは、測れるかどうか。計測可能性と正しさのトレードオフをSignalとMetricsで表現している。SignalはGoalを測るために達成すべき条件、MetricsはSignalを計測可能にするため代替品。Signalは妥当なコストで計測可能であるとは限らない。
Signalを計測するためのMetricsは複数あるかもしれない。複数あるMetricsが矛盾する可能性もある。それはあくまでMetricsがSignalの代替品であるため。その場合、Metricsを再検討すべきかもしれない。
重要なのは追跡可能性を維持すること