thinking-fermi-estimation

フェルミ推定

概要

物理学者エンリコ・フェルミにちなんで名付けられたフェルミ推定は、直接測定しなければ分からないように思える数量を、妥当な範囲で推定する技術です。推定できる要素に質問を分解してから掛け合わせることで、驚くほど正確な桁数レベルの結果が得られることがよくあります。

基本原則： 未知のものを、既知の（または推定可能な）要素に分解します。誤差が相殺されるため、大まかな推定値でも妥当な精度にまとまります。

トリガーカード

測定したり調べたりできない数値が必要で、桁数レベルの精度で十分な場合：

1. 分解する： 数量 = 要素₁ × 要素₂ × ... × 要素ₙ（構成要素別、率×時間別、または母集団×割合別）。
2. 各要素を推定する： 単一の値ではなく範囲で推定し、桁数レベルでは幾何平均を使い、有効数字1桁に丸めます。
3. 掛け合わせて妥当性を確認する： 桁数は妥当ですか？ 10倍の誤差があれば判断は変わりますか？
4. 報告する： 「約X、誤差は3〜5倍の範囲」—決して見せかけの精度を示さないでください。

数値を検索できる場合（COUNT(*)、料金ページ、プロファイリングなど）は、代わりにそうしてください。実際の値があるのに作り上げた推定値を使うのは、明らかに悪い選択です。

使用する場面

• キャパシティプランニング（「ストレージはどれくらい必要ですか？」）
• コスト見積もり（「このインフラにはいくらかかりますか？」）
• 市場規模の推定（「見込みユーザーは何人いますか？」）
• 実現可能性の評価（「そもそも実現可能ですか？」）
• 妥当性の確認（「この数値は妥当ですか？」）
• 面接の質問（「シカゴにはピアノ調律師が何人いますか？」）
• 迅速な優先順位付け（「これに取り組む価値はありますか？」）

判断フロー：

Need a number you don't have? → Can you measure OR look it up cheaply? → yes → DO THAT (don't Fermi it)
                                                                       ↘ no → Will an order-of-magnitude answer suffice? → yes → FERMI ESTIMATE
                                                                                                                          ↘ no → you need real data, go get it

使用しない場面

• 数値を簡単に検索または測定できる場合。 COUNT(*) で数えられるテーブルのサイズ、プロファイリングできるレイテンシ、ls で確認できるファイルサイズ、料金ページにある価格、あるいはクエリや検索を1回すれば分かる事実をフェルミ推定しないでください。実際の値が分かるのに作り上げた推定値を使うのは、明らかに悪い選択です。誤差と誤った確信を招くだけです。調べてください。
• 桁数ではなく精度が必要な場合。 フェルミ推定で得られるのは「約4 TB、誤差は3〜5倍の範囲」です。3.8と4.2のどちらかで判断が変わるなら、推定では対応できません。実際の数値を調べてください。
• 要素同士に相関がある場合や、基準率をでっち上げることになる場合。 分解が根拠のない推測の積み重ねにすぎないなら、それは推定のふりをしたものです。実際の根拠を1つ見つけるか、全体が大まかな推測であることを明示してください。
• 妥当な範囲内で判断が変わらない場合。 「1 GBから1 TBのどこか」で行動が変わらないなら、推定を省略して実行に移してください。

フェルミ推定のプロセス

ステップ1：推定対象を明確にする

数量を正確に定義します：

Vague: "How big is the market?"
Precise: "How many SaaS companies with 50-500 employees in the US
         would pay $1000/month for our product?"

ステップ2：推定可能な要素に分解する

推定できる要素に分けます：

Storage needs for user data:
= (Number of users)
  × (Data per user per day)
  × (Days of retention)
  × (Overhead factor)

分解の方法：

方法	例
構成要素別	合計 = 各要素の合計
率 × 時間別	合計 = 率 × 期間
母集団 × 割合別	対象 = 基準となる母集団 × 割合
類推 × 補正別	新しい値 ≈ 類似する値 × 比率

ステップ3：各要素を推定する

各要素を次の情報に基づいて推定します：

情報源	例
既知のデータ	「DAU は10,000です」
業界のベンチマーク	「SaaS の平均解約率は5％です」
物理的な制約	「人間は1日に約50回の判断を下せます」
論理的な範囲	「最低1、最大100万です」
個人的な経験	「1,000 req/s を処理するシステムを見たことがあります」

推定する際のポイント：

• 単一の値ではなく範囲を使います：「10,000〜50,000」
• 桁数レベルの推定には幾何平均を優先します：√(10,000 × 50,000) = 22,360
• 有効数字1桁に丸めます：約20,000

ステップ4：要素を組み合わせる

要素を掛け合わせる（または足し合わせる）：

Storage = 50,000 users × 10 KB/user/day × 365 days × 1.5 overhead
        = 50,000 × 10,000 × 365 × 1.5 bytes
        = 274 billion bytes
        ≈ 270 GB/year

ステップ5：妥当性を確認する

妥当かどうかを検証します：

• 桁数は妥当ですか？
• 物理的に実現可能ですか？
• 既知のデータポイントと一致しますか？
• 10倍の誤差があれば判断は変わりますか？
• 実際に検索できる要素はありませんか？ ある場合は、推定値を実際の値に置き換えてください。測定した要素を置き換えるたびに、誤差の幅が小さくなります。

ステップ 6：確信度と影響を示す

Estimate: ~270 GB/year
Confidence: Within 3-5x (80-1,500 GB)
Implication: Standard database tier sufficient; no special infrastructure needed

フェルミ推定テンプレート

# Fermi Estimate: [Question]

## Question (Precise)
[Exactly what we're estimating]

## Decomposition
[Quantity] = [Factor 1] × [Factor 2] × ... × [Factor N]

## Factor Estimates

### Factor 1: [Name]
- Estimate: [Value]
- Source/Reasoning: [Why this number]
- Confidence: High / Medium / Low

### Factor 2: [Name]
- Estimate: [Value]
- Source/Reasoning: [Why this number]
- Confidence: High / Medium / Low

[Continue for all factors...]

## Calculation
[Show the math]

## Result
- Point estimate: [Value]
- Range: [Low] to [High] (representing Xx uncertainty)

## Sanity Check
- Physical plausibility: [Check]
- Comparison to known data: [Check]
- Order of magnitude reasonable: [Check]

## Implications
[What does this estimate mean for the decision?]

例 1：データストレージのニーズ

質問： 新機能には、1 年目にどれくらいのストレージが必要ですか？

## Decomposition
Storage = Users × Events/User/Day × Event Size × Days × Replication

## Factor Estimates

### Users (DAU)
- Estimate: 100,000 (current) growing to 200,000 (end of year)
- Average over year: ~150,000
- Confidence: High (we have current data)

### Events per User per Day
- Estimate: 50 events (based on current feature usage patterns)
- Confidence: Medium (new feature might differ)

### Event Size
- Estimate: 500 bytes (JSON with typical payload)
- Confidence: High (we can measure similar events)

### Days in Year
- Estimate: 365
- Confidence: Certain

### Replication Factor
- Estimate: 3x (standard for durability)
- Confidence: High (architectural requirement)

## Calculation
Storage = 150,000 × 50 × 500 × 365 × 3
        = 150,000 × 50 × 500 × 365 × 3
        = 4.1 × 10^12 bytes
        = 4.1 TB

## Result
- Point estimate: ~4 TB
- Range: 1 TB (pessimistic assumptions) to 15 TB (growth beats expectations)

## Sanity Check
- 4 TB for 150K users = ~27 MB/user/year = reasonable
- Similar feature at other company uses "several TB" = consistent
- Standard database can handle 4 TB = feasible

## Implications
- Standard managed database tier sufficient
- No need for sharding or special storage architecture in Year 1
- Budget ~$500/month for storage costs

例 2：API のレート容量

質問： API はブラックフライデーのトラフィックに対応できますか？

## Decomposition
Required RPS = Peak Daily Users × Requests/User/Session × Sessions/Day × Peak Multiplier / Seconds in Peak Hour

## Factor Estimates

### Peak Daily Users
- Estimate: 500,000 (3x normal 170K)
- Source: Last year's Black Friday
- Confidence: Medium

### Requests per Session
- Estimate: 30 API calls (measured)
- Confidence: High

### Sessions per Day
- Estimate: 2 (mobile + desktop)
- Confidence: Medium

### Peak Multiplier
- Estimate: 5x (traffic concentrated in 4-hour window, spiky within that)
- Confidence: Medium

### Seconds in Peak Hour
- Estimate: 3,600
- Confidence: Certain

## Calculation
Required RPS = (500,000 × 30 × 2 × 5) / 3,600
             = 150,000,000 / 3,600
             = 41,667 RPS
             ≈ 40,000 RPS peak

## Result
- Point estimate: 40,000 RPS
- Range: 15,000 to 100,000 RPS

## Sanity Check
- Current capacity: 10,000 RPS
- Gap: 4x capacity needed
- Similar scale companies report 20-50K RPS on peak days = consistent

## Implications
- Need 4x capacity increase
- Auto-scaling must handle 40K+ RPS
- Load test to 60K RPS (1.5x safety margin)

例 3：市場規模

質問： 開発者向けツールの潜在顧客は何人いますか？

## Decomposition
TAM = Software Companies × Avg Developers × Adoption Rate × Price Tolerance

## Factor Estimates

### Software Companies (US)
- Estimate: ~500,000 (SBA data: tech companies)
- Confidence: Medium

### With 10+ Developers (our target)
- Estimate: 10% = 50,000 companies
- Confidence: Low (rough estimate)

### Developers per Target Company
- Estimate: 30 average
- Confidence: Medium

### Adoption Rate (would consider)
- Estimate: 20% (dev tools are crowded)
- Confidence: Low

### Price Point
- Estimate: $50/developer/month
- Confidence: Medium (based on similar tools)

## Calculation
Addressable Users = 50,000 × 30 × 20% = 300,000 developers
Revenue = 300,000 × $50 × 12 = $180M/year TAM

## Result
- TAM: ~$180M/year
- Realistic serviceable market: 5-10% = $10-20M/year

## Sanity Check
- Similar dev tools (Datadog, etc.) have $100M+ revenue = plausible ceiling
- 300K potential users in a niche = reasonable

## Implications
- Market size justifies investment if we can capture 5%+
- Need differentiation in crowded space

よくある分解パターン

キャパシティプランニング

Needed = Users × Usage/User × Factor/Usage × Growth × Safety

コスト見積もり

Cost = Resources × Unit Cost × Duration × Overhead

時間見積もり

Time = Tasks × Time/Task × (1 + Risk Factor)

市場規模の推定

Market = Population × Segment% × Adoption% × Price × Frequency

より良い見積もりを行うためのヒント

複数のアプローチを使う

同じものを異なる方法で見積もります：

Website traffic estimate:
Method 1: Bottom-up from user base
Method 2: Top-down from market share
Method 3: Analogy to similar company

If methods agree within 3x, confidence increases
If they diverge wildly, investigate assumptions

まず上下限を設定する

上限と下限から始めます：

"Definitely more than 1,000, definitely less than 10 million"
"So somewhere in 10,000-1,000,000 range"
"Let me narrow from there..."

相関する誤差に注意する

要因に相関がある場合、誤差は相殺されません：

BAD: Users × Revenue/User (both depend on same growth assumption)
BETTER: Estimate revenue directly, or use independent factors

有効数字は 1 桁にする

過剰な精度を示さないでください：

Calculation: 47,832,519 bytes
Report: ~50 MB (not "47.8 MB")

確認チェックリスト

• 質問を正確に定義した
• 見積もり可能な 3〜6 個の要因に分解した
• 各要因に根拠または出典がある
• 要因同士は比較的独立している
• 計算を示し、確認した
• 結果が現実と照らして妥当か確認した
• 不確実性の範囲を示した
• 意思決定への影響を明確にした

重要な質問

• 「これを、より小さく見積もり可能な要素に分解できるか？」
• 「この値の範囲を絞り込むために、すでに分かっていることは何か？」
• 「上限は？ 下限は？」
• 「この数値は妥当そうか？」
• 「10 倍ずれていたら、意思決定は変わるか？」
• 「別の方法でも見積もって、相互確認できるか？」

フェルミの知恵

シカゴにピアノ調律師が何人いるか尋ねられたとき、フェルミは調べるのではなく、人口、世帯数、ピアノの台数、調律の頻度、調律師の対応能力から推定しました。その推定は、実際の数値から 20％以内だったと言われています。

教訓：自分が思っている以上に、多くのことを知っています。分解し、推定し、組み合わせましょう。誤差は相殺されることが多く、驚くほど真実に近づけます。

「答えが分かるまでは、計算をしてはいけない。」— ジョン・ホイーラー（フェルミの同僚）

意味：まず答えの見当をつけてから、計算して確かめます。