ソフトウェアの法則

目次

主要項目のみを表示しています。詳細な小見出しは本文内で確認できます。

• 概要
• 法則と原則の違い
• 法則全体の地図
• コンウェイの法則
• ブルックスの法則
• ホフスタッターの法則
• ハイラムの法則
• ポステルの法則
• グッドハートの法則
• ヴィルトの法則
• ギャルの法則
• クヌースの最適化原則
• リーナスの法則
• パレートの法則
• スタージョンの法則
• レーマンのソフトウェア進化の法則
• グリーンスパンの第10法則
• マーフィーの法則
• アムダールの法則とグスタフソンの法則
• ムーアの法則
• ピーターの法則
• カニンガムの法則
• パーキンソンの法則
• ザウィンスキーの法則
• ワドラーの法則
• セイアの法則
• テスラーの法則
• ケルクホフスの原理
• ピーター・ヒンチェンスの法則
• ストールマンの法則
• ノーヴィグの法則
• カニンガムのもう一つの法則(技術的負債の比喩)
• ノーヴィグの品質観
• ノーヴィグとクヌース
• アンダーソンの法則
• ヘッブの法則
• アマラの法則
• リードの法則
• 法則の使い方
• 法則の限界と誤用
• 現代開発への接続
• 法則のメタ知識
• ケーススタディ: コンウェイの法則と組織再編
• まとめ
• 参考文献

概要

ソフトウェア開発の世界には、観察と経験から生まれた多くの「法則」が存在します。これらは厳密な数学的法則ではなく、組織、プロジェクト、コードに繰り返し現れる現象に名前を与えたものです。覚える価値があるのは、設計や運用の判断をするときに、具体的な状況を素早く言語化できるためです。

法則と原則の違い

「プログラミング原則」と「ソフトウェアの法則」は似ていますが、性格が違います。

原則は「すべきこと」、法則は「起こりがちなこと」です。法則を知っておくと、トラブルの原因を素早く言語化でき、防止策や対処策を選びやすくなります。

法則全体の地図

ソフトウェアに関する法則は、何を観察しているかでまとめると見通しがよくなります。

すべてを一度に覚える必要はありません。設計やレビュー、ポストモーテムの中で、現象を説明する語として引き出せれば十分です。

コンウェイの法則

コンウェイの法則(Conway’s Law)は、Melvin Conwayが1967年に書き、Datamation 誌が1968年4月号に掲載した論文 「委員会はいかに発明するか」 で提示されました。原典の言い回しは次の通りです。

システムを設計する組織は、その組織のコミュニケーション構造を写した設計を生み出す。

たとえば、フロントエンド・バックエンド・DBチームに分かれた組織は、フロントエンド・バックエンド・DBに分離したシステムを作りがちです。逆に、機能ごとに編成された自律チームは、機能ごとに切れたサービス(マイクロサービス)を作りがちです。

Conway の法則は、Fred Brooks の 「人月の神話」 で取り上げられ、有名になりました。現代では 「逆コンウェイ戦略」 という発想もあります。これは「望ましいアーキテクチャに合わせて組織を先に変える」というアプローチです。

注意点もあります。組織構造を変えるだけで設計が変わるわけではなく、技術的負債、既存の依存関係、政治的な力学が絡みます。Conway の法則は決定論ではなく、「設計判断は組織判断と切り離せない」という強い相関の指摘です。

ブルックスの法則

ブルックスの法則(Brooks’s Law)は、Frederick P. Brooks Jr. が1975年の名著 「人月の神話」 で提示しました。原典の言い回しは次の通りです。

遅れているソフトウェア開発プロジェクトに人を追加すると、さらに遅れる。

Brooks 自身は「これは乱暴な単純化だ」と認めつつ、現象として広く成立すると述べています。

なぜそうなるのか、二つの理由があります。

• 立ち上がりコスト: 新しいメンバーは既存コードや設計の理解に時間が必要で、教育する側の生産性も一時的に下がります。
• コミュニケーションコスト: 人数が n のとき、コミュニケーション経路は n(n-1)/2 で増えます。10人から20人に倍増しても、経路は4倍以上になります。

ブルックスの法則(Brooks’s Law)は「人手を足してはいけない」と読むのは誤りで、「すでに遅れているプロジェクトに泥縄で足しても効かない」という観察です。早い段階で計画的に増員する場合や、独立したサブシステムに人を割り当てる場合は別です。

派生する教訓として、「人月の神話」 には 「銀の弾丸はない」、「セカンドシステム効果」、「概念的完全性」 といった洞察も含まれており、Brooks’s Law と合わせて読まれます。

ホフスタッターの法則

ホフスタッターの法則(Hofstadter’s Law)は、Douglas Hofstadter が1979年の 「ゲーデル、エッシャー、バッハ」 で提示した自己言及的な格言です。

それはいつも予想より時間がかかる。ホフスタッターの法則を考慮に入れていても。

「予想より時間がかかる、Hofstadter の法則を考慮に入れていても」。自分が遅れる傾向を知っていても、その補正を入れてもまだ遅れる、という再帰的な観察です。

もとの文脈は、当時のチェスを打つコンピュータでした。「あと10年で人間に勝てる」と言われ続けて、10年経ってもまた「あと10年」と言われ続ける状況を Hofstadter が観察したものです。

ソフトウェア開発でも同じことが起きます。

• バッファを乗せた見積りでも超過する
• 「今度こそ慎重に」見積もっても超過する
• 残り作業が見えてもまだ別の問題が出てくる

実務での使い方は、「見積りに2〜3倍を掛けて初めて現実的」「クリティカルパスでは複数回のバッファを置く」「重要な締切では段階的なリリースで早く現実検証する」など、防御的な計画です。

ハイラムの法則

ハイラムの法則(Hyrum’s Law)は、Hyrum Wright(Google)が提唱した観察で、https://www.hyrumslaw.com/ に簡潔な定式化があります。

APIの利用者が十分に多くなると、契約で何を約束していても関係なく、観察可能な振る舞いはすべて誰かに依存される。

例として、ライブラリのドキュメントには「順不同で返る」と書かれていても、実装が偶然ソート順で返している場合、利用者の一部はその順序に依存しています。実装を「本当に順不同」に変えると、契約上は正しくても、彼らのコードは壊れます。

ハイラムの法則(Hyrum’s Law)は次のような帰結を持ちます。

• パフォーマンス特性、ログ形式、エラーメッセージの文字列、リクエストのタイミングまで、依存される
• バグでさえ「機能」として依存されることがある
• バージョンを上げる際は、契約だけでなく観察可能な振る舞いの差分を考える必要がある
• API設計では、「不透明」 な値を返したり、内部順序を意図的にシャッフルすることで、依存を防げる

Google の「Googleのソフトウェアエンジニアリング」では、ハイラムの法則を考慮した設計と運用(テスト、フェーズドロールアウト、観測)が詳述されています。

ポステルの法則

ポステルの法則(Postel’s Law / Robustness Principle)は、Jon Postel が TCP の仕様 RFC 761(1980年)で示した次のフレーズです。

送るものには厳密に、受け取るものには寛容に。

「送るときは厳密に、受け取るときは寛容に」。インターネットがマルチベンダー環境で相互運用性を保つために重要な原則でした。

利点は明らかです。仕様の解釈が分かれる場合でも、寛容な受信側が異種実装と通信できるため、エコシステムが成長しやすくなります。

一方で、近年は批判もあります。

• 寛容な受信は、仕様違反の実装を温存し、結果的にセキュリティホールやプロトコルの曖昧さを生む
• HTML パーサが寛容すぎたために XSS や難解な互換コードを生んだ歴史
• 2023年の Martin Thomson と David Schinazi の論文 「ロバストネス原則の再考」 は、現代では「厳密に受け取り、エラーを早期に返す」方が安全という議論を提示

Postel’s Law は古典的な道標ですが、現代のセキュリティ要件と組み合わせて慎重に運用する必要があります。Fail Fast 原則とのバランスが重要です。

グッドハートの法則

グッドハートの法則(Goodhart’s Law)は、英国の経済学者 Charles Goodhart が1975年の金融政策論文で提示した観察を、人類学者 Marilyn Strathern が1997年に短く言い換えたフレーズで広く知られます。

測定が目標になると、それは良い測定ではなくなる。

「測定が目標になると、それは良い測定ではなくなる」。Goodhart 自身の原文はもう少し堅く、「観察された統計的規則性は、それを管理目的で利用しようとした瞬間に崩壊する傾向がある」というものでした。

ソフトウェア開発で起こる典型は次のようなケースです。

• コードカバレッジを KPI にすると、無意味な assertion ばかりのテストが量産される
• バグ件数を評価指標にすると、バグを「タスク」として登録しなくなる
• ベロシティを目標にすると、ストーリーポイントが膨張する
• ビルド時間を測ると、CIから時間のかかるテストが外される

対処は、メトリクスを単独で追わず、複数の指標を組み合わせて観察することです。「目標・問い・指標」 のようなフレームワークが助けになります。

Campbell’s Law(社会指標版)と Cobra Effect(インド英国植民地時代のコブラ報奨金が逆効果になった逸話)も同種の警告として参照されます。

ヴィルトの法則

ヴィルトの法則(Wirth’s Law)は、Niklaus Wirth が1995年の論文 「リーンなソフトウェアへの嘆願」 で提示した観察です。

ソフトウェアは、ハードウェアが速くなる速度よりも速く遅くなる。

「ソフトウェアはハードウェアが速くなる速度より速く遅くなる」。Wirth 自身は、Martin Reiser の Oberon System の前書きにこの傾向が指摘されていたとして謙虚に紹介しています。

派生として ゲイツの法則(市販ソフトの速度は18ヶ月で半減する)、メイの法則(ソフトウェアの効率は18ヶ月ごとに半減する)といったジョーク的な変奏もあります。

Wirth が指摘した原因は二つです。

• ハードウェアの急速な進化が、効率を犠牲にすることを許してしまう
• 顧客が「本質的な機能」と「あれば嬉しい機能」を区別しない

Wirth は Oberon System を、最小限のハードウェアで動く実用OSとして実装し、「リーンなソフトウェア」 が実現可能であることを示しました。現代の Web フロントエンド、Electron アプリ、コンテナイメージのサイズを見ると、ヴィルトの法則(Wirth’s Law)は皮肉にも現役です。

「機能を足し続けるより、何を捨てるか」を問う姿勢は、KISS や YAGNI と並ぶ重要な視点です。

ギャルの法則

ギャルの法則(Gall’s Law)は、John Gall が1975年の 「システムはどう働き、どう失敗するか」 で提示した観察です。

動く複雑なシステムは、動く単純なシステムから進化している。逆もまた真で、一から設計された複雑なシステムは動かず、パッチで直すこともできない。動く単純なシステムから始め直す必要がある。

Web、ブログ圏、Linux カーネル、Git は単純な始点から進化した成功例です。一方、CORBA、ITER(一部)、いくつかのウォーターフォール型大規模再設計プロジェクトが失敗例として参照されます。

ギャルの法則(Gall’s Law)は YAGNI と相性がよく、「歩く骨格」(最小機能で動くものを早く作る)、MVP(Minimum Viable Product)、「曳光弾」(小さく実装しながら方向を確認する)といった現代の実践に通じます。

「最初から完璧な設計を狙うな、動くものから進化させよ」という指針は、原則というよりも開発戦略として広く受け入れられています。

クヌースの最適化原則

Donald Knuth は1974年の論文 「goto文付き構造化プログラミング」(Computing Surveys 6:4, pp. 261-301)で次の有名な一節を残しました。

プログラマは重要でない部分の速度を気にして膨大な時間を浪費し、その効率化はデバッグや保守を考えると強い悪影響を持つ。小さな効率化は、たとえば97%の場面では忘れるべきだ。早すぎる最適化は諸悪の根源である。ただし、重要な3%の機会を見逃してはならない。

短く 「早すぎる最適化は諸悪の根源である」 の部分だけが流通しがちですが、原文を読むと「小さな効率に時間を使うな、ただしクリティカルな3%は見逃すな」という慎重な命題です。

Knuth は後にこの言葉を 「ホーアの格言」 と呼びました(C. A. R. Hoare の発言とされていますが、確証はありません)。

実務上の使い方は次の通りです。

• 計測なしの最適化は避ける
• ボトルネックを推測ではなく観測で特定する
• 可読性とメンテナンス性を優先し、必要な箇所だけ最適化する
• 一方で、クリティカルパスや tight loop では真剣な最適化が必要

Rob Pike の Notes on Programming in C の 第1則(プログラムがどこで時間を使うかは予想できない。ボトルネックは意外な場所に現れるので、そこがボトルネックだと証明するまでは、推測で高速化の小技を入れてはいけない)も、同じ精神を別の言葉で述べています。

リーナスの法則

リーナスの法則(Linus’s Law)は、Eric S. Raymond が1999年のエッセイと書籍 The Cathedral and the Bazaar で命名した命題です。

十分な数の目があれば、すべてのバグは浅い。

形式的には「十分に大きなベータテスターと共同開発者の基盤があれば、ほとんどすべての問題はすぐに特徴づけられ、誰かにとって修正方法が明らかになる」という意味です。Linus Torvalds に敬意を表して命名されました。

オープンソース開発の核心を捉えた観察で、ソースコードを公開することでバグの発見と修正が早まる、というオープンソースの強みを表現します。

ただし反例もあります。

• 2014年に発覚した OpenSSL の Heartbleed 脆弱性は、何年もの間誰も気づきませんでした
• 多くの目があっても、複雑なコードや暗号領域では発見が難しい
• 「目がある」と「実際にレビューされている」は別物

Robert Glass はこの法則を「オープンソース運動のマントラ」と呼び、追加レビュアーとバグ発見率の関係が線形でないことを指摘しています。

それでも、レビューやコミュニティスケールの恩恵は実在します。リーナスの法則(Linus’s Law)は絶対の保証ではなく、「公開と協働には品質的な追い風がある」という相対的な命題と捉えるのが適切です。

パレートの法則

Pareto Principle(80/20の法則)は、イタリアの経済学者 Vilfredo Pareto の19世紀の観察(イタリアの土地の80%が人口の20%に保有されている)に由来します。Joseph M. Juran が品質管理の文脈で Pareto Principle と命名しました。

結果の80%は、原因の20%から生じる。

ソフトウェア開発での典型的な現れ方は次の通りです。

• バグの80%はコードの20%に集中する
• ユーザーの80%は機能の20%だけを使う
• パフォーマンス問題の80%はコードの20%に存在する
• テストの20%でバグの80%を捕まえられる
• 機能開発の80%は時間の20%で進み、最後の20%が80%の時間を奪う

これは厳密な数値ではなく、重要な少数と些末な多数 という分布の傾向です。実務上は次のように活用されます。

• ボトルネック特定: ホットスポットに集中して最適化する
• リスク管理: 重要な少数のコンポーネントに監視と冗長化を厚くする
• 機能優先順位: コアユースケースに集中する
• テスト戦略: 重大なリスクを持つ部分から徹底的にテストする

ただし、80/20 を守りすぎると残りの20%(重要だが少数のユースケース)を切り捨てる危険があります。ロングテールの効用と組み合わせて考えるとバランスが取れます。

スタージョンの法則

スタージョンの法則(Sturgeon’s Law)は、SF作家 Theodore Sturgeon が1951〜52年に提唱し、1957年に文章化したものです。

あらゆるものの90%はガラクタである。

「あらゆるもののうち90%はガラクタ」。Sturgeon は SF への低評価への反論として、「SF の90%はガラクタかもしれないが、すべてのジャンルの90%もそうだ」と主張しました。

ソフトウェア界では次のような形で参照されます。

• 公開されているライブラリの大半は使えない、または保守されていない
• 大量のチュートリアルや記事は古い、または間違っている
• 新興フレームワークの多くは消える
• スタートアップのプロダクトの多くは失敗する

これは悲観論ではなく、「玉石混交を前提に、選別力を磨こう」という提案として読まれます。Hacker News や GitHub のスターを鵜呑みにせず、ドキュメント、メンテナンス頻度、コミュニティの応答性で評価する姿勢が大切です。

依存ライブラリの選定、技術スタックの選択、情報源の評価において、スタージョンの法則(Sturgeon’s Law)は健全なフィルタとして機能します。

レーマンのソフトウェア進化の法則

レーマンの法則(Lehman’s Laws)は、Manny Lehman と Laszlo Belady が1974年から積み上げた観察で、最終的に8つの法則にまとめられました。代表的なものは次の通りです。

E-type は実世界の活動に組み込まれたソフトウェアで、要件が常に変化するシステムを指します。仕様だけで完結する S-type や手続的処理 P-type とは別カテゴリです。

実務的な含意は次のようなものです。

• 新規機能を足し続けると複雑さは必ず増える
• リファクタリングを意識的に行わないと品質は劣化する
• コードベースの寿命は組織の継続性と相関する
• 安定運用にはフィードバックループ(観測、レビュー、リファクタ)が不可欠

Conway’s Law と並び、システムは静止しない という観察を体系化した古典です。

グリーンスパンの第10法則

グリーンスパンの第10法則(Greenspun’s Tenth Rule)は、Philip Greenspun が1993年頃に書いたとされる皮肉な格言です。

十分に複雑なCまたはFortranのプログラムには、Common Lispの半分を場当たり的に、非公式仕様で、バグだらけで、遅く実装したものが含まれている。

「十分に複雑な C や Fortran のプログラムには、Common Lisp の半分を、場当たりで、非公式仕様で、バグだらけで、遅く再実装したものが含まれている」。

Greenspun 自身が 9つの先行ルールはない、ただ覚えやすい名前にしただけ と認めています。

意図は、複雑なシステムが結局は動的言語の機能(メタプログラミング、関数オブジェクト、ガベージコレクション、リフレクション)を独自に再発明する傾向を皮肉ることでした。実例として、build system が DSL を内蔵するようになる、設定ファイルがチューリング完全になる、テンプレートエンジンが言語化する、といった現象が挙げられます。

現代では、JSON+Jsonnet+HCL+YAML+Helm のような設定言語の階層化、webpack.config.js、build.gradle.kts のような JS/Kotlin スクリプト化が、Greenspun’s Tenth Rule の現代版と言えます。

教訓は「言語的な能力を独自実装しなくて済むよう、最初から表現力のある言語を使う」または「DSL は意識的に設計する」です。

マーフィーの法則

マーフィーの法則(Murphy’s Law)は、Edward Aloysius Murphy Jr. に由来する有名な格言です。

起こりうる悪いことは、必ず起こる。

Murphy は1949年の Edwards 空軍基地(当時 Muroc)の MX981 プロジェクト(人体への加速度耐性試験)に関わったエンジニアで、計測機器の取り付けに失敗が起きたときに発した言葉が起源とされます。

オリジナルは「部品が誤った向きに取り付けられる可能性があるなら、現場で必ず誤って取り付けられる」という防御設計の指針でした。それが「うまくいかないことは必ずうまくいかない」と一般化されました。

ソフトウェアでの典型は次のようなものです。

• 入力フォームに想定外の文字を入れる利用者が必ずいる
• ネットワーク障害は最重要のデモ中に発生する
• データベース接続は最高負荷の瞬間に切れる
• バックアップは必要になるまで動作確認されない
• リリース直後にバグが発覚する

防御策は、Fail Fast、防御的プログラミング、入力バリデーション、リトライ、サーキットブレーカ、カオスエンジニアリングなどです。Murphy’s Law を真剣に受け止めることが、信頼性の高いソフトウェアの起点です。

アムダールの法則とグスタフソンの法則

アムダールの法則(Amdahl’s Law)は、Gene Amdahl が1967年の AFIPS Spring Joint Computer Conference で提示した、並列処理の上限を表す式です。

Speedup = 1 / ((1 - P) + P / N)

ここで P は並列化可能な割合、N はプロセッサ数。P = 0.9 で N = ∞ でも、最大のスピードアップは10倍です。直列部分が全体の足を引っ張ります。

グスタフソンの法則(Gustafson’s Law)は、John L. Gustafson が1988年に示したもので、別の見方を示します。問題サイズが固定ではなく、利用可能な計算資源に応じて拡張される現実を踏まえると、並列化の効果はもっと大きく出ます。

Speedup = N - α(N - 1)

ここで α は直列部分の割合。問題を大きくすれば、α が相対的に小さくなり、並列化が有利になります。

両者は矛盾するのではなく、扱う問題の性質が違います。

実務では、HPC(高性能計算)、機械学習の分散学習、データパイプラインの設計で両者を意識します。並列化の限界と、問題のスケール戦略を分けて考えるのが要諦です。

ムーアの法則

ムーアの法則(Moore’s Law)は、Gordon Moore が1965年の Electronics 誌に寄稿した論文 Cramming more components onto integrated circuits で示した予測です。

集積回路あたりの部品数は、およそ毎年2倍になる。

これは1975年に「2年ごとに倍」に修正されました。ムーアの法則 という呼び名は、Caltech の Carver Mead 教授が後に命名しました。

ムーアの法則(Moore’s Law)は厳密な物理法則ではなく、半導体産業の経済的・工学的進化の経験則ですが、半世紀にわたり概ね成立してきました。これにより、CPU、メモリ、ストレージの性能向上をソフトウェア側が前提にできました。

近年は減速していると言われます。

• 物理的制約(量子トンネリング、発熱)
• 経済的制約(先端プロセスの開発コスト)
• 設計の複雑化

デナードスケーリング(電圧と電流が比例して縮小する)は2005年頃に終わりました。これにより、クロック速度の向上から、マルチコア・並列化・SIMD・GPU・専用アクセラレータ(TPU、NPU)への移行が始まりました。

ソフトウェアエンジニアにとって ムーアの法則(Moore’s Law)は「ハードウェアの性能は永遠に伸びない」と心構えする材料です。Wirth’s Law と組み合わせると、効率的なソフトウェアの重要性が見えてきます。

ピーターの法則

Peter Principle は、Laurence J. Peter と Raymond Hull が1969年の書籍 The Peter Principle で提示した観察です。

階層組織では、すべての従業員は自分が無能になる水準まで昇進する傾向がある。

「階層組織では、すべての従業員はそれぞれの無能のレベルまで昇進する」。優秀な技能で昇進した人が、新しい役割の技能を持たないため、そこで停滞する、という現象を指します。

ソフトウェア業界での典型は、優秀なエンジニアが管理職に昇進し、コーディングの強みを失い、マネジメントの強みも持たないままプラトーに達する、というものです。Microsoft の1990〜2000年代の managerial bloat(管理職肥大化)が典型例として参照されます。

対策として、Individual Contributor track(IC キャリアパス)が普及しました。シニアエンジニア、スタッフエンジニア、プリンシパルエンジニア、ディスティングイッシュドエンジニアといった称号で、管理職にならずに昇進できる仕組みです。Google、Apple、Netflix、Meta などが採用しています。

Peter Principle の批判的な見方も大切です。「現在のスキルが将来のスキルを保証しない」という観察は、教育、メンタリング、ジョブローテーションの重要性を示します。昇進は学習の機会と組み合わせる必要があります。

カニンガムの法則

Cunningham’s Law(カニンガムの法則)は、Wiki の発明者 Ward Cunningham に由来する観察です。実際に表現としてまとめたのは Steven McGeady で、Cunningham が1980年代に Usenet について語ったアドバイスをもとにしているといいます。

インターネットで正しい答えを得る最善の方法は、質問することではなく、間違った答えを投稿することである。

これは、人は他人の誤りを訂正するためには時間を惜しまない、という人間心理を表しています。Wikipedia、Stack Overflow、GitHub Issues といったオンラインコミュニティの現実をよく説明します。

ソフトウェア開発での応用例:

• ストローマン提案(叩き台)を出して議論を始める
• 悪い設計を仮置きして、レビューで改善する
• ペアプログラミングで「これじゃダメだろう」と言わせる
• Pull Request の最初は粗くてもよい、レビューで磨く

ただし、悪用は禁物です。意図的に間違いを書いてコミュニティを困らせる行為は、Cunningham 自身が 誤解の伝播 と批判しています。間違いを真剣に試みる ことと 怠惰の隠れ蓑 の差を意識する必要があります。

Cunningham 本人は法則の所有権を主張せず、これはネットで広まったために自分が言ったことになった誤引用だ とユーモアで対処しています。

パーキンソンの法則

Parkinson’s Law(パーキンソンの法則)は、英国の海軍史学者 C. Northcote Parkinson が1955年の風刺エッセイで提示した観察です。

仕事は、完成のために利用できる時間を満たすまで膨張する。

「仕事は、その完了に与えられた時間を満たすまで膨らむ」。

ソフトウェア開発での現れ方:

• 1週間の見積りタスクは1週間ぴったり使う(Hofstadter’s Lawとも組み合わさる)
• スプリント期間が長いほど、タスクは大きくなる
• 締切が遠いほど、開始が遅れる
• 余裕があるほど、ムダな機能を足してしまう

派生として Parkinson's Law of Triviality(三文の法則、別名 Bikeshedding)があります。

議題の各項目に費やされる時間は、その項目に関わる金額に反比例する。

「議題に費やされる時間は、関連する金額に反比例する」。

例として、Parkinson は 原子炉の建設委員会 を挙げました。原子炉本体の議論は技術が複雑すぎて短時間で終わるが、駐輪場(bike shed)の屋根の色の議論は誰でも参加できるので延々と続く、という風刺です。

ソフトウェア開発の現場でも、変数の命名規則やインデント幅で何時間も議論する一方、アーキテクチャの根本的な選択は短時間で決まる、ということが起きます。

Bikeshedding という用語自体は、1999年に Poul-Henning Kamp が BSD コミュニティで広めました。

対策:

• 議題の重要度をあらかじめ整理する
• 些末な議論には時間制限を設ける
• 重要な決定は時間を確保し、判断材料を準備する
• ADRで意思決定を記録し、再議論を防ぐ

ザウィンスキーの法則

Zawinski’s Law(ザヴィンスキーの法則)は、Mozilla、XEmacs、Netscape Navigator の開発に関わった Jamie Zawinski が提唱した、ソフトウェアの機能膨張に関する観察です。

すべてのプログラムは、メールを読めるようになるまで拡張しようとする。そう拡張できないプログラムは、拡張できるものに置き換えられる。

「すべてのプログラムは、メールを読めるようになるまで機能を拡張しようとする。そうできないプログラムは、できるものに置き換えられる」。

これは Wirth’s Law と並ぶ、ソフトウェアの機能膨張(feature creep)に対する警告です。テキストエディタが IDE になり、IDE が開発環境になり、開発環境がコラボツールになる、という拡張の傾向を捉えています。

現代の例:

• Slack が単なるチャットからメッセージング、ファイル共有、ワークフロー自動化まで拡張
• Notion がドキュメントからタスク、データベース、AIまで
• VS Code がエディタからIDE、リモート開発、ターミナル、Git クライアントまで
• Discord がゲーマー向けボイスチャットからストリーミング、コミュニティ、ストアまで

機能拡張は競争上の理由(NotionとObsidian、SlackとTeams)で必要な場合もあります。一方、機能膨張はWirth’s Lawと連動して、性能と保守性を犠牲にすることもあります。

Do one thing well というUNIX哲学とZawinski’s Lawは対立する観察です。両者を意識して、機能追加の際に「これは本質に必要か、それとも feature creep か」を問う姿勢が大切です。

ワドラーの法則

Wadler’s Law(ウォドラーの法則)は、関数型プログラミング研究者 Philip Wadler が言語設計の議論で観察した法則です。

どんな言語設計でも、この一覧にある機能について議論される総時間は、その位置を指数とする2のべき乗に比例する。

1. 意味論
2. 構文
3. 字句構文
4. コメントの字句構文

つまり:

• セマンティクス(意味論)の議論: 1単位
• 構文(シンタックス)の議論: 2単位
• 字句構文(キーワード、識別子の規則)の議論: 4単位
• コメントの字句構文: 8単位

下に行くほど、本質的でない要素ほど議論が長引く、という観察です。

これは Sayre’s Law(後述)と Bikeshedding の言語設計版と言えます。実際、プログラミング言語のコミュニティでは、タブとスペース セミコロン要否 波括弧の位置 のような表面的な議論が、型システムや並行性モデルといった本質的な議論より圧倒的に多くの時間を消費します。

セイアの法則

Sayre’s Law(セイヤーの法則)は、米国の政治学者 Wallace S. Sayre による、組織内の論争に関する観察です。

どんな論争でも、感情の強さは争点の価値に反比例する。

「あらゆる論争において、感情の強さは争点の価値に反比例する」。

この法則は、Parkinson’s Law of Triviality と Wadler’s Law の上位版です。重要でないことほど人は熱くなる、という観察です。

ソフトウェア開発での現れ方:

• vim vs Emacs の議論
• タブ vs スペース
• セミコロン必須 vs オプショナル
• camelCase vs snake_case
• どの linter を使うか

これらはどれも長期的には大して影響がないのに、何時間も議論される題材です。

対策は Wadler’s Law と同じです。大事な議論には時間と知性を注ぎ、些末な議論は規約で決めて議論を打ち切る、という運用が現実的です。

テスラーの法則

Tesler’s Law(テスラーの法則、「複雑さの保存の法則」)は、Xerox Alto の UI 研究者 Larry Tesler が観察した原則です。

すべてのプロセスには、縮小不可能な複雑さがある。その複雑さをシステムが吸収しなければ、利用者が吸収しなければならない。

つまり、複雑さはゼロにはならず、どこかが吸収する必要があるという観察です。

複雑さの移動

複雑さはシステム内で移動することはあっても、消えることはありません。

たとえば:

• ファイルシステムの概念を隠すと、クラウドストレージの操作は簡潔だが、同期競合やキャッシュ戦略の複雑さが隠れている
• GUI を単純にしすぎると、利用者が手作業や迂回操作で複雑さを補う
• 自動化でセットアップを簡潔にすると、設定ファイルや DSL の複雑さが増える
• API を単純にすると、クライアント側で複雑な処理を重ねる

複雑さは移動するのであり、「本質的な複雑さ」(accidental complexity)と「偶発的な複雑さ」(essential complexity)を分ける必要があります。

ソフトウェアでの現れ方

設計判断では、「どの複雑さが利用者に見えるべきか」を問うことになります。

すべての複雑さを隠すことはできない。だから、どの複雑さを利用者に見せるかを選ぶ。

設計への含意

Tesler’s Law を意識すると、次のようなアプローチが出ます。

• シンプルな UI の背後の複雑さを認める
• 利用者が複雑さを吸収する場面を減らす設計に集中する
• すべてを自動化するのではなく、必要な場所では利用者に制御権を渡す
• API や設定ファイルの複雑さが許容可能か判断する

Wirth’s Law(ソフトウェアはハードウェアより速く遅くなる)と異なり、Tesler’s Law は複雑さそのものが不可避であることを語ります。

ケルクホフスの原理

Kerckhoffs’s Principle(ケルクホフスの原則)は、19世紀のオランダ系暗号学者 Auguste Kerckhoffs が1883年の論文 La Cryptographie Militaire で提示した暗号設計の原則です。

暗号システムは、鍵を除くすべてが公知であっても安全であるべきだ。

「暗号システムは、鍵以外のすべてが公開されても安全であるべきである」。

この原則は、Security through obscurity(隠蔽による安全)の対立概念です。アルゴリズムを秘密にすることで安全を保とうとする方法は、Kerckhoffs の時代から「弱い」と見なされてきました。

理由:

• アルゴリズムは結局漏洩する
• 漏洩したときにシステム全体を作り直すコストが大きい
• 公開すれば多くの目(Linus’s Law)でレビューされる
• 標準化された強い暗号を使う方が安全

現代の暗号(AES、RSA、ChaCha20、Ed25519)はすべてアルゴリズムが公開されており、鍵管理だけが秘密です。これは Kerckhoffs’s Principle に直接従っています。

ソフトウェアセキュリティでも同じ原則が応用されます。

• ソースコードを公開してレビューを受ける(オープンソース)
• 認証トークンや秘密鍵だけを秘密にする
• アーキテクチャは公開してよい、設定値は隠す
• 暗号は自分で書かない(Don’t roll your own crypto)

Don't roll your own crypto は、Kerckhoffs’s Principle と Linus’s Law の組み合わせから出る現実的な指針です。

ピーター・ヒンチェンスの法則

Pieter Hintjens(ZeroMQの作者、2016年没)は、Social Architecture という観点でいくつかの法則を提唱しました。代表的なもの。

バグを見つけるコストは、バグとエラーの間にあるコード行数に比例する。

「バグを見つけるコストは、バグの位置とエラーの位置の間にあるコード行数に比例する」。Fail Fast の精神を別の形で述べたものです。

それをどう壊すか分からないなら、どう直すかも分かっていない。

「壊し方が分からないなら、直し方も分からない」。テストとファジングの重要性を示します。

成功するプロトコルやAPIは、悪用するよりも正しく使う方が簡単である。

「成功するプロトコルやAPIは、悪用するより使う方が楽なものだ」。POLA と相性のよい指針です。

Hintjens の ZeroMQ Guide には、こうした観察が数多く散りばめられており、システム設計の思想として読まれています。

ストールマンの法則

Stallman’s Law(ストールマンの法則)は、Richard Stallman の名を冠した観察ですが、Stallman 自身が提唱したわけではなく、コミュニティで広まった命名です。

企業が社会を支配し法律を作るあいだ、技術の進歩や変化は、利用者をさらに制限したり不当に扱ったりする機会になる。

「企業が社会を支配し法律を書く間、技術の進歩は利用者をさらに制限したり虐げたりする機会となる」。

ソフトウェアの法則というよりも社会観察ですが、ソフトウェア領域では次のような現象を説明します。

• DRM、トラステッドコンピューティング
• データロックインの加速
• ベンダー固有のAI機能による囲い込み
• ソーシャルメディアのアルゴリズム不透明化

Stallman’s Law は、自由ソフトウェア運動の哲学的背景と密接です。商用化と技術の進歩が利用者の自由を侵食する傾向に対する警鐘として読まれます。

ノーヴィグの法則

Peter Norvig(Googleの研究ディレクターを務めた)が提示した、長く成功した技術スタックに関する観察です。

市場シェアが50%を超えた技術は、もう一度2倍にはならない。

「50%のシェアを超える技術は、もう倍にはならない」。

これは技術成長の限界を示します。OS のシェア、ブラウザのシェア、プログラミング言語のシェアなど、市場が一定以上飽和すると、絶対的な伸びは止まり、別の技術が新しいセグメントを作る、というパターンです。

実例:

• Internet Explorer のシェアと Chrome の台頭
• iPhone のシェア飽和と Android の伸び
• Java の絶対的優位から多言語環境へ

技術選定で これが今主流だから永遠に主流 と考えるのは危険です。

カニンガムのもう一つの法則(技術的負債の比喩)

Ward Cunningham は1992年に Technical Debt(技術的負債)の比喩を提唱しました。

初回のコードを出荷することは借金をするようなものだ。少しの借金は、すぐ書き直して返済する限り、開発を速める。

「最初のコードを出荷することは借金のようなものだ。少しの借金は、すぐに書き直しで返済する限り、開発を加速する」。

技術的負債は、利子(=保守コスト)を伴う負債として扱う比喩です。完済しないと利子で破産する、という直感的な理解を可能にします。

ソフトウェア開発における意味:

• 急いで書いたコードは「借金」
• 借金は意識的に作ることもある(締切のため)
• 利子は時間とともに増える(保守の困難)
• 元本を返さないと、新機能の追加コストが上がる
• 破産すると、書き直しが必要になる

技術的負債は Lehman’s Laws の Increasing Complexity とも関連します。リファクタリングを意識的に行わないと、システムは「破産」に向かいます。

ノーヴィグの品質観

Peter Norvig の言葉として知られる、ソフトウェア品質に関する判断軸です。市場シェアの成長限界を扱う前節のノーヴィグの法則とは別の文脈なので、ここでは品質観として整理します。

Wrong in production is worse than slow in development.

「本番環境での不正確さは、開発環境での遅さより悪い」。

つまり、正確性と安定性を手に入れるために開発を遅くすることは許容できるが、速さを優先して本番環境でバグを放つことは許容できない、という判断軸です。

実務での含意

• テストを遅くすることは許容可能
• 本番での障害を避けるための安全装置は重要
• パフォーマンスチューニングより品質第一
• 完璧は敵(Pareto で十分)だが、破壊的バグは許されない

この原則は、スタートアップの「Move Fast and Break Things」と対比されます。初期段階では速さが重要ですが、ある規模に達すると品質が顧客信頼を左右します。

ノーヴィグとクヌース

二人の著名な計算機科学者の言葉が、ソフトウェア開発の哲学を象徴的に表します。

Donald Knuth: 「早すぎる最適化は諸悪の根源である」

Peter Norvig: Wrong in production is worse than slow in development.

両者は矛盾しません。設計時は単純さを優先し、計測した上で必要な箇所を最適化する、というのが両者の共通する姿勢です。

Norvig が編集に関わった Beautiful Code (O’Reilly, 2007)には、こうした原則が実例とともに収められています。

アンダーソンの法則

Anderson’s Law は、技術進化とコストに関する観察です。

今日のぜいたく品は、明日の必需品になる。

または、より正確には Chris Anderson が述べた「Free Economy(フリーエコノミー)」に関する洞察で、デジタル製品やサービスの単位コストが指数的に下がる現象を指します。

ソフトウェアでの現れ方

無料化のパターン:

• クラウドストレージ(かつては企業向けバックアップは高額)
• メールサービス(Gmail が登場するまで企業の買い物リスト)
• バージョン管理(Git の前は商用ツール)
• CI/CD プラットフォーム
• モニタリング・ロギングツール
• APIゲートウェイ

多くの場合、「無料版で十分な層」と「企業向け有料版」の二層構造になります。

経営への含意

Anderson’s Law が示唆するのは:

• ソフトウェアの商用モデルは、「単位原価の低下」に適応する必要がある
• 無料版戦略で市場を取ったスタートアップが、後から料金化で競争優位を失うことがある
• プラットフォーム企業(Google, AWS, Microsoft)が、下流の特定分野の無料化で競合を潰すことがある

「かつて高価だった技術的ケイパビリティが、今や無料で手に入る」という環境変化は、新規参入者には有利でも、既存企業には脅威です。

90-90ルール

Ninety-Ninety Rule(90-90ルール)は、プログラミング通話 Tom Cargill が述べた見積りの陥穽です。

最初の90%のコードは90%の時間で書ける。残りの10%のコードも90%の時間で書ける。

つまり、プロジェクトの最後の10%が、全体の90%の時間を消費する、という観察です。Hofstadter’s Law の変種と言えます。

なぜこうなるのか

• バグ修正が予想外に深い
• エッジケースやUI調整が思った以上に多い
• パフォーマンス問題が後半に見える
• 統合テストで想定外の相互作用が見える
• ドキュメント、リリースノート、サポート対応

最後の10%を侮ると、プロジェクト全体が遅延します。見積り時には「最後の10%は最初の90%と同じくらい時間がかかる」と想定するのが現実的です。

ヘッブの法則

Hebb’s Law(ヘッブの法則)は、神経心理学者 Donald O. Hebb による学習原理です。

Neurons that fire together, wire together.

「一緒に発火するニューロンは、一緒に配線される」。つまり、同時に活動する神経は、その結合を強化するということです。

ソフトウェア開発での応用

この原理は、プログラミング学習やチーム形成に適用できます。

学習:

• 概念を何度も一緒に使えば、関連づけられる
• 問題解決パターンを繰り返し実践すれば、 intuition として身につく
• ペアプログラミング、モブプログラミングで知識が「配線される」

組織:

• 一緒にプロジェクトを進めたチームメンバーは、暗黙知が共有されやすい
• 定期的なコードレビューで、設計判断が shared になる
• ふりかえりを繰り返すと、チームの判断基準が統一される

Hebb の原理は、昨今の神経科学研究では「脳可塑性」「シナプス可塑性」として再検証されており、学習効果と反復の関係を裏支持しています。

アマラの法則

Amara’s Law(アマラの法則)は、技術未来学者 Roy Amara による、技術の社会への浸透に関する観察です。

人間は短期の技術の影響を過大評価し、長期の影響を過小評価する傾向がある。

「短期は楽観的に、長期は悲観的に」という人間の見積もりバイアスを指しています。

ソフトウェアでの現れ方

短期の過大評価(3-5年のタイムスパン):

• AI/LLM は「すぐに人間の仕事を奪う」と予測される
• クラウドは「すぐにオンプレミスを全滅させる」と予測される
• NoSQL は「SQL の時代の終わり」と予測される
• ブロックチェーンは「あらゆる取引を革新する」と予測される
• マイクロサービスは「モノリスの完全な置き換え」と予測される

実際には、5年後のテックスタックのコアは、前の5年と大して変わっていません。

長期の過小評価(10-20年のタイムスパン):

• モバイルの本当の影響(仕事の方法、社会構造、産業の再配置)
• インターネットのセキュリティ課題(IoT、スマートホーム、Supply Chain Attack)
• クラウドの倫理的課題(データ主権、プライバシー、監視資本主義)
• オープンソースの経済的・社会的インパクト
• Linux がどこまで浸透するか(サーバ、組み込み、スマートフォン)

長期で実現する影響は、短期の誇大広告より遥かに深いです。

引き出しへの含意

技術選定や投資判断では、Amara’s Law を意識します。

• ハイプサイクルを参考にするが、短期の過大評価を割引く
• 10年単位のトレンド(基盤技術の安定化)を見る
• 「今流行っているから」と「長期的に必要だから」を分ける
• 短期トレンドに振り回されず、本質的な需要を見る
• 過小評価されている技術(地味だが重要な改善)に気づく力

リードの法則

David P. Reed が提唱した、ネットワーク効果に関する法則です。

大規模ネットワーク、特にソーシャルネットワークの効用は、ネットワークの規模に対して指数的に拡大しうる。

「大規模なネットワーク、特にソーシャルネットワークの効用は、サイズに対して指数関数的にスケールする」。

ネットワークの効用は、可能なサブグループ数(2のn乗)に比例するという観察です。

ソフトウェアエコシステムでは、ライブラリの依存関係、API の互換性、開発者コミュニティの規模が Reed’s Law の効果で価値を生みます。

法則の使い方

ソフトウェアの法則は、実務でどう使えばよいでしょうか。

• 設計レビュー: 「これは Conway の法則で、組織の溝が現れているのでは？」
• ポストモーテム: 「Hyrum の法則で、依存されていなかった振る舞いが依存されていた」
• 見積り会議: 「Hofstadter を考慮して、バッファを2倍にしよう」
• インフラ計画: 「Murphy の法則で、必ずどこかが壊れる前提で組もう」
• KPI設計: 「Goodhart の法則を避けるため、複数指標を組み合わせよう」
• リファクタリング: 「Lehman の法則で、複雑さは自然に増える。意識的に減らす」
• 性能設計: 「Amdahl の法則で、直列部分の最適化が肝心」

法則を持っていると、議論が短くなり、暗黙の前提が可視化されます。「気をつけよう」を「これは Conway なので」に置き換えるだけで、共通理解が早まります。

法則の限界と誤用

ソフトウェアの法則を扱う際の注意点を挙げます。

• 観察であって決定論ではない: Conway の法則は「組織を変えなくてもよい設計が偶然できる」可能性を否定しません。
• 文脈が必要: Brooks の法則は「すでに遅れているプロジェクト」が条件です。すべての増員に当てはまるわけではありません。
• 現代では再考の必要があるものもある: Postel の法則は、現代のセキュリティ要件と衝突する場面があります。
• 数値は厳密ではない: Pareto の80/20、Sturgeon の90% は、傾向の表現であり、計測値ではありません。
• 引用の濫用: 「Hofstadter の法則だから仕方ない」と言って改善を諦めるのは、法則の誤用です。

法則は問いの起点であり、思考停止のための盾ではありません。「この法則はこの状況で本当に当てはまるか」「対処策は何か」を問う姿勢が大切です。

現代開発への接続

ソフトウェアの法則は、現代の開発・運用にも直接的に効きます。

それぞれの法則は古典ですが、現代の文脈に翻訳することで、新しい技術スタックや組織構造の議論にも活用できます。

たとえば LLM エージェントの評価指標は Goodhart’s Law の罠にハマりやすく、API のバージョン互換性は Hyrum’s Law を考慮した設計が必須です。組織の境界を意識的に設計しないと、Conway’s Law が無自覚にアーキテクチャを規定します。

法則のメタ知識

ソフトウェアの法則を扱うときに役立つメタ知識をまとめます。

• 多くの法則は厳密な統計的事実ではなく、観察に基づく経験則
• 文化的な背景(時代、組織、業界)に依存することが多い
• 現代の文脈に翻訳すると、別の現象を説明できる場合がある
• 法則同士は補強したり対立したりする
• 法則名を覚えるだけでは設計力は上がらない、現象を観察して名前を当てはめる練習が大事

これらを意識すると、法則を実用的な思考道具として使えます。

ケーススタディ: コンウェイの法則と組織再編

ある会社で、フロントエンド・バックエンド・モバイルの3チーム制で開発していたが、マイクロサービスへの移行を試みたが失敗した、という話を考えます。

原因:

• チーム境界がアーキテクチャ境界と一致していなかった
• 機能ごとの自律的開発ができず、3チーム間の調整が増えた
• 技術スタック別の組織が、機能別の自律性を阻害した
• リリースが3チームの同期に依存し、頻度が下がった

対処(Inverse Conway Maneuver):

• 機能チーム(プロダクトドメイン別)に再編
• 各チームがフロント・バック・モバイルを横断的に持つ
• 共通基盤チームは Platform チームとして分離
• 機能チームの境界 = サービス境界

結果として、Conway’s Law が機能サービスの境界を強化する方向に働きました。組織変更が伴わないアーキテクチャ変更は、Conway’s Law によって元の構造に引き戻される傾向があります。

ケーススタディ: ハイラムの法則とAPI移行

ある SaaS 企業が、内部APIを v1 から v2 に移行しようとしたとき、想定外の事象が起きました。

• v1 で「順不同で返る」とドキュメントに書かれていたエンドポイントが、実装ではソート順で返していた
• 利用者の40%がソート順に依存していた
• v2 で本当に順不同にしたら、本番障害が複数発生

これが Hyrum’s Law の典型例です。対処:

• v1 を維持し、v2 でソート順を保証する sort パラメータを追加
• v2 のドキュメントに「明示しない限りソート順は保証しない」と記載
• 観測ログから、実際にソート順に依存している利用者を特定
• 段階的にソート順を意図的に乱して、依存を発見

教訓:

• 仕様より観察可能な振る舞いが依存される
• 大規模APIではフェーズドロールアウトが必須
• 移行ガイドだけでは不十分、実装側でも互換性を考慮する

ケーススタディ: ブルックスの法則とプロジェクト遅延

あるプロジェクトが3ヶ月遅延し、5人増員 という対処をした結果、さらに2ヶ月遅延しました。

原因:

• 新しい5人がドメインを理解するのに2ヶ月
• 既存メンバーがオンボーディングに時間を取られた
• コミュニケーションパスが急増し、仕様の伝達ロスが多発した
• 既存設計に新人が入って、設計の一貫性が崩れた

対処:

• 増員はモジュール境界がはっきりした部分にだけ
• スコープを削減して、既存チームで完了可能な範囲を再定義
• ペアプログラミングで知識移転を加速
• 重要な機能は既存メンバーが、補助機能は新メンバーが担当

教訓: ブルックスの法則(Brooks’s Law)は遅延プロジェクトに対する警告であり、増員自体は適切な範囲で計画的に行えば効果があります。

ケーススタディ: グッドハートの法則とKPI

ある開発チームが テストカバレッジ80% を目標に設定しました。半年後の状況:

• カバレッジは85%に到達
• バグは増えた
• テストは無意味な assertion の集合(assert True、assert mock.called)
• 実際のロジック検証はほとんどなかった

これは Goodhart’s Law の典型例です。測定(カバレッジ)が目標になり、本来の意図(品質保証)が失われました。

対処:

• カバレッジを単独の目標から外す
• 結合テスト、エンドツーエンドテストを併用
• バグ密度、本番障害、MTTRなどを多面的に測定
• レビューでテストの内容自体を確認する

教訓: 単一の数値で品質を測ろうとすると、Goodhart’s Law が必ず発動します。複数の指標を組み合わせ、定性的な評価も併用するのが現代的な品質管理です。

ケーススタディ: マーフィーの法則と障害設計

金融サービスで、データベースが落ちることはない という前提で設計したサービスが、本番でDBの計画停止を経験して全面停止しました。

Murphy’s Law の典型適用例:

• DBは必ず落ちる(計画停止、ハードウェア障害、ネットワーク障害)
• ネットワークは必ず分断する
• ディスクは必ず満杯になる
• 監視は必ずアラート疲れを起こす
• バックアップは必ず復元時に問題が出る

対処(カオスエンジニアリング、Netflixの Simian Army):

• 意図的にDBを停止して、サービスがどう振る舞うかを観察
• ネットワーク分断、レイテンシー注入を本番に近い環境で実施
• ディスク満杯、メモリ不足の状況を再現
• バックアップから復元するリハーサル

障害は起きない という前提を捨て、障害は必ず起きるので、起きたときに何が起きるかを設計する という姿勢が、現代の SRE の基本です。

法則を運用に活かすチェックリスト

ソフトウェアの法則を実務で使うためのチェックリストです。

• 組織の境界を見直すとき: Conway’s Law を意識する
• 増員でスケジュール回復を狙うとき: Brooks’s Law を確認する
• 見積りを立てるとき: Hofstadter’s Law でバッファを確保する
• API を変更するとき: Hyrum’s Law で観察可能な振る舞いの依存を確認する
• 寛容な受信を許すとき: Postel’s Law と Fail Fast のバランスを考える
• KPI を設定するとき: Goodhart’s Law が発動しないか確認する
• 機能追加するとき: Wirth’s Law と Zawinski’s Law で増殖していないかチェック
• 大規模設計を始めるとき: Gall’s Law で動く小さなものから始める
• 最適化するとき: Knuth’s words で計測してから取り掛かる
• レビュアーを増やすとき: Linus’s Law を期待しすぎない
• バグを観察するとき: Pareto Principle で集中する
• 並列化するとき: Amdahl’s Law と Gustafson’s Law で限界を見極める
• 障害設計するとき: Murphy’s Law を真剣に受け止める

法則は思考の道具です。状況に応じて引き出せると、設計と運用の判断が早くなります。

よくある質問

Q. 法則と原則の違いは何か？

A. 原則は「すべきこと」を示す指針、法則は「起こりがちなこと」を示す観察です。例えば、SOLID は原則、Conway’s Law は法則です。原則は遵守するもの、法則は対処するものです。

Q. すべての法則を覚える必要はあるか？

A. ありません。コンウェイ / ブルックス / ハイラム / ポステル / Goodhart / Wirth / Knuth / Murphy / Amdahl あたりが現代の実務でよく引用されます。残りは知識として知っておき、必要なときに引き出せれば十分です。

Q. 法則を引用するとき、相手に伝わらない場合は？

A. 法則名だけ言わず、現象を説明してから名前を出すと伝わりやすいです。「組織の境界が設計を縛る、いわゆる Conway’s Law」のように。

Q. 法則は時代遅れになるのか？

A. 一部の法則は時代の文脈で再考されています。Postel’s Law は現代のセキュリティ要件で批判されることがあります。ムーアの法則(Moore’s Law)は減速しています。法則も進化する観察として捉えるのが健全です。

Q. 法則を逆手に取ることはできるか？

A. できます。Cunningham’s Law は「間違いを書いて答えを得る」、ハイラムの法則(Hyrum’s Law)は「自分のコードもいずれ依存される」と意識するなど、法則を予防策に使えます。

Q. 日本のソフトウェア業界で広まっている法則は？

A. Conway、Brooks、Murphy、Knuth が広く知られます。Hyrum、Goodhart、Wirth は近年広まりつつあります。組織や業界によって浸透度は異なります。

Q. 法則を学ぶおすすめの順序は？

A. 1) Murphy(障害は必ず起きる)、2) Conway(組織が設計を縛る)、3) Brooks(人を足しても遅れる)、4) Knuth(早すぎる最適化)、5) Hyrum(観察可能な振る舞いに依存される)、の順で実務的なインパクトが大きいです。

Q. パレートの法則とロングテールはどちらを優先するか？

A. 状況依存です。コアユースケースは Pareto で集中、ビジネスとして長く続けるなら Long Tail も拾う、という使い分けが現実的です。

Q. アムダールとグスタフソン、どちらを参照すべきか？

A. 既存問題のスケールアップを評価するなら Amdahl、問題サイズが計算資源に応じて拡大するなら Gustafson です。HPCや機械学習では両方を意識します。

Q. 法則は新しく作れるか？

A. 観察に基づいて命名すれば作れます。実際、近年は Hyrum’s Law のように現代的な観察が新しく命名されています。ただし、コミュニティに認知されるかは別の問題です。

法則を読むための原典の読み方

法則を深く理解するには、原典の論文や書籍を読むことが重要です。

• Conway: 原典 PDF が melconway.com で公開されている
• Brooks: 「人月の神話」 全体を読むと、「銀の弾丸はない」 も含めた全体像が見える
• Hyrum: Software Engineering at Google の章を読むと現代的な実例が豊富
• Lehman: 8つの法則を整理した論文が無料で入手できる
• Knuth: Structured Programming with go to Statements の文脈は読む価値あり

二次情報(ブログ、まとめ記事)は導入には便利ですが、しばしば誤解や単純化が混じります。原典に当たることで、法則の真の意図と限界が見えてきます。

ハッカー文化と法則

ソフトウェアの法則の多くは、ハッカー文化(Eric S. Raymond の意味で)の中で語り継がれてきました。

• The Jargon File: Greenspun’s Tenth Rule、Cargo Cult Programming などの言葉
• Hacker News: 法則の議論と再評価
• Stack Overflow / Reddit: 実例の蓄積
• GitHub の hacker-laws リポジトリ: コミュニティが整理した法則集

法則を学ぶことは、単に知識を増やすだけでなく、ハッカー文化の語彙を共有することでもあります。

法則の進化

ソフトウェアの法則は、新しい現象を捉えて命名されることで進化を続けます。

新しい法則が生まれる一方、古い法則も再解釈されます。これは観察辞典が常に更新されているということです。

法則を考えるためのフレームワーク

法則を実践に落とし込むには、いくつかのフレームワークが役立ちます。

OODA ループ(Observe-Orient-Decide-Act)と組み合わせる例:

• Observe: 現象を観察する
• Orient: 適切な法則名で現象を整理する
• Decide: 法則の含意を踏まえて対処を決める
• Act: 実行する

例: スプリントが連続で遅延している という観察に対して、Hofstadter's Law を当てはめると、見積りに楽観バイアスがあるという仮説が立ちます。バッファを2倍に増やす スコープを段階的に削減する という対処を決めて実行する、という流れです。

5 Whys と組み合わせる例:

• なぜ本番障害が起きた？ → DBが落ちたから
• なぜDBが落ちた？ → ディスク満杯
• なぜディスク満杯？ → ログローテーションが止まっていた
• なぜ止まっていた？ → 設定ファイルのバグ
• なぜバグに気付かなかった？ → テスト環境では発生しない条件だった

ここで Murphy’s Law を引用すると、「テスト環境で起きないことは本番で起きる」という観察を補強できます。

5 Whys は技術的な root cause を見つける手法、法則は文脈の解釈枠組みです。両方使うと、原因と防止策が明確になります。

ソフトウェア設計のメンタルモデル

ソフトウェアの法則は、設計者のメンタルモデルの一部です。優れた設計者は、法則を意識的に引用しなくても、その含意を反映した判断をしています。

メンタルモデルとして法則を内在化するには:

• 実例を積み重ねる: 過去の障害、成功例を法則の語彙で振り返る
• ポストモーテムで使う: ブレイムレスな分析の中で法則を引用する
• ペアプログラミングで共有する: 法則名で現象を共有することで、思考の枠組みを伝える
• 教える: 新人や同僚に教えるときに、法則を文脈で引く
• 反例を探す: 法則が当てはまらないケースを観察し、限界を理解する

法則を「教科書知識」から「日常の道具」にする努力が、設計判断の質を上げます。

結論と展望

ソフトウェアの法則は、コードや組織を観察するための語彙です。この章では Conway、Brooks、Hofstadter、Hyrum、Postel、Goodhart、Wirth、Gall、Knuth、Linus、Pareto、Sturgeon、Lehman、Greenspun、Murphy、Amdahl、Gustafson、Moore、Peter、Cunningham、Parkinson、Zawinski、Wadler、Sayre、Kerckhoffs、Hintjens、Stallman、Norvig、Reed、Technical Debt と、合わせて30以上の法則を扱いました。

これらは絶対のルールではなく、現象を捉えるレンズです。法則を引き出せると、設計レビュー、ポストモーテム、見積り、技術選定、組織再編といった場面で、議論を短くし、暗黙の前提を可視化できます。

将来、新しい技術スタック(量子コンピューティング、神経計算、AI エージェント)が登場するとき、新しい法則が観察されるでしょう。一方、Conway や Murphy のような古典的な法則は、形を変えて生き続けます。組織が設計を縛り、障害は必ず起きる、という観察は、技術が変わっても変わりません。

法則を学ぶことは、過去の経験と未来の判断をつなぐ橋を持つことです。あなたが次に出会う現象を、法則の語彙で言語化できれば、ソフトウェア工学の集合知の一員になります。

最後に、法則を実践するための心構えを整理します。

• 法則は道具、決定論ではない
• 観察された現象に対して仮説として当てはめる
• 状況に応じて含意を引き出す
• 法則を引用するときは、現象の説明とセットで
• 新しい現象には、既存の法則を変奏したり、新しい命名を試みる
• 法則は思考停止ではなく、思考の起点

法則は静的な知識ではなく、動的に磨かれていく観察辞典です。あなたの組織とコードベースの中で、法則がどう生きているかを観察し続けることが、最も実践的な学びになります。

付録A: 法則早見表

付録B: 法則の関連マップ

法則は単独ではなく、関連し合います。

付録C: 法則を学ぶための書籍

• Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering(Conway、Brooks、No Silver Bullet)
• Douglas Hofstadter, 「ゲーデル、エッシャー、バッハ」(Hofstadter’s Law)
• John Gall, Systemantics(Gall’s Law)
• Donald Knuth, The Art of Computer Programming(最適化と計算量)
• Eric S. Raymond, The Cathedral and the Bazaar(Linus’s Law)
• Niklaus Wirth, 「リーンなソフトウェアへの嘆願」(Wirth’s Law、論文)
• Laurence Peter, The Peter Principle(Peter Principle)
• Titus Winters et al., Software Engineering at Google(Hyrum’s Law、現代の事例)
• Eric Evans, ドメイン駆動設計(境界づけと組織)
• Robert C. Martin, Clean Architecture(SOLID と現代設計)

これらを読むと、法則の文脈と背景が深く理解できます。

付録D: コミュニティ駆動の法則集

オンラインで継続的に整理されている法則集も役立ちます。

• hacker-laws (GitHub): 最大規模の法則集
• Laws of Software: 法則ごとに整理されたサイト
• Laws of Software Engineering: 個別法則の解説
• DevIQ Laws: 設計法則の整理
• Refactoring Guru: 法則と関連するパターン

これらは継続的に更新され、新しい法則の追加もコミュニティが行います。

付録E: 法則を引用するときの注意

法則を会話やドキュメントで引用するとき、いくつかの注意点があります。

• 文脈を説明する: 法則名だけ言わず、現象を簡潔に説明する
• 原典を引く: 二次情報の言い回しと原典は異なることがある
• 適用範囲を明示する: 法則が当てはまる状況とそうでない状況を区別する
• 攻撃の道具にしない: 法則を相手批判に使うと、議論が建設的でなくなる
• 確証バイアスに注意: 法則に当てはまるように現象を歪めて解釈しない

法則は「思考の補助輪」であり、「議論の終結装置」ではありません。

付録F: 法則の翻訳と文化差

ソフトウェアの法則の多くは英語圏で生まれていますが、翻訳すると微妙にニュアンスが変わります。

翻訳して使うときは、原語のニュアンスを補足することで誤解を防げます。

付録G: 自分で観察した法則を提案する

ソフトウェアの法則は、誰でも提唱できます。命名されてコミュニティに認知されるかは別問題ですが、観察を整理することは設計力を磨くトレーニングになります。

法則を作るためのテンプレート:

1. 観察された現象を一文で記述
2. 現象が現れる条件を特定
3. 現象の原因を仮説として整理
4. 対処策があれば併記
5. 反例や限界を明示

例: 朝に書いたコードは午後に読むと信じられないほど悪く見える → 仮称 Refactoring Lag Law。条件: 同じ作業日、原因: 文脈スイッチ、対処: 一晩寝かせる、反例: ペアプログラミングで書いたコード。

このような小さな法則化の習慣は、観察力と設計感覚を磨きます。

付録H: 法則と現代開発の運用

近年のソフトウェア開発トレンドと法則の関係を整理します。

新しいトレンドも、古典的な法則の枠組みで捉え直すと、根底にある本質が見えてきます。

付録I: チームでの法則導入ガイド

法則をチーム文化に取り入れるためのステップです。

1. 共通の語彙を作る: チーム全員が理解する数個の法則から始める
2. ドキュメントに書く: ADRやエンジニアリングハンドブックで参照する
3. レビューで使う: コードレビューや設計レビューで法則を引用する
4. ポストモーテムで活用: 障害分析の中で関連法則を整理する
5. 新人教育に取り入れる: オンボーディング資料に法則を含める
6. 定期的に振り返る: 四半期や半期ごとに法則の活用例を共有する

最初は3〜5個の法則だけに絞ります。Conway、Hyrum、Murphy、Knuth、Goodhart の5つで多くの現場の議論をカバーできます。

付録J: 法則を否定する勇気

ソフトウェアの法則は経験則であり、絶対ではありません。状況によっては法則を意識的に破ることが必要です。

例:

• Brooks’s Law を破る: 独立性の高いサブシステムなら増員が機能する
• Postel’s Law を破る: セキュリティ重視ではFail Fastを優先
• Knuth’s quote を破る: tight loopやリアルタイム処理では早期最適化が正解
• Hofstadter’s Law を破る: 完全に既知の問題なら見積りが正確になる
• Pareto を破る: ロングテール戦略で20%以外も拾う

法則を批判的に評価する力は、設計の成熟度を示す指標です。法則を盲信せず、現象を観察し、必要なら破る判断ができる人が、優れた設計者になります。

付録K: 法則の進化と将来

ソフトウェアの法則は、技術と社会の変化とともに進化します。

近年新しく観察された現象:

• AIモデルのスケーリング則(Chinchilla scaling law、AIモデルのサイズと性能の関係)
• LLMの文脈長依存(コンテキスト窓のサイズと精度の関係)
• マイクロサービスの境界が組織再編で動く(Conway の現代版)
• イベントソーシングと整合性の限界(CAP の現代版)
• フィードバックループの自動化と Goodhart の悪化

将来、これらの観察が新しい法則として命名されるかもしれません。ソフトウェアの法則は静的な辞典ではなく、動的に成長する生き物です。

ソフトウェアの法則を学ぶことは、過去の経験を継承し、現代の現象を整理し、未来の課題を予測する力を養うことです。法則という語彙を持つことで、あなたの設計判断は文脈に深く根ざし、説得力を持つようになります。

付録L: 法則の盲点

ソフトウェアの法則を学ぶときに見落としがちな視点を整理します。

文化的バイアス

多くの法則は欧米のソフトウェア文化、特に米国のシリコンバレーで生まれました。文化が異なる組織での当てはまり方は変わることがあります。

• Brooks’s Law: 個人主義的な組織で強く現れる、集団主義的な組織では立ち上げコストが軽減される場合もある
• Conway’s Law: フラットな組織では境界が変動的になりやすい
• Linus’s Law: コミュニティ規範が成熟していないとレビューの質が伴わない

規模依存性

法則は規模によって当てはまり方が変わります。

• スタートアップでは Hyrum’s Law がほぼ無視できる(利用者が少ない)
• 巨大企業では Conway’s Law が極めて強く現れる
• 中規模では Goodhart’s Law の影響を受けやすい

時代依存性

技術が変わると法則も変わります。

• ムーアの法則(Moore’s Law)は2010年代以降、減速している
• Postel’s Law は現代ではセキュリティとの関係で再評価されている
• リーナスの法則(Linus’s Law)は Heartbleed 以降、限界が認識されている
• ヴィルトの法則(Wirth’s Law)は Web フロントエンドで皮肉にも強く現れている

観測者効果

法則を意識すると、それに合わせて行動が変わることがあります。

• Hofstadter’s Law を意識して見積りを増やすと、Parkinson’s Law でその時間を埋めるよう仕事が膨らむ
• Murphy’s Law を強く意識すると、過剰防御に陥る
• Goodhart’s Law を意識して指標を増やすと、指標の管理コスト自体が問題になる

法則は道具ですが、道具を使うときの自分の態度も観察対象になります。

付録M: 法則を超えて

ソフトウェアの法則を学んだ後、一段上の視点が必要になります。

法則は「現象を整理する語彙」ですが、現実は法則の集合より複雑です。優れた設計者は、法則を引用するだけでなく、法則の背景にあるトレードオフを理解し、状況固有の判断ができます。

• 法則を覚える: 表面的な理解
• 法則を当てはめる: 現象を整理できる
• 法則の含意を引き出す: 対処策を考えられる
• 法則を批判する: 適用範囲と限界を理解できる
• 法則を超える: 新しい観察を組み合わせて、独自の判断ができる

最終的には、法則は設計判断の補助線でしかなく、実際の判断は文脈と経験に基づく独自のものになります。法則を学ぶことは、その独自の判断のための土台を作ることです。

付録N: 法則を題材にしたエッセイ

最後に、いくつかの法則について深掘りしたエッセイ的な記述を加えます。

コンウェイの法則 とリモートワーク

Conway’s Law が観察された1968年と、リモートワーク全盛の2020年代では、コミュニケーション構造の意味が変わっています。

旧来の Conway’s Law は、同じフロアで席が近い 毎日顔を合わせる という物理的距離に基づいていました。リモートワークでは、これがチャットチャンネル、ミーティング頻度、文書ベースの非同期コミュニケーションに置き換わっています。

新しい現象:

• Slackチャンネルの構造が組織図と一致する
• 非同期文書(ADR、RFC)が増えると、コミュニケーション構造が文書化される
• ミーティングが多いチームほど、密結合な設計を作りがち
• 完全非同期チームは、明示的な API と契約に依存する

リモートワーク時代の Inverse Conway Maneuver は、チャネル構造を再編する 定期会議を変える という形で現れます。

ブルックスの法則 と AI コーディング

LLMによるコーディング支援が普及する中、ブルックスの法則(Brooks’s Law)は新しい形で現れています。

• AIエージェントを「人」として足すと、レビューと教育のコストが発生する
• 生成コードのレビューに時間がかかり、ベテラン開発者の負担が増える
• コードベースの一貫性が崩れる(Cargo Cult Programming の AI 版)
• ジュニア開発者がAIに依存し、本質的な学習機会を失う

一方、AIが偶発的複雑さを軽減することで、Brooks の 「銀の弾丸はない」 の議論も再考されつつあります。AIは銀の弾丸ではないが、偶発的複雑さを大幅に減らせる新しい道具です。

ハイラムの法則 と AI モデル

LLMのバージョンアップ時、利用者は出力の細かいスタイルや特性に依存しています。

• プロンプトが特定モデルの応答パターンに最適化されている
• 出力フォーマットの細部に依存している
• レイテンシ特性に依存している
• 特定のバイアスや傾向に依存している

これは Hyrum’s Law の AI モデル版です。OpenAI、Anthropic、Google などが新モデルをリリースするたびに、利用者の一部のプロンプトが微妙に動かなくなる現象が観察されます。

対処は API と同じです。フェーズドロールアウト、互換性レイヤー、明示的な依存契約。

グッドハートの法則とLLM評価

LLMの評価指標(MMLU、HumanEval、GSM8Kなど)が目標になると、その指標に最適化されたモデルが現れます。

• ベンチマーク特化のチューニング
• データリーケージ(評価データが訓練データに含まれる)
• 評価戦略の変化(プロンプト工学による底上げ)

これは Goodhart’s Law の典型例です。新しいベンチマークが定期的に必要になる理由でもあります。

マーフィーの法則 と 分散システム

クラウドネイティブの分散システムでは、Murphy’s Law がほぼ確実に発動します。

• ネットワーク分断は必ず起きる
• ノード障害は必ず起きる
• レプリケーション遅延は必ず起きる
• 想定外の負荷は必ず来る
• 設定ミスは必ず本番で見つかる

カオスエンジニアリング(Netflix、Google、Amazon)は、Murphy’s Law を真剣に受け止めた工学的アプローチです。障害は起きない という前提を捨て、障害が起きたときに何が起きるかを設計する という姿勢の象徴です。

法則を統合する視点

複数の法則を統合すると、より深い洞察が得られます。

• Conway × Brooks: 組織の境界が設計を縛り、人を足すとコミュニケーションが爆発する → 境界を意識した増員計画
• Hyrum × Postel: 観察可能な振る舞いに依存され、寛容な受信が依存を温存する → 厳密な仕様と意図的な乱雑化
• Murphy × Lehman: 障害は必ず起き、システムは必ず複雑になる → 継続的な observability とリファクタリング
• Goodhart × Pareto: 指標は腐敗し、効果は集中する → 多面的な指標と重要箇所への集中

法則は単独でも有用ですが、組み合わせるとより強力な思考道具になります。

結語

ソフトウェアの法則を学ぶことは、ソフトウェア工学の歴史を学ぶことでもあります。Conway、Brooks、Knuth、Postel、Lehman、Liskov、Wirth、Pareto、Murphy ── これらの名前は、ソフトウェアという若い学問領域の先駆者たちです。

彼らが半世紀前に観察した現象は、今もなお現代の開発現場で繰り返されています。技術スタックは変わっても、組織の構造、人間の認知、コードベースの進化、システムの複雑化、利用者の依存、といった本質は変わりません。

法則を学ぶことは、こうした不変の現象を捉える視点を持つことです。新しい技術が出てくるたびに これは新しい現象だ と驚くのではなく、これは Conway の現代版だ これは Hyrum の AI 版だ と整理できる視点を持つことが、長く活躍できる設計者の条件です。

最後に、ソフトウェアの法則を実務で使うときの究極の指針を一つ挙げるなら、それは次の言葉です。

法則を知れ、しかし法則に縛られるな。

法則は道具であり、教義ではありません。観察された現象に対して仮説として当てはめ、状況に応じて含意を引き出し、必要なら破る判断をする。この柔軟さこそが、法則を真に活用するということです。

付録O: 各法則の歴史的背景の深掘り

Conway’s Law の生まれた時代

Conway’s Law が生まれた1967〜1968年は、ソフトウェア開発が アート から 工学 へ移行しつつあった時代です。1968年の NATO Software Engineering Conference で Software Engineering という言葉が広まり、Software Crisis の認識が始まりました。

Melvin Conway は当時、汎用言語の処理系を作る研究をしており、委員会 構造の組織がどう設計に影響するかを観察していました。彼の論文 How Do Committees Invent? は最初 Harvard Business Review に投稿されましたが、却下され、最終的に Datamation 誌に掲載されました。

Fred Brooks が The Mythical Man-Month(1975)で Conway’s Law を引用したことで、ソフトウェア工学の古典として定着しました。

Brooks’s Law と OS/360

Brooks’s Law の背景には、IBM の System/360 プロジェクトの教訓があります。Brooks は1964年からこの巨大プロジェクトのマネージャを務め、5000人以上のエンジニアを管理しました。

スケジュール遅延を取り戻すため何度も増員したが、結果は逆効果でした。この経験から The Mythical Man-Month が生まれました。

Brooks 自身が驚いたことに、この本は40年以上経った今も売れ続けています。組織と人間の本質は変わらないため、技術が変わっても教訓は古びません。

Hyrum’s Law と Google の規模

Hyrum’s Law は Google の Hyrum Wright が経験から定式化しました。Google のような巨大コードベース(数十億行のモノリポ、数万のエンジニア)では、APIの観察可能な挙動が必ず誰かに依存される、という現象が日常的に観察されます。

Software Engineering at Google(Winters, Manshreck, Wright 編、2020)の章では、Hyrum’s Law を考慮した:

• Beyoncé Rule(壊したら鳴らせ、だから自動テストで全社を守る)
• Forklift Upgrades(一気に書き換えるための自動化基盤)
• LSC(Large-scale changes、大規模変更を可能にする仕組み)

といった実践が紹介されています。

Postel’s Law と HTML の歴史

Postel’s Law が問題を起こした典型例は HTML の歴史です。1990年代初頭、ブラウザは寛容に HTML を解釈し、不正なタグも何とか表示しようとしました。

結果、Web は 動くなら何でも書ける 状態になり:

• パーサがブラウザごとに違う
• 同じページが違って表示される
• セキュリティホール(XSS)が生まれる
• 標準化が困難

WHATWG が HTML5 で 定義された誤りの修復ルール を作るまで、Postel’s Law が現実の混乱を生み続けました。現代の HTML5 標準は、不正な HTML をどう解釈するかを厳密に定義しており、ブラウザ間の差を解消しています。

これは Postel’s Law の現代的な再評価の一例です。寛容性 は 定義された範囲内 で行うべきで、何でも受け入れる ことではない、という教訓です。

Goodhart’s Law の経済学的起源

Goodhart’s Law は、英国の中央銀行が金融政策で観察した現象から生まれました。マネーサプライを目標にすると、その指標は政策手段として機能しなくなる という観察でした。

これは Lucas Critique(Robert Lucas、1976)と類似した経済学的洞察です。政策が変わると、人々の行動も変わるので、過去の統計的関係は崩れる という命題です。

ソフトウェア開発における類似:

• テストカバレッジを目標にすると、無意味なテストが量産される
• バグ件数を評価指標にすると、隠蔽が増える
• デプロイ頻度を目標にすると、リスクの高いデプロイが増える

人間の行動が指標に応答することで、指標の意味が崩れる、という現象です。

Wirth’s Law と Niklaus Wirth の哲学

Niklaus Wirth は Pascal、Modula-2、Oberon の作者で、小さく美しい言語 を一貫して追求した人物です。彼の A Plea for Lean Software(1995)は、ソフトウェアの肥大化への警鐘でした。

Wirth は Oberon System で、最小限のハードウェアで動く実用 OS を実装し、lean software が可能であることを実証しました。

Wirth’s Law が皮肉なのは、現代のソフトウェアが Oberon の対極にあることです。Web ブラウザのメモリ使用量、Electron アプリのサイズ、Docker イメージの肥大化、すべて Wirth’s Law を実証しています。

しかし、Wirth’s Law は宿命ではありません。意識的に lean を選ぶ設計者は、現代でも軽量なソフトウェアを作っています。Go、Zig、Rust の一部のプロジェクトは、Wirth の精神を継承しています。

Lehman’s Laws の40年

Manny Lehman は IBM Research で OS/360 の進化を研究しました。彼の最初の論文は1969年で、その後40年以上にわたって法則を改良し続けました。

特に重要なのは、E-type システム(実世界の活動に組み込まれたシステム)と S-type システム(仕様で完結するシステム)の区別です。E-type は環境の変化に合わせて進化せざるを得ません。

現代のソフトウェアのほぼすべてが E-type です。SaaS、モバイルアプリ、エンタープライズシステム、すべて環境変化に応答する必要があります。

Lehman の Continuing Change と Increasing Complexity は、リファクタリング文化の理論的根拠を提供しています。複雑さは放置すれば自然に増えるので、意識的に下げる努力が必要、という命題です。

Murphy’s Law と航空宇宙

Murphy’s Law は1949年の Edwards 空軍基地(当時 Muroc)の MX981 プロジェクトで生まれました。これは人体の加速度耐性を測る実験で、ロケットスレッドに人を乗せる過酷な研究でした。

エンジニアの Edward A. Murphy Jr. は計測機器の取り付けに失敗し、誤った向きに取り付けられる可能性があるなら、現場で必ず誤って取り付けられる と語ったとされます。

これは 防御設計 の原則として始まりました。後に Anything that can go wrong will go wrong と一般化されました。

ソフトウェアにおける Murphy’s Law の現代版:

• Site Reliability Engineering(SRE)の前提
• カオスエンジニアリング(Netflix の Chaos Monkey)
• 障害シナリオベースのテスト
• 多層防御(Defense in Depth)

障害は起きない という前提を捨て、障害が起きたときに何が起きるかを設計する 姿勢が、現代の信頼性エンジニアリングです。

付録P: 法則の批判と再評価

ソフトウェアの法則は古典として尊重されますが、現代では批判や再評価も進んでいます。

Postel’s Law への批判

2023年の Martin Thomson と David Schinazi の論文 The Robustness Principle Reconsidered は、Postel’s Law を強く批判しました。

Postel’s robustness principle should be considered an antipattern.

理由:

• 寛容な受信は仕様違反の実装を温存する
• セキュリティホールを生む
• 長期的にプロトコル全体を弱める

代替として、厳密に検証し、エラーを早く返す ことが推奨されます。これは Fail Fast 原則と一致します。

Linus’s Law への批判

Robert Glass は Linus's Law を mantra(マントラ)と呼び、実証的な根拠が薄いと指摘しました。Heartbleed(2014年)の発見遅延は、Linus’s Law の限界を示しました。

OpenSSL は世界中のシステムが依存する重要ライブラリでしたが、何年も気付かれない脆弱性が含まれていました。目があれば ではなく 専門的な目があれば という条件付きでないと、Linus’s Law は機能しません。

これを受けて、Linux Foundation は Core Infrastructure Initiative(CII)を立ち上げ、重要なオープンソースプロジェクトに資金を提供してセキュリティ監査を促進する活動を始めました。

Brooks’s Law の再評価

Brooks’s Law は1975年の文脈で生まれましたが、現代の分散開発では条件が変わっています。

• Git のような分散バージョン管理
• リモートワークによる地理的分散
• 自動化(CI/CD、テスト)
• マイクロサービスによる独立性

Frederick Brooks 自身は No Silver Bullet—Refired(1995)で、Brooks's Law が完全に成り立たない場面もある と認めました。独立性の高いサブシステムなら、増員は機能します。

Moore’s Law の終焉

Moore’s Law は2010年代以降、明確に減速しました。

• 半導体プロセスの微細化が物理的限界に近づく
• 開発コストが指数的に増大
• 性能向上の大部分はクロック以外の工夫(マルチコア、SIMD、専用アクセラレータ)

Moore's Law is dead という議論は2010年代から繰り返されており、半導体産業の常識でもあります。代わりに Domain-Specific Architecture が次の波として注目されています。

Pareto Principle の限界

80/20 の Pareto は便利な経験則ですが、すべての分布が80/20 ではありません。多くの自然現象は べき乗則(power law)に従いますが、指数や分布の形は変わります。

Long Tail の議論(Chris Anderson、2004)は、80/20 の vital few だけでなく、useful many の重要性を指摘しました。Amazon、Netflix のようなプラットフォームでは、Long Tail がビジネスの重要部分です。

Gustafson’s Law と Amdahl’s Law の使い分け

両法則は、スケーラブルな計算 の異なる側面を捉えます。

• Amdahl: 固定問題サイズでの並列化限界
• Gustafson: 問題サイズが資源に応じて拡大する場合

実際のシステムは両方の側面を持ちます。スループットを上げたい なら Gustafson 寄り、レイテンシを下げたい なら Amdahl 寄り、という使い分けが現実的です。

付録Q: 法則を組み合わせた事例分析

複数の法則を組み合わせて分析すると、複雑な現象も整理できます。

事例1: マイクロサービス移行の失敗

ある企業がモノリスから100サービスに分割した結果、開発生産性が下がりました。

関連する法則:

• Conway’s Law: チーム構造とサービス境界が一致しない
• Brooks’s Law: サービス間調整でコミュニケーションコスト爆発
• Hyrum’s Law: サービス間APIの観察可能な依存
• Wirth’s Law: サービスメッシュ・トレーシング・観測ツールでメモリ消費増大
• Hofstadter’s Law: 移行が予定の3倍の時間
• Goodhart’s Law: 「サービス数」が KPI になり粒度が誤った

対処は組み合わせて行う必要があります。

事例2: AI 機能の品質低下

LLM を使った機能の品質が、ユーザー数増加とともに低下しました。

関連する法則:

• Hyrum’s Law: ユーザーがプロンプトの細かい応答に依存
• Goodhart’s Law: ベンチマーク指標を改善するためのチューニングが本物の品質を犠牲に
• Wirth’s Law: モデルが大きくなり推論コスト増大
• Murphy’s Law: エッジケースで予測不可能な出力
• Pareto Principle: クエリの20%が80%の問題を起こす

複数法則の交差点で問題が発生しています。

事例3: スタートアップの組織崩壊

急成長したスタートアップが、エンジニアの離職と品質低下に直面しました。

関連する法則:

• Brooks’s Law: 急速な増員でコミュニケーション混乱
• Conway’s Law: 組織変更がアーキテクチャを歪める
• Peter Principle: 創業エンジニアが管理職に昇進、強みを失う
• Lehman’s Continuing Change: コードベースの複雑さ増大
• Hofstadter’s Law: 機能リリースが常に遅れる
• Goodhart’s Law: ベロシティを目標にして質が低下

組織の問題は技術の問題と切り離せない、Conway’s Law の現代的な事例です。

付録R: 法則を引用するための語彙集

実務で法則を引用する際の語彙を整理します。

法則名を出すだけでなく、現象の説明とセットで使うと伝わりやすくなります。

付録S: 法則を学ぶための練習

法則の理解を深めるための練習をいくつか提案します。

練習1: 過去の障害分析

過去のポストモーテムを読み、関連する法則を当てはめてみる。新しい視点で原因が整理できるかもしれません。

練習2: 流行の技術を分析

最新のトレンド(生成 AI、Edge Computing、サーバレス)を、既存の法則で分析する。これは Wirth's Law の再来 これは Goodhart's Law の AI 版 といった発見ができるかもしれません。

練習3: 組織の観察

自分の組織を Conway’s Law、Brooks’s Law、Peter Principle で観察する。改善のヒントが見つかるかもしれません。

練習4: コードベース分析

自分のコードベースを Hyrum’s Law、Lehman’s Laws、Wirth’s Law で分析する。改善の優先順位が見えてくるかもしれません。

練習5: 自分なりの法則を作る

繰り返し観察する現象に名前をつけて、〜Law として定式化してみる。コミュニティに認知されなくても、自分の思考整理の道具になります。

法則を学ぶことは、観察力を磨くことです。新しい現象に出会ったときに これは何の法則か と問う習慣が、長期的な設計力を上げます。

付録T: 法則と AI

近年の AI/LLM の登場で、ソフトウェア法則はどう変わるか、考察します。

AI と Conway’s Law

LLM がコードを書く時代、組織の境界 がどう変わるか。AI エージェントは人間ではないが、コミュニケーション構造 の一部です。AI を組み込んだチームは、AI を含めたコミュニケーション構造を持ち、それがアーキテクチャに反映されるかもしれません。

AI と Brooks’s Law

AI で生産性が劇的に向上するなら、Brooks’s Law は弱まるか?

実際は逆の可能性があります。AI が大量のコードを生成するため、レビューと統合のコストが増えます。AI を 人手 として足すと、人間がレビューするコストでオフセットされます。

AI と Hyrum’s Law

LLM の出力に依存する利用者は、モデルのアップデートで影響を受けます。プロンプトの細かい挙動、レイテンシ、特定のフレーズへの反応、すべてが Hyrum’s Law の対象です。

OpenAI、Anthropic、Google のメジャーアップデートで、利用者のプロンプトが微妙に動かなくなる現象が頻発しています。

AI と Goodhart’s Law

LLM の評価ベンチマーク(MMLU、GSM8K、HumanEval)が目標になると、Goodhart’s Law が発動します。ベンチマーク特化のチューニング、データリーケージ、評価戦略の最適化が増え、ベンチマークの意味が崩れます。

新しいベンチマーク(MMLU-Pro、Chatbot Arena、HumanEval+)が定期的に必要なのは、Goodhart’s Law を意識した結果です。

AI と Wirth’s Law

LLM のサイズと推論コストは指数的に増えています。ハードウェアの進化(H100、B200、TPU、専用 ASIC)が追いつかず、Wirth’s Law が極めて顕著に現れています。

大きいモデルが正解 という流れに対して、SLM(Small Language Model)、Distillation、Mixture of Experts、Quantization といった lean AI の動きが対抗策として登場しています。

AI と Murphy’s Law

LLM は確率的な出力を返すため、Murphy’s Law がより強く現れます。エッジケースで予測不可能な出力 ハルシネーション プロンプトインジェクション data poisoning といった事故が必ず起きます。

Robust AI Adversarial Testing Safety Layer といったプラクティスが、Murphy’s Law の AI 版への対処です。

新しい法則の予感

AI 時代の新しい法則が観察されつつあります。

• Scaling Law(Chinchilla、Kaplan ら): モデルサイズ・データ量・計算量と性能の関係
• Hallucination Law: LLMは確信を持って間違える傾向がある
• Emergence Law: 大きさを超えるとできなかったタスクが突然できる
• Capability Overhang: モデルの潜在能力と利用者の引き出し方のギャップ

これらが将来 Hyrum's Law のように業界標準の語彙になるかもしれません。

終章: 法則の永続性

ソフトウェア工学の法則を学んできた最後に、なぜこれらが時を超えて生き残るかを考えます。

人間の不変性

技術は急速に変わりますが、人間の認知、組織の力学、社会的相互作用は変わりません。Conway’s Law、Brooks’s Law、Peter Principle、Goodhart’s Law は、人間の本質を捉えているため、技術が変わっても通用します。

計算の物理的制約

Amdahl’s Law、Moore’s Law(の減速)、Gustafson’s Law は、計算の物理的・数学的限界を捉えています。物理法則は変わらないので、これらの法則も普遍的です。

システムの複雑さ

Lehman’s Laws、Wirth’s Law、Greenspun’s Tenth Rule は、システムが時間とともに複雑化する性質を捉えています。エントロピー増大の法則の情報科学版とも言えます。

コミュニケーションのコスト

Brooks’s Law、Hyrum’s Law、Postel’s Law は、システム間・人間間のコミュニケーションコストを捉えています。情報の伝達、契約、依存は、いつの時代も計算機科学の核です。

これらの法則は、ソフトウェア工学が アート から 科学 へ、そして 工学 へと成熟する過程で蓄積された知恵です。新しい技術、新しいパラダイム、新しい問題が出てきても、これらの法則は形を変えて再演されます。

法則を学ぶことは、ソフトウェア工学の不変な部分を学ぶことです。変わるものと変わらないものを区別する視点を持つことで、技術の流行に振り回されず、本質的な判断ができるようになります。

最後に、ソフトウェアの法則を一言で表すなら、次のようになるでしょう。

法則は道具、しかし思考の道具である。

法則を覚えても設計力は上がりません。法則を引き出して現象を整理し、含意を引き出し、対処を考える、という思考のプロセスを身につけることが、本当の学びです。

あなたが次にソフトウェア工学の現場で出会う現象を、法則の語彙で言語化できれば、ソフトウェア工学の集合知の一員になります。そしていつか、あなた自身の観察が、新しい法則として命名される日が来るかもしれません。

• The Cathedral and the Bazaar
• Wikipedia: Pareto principle
• Wikipedia: Sturgeon’s law
• Wikipedia: Lehman’s laws of software evolution
• Wikipedia: Greenspun’s tenth rule
• Wikipedia: Murphy’s law
• Wikipedia: Amdahl’s law
• Wikipedia: Gustafson’s law
• Wikipedia: Moore’s law
• Gordon Moore, Cramming more components onto integrated circuits (1965)
• Wikipedia: Peter principle
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
• John Gall, Systemantics: How Systems Really Work and How They Fail
• Douglas Hofstadter, 「ゲーデル、エッシャー、バッハ」
• Eric S. Raymond, The Cathedral and the Bazaar
• Laurence J. Peter and Raymond Hull, The Peter Principle
• Titus Winters, Tom Manshreck, and Hyrum Wright (eds.), Software Engineering at Google

まとめ

ソフトウェアの法則は、実務で繰り返し観察されてきた現象に名前を付けたものです。Conway は組織と設計、Brooks は人と進捗、Hofstadter は時間、Hyrum はインターフェース、Postel は寛容性、Goodhart は測定、Wirth は性能と機能、Gall はシステム成長、Knuth は最適化、Linus と Sturgeon と Pareto は品質と分布、Lehman は進化、Murphy は事故、Amdahl と Gustafson は並列、Moore はハードウェア進化、Peter は組織のキャリアを扱います。

これらは絶対のルールではなく、設計判断やレビュー、ポストモーテム、見積りで参照する語彙です。法則を引き出せると、議論は短くなり、暗黙の前提が可視化されます。

重要なのは、法則名を暗記することではなく、現象を観察したときに「これは Conway っぽい」「これは Hyrum の典型だ」と言語化できることです。原則がコードを書く前の指針なら、法則はコードと組織を運用しながら参照する観察辞典です。両方を持つことで、ソフトウェア開発の判断は強くなります。

参考文献

論文

• Donald Knuth, Structured Programming with go to Statements (ACM)
• Melvin Conway, How Do Committees Invent?
• The Robustness Principle Reconsidered (ACM Queue)

書籍

• Eric S. Raymond, The Cathedral and the Bazaar

解説・補助

• Wikipedia: The Mythical Man-Month
• Hyrum’s Law
• John Gall, Wikiquote
• Niklaus Wirth, A Plea for Lean Software
• Wikipedia: Brooks’s law
• Wikipedia: Conway’s law
• Wikipedia: Goodhart’s law
• Wikipedia: Hofstadter’s law
• Wikipedia: Linus’s law
• Wikipedia: Robustness principle
• Wikipedia: Wirth’s law