【エンジニアの教養】なぜかエンジニア界隈で有名な◯◯の法則的なやつをまとめてみた

Last updated at 2026-05-11Posted at 2026-05-11

前置き

こんばんは、mirukyです。

この間のGW中に、高校時代の先輩（テックリード）と飲みに行きました。
そのとき先輩が経験した炎上プロジェクトの話になり、先輩が「ブルックスの法則ってあるじゃん。まさしくあれになってさ」みたいなことを言っていたのですが、本で見たことはあったものの、お恥ずかしいことに、正直意味を思い出せませんでした。

これに限らずエンジニア界隈には、なぜかみんな知っている「◯◯の法則」「◯◯原則」「◯◯効果」みたいな言葉がたくさんあります。他の業種にも格言や経験則はありますが、エンジニア界隈は特にこういう言葉が会話に出てきやすいですよね。多分、哲学的な思想を重んじる英語圏文化（と、それを反映した書籍）の影響だと思ってます。

具体的な法則は、さきほどのブルックスの法則、コンウェイの法則、ハイラムの法則、ジョシュアツリーの法則、石のスープ、ゆでガエル、車輪の再発明、ヤクの毛刈り、などなどです。

別に覚える必要は無いのかもしれませんが、エンジニアの教養として、また自分の矜持としても覚えておきたいと思いました（失敗を繰り返さないように、、）。
レビューの時に役に立つものもあったりするので、この記事では、エンジニアがどこかで一度は聞く有名どころを、端的な意味と使いどころに絞って整理します。備忘録と思ってください。

この記事では、学術的な厳密さよりも「エンジニアが会話でよく使うか」「名著や古典的なソフトウェア工学の文脈で見かけるか」を重視しています。マイナーなものは意図的に省いています。

1. 法則系

星は、私の体感として「エンジニア界隈の会話やレビューでどれくらい術語として使われるか」を表した目安です。厳密なランキングではなく、技術記事、設計議論、コードレビューでの出現頻度くらいに見てください。

星	目安
★★★★★	星5つ。会話やレビューでかなりよく使われる
★★★★☆	星4つ。教養として知られ、設計や雑談で出ることがある
★★★☆☆	星3つ。知っている人はいるが、日常会話では少し減る
★★☆☆☆	星2つ。本や古典で見るが、普段はあまり聞かない
★☆☆☆☆	星1つ。かなりマイナー。この記事ではほぼ使っていません

まずは、ソフトウェア開発の現場で法則として扱われることが多いものです。

1-1. プロジェクトと組織の法則

$$
コンウェイの法則　★★★★☆
$$

システムの構造は、それを作る組織のコミュニケーション構造に似る、という法則です。

たとえば、認証チーム、決済チーム、在庫チームがまったく会話しない組織では、その断絶がAPI境界や画面遷移にも出やすくなります。アーキテクチャの話に見えて、実は組織設計の話でもあります。マイクロサービス分割、チーム分割、責務境界の議論でよく登場します。

$$
ブルックスの法則　★★★★☆
$$

遅れているソフトウェア開発に人を追加すると、さらに遅れることがある、という法則です。

「人を増やすな」という単純な話ではありません。新しく入った人への説明、認識合わせ、レビュー、マージ、意思決定の調整が増えるため、遅延プロジェクトに後から人を入れても即効性がない、という話です。炎上案件に人員追加する前の警告としてよく引用されます。

$$
パーキンソンの法則　★★★★☆
$$

仕事は、使える時間を満たすまで膨張する、という法則です。

締切が1週間なら1週間かかり、1か月なら1か月かかる。会議も同じで、30分で終わる議題でも1時間枠を取ると1時間使ってしまうことがあります。締切、レビュー期間、会議時間を短く区切る理由になります。夏休みの宿題は集中してやれば数週間で終わりますが、結局夏休み終わり頃にならないと終わらない、的なアレです。

$$
90-90の法則　★★★☆☆
$$

最初の90%のコードに開発時間の90%がかかり、残り10%のコードにさらに90%の時間がかかる、という皮肉です。トム・カーギルの言葉として知られ、ジョン・ベントリーのProgramming Pearlsでも紹介されました。

合計180%になるところがポイントです。「ほぼ完成です」「あとは微修正だけです」が、なぜ信用できないのかを説明してくれます。最後のエッジケース、例外処理、ドキュメント、テスト、運用まわりが想像以上に重い、という話です。これは、経験則的に理解できるのではないでしょうか。

$$
パーキンソンの凡俗法則　★★★☆☆
$$

人は重要で難しい問題より、わかりやすい些細な問題に時間を使いがち、という法則です。バイクシェッドとも呼ばれます。

原子炉の設計より、自転車置き場の色のほうが議論しやすい、というたとえが有名です。開発現場では、アーキテクチャの難問より、変数名、ボタンの色、文言の細部で会議が伸びる現象として現れます。

$$
ピーターの法則　★★★☆☆
$$

人は能力の限界に達するまで昇進し、そこで止まりやすい、という法則です。

優秀な開発者を管理職にすれば、必ず良いマネージャーになるわけではありません。開発者としての能力と、採用、評価、チーム設計、予算調整の能力は別物です。エンジニアリングマネージャーやテックリードの役割設計で思い出したい言葉です。

$$
ホフスタッターの法則　★★☆☆☆
$$

何かをするには予想より時間がかかる。たとえその法則を考慮しても、なお時間がかかる、という自己言及的な法則です。

見積もり、リリース計画、移行作業、レガシー刷新でよく刺さります。「余裕を見たつもりだったのに、それでも足りない」という現場の現実を短く表しています。

1-2. 設計とコードの法則

$$
ポステルの法則　★★★★☆
$$

送信は厳格に、受信は寛容に、というネットワークプロトコル由来の原則です。

TCP/IPの古いRFCで示されたRobustness Principleとして有名です。昔のインターネットでは、多少の揺れを受け入れる寛容さが相互接続性を高めました。ただし、現代のWebやセキュリティ文脈では、寛容すぎる受信が曖昧な仕様や脆弱性につながることもあります。入力検証では「寛容に受け入れすぎない」ことも大事です。

$$
デメテルの法則　★★★★☆
$$

オブジェクトは近い相手だけを知るべき、という設計原則です。最小知識の原則とも呼ばれます。

user.getCompany().getAddress().getZip() のような長い連鎖は、内部構造への依存を増やします。呼び出し側が遠くの詳細まで知ってしまうと、構造変更に弱くなります。クラス設計、ドメインモデル、API設計で効きます。

$$
漏れ出す抽象化の法則　★★★★☆
$$

どんな抽象化も、どこかで下層の事情が漏れる、という法則です。

ORMを使っていてもSQLの知識は必要です。クラウドを使っていてもネットワークやIAMの理解は必要です。ReactやNext.jsを使っていてもブラウザの仕組みは漏れてきます。抽象化は便利ですが、下の層を完全に消してくれるわけではありません。

$$
カーニハンの法則　★★★★☆
$$

デバッグはコードを書くより難しい。だから、賢すぎるコードを書くと自分でも直せなくなる、という法則です。

ワンライナー、ネストした三項演算子、過剰なメタプログラミング、読み手を試すような抽象化に対する戒めです。コードは「書けるか」ではなく「あとで読めるか」「バグったとき直せるか」で考える必要があります。

$$
アトウッドの法則　★★★★☆
$$

JavaScriptで書けるものは、いずれJavaScriptで書かれる、という法則です。

Web技術がブラウザを越えて、サーバー、デスクトップ、モバイル、CLI、IoTまで広がった流れを端的に表しています。ElectronやNode.js、React Nativeのような技術を見ていると、妙に納得してしまう言葉です。

$$
ハイラムの法則　★★★☆☆
$$

十分な利用者がいれば、システムの観測可能な挙動はすべて誰かに依存される、という法則です。

APIを公開している人ほどよくわかるのではないでしょうか。たとえば「たまたまレスポンスのキー順が固定されている」「エラーメッセージが毎回同じ」「処理時間がだいたい一定」というだけでも、利用者がそれに依存してしまうことがあります。公式仕様に書いていなくても、見えている挙動は契約になりうる、という怖い話です。

$$
リーナスの法則　★★★☆☆
$$

十分な目があれば、バグは浅くなる、というOSS文脈で有名な言葉です。あのリーナス・トーバルズの名言ですね。

多くの人が見れば、バグの発見や原因特定がしやすくなる、という意味で使われます。レビュー、OSS、監査、バグバウンティの価値を説明するときに便利です。ただし、人数だけで安全になるわけではありません。見る人の専門性、レビューしやすい設計、テスト、再現性があって初めて効きます。

$$
ザウィンスキーの法則　★★☆☆☆
$$

便利なプログラムは、やがてメールを読めるところまで膨張しがち、という皮肉です。

本質は「便利なツールは機能追加を重ねて、いつの間にか巨大なプラットフォームになる」という話です。最初は小さなタスク管理ツールだったのに、チャット、カレンダー、メール、AI、ワークフローまで抱え込むような現象です。

$$
スタージョンの法則　★★☆☆☆
$$

たいていのものの大半は微妙、という身もふたもない法則です。

ライブラリ、サンプルコード、技術記事、OSS、AI生成コードを見るときの冷静さとして使えます。世の中にあるものを全部ありがたがるのではなく、よい10%を探す目が必要です。

1-3. 性能とスケールの法則

$$
ムーアの法則　★★★★☆
$$

半導体の集積度は一定期間で倍増してきた、という経験則です。

もともとは集積回路上の部品数に関する予測で、のちに「計算性能が継続的に伸びる」文脈でも広く使われました。ただし、物理的限界や製造コストの問題もあり、現在は昔ほど単純には語れません。

$$
アムダールの法則　★★★★☆
$$

並列化しても、直列部分が全体の速度向上を制限する、という法則です。

「サーバーを増やせば速くなる」という雑な期待を冷ましてくれます。ボトルネックがDBのロック、単一キュー、外部API、同期処理にあるなら、ワーカーだけ増やしても限界があります。マルチスレッド、分散処理、GPU利用時のホスト処理やデータ転送のように、直列ボトルネックが残る場面でよく出ます。

$$
ヴィルトの法則　★★★☆☆
$$

ソフトウェアは、ハードウェアが速くなる以上に遅くなりがち、という皮肉です。

ハードウェアが速くなっても、依存関係の肥大化、抽象化の増加、Electron化、過剰な機能追加で体感速度が上がらないことがあります。性能改善や軽量化の話でよく出ます。

$$
メトカーフの法則　★★★☆☆
$$

参加者数の増加でネットワークの価値が大きく伸びる、という法則です。

参加者数を n とすると、接続可能なペア数は n(n-1)/2 で増えます。大きな n では参加者数の二乗に近い増え方をするため、ネットワークの価値は参加者数の二乗に比例する、という形で説明されます。SNS、マーケットプレイス、通信ネットワーク、開発者コミュニティの説明で使われます。

$$
グスタフソンの法則　★★☆☆☆
$$

問題サイズを大きくできるなら、並列化の効果はより大きく見積もれる、という法則です。

アムダールの法則が「固定された仕事をどれだけ速くできるか」を見るのに対し、グスタフソンの法則は「計算資源が増えたぶん、より大きな問題を解ける」と考えます。HPC、バッチ処理、大規模データ処理で出てきます。

1-4. 指標と意思決定の法則

$$
パレートの法則　★★★★★
$$

これはエンジニア以外でも有名ですね。結果の多くは、少数の原因から生まれやすい、という法則です。80対20の法則とも呼ばれます。

障害の多くが一部の機能に集中する、問い合わせの大半が一部の画面に集中する、売上の多くが一部の顧客から来る、といった見方です。重要バグ、主要ユーザー、頻出問い合わせの分析に使えます。

$$
マーフィーの法則　★★★★★
$$

本来は「失敗しうることは失敗する」と要約されることが多い法則です。

実務では「失敗するはずがない」ではなく、「失敗したらどう安全に止めるか」を考えるための言葉です。障害設計、リトライ、監視、バックアップ、冪等性、フェイルセーフの話と相性が良いです。ジャムを塗ったパンを落とすと、なぜか落ちてほしくないジャムの面が下になって落ちる、みたいな話が有名です。

$$
グッドハートの法則　★★★★☆
$$

指標が目標になると、その指標は良い指標でなくなる、という法則です。これは、マリリン・ストラザーンによる有名な言い換えとして広く知られています。

テストカバレッジを目標にすると、意味の薄いテストが増えます。ベロシティを評価に使うと、チケット分割がゲーム化します。障害件数を目標にすると、小さな障害を報告しなくなるかもしれません。指標は見るものですが、それだけを目的にすると壊れます。

$$
ギャルの法則　★★★☆☆
$$

動く複雑なシステムは、動く単純なシステムから進化する、という法則です。

最初から巨大で理想的なシステムを作るより、小さく動くものを作り、そこから育てるほうが成功しやすいという考え方です。新規プロダクト、大規模リプレイス、基盤刷新でかなり効きます。

$$
キャンベルの法則　★★☆☆☆
$$

重要な意思決定に使われる指標ほど、歪められやすい、という法則です。

グッドハートの法則に近いですが、評価制度、教育、行政、KPI運用などでよく使われます。開発組織なら、PR数、コミット数、ストーリーポイント、レビュー件数などを評価に直結させると歪みやすくなります。

2. そのほか

ここからは、厳密には法則ではないけれど、エンジニア界隈でやたら通じる原則、戦略、指標、比喩、名著由来の言い回しです。

2-1. 設計原則

$$
DRY　★★★★★
$$

これは実際にレビューで指摘されたことがあります。Don't Repeat Yourselfの略で、同じ知識を複数箇所に重複させない、という原則です。

よく誤解されますが、「同じコードを1行も書くな」ではありません。重複してはいけないのは、主にビジネスルール、定数、スキーマ、仕様のような知識です。たまたま形が似ているだけのコードを無理に共通化すると、逆に変更しづらくなります。この辺りは、『達人プログラマー』を読んでみてください。

$$
KISS　★★★★★
$$

Keep It Simple, Stupidの略で、できるだけシンプルにする、という原則です。

設計、API、運用手順、チームルールに効きます。賢そうな抽象化より、読める構造、説明できる構造、壊れたときに直せる構造を優先します。シンプルイズベストです、ほんとに。

$$
YAGNI　★★★★★
$$

You Aren't Gonna Need Itの略で、まだ必要でない機能は作らない、というExtreme Programming（XP）由来の原則です。

「将来を考えるな」ではありません。まだ確定していない未来のために、複雑な抽象化や設定項目を先に作り込まない、という戒めです。未来の要件に備えたつもりのコードが、結局一度も使われないことはかなり多いということですね。

$$
SOLID　★★★★★
$$

オブジェクト指向設計でよく語られる5原則の頭文字です。

単一責任の原則、開放閉鎖の原則、リスコフの置換原則、インターフェース分離の原則、依存性逆転の原則をまとめたものです。現代では批判的に語られることもありますが、依存関係、変更理由、責務分割を考えるための共通語彙としてまだ強いです。

$$
単一責任の原則　★★★★★
$$

これもめちゃめちゃ聞きます。モジュールやクラスの変更理由をひとつに近づける、という原則です。

「1クラス1メソッド」という意味ではありません。ユーザー表示の変更、課金ルールの変更、DB保存形式の変更が同じクラスに混ざっているなら、責務が広すぎる可能性があります。

$$
関心の分離　★★★★★
$$

異なる関心を混ぜない、という原則です。

UI、ドメインロジック、DBアクセス、認証、ログ、通知、外部API呼び出しが混ざると、変更が怖くなります。レイヤードアーキテクチャ、クリーンアーキテクチャ、MVCなどの根底にもある考え方です。

$$
最小権限の原則　★★★★★
$$

絶対に知っておくべき原則と言えます。必要最小限の権限だけ与える、というセキュリティ原則です。

IAM、DB権限、CI/CD、GitHub Actions、AIエージェント、MCPツール、管理画面など、かなり広く使えます。権限は「困ったら広げる」ではなく、「必要な範囲を確認して狭く渡す」が基本です。

$$
開放閉鎖の原則　★★★★☆
$$

拡張には開き、既存修正には閉じる、という原則です。

新しい支払い方法や通知先を追加するとき、既存コードを何箇所も書き換えずに済む設計を目指します。ただし、過剰にやると抽象化だらけになるので、YAGNIとのバランスが必要です。

$$
最小驚きの原則　★★★★☆
$$

利用者が驚かない挙動にする、という原則です。

関数名、APIレスポンス、UI、デフォルト値、CLIオプションに効きます。deleteUser() という名前なのに論理削除ではなく物理削除する、get なのにDB更新する、のような挙動は驚きを生みます。

$$
Unix哲学　★★★★☆
$$

小さく作り、うまく組み合わせる、というUnix文化の設計思想です。

「一つのことをうまくやる」「テキストストリームでつなぐ」「小さなツールを組み合わせる」といった考え方が代表的です。CLI、パイプ、マイクロサービス、開発者向けツール設計に影響しています。

$$
WET　★★☆☆☆
$$

Write Everything Twice、Write Every Time、あるいは We Enjoy Typing などと説明される、DRYの逆を表す言葉です。よくない状態を表します。

同じ処理、同じルール、同じ設定をあちこちに書いている状態です。仕様変更時に片方だけ直し忘れる、ドキュメントとコードがズレる、テストだけ古い挙動を見ている、といった事故につながります。このDRYとWETの対応関係は、ちょっとおしゃれさを感じます。

$$
ETC（変更しやすさ）　★★☆☆☆
$$

Easier to Changeの略で、変更しやすさを設計判断の中心に置く、という考え方です。

『達人プログラマー』第2版では、ETCはルールではなく価値だと説明されます。DRY、KISS、YAGNI、関心の分離などは、それぞれ別の原則に見えますが、最終的には「あとから安全に変えられるか（変更容易性）」に集約できます。迷ったときは「この実装は、次の変更を楽にするか、難しくするか」と問い直すと判断しやすくなります。

2-2. 名著でよく見る開発手法と比喩

$$
プロトタイプ　★★★★★
$$

捨てる前提で学習するために作るものです。

未知の技術、UI、ライブラリ、性能特性を試すために作ります。大事なのは「本番コードに育てるもの」と「捨てるもの」を混同しないことです。捨てるつもりのコードが、そのまま本番化されると危険です。トレーサーバレット（曳光弾）との違いも、開発手法の話でよく出てきます。

$$
車輪の再発明　★★★★★
$$

既にあるものを無駄に作り直す、という比喩です。めっちゃ聞きます。

ライブラリや標準機能を調べずに、自作フレームワークや自作暗号を作ってしまうような場面で使われます。ただし、学習目的や制約が明確な場合の再実装には価値があります。問題なのは、既存の知見を無視して同じ失敗を繰り返すことです。

$$
ゆでガエル　★★★★☆
$$

少しずつ悪化すると、人は危険に気づきにくい、という比喩です。

『達人プログラマー』では、石のスープと並んで「ゆでガエル」の話が紹介されています。水を少しずつ温められたカエルが危険に気づけない、という寓話的な説明から、ゆっくり進む劣化への鈍感さを表す言葉として使われます。

ビルドが1分ずつ遅くなる。テストが少しずつ落ちやすくなる。型エラーを少しずつ無視する。急激な事故ではないので見逃されますが、最後にはチーム全体の速度を落とします。技術的負債の増え方そのものです。なお、生物学的な事実としてではなく、あくまでソフトウェア開発の比喩として扱うのが安全です。

$$
割れ窓理論　★★★★☆
$$

小さな荒れを放置すると、さらに荒れる、という理論です。これはエンジニアに限らず一般的に有名な理論です。

コードで言えば、壊れたテスト、雑な命名、放置されたTODO、フォーマットされていないファイル、失敗しているCIです。小さな荒れを放置すると、「このリポジトリは雑に扱ってよい」という空気が生まれます。

$$
ゴムのアヒルデバッグ　★★★★☆
$$

誰かに説明すると、自分で原因に気づく、というデバッグ手法です。

相手は人間でなくてもよく、机の上のゴムのアヒルでもよい、という話です。コードを一行ずつ説明することで、自分の理解の穴が見えます。レビュー前のセルフチェックにも使えます。

$$
銀の弾丸はない　★★★★☆
$$

ソフトウェア開発の本質的な難しさを一撃で消す技術はない、というフレデリック・ブルックスの有名な主張です。

新しい言語、フレームワーク、クラウド、AIツールが出ても、仕様理解、複雑性、変更、コミュニケーションの難しさは消えません。新技術への過剰期待を抑える言葉です。なお、ここでいう銀の弾丸は、怪物を一撃で倒す伝承上の武器の比喩です。

$$
ヤクの毛刈り　★★★★☆
$$

本来やりたい作業の前に、前提作業が連鎖していく現象です。

「小さな修正をしたいだけなのに、テストを動かすためにNodeを上げ、Nodeを上げるためにCIを直し、CIを直すために権限を見直し、気づけば全然違う作業をしている」みたいな状態です。環境構築や依存更新でよく起きます。

$$
石のスープ　★★★☆☆
$$

小さなきっかけを作り、周囲を巻き込んで大きな成果にする、という比喩です。

もとは民話として知られる話で、旅人が「石でスープを作る」と言って鍋を用意し、周囲の人から少しずつ具材を出してもらい、最後には本物のスープができる、という流れです。

最初から「全部リファクタリングしましょう」と言っても動かない場面で、小さな改善PRを出す。それを見た人がテストを足し、別の人がドキュメントを足し、気づけば改善活動になっている。そういう動き方です。

$$
トレーサーバレット（曳光弾）　★★★☆☆
$$

最初から本番に近い細い縦切りを通す、という考え方です。曳光弾はえいこうだん、と読みます。

由来は、弾道を目で追えるように発光する曳光弾です。これを打って弾道を把握し、対象に当てるイメージです。

単なる捨てるプロトタイプではなく、実際のアーキテクチャを薄く通すイメージです。UI、API、DB、デプロイ、監視まで最小の線を通してから、徐々に太くします。歩く骨格とも近いです。

プロトタイプとの違いは、コードを残して育てる前提かどうかです。どちらも早期フィードバックの手段ですが、トレーサーバレットは本番に向かう細い実装として扱います。

2-3. 認知と学習の比喩

$$
ジョシュアツリーの法則　★★★★★
$$

これはかなり共感できる法則で、名前を知ると、それまで見えていなかったものが見えるようになる、という比喩です。

厳密な学術法則というより、Joshua Tree principleやJoshua Tree effectのように語られることがある比喩です。たとえば「ハイラムの法則」という名前を知ると、APIレビュー中に「これは誰かが依存しそうだ」と気づけるようになります。設計パターン、アンチパターン、障害パターン、認知バイアスは、名前を知るだけで観察しやすくなります。

$$
ダニング＝クルーガー効果　★★★★☆
$$

その領域の能力が低い人ほど、自分の能力を過大評価しやすい、という認知バイアスです。

よく「初心者ほど自信満々」という雑な意味で使われますが、本来は、自分の誤りに気づくためのメタ認知能力も不足しやすい、という話です。AI生成コードの過信にも似ています。よく知らない領域ほど、断言せず、検証とレビューを挟む必要があります。

$$
確証バイアス　★★★★☆
$$

自分の仮説に合う情報だけを集めやすい、という認知バイアスです。

障害調査で「DBが原因に違いない」と思い込むと、DBに都合のよいログばかり見てしまいます。性能改善やレビューでも起きます。仮説を立てるのは大事ですが、反証するログも見る必要があります。

$$
オッカムの剃刀　★★★★☆
$$

複数の説明が同じくらい成り立つなら、必要以上に仮定を増やさない、という考え方です。

名前は14世紀の哲学者・神学者ウィリアム・オブ・オッカムに由来します。「必要なしにものを増やしてはいけない」という単純性の原理として知られ、余計な仮説を剃刀で削ぎ落とす、という比喩で語られます。

障害調査で、いきなり複雑な分散システムのバグを疑う前に、設定ミス、環境変数、デプロイ漏れ、入力値、タイムゾーンのような単純な原因を確認します。単純な説明が常に正しいわけではありませんが、最初の仮説として強いです。

$$
チェスタトンの柵　★★★★☆
$$

なぜ存在するかわからないものを、理解する前に壊してはいけない、という考え方です。

由来はG・K・チェスタトンの議論です。道にある柵を見て「何の役にも立っていないから撤去しよう」と考える前に、まずその柵がなぜ作られたのかを理解しなければならない、というたとえです。

レガシーコードで、意味不明な if 文や謎の設定を見つけたとき、すぐ消したくなります。しかし、そのコードが過去の障害対応や顧客個別要件の名残かもしれません。消す前に、ログ、Issue、コミット履歴、担当者の記憶を確認します。

$$
生存者バイアス　★★★☆☆
$$

生き残った成功例だけを見て判断してしまう、というバイアスです。

成功したスタートアップ、人気OSS、伸びた技術記事だけを見ると、「そのやり方をすれば成功する」と思いがちです。しかし、同じやり方で失敗した大量の事例は見えません。技術選定やキャリア論で注意したい視点です。

$$
バーダー・マインホフ現象（頻度錯誤）　★★☆☆☆
$$

知ったばかりの言葉を、急に何度も見るように感じる現象です。頻度錯誤とも呼ばれます。

新しい技術用語を覚えた直後に、タイムラインや記事、会議で急にその言葉を見かけるように感じることがあります。実際に増えたというより、自分の注意が向くようになった、という話です。

2-4. アーキテクチャと分散システムの定番

$$
CAP定理　★★★★★
$$

分散システムでは、一貫性、可用性、分断耐性のすべてを同時に完全には満たせない、という定理です。

よく「3つのうち2つしか選べない」と説明されますが、実務ではネットワーク分断が起きたときに一貫性と可用性のどちらを優先するか、という設計判断として考えるほうが自然です。

$$
冪等性　★★★★★
$$

同じ操作を何度実行しても結果が変わらない、という性質です。べきとうせい、と読みます。

より正確には、同じ操作を1回実行しても複数回実行しても、サーバー側の状態に対する意図した効果が同じになる、という性質です。レスポンス内容まで毎回完全に同じである必要はありません。ネットワークは失敗します。リトライも起きます。だからこそ、同じ決済リクエストやWebhook処理が2回来ても二重処理にならないように設計します。決済、ジョブ処理、API設計で非常に重要です。

$$
フェイルセーフ　★★★★★
$$

失敗しても安全側に倒す、という考え方です。

認可エラーなら許可ではなく拒否に倒す。決済で不明な状態なら二重請求ではなく保留にする。制御システムなら危険な動作ではなく停止に倒す。セキュリティや安全性の基本です。

$$
フールプルーフ　★★★★★
$$

人が間違えても危険な状態になりにくいように、操作や設計でミスを起こしにくくする考え方です。

削除ボタンに確認を入れる、危険な本番操作には環境名入力を求める、破壊的コマンドをデフォルトで無効にする、入力値を選択式にするなどです。ユーザーや運用者の注意力に頼るのではなく、間違いにくい仕組みに寄せます。

$$
結果整合性　★★★★☆
$$

すぐには一致しないが、時間が経てば整合する、という考え方です。

NoSQL、キャッシュ、イベント駆動、非同期処理でよく出ます。書き込み直後に読み込むと古い値が見えるかもしれないが、しばらくすれば一致する、という性質です。

$$
フェイルファスト　★★★★☆
$$

問題があるなら早く失敗させる、という考え方です。

設定が足りない、入力が不正、依存サービスに接続できない。こうした問題を後段まで引きずらず、早い段階で止めます。入力検証、設定チェック、CI、起動時検証でよく使います。

$$
バックプレッシャー　★★★☆☆
$$

受け手が処理しきれないとき、送り手を抑制する仕組みです。

キュー、ストリーム、API制限、ログ処理で登場します。受け手が詰まっているのに送り続けると、メモリが膨らみ、遅延が増え、最終的に落ちます。流量制御の考え方です。

$$
Graceful 　degradation　★★★☆☆
$$

一部が壊れても、全体をできるだけ動かす、という考え方です。

外部APIが落ちても、主要機能は動かす。レコメンドが死んでも、商品一覧は出す。画像変換が遅れても、テキストだけ表示する。障害時の縮退運転やレジリエンス設計で使われます。

2-5. 組織と開発の戦略・指標

$$
バス係数　★★★★☆
$$

エンジニア特有のもの来ました。何人いなくなるとプロジェクトが止まるかを表す考え方です。

バス係数が1なら、その1人が退職、異動、休職しただけでプロジェクトが危険になります。属人化、ドキュメント不足、レビュー体制不足の危険度を測る言葉です。コードレビュー、ペア作業、手順書、ローテーションで上げていきます。

$$
逆コンウェイ戦略　★★★☆☆
$$

コンウェイの法則を逆に使い、作りたいアーキテクチャに合わせて組織を設計する考え方です。

「こういうサービス境界にしたいから、チームもその境界に合わせる」という発想です。Team Topologies、プラットフォームチーム、ストリームアラインドチーム、境界づけられたコンテキストの話と相性が良いです。

3. 使い方の注意

ここまで並べた言葉は便利ですが、万能ではありません。

3-1. 名前だけで議論を終わらせない

「それはブルックスの法則ですね」「YAGNIです」「コンウェイですね」で会話を止めると、ただの呪文になります。

大事なのは、名前を出したあとに具体化することです。

【悪い例】

「それはYAGNIです」で終わらせる。

【良い例】

「その拡張ポイントは、今期中に使う具体的な要件がありますか」と聞く。

【悪い例】

「ブルックスの法則で無理です」で終わらせる。

【良い例】

「今人を増やすと、オンボーディングとレビューで2週間は遅れそうです」と影響を具体化する。

名前はショートカットです。説明を省略するためではなく、議論を深くするために使います。

3-2. 名著の言葉は現場に翻訳する

『達人プログラマー』『人月の神話』『UNIXという考え方』『ソフトウェア工学の古典』に出てくる言葉は、今読んでも現場で使える知識が多く詰まっています。

ただし、そのまま現代のWeb開発、クラウド、AIエージェント、分散システムに当てはめるには多少翻訳が必要です。

石のスープは、現代なら「小さな改善PRでチームを巻き込む」
ゆでガエルは、現代なら「CIの遅さや型の緩みを少しずつ放置する」
車輪の再発明は、現代なら「既存ライブラリを調べずに自作する。ただし学習目的なら価値がある」
漏れ出す抽象化は、現代なら「クラウドやAIツールを使っても、下層の仕組みを完全には忘れられない」

古典は、暗記するものではなく、現場の違和感に名前を付けるための道具です。
横文字を連発するちょっと近寄りがたい人にはならないようにしましょうね。

おわりに

ここまでお読みいただきありがとうございます。

エンジニア界隈で有名な法則や比喩は、単なる雑学ではありません。見積もりが外れる理由、組織構造がコードに出る理由、API互換性が壊れにくい理由、指標が歪む理由、技術的負債が静かに増える理由を、短い名前で思い出せるようにしてくれます。

この記事で一番伝えたいのは、 名前を知ると、現場の違和感に気づけるようになる ということです。まさにジョシュアツリーの法則そのものです。

ではまた、お会いしましょう。

参考リンク

法則系

名著と原則

比喩、認知、その他

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up