Category: 法則
Type: ソフトウェア性能と複雑性のヒューリスティック
Origin: ニクラウス・ワースに帰される（1990年代中盤）
Also known as: ソフトウェア膨張の原理
Type: ソフトウェア性能と複雑性のヒューリスティック
Origin: ニクラウス・ワースに帰される（1990年代中盤）
Also known as: ソフトウェア膨張の原理
先に答えると — ワースの法則（Wirth’s Law）は、ソフトウェアが遅くなる速度が、ハードウェアが速くなる速度を上回りやすいという警告です。問題はCPUだけでなく、複雑性を許容する組織運用です。実務では、性能予算・メモリ予算・依存関係上限を製品要件として固定することが有効です。
ワースの法則（Wirth’s Law）とは
ワースの法則（Wirth’s Law）は、ハード進化がそのまま体感速度に変わるとは限らない理由を説明します。ソフトウェアが機能・抽象・統合で重くなると、得られた性能余白は利用者に届く前に消費されます。速くなる余地は、設計しなければ積み増されず、管理しなければ消える。ムーアの法則（ハード能力の伸長）、ブルックスの法則（協調コスト）、コンウェイの法則（組織構造とシステム構造の対応）と組み合わせると、遅化の組織的原因が見えます。ホフスタッターの法則が示す見積もり甘さとも相性が高いです。
ワースの法則を3つの深さで理解する
- 初心者: 新しい端末でもアプリが重ければ体感は速くならない。
- 実践者: 性能予算を明示し、超過機能は価値根拠なしに採用しない。
- 上級者: アーキテクチャ、評価制度、リリース門番を連動させ、複雑性の増加率を容量増加率より低く保つ。
起源
この表現は、言語設計と簡潔なソフトウェア実践を重視した計算機科学者 ニクラウス・ワース に広く帰されています。1990年代、ハードが大きく進歩する一方、日常ソフトの体感改善が追いつかない現象を説明する文脈で広まりました。 定着した理由は、技術よりも組織の再現パターンを言い当てたからです。多くの現場では、可視的な機能追加は評価される一方、性能劣化は利用者と将来保守へ先送りされがちでした。要点
ワースの法則は「速度問題」を「意思決定問題」に戻すための枠組みです。応用場面
「遅くなってから直す」運用をやめるための実装ポイントです。Webプロダクト
CIでバンドルサイズと操作遅延を監視し、閾値超過のマージを止めます。
モバイルアプリ
上位機だけでなく中位機のコールドスタートとメモリ圧を主要評価軸にします。
バックエンド
依存の増殖を抑え、テールレイテンシを継続監視してリリースごとの劣化を防ぎます。
開発マネジメント
性能回退をロードマップコストに計上し、「ハードが吸収する」という発想を排除します。
事例
公開Web計測の長期データでは、ページ複雑性と転送サイズの増加が続き、JavaScriptとメディアの実行・通信コストが体感速度を圧迫してきました。多くのチームで、CPUやネットワークの改善分が機能追加由来の負荷増に相殺され、とくに中位端末で影響が強く出ます。実務上は Core Web Vitals（LCP、INP など）を継続監視すると、機能集中リリース後に回退が起きやすいことが確認されます。ワースの法則の含意は明確で、性能は自然に良くならず、守られたときだけ良くなります。限界と失敗パターン
ワースの法則は傾向であり、抽象化そのものを否定するものではありません。 限界1: ツール進化で逆転できるコンパイラ最適化、ランタイム改善、構造簡素化により、遅化傾向は十分反転可能です。 限界2: 一部の性能コストは正当化できる
セキュリティ、アクセシビリティ、正確性向上は計算コスト増でも全体価値を高めます。 よくある誤用: 近代化を一律に拒否し、価値と遅延の明示的な比較を怠ること。
よくある誤解
誤解を減らすと、速度重視と価値提供を両立できます。誤解: 近代的フレームワークは全部悪い
誤解: 近代的フレームワークは全部悪い
実際: 問題は道具ではなく、オーバーヘッド管理をしない運用です。
誤解: ハード更新は無意味
誤解: ハード更新は無意味
実際: 効果は大きいが、管理しなければソフト側で食い潰されます。
誤解: 性能は最後に最適化すればいい
誤解: 性能は最後に最適化すればいい
実際: 長期性能の大半は初期設計と予算規律で決まります。
関連概念
次の概念を併用すると、性能ガバナンスを制度化しやすくなります。ムーアの法則
ハード能力の伸びは機会であり、体感速度の保証ではない。
コンウェイの法則
組織構造はシステム構造に写り、性能負債の形も決める。
ブルックスの法則
調整コストの増加が複雑性を高め、品質速度を下げる要因になる。