https://kanywst.github.io/hammurabi/ja/ エンジニアリングの法則と、その歯止め。 ja https://kanywst.github.io/hammurabi/ja/laws/psychological-safety/ https://kanywst.github.io/hammurabi/ja/laws/psychological-safety/ チームが学べるのは、メンバーが間違いを認め、助けを求め、異を唱えるときだ。人がそうしやすくなるのは、そうしても安全だと信じているときだ。 https://kanywst.github.io/hammurabi/ja/laws/twymans-law/ https://kanywst.github.io/hammurabi/ja/laws/twymans-law/ それほど大きな本物の効果がめったにない場で指標が驚くほど大きく動いたら、本当の効果より、計測か分析のバグであることのほうが多い。 https://kanywst.github.io/hammurabi/ja/laws/mcnamara-fallacy/ https://kanywst.github.io/hammurabi/ja/laws/mcnamara-fallacy/ 判断は数えられるものに寄っていき、やがて数えられないものは存在しないかのように扱われる。 https://kanywst.github.io/hammurabi/ja/laws/makers-schedule/ https://kanywst.github.io/hammurabi/ja/laws/makers-schedule/ ものを作る人には途切れない長い時間が要る。一時間刻みで回る予定表は、その時間を使えないほど細かく切ってしまう。 https://kanywst.github.io/hammurabi/ja/laws/kingmans-formula/ https://kanywst.github.io/hammurabi/ja/laws/kingmans-formula/ サーバの稼働率が 100% に近づくほど、仕事がその前で待つ時間は急に伸びる。到着と処理のばらつきは、その伸びをさらに大きくする。 https://kanywst.github.io/hammurabi/ja/laws/most-ideas-fail/ https://kanywst.github.io/hammurabi/ja/laws/most-ideas-fail/ 大手 Web 企業のオンライン対照実験では、チームが自分たちでふるいにかけた後のアイデアでも、測ってみると大半は効果がないか逆効果で、どれがそうかを専門家が事前に見分けるのも苦手なことが多い。 https://kanywst.github.io/hammurabi/ja/laws/wicked-problems/ https://kanywst.github.io/hammurabi/ja/laws/wicked-problems/ 問題によっては、何が問題かを見極めることと解決策を選ぶことが同じ作業になる。だから設計を始める前に要求を固めることはできず、ここで終わりという地点もない。 https://kanywst.github.io/hammurabi/ja/laws/pre-mortem/ https://kanywst.github.io/hammurabi/ja/laws/pre-mortem/ すでに決まった計画に疑問を持つ人は、黙っていることが多い。失敗はもう起きたことにして、その理由を説明してもらうと、疑問が表に出てくる。 https://kanywst.github.io/hammurabi/ja/laws/last-responsible-moment/ https://kanywst.github.io/hammurabi/ja/laws/last-responsible-moment/ 早く決めすぎると推測がそのまま設計として固まる。待ちすぎると選択肢が黙って消え、誰も決めないまま成り行きで決まってしまう。 https://kanywst.github.io/hammurabi/ja/laws/cost-of-delay/ https://kanywst.github.io/hammurabi/ja/laws/cost-of-delay/ 仕事は大きさや勘、声の大きさで並べられ、待たせた週ごとに失う価値は数えられない。だから一番価値のある仕事が、目立つだけの仕事の後ろで待たされることが多い。 https://kanywst.github.io/hammurabi/ja/laws/lethal-trifecta/ https://kanywst.github.io/hammurabi/ja/laws/lethal-trifecta/ 非公開データを読めて、外から来た内容を取り込み、外へデータを送れる AI エージェントは、その内容を書いた誰にでも操られてデータを漏らしうる。 https://kanywst.github.io/hammurabi/ja/laws/test-oracle-problem/ https://kanywst.github.io/hammurabi/ja/laws/test-oracle-problem/ テストが誤った答えを捕まえられるのは、コードとは別に正しい答えを知っているものがあるときだけだ。そして多くのプログラムには、それがない。 https://kanywst.github.io/hammurabi/ja/laws/programming-as-theory-building/ https://kanywst.github.io/hammurabi/ja/laws/programming-as-theory-building/ プログラムの設計は作った人たちの頭の中にあり、コードや文書が運べるのはその一部だけだ。だから作った人たちがいなくなると、文書がそろっていても、変更を重ねるうちに設計が崩れやすい。 https://kanywst.github.io/hammurabi/ja/laws/small-changes/ https://kanywst.github.io/hammurabi/ja/laws/small-changes/ レビューに出す変更が大きいほど、一行ずつは丁寧に読まれなくなる。欠陥はすり抜け、最初に見てもらうまでの待ちも長くなる。 https://kanywst.github.io/hammurabi/ja/laws/automation-bias/ https://kanywst.github.io/hammurabi/ja/laws/automation-bias/ 自動化された補助を使う人は、自分で確かめる代わりにそれを頼りがちだ。補助が指摘しないものを見落とし、補助が間違っていてもそれに従う。 https://kanywst.github.io/hammurabi/ja/laws/brandolinis-law/ https://kanywst.github.io/hammurabi/ja/laws/brandolinis-law/ 誤った主張を論破するには、それを言うよりはるかに手間がかかる。だから安い主張が大量に来ると、確かめる側の手が回らなくなりうる。 https://kanywst.github.io/hammurabi/ja/laws/braintrust/ https://kanywst.github.io/hammurabi/ja/laws/braintrust/ オーナーを覆せる人からの意見は、活かされるより先に防御の対象になる。修正を強制できない仲間なら率直に言えるし、オーナーも落ち着いて聞ける。 https://kanywst.github.io/hammurabi/ja/laws/believability-weighted-decisions/ https://kanywst.github.io/hammurabi/ja/laws/believability-weighted-decisions/ 集団がどの意見も同じ一票と数えたり、役職に従ったりすると、実際にそれをやったことのある人が、やったことのない人に多数決で負ける。 https://kanywst.github.io/hammurabi/ja/laws/genchi-genbutsu/ https://kanywst.github.io/hammurabi/ja/laws/genchi-genbutsu/ 報告をもとに下す判断は、実際に起きていることから離れていく。要約が一段挟まるたびに、その形式に収まらなかった細部が落ちるからだ。 https://kanywst.github.io/hammurabi/ja/laws/one-version-rule/ https://kanywst.github.io/hammurabi/ja/laws/one-version-rule/ 共有する依存先のどのバージョンを使うかを利用者が選べると、選ぶたびに、選んでいない誰かが衝突を抱える。 https://kanywst.github.io/hammurabi/ja/laws/narratives-not-slides/ https://kanywst.github.io/hammurabi/ja/laws/narratives-not-slides/ スライドと箇条書きに縮めた議論は、論点どうしのつながりを失う。文章なら露わになったはずの穴や警告が、気づかれないままレビューを通り抜ける。 https://kanywst.github.io/hammurabi/ja/laws/pesticide-paradox/ https://kanywst.github.io/hammurabi/ja/laws/pesticide-paradox/ バグを見つける方法はどれも、その方法では見つからないバグを残す。だから変わらないテストスイートが見つけるバグは減っていく。 https://kanywst.github.io/hammurabi/ja/laws/bus-factor/ https://kanywst.github.io/hammurabi/ja/laws/bus-factor/ システムを動かし続けられる人が少ないほど、その将来は一人ひとりが辞めずにいることにかかってくる。 https://kanywst.github.io/hammurabi/ja/laws/lehmans-laws/ https://kanywst.github.io/hammurabi/ja/laws/lehmans-laws/ 実際に使われているプログラムは、変わり続けなければ役に立たなくなる。そして変えるたびに、手をかけて単純にしない限り複雑になっていく。 https://kanywst.github.io/hammurabi/ja/laws/technical-debt/ https://kanywst.github.io/hammurabi/ja/laws/technical-debt/ 問題を十分に理解する前に出したコードは、誰かが書き直すまで、そのコードをその後変えるたびに余計なコストを生む。 https://kanywst.github.io/hammurabi/ja/laws/choose-boring-technology/ https://kanywst.github.io/hammurabi/ja/laws/choose-boring-technology/ 不慣れな技術を採り入れるたびに、未知の故障モードと恒久的な運用コストが付いてくる。チームが抱えられる数は多くない。 https://kanywst.github.io/hammurabi/ja/laws/strangler-fig/ https://kanywst.github.io/hammurabi/ja/laws/strangler-fig/ 稼働中のシステムは、一度に置き換えるより、周縁から少しずつ置き換えるほうがたいてい安全だ。 https://kanywst.github.io/hammurabi/ja/laws/fixed-time-variable-scope/ https://kanywst.github.io/hammurabi/ja/laws/fixed-time-variable-scope/ スコープを固定して時間を固定しないと、ずれるのは期日で、スコープは残る。時間を固定すれば、何が大事かを選ばざるを得なくなる。 https://kanywst.github.io/hammurabi/ja/laws/churn-rule/ https://kanywst.github.io/hammurabi/ja/laws/churn-rule/ 共有基盤を変えるチームが移行作業を利用者に押しつけられると、変更のコストは利用者の数だけ膨らむ。 https://kanywst.github.io/hammurabi/ja/laws/beyonce-rule/ https://kanywst.github.io/hammurabi/ja/laws/beyonce-rule/ 共有コードベースでは、どのテストも確かめていない挙動こそが予告なく変わる。 https://kanywst.github.io/hammurabi/ja/laws/code-health-standard/ https://kanywst.github.io/hammurabi/ja/laws/code-health-standard/ すべての変更に完璧を求めるとレビューが遅くなり、遅いレビューはコードベースを良くするどころか悪くする。 https://kanywst.github.io/hammurabi/ja/laws/context-not-control/ https://kanywst.github.io/hammurabi/ja/laws/context-not-control/ 組織が大きくなるほど、ルールと承認は共有された理解ほどにはスケールしにくい。手順を渡された人より目標の背景を渡された人のほうが現場でよい判断をする、というのが Netflix の主張だ。 https://kanywst.github.io/hammurabi/ja/laws/chaos-engineering/ https://kanywst.github.io/hammurabi/ja/laws/chaos-engineering/ 一度も試されていない耐障害性は仮説にすぎない。予定を組もうと組むまいと、本番がいずれそれを試す。 https://kanywst.github.io/hammurabi/ja/laws/five-whys/ https://kanywst.github.io/hammurabi/ja/laws/five-whys/ 「なぜ失敗したか」への最初の答えはたいてい症状だ。症状だけを直しても原因は残り、また同じ失敗が起きる。 https://kanywst.github.io/hammurabi/ja/laws/andon/ https://kanywst.github.io/hammurabi/ja/laws/andon/ 異常に気づいた人が誰でもラインを止められれば、欠陥は下流へ流れない。下流で見つかれば、見つけるのも直すのも高くつく。 https://kanywst.github.io/hammurabi/ja/laws/mechanisms-not-good-intentions/ https://kanywst.github.io/hammurabi/ja/laws/mechanisms-not-good-intentions/ 失敗のあとで「もっと気をつけろ」と求めても、ほとんど何も変わらない。失敗した人は、もともと気をつけていたからだ。 https://kanywst.github.io/hammurabi/ja/laws/constant-work/ https://kanywst.github.io/hammurabi/ja/laws/constant-work/ 変更や障害の数に応じて仕事が増えるシステムは、余力がいちばん少ないときにいちばん多くの仕事をする。 https://kanywst.github.io/hammurabi/ja/laws/avoid-fallback/ https://kanywst.github.io/hammurabi/ja/laws/avoid-fallback/ フォールバック経路は何かがすでに失敗したあとでしか動かない。だから、システムでいちばん試されていないコードが最悪の条件で動く。 https://kanywst.github.io/hammurabi/ja/laws/static-stability/ https://kanywst.github.io/hammurabi/ja/laws/static-stability/ 障害を乗り切るのに新しい動作が必要なシステムは、状況がいちばん悪いときにその動作が成功することに頼っている。 https://kanywst.github.io/hammurabi/ja/laws/you-build-it-you-run-it/ https://kanywst.github.io/hammurabi/ja/laws/you-build-it-you-run-it/ サービスを作るチームが運用も担えば、運用上の弱点のコストは、それを直せる人のところに落ちる。 https://kanywst.github.io/hammurabi/ja/laws/disagree-and-commit/ https://kanywst.github.io/hammurabi/ja/laws/disagree-and-commit/ 全員の同意を待つより、決めて実行し、誤りなら軌道修正するほうが速いことが多い。 https://kanywst.github.io/hammurabi/ja/laws/working-backwards/ https://kanywst.github.io/hammurabi/ja/laws/working-backwards/ 解決策から始めると、誰も必要としないものを作ることが多い。発表文から始めれば早く気づける。 https://kanywst.github.io/hammurabi/ja/laws/blameless-postmortem/ https://kanywst.github.io/hammurabi/ja/laws/blameless-postmortem/ 障害のいちばん近くにいた人を罰すると、人は自分のしたことを隠すようになる。 https://kanywst.github.io/hammurabi/ja/laws/toil/ https://kanywst.github.io/hammurabi/ja/laws/toil/ 手作業の繰り返し運用はサービスと一緒に増え、放っておけば開発の時間を食い尽くす。 https://kanywst.github.io/hammurabi/ja/laws/error-budget/ https://kanywst.github.io/hammurabi/ja/laws/error-budget/ 100% 未満の SLO は許容できる失敗の量を決める。その量は使ってよい予算だ。 https://kanywst.github.io/hammurabi/ja/laws/shirky-principle/ https://kanywst.github.io/hammurabi/ja/laws/shirky-principle/ 組織は、自分たちが存在する理由である問題を残そうとする。 https://kanywst.github.io/hammurabi/ja/laws/ringelmann-effect/ https://kanywst.github.io/hammurabi/ja/laws/ringelmann-effect/ 集団が大きくなるほど、一人ひとりが出す力は減る。誰の成果か見えないと特にそうだ。 https://kanywst.github.io/hammurabi/ja/laws/metcalfes-law/ https://kanywst.github.io/hammurabi/ja/laws/metcalfes-law/ ノードが一つ増えるたびに既存の全ノードの価値が上がり、価値は規模より速く増える。 https://kanywst.github.io/hammurabi/ja/laws/the-bitter-lesson/ https://kanywst.github.io/hammurabi/ja/laws/the-bitter-lesson/ AIでは長い目で見ると、計算量とともに伸びる汎用手法が、人が作り込んだ知識に勝ってきた。 https://kanywst.github.io/hammurabi/ja/laws/amaras-law/ https://kanywst.github.io/hammurabi/ja/laws/amaras-law/ 新しい技術は、最初の数年は過大評価され、十年単位では過小評価される。 https://kanywst.github.io/hammurabi/ja/laws/moores-law/ https://kanywst.github.io/hammurabi/ja/laws/moores-law/ 部品単価が最も安くなるチップのトランジスタ数は、約2年ごとに倍になる。 https://kanywst.github.io/hammurabi/ja/laws/second-system-effect/ https://kanywst.github.io/hammurabi/ja/laws/second-system-effect/ 最初の成功のあと、設計者は先送りしたアイデアを二作目に詰め込みがちだ。 https://kanywst.github.io/hammurabi/ja/laws/principle-of-least-astonishment/ https://kanywst.github.io/hammurabi/ja/laws/principle-of-least-astonishment/ 利用者を驚かせる挙動は、少し劣っても予想どおりの挙動より高くつく。 https://kanywst.github.io/hammurabi/ja/laws/single-responsibility-principle/ https://kanywst.github.io/hammurabi/ja/laws/single-responsibility-principle/ 二つの利用者グループに使われるモジュールには、両方から食い違う変更要求が届く。 https://kanywst.github.io/hammurabi/ja/laws/occams-razor/ https://kanywst.github.io/hammurabi/ja/laws/occams-razor/ 検証されていない仮定が最も少ない説明が、たいてい正しい。 https://kanywst.github.io/hammurabi/ja/laws/theory-of-constraints/ https://kanywst.github.io/hammurabi/ja/laws/theory-of-constraints/ システムの処理量は、最も詰まっている一か所で決まる。 https://kanywst.github.io/hammurabi/ja/laws/dry-principle/ https://kanywst.github.io/hammurabi/ja/laws/dry-principle/ 同じ知識を二か所に置くと、一緒に変わる保証がないので食い違っていく。 https://kanywst.github.io/hammurabi/ja/laws/kiss-principle/ https://kanywst.github.io/hammurabi/ja/laws/kiss-principle/ システムは、普通の人が悪条件の中でも直せる程度に単純である必要がある。 https://kanywst.github.io/hammurabi/ja/laws/yagni/ https://kanywst.github.io/hammurabi/ja/laws/yagni/ 想像した将来のために書いたコードは、今の工数を食い、実際の要件に合うこともまれだ。 https://kanywst.github.io/hammurabi/ja/laws/broken-windows-theory/ https://kanywst.github.io/hammurabi/ja/laws/broken-windows-theory/ 放置された小さな乱れは、基準は守らなくてよいという合図になり、さらに乱れを呼びやすい。 https://kanywst.github.io/hammurabi/ja/laws/normal-accident-theory/ https://kanywst.github.io/hammurabi/ja/laws/normal-accident-theory/ 複雑で密に結合したシステムでは、事故は構造そのものから生じる。 https://kanywst.github.io/hammurabi/ja/laws/jevons-paradox/ https://kanywst.github.io/hammurabi/ja/laws/jevons-paradox/ 資源を安く使えるようにすると、かえって総使用量が増えることがある。 https://kanywst.github.io/hammurabi/ja/laws/law-of-demeter/ https://kanywst.github.io/hammurabi/ja/laws/law-of-demeter/ 他のオブジェクトの内部をたどるコードは、その連鎖のどこが変わっても壊れる。 https://kanywst.github.io/hammurabi/ja/laws/ashbys-law/ https://kanywst.github.io/hammurabi/ja/laws/ashbys-law/ 制御側は、対象がとりうる状態と同じだけの対応を持たないと制御できない。 https://kanywst.github.io/hammurabi/ja/laws/tail-at-scale/ https://kanywst.github.io/hammurabi/ja/laws/tail-at-scale/ 一つのリクエストが多数のサーバに分かれると、最も遅いサーバが応答時間を決める。 https://kanywst.github.io/hammurabi/ja/laws/gustafsons-law/ https://kanywst.github.io/hammurabi/ja/laws/gustafsons-law/ 問題の規模が計算機とともに大きくなるなら、並列化の効果はほぼ比例して伸びる。 https://kanywst.github.io/hammurabi/ja/laws/kerckhoffs-principle/ https://kanywst.github.io/hammurabi/ja/laws/kerckhoffs-principle/ 設計が秘密である間だけ安全なシステムは、安全ではない。 https://kanywst.github.io/hammurabi/ja/laws/principle-of-least-privilege/ https://kanywst.github.io/hammurabi/ja/laws/principle-of-least-privilege/ 不要な権限を持つ部品ほど、問題が起きたときの被害範囲が広がる。 https://kanywst.github.io/hammurabi/ja/laws/ironies-of-automation/ https://kanywst.github.io/hammurabi/ja/laws/ironies-of-automation/ 自動化は人に最も難しい例外だけを残し、その対応に要る腕は使わないうちに鈍る。 https://kanywst.github.io/hammurabi/ja/laws/fallacies-of-distributed-computing/ https://kanywst.github.io/hammurabi/ja/laws/fallacies-of-distributed-computing/ ネットワーク越しのコードは、本番では成り立たない8つの前提を暗に置いている。 https://kanywst.github.io/hammurabi/ja/laws/millers-law/ https://kanywst.github.io/hammurabi/ja/laws/millers-law/ 作業記憶に保てるのは数個のまとまりだけだ（Miller は7前後とし、後の研究はもっと少ないとする）。 https://kanywst.github.io/hammurabi/ja/laws/fitts-law/ https://kanywst.github.io/hammurabi/ja/laws/fitts-law/ 小さく遠いターゲットほど、押すのに時間がかかり、押し間違えも増える。 https://kanywst.github.io/hammurabi/ja/laws/hicks-law/ https://kanywst.github.io/hammurabi/ja/laws/hicks-law/ 選択肢が増えるほど、人は一つを選ぶのに時間がかかる。 https://kanywst.github.io/hammurabi/ja/laws/eaglesons-law/ https://kanywst.github.io/hammurabi/ja/laws/eaglesons-law/ 半年見ていない自分のコードは、他人が書いたコードも同然だ。 https://kanywst.github.io/hammurabi/ja/laws/ninety-ninety-rule/ https://kanywst.github.io/hammurabi/ja/laws/ninety-ninety-rule/ 残り1割の作業に、最初の9割と同じくらいの時間がかかりがちだ。 https://kanywst.github.io/hammurabi/ja/laws/wirths-law/ https://kanywst.github.io/hammurabi/ja/laws/wirths-law/ ソフトウェアが遅くなる速さは、ハードウェアが速くなる速さを上回る。 https://kanywst.github.io/hammurabi/ja/laws/parkinsons-law/ https://kanywst.github.io/hammurabi/ja/laws/parkinsons-law/ 仕事は、完了までに使える時間をすべて使い切るまで膨らむ。 https://kanywst.github.io/hammurabi/ja/laws/peter-principle/ https://kanywst.github.io/hammurabi/ja/laws/peter-principle/ 人は苦手な役職にたどり着くまで昇進し、そこにとどまりがちだ。 https://kanywst.github.io/hammurabi/ja/laws/two-generals-problem/ https://kanywst.github.io/hammurabi/ja/laws/two-generals-problem/ 信頼できない通信路では、二者は合意できたと確信できない。 https://kanywst.github.io/hammurabi/ja/laws/littles-law/ https://kanywst.github.io/hammurabi/ja/laws/littles-law/ 安定した系では、系の中にある件数の平均は、到着率と平均滞在時間の積に等しい。 https://kanywst.github.io/hammurabi/ja/laws/cap-theorem/ https://kanywst.github.io/hammurabi/ja/laws/cap-theorem/ ネットワーク分断が起きたら、データストアは一貫性か可用性のどちらかを捨てる。 https://kanywst.github.io/hammurabi/ja/laws/linus-law/ https://kanywst.github.io/hammurabi/ja/laws/linus-law/ 一人では見つからないバグも、同じコードを見る別の人にはあっさり分かることが多い。 https://kanywst.github.io/hammurabi/ja/laws/premature-optimization/ https://kanywst.github.io/hammurabi/ja/laws/premature-optimization/ 計測する前に最適化すると、ボトルネックでない箇所に工数を使ってしまう。 https://kanywst.github.io/hammurabi/ja/laws/swiss-cheese-model/ https://kanywst.github.io/hammurabi/ja/laws/swiss-cheese-model/ どの防御層にも穴がある。事故は複数の層の穴がそろったときに起きる。 https://kanywst.github.io/hammurabi/ja/laws/curse-of-knowledge/ https://kanywst.github.io/hammurabi/ja/laws/curse-of-knowledge/ 一度知ってしまうと、知らなかったときの感覚を想像できなくなる。 https://kanywst.github.io/hammurabi/ja/laws/dunning-kruger-effect/ https://kanywst.github.io/hammurabi/ja/laws/dunning-kruger-effect/ ある分野に疎い人ほど、自分の能力を過大評価しがちだ。 https://kanywst.github.io/hammurabi/ja/laws/teslers-law/ https://kanywst.github.io/hammurabi/ja/laws/teslers-law/ システムに本来備わる複雑さは消せない。誰か別の人に移るだけだ。 https://kanywst.github.io/hammurabi/ja/laws/boy-scout-rule/ https://kanywst.github.io/hammurabi/ja/laws/boy-scout-rule/ コードが劣化するのは、片付けが、めったに実施されないリファクタリングに先送りされがちだからだ。 https://kanywst.github.io/hammurabi/ja/laws/murphys-law/ https://kanywst.github.io/hammurabi/ja/laws/murphys-law/ 時間と負荷が十分にあれば、起こりうる故障はいずれ起きる。 https://kanywst.github.io/hammurabi/ja/laws/bystander-effect/ https://kanywst.github.io/hammurabi/ja/laws/bystander-effect/ 問題を目にする人が多いほど、一人ひとりが自分から動く可能性は下がる。 https://kanywst.github.io/hammurabi/ja/laws/cunninghams-law/ https://kanywst.github.io/hammurabi/ja/laws/cunninghams-law/ 人は質問に答えるより、間違った答えを訂正するほうに熱心だ。 https://kanywst.github.io/hammurabi/ja/laws/worse-is-better/ https://kanywst.github.io/hammurabi/ja/laws/worse-is-better/ 作りやすく広めやすい単純な設計は、正しいが複雑な設計に勝ちやすい。 https://kanywst.github.io/hammurabi/ja/laws/dunbars-number/ https://kanywst.github.io/hammurabi/ja/laws/dunbars-number/ 人が安定して保てる関係は150人ほどだ。エンジニアリングではそこから、文脈を共有できる規模を超えると増員分は調整に消えると類推している。 https://kanywst.github.io/hammurabi/ja/laws/cobra-effect/ https://kanywst.github.io/hammurabi/ja/laws/cobra-effect/ 問題を減らすための報酬が、問題を増やす行動に報いてしまう。 https://kanywst.github.io/hammurabi/ja/laws/kernighans-law/ https://kanywst.github.io/hammurabi/ja/laws/kernighans-law/ デバッグは書くより難しい。だから、最大限に凝って書いたコードは自分でもデバッグできない。 https://kanywst.github.io/hammurabi/ja/laws/survivorship-bias/ https://kanywst.github.io/hammurabi/ja/laws/survivorship-bias/ 成功例だけから結論を出すと、同じやり方で失敗した例が見えなくなる。 https://kanywst.github.io/hammurabi/ja/laws/pareto-principle/ https://kanywst.github.io/hammurabi/ja/laws/pareto-principle/ 結果の大半は少数の原因から生まれる。たとえば、バグは一部のモジュールに集中する。 https://kanywst.github.io/hammurabi/ja/laws/leaky-abstractions/ https://kanywst.github.io/hammurabi/ja/laws/leaky-abstractions/ 込み入った抽象化はいずれ、隠したはずの下の層の詳細を露出させる。 https://kanywst.github.io/hammurabi/ja/laws/amdahls-law/ https://kanywst.github.io/hammurabi/ja/laws/amdahls-law/ ボトルネックが別の場所にあれば、一部を速くしても全体はほとんど速くならない。 https://kanywst.github.io/hammurabi/ja/laws/cargo-cult-engineering/ https://kanywst.github.io/hammurabi/ja/laws/cargo-cult-engineering/ うまくいった理由を理解しないまま、他社のやり方の形だけを真似る。 https://kanywst.github.io/hammurabi/ja/laws/sunk-cost-fallacy/ https://kanywst.github.io/hammurabi/ja/laws/sunk-cost-fallacy/ すでに注ぎ込んだ分が惜しくて、失敗しているプロジェクトに投資し続ける。 https://kanywst.github.io/hammurabi/ja/laws/lindy-effect/ https://kanywst.github.io/hammurabi/ja/laws/lindy-effect/ アイデアやソフトウェアは、長く生き残ったものほどこの先も長く残る可能性が高い。 https://kanywst.github.io/hammurabi/ja/laws/goodharts-law/ https://kanywst.github.io/hammurabi/ja/laws/goodharts-law/ 数字を動かすことに報酬がつくと、その数字は実態を測らなくなる。 https://kanywst.github.io/hammurabi/ja/laws/hofstadters-law/ https://kanywst.github.io/hammurabi/ja/laws/hofstadters-law/ 作業は見積りより長くかかる。それを織り込んで見積もっても、やはり長くかかる。 https://kanywst.github.io/hammurabi/ja/laws/hanlons-razor/ https://kanywst.github.io/hammurabi/ja/laws/hanlons-razor/ 疲労や文脈不足で説明がつく遅れやバグに、人は悪意を読み取ってしまう。 https://kanywst.github.io/hammurabi/ja/laws/postels-law/ https://kanywst.github.io/hammurabi/ja/laws/postels-law/ 相手が仕様どおりに動く前提のシステムは、最初の逸脱にもろくなりがちだ。 https://kanywst.github.io/hammurabi/ja/laws/xy-problem/ https://kanywst.github.io/hammurabi/ja/laws/xy-problem/ 人は本当の問題ではなく、自分が試している解決策について助けを求める。 https://kanywst.github.io/hammurabi/ja/laws/brooks-law/ https://kanywst.github.io/hammurabi/ja/laws/brooks-law/ 遅れたプロジェクトに人を足すと、立ち上がりと調整にかかる手間が、増えた人の働きを上回り、かえって遅れがちだ。 https://kanywst.github.io/hammurabi/ja/laws/hyrums-law/ https://kanywst.github.io/hammurabi/ja/laws/hyrums-law/ 利用者が十分に多ければ、バグも含めた観測可能な挙動すべてに誰かが依存する。 https://kanywst.github.io/hammurabi/ja/laws/conways-law/ https://kanywst.github.io/hammurabi/ja/laws/conways-law/ システムの構造は、作るチーム同士の意思疎通の形に似てくる。 https://kanywst.github.io/hammurabi/ja/laws/galls-law/ https://kanywst.github.io/hammurabi/ja/laws/galls-law/ 動く複雑なシステムは、たいてい動く単純なシステムから育ったものだ。最初から設計したものが動くことはまれだ。 https://kanywst.github.io/hammurabi/ja/laws/law-of-triviality/ https://kanywst.github.io/hammurabi/ja/laws/law-of-triviality/ 議論は重要な部分ではなく、誰でも口を出せる簡単な部分に集中する。 https://kanywst.github.io/hammurabi/ja/laws/normalcy-bias/ https://kanywst.github.io/hammurabi/ja/laws/normalcy-bias/ 本物の異常を前にしても、人はいつもの無害な説明に飛びつく。 https://kanywst.github.io/hammurabi/ja/laws/chestertons-fence/ https://kanywst.github.io/hammurabi/ja/laws/chestertons-fence/ 経緯を知らないコードやルールは無駄に見え、理由も知らずに消したくなる。 https://kanywst.github.io/hammurabi/ja/laws/normalization-of-deviance/ https://kanywst.github.io/hammurabi/ja/laws/normalization-of-deviance/ すぐに害が出なかったルール違反は、いつの間にか当たり前になる。 https://kanywst.github.io/hammurabi/ja/laws/type-1-vs-type-2-decisions/ https://kanywst.github.io/hammurabi/ja/laws/type-1-vs-type-2-decisions/ やり直せる決定にまで、やり直せない決定と同じ慎重さを払ってしまう。