> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# ワースの法則

> ワースの法則は、ソフトウェアの遅化がハードウェアの高速化より速く進みうると警告します。性能予算と複雑性管理を設計段階で扱う重要性を解説します。

<Info>
  **Category**: 法則<br />
  **Type**: ソフトウェア性能と複雑性のヒューリスティック<br />
  **Origin**: ニクラウス・ワースに帰される（1990年代中盤）<br />
  **Also known as**: ソフトウェア膨張の原理
</Info>

<Note>
  **先に答えると** — **ワースの法則**（Wirth's Law）は、ソフトウェアが遅くなる速度が、ハードウェアが速くなる速度を上回りやすいという警告です。問題はCPUだけでなく、複雑性を許容する組織運用です。実務では、性能予算・メモリ予算・依存関係上限を製品要件として固定することが有効です。
</Note>

## ワースの法則（Wirth's Law）とは

**ワースの法則**（Wirth's Law）は、ハード進化がそのまま体感速度に変わるとは限らない理由を説明します。ソフトウェアが機能・抽象・統合で重くなると、得られた性能余白は利用者に届く前に消費されます。

> 速くなる余地は、設計しなければ積み増されず、管理しなければ消える。

[ムーアの法則](/ja/laws/moores-law)（ハード能力の伸長）、[ブルックスの法則](/ja/laws/brookss-law)（協調コスト）、[コンウェイの法則](/ja/laws/conways-law)（組織構造とシステム構造の対応）と組み合わせると、遅化の組織的原因が見えます。[ホフスタッターの法則](/ja/laws/hofstadters-law)が示す見積もり甘さとも相性が高いです。

### ワースの法則を3つの深さで理解する

* **初心者**: 新しい端末でもアプリが重ければ体感は速くならない。
* **実践者**: 性能予算を明示し、超過機能は価値根拠なしに採用しない。
* **上級者**: アーキテクチャ、評価制度、リリース門番を連動させ、複雑性の増加率を容量増加率より低く保つ。

## 起源

この表現は、言語設計と簡潔なソフトウェア実践を重視した計算機科学者 **ニクラウス・ワース** に広く帰されています。1990年代、ハードが大きく進歩する一方、日常ソフトの体感改善が追いつかない現象を説明する文脈で広まりました。

定着した理由は、技術よりも組織の再現パターンを言い当てたからです。多くの現場では、可視的な機能追加は評価される一方、性能劣化は利用者と将来保守へ先送りされがちでした。

## 要点

ワースの法則は「速度問題」を「意思決定問題」に戻すための枠組みです。

<Steps>
  <Step title="複雑性は静かに余白を消費する">
    依存関係、抽象層、統合点が増えるほど、起動・実行・障害時のオーバーヘッドが積み上がります。
  </Step>

  <Step title="既定インセンティブは機能量を優先する">
    速度維持は見えにくく、機能追加は見えやすいため、無意識に前者が犠牲になります。
  </Step>

  <Step title="性能負債は複利で効く">
    毎回の小さな遅化が、数リリース後には大きな体感低下と運用コスト増になります。
  </Step>

  <Step title="予算管理でトレードオフを明文化する">
    性能予算を出荷条件にすれば、速度は願望ではなく意思決定基準になります。
  </Step>
</Steps>

## 応用場面

「遅くなってから直す」運用をやめるための実装ポイントです。

<CardGroup cols={2}>
  <Card title="Webプロダクト" icon="globe">
    CIでバンドルサイズと操作遅延を監視し、閾値超過のマージを止めます。
  </Card>

  <Card title="モバイルアプリ" icon="mobile-screen-button">
    上位機だけでなく中位機のコールドスタートとメモリ圧を主要評価軸にします。
  </Card>

  <Card title="バックエンド" icon="server">
    依存の増殖を抑え、テールレイテンシを継続監視してリリースごとの劣化を防ぎます。
  </Card>

  <Card title="開発マネジメント" icon="users-gear">
    性能回退をロードマップコストに計上し、「ハードが吸収する」という発想を排除します。
  </Card>
</CardGroup>

## 事例

公開Web計測の長期データでは、ページ複雑性と転送サイズの増加が続き、JavaScriptとメディアの実行・通信コストが体感速度を圧迫してきました。多くのチームで、CPUやネットワークの改善分が機能追加由来の負荷増に相殺され、とくに中位端末で影響が強く出ます。実務上は Core Web Vitals（LCP、INP など）を継続監視すると、機能集中リリース後に回退が起きやすいことが確認されます。ワースの法則の含意は明確で、性能は自然に良くならず、守られたときだけ良くなります。

## 限界と失敗パターン

ワースの法則は傾向であり、抽象化そのものを否定するものではありません。

**限界1: ツール進化で逆転できる**\
コンパイラ最適化、ランタイム改善、構造簡素化により、遅化傾向は十分反転可能です。

**限界2: 一部の性能コストは正当化できる**\
セキュリティ、アクセシビリティ、正確性向上は計算コスト増でも全体価値を高めます。

**よくある誤用**: 近代化を一律に拒否し、価値と遅延の明示的な比較を怠ること。

## よくある誤解

誤解を減らすと、速度重視と価値提供を両立できます。

<AccordionGroup>
  <Accordion title="誤解: 近代的フレームワークは全部悪い">
    **実際**: 問題は道具ではなく、オーバーヘッド管理をしない運用です。
  </Accordion>

  <Accordion title="誤解: ハード更新は無意味">
    **実際**: 効果は大きいが、管理しなければソフト側で食い潰されます。
  </Accordion>

  <Accordion title="誤解: 性能は最後に最適化すればいい">
    **実際**: 長期性能の大半は初期設計と予算規律で決まります。
  </Accordion>
</AccordionGroup>

## 関連概念

次の概念を併用すると、性能ガバナンスを制度化しやすくなります。

<CardGroup cols={3}>
  <Card title="ムーアの法則" icon="microchip" href="/ja/laws/moores-law">
    ハード能力の伸びは機会であり、体感速度の保証ではない。
  </Card>

  <Card title="コンウェイの法則" icon="diagram-project" href="/ja/laws/conways-law">
    組織構造はシステム構造に写り、性能負債の形も決める。
  </Card>

  <Card title="ブルックスの法則" icon="people-group" href="/ja/laws/brookss-law">
    調整コストの増加が複雑性を高め、品質速度を下げる要因になる。
  </Card>
</CardGroup>

## 一言で言うと

<Tip>
  ハードがくれる速さの予算を、ソフトの複雑性で使い切らない設計と運用を選べ。
</Tip>