meta-structured-problem

構造化された問題解決

フレームワーク

IRON LAW: MECE or It's Not Structured

Every decomposition must be MECE:
- Mutually Exclusive: No overlap between categories
- Collectively Exhaustive: No gaps — all possibilities covered

"Revenue = New customers + Existing customers" is MECE ✓
"Revenue = Online + Enterprise + Growth" is NOT MECE ✗ (overlapping)

主なツール

イシューツリー：問いをサブクエスチョンに分解し、各階層でMECEにします

"Why is profit declining?"
├── Revenue declining?
│   ├── Volume down?
│   │   ├── New customer acquisition down?
│   │   └── Existing customer churn up?
│   └── Price down?
│       ├── Discounting increased?
│       └── Mix shift to lower-priced products?
└── Costs increasing?
    ├── COGS up?
    └── OpEx up?

仮説主導のアプローチ：すべてを調べるのではなく、仮説を立てて検証します

1. 初期仮説を立てます（「解約率が上がったため、利益が減少した」）
2. 仮説を立証または反証する証拠を特定します
3. その証拠を収集します
4. 仮説を修正するか、棄却します
5. これを繰り返します

ピラミッド原則（Barbara Minto）：トップダウンでコミュニケーションを構成します

1. 答えから始める：分析ではなく、提案から始めます
2. 根拠となる論点をまとめる：3～5個の論点を、MECEにまとめます
3. 論理的に並べる：論拠の強さ、時系列、または構造に沿って並べます
4. 求められた場合にのみ詳細を示す：各階層で、より詳しく知りたい人向けに詳細を提示します

80/20の法則：答えの80％を導く分析の20％に集中します。イシューツリーの二次的な分岐を分析しすぎないようにします。

問題解決のプロセス

1. 問題を定義する：「クライアントの利益は前年比で15％減少しました。原因は何で、何をすべきでしょうか？」
2. イシューツリーで構造化する：考えられる原因をMECEに分解します
3. 分岐に優先順位を付ける：どの分岐に答えが含まれている可能性が高いでしょうか？（80/20）
4. 仮説を立てる：「主な原因は……だと考えます」
5. 証拠を収集する：データで各仮説を検証します
6. 調査結果を統合する：証拠から何がわかるでしょうか？
7. 提案する：ピラミッド原則に沿って提示します（最初に答えを示す）

出力形式

# Structured Analysis: {Problem}

## Problem Statement
{One sentence, specific and measurable}

## Issue Tree
{MECE decomposition — text or visual}

## Hypothesis
{Initial hypothesis with rationale}

## Evidence
| Branch | Hypothesis | Evidence | Verdict |
|--------|-----------|---------|---------|
| {branch} | {sub-hypothesis} | {data found} | Confirmed/Rejected |

## Synthesis (Pyramid Structure)
**Recommendation**: {answer first}

**Supporting Arguments**:
1. {argument 1 with evidence}
2. {argument 2 with evidence}
3. {argument 3 with evidence}

## Next Steps
1. {action item}

例

適切な適用例

シナリオ：「フードデリバリーアプリの市場シェアが低下しているのはなぜでしょうか？」

イシューツリー（MECE）：

Market share declining
├── Our growth slowing?
│   ├── New user acquisition down?
│   │   ├── Marketing spend reduced?
│   │   └── Conversion rate dropped?
│   └── Existing user activity down?
│       ├── Order frequency declining?
│       └── Users churning?
└── Competitors growing faster?
    ├── New entrant capturing share?
    └── Existing competitor accelerating?

仮説：「配達料の値上げ後に注文頻度が下がったため、既存ユーザーの利用が減少している。」 証拠：値上げ後の1か月間で、注文頻度が22％低下しました。✓

ピラミッド：「注文頻度の高いユーザーを対象に、配達料の値上げを撤回します。値上げ後に注文頻度が22％低下しており、失われた注文の60％は週3回以上注文していたユーザーによるものです。頻繁に利用するユーザーの配達料を免除するロイヤルティプランを導入すれば、月額NT$Xの費用で、失われたシェアの推定15％を取り戻せます。」

不適切な適用例

• イシューツリー：「収益の問題：オンライン、マーケティング、カスタマーサービス」→ MECEではありません（カテゴリが重複しており、網羅的でもありません）。鉄則に反しています。

注意点

• 実際にMECEにするのは難しい：完全なMECEは理想です。できる限り近づけ、カテゴリの境界が曖昧な箇所を記録します。「3日かけた完璧なMECE」より「十分なMECE」のほうが優れています。
• 仮説主導 ≠ 確証バイアス：仮説は調査を導くための出発点であり、擁護すべき結論ではありません。証拠が仮説と矛盾する場合は、仮説を変更します。
• ピラミッド原則は直感に反するように感じられます：人は自然と、問題→分析→結論の順に話したくなります。しかし、聞き手が求めているのは、まず答え、その後に根拠となる証拠です。提案から始めます。
• 構造化 ≠ 時間がかかる：問題の構造化に30分かければ、焦点の定まらない分析に何時間も費やさずに済みます。構造化こそがスピードにつながります。
• いつやめるべきかを見極める：分析による効果は次第に小さくなります。自信を持って提案するのに十分な証拠が得られたら、分析をやめて提案します。

参考資料

• 問題の種類別のイシューツリーのテンプレートについては、references/issue-tree-templates.mdを参照してください
• ピラミッド原則に基づく文章作成ガイドについては、references/pyramid-principle.mdを参照してください