ソフトウェア工学の法則集

 (lawsofsoftwareengineering.com)
124 ポイント 投稿者 GN⁺ 8 일 전 | 2件のコメント | WhatsAppで共有
  • ソフトウェアシステム、チーム、意思決定に影響を与える56の原則とパターンを一か所に集めたコレクションで、チーム運営からアーキテクチャ、品質、設計、意思決定まで幅広い領域を網羅
  • Conwayの法則、Brooksの法則、Dunbar数などチーム関連の法則は、組織構造がシステム設計と生産性に直接影響することを示している
  • アーキテクチャ領域ではHyrumの法則、CAP定理、Gallの法則など、複雑なシステム設計時に必ず考慮すべき制約と原則を整理
  • 品質関連の法則では技術的負債、テストピラミッド、Kernighanの法則など、コード品質の維持とデバッグの現実的な難しさを扱う
  • 意思決定領域ではダニング＝クルーガー効果、サンクコストの誤謬、パレートの法則など、開発プロセスで陥りやすい認知バイアスと判断基準を網羅

チーム（Teams）

1. Conwayの法則（Conway's Law）

組織は、そのコミュニケーション構造をそのまま反映したシステムを設計する

  • ソフトウェアアーキテクチャは、それを作った組織のコミュニケーション構造に自然と従う現象
  • チームが3つに分かれていれば、システムも3つの大きなモジュールに分かれる傾向がある
  • これを逆に活用する**「逆Conway戦略」**（Inverse Conway Maneuver）も存在する: 望むアーキテクチャに合わせて先にチーム構造を再編するアプローチ
  • マイクロサービス導入時には、チーム境界とサービス境界を一致させることが効果的

2. Brooksの法則（Brooks's Law）

遅延しているソフトウェアプロジェクトに人員を追加すると、かえってさらに遅れる

  • 新しい人員が加わると、既存メンバーが教育と調整に時間を費やすため、チーム全体の生産性が一時的に低下
  • メンバーが増えるほどコミュニケーション経路が幾何級数的に増加する（n人のとき n(n-1)/2）
  • Frederick BrooksがIBM OS/360プロジェクトの経験をもとに、1975年の著書 The Mythical Man-Month で定式化
  • Littleの法則（L = λ × W）でも定量的に説明可能: 人員追加でWIP（仕掛中の作業項目）は増えるが、スループットは停滞し、リードタイムがむしろ増加
  • 解決策は人員追加ではなく、スコープ調整またはスケジュール変更

3. Dunbar数（Dunbar's Number）

1人が安定して維持できる関係の認知的限界は約150人

  • Robin Dunbarが霊長類の脳の大きさと社会集団規模の相関関係から導いた数値
  • Dunbarの社会的階層構造: 約5人（親密な関係）、約15人（信頼できる協力者）、約50人（近い業務関係）、約150人（安定した社会的つながり）
  • エンジニアリング組織が150人を超えると、非公式なコミュニケーションが限界に達し、公式な階層とプロセスが必要になる
  • Amazonの**「Two-Pizza Team」**（5〜10人）は、150人の範囲内でも実質的な協業はより小さな単位で起きることを反映

4. リンゲルマン効果（The Ringelmann Effect）

グループの規模が大きくなるほど、個人の生産性は低下する

  • グループ構成員が増えるほど各個人の貢献度が下がる**「社会的手抜き」**（social loafing）現象
  • ソフトウェアチームでも、チーム規模が大きくなると個々の責任感が薄れ、調整コストが増加
  • 小規模チームのほうが1人当たりの成果が高い理由を説明する

5. Priceの法則（Price's Law）

参加者総数の平方根にあたる人数が、全作業の50%を担う

  • 100人の組織では約10人が全作業の半分を担う
  • 組織が大きくなるほど、少数の高業績者への依存度が深まる
  • チーム拡大時に生産性が線形に増加しない理由を説明する

6. Puttの法則（Putt's Law）

技術を理解する人は管理せず、管理する人は技術を理解しない

  • 技術組織における管理職の役割と技術的専門性の乖離を風刺的に表現
  • 技術リーダーシップ構造を設計する際には、このギャップを認識し補完する仕組みを用意する必要がある

7. Peterの法則（Peter Principle）

組織ではすべての社員が自分の無能レベルに達するまで昇進する傾向がある

  • ある役割で有能だった人が昇進し、新しい役割では無能になるパターン
  • 優れた開発者が必ずしも良いマネージャーになるわけではないという現実を反映
  • IC（Individual Contributor）トラックとマネジメントトラックを分離するデュアルラダー制度の必要性

8. Bus Factor

プロジェクトが深刻なリスクにさらされる可能性がある最小のチーム離脱人数

  • Bus Factorが1であれば、単一障害点（Single Point of Failure）が存在する状態
  • 知識共有、ペアプログラミング、文書化によってBus Factorを高めることが重要
  • コードレビューとクロストレーニングがBus Factorを改善する実践的な方法

9. Dilbert原則（Dilbert Principle）

企業は無能な社員を管理職に昇進させ、被害を限定する傾向がある

  • Scott Adamsが提唱した風刺的な観察で、Peterの法則の変形
  • 管理職が現場業務で最も被害を与えにくいポジションと見なされる逆説的な組織現象

計画（Planning）

10. 早すぎる最適化 / Knuthの最適化原則（Premature Optimization）

早すぎる最適化は諸悪の根源である

  • Donald Knuthが1974年の論文で提示: 「約97%のケースでは小さな効率性は無視すべきだ」
  • コードの約20%が実行時間の80%を占めるため、残り80%のコードを最適化するのは無駄
  • 正しい順序: まず動くようにし → 正しくし → 必要なら速くする
  • 最適化されたコードは複雑性が高くなるため、プロファイリングで実際のボトルネックを確認してから行うべき

11. Parkinsonの法則（Parkinson's Law）

仕事は与えられた時間をすべて満たすまで膨張する

  • 締め切りが2週間なら2週間、4週間なら4週間かけて仕事が膨らむ現象
  • ソフトウェアプロジェクトで短く明確なマイルストーンの設定が重要な理由
  • スプリントベースのアジャイルは、この法則に対する実践的な対応方法

12. 90-90の法則（The Ninety-Ninety Rule）

コードの最初の90%が開発時間の90%を占め、残り10%がさらに別の90%の時間を占める

  • ソフトウェアプロジェクトの最後の10%（エッジケース、磨き込み、バグ修正）が予想よりはるかに長くかかることへの警告
  • 「ほぼ完成」という言葉が、実際には全体スケジュールの半分地点である可能性がある

13. Hofstadterの法則（Hofstadter's Law）

Hofstadterの法則を考慮しても、常に予想より長くかかる

  • 再帰的自己参照構造を持つ法則で、ソフトウェア日程見積もりの本質的な難しさを表現
  • バッファを追加しても依然としてスケジュールを超過する現実
  • Douglas Hofstadterが1979年の著書 Gödel, Escher, Bach で紹介

14. Goodhartの法則（Goodhart's Law）

測定指標が目標になると、もはや良い測定指標ではなくなる

  • コードカバレッジをKPIに設定すると、意味のないテストが量産される現象が代表例
  • コード行数（LOC）で生産性を測ると、不必要に冗長なコードが生まれる
  • 指標の最適化ではなく、本質的な価値の達成に集中すべき

15. Gilbの法則（Gilb's Law）

定量化が必要なものは、まったく測定しないよりも、何らかの形で測定するほうがよい

  • 完璧な測定が不可能でも、おおまかな測定は無測定より常に有益
  • ソフトウェア品質、ユーザー満足度など、定量化が難しい項目にも適用できる

アーキテクチャ（Architecture）

16. Hyrumの法則（Hyrum's Law）

API利用者が十分に多ければ、システムの観測可能なあらゆる振る舞いに誰かが依存する

  • 公式API仕様だけでなく、タイミング、エラーメッセージの形式、ソート順などの非公式な挙動も依存対象になる
  • Microsoft Windowsが、過去に文書化されていない挙動やバグに依存するサードパーティアプリとの互換性のために旧バージョンの挙動を維持した事例
  • GoogleのHyrum Wrightが、2011〜2012年ごろのGoogle社内ライブラリ変更の経験から観察
  • 同僚のTitus Wintersが「Hyrum's Law」という名前を付けた（Software Engineering at Google に収録）
  • 実質的な契約は公式APIではなく、実際に観測される挙動全体

17. Gallの法則 (Gall's Law)

動作する複雑なシステムは、必ず動作する単純なシステムから進化した結果である

  • 最初から複雑なシステムを設計すると、検証されていない未知の変数が多すぎて失敗確率が高い
  • MVP(Minimum Viable Product) アプローチの理論的根拠
  • Facebookが2004年にHarvardの学生向けの単純なプロフィールシステムとして始まり、段階的に拡張した事例
  • マイクロサービス移行でも、モノリスから始めて段階的に分離するほうが有利
  • John Gallが1975年の著書 Systemantics で提示（30社の出版社に断られた後に出版されたカルト的名著）

18. 漏れる抽象化の法則 (The Law of Leaky Abstractions)

自明でない(non-trivial)あらゆる抽象化は、ある程度漏れを生じる

  • ORMはSQLを隠すが、性能問題が発生すると結局は生成されるクエリを確認しなければならない状況が代表例
  • Java/Pythonのガベージコレクションも抽象化だが、GC停止のような内部挙動が性能に影響する
  • 抽象化自体が悪いのではなく、抽象化が破れたときに備えるべきだという教訓
  • Joel Spolskyが2002年のブログ記事で、TCPや仮想メモリなどの事例とともに紹介
  • George Boxの「すべてのモデルは間違っているが、一部は有用である」とも文脈的に通じる

19. Teslerの法則 / 複雑性保存の法則 (Tesler's Law)

すべてのアプリケーションには取り除けない固有の複雑性があり、それは移動させることはできても、除去することはできない

  • 核心的な問い: 複雑性を誰が負担するのか（ユーザー vs システム）
  • Calendlyは日程調整の複雑性をシステムが吸収し、メールスレッドはそれをユーザーに転嫁するという違いがある
  • 良い設計は、複雑性をユーザー体験からシステム内部へ移す
  • Larry TeslerがApple Lisaおよび初期GUIの作業中に1980年代に定式化

20. CAP定理 (CAP Theorem)

分散システムは一貫性(C)、可用性(A)、分断耐性(P)のうち二つしか保証できない

  • ネットワーク分断は現実には避けられないため、実質的な選択は一貫性 vs 可用性
  • CPシステム（例: MongoDB）: 分断発生時に書き込みをブロックし、すべてのレプリカの同期を維持
  • APシステム（例: Cassandra, DNS）: 分断中でもリクエストへの応答を維持し、レプリカ間の一時的不整合を許容
  • Eric Brewerが2000年にWebサービスの文脈で提唱し、Gilbert & Lynchが2002年に正式に証明

21. セカンドシステム効果 (Second-System Effect)

小さく成功したシステムの次には、過剰設計された肥大な後継システムが続く傾向がある

  • 最初のシステムの成功で自信を得て、二つ目のシステムにあらゆるアイデアを注ぎ込むパターン
  • 機能過多(feature creep)と過度な一般化(over-generalization)が主な原因
  • Frederick Brooksが The Mythical Man-Month で指摘

22. 分散コンピューティングの誤謬 (Fallacies of Distributed Computing)

分散システムを初めて設計する人々がしばしば抱く8つの誤った前提

  • 8つの誤謬: (1) ネットワークは信頼できる、(2) レイテンシは0である、(3) 帯域幅は無限である、(4) ネットワークは安全である、(5) トポロジーは変化しない、(6) 管理者は一人である、(7) 転送コストは0である、(8) ネットワークは均一である
  • これらの前提に基づいて設計すると、本番環境で予期しない障害や性能問題が発生する

23. 意図しない結果の法則 (Law of Unintended Consequences)

複雑なシステムを変更するなら、予期しない結果を想定しなければならない

  • システムの一つのコンポーネントを変更すると、予測していなかった場所で副作用が発生する
  • カオスエンジニアリングと包括的なテストの必要性を裏づける原則

24. Zawinskiの法則 (Zawinski's Law)

あらゆるプログラムは、メールを読めるようになるまで拡張を試みる

  • ソフトウェアが成功すると、ますます多くの機能を追加しようとする機能肥大化(feature bloat)現象を風刺
  • Jamie Zawinski（Netscape初期の開発者）が観察
  • 単純なツールが時間の経過とともに万能プラットフォームになろうとする傾向への警告

品質(Quality)

25. ボーイスカウト・ルール (The Boy Scout Rule)

コードは見つけたときよりも良い状態で残さなければならない

  • 大規模なリファクタリングではなく、継続的で段階的な改善が核心
  • 分かりにくい関数名の修正、重複コードの削除、欠けているテストの追加など、毎回小さな改善を実践
  • Robert C. Martin（Uncle Bob）が Clean Code（2008）でソフトウェア開発に適用
  • Googleエンジニアの原則「If you touch it, you own it」— コードを修正したら、その品質への責任も引き受ける
  • このルールを実践すれば、割れ窓効果(Broken Windows)を防ぎ、技術的負債の蓄積を抑えられる

26. Murphyの法則 (Murphy's Law)

悪くなりうるものは、必ず悪くなる

  • 防御的プログラミング、例外処理、障害に備えた設計の根拠
  • ソフトウェアでは「起こりうるエラーは必ず起こる」という姿勢で、エラーハンドリングとフォールバックを設計すべき

27. Postelの法則 / 堅牢性の原則 (Postel's Law)

自分が行うことには保守的に、他者から受け取るものには寛容に

  • API設計では、出力は厳密に仕様に従いつつ、入力はさまざまな形式を柔軟に受け入れるという原則
  • Jon PostelがTCP/IPプロトコル設計時に定めた堅牢性の原則(Robustness Principle)
  • システム間の相互運用性を高める実践的なガイドライン

28. 割れ窓理論 (Broken Windows Theory)

悪い設計、誤った判断、低品質なコードを放置してはならない

  • 一つの「割れ窓」（悪いコード）が放置されると、さらなる品質低下を引き起こす
  • コードベースにTODOコメント、デッドコード、未解決の警告が積み重なると、新しいコードも低い水準で書かれる傾向がある
  • 発見したらすぐに、小さな問題でも修正する文化が重要

29. 技術的負債 (Technical Debt)

ソフトウェア開発の速度を低下させるあらゆる要素

  • Ward Cunninghamが1992年のOOPSLAで金融メタファーとして初めて使用: コード上の近道を選ぶのは未来から時間を借りること
  • 元本（修正コスト） + 利息（汚れたコードによる継続的な生産性低下）
  • 意図的な技術的負債は時に合理的（市場投入のタイミング、プロトタイピング）だが、返済計画が必須
  • 自動テストの省略が代表例: リリースは成功しても、その後の変更のたびに予想外のバグが発生
  • 解決方法: リファクタリング、欠けているテストの追加、設計改善

30. Linusの法則 (Linus's Law)

十分な数のレビューアがいれば、すべてのバグは容易に見つかる

  • オープンソース開発の核心原理: 多数の目でコードをレビューすれば、バグは些細な問題になる
  • Eric Raymondが The Cathedral and the Bazaar でLinus Torvaldsの名前にちなんで命名
  • コードレビュー文化の重要性を裏づける

31. Kernighanの法則 (Kernighan's Law)

デバッグは、コードを最初に書くことより二倍難しい

  • したがって、できるだけ賢くコードを書くと、デバッグ時には十分に賢くいられなくなる
  • 可読性の高いシンプルなコードを書くべき理由
  • Brian Kernighanが The Elements of Programming Style で提示

32. テスティングピラミッド (Testing Pyramid)

> プロジェクトは高速な単体テストを多く、統合テストは少なく、UIテストはごく少数だけ持つべきだ

  • 単体テスト（下段）: 高速で低コスト、最も多く作成する
  • 統合テスト（中段）: コンポーネント間の相互作用を検証
  • UI/E2Eテスト（上段）: 遅く壊れやすいため最小限にする
  • Mike Cohnが Succeeding with Agile で紹介したテスト戦略モデル

33. 殺虫剤のパラドックス (Pesticide Paradox)

> 同じテストを繰り返し実行すると、時間の経過とともに効果が低下する

  • 既存のテストで捕捉できるバグはすでに取り尽くしているため、新しいテストケースを継続的に追加する必要がある
  • テストセットを定期的に見直し、更新することが不可欠

34. Lehmanのソフトウェア進化の法則 (Lehman's Laws of Software Evolution)

> 現実世界を反映するソフトウェアは必ず進化しなければならず、その進化には予測可能な限界が存在する

  • E-type（現実世界を反映する）ソフトウェアは、使われ続けるために継続的な変更が避けられない
  • 変更のたびに 複雑性が増加 し、これを積極的に管理しなければ品質が低下する

35. Sturgeonの法則 (Sturgeon's Law)

> あらゆるものの90%は役に立たない

  • Theodore SturgeonがSF文学批評への応答として提示
  • ソフトウェアにも当てはまる: コード、ツール、フレームワークの大半の中で 本当に優れているものは少数
  • 品質に対する高い基準を維持し、価値ある10%に集中する姿勢が必要

スケール (Scale)

36. Amdahlの法則 (Amdahl's Law)

> 並列化による速度向上は、並列化できない作業の割合によって制限される

  • プログラムの5%が逐次処理なら、どれだけ多くのプロセッサを投入しても理論上の 最大速度向上は20倍
  • 並列化の限界を認識し、逐次的なボトルネック区間を減らすほうが効果的
  • Gene Amdahlが1967年に提唱

37. Gustafsonの法則 (Gustafson's Law)

> 問題規模を大きくすることで、並列処理で大幅な速度向上を達成できる

  • Amdahlの法則に対する 補完的な視点: 固定された問題ではなくスケール可能な問題では、プロセッサの追加が効果的
  • ビッグデータ処理、科学シミュレーションなどでは、より多くのリソースで より大きな問題 を解ける

38. Metcalfeの法則 (Metcalfe's Law)

> ネットワークの価値はユーザー数の二乗に比例する

  • ユーザーが10人なら価値は100単位、100人なら10,000単位へと増加
  • ソーシャルネットワーク、メッセンジャー、マーケットプレイスなど ネットワーク効果 の理論的基盤
  • Robert Metcalfeがイーサネット技術の価値を説明するために提示

設計 (Design)

39. DRY原則 (Don't Repeat Yourself)

> すべての知識は、単一で明確かつ権威ある1つの表現だけを持つべきである

  • コードの重複だけでなく、知識、ロジック、データの重複も含む
  • 重複は変更時に複数箇所を同時に修正する必要があるため、バグや不整合の原因になる
  • Andy HuntとDave Thomasが The Pragmatic Programmer で体系化

40. KISS原則 (Keep It Simple, Stupid)

> 設計とシステムは可能な限りシンプルであるべきだ

  • 複雑性は理解、保守、デバッグのコストを増大させる
  • シンプルな解決策 がほとんどの場合でより効果的で、欠陥の可能性も低い
  • 1960年代に米海軍が提示した設計原則に由来

41. SOLID原則 (SOLID Principles)

> ソフトウェア設計を改善する5つの中核的ガイドライン

  • S — 単一責任の原則 (Single Responsibility): クラスは1つの理由でのみ変更されるべき
  • O — オープン・クローズドの原則 (Open-Closed): 拡張には開かれ、修正には閉じているべき
  • L — リスコフの置換原則: サブタイプはスーパータイプを置き換え可能であるべき
  • I — インターフェース分離の原則: クライアントは使わないインターフェースに依存すべきではない
  • D — 依存性逆転の原則: 上位モジュールは下位モジュールに依存せず、抽象に依存する
  • Robert C. Martinが体系化し、Michael FeathersがSOLIDという略語を命名

42. デメテルの法則 (Law of Demeter)

> オブジェクトは直接の友人とのみ相互作用すべきであり、見知らぬオブジェクトと直接やり取りするのは避けるべきだ

  • a.getB().getC().doSomething() のような チェーン呼び出しを避けるべきという原則
  • 結合度を下げ、カプセル化を強化して変更の影響範囲を狭める
  • 「最小知識の原則」とも呼ばれる

43. 最小驚愕の原則 (Principle of Least Astonishment)

> ソフトウェアやインターフェースは、ユーザーや他の開発者をできるだけ驚かせない方法で動作すべきだ

  • 関数、API、UIは名前や慣習において 予測可能な振る舞い をすべき
  • delete() 関数が実際にはアーカイブするだけなら驚きを生み、設計上の欠陥となる
  • 直感的でない動作はバグやユーザーのミスを招く

44. YAGNI (You Aren't Gonna Need It)

> 必要になるまでは機能を追加するな

  • 1990年代後半にRon Jeffriesが提示したExtreme Programming (XP) の中核原則
  • 「将来必要になるかもしれない」という理由でコードを書くと、過剰設計 と保守負担が生じる
  • リファクタリングへの 自信（十分なテストカバレッジ、CI）があってこそYAGNIを実践できる
  • 現時点でJSONエクスポートだけが必要ならJSONだけ実装し、XML/YAMLなどは要求されたときに追加する

意思決定 (Decisions)

45. ダニング＝クルーガー効果 (Dunning-Kruger Effect)

> あることについて知識が少ないほど、かえって自信を持ちやすい傾向がある

  • 初級開発者が複雑なシステムの難しさを過小評価したり、専門家のほうがむしろ自分の知識に謙虚であったりする現象
  • コードレビュー、メンタリング、継続学習を通じて 自己認識の正確さ を高めることが重要

46. Hanlonの剃刀 (Hanlon's Razor)

> 愚かさや不注意で十分説明できることを悪意に帰してはならない

  • 同僚の悪いコードや誤った判断を意図的妨害だと解釈する前に、無知、ミス、時間不足 をまず考慮する
  • チーム内の信頼と建設的なコミュニケーションの基盤

47. Occamの剃刀 (Occam's Razor)

> 最もシンプルな説明が最も正確であることが多い

  • デバッグ時には複雑な原因よりも 最もシンプルな可能性 から先に確認する
  • アーキテクチャ設計でも、不必要な抽象化レイヤーを追加する前にシンプルな解決策を優先的に検討する

48. サンクコストの誤謬 (Sunk Cost Fallacy)

> 時間やエネルギーを投資したという理由だけで、不利な選択を続けてしまう現象

  • 6か月間開発した機能が誤った方向だったとしても、投じた時間のために捨てられない 心理
  • 正しい判断は過去の投資ではなく 将来価値 を基準にすべき

49. 地図は領土ではない (The Map Is Not the Territory)

> 現実の表現（モデル）は現実そのものと同一ではない

  • UMLダイアグラム、アーキテクチャ文書、データモデルなどは 現実の近似 にすぎない
  • モデルを盲信せず、実際のシステムの挙動を観察しながらモデルを更新すべき

50. 確証バイアス (Confirmation Bias)

> 既存の信念やアイデアを支持する情報を好む傾向

  • 自分が選んだ技術スタックや設計判断に有利な情報だけを選択的に集めてしまう落とし穴
  • 反対の証拠を積極的に探し、多様な視点を受け入れることがバランスの取れた意思決定の核心

51. Hype Cycle と Amaraの法則 (The Hype Cycle & Amara's Law)

技術の短期的な効果は過大評価し、長期的な影響は過小評価する傾向がある

  • GartnerのHype Cycle: 技術の引き金 → 過度な期待のピーク → 幻滅の谷 → 啓蒙の坂道 → 生産性の安定期
  • 新技術（ブロックチェーン、AI など）を導入する際は、短期的な過熱に流されず、長期的な実用性を評価すべき

52. Lindy効果 (The Lindy Effect)

長く使われてきたものほど、今後も使われ続ける可能性が高い

  • UNIX、SQL、C言語のように数十年にわたって使われてきた技術は、今後も長く生き残る可能性が高い
  • 新しいフレームワークよりも実証済みの技術を選ぶ際の理論的根拠
  • Nassim Nicholas Talebが Antifragile で一般化

53. 第一原理思考 (First Principles Thinking)

複雑な問題を最も基本的な構成要素に分解した後、そこから再構築する思考法

  • 既存の慣行や前提を取り除き、根本的な真実から出発して解決策を導き出す
  • Elon MuskがSpaceXのロケットコスト削減に適用した事例で有名
  • 複雑なシステムを設計する際は、「もともとみんなそうしているから」という思考を警戒する

54. 逆転思考 (Inversion)

反対の結果を想定し、逆向きに推論して問題を解決する方法

  • 「どうすれば成功できるか」ではなく、「どうすれば失敗するか」 を先に考えてリスク要因を特定する
  • 障害モード分析（Failure Mode Analysis）とプレモーテム（Pre-mortem）の理論的根拠
  • Charlie Mungerがよく活用するメンタルモデル

55. パレートの原則 / 80/20の法則 (Pareto Principle)

問題の80%は原因の20%から発生する

  • 全体のバグの80%がコードの 20%に集中 する傾向がある
  • 最も影響力の大きい20%にリソースを集中することが、効率的な資源配分戦略
  • Vilfredo Paretoがイタリアの土地所有分布で観察した原理に由来

56. Cunninghamの法則 (Cunningham's Law)

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

  • 人は質問に答えることよりも、誤った情報を訂正することに より積極的に参加する
  • Wikiの発明者であるWard Cunninghamの名を冠した法則だが、実際にこの名前を付けたのはSteven McGeady
  • オープンソースコミュニティで、ドキュメント化や知識共有に活用できる洞察

関連記事

  • UXの法則
    1 ポイント · 1件のコメント · 43 분 전

2件のコメント

 
choam2426 2 일 전

vibe codingはその場では良いのですが、結局はツケが回ってくる気がします…
 
GN⁺ 8 일 전
Hacker Newsの意見

  • 私は「早すぎる最適化は諸悪の根源」という言葉が特に嫌いだ。この文は1974年の文脈で出たもので、今とは前提が違う。当時の最適化はアセンブリやサイクル計算に近かったが、今の性能は主に アーキテクチャ選択 の問題なので、最初から考慮すべきだ。プロファイリングで偶発的な O(n²) のような性能バグを見つけるという助言は今でも有効だが、抽象化コストがボトルネックになった後では、キャッシュや並列性を継ぎ足すだけで、より複雑でより遅いシステムになりがちだ。今では遅すぎる最適化も、早すぎる最適化と同じくらい、あるいはそれ以上に悪いと思う

    • これはプログラミングで最もよく 誤解される文 の一つだと思う。Donald Knuthの原文 を直接読むと、要点は、計測もせず不要な性能改善に力を使うな、ただし性能が核心となる10%の場面は例外だ、ということだ。ところがこれを「何も計測するな」という妙な教義として受け取るケースをよく見る
    • 私が考える本当に 悪い早すぎる最適化 は、重要でもない些細な差に執着することだ。たとえば Java では、後でマルチスレッド文脈に進む可能性もあるので ConcurrentHashMap をよく使うが、ほとんどの状況で性能差は大きくない。なのに「HashMap のほうが速い」という理由で PR が止まり、終わりのない議論になることがある。そんなことより、PostgreSQL のブロッキング呼び出し40回や不要な Web リクエストのように、体感差を生む箇所に集中するほうが正しいと思う。ただしアルゴリズムレベルの早い最適化は十分にありだと考えている
    • 私は「早すぎる最適化」の代わりに 成熟した最適化 しかしないと冗談めかして言う。フレームワークを積み上げる前に、使い方、データアクセスパターン、性能要件を先に考えるのはとても成熟したアプローチだ。大半はサイクル計算まで行く必要はないが、bulk load なのか単件処理なのか、並行性や分散を考える必要があるのかといった判断を初期にしておくと差が大きい。性能は後で考えればよいという陣営は、その後の改善でよく行き詰まる傾向がある
    • 私は去年、リクエストごとに 40ms 余計に食う 抽象化レイヤー を取り除くのに6か月を費やした。プロファイリングで hot path は見つけたが、書き直しなしでは解決できなかった。「あとで最適化しよう」という側は、その「あとで」が実際には 永遠に来ないかもしれない ことをあまり語らない
    • 私は現代のツールなら スケーラブルな設計 を比較的簡単に作れると思う。だから早すぎる最適化とは、すでに十分良い部分をわざわざさらに削る行為であって、最初からひどいコードを書いていいという意味ではない、と理解している

  • 私は Curly's Law が抜けているのが残念だ。変数は 一つの意味 だけを持つべきで、状況によって別のドメインの値を入れたり、二つの役割を同時に担ったりしてはいけない。「床用ワックスでもありデザートのトッピングでもある」ような状態になってはいけない、という比喩がぴったり当てはまる

    • あの「床用ワックスでありデザートのトッピングでもある」という比喩は、そこまで普遍的な法則ではないかもしれないと冗談を言いたい。飲食店の近くで清掃の仕事をしたことがある身としては、酔えると言えば 床用ワックス をトッピングみたいに食べてみようとする人もかなりいそうだと思う
    • 私はこの原則を名前では知らなかったが、身をもって学んだことがある。たとえば x が 0 でなければ y を 0 にするという規則があるなら、x が 0 か知りたいからといって y を迂回シグナル のように見てはいけない。さらに悪いのは、余っているからといって y を別用途に再利用することだ
    • 私は Shellac が実際に床用ワックスであり食品添加物でもあったことを思い出す。今ではもっと良い代替品があるが、昔は特にキャンディで使われていて、今でも管楽器の接着剤としては使われていると認識している
    • 私は Google で使っていた absl::StatusOr がかなり好きだった
    • 私はこういう状況を普通 POSIWID という名前で呼ぶ

  • 私はこういうソフトウェア「法則」を一か所に集めると、互いに 内部矛盾 が多すぎて、結局は自分の主張を正当化してくれる文を一つ選んで使いやすくなるだけだと感じる。本当に難しいのは、いつどの法則を破るべきか、そしてなぜ破るのかを知ることだ

    • 私は Postel's Law と Hyrum's Law の衝突が代表例だと思う。入力を寛大に受け入れると、API の観察可能なあらゆる挙動に誰かが依存するようになり、後で厳格に変えた瞬間、文書化されていなくても互換性破壊になる。だから私の結論は、自分が制御できる内部境界では厳格に受け取り、クライアントのアップグレードを強制できない外部境界でだけ寛大にする、というやり方だ。ただ現実には、その境界を見分けるのが一番難しい
    • 私はこういう矛盾の代表例として DRY をよく挙げる。似た関数を二つ書かないようにしようとして、概念的複雑さを空の彼方まで押し上げるケースを特によく見てきた
    • 私はかなり長く働いてきた SWE として、今でも KISS と YAGNI だけでとてつもない効用を得ている。ソフトウェアエンジニアリングの多くが過剰設計だと感じるし、正直このサイトもそうだと思う。他の工学分野では資材費や人件費が目に見えるので、こういう過剰は長く持ちこたえられない
    • 私は Amazon の Leadership Principles も似たようなものだと感じた。たいていはもっともらしい指針だが、実際の議論では、どの原則を最ももっともらしく 武器化 して自分の主張に貼り付けられるかの争いになりがちだった。必ずしも悪いことばかりではないかもしれないとも思う
    • 私は形式的な IT 法則戦争より、Dan North の CUPID のような代替案のほうが好きだ。joyful coding のための属性 という点で、SOLID より実用的に感じる

  • 私は2026年版のソフトウェア工学の法則として、あらゆる Web サイトが Claude Opus で vibe coding されるだろうと冗談を言いたい。その結果、背景色は Anthropic に似たクリームトーンになり、フォントと太さはデザイン初心者がたった今タイポグラフィを覚えたかのように過剰に混ぜられ、カード UI があふれ、カードの片側だけに丸いカラー境界線が入るといったパターンが繰り返されそうだ

    • 私はそのサイトを vibe coding した人が本も vibe coding した可能性が高いと見て、すぐにパスしたくなる。しかもこの人のコーディング履歴を調べるとチートシートやロードマップ中心で、本の内容にもほとんど信頼が持てない
    • ドメインもきっと 長いタイトルそのまま .com が付く形になるだろうと予想する

  • 私は Boyd's Law of Iteration も入れるべきだと思う。複雑性を扱うときには、深い分析より 素早い反復 のほうが良い結果を生むことが多いという話で、Boyd が OODA loop を作った人物だと考えるとさらに印象的だ

    • 私はこの法則が本当に好きで、もっと多くの人に理解してほしい。管理やビジネスの側は事前計画を求めるが、ソフトウェアでは最初からすべての問題を予測することはできない。最初から硬直した構造を設計して自分を閉じ込めるより、柔軟なアーキテクチャ の上でリファクタリングしながら問題を解くほうが効果的だと思う
    • 私は一般に、慎重すぎる開発より 反復的開発 のほうが優れていると思う。戦闘機の操縦桿の事例もとても繊細で良い例だった。この話を見て、大学時代にビルド時間が毎回10分かかっていた苦しいプロジェクトを思い出した。実装の代わりに提供された mock コンポーネントに差し替えるべきだったのに、それに気づくのが遅くて締切前に終えられなかった。それ以来、私はいつもまずビルド時間を減らす方法を探すようになった
    • 私は Boyd の法則を極端に押し進めすぎると、1週間スプリント 以下のような形に流れがちだと感じる

  • 削除されたコメントの中に、この記事に対する 最高のメタ法則 があったと思う。「あらゆるソフトウェア工学の法則は即座に誤解され、原著者が仰天する形で無批判に適用される」という内容だったが、核心の文脈が抜けた LLM の振る舞いを見ると、なぜそうなるのかがよりよく分かる気がする。結局、何十年分もの知恵と経験を 一行の名言 に圧縮することには限界がある

  • 私は「『ソフトウェア工学の法則』一覧サイト」を丸ごと vibe coding するくらいなら、そもそも Wikipedia ページを作らなかったのは何の法則違反なんだと聞きたい

    • 「Wikipedia ページを作れ」という提案も少し妙に聞こえる。2026年の Wikipedia は、実質的に Wikipedia 文化圏 の深い専門家でないと新規ページを作りにくい場所のように感じる。ウィキの達人たちは137個のガイドラインに従えば誰でも作れると言うが、現実には管理者に削除されやすいというシニカルな見方がある
    • その法則名は Slop's Law にしたい。雑に作れるなら、結局雑に作られるという意味だ
    • 2026年版の Sturgeon's Law として、「あらゆるものの99%は crap または slop」だと要約したい

  • 私はこういう内容が就職要件になるくらいの 基本教養 であってほしいと思う。誰もが知っておくべき話のように感じる

  • 私はソフトウェア専用の法則ではなくても Chesterton's Fence をインターンや新入社員に最初に教えることが多い

    • 一覧にある Law of Unintended Consequences も同じ現象を説明していると思う。それでも個人的には、その法則より柵の話のほうが好きだ
    • 私はこの原則を自分の中核原則の一つにしていて、一言でいえば 考えてから行動する ことだと思っている

  • 私は Tesler の複雑性保存則 は、文そのものだけで直ちに洞察を与えると感じる。すべてのアプリケーションには、取り除くことはできず移動させることしかできない固有の複雑さがある、という話だ。ただし説明に入ると、結局はユーザーをあまり苦しめるなというありふれた助言に縮小してしまうようで、興味が少し薄れる。ユーザーは必要なレベルの複雑さは結局持たなければならず、やみくもに減らすと柔軟性のないおもちゃになりがちだ。だから私は、リファクタリングである部分を単純化すると別の部分がもっと複雑になるかもしれない、という点を覚えておくほうが有用だと思う