第1条意思決定
タイプ 1／タイプ 2 の意思決定
やり直せる決定にまで、やり直せない決定と同じ慎重さを払ってしまう。
確信の度合いより先に、やり直せるかを問う
カードデッキ
A4 に倍率 100% で両面印刷し（長辺とじ）、薄い線に沿って切る。表が法則、裏が歯止めとどうするか。
第2条安全工学
逸脱の常態化
すぐに害が出なかったルール違反は、いつの間にか当たり前になる。
何も起きなかった例外は、安全の証明ではない
第3条システム
チェスタトンの柵
経緯を知らないコードやルールは無駄に見え、理由も知らずに消したくなる。
理由を知ってから消す。ただし探すのは期限つきで
第4条認知
正常性バイアス
本物の異常を前にしても、人はいつもの無害な説明に飛びつく。
打ち消す前に、本物だったら何が起きるかを考える
第5条組織
パーキンソンの凡俗法則
議論は重要な部分ではなく、誰でも口を出せる簡単な部分に集中する。
議論は、意見の多いところでなくリスクの大きいところに使う
第6条システム
ガルの法則
動く複雑なシステムは、たいてい動く単純なシステムから育ったものだ。最初から設計したものが動くことはまれだ。
一度に全部動かないと動かない設計を疑う
第7条組織
コンウェイの法則
システムの構造は、作るチーム同士の意思疎通の形に似てくる。
アーキテクチャを変えたいなら、先にチームを変える
第8条システム
ハイラムの法則
利用者が十分に多ければ、バグも含めた観測可能な挙動すべてに誰かが依存する。
見えているものは、すべて約束したものとみなす
第9条組織
ブルックスの法則
遅れたプロジェクトに人を足すと、立ち上がりと調整にかかる手間が、増えた人の働きを上回り、かえって遅れがちだ。
遅れたら、人を足す前に範囲か期限を動かす
第3条 チェスタトンの柵
歯止め：期限付きの経緯調査
この規則を絶対視すると何ひとつ消せなくなる。理由を知っていた人がいなくなり、理由ごと失われていることもあるからだ
どうするか
その「柵」（コードやルール）がなぜ立てられたのかを説明できるまで、取り除かない。ただし調べる期限は決めておく。期限が来たら、ロールバックを用意してフラグの裏で外し、どこから苦情が出るかを見る。
第2条 逸脱の常態化
歯止め：エラーバジェット
逸脱がすべて前兆とは限らない。一つ残らず調べるチームは出荷が止まり、やがて調査そのものを無視し始める。許容量を合意しておけば、本物の警報が埋もれない
どうするか
チェックが失敗したまま出荷するなら、誰がなぜ決めたか、いつ見直すかを書き残す。ポストモーテムでは、過去のどの例外のせいで今回が当たり前に見えたのかを問う。
第1条 タイプ 1／タイプ 2 の意思決定
歯止め：隠れた一方通行のドア
やり直せるように見えて実はやり直せない決定は多い（公開 API、ディスクに書いたデータ形式、顧客に告知した価格）。こうした決定を速く通すと、取り消せない約束を世に出してしまう
どうするか
議論の予定を組む前に、その決定がどちらの種類かを見極める。1スプリント以内に、受け入れられるコストでやり直せるなら、一人か少人数が今週中に決める。完全なレビューは、永続化するデータ、公開インタフェース、セキュリティ、顧客にすでに約束したことに関わる決定に限る。
第6条 ガルの法則
歯止め：おもちゃから育てられないシステムもある
決済の元帳、安全インターロック、独立した実装が多いプロトコルは、最初の版から正しくなければならない。こうしたものを本番で育てると、誤った版を本物のお金や人に対して動かすことになる
どうするか
本物の仕事を端から端まで一つこなせる最小の版を出し、動く状態を保ったまま段階的に育てる。書き直しが提案されたら、どの動いているシステムから育てるのかを問う。
第5条 パーキンソンの凡俗法則
歯止め：名前はインタフェースである
議論しやすい小さなことが、後から変えられないこともある。公開 API の名前や設定キーは、議論するのは安いが、リリース後に変えるのは高くつく
どうするか
ツールで決められること（整形、import の順序、lint ルール）は人のレビューから外す。レビューのやり取りがスタイルの話ばかりになったら打ち切り、変更のうち最もリスクの高い部分について一つ質問する。会議では、金額やリスクの最も大きい議題を最初に置く。
第4条 正常性バイアス
歯止め：アラーム疲れ
異常のたびに崩壊の始まりとして扱えばオンコールが燃え尽き、何でもエスカレーションする人はやがて相手にされなくなる。たいていの異常は本当にいつものことだ
どうするか
異常が起きたら、「これがシステム全体の崩壊の始まりだとしたら、この先10分で何が起きるか」を考える。その答えが怖いなら、すぐに調査する。
第9条 ブルックスの法則
歯止め：分割できる仕事
Brooks 自身、この法則を「とんでもなく単純化すれば」と断って述べている。早い段階で、ほとんど意思疎通なしにきれいに分けられる仕事に人を足せば、速くなる
どうするか
プロジェクトが遅れたら、まずスコープを削るか期限を動かす。人を足すのは、きれいに分けられて、ベテランの日々の手助けなしに始められる仕事に限る。それも最後の月ではなく、早いうちに足す。
第8条 ハイラムの法則
歯止め：意図的なゆらぎ
観測できる挙動をすべて不可侵にすると、何も変えられなくなる。約束していない部分は、反復順序のランダム化や計画的な停止のように意図的に揺らしておく。そうすれば依存はそもそも生まれない
どうするか
利用者がいる以上、「内部実装」というものはない。約束した部分はバージョニングと機能フラグで守り、約束していない部分は意図的に揺らして、そもそも依存されないようにする。
第7条 コンウェイの法則
歯止め：まずモノリス
チームごとにサービスを持たせると、分散システムのコストまで抱え込む。組織図がどうであれ、一つのチームが一つのデプロイ単位を持つべき場合もある
どうするか
モジュール化されたアーキテクチャが欲しいなら、先にチームを独立したモジュールとして編成する。組織構造にコードで逆らわない。
第10条認知
XY問題
人は本当の問題ではなく、自分が試している解決策について助けを求める。
質問された手段より、その先の目的を見る
第11条分散システム
ポステルの法則
相手が仕様どおりに動く前提のシステムは、最初の逸脱にもろくなりがちだ。
送るものは厳密に、受け入れる逸脱は明示して
第12条組織
ハンロンの剃刀
疲労や文脈不足で説明がつく遅れやバグに、人は悪意を読み取ってしまう。
悪意を疑う前に、相手に何が見えていなかったかを探す
第13条見積り
ホフスタッターの法則
作業は見積りより長くかかる。それを織り込んで見積もっても、やはり長くかかる。
見積りは、いまの見た目より過去の実績を信じる
第14条インセンティブ
グッドハートの法則
数字を動かすことに報酬がつくと、その数字は実態を測らなくなる。
数字ではなく、数字が表しているはずの結果を見る
第15条システム
リンディ効果
アイデアやソフトウェアは、長く生き残ったものほどこの先も長く残る可能性が高い。
長く使うものは、すでに長く生き残ったものから選ぶ
第16条意思決定
サンクコストの誤謬
すでに注ぎ込んだ分が惜しくて、失敗しているプロジェクトに投資し続ける。
使ったコストではなく、この先の見込みで決める
第17条認知
カーゴ・カルト・エンジニアリング
うまくいった理由を理解しないまま、他社のやり方の形だけを真似る。
その手法が解いた問題を抱えているときだけ真似る
第18条性能
アムダールの法則
ボトルネックが別の場所にあれば、一部を速くしても全体はほとんど速くならない。
何かを速くする前に、ボトルネックを見つける
第12条 ハンロンの剃刀
歯止め：侵害を前提にする
悪意による失敗もあり、攻撃者は正直なミスに見えることを当てにしている。xz utils のバックドア（2024年）は、親切で辛抱強い貢献者が持ち込んだものだった
どうするか
失敗を意図のせいにする前に、その人がその時点で何を見られたかを確かめ、欠けていたものを補う。意図を問題にするのは証拠があるときだけにし、その場合も一対一で話す。
第11条 ポステルの法則
歯止め：堅牢なプロトコルの維持（RFC 9413）
不正な入力を許すと、壊れた送信側がそのまま出荷される。受信側はみな同じ寛容さを真似るしかなくなり、事実上のプロトコルが仕様から離れていく。IAB は現在、寛容さが恒久化しないよう仕様を保守し続けることを設計者に求めており、不正な入力を無視するのはほぼ常に誤った対処だとしている
どうするか
送るものは仕様どおりにする。受け取る側の小さな逸脱は、文書化してログに残すときに限って境界で受け入れ、受け入れをやめる期日を決めておく。
第10条 XY問題
歯止め：聞かれたことに答える
質問者が X をすでに検討したうえで、こちらに説明する義理のない理由で Y を必要としていることもある。毎回問いただすのは相手を見下す態度で、分かっている人の足を引っ張る
どうするか
「Y はどうやるのか」と聞かれたら、手早く答えられるなら Y に答える。そのうえで、何を達成したいのかを一度だけ聞く。
第15条 リンディ効果
歯止め：土台は変わる
年数が示すのは、過去の条件で生き延びたことだ。ハードウェアや規模、脅威モデルが変われば、長く使われてきた選択肢こそが、もうない世界に合わせて最適化されていることもある
どうするか
10年安定して動くシステムが必要なら、すでに10年使われてきた技術を選ぶ（例: 新しい NoSQL より PostgreSQL）。
第14条 グッドハートの法則
歯止め：バランスト・スコアカード
それでも数字なしでは舵を取れない。まとめて操作するのが難しい複数の指標を、仕事そのものと並べて読めば、測るのをやめるよりも長く信号を保てる
どうするか
単一の指標で成果を評価しない。代わりの指標ではなく、システムが実際に出しているものを見る。
第13条 ホフスタッターの法則
歯止め：パーキンソンの法則
見積りに余裕を足しても、その余裕は貯金されない。仕事のほうが膨らんで埋めるので、余裕のある見積りもきつい見積りと同じくらい遅れる
どうするか
見積りは、今どう見えるかではなく、似た過去の作業に実際にかかった時間から出す。期限が危うくなったときに削るスコープは最初に書いておく。終盤だけでなく、マイルストーンを終えるたびに見積り直す。
第18条 アムダールの法則
歯止め：グスタフソンの法則
問題の規模が計算機とともに大きくなるなら、逐次部分の割合は縮み、速度向上は伸び続ける
どうするか
まずプロファイルを取る。時間はたいていコードのごく一部に集中していて、1%のコードが90%の時間を占めることも多い。最適化するのはその部分だけにして、残りは気にしなくてよい。
第17条 カーゴ・カルト・エンジニアリング
歯止め：実績あるやり方
すべてを第一原理から導くと、他人が苦労して得た教訓を捨てることになる。うまくいくと広く知られたやり方を真似るほうが、作り直すよりたいてい安い
どうするか
Google が使っているという理由で道具やプロセスを導入しない。導入するのは、Google があの規模で抱えていたのと同じ問題を自分たちが抱えているときに限る。
第16条 サンクコストの誤謬
歯止め：J カーブ
価値あるプロジェクトの多くは、途中でいちばん悪く見える。最初の谷で何でも打ち切るチームは、何も完成させられない。過去の投資は判断材料にならないが、完成までに残るコストは小さいかもしれない
どうするか
「今日、何も投資していない状態から始めるとしたら、この道を選ぶか」と問う。選ばないなら、やめる。
第19条システム
リーキー・アブストラクション
込み入った抽象化はいずれ、隠したはずの下の層の詳細を露出させる。
抽象化には乗る。ただし下の層を知る人を残す
第20条意思決定
パレートの法則
結果の大半は少数の原因から生まれる。たとえば、バグは一部のモジュールに集中する。
効いている少数の原因を見つけて、そこから手をつける
第21条認知
生存者バイアス
成功例だけから結論を出すと、同じやり方で失敗した例が見えなくなる。
成功例を真似る前に、同じことをして消えた例を数える
第22条保守性
カーニハンの法則
デバッグは書くより難しい。だから、最大限に凝って書いたコードは自分でもデバッグできない。
疲れた他人でもデバッグできるコードを書く
第23条インセンティブ
コブラ効果
問題を減らすための報酬が、問題を増やす行動に報いてしまう。
どの報酬も、問題を解かずに稼ぐ道がないか疑う
第24条組織
ダンバー数
人が安定して保てる関係は150人ほどだ。エンジニアリングではそこから、文脈を共有できる規模を超えると増員分は調整に消えると類推している。
互いの仕事が見えなくなったら、分けどきだ
第25条システム
劣っている方が勝つ
作りやすく広めやすい単純な設計は、正しいが複雑な設計に勝ちやすい。
実装は単純に出し、手間はインタフェースにかける
第26条組織
カニンガムの法則
人は質問に答えるより、間違った答えを訂正するほうに熱心だ。
正解がほしければ、まず自分の答えを出して直してもらう
第27条組織
傍観者効果
問題を目にする人が多いほど、一人ひとりが自分から動く可能性は下がる。
全員の担当は誰の担当でもない。一人を名指しする
第21条 生存者バイアス
歯止め：成功から学ぶ（Safety-II）
失敗だけを調べると、なぜ普段はうまくいくのかを見落とす。たいていは同じ雑なやり方で成功しており、それも証拠になる
どうするか
「X社がこの方法で成功した」を根拠に採用する前に、同じ方法で失敗した企業がどれだけあるかを調べる。死者はブログ記事を書かない。
第20条 パレートの法則
歯止め：ロングテール
小さな原因も数が多ければ、少数の大きな原因を合計で上回ることがある。可用性やセキュリティでは、後回しにしたまれな経路から障害や侵害が起きる
どうするか
品質改善を始める前に、直近の四半期の欠陥やインシデントの件数でモジュールを並べ、上から手を付ける。重要な少数は入れ替わるので、順位は四半期ごとに付け直す。
第19条 リーキー・アブストラクション
歯止め：情報隠蔽
抽象化の利用者のほとんどは漏れに出くわさない。下に何があるかを大半の人が学ばずに済むことが、層を設ける意味だ（Parnas, 1972）
どうするか
抽象化を使って速く進める。ただし、その下の層を理解している人をチームに少なくとも一人置く。
第24条 ダンバー数
歯止め：インタフェースによる協調
部品間のインタフェースが十分に安定していて、ほとんどの人が互いの文脈を必要としないなら、大きな集団でも一貫したシステムを出せる（Linux カーネルには数千人の貢献者がいる）
どうするか
人数ではなく症状を見る。チームの誰もが他の全員の作業内容を言えなくなったり、状況共有の会議が増え始めたりしたら、システムの継ぎ目に沿ってチームを分ける。具体的な人数の上限は、知見ではなく慣習として扱う。
第23条 コブラ効果
歯止め：インセンティブはたいてい効く
報奨金や目標の多くは、意図した方向に行動を動かす。悪用されうるからといって成果に報いなければ、問題の解決に誰もお金を払わないままになる
どうするか
インセンティブを作るたびに、問題を直さずに報酬を得る方法がないかを考える。できるなら証拠ではなく成果に支払い、終わらせ方を先に決めておく。
第22条 カーニハンの法則
歯止め：抽象化の力
凝った版のほうが、短くて正しいこともある。うまく選んだデータ構造やライブラリは、「単純な」手書きのループに残り続ける種類のバグを丸ごとなくせる
どうするか
レビューでは、次のオンコール担当が作者に聞かずにそのコードを説明できるかを確かめる。残す価値のある技巧なら、名前を付け、解説へのリンクを置き、振る舞いを固定するテストを足す。
第27条 傍観者効果
歯止め：単一障害点
毎回一人を名指しすると、その人がボトルネックになり、いなくなれば止まる。担当者は対応を調整する役であって、全部を自分でやる役ではない
どうするか
「誰か見てもらえますか」とは言わない。「@名前 さん、これの調査をお願いします」と名指しで頼む。インシデントには必ず、名前のついた担当者を一人割り当てる。
第26条 カニンガムの法則
歯止め：誤答は残る
訂正が来るとは限らず、その間に誤答は複製され、検索に載る。共有ドキュメントでは、推測は推測だと明記しなければならない
どうするか
ドキュメントがないときは、自分の理解を書いて未確認だと明記し、知っていそうな人に送る。
第25条 劣っている方が勝つ
歯止め：正しいもの（The Right Thing）
Gabriel 自身が対置した考え方。プロトコル、ファイル形式、セキュリティ境界のように後から変えにくいインタフェースでは、先に出すことより先に正しく作ることのほうが大事になる場合がある
どうするか
利用者がその上に何かを作るものは、何年も付き合えるインタフェースを備えた最も単純な版で出す。実装は単純に保ち、手間はインタフェースにかける。
第28条安全工学
マーフィーの法則
時間と負荷が十分にあれば、起こりうる故障はいずれ起きる。
失敗する経路は、いつか通るものとして作る
第29条保守性
ボーイスカウトの規則
コードが劣化するのは、片付けが、めったに実施されないリファクタリングに先送りされがちだからだ。
触ったところは、同じ差分の中で少しだけきれいにする
第30条システム
テスラーの複雑性保存則
システムに本来備わる複雑さは消せない。誰か別の人に移るだけだ。
複雑さは消えない。誰に移したかを把握する
第31条認知
ダニング・クルーガー効果
ある分野に疎い人ほど、自分の能力を過大評価しがちだ。
自信は根拠ではなく、実績を確かめるきっかけにする
第32条認知
知識の呪い
一度知ってしまうと、知らなかったときの感覚を想像できなくなる。
自分の前提は自分には見えない。初めての人に試してもらう
第33条安全工学
スイスチーズモデル
どの防御層にも穴がある。事故は複数の層の穴がそろったときに起きる。
失敗した一層で止まらず、すべての層の穴を見る
第34条性能
早すぎる最適化
計測する前に最適化すると、ボトルネックでない箇所に工数を使ってしまう。
測ってから直す。後で直せない設計だけは先に考える
第35条保守性
リーナスの法則
一人では見つからないバグも、同じコードを見る別の人にはあっさり分かることが多い。
同じ種類のバグが抜けるなら、目を凝らすより違う目を足す
第36条分散システム
CAP定理
ネットワーク分断が起きたら、データストアは一貫性か可用性のどちらかを捨てる。
分断が来る前に、何を諦めるか決めておく
第30条 テスラーの複雑性保存則
歯止め：偶有的な複雑さ
Brooks は複雑さを本質的なものと偶有的なものに分けた。システムが抱える複雑さの多くは偶有的なもので、それは移すのではなく消せる
どうするか
「シンプルな API」がきれいすぎると感じたら、自分が取り除いた複雑さを誰が引き受けたのかを問う。答えられないなら、単純化したのではなく、よそへ移しただけだ。
第29条 ボーイスカウトの規則
歯止め：1つの差分に1つの理由
振る舞いの変更に片付けが相乗りすると、変更そのものが埋もれる。ついでに40箇所をリネームした PR は、誰もレビューしない
どうするか
コードは必ず来たときよりもきれいにして去る。ただし片付けは、同じ差分の中で読み切れる大きさにとどめる。1行のリネーム、分かりやすくしたコメント、使われていない分岐の削除くらいだ。それより大きい片付けは別のコミットにする。
第28条 マーフィーの法則
歯止め：リスクの予算化
考えうる故障すべてに備えると、故障の一部が起きたときの損失より高くつく。故障モードを起こりやすさとコストで並べ、安くてまれなものは受け入れる
どうするか
外部依存、リトライ、タイムアウトはすべて、本番でいつか必ず失敗するものとして扱う。成功パスより先に失敗パスを作る。
第33条 スイスチーズモデル
歯止め：通常事故理論
層は互いに独立しておらず、層を足すたびにその層の相互作用も増える。ある程度を超えると、安全策を一つ足すことは失敗の経路を一つ足すことになる
どうするか
インシデントレビューでは「失敗した一か所」で終わらせない。その失敗を止めるはずだった層をすべて挙げ、なぜその瞬間に各層の穴が開いていたのかを問う。一つの層を直すだけで済むことはまれだ。層同士が互いに独立して失敗するようにする変更を優先する。
第32条 知識の呪い
歯止め：読み手に合わせて書く
何もかも説明する文書では、熟練した読み手が必要な情報にたどり着けない。午前3時の運用担当に必要なのはチュートリアルではなくコマンドだ
どうするか
ドキュメントや公開 API を出す前に、システムを触ったことのない人にその作業を実際にやってもらい、自分は黙って見る。その人がつまずいた箇所が、そのまま書き忘れた前提を示している。
第31条 ダニング・クルーガー効果
歯止め：較正された自信
この効果には異論がある。古典的なパターンの多くは、ノイズの多い自己評価で起きる平均への回帰でも再現できる。だから過信は診断としてではなく、実績を確かめるきっかけとして扱う
どうするか
誰かが難しい問題を「簡単」と言い切ったら、その見積りを信じる前にその分野での実績を確認する。スコープを決める段階では、自信のある新人と口数の少ないベテランを組ませ、口数の少ない側の意見を重く見る。
第36条 CAP定理
歯止め：PACELC / 調整可能な一貫性
分断はまれだ。毎日払っているのは、レイテンシと一貫性のトレードオフのほうだ（Abadi, 2012）。CAP の言葉だけで議論した設計は、平常時を考えていない
どうするか
障害が起きる*前*に、操作ごとに一貫性と可用性のどちらを優先するかを決めておく。分断はいずれ起きる。問題は、そのときシステムがどう動くかだけだ。
第35条 リーナスの法則
歯止め：目は多くても見ていない
公開されていることとレビューされていることは別だ。Heartbleed のバグは2014年に公表されるまで、2年間 OpenSSL の公開ソースに残っていた。コードによっては、気軽に眺める大勢より、報酬を受けた少数の専門家の目が必要になる
どうするか
同じ種類のバグが何度もすり抜けるなら、同じ人がもっと慎重にレビューしても解決しない。視点の違う多くの人にコードを見せる。レビュアーを入れ替え、社内ライブラリを公開し、バグバウンティを実施する。
第34条 早すぎる最適化
歯止め：性能は設計で決まる
性能の一部は初期の設計（データ配置、往復回数、同期か非同期か）で決まり、後からプロファイルしても直せない。そうした判断では、測れるものができる前から速さを考える
どうするか
まず素直なコードを書く。最適化するのは、プロファイラでボトルネックだと確かめたホットパスだけにする。残り97%のクリティカルでないコードは単純なまま残す。次のメンテナーが日々触るのはそこだ。
第37条性能
リトルの法則
安定した系では、系の中にある件数の平均は、到着率と平均滞在時間の積に等しい。
早く終わらせたければ、始める数を減らす
第38条分散システム
二人の将軍問題
信頼できない通信路では、二者は合意できたと確信できない。
送ったことは届いたことではない。再送を前提に作る
第39条組織
ピーターの法則
人は苦手な役職にたどり着くまで昇進し、そこにとどまりがちだ。
昇進は、いまの役の褒美でなく次の役への適性で決める
第40条組織
パーキンソンの法則
仕事は、完了までに使える時間をすべて使い切るまで膨らむ。
終わりの見えない仕事には、短い箱を与える
第41条性能
ヴィルトの法則
ソフトウェアが遅くなる速さは、ハードウェアが速くなる速さを上回る。
ハードの進歩は、使い切らずに守る予算と考える
第42条見積り
90対90の法則
残り1割の作業に、最初の9割と同じくらいの時間がかかりがちだ。
「ほぼ終わり」の先に、同じだけの仕事があると見込む
第43条保守性
イーグルソンの法則
半年見ていない自分のコードは、他人が書いたコードも同然だ。
半年後の、他人になった自分に向けて書く
第44条ヒューマンインタフェース
ヒックの法則
選択肢が増えるほど、人は一つを選ぶのに時間がかかる。
どの選択肢にも、そこにある理由を求める
第45条ヒューマンインタフェース
フィッツの法則
小さく遠いターゲットほど、押すのに時間がかかり、押し間違えも増える。
よく使う操作は近く大きく、危ない操作は遠く小さく
第39条 ピーターの法則
歯止め：人は役職に合わせて育つ
一つ上の職務ですでに実績がある人しか昇進させなければ、誰もその職務を学ぶ機会を得られない。良いマネージャーの多くは、支援と戻り道のある背伸びの役割から育ってきた
どうするか
一番優秀なエンジニアを、褒美としてマネジメントに昇進させない。優秀なエンジニアを一人失ううえに、力不足のマネージャーを生むおそれがある。技術職のキャリアラダーを用意し、候補者は、すでに習熟した職務ではなく一つ上の職務への適性で評価する。
第38条 二人の将軍問題
歯止め：十分な確からしさ
確実さは得られないが、必要になることもまれだ。TCP も決済もあらゆる RPC も、高い確率と後から突き合わせる手段で動いている。証明を待っていたら何もできない
どうするか
「送ったから届いた」とは決して考えない。ネットワークをまたぐ操作はすべて安全に再試行できるようにべき等にし、一往復の結果を信じるのではなく状態を突き合わせる。
第37条 リトルの法則
歯止め：稼働率
仕掛りを削りすぎると到着の合間にサーバが遊び、スループットが落ちる。断った仕事も、どこかで誰かがやらなければならない
どうするか
容量を増やさずに滞在時間を縮めたいなら、始める仕事を減らす。仕掛りに上限を設け、上限を超えた分は捨てるか断るか後回しにする。そうすれば超過分は行列で長く待たされず、すぐに断られる。捨てずに上限だけ設けても、行列は測っていない場所に移るだけだ。
第42条 90対90の法則
歯止め：出せる程度で十分
最後の1割は、やる価値がないこともある。誰も使わない仕上げや誰も踏まないエッジケースは削れる。難しいのは、どれを削るかの判断だ
どうするか
「ほぼ完成」に見えたら、プロジェクトがもう一つ丸ごと残っていると考える。残りの10%にあたる堅牢化、エッジケース、統合だ。誤差として片づけず、スケジュールにはっきり組み込む。
第41条 ヴィルトの法則
歯止め：機械の時間より人の時間
ハードウェアは安く、エンジニアは高い。「肥大」の多くは、機能を数か月ではなく数週間で出すための抽象化だ
どうするか
マシンが速くなって得た余裕は、使ってよい分ではなく守るべき予算として扱う。性能予算を決め、リリースがそれより遅くなったらビルドを失敗させる。
第40条 パーキンソンの法則
歯止め：余裕
いつも最短の箱に押し込まれる仕事には、品質を保つための思考、学習、回復の余地がない（DeMarco『Slack』2001年）
どうするか
終わりの見えない作業には、あえて短いタイムボックスを設け、締切の時点で見直す。期限がきついと、ゆるい期限ならいつまでも先送りできるスコープの判断をその場で下すことになる。
第45条 フィッツの法則
歯止め：意図的な摩擦
ボタンが押しやすくなれば、同じ理屈で誤って押すことも増える。取り消せない操作では、遅くて押しにくいことこそが狙いだ
どうするか
よく使う操作は大きくし、ポインタが今ある場所の近くに置く。破壊的な操作は小さくし、よく使う操作から離して、確認を挟む。画面の端と角はカーソルがそこで止まるので、無限に大きいターゲットに近くなる。だから主要な操作はそこに置く。
第44条 ヒックの法則
歯止め：熟練者の効率
選択肢をメニューや既定値の裏に隠すと、よく使う人のクリック数が増え、機能が見つけにくくなる。熟練者が一度覚えれば済む密な画面は、すかすかの画面より速いことがある
どうするか
画面や API で見せる選択肢は、本当に必要な少数に絞る。残りは既定値や段階的開示の裏に回す。入口が少ないほど、決定は速い。
第43条 イーグルソンの法則
歯止め：コメントは腐る
最新だと確実に言えるのはコードだけだ。保守されないコメントや ADR は自信ありげな嘘になり、何もないより悪い
どうするか
コードとコミットメッセージは、半年後には他人同然になる自分に向けて書く。コードを読んでも分からない判断は、その「なぜ」を頭の中だけにとどめず、コメントか ADR に残す。
第46条認知
ミラーの法則
作業記憶に保てるのは数個のまとまりだけだ（Miller は7前後とし、後の研究はもっと少ないとする）。
人に一度に覚えさせるのは、数個までにする
第47条分散システム
分散コンピューティングの誤謬
ネットワーク越しのコードは、本番では成り立たない8つの前提を暗に置いている。
ネットワークは落ちるし遅いしタダではない、と思って書く
第48条安全工学
自動化の皮肉
自動化は人に最も難しい例外だけを残し、その対応に要る腕は使わないうちに鈍る。
自動化するほど、手で扱う練習が要る
第49条セキュリティ
最小権限の原則
不要な権限を持つ部品ほど、問題が起きたときの被害範囲が広がる。
権限はゼロから始め、必要と示せたものだけ足す
第50条セキュリティ
ケルクホフスの原理
設計が秘密である間だけ安全なシステムは、安全ではない。
設計は読まれている前提で、秘密は鍵だけに置く
第51条性能
グスタフソンの法則
問題の規模が計算機とともに大きくなるなら、並列化の効果はほぼ比例して伸びる。
マシンと一緒に問題も大きくなるかを問う
第52条分散システム
スケールの裾野
一つのリクエストが多数のサーバに分かれると、最も遅いサーバが応答時間を決める。
ファンアウトでは、平均でなく遅い裾を見る
第53条システム
アシュビーの必要多様性の法則
制御側は、対象がとりうる状態と同じだけの対応を持たないと制御できない。
システムの多様さに見合う手を持つか、多様さを減らす
第54条保守性
デメテルの法則
他のオブジェクトの内部をたどるコードは、その連鎖のどこが変わっても壊れる。
隣とだけ話し、隣の隣には手を伸ばさない
第48条 自動化の皮肉
歯止め：トイル
腕を鈍らせないためだけに定型作業を人に続けさせるのにもコストがある。負荷に比例して増える繰り返し作業は時間を食い、ミスを招くので、自動化を進める理由は確かにある。この対立は、自動化を減らすことではなく、人と機械の連携をよくすることで解く
どうするか
定期的なゲームデーと実地訓練で、運用担当の勘を保つ。引き継ぎは、人が何も知らないままいきなり引き取るのではなく、状況を把握したうえで引き取れるように設計する。
第47条 分散コンピューティングの誤謬
歯止め：分散させない
Fowler の分散オブジェクト設計の第一法則。8つの誤謬を乗り切る一番安い方法は、そもそも呼び出しをリモートにしないことだ
どうするか
プロセス間呼び出しを出す前に、8つの仮定のどれに頼っているかを書き出し、それぞれにタイムアウト、リトライ、失敗時の処理を明示的に用意する。
第46条 ミラーの法則
歯止め：まとめすぎ
まとめるたびに間接参照が一段増える。短い一覧を名前付きのグループに分けると、グループ名まで覚えなければならなくなる
どうするか
関数の引数、フォーム項目、メニューのグループ、オンコール手順のように、人が状態を頭の中に保たなければならない場所では、関連する項目を電話番号のように少数の名前付きチャンクにまとめる。
第51条 グスタフソンの法則
歯止め：アムダールの法則
作業量の大きさが固定なら、やはり逐次部分が速度向上の上限を決める
どうするか
コアの追加を求める前に、問題の規模がハードウェアに合わせて大きくなるかを確かめる。作業量が固定ならアムダールで考え、規模とともに増えるならグスタフソンで考える。
第50条 ケルクホフスの原理
歯止め：多層防御
秘匿は薄い追加の一層にはなっても、土台には決してならない
どうするか
攻撃者はソースコードも設計もすべて手にしている前提で考える。秘密はすべて交換できる鍵に寄せ、隠したアルゴリズムで何かを守ろうとしない。
第49条 最小権限の原則
歯止め：心理的受容性
利用者が回避するほど厳しい制限は、かえって守りを崩す
どうするか
プロセス、サービスアカウント、トークンはすべて既定で拒否にし、その仕事に必要だと確かめられた最小限のスコープだけを加える。仕事の内容が変わったら、そのたびに権限を監査し直す。
第54条 デメテルの法則
歯止め：教条より実用
厳密に適用すると、転送メソッドやラッパーが増えすぎる
どうするか
メソッドを呼ぶ相手は、直接の協力オブジェクト、引数、自分で生成したオブジェクト、自分のフィールドに限る。getter をつなげて呼んでいるなら、データを持っているオブジェクトの側にメソッドを足す。
第53条 アシュビーの必要多様性の法則
歯止め：環境そのものを制約する
制御側の多様さが過剰なら、それ自体がコストと複雑さになる
どうするか
障害がアラートや手順書を何度もすり抜けるなら、それに見合うだけ対応能力を増やすか、設定を減らし入力を厳しくして、系がとりうる状態をあえて減らす。
第52条 スケールの裾野
歯止め：冗長化には代償がある
ヘッジドリクエストや連動リクエストは負荷を増やす。利用者の体感を決めるのが中央値なら、テールを追いかけない
どうするか
SLO は平均ではなく p99／p99.9 に設定する。すべてのノードを同じように速くしようとするのではなく、ヘッジドリクエストやマイクロパーティショニングのようなテール対策を入れる。
第55条インセンティブ
ジェヴォンズのパラドックス
資源を安く使えるようにすると、かえって総使用量が増えることがある。
安くすれば、使われる量は増えると見込む
第56条安全工学
通常事故理論
複雑で密に結合したシステムでは、事故は構造そのものから生じる。
安全装置を足す前に、結合を緩める
第57条安全工学
割れ窓理論
放置された小さな乱れは、基準は守らなくてよいという合図になり、さらに乱れを呼びやすい。
目の前の小さな乱れは、それが基準になる前に直す
第58条保守性
YAGNI
想像した将来のために書いたコードは、今の工数を食い、実際の要件に合うこともまれだ。
想像した将来ではなく、いまある要件のために作る
第59条保守性
KISS の原則
システムは、普通の人が悪条件の中でも直せる程度に単純である必要がある。
単純とは、夜中の3時に他人が直せることだ
第60条保守性
DRY 原則
同じ知識を二か所に置くと、一緒に変わる保証がないので食い違っていく。
重複をなくすのは、テキストではなく知識
第61条性能
制約理論
システムの処理量は、最も詰まっている一か所で決まる。
改善はボトルネックに集める。ほかはそれを待っているだけだ
第62条認知
オッカムの剃刀
検証されていない仮定が最も少ない説明が、たいてい正しい。
仮定の少ない説明から確かめる
第63条保守性
単一責任の原則
二つの利用者グループに使われるモジュールには、両方から食い違う変更要求が届く。
コードは、変更を頼んでくる人の境目で分ける
第57条 割れ窓理論
歯止め：修繕もタダではない
塗装に注意を向ければ、その分だけ土台への注意が減る。そもそも元の犯罪学的な主張を裏づける証拠には異論がある
どうするか
いま触っているファイルに目に見える欠陥があれば、最初の一つを直す。黙認する例外にはすべて担当者と期限を付ける。自分がいま手を入れていない場所の窓を直すために、リファクタリングを始めない。
第56条 通常事故理論
歯止め：高信頼性組織（HRO）
空母や航空管制のような組織は、冗長性、専門性への敬意、小さな失敗への絶え間ない注意によって、密結合で複雑な系をごく少ない事故で動かしている
どうするか
安全のための連動装置を足す前に、バッファ、タイムアウト、バルクヘッド、サーキットブレーカで結合を緩め、複雑さを減らす。連動装置そのものも相互作用を増やす。
第55条 ジェヴォンズのパラドックス
歯止め：反動に上限を設ける
効率化には割当、上限、価格シグナルを組み合わせ、節約分を実際に手元に残す
どうするか
計算資源、ストレージ、社内 API などを安くしたら、需要が大きく膨らむと見込む。全体として減ると決めつけず、反動を見込んで容量と予算を確保する。
第60条 DRY 原則
歯止め：誤った抽象より重複のほうが安い
今たまたま似ているだけの2つのブロックは、別々に変える必要が出たとたんに互いの足かせになる
どうするか
なくすのはテキストの重複ではなく知識の重複だ。似た2つのブロックをまとめる前に、同じ理由で、同じ人の要求によって変わるかを確かめる。そうでなければ分けたままにする。
第59条 KISS の原則
歯止め：アシュビーの必要多様性の法則
制御すべき問題より単純な系は、その問題に対処できない。その下限を下回る単純さは、複雑さを減らしたのではなく、よそへ移しただけだ
どうするか
設計は、レビューでの読みやすさではなく「午前3時に誰が直せるか」で評価する。オンコール担当が作者を呼ばないと直せないなら、それは単純なのではなく、一人が慣れているだけだ。
第58条 YAGNI
歯止め：チェスタトンの柵
YAGNI が認めるのは作らないことだけで、目的を確かめていないものを消すことまでは認めていない
どうするか
実装するのは、いま実際にあるケースだけにする。一般化したくなったら、まず2つ目の具体的なケースを挙げる。挙げられないなら、それはパターンではなく当て推量だ。
第63条 単一責任の原則
歯止め：早すぎる分解
想像した責務で分割すると、メソッドが一つしかないクラスが散らばり、複雑さはすべてクラス同士のつなぎ込みに移るだけになる
どうするか
責務は、コードが何をするかではなく、誰が変更を求めてくるかで決める。同じモジュールに対して別々の人がそれぞれ修正を求められるなら、その線で分割し、それ以外では分けない。
第62条 オッカムの剃刀
歯止め：ヒッカムの格言
システムは独立した障害を同時にいくつも抱えることがある。症状に合ういちばん単純な説明が、そのまま真実とは限らない
どうするか
仮説を「未検証の仮定がいくつ必要か」で並べ、安く確かめられるものから検証する。「何が壊れたか」より先に「何が変わったか」を聞く。
第61条 制約理論
歯止め：制約は移動する
一つを緩めれば別のものが制約になる。昨日のボトルネックに合わせて恒久的に最適化した工程は、新しい制約の前で立ち往生する
どうするか
制約を特定し、能力を買い足す前にまずそれを目一杯使い切り、他の全工程をそれに従わせる。そのあと測り直す。今の改善で、別の場所に新しいボトルネックができているからだ。
第64条ヒューマンインタフェース
驚き最小の原則
利用者を驚かせる挙動は、少し劣っても予想どおりの挙動より高くつく。
迷ったら、利用者が予想するとおりに動かす
第65条システム
セカンドシステム症候群
最初の成功のあと、設計者は先送りしたアイデアを二作目に詰め込みがちだ。
作り直しで持ち越すのは、願望リストではなく制約
第66条性能
ムーアの法則
部品単価が最も安くなるチップのトランジスタ数は、約2年ごとに倍になる。
来年のハードが設計を救ってくれると当てにしない
第67条見積り
アマラの法則
新しい技術は、最初の数年は過大評価され、十年単位では過小評価される。
二年先の熱狂は割り引き、十年先の変化は侮らない
第68条システム
苦い教訓
AIでは長い目で見ると、計算量とともに伸びる汎用手法が、人が作り込んだ知識に勝ってきた。
予算が倍になったとき、勝手に良くなるほうに賭ける
第69条システム
メトカーフの法則
ノードが一つ増えるたびに既存の全ノードの価値が上がり、価値は規模より速く増える。
プロダクトではつながりを増やし、チームでは減らす
第70条組織
リンゲルマン効果
集団が大きくなるほど、一人ひとりが出す力は減る。誰の成果か見えないと特にそうだ。
誰が何をしたかを見えるようにし、担当を決める
第71条インセンティブ
シャーキーの原理
組織は、自分たちが存在する理由である問題を残そうとする。
解決役の組織には、「解けた」とは何かを問う
第72条運用
エラーバジェット
100% 未満の SLO は許容できる失敗の量を決める。その量は使ってよい予算だ。
許された失敗は出荷に使い、尽きたら止める
第66条 ムーアの法則
歯止め：ヴィルトの法則
得られた余力は貯めておかれずに使い切られる。しかもクロック速度は、トランジスタ数よりずっと早く頭打ちになった
どうするか
設計の問題をハードウェアが救ってくれる前提で予算を組まない。ワークロードがシングルスレッドでレイテンシ律速なら、来年のマシンでも解決しない。並列化するか、処理の量を減らすしかない。
第65条 セカンドシステム症候群
歯止め：行き止まりのアーキテクチャ
育てようのない最初のシステムもある。データモデル、プラットフォーム、セキュリティ境界が次の一歩を完全に塞いでいるなら、範囲を絞って意図的に作る2番目のシステムが正しい判断になる
どうするか
書き直すときは、やりたいことの一覧だけでなく制約も引き継ぐ。見送っていた機能は、実際に利用者の妨げになっていた少数まで削り、元のシステムを一つずつ置き換える。
第64条 驚き最小の原則
歯止め：驚きは相対的である
今日の期待だけに合わせて設計すると、悪い慣習がそのまま固定される。移行手順を用意したうえで、一度だけ大々的に全員を驚かせるのが正しいこともある
どうするか
2つの設計が拮抗したら、フラグ名、終了コード、並び順など、利用者がすでに知っている慣習に合うほうを選ぶ。意図した驚きは、告知するコストを払える場所でだけ使う。
第69条 メトカーフの法則
歯止め：同じ二次関数はコストでもある
接続は利用者どうしでは資産だが、同僚どうしでは負債になる。ブルックスの法則はメトカーフの法則の符号を反転させたものだ
どうするか
他の利用者から価値が生まれるプロダクトでは、初期の労力を機能ではなく、参加者にとってすでに役に立つ最小のネットワークづくりに注ぐ。チームでは逆に、接続を減らす。
第68条 苦い教訓
歯止め：計算資源はタダではない
予算が固定されていれば、使える手段が領域知識しかないことも多い。この教訓は分野がたどってきた流れを述べたもので、今四半期に何をすべきかを示すものではない
どうするか
知っていることを組み込むか、より多くのデータや計算から学ぶものを作るかで迷ったら、予算が倍になったときに手を加えなくても良くなるのはどちらかを考える。数年単位の取り組みなら、そちらに賭ける。
第67条 アマラの法則
歯止め：そもそも来ないものもある
生存者バイアスのせいで、この法則は必然に見える。長く続かなかった技術は、あとから引き合いに出されないからだ
どうするか
新技術の2年予測は割り引き、10年予測は真剣に受け止める。ただし計画は、デモ版ではなく実際に出荷される版を前提に立てる。
第72条 エラーバジェット
歯止め：逸脱の常態化
失敗を許す枠があると、チームは失敗をいつものことだと覚える。本来なら騒ぎになるはずの障害も予算から差し引かれるだけで、調べられずに終わる
どうするか
SLO と、予算を使い切ったときの方針は、障害の最中ではなく事前に合意しておく。予算が残っていればリリースし、使い切ったら機能リリースを止め、回復するまで信頼性に時間を使う。データ消失とセキュリティは、そもそも予算の外に置く。
第71条 シャーキーの原理
歯止め：なくならない問題もある
長く続くチームをすべて自己保身だとみなすと、必要な保守をしているチームまでなくしてしまう。保守は、うまくいっているときほど目に見えない
どうするか
何かを直すために作ったチームやツールには、「直った」とはどういう状態か、いつそれを確かめるかを書き出しておく。自分たちが不要になる条件を説明できないプラットフォームチームは、自分たちの存続を目的にしている。
第70条 リンゲルマン効果
歯止め：一人ずつの仕事を見えるようにする
この効果は人の性質ではなく、仕事の測り方から生まれる。誰がどれだけやったかが見えるようにすれば、効果の大半は消える
どうするか
作業の流れごとに、名前の分かる担当者を一人と、目に見える成果物を決める。結果のどの部分を誰が出したか言えないなら、その集団は全員の力の合計より少ない成果しか出さないと見ておく。
第73条運用
トイル
手作業の繰り返し運用はサービスと一緒に増え、放っておけば開発の時間を食い尽くす。
繰り返す手作業は、務めではなく欠陥として扱う
第74条運用
非難なきポストモーテム
障害のいちばん近くにいた人を罰すると、人は自分のしたことを隠すようになる。
直すのは人ではなく、間違えやすくしていた仕組み
第75条意思決定
ワーキング・バックワーズ
解決策から始めると、誰も必要としないものを作ることが多い。発表文から始めれば早く気づける。
顧客が何を得るか言えないうちは、作り始めない
第76条意思決定
反対してもコミットする
全員の同意を待つより、決めて実行し、誤りなら軌道修正するほうが速いことが多い。
反対は一度きっちり言い、戻せない決定以外は乗る
第77条運用
作った者が運用する
サービスを作るチームが運用も担えば、運用上の弱点のコストは、それを直せる人のところに落ちる。
直せる人が、起こされる人であるべきだ
第78条分散システム
静的安定性
障害を乗り切るのに新しい動作が必要なシステムは、状況がいちばん悪いときにその動作が成功することに頼っている。
障害の最中に何かをしないと助からない作りにしない
第79条分散システム
フォールバックを避ける
フォールバック経路は何かがすでに失敗したあとでしか動かない。だから、システムでいちばん試されていないコードが最悪の条件で動く。
壊れたときにしか動かないコードを信用しない
第80条分散システム
一定の作業量
変更や障害の数に応じて仕事が増えるシステムは、余力がいちばん少ないときにいちばん多くの仕事をする。
制御系では、変化の有無に関係なく同じ量の仕事をさせる
第81条組織
善意ではなく仕組み
失敗のあとで「もっと気をつけろ」と求めても、ほとんど何も変わらない。失敗した人は、もともと気をつけていたからだ。
「気をつける」を、誰も覚えていなくても効く仕組みに置き換える
第75条 ワーキング・バックワーズ
歯止め：作って学ぶ
顧客が紙の上では判断できないもの（新しいプラットフォーム、基盤の変更、前例のないもの）では、磨いたプレスリリースより安い試作品のほうが多くを教えてくれる
どうするか
プロジェクトを始める前に、顧客向けのプレスリリース一枚と FAQ を書き、チームでレビューする。最初の段落で顧客とその問題を言えないなら、作り始めない。
第74条 非難なきポストモーテム
歯止め：責任の拡散
誰も責任を負わないと、対策項目に持ち主がいなくなり、いつの間にか立ち消える。だから責めないことと引き換えに、修正の担当者だけは名指しするチームもある
どうするか
ポストモーテムは、各人が何を見て、なぜその操作がその時点で妥当だったかを時系列で書き、人ではなく仕組みの変更で締めくくる。変更ごとに担当者を一人決め、期日を付ける。根本原因に「ヒューマンエラー」と書くのは禁止し、何がその誤りを起こしやすくしていたかを問う。
第73条 トイル
歯止め：自動化の皮肉
作業を自動化すると、自動化がうまく動かなくなったときに人が対処するための慣れが失われる。作って動かし続けるコストが、置き換えたトイルより高くつく自動化もある
どうするか
一人ひとりの時間のうちトイルが占める割合を測り、上限を決める（Google は 50%）。同じ作業が三度目に来たら（本書ではなく経験則）開発タスクとして起票する。利用者数に比例して増える作業は、雑用ではなく欠陥として扱う。
第78条 静的安定性
歯止め：遊休容量のコスト
まれにしか起きない障害のための容量にも、毎日お金がかかる。復旧が遅くても許される場所では、需要に合わせて伸縮させるほうが安い。リージョン単位ではなくゾーン単位でサービスを作ると複雑さが増すことは、出典自身も認めている
どうするか
ゾーンや依存先を一つ失ったとき、サービスが復旧のために何をしなければならないかを書き出す。コントロールプレーンを呼ぶ手順や何かを起動する手順ごとに、代わりに前もって用意しておけないかを判断する。たとえば全ゾーンに予備の容量を置く、最後に正常だった設定を手元にキャッシュする、コントロールプレーンが落ちても配信を続ける、といった形だ。これは失敗が許されない経路に限り、それ以外は需要に応じて伸縮させる。
第77条 作った者が運用する
歯止め：開発者の認知負荷
開発から運用までを丸ごと持つと、開発者一人が知るべきことと毎週抱える優先事項が増える。共通の道具とオンコールのローテーションがなければ燃え尽きに行き着く。このモデルを採る Netflix も、幅より深さを求める人には、そうした役割を見つける手助けをするとしている
どうするか
サービスをリリースしたチームを、そのサービスのオンコールに就ける。呼び出しの原因を直す権限とデプロイ権限も渡す。デプロイ、可観測性、アラートの共通基盤（舗装された道）とオンコールのローテーションを用意し、一人が全部を抱えないようにする。呼び出される対象を自分で変えられないチームには適用しない。それでは所有を渡したことにならず、呼び出しを押しつけるだけだ。
第76条 反対してもコミットする
歯止め：集団浅慮
コミットを重んじる文化では、人は早いうちに反対するのをやめるようになる。黙って従う人が増えると、誤りに気づけたはずの異論が表に出てこない
どうするか
反対意見は一度だけ、理由を添えて全部言う。そのうえで「反対だがコミットする」と言い、自分の案だったつもりで実行する。立場が上の人も同じようにする。チームに自分を説得させるのではなく、チームの判断を後押しする。ただし取り返しのつかない決定や、安全・倫理上のリスクがある決定では、黙ってコミットせずエスカレーションする。
第81条 善意ではなく仕組み
歯止め：代理指標に抗う
仕組みは、それ自体が目的として固まることがある。プロセスに従ったかどうかで評価されるようになると、人は悪い結果を「プロセスどおりにやった」と弁護し、そのプロセスがまだ結果の役に立っているかを誰も問わなくなる
どうするか
ポストモーテムの対策項目が「注意する」「チームに周知する」「ダブルチェックする」なら、誰も覚えていなくても働く変更に置き換える。CI のチェック、安全な既定値、飛ばせない入力欄などだ。それぞれに担当者と、使われているか、効果があったかを点検する期日を付ける。もう結果を変えていない仕組みは廃止する。
第80条 一定の作業量
歯止め：伸縮性
毎回すべての仕事をすれば、ほとんど何も変わっていないときには資源の無駄になる。設定やヘルス状態の伝播ならコストは無視できるが、Web サーバー群では、ピーク容量を一日中動かすより、負荷に合わせて伸縮させて節約するほうがたいてい得になる
どうするか
設定やヘルス状態を伝える制御ループでは、変更のたびに差分を送るのではなく、決まった間隔で状態全体を送る。ペイロードの大きさは平均ではなく最大に合わせる。仕事の量を、変わったものの数に左右させない。この方式は仕事が小さい場所で使い、リクエストを処理する容量は負荷に応じて伸縮させ、過負荷時の振る舞いを明示的に設計する。
第79条 フォールバックを避ける
歯止め：グレースフル・デグラデーション
縮退した経路が普段から動いているなら、エラーを返すより縮退した答えを返すほうがよい。おすすめ欄が、普段から出している固定リストに切り替える場合などだ。危ないのは縮退そのものではなく、普段一度も動かない経路のほうだ
どうするか
フォールバックを足す前に、同じ労力で主経路の可用性を上げられないかを考える。リクエストのたびに取りに行く代わりに呼び出し側へ前もってデータをプッシュしておく、冗長化する、といった方法がある。フォールバックを残すなら、障害時だけでなく本番で常に動かし、その出力を主経路と同等に正当なデータ源として扱う。誰も動かしたことのないフォールバック経路は消す。
第82条運用
アンドン（ラインを止める）
異常に気づいた人が誰でもラインを止められれば、欠陥は下流へ流れない。下流で見つかれば、見つけるのも直すのも高くつく。
誰でもラインを止められるようにし、止めた人を咎めない
第83条運用
なぜなぜ分析
「なぜ失敗したか」への最初の答えはたいてい症状だ。症状だけを直しても原因は残り、また同じ失敗が起きる。
変えられるものに届くまで、なぜを問い続ける
第84条運用
カオスエンジニアリング
一度も試されていない耐障害性は仮説にすぎない。予定を組もうと組むまいと、本番がいずれそれを試す。
本番に壊される前に、自分で壊して確かめる
第85条組織
統制ではなく文脈を
組織が大きくなるほど、ルールと承認は共有された理解ほどにはスケールしにくい。手順を渡された人より目標の背景を渡された人のほうが現場でよい判断をする、というのが Netflix の主張だ。
ルールを書く前に、足りなかった文脈を渡す
第86条保守性
コードの健全性を上げるなら承認する
すべての変更に完璧を求めるとレビューが遅くなり、遅いレビューはコードベースを良くするどころか悪くする。
完璧でなくても、良くなるなら通す
第87条保守性
ビヨンセ・ルール
共有コードベースでは、どのテストも確かめていない挙動こそが予告なく変わる。
頼っている挙動には、テストを置く
第88条組織
チャーンルール
共有基盤を変えるチームが移行作業を利用者に押しつけられると、変更のコストは利用者の数だけ膨らむ。
共有のコードを変える側が、移行の費用も持つ
第89条見積り
時間を固定し、スコープを変える
スコープを固定して時間を固定しないと、ずれるのは期日で、スコープは残る。時間を固定すれば、何が大事かを選ばざるを得なくなる。
かかる時間より先に、かける価値のある時間を決める
第90条保守性
ストラングラーフィグ
稼働中のシステムは、一度に置き換えるより、周縁から少しずつ置き換えるほうがたいてい安全だ。
移行は一歩ずつ出せる形にし、旧系の削除まで計画する
第84条 カオスエンジニアリング
歯止め：まず害をなさない
実際の顧客が頼っているシステムをわざと劣化させれば、その顧客の信頼を削ることになる。同じ知見の多くは、障害注入テスト、ゲームデイ、設計レビューでもっと安く得られる。もろいと分かっているシステムで実験しても分かっていたことを確かめるだけなので、まず直す
どうするか
依存先を一つ選び、それが落ちている間の定常状態がどうあるべきかを書き出す。そのうえで業務時間中に、中止スイッチと見張り役を用意して、本番でその依存先を取り除く。トラフィックのごく一部から始め、システムが持ちこたえてから範囲を広げる。落ちると見込んでいるサービスでは実験しない。
第83条 なぜなぜ分析
歯止め：スイスチーズモデル
なぜを一本の鎖でたどると、複数の経路があった事故から一本だけを選ぶことになる。各段で分析者が何を選ぶかによって、出てくる根本原因が変わる。複雑なシステムでは、単一の根本原因がそもそも存在しないことも多い
どうするか
ポストモーテムでは、答えが出るたびに「なぜ」を問い、チームが変えられて、しかも変えていれば連鎖を断てたはずのものに行き着くまで続ける。その変更には担当者を付ける。一つの答えに原因が複数あるなら枝分かれさせ、人のところで止めない。「エンジニアがミスをした」は、なぜそのミスが起こしやすかったのかを問う合図だ。
第82条 アンドン（ラインを止める）
歯止め：スループットの圧力
止めるたびに生産量は落ちる。スループットで評価されるチームでは、紐を引くことは誰かが理由を説明しなければならないコストになる。頻繁に、あるいは誤って止まる紐があると、人はそれを避けて通るようになる
どうするか
main ブランチのビルドが赤い、カナリアが失敗した、SLO を割った、といったときには、全員のマージやデプロイが止まるようにする。その紐は誰でも許可なく引けるようにする。誤発火がめったに起きない程度に条件を絞る。誰も調べない停止は、引いた人ではなく対応する側の欠陥として扱う。
第87条 ビヨンセ・ルール
歯止め：チャーンルール
テストの形をした契約は、変更する側に何を壊したかを教えるだけで、壊してよかったことにはならない。変更するチームは、利用者の移行作業をそれでも負う
どうするか
共有ライブラリや依存先に頼っている挙動には、すべてテストを書く。そのテストが、他人の変更を止める CI の中で走るようにする。テストで捕まえられずに何かが壊れたら、障害を閉じる前にそのテストを足す。共有コードを持つ側なら、テストが契約だと前もって宣言する。ただし、自分の変更で利用者側のテストを実際に走らせていないなら、このルールを持ち出さない。
第86条 コードの健全性を上げるなら承認する
歯止め：割れ窓理論
差し引きで改善だからと小さな欠点を一つずつ通していくと、見過ごされた欠点だらけのコードベースが残る。一つ通すたびに、次も通しやすくなる
どうするか
変更によってコードが以前より確実に健全になるなら、自分なら違う書き方をしたとしても承認する。磨き込みの指摘には「Nit:」を付けて、作者が見送れるようにする。ブロックするのはコードを悪くする点だけにする。緊急時を除き、全体としてコードの健全性を確実に悪くする変更は承認しない。
第85条 統制ではなく文脈を
歯止め：ガードレール
一部の失敗（認証情報の漏洩、コンプライアンス違反、取り消せない削除）は、判断に任せるには代償が大きすぎる。また文脈は、まだそれを身につけていない新人には役に立たない
どうするか
自分なら別の判断をしたと思う決定をチームが下したら、ルールを書く前に、チームに欠けていた文脈は何かを問い、まず文脈を補う。強い統制（承認ゲート、強制されるポリシー）は、取り返しのつかない決定、倫理に反する決定、重大なリスクを伴う決定に限る。統制ごとに存在理由を書き残し、理由がなくなったら外せるようにする。
第90条 ストラングラーフィグ
歯止め：一括切り替え
古いシステムにきれいな振り分け点を置けないときや、移行用の層が書き直しより高くつくときは、計画した一度の切り替えのほうが、段階的移行のありがちな末路を避けられる。簡単な経路だけが移り、いちばん絡み合った部分はいつまでも移らず、組織は二つのシステムを運用し、その費用を払い続ける
どうするか
レガシーシステムの前に振り分け点（プロキシ、ルーター、ファサード）を置き、挙動を一部分ずつその裏へ移す。最初は、それだけで価値を生む部分を選ぶ。「完了」の定義を最初に決め、古い経路に残っているトラフィックの割合を追う。古いコードと移行用の層を消す作業は、後片づけではなくプロジェクトの一部として見積もる。
第89条 時間を固定し、スコープを変える
歯止め：隠れた変数としての品質
期日が固定されてもスコープを削れない、あるいは削らないチームは、代わりにテストやレビュー、エラー処理を削る。また、プロトコルやコンプライアンス要件のように、それ以下に切っては出す意味のない下限がある仕事もある
どうするか
作業を始める前に、どれだけかかるかではなく、どれだけの時間をかける価値があるかを決め、スコープをそれに合わせる。時間が尽きたら原則として止める。できた部分が単独で成り立つなら出し、そうでなければ問題の切り方を作り直して、もう一度賭けるかを改めて決める。黙って延長しない。機能はテストやレビューより先に削る。筋の通った最小単位より細かく切れない仕事では、時間を固定しない。
第88条 チャーンルール
歯止め：コードオーナーシップ
普段触っていないコードを変える人は、そのコードにある固有の事情を見落とす。だから中央で一括して行う移行でもオーナーチームのレビューは要るし、オーナーにしか安全にできない変更もある
どうするか
ライブラリやサービス、プラットフォームを持つ側なら、移行作業を変更の一部として見積もる。呼び出し側は自分たちで移すか、後方互換を保ったままその場で変える。非推奨の告知と期限だけを移行計画として出さない。コードベースをまたぐ変更を安くする道具に投資し、変更は黙って入れず、一つずつオーナーチームのレビューに回す。
第91条意思決定
退屈な技術を選べ
不慣れな技術を採り入れるたびに、未知の故障モードと恒久的な運用コストが付いてくる。チームが抱えられる数は多くない。
新しい技術は、差がつくところにだけ使う
第92条保守性
技術的負債
問題を十分に理解する前に出したコードは、誰かが書き直すまで、そのコードをその後変えるたびに余計なコストを生む。
近道は借金として記録し、よく触るところから返す
第93条保守性
レーマンのソフトウェア進化の法則
実際に使われているプログラムは、変わり続けなければ役に立たなくなる。そして変えるたびに、手をかけて単純にしない限り複雑になっていく。
変更だけでなく、単純化にも予算を割く
第94条組織
バス係数
システムを動かし続けられる人が少ないほど、その将来は一人ひとりが辞めずにいることにかかってくる。
一人しかできないことは、いま潰すべきリスクだ
第95条保守性
殺虫剤のパラドックス
バグを見つける方法はどれも、その方法では見つからないバグを残す。だから変わらないテストスイートが見つけるバグは減っていく。
バグの探し方を変え続ける
第96条意思決定
スライドではなく文章で
スライドと箇条書きに縮めた議論は、論点どうしのつながりを失う。文章なら露わになったはずの穴や警告が、気づかれないままレビューを通り抜ける。
重い決定は、箇条書きではなく文章で書く
第97条保守性
ワン・バージョン・ルール
共有する依存先のどのバージョンを使うかを利用者が選べると、選ぶたびに、選んでいない誰かが衝突を抱える。
二つ目のバージョンは、持ち主と期限つきの負債とみなす
第98条意思決定
現地現物
報告をもとに下す判断は、実際に起きていることから離れていく。要約が一段挟まるたびに、その形式に収まらなかった細部が落ちるからだ。
要約を信じる前に、現物を自分の目で見る
第99条意思決定
信頼度で重みづけする意思決定
集団がどの意見も同じ一票と数えたり、役職に従ったりすると、実際にそれをやったことのある人が、やったことのない人に多数決で負ける。
意見の重みは、肩書きや人数ではなく実績で決める
第93条 レーマンのソフトウェア進化の法則
歯止め：安定も機能のうち
変更のたびに利用者は覚え直しを強いられ、古い挙動に頼っていた誰かが壊れる。他人がその上に作るプロトコルやファイル形式、ツールなら、世の中に追従するより設計を凍結するほうが価値を生むこともある
どうするか
継続的な変更は、リリース後の例外ではなく、使われているプログラムの通常のコストとして予算に入れる。毎回のサイクルの一部を、使われない経路の削除や例外処理の統合など、複雑さを減らす作業にあてる。複雑さの指標をリリースごとに追い、身動きが取れなくなる前に傾向をつかむ。凍結するのは他人がその上に作るものだけにし、凍結するときはそう明言する。
第92条 技術的負債
歯止め：早すぎる返済
負債を早く返すと、設計がまだ変わるかもしれないコードや、次に誰かが触る前に消えるかもしれないコードに時間を使うことになる。次の変更の前に片づけるほうが、節約できる利息より高くつくこともある
どうするか
問題を十分に理解する前に書いたコードは借金として扱う。どこにあり、返すには何が要るかを書き残し、コードが誰かの記憶に新しいうちに書き直しの予定を立てる。返済は、見た目が一番ひどいコードではなく、チームが一番よく変えるコードから始める。記録のないまま負債をためない。
第91条 退屈な技術を選べ
歯止め：目的への適合
退屈な技術を選ぶとは、新しいものを決して入れないことではない。今の技術スタックでは本当に仕事ができないなら、無理に使い続けるほうがトークン一枚より高くつく。まったく変わらないスタックは、誰も触りたがらないレガシーになる
どうするか
言語、データストア、フレームワークを足す前に、今動かしているもので同じ仕事をするには何が要り、なぜそれでは足りないのかを書き出す。そのうえで、一つのチームの中ではなく、それを運用することになる全員で決める。新しい技術は、製品を他と差別化する場所にだけ使う。何かを採り入れるなら、それが置き換えるものを廃止する計画も立てる。
第96条 スライドではなく文章で
歯止め：包括的なドキュメントよりも動くソフトウェア
動くコードのほうが文章より早く設計上の問いに答えを出せるなら、先に書く文書は推測を一週間かけて書き留めるだけになる。実のところ実装手順書でしかない設計文書は、そもそも書かない
どうするか
取り消すのに高くつく決定や、チームの外の人の承認が要る決定は、数ページの文章で提案する。問題、検討した選択肢、トレードオフ、推奨案を書く。レビューは全員が黙って読むところから始め、それから議論する。取り消しやすい変更や、簡単な試作で答えが出る問いには書かない。試作を作る。
第95条 殺虫剤のパラドックス
歯止め：古いテストの守り
何年も落ちていないテストも、直したバグの再発を止め、他人が頼る挙動を固定している。新しいバグを追うために古いテストを捨てれば、今も効いている守りを失う
どうするか
回帰テストは残すが、それで新しいバグが見つかるとは期待しない。新しい入力、ファジング、プロパティベーステスト、探索的テストなど、スイートが確かめていないところを狙うテストを足す。本番にバグが漏れたら、どの種類のテストなら捕まえられたかを考え、その一件だけでなく、その種類のテストを足す。スイートは定期的に見直し、互いに重複するテストは消す。
第94条 バス係数
歯止め：所有の深さ
ある領域を持つ専門家は、少しずつ知っている人の持ち回りよりずっと速く動き、問題にも多く気づく。小さなチームがあらゆる知識を二人目にも持たせようとすると、ない時間を使うことになる
どうするか
一人しか変更も運用もできない箇所を洗い出す。それぞれについて、誰も読まない引き継ぎ文書を書くのではなく、次の実際の変更で二人目をペアにつける。オンコールとコードレビューを持ち回りにして、普段の仕事のついでに知識が移るようにする。予定された不在は訓練として扱う。一週間の休みでシステムが止まるなら、誰かが本当に辞める前に直す。
第99条 信頼度で重みづけする意思決定
歯止め：群衆の知恵
判断が互いに独立していれば、均等な重みの単純な集計を上回るのは難しい (Galton が見た品評会の群衆の推定の中央値は、牛の重さとの差が 1% もなかった)。専門家を前もって選ぶのは、過去の実績が新しい問いにも通じるほうに賭けることだ
どうするか
意見の割れる技術判断の前に、この種のものを作ったり運用したりした人は誰か、それはうまくいったかを確かめ、その人の見解を人数や肩書きより重く扱う。議論の前に意見を書面で集めて独立性を保ち、単純な集計と重みづけした集計の両方を見る。両者が食い違ったら、重みづけした側を自動的に勝たせず、掘り下げる。信頼度は、出荷したシステムやポストモーテムなど、確かめられる結果をもとに決める。チームの誰も経験したことのない問いでは、重みづけをやめる。
第98条 現地現物
歯止め：集計を信じる
現場で見られるのは一つのシフト、一人の利用者、一本のトレースだ。人は小さな標本を全体の代表のように扱いがちだ (少数の法則の信念)。全体についての問いなら、すべての事例を含むダッシュボードのほうが確かな証人になる
どうするか
修正、優先順位、ポストモーテムの結論を決める前に、一次情報を自分の目で確かめる。バグを再現する、生のログと失敗したリクエスト一件のトレースを読む、実際の利用者が問題にぶつかる様子を見る、一時間サポートの窓口に座る。見たものはダッシュボードを疑うのに使い、置き換えるのには使わない。
第97条 ワン・バージョン・ルール
歯止め：セマンティック・インポート・バージョニング
オープンソースのエコシステムのように、すべての呼び出し側を持つ者がいない場では、全員を一度に移す変更は誰にもできない。互換性のないメジャーバージョンを別のインポートパスで並べて置けば、呼び出し側はそれぞれの都合でアップグレードでき、コピーが重複するのはその代価として受け入れる。Go のモジュールはこのやり方を採っている
どうするか
社内のものも外部のものも、共有する依存先はバージョンを一つに保つ。アップグレードは、すべての呼び出し側を一度に移す一つの変更にする。一度で入らないアップグレードに限り、二つ目のバージョンを別の名前で、オーナーと期限を付けて許し、期限が来たら消す。チームが共有ライブラリを勝手にフォークしたり固定したりするのは認めない。セキュリティ、法務、リリースの要件が本当に違うプロジェクトはリポジトリを分けてよいが、それぞれの中では依存先ごとにバージョンを一つに保つ。
第100条組織
ブレイントラスト (権限を持たない助言)
オーナーを覆せる人からの意見は、活かされるより先に防御の対象になる。修正を強制できない仲間なら率直に言えるし、オーナーも落ち着いて聞ける。
率直に指摘し、直し方は持ち主に任せる
第101条認知
ブランドリーニの法則
誤った主張を論破するには、それを言うよりはるかに手間がかかる。だから安い主張が大量に来ると、確かめる側の手が回らなくなりうる。
反論に手間をかける前に、まず主張に証拠を出させる
第102条認知
自動化バイアス
自動化された補助を使う人は、自分で確かめる代わりにそれを頼りがちだ。補助が指摘しないものを見落とし、補助が間違っていてもそれに従う。
ツールに従ったかではなく、結果に責任を持つ
第103条保守性
小さな変更
レビューに出す変更が大きいほど、一行ずつは丁寧に読まれなくなる。欠陥はすり抜け、最初に見てもらうまでの待ちも長くなる。
一度に読み切れる大きさで変更を出す
第104条保守性
プログラミングは理論の構築である
プログラムの設計は作った人たちの頭の中にあり、コードや文書が運べるのはその一部だけだ。だから作った人たちがいなくなると、文書がそろっていても、変更を重ねるうちに設計が崩れやすい。
理由を言える人がいるうちが、保守できるコードだ
第105条保守性
テストオラクル問題
テストが誤った答えを捕まえられるのは、コードとは別に正しい答えを知っているものがあるときだけだ。そして多くのプログラムには、それがない。
通ったテストは、何と照合したかを問う
第106条セキュリティ
致命的な三点セット
非公開データを読めて、外から来た内容を取り込み、外へデータを送れる AI エージェントは、その内容を書いた誰にでも操られてデータを漏らしうる。
エージェントが読む文章は、書いた人からの指示だと思う
第107条意思決定
遅延コスト
仕事は大きさや勘、声の大きさで並べられ、待たせた週ごとに失う価値は数えられない。だから一番価値のある仕事が、目立つだけの仕事の後ろで待たされることが多い。
作る費用より先に、一週間待たせる費用を聞く
第108条意思決定
最終責任時点
早く決めすぎると推測がそのまま設計として固まる。待ちすぎると選択肢が黙って消え、誰も決めないまま成り行きで決まってしまう。
決定ごとの期限を知り、その手前で決める
第102条 自動化バイアス
歯止め：アルゴリズム嫌悪
逆向きの誤りもよく起きる。Dietvorst、Simmons、Massey によれば、人は同じ間違いを見たとき、人間の予測者よりアルゴリズムのほうに早く信頼を失う。そのため、まだ自分より正確な補助を手放してしまう
どうするか
自動化された補助が判断に入る場所（生成されたコード、スキャナの結果、異常なしと告げるアラート）では、ツールに従ったかどうかではなく、結果に責任を持つ人を一人決める。セキュリティ、データ移行、本番の変更のように影響の大きい経路では、レビュアーはツールの出力ではなく要件と照らし合わせて確かめ、補助が見落としたものを記録しておく。ツールのほうが確かだとわかっている作業を手でやり直すことはしない。影響の小さい出力は抜き取りで確かめる。
第101条 ブランドリーニの法則
歯止め：カニンガムの法則
詳しい人が見ている場では、間違った主張にはすぐに無料で訂正がつくことが多い。主張を一つ残らず確かめてから出すより、自分の推測を出して直してもらうほうが早い場合もある
どうするか
確かめる速さを超えて主張が届く場所（バグ報告、レビューコメント、脆弱性の報告）では、最初に証拠を求める。再現手順、失敗するテスト、ログを出してもらう。最初の確認には時間の上限を決める。報酬が何を呼び込むかも見ておく。確認済みの結果にだけ払う報酬でも、確かめきれないほどの主張を集めるなら、やめたほうがいい。ただし、得るもののない人からの短い報告を切り捨てる口実にはしない。短くても再現する報告は、きちんと見る。
第100条 ブレイントラスト (権限を持たない助言)
歯止め：関門としてのレビュー
死角のツケがオーナー以外の誰か (セキュリティの穴、失われたデータ、別チームのオンコール) に回るなら、無視できる助言では足りず、レビュアーが止められなければならない
どうするか
設計レビューや RFC のレビューでは、レビュアーは問題とその原因と思われるものを指摘するが、直し方は指図しない。判断は作者に任せ、作者は指摘の一つひとつに書面で答える。部屋には、作者を評価する上司ではなく、似たものを作った経験のある仲間を集める。誤りのツケが他人に回るもの (セキュリティ、データ消失、取り消せない移行) では、止める権限のある承認を残す。ただし助言のためのレビューとは別の手順にする。
第105条 テストオラクル問題
歯止め：本番を判定役にする
安くて取り消せる変更なら、一部に期間を限って出し、実際のトラフィックと SLO に照らして見るほうが、テストを書く人が思いつかなかった問題を拾える
どうするか
大事なものを守るテストは、期待値の出どころを言えるようにする。仕様、手計算、独立した別実装、その分野の専門家などだ。現在の出力をそのまま期待値にしたスナップショットテストや生成テストは、変化の検知器として扱い、コードが正しい証拠とはみなさない。オラクルがないところでは、どのみち成り立つはずのことを確かめる。不変条件、往復変換、関連する入力どうしの出力の関係などだ。監視の整った取り消せる変更なら、カナリアを確認手段にしてよい。手で作るオラクルは、取り消しが高くつく変更のためにとっておく。
第104条 プログラミングは理論の構築である
歯止め：合理的な設計を装う
Parnas と Clements は、設計を合理的に導いたかのように書き残し、変更のたびにその記録を最新に保つべきだと論じた。そうすれば新しく入った人は古いメンバーだけに頼らずにすむ。人の入れ替わりが多い職場では、誰が残るかに賭けるより、保たれた記録のほうが確かだ
どうするか
システムの担当が替わるときは、重なる期間を取る。新しい担当が実際に変更を加え、前のチームがそれをレビューする。設計に逆らうパッチを前のチームが見つけなくなったら、引き継ぎを終える。生成コードや外注のコードをマージする前に、それを持つことになる人に、なぜこういう形なのかを説明させる。誰も説明できないなら、持ち主のいないコードとして扱う。チームがいなくなったプログラムについて、Naur は古いプログラムを捨てて新しいチームに問題を解き直させるよう勧め、そのほうが復活させるより高くはつかないとした。書き直せないなら、何かを組み替える前に、実際の変更をペアで進めて理論を組み立て直す。
第103条 小さな変更
歯止め：変更ごとの固定費
変更には大きさに関係なくかかる固定費がある（レビューの往復、CI の実行、レビュアーの頭の切り替え）。細かく割るほどその費用と待ちが増える。レビューが遅い場では、依存し合う小さな変更を順に通すほうが、まとまった一つの変更より取り込みまでずっと時間がかかることがある
どうするか
変更は一つで完結するものにする。100行くらいならたいてい妥当で、1000行はたいてい大きすぎる。ただし最後はレビュアーが決める。リファクタリングは振る舞いの変更と別に出し、依存し合う変更は一つにまとめず、順番に積んで出す。名前の変更や生成コードのような機械的な変更を、行数を合わせるためだけに割ることはしない。レビュアーが全体として何をするのか見えなくなるほど、設計を細かく切り分けることもしない。
第108条 最終責任時点
歯止め：最も責任ある時点
Wirfs-Brock は、最終責任時点がいつなのか自分には見分けられないと書く。それを狙うと、いつでも考え直す時間があると思い込んでしまうという。だから、決めることで良い影響が出る時点が来たら決めるほうを選ぶ。その時点は、多くの場合もっと早く来る
どうするか
保留中の設計判断ごとに、選択肢を消してしまう出来事（契約の期日、インタフェースが固まるリリース、別チームがその上に作り始めること）を書き出し、その日付をカレンダーに入れる。その日になってからではなく、その前に決める。他の作業を止めている決定や、レイヤ分けのように後のすべてを形づくる決定を先送りする口実には使わない。
第107条 遅延コスト
歯止め：開発時間の取り置き
エンジニアリングの仕事に一件ずつ順位を勝ち取らせるのではなく、人手の取り分をルールで決めておく。Google は SRE の運用作業を時間の50%までに抑え、"Their remaining time should be spent using their coding skills on project work." としている。SRE 本は遅延コストの話をしていないが、本項の読みでは、決まった取り分があれば負債の返済のように一週間あたりの損が小さく見え、順位の上に来にくい仕事を守れる
どうするか
バックログの上位について、一週間待たせるごとに失う額を見積り、その前提を数字の横に書く。それを見込み期間で割り、その順に着手する。幅のある大まかな見積りで構わない。狙いは正確さではなく、各自の見積りがどれだけ食い違っているかを表に出すことだ。効果が長期にわたる仕事のために、順位の外に一定の人手を残しておく。
第106条 致命的な三点セット
歯止め：道具ではなく流れを縛る
役に立つアシスタントは三つを同時に要することが多い。Google DeepMind の CaMeL のような設計は、信頼できる利用者の依頼だけから手順を組み、データに権限の印をつけて三つとも残す。そうすれば、CaMeL が追跡する制御とデータの流れの範囲では、信頼できない内容がどの手順を実行するかを変えることも、ポリシーが禁じる先へ非公開データを送ることもできない。エージェントを自分で作るなら、能力を一つ外すよりこちらが合うこともある。ただし、こなせるタスクは減る。論文によれば、ベンチマーク AgentDojo で CaMeL は77%、防御なしのエージェントは84%だった
どうするか
エージェントにツールをつなぐ前に、そのツールが三つのどれを足すかを書き出す。非公開データ、信頼できない内容、外へ送る手段(リンク、画像の読み込み、プルリクエスト、メールを含む)だ。一つのセッションに三つがそろったら、一つを外す。認証情報のないサンドボックスで閲覧させる、送信経路を断つ、外への送信は一件ずつ人が承認する、のどれかにする。プロンプトインジェクションのフィルタを対策として数えない。信頼できるデータだけを読むエージェントや、出力が手元から出ないエージェントには要らない。
第109条意思決定
プレモーテム
すでに決まった計画に疑問を持つ人は、黙っていることが多い。失敗はもう起きたことにして、その理由を説明してもらうと、疑問が表に出てくる。
計画はもう失敗したと考え、理由を見つけた人が賢い場にする
第110条意思決定
厄介な問題
問題によっては、何が問題かを見極めることと解決策を選ぶことが同じ作業になる。だから設計を始める前に要求を固めることはできず、ここで終わりという地点もない。
解くたびに問題が変わるなら、問題の書き方は関門でなく下書きだ
第111条意思決定
大半のアイデアは失敗する
大手 Web 企業のオンライン対照実験では、チームが自分たちでふるいにかけた後のアイデアでも、測ってみると大半は効果がないか逆効果で、どれがそうかを専門家が事前に見分けるのも苦手なことが多い。
気に入っている案ほど、たぶん外れる仮説として扱う
第112条性能
キングマンの公式
サーバの稼働率が 100% に近づくほど、仕事がその前で待つ時間は急に伸びる。到着と処理のばらつきは、その伸びをさらに大きくする。
誰かが答えを待つところには、余裕を残す
第113条組織
メイカーの時間割、マネージャーの時間割
ものを作る人には途切れない長い時間が要る。一時間刻みで回る予定表は、その時間を使えないほど細かく切ってしまう。
会議の代償は、一時間ではなく壊す時間のまとまりで数える
第114条意思決定
マクナマラの誤謬
判断は数えられるものに寄っていき、やがて数えられないものは存在しないかのように扱われる。
数えられないものも、数字の横に名前を書いておく
第115条認知
トワイマンの法則
それほど大きな本物の効果がめったにない場で指標が驚くほど大きく動いたら、本当の効果より、計測か分析のバグであることのほうが多い。
意外な数字は、確かめるまでバグ報告として扱う
第116条組織
心理的安全性
チームが学べるのは、メンバーが間違いを認め、助けを求め、異を唱えるときだ。人がそうしやすくなるのは、そうしても安全だと信じているときだ。
「間違えた」「知らない」を言いやすくしておく
第111条 大半のアイデアは失敗する
歯止め：確信への賭け
対照実験にそもそもかけられない決定もある。同じ論文は、実験が向くのは戦略の実行で戦略の立案ではなく、"not suited for assessing a major change in business models, a large merger or acquisition" だという Davenport の指摘に同意し、測るのが "non-economical" な場合があることも認めている。本項の読みでは、そこでは誰かが判断で決めるしかない
どうするか
作る前に、そのアイデアで動かしたい指標とその幅を書いておき、フラグの裏に置いてランダムに選んだ一部の利用者に出す。指標が動かなければ、チームがどれだけ自信を持っていても捨てるか作り直す。ランダムに割り振れないとき（トラフィックが少ない、長期の賭け、戻せない変更）はそう明記し、測ったふりをせずに判断で決める。
第110条 厄介な問題
歯止め：まず問題を理解する
Pólya の方法は "You have to understand the problem." で始まり、計画を立てる前に "What is the unknown?" と問う。バグや移行、レイテンシの目標のような技術の仕事の多くは、先に未知のもの、与えられたもの、条件を書き出すことで解けるようになる。そうした仕事を「厄介な問題」と呼ぶのは、その手順を飛ばす言い訳になる
どうするか
要求を書く前に二つ確かめる。誰かが解決策を出すたびに問題の書き方が変わるか。解けたと判定できるテストがないか。両方とも当てはまるなら、要求を先に固めようとしない。意見の違う人を同じレビューに集め、小さな版を早く見せ、いつやめるかを先に決めておく。問題のほうは終わりを教えてくれない。どちらかが当てはまらないなら、飼いならされた問題として扱い、問題記述を書く。
第109条 プレモーテム
歯止め：行動を優先する
どの計画でも失敗探しをすると、慎重になりすぎる。Klein 自身、プレモーテムは "tend to encourage risk aversion" と書いている。安く戻せる一歩なら、失敗を想像するより試したほうが多くを学べる
どうするか
失敗すると痛いプロジェクトでは、キックオフで計画の説明が終わったら、このプロジェクトは失敗したとチームに告げる。各自に二分間、一人で理由を書かせ、それから一人一つずつ順に、リストが尽きるまで読み上げてもらう。上位のいくつかには担当者と計画の変更を割り当てる。小さく戻せる変更ではやらない。出して様子を見るほうが安い。
第114条 マクナマラの誤謬
歯止め：それでも測る
測れないように見えるものの多くは粗くなら測れる。粗い数字でも、確かめていない勘よりは多くを教えてくれる。Hubbard は、何かが測れないという思い込みは誤解に基づいていると論じる（『How to Measure Anything』2007年）
どうするか
ダッシュボードで判断するときは、ダッシュボードに出てこないが大事なもの（利用者の信頼、オンコールの負担、コードの健全さなど）を書き出し、少なくとも一つは直接見たものかアンケートを数字の横に置く。SPACE の著者も、開発者の生産性は単一の指標や次元では測れないと書いている。一つのエンドポイントのレイテンシのように、狭くて計測が行き届いた問いなら数字だけで足りる。
第113条 メイカーの時間割、マネージャーの時間割
歯止め：ラインを止めて対処する
トヨタは、問題が起きたら誰でもラインを止められるようにして、問題を後工程に溜めずにその場で扱う。メイカーのまとまった時間を同じように守りすぎるチームは、止まっている仲間や欠陥を、その後ろで待たせてしまうことがある
どうするか
会議は一日の端に寄せるか、決まった曜日にまとめる。作る人には、会議のない半日以上のまとまりを残す。メイカーの予定を押さえる前に、取る一時間ではなく壊すまとまりを数える。障害対応はすぐ答える。レビューを待っているチームメイトには、次の区切りで、遅くとも一日以内に答える。
第112条 キングマンの公式
歯止め：余裕にも金がかかる
余らせた容量は、使われなくても費用がかかる。だから予算を持つ側は稼働率を上げようとし、それが正しいことも多い。Google の SRE 本は "Efficient use of resources is important any time a service cares about money." と書き、容量の確保がサービスの総費用を大きく左右すると見ている。答えが遅くなっても損が小さいところでは、詰めて回して浮いたお金をもっと大事な仕事に回せる
どうするか
レイテンシが問題になるもの（サービス、共有のビルドランナー、オンコール担当）には、飽和より下に稼働率の上限を決める。サーバが一台、担当が一人ならかなり下に置き、代わりの利く担当が何人もいるプールなら、もっと満杯に近づけて回してよい。上限を超えたら容量を足すか負荷を捨てる。レイテンシが跳ねてからでは遅い。ばらつきも減らす。仕事を小さく揃えれば、同じ負荷でも待ちは短くなる。上限は、答えが遅くなる損と遊ばせる容量の費用を比べて決め、待ちの安いところでは上げる。
第116条 心理的安全性
歯止め：説明責任の実感
Higgins らがニューヨーク市の公立学校545校を3年間追った研究では、成果が最も高かったのは心理的安全性が相対的に低く、説明責任の実感が相対的に高い学校だった。Edmondson のモデルが言う両方とも高い学校ではない。彼らは心理的安全性を「ひとつまみのイースト」にたとえる。成果が伸びないときは、居心地を足す前に、共有の目標への説明責任を上げる（Academy of Management Discoveries, 2022年）
どうするか
まずリーダーがやって見せる。自分のミスと分からないことを口に出し、決める前に反対意見を求め、悪い知らせには知らせた人に礼を言って仕組みを直す。水準と締切は動かさない。心理的安全性は声を上げられることであって、基準を下げることではない。Edmondson 本人も「心理的安全性だけをつくるなら、それはコンフォートゾーンをつくっているにすぎない」と言う。
第115条 トワイマンの法則
歯止め：ささいな変更が大きく効くこともある
同じ論文のルール1。ささいな変更が主要な指標を大きく動かすことがある。Bing のフォントの色の変更は年間1000万ドル以上の価値があった。大きな勝ちをすべてバグ扱いするチームは、それを見つける安くて当たりにくい実験をやめてしまう
どうするか
過去の実験よりはるかに良い、あるいは悪い結果が出たら、発表を止めてまず配管を確かめる。指標がどう記録されているか、変更が記録される中身を変えていないか、分析が同じものどうしを比べているか。そのうえで新しいサンプルで再現する。予想どおりのふつうの動きには、ここまでしなくてよい。