# 方法論の科学的論理：なぜこのレポートは議論に耐えるか

> 🌐 言語：[繁體中文](METHODOLOGY_SCIENTIFIC_LOGIC.md) ｜ [English](METHODOLOGY_SCIENTIFIC_LOGIC_EN.md) ｜ [Deutsch](METHODOLOGY_SCIENTIFIC_LOGIC_DE.md) ｜ [Français](METHODOLOGY_SCIENTIFIC_LOGIC_FR.md) ｜ [Español](METHODOLOGY_SCIENTIFIC_LOGIC_ES.md) ｜ 日本語 ｜ [한국어](METHODOLOGY_SCIENTIFIC_LOGIC_KR.md)
>
> Apache License 2.0 · 著者：Morris Lu · Tiger AI

最終更新：2026-05-15

---

> **この文書が答えるもの**：なぜこの方法論はこのように設計されているのか？なぜ 8 ステージ、5 でも 12 でもなく？なぜデータはこのように流れるのか？なぜケースは Benchmark-grade でなければならないのか？**最終的に**：クライアント / ボード / 規制当局がそれを挑戦するとき、このコンサルティングレポートは何に基づいて立つのか？
>
> **コア主張**：この方法論はコンサルティング経験のコレクションではなく、**クローズドループの科学的管理論理** — すべてのステップが科学的方法の 5 条件を満たす：観測可能、定量化可能、再現可能、反証可能、監査可能。

---

## 1. なぜコンサルティングレポートには「科学的論証力」が必要か

一般的な失敗シナリオ：

| シナリオ | クライアント挑戦 | 典型的なコンサルタント回答 | なぜ失敗するか |
| --- | --- | --- | --- |
| ボード質問 | 「我々が L2 だとどうしてわかる？」 | 「インタビューに基づいて...」 | 主観的；検証不可能 |
| 内部監査 | 「なぜカスタマーサービスがセールスより先？」 | 「我々の経験では...」 | 経験は監査不可能 |
| 規制チェック | 「AI が失敗したら誰が責任？」 | 「ポリシーがある...」 | 監査チェーンのないポリシーはカウントされない |
| コンサルタント切り替え | 「前のファームは L3 と言った；あなたは L2 — どちらが正しい？」 | 「方法が違う」 | 非再現可能 = 非科学的 |

**Tiger AI の設計目標**：あらゆるこのような質問に **検証可能な数字 + 監査可能なエビデンス + 再現可能な手順** が回答として存在する。

---

## 2. 科学的方法の 5 条件 vs. 本方法論

| 科学的条件 | 定義 | 方法論がいかに満たすか |
| --- | --- | --- |
| **1. 観測可能** | 結論は他者が見えるエビデンスに依拠 | Stage 1 録音 + システム inventory + As-Is Swimlanes；各項目にタイムスタンプとソース |
| **2. 定量化可能** | 結論は形容詞ではなく数字に還元可能 | Stage 2 レーダー 0-4 スコアリング；Stage 4 Impact×Effort スコアリング；Stage 5 80/20 impact-surface 数字；Stage 8 value tracking 5 次元 |
| **3. 再現可能** | 異なるコンサルタントが同じ方法で類似結論に到達 | 3 つの Reference Model（APQC / SCOR / Tiger AI L1-L5）は公的標準；40 問インタビューバンク；MECE 規律 |
| **4. 反証可能** | 結論には明示的な反駁条件がある | Stage 6 Stage Gate Criteria が明示的に pass/fail をリスト；チェックリストには観測可能条件；目標未達 = 仮説反証 |
| **5. 監査可能** | プロセスは第三者によって独立検証可能 | Stage 8 Audit Log（LLM コール、権限変更、Skill デプロイ、Reviewer サインオフ完全チェーン）、保持期間定義 |

> **これら 5 条件は装飾ではない**。これら 5 つに反応できないコンサルタント結論はいかなるものも科学的管理ではない — 単なる経験共有。

---

## 3. なぜちょうど 8 ステージ（5 でも 12 でもない）

科学的方法から逆推論：擁護可能な AI トランスフォーメーションレポートは **5 つの推論アクションを歩まなければならない**、それらの間に厳格なデータ依存関係：

| 推論アクション | Stage にマッピング | スキップが引き起こすもの |
| --- | --- | --- |
| **A. 現状を観測** | Stage 1 As-Is | 客観的ベースラインなし → 後のすべてが推測 |
| **B. 国際座標を適用** | Stage 2 Reference Model | 外部座標なし → 「我々は十分でない」はコンサルタント意見 |
| **C. クライアントが自分の Ideal Practice を展開** | Stage 3 Best Practice | クライアント署名目標なし → クライアントはギャップを否定可能 |
| **D. ギャップを定量化** | Stage 4 Gap Analysis | 構造化ギャップなし → 優先順位付け不可 |
| **E. コア問題を収束** | Stage 5 Problem Definition | 80/20 なし → 「すべてが重要」 = 何も実行されない |
| **F. 吸収可能ターゲットを設定** | Stage 6 Phased Goals | フェーズ分解なし → ワンショット完璧主義 = 失敗 |
| **G. ブループリント設計** | Stage 7 To-Be Design | To-Be 図なし → Roadmap は組織とシステムに着地しない |
| **H. 実行 & 統治** | Stage 8 Implementation | Change Mgmt + Value Tracking + Audit なし → ブループリントは壁紙 |

**なぜちょうど 8**：各推論アクションは不可分；**いずれか 1 つをスキップすると挑戦が無回答のまま**。

- Stage 2 スキップ → 「あなたの標準は？」無回答
- Stage 4 スキップ → 「なぜこれが先で、あれが後？」無回答
- Stage 6 スキップ → 「なぜ 9 ヶ月、3 ヶ月ではなく？」無回答
- Stage 8 スキップ → 「改善したことをどう証明？」無回答

> 5 ステージは粗すぎる（Reference Model、Phased Goals、Change Mgmt を省略）；12 ステージは細かすぎる（冗長なサブステップ）。**8 は「最小完全議論可能推論チェーン」**。

---

## 4. なぜデータはこのように流れるか（各矢印の科学的理由）

```
Stage 1 ──────────► Stage 2 ──────────► Stage 3 ──────────► Stage 4
As-Is              Reference Model     Best Practice         Gap
観測された現実      国際座標            クライアント Ideal     客観的ギャップ
                                        Practice（署名）
                                                              │
                                                              ▼
Stage 8 ◄────────── Stage 7 ◄────────── Stage 6 ◄────────── Stage 5
Implementation      To-Be Design       Phased Goals          Problem
着地 + change       未来ブループリント   吸収可能ステップ      コア収束
                                                              
        ↑                                                     ↓
        └─── 四半期：Stage 2 レーダー再訪（クローズドループ検証） ───┘
```

#### 各矢印がなぜ因果的に必要か

| 矢印 | なぜこの方向 | 反転が引き起こすもの |
| --- | --- | --- |
| **Stage 1 → 2** | 「標準」と比較する前に「現実」を持たなければならない | 反転：エビデンスを標準に合わせるためチェリーピック |
| **Stage 2 → 3** | 「クライアント Ideal」を議論する前に「構造完全」を確認しなければならない | 反転：Ideal が構造ギャップをスキップ |
| **Stage 3 → 4** | 「Gap =（クライアント Ideal − クライアント As-Is）」を計算する前に **クライアント署名 Ideal Practice** を持たなければならない | クライアント署名なし、ギャップ = コンサルタント意見、反駁可能 |
| **Stage 4 → 5** | 「コア問題」に 80/20 収束する前に「すべてのギャップ」を持たなければならない | 4 なし、問題定義 = 推測 |
| **Stage 5 → 6** | 「ターゲット」を設定する前に「コア問題」をロックしなければならない | 5 なし、ターゲット分散 |
| **Stage 6 → 7** | 「ブループリント」を設計する前に「フェーズターゲット」を持たなければならない | 6 なし、ブループリントはワンショット試行 |
| **Stage 7 → 8** | 「実行」の前に「ブループリント」を持たなければならない | 7 なし、実行は盲目 |
| **Stage 8 ↑ Stage 2（四半期）** | 実行後、「標準レーダーはより丸い？」を再訪 | ループバックなし、PoC は完了したが構造は未検証 |

> **これが「クローズドループ」の科学的意味**：「やった = 良い」ではなく、「結果は遡及的に検証 / 反証可能」。

---

## 5. なぜ Reference Model は 4 層（3 でも 5 でもない）

成熟度の「**抽象 × 揮発性**」軸から導出（[`CONSULTING_TOOLKIT_TEMPLATES_EN.md`](../03_Consulting_Report/CONSULTING_TOOLKIT_TEMPLATES_EN.md) Tool 2.7 参照）：

| 抽象 | 揮発性 | 層 | なぜマージまたは省略できないか |
| --- | --- | --- | --- |
| 最も抽象 | 年単位 | **L1 Governance** | 戦略とポリシーはプロセスと混合できない（揮発性が 10 倍違う） |
| 抽象 | 四半期-年 | **L2 Business** | ビジネス機能はデータサービスと混合できない |
| 中 | 月-四半期 | **L3 Information** | データサービスはハードウェア/ネットワークと混合できない |
| 最も具象 | 週-月 | **L4 Technical** | ハードウェアが Business 層に混入するとテック選択がロック |

**3 層不十分**：通常 L3 Information を落とす → データサービスが L2 または L4 に押し込まれる → フォーカス喪失。
**5 層過剰**：余分な層は通常 L2 または L3 のサブ層 → MECE 違反。

> **Dragon1 学派が 4 層に固執するのはこの科学的理由から**。Tiger AI Enterprise AI Reference Model は厳密にそれに従う。

---

## 6. なぜケースは Benchmark-grade でなければならないか（叙述でない）

科学は「**再現可能性**」を要求する — 異なるコンサルタント / クライアントが読む同じケースは類似の「ギャップ推定」を産むべき。

- **叙述的ケース**：「X 社は AI 品質検査を行い成功した」 → 再現不可能（各読者が違うように解釈）
- **Benchmark-grade ケース**：9 必須フィールド（業界 + スケール + 開始 L + 終了 L + 期間 + 投資 + Wins + Failures + 適用性） → **再現可能**（任意の読者のギャップ/時間/予算推定が類似範囲に落ちる）

Tool 3.5 Cases-as-Benchmarks 参照。

> **これがなぜすべての 7 Tiger AI ケースが同じ 9 フィールドテンプレートに従うか** — 視覚的一貫性のためでなく、**再現可能性**の科学的条件のため。

---

## 7. レポートの「科学的論証力」チェックリスト

クライアント / ボード / 規制当局が以下の質問をするとき、本方法論には特定の回答場所がある：

| 挑戦 | 回答場所 | エビデンス |
| --- | --- | --- |
| 「我々が L2 だとどうしてわかる？」 | §3 As-Is + §4 RM Mapping | インタビュー録音、システム inventory、RM レーダー 0-4 |
| 「なぜ APQC / Tiger AI L1-L5？」 | §4.1 + Tool 2.5 | 10 条件資格スコアカード |
| 「我々の理想からどれだけ離れている？」 | §5 + §6.1 | **クライアント署名 Ideal Practice 定義テーブル** + ケース Benchmark；Gap =（あなたの署名 Ideal − あなたの As-Is）、両端ともあなたの陳述 |
| 「なぜカスタマーサービスがセールスより先？」 | §6.2 + §6.3 | Impact × Effort マトリックス + Prioritization Score |
| 「なぜコア問題が「ナレッジ資産化」？」 | §7 | 80/20 impact-surface 数字 + 5 Whys チェーン |
| 「なぜ 9 ヶ月、3 ヶ月ではなく？」 | §8 + Tool 6.3 | Phased 分解 + Organizational Absorption（6 次元）+ benchmark ケース期間 |
| 「PoC が失敗したら？」 | §13.2 | Risk Register + Triggers + Mitigation Owners |
| 「改善したことをどう証明？」 | §13.1 + 四半期レーダーレビュー | Value Tracking 5 次元 + Stage 2 レーダー before/after |
| 「AI が失敗したら誰が責任？」 | §12.1 + Tool 8.8 | RACI + AI Ethics Checklist + Audit Log 完全チェーン |
| 「方法論は再現可能か？」 | 方法論全体 | Apache 2.0 + GitHub + Tool 2.5 自己資格 9/10 |
| 「前のコンサルタントは L3、あなたは L2 — どちらが正しい？」 | §3 スコアリングエビデンス | 公的 0-4 スケール + 各スコアに観測可能エビデンス → **第三者検証可能** |
| 「なぜちょうど 8 ステージ？」 | 本文書 §3 | 「最小完全議論可能推論チェーン」議論 |

> **レポートが議論可能文書になる**：クライアントは「コンサルタント権威を信頼」するのでなく、「エビデンスチェーンに従って同じ結論に自分で到達」する。それが科学的管理。

---

## 8. メインストリームコンサルティング方法論との比較

| 方法論 | 強み | 欠けるもの（科学的完全性のレンズから） |
| --- | --- | --- |
| **McKinsey Issue Tree + Pyramid** | 厳密な論理推論、強いナラティブ | Reference Model なし（座標なし）；Phased Goals なし（フェーズ分解なし） |
| **BCG Digital Maturity** | 明確な 5 段階成熟度 | 定量化された Best Practice なし（卓越がコンサルタントにより記述）；組織吸収評価なし |
| **Gartner AI Maturity** | 業界認知 | As-Is インタビュー規律なし；再現可能ケース Benchmark なし |
| **MIT AI Capability** | 学術的厳密 | Implementation & Change 着地ツール欠如 |
| **Tiger AI（本方法論）** | **8 ステージ完全推論チェーン + 4 層 Reference Model + Cases-as-Benchmarks クローズドループ** | 新規（2025 ローンチ、ケース蓄積中） |

> **他の方法論が悪いとは言わない** — 各々強みがあるが **クローズドループが不完全** と言う。Tiger AI の設計目標はそのループを完成させ、レポートが **表紙から最終ページまで各文にエビデンス** を持つようにすること。

---

## 9. 学術および規制引用の価値

なぜ本方法論は学術コミュニティによって検証、引用、改善可能か：

1. **公的**：Apache 2.0、GitHub repo、zh/en バイリンガル
2. **自己資格可能**：Tool 2.5 自己評価、10 条件のうち 9 を満たす
3. **理論的ルーツ透明**：Rosemann BPM Maturity 学派（QUT）+ CMMI + APQC + Dragon1 EA 各々引用
4. **業界横断検証**：製造 / 病院 / マーケティング / B2B / Financial / Government / Education — 7 業界ケース（ポータビリティ検証）
5. **反証可能**：各 Stage Gate Criteria に反駁条件
6. **批判可能**：本文書と Tool 2.5 はともに「新規、認知蓄積中」と明示的に注記

> **学術引用のゴールドスタンダードは「他の誰かがこの方法を別の問題に適用して類似の結論を得られるか？」** — Tiger AI 方法論は Yes と回答、すべてのステップ、ツール、スコアリング基準が公的だから。

---

## 10. コンサルタントのための運用規律

このレポートを書くとき、各段落は以下に回答しなければならない：

```
この陳述のエビデンスは何か？                          ← 観測可能
この数字はどう計算されたか？                          ← 定量化可能
別のコンサルタントが同じ結果を得るか？                ← 再現可能
これが間違っていたら何が見えるか？                    ← 反証可能
このプロセスに誰が署名したか？                        ← 監査可能
```

**5 つすべてに回答 → その段落は科学的管理**。
**いずれか回答不可 → その段落は個人的意見；エビデンスを補足するか削除**。

---

## 11. クライアントへの約束

本方法論は約束する：

1. **すべての結論に番号付きエビデンス** — Appendices A-G 完全追跡可能
2. **すべての数字に計算式** — 「コンサルタント判断に基づいて」なし
3. **すべての推奨に Stage Gate Criteria** — あなたが検証可能
4. **すべての risk に Trigger + Owner + Mitigation** — あなたが管理可能
5. **すべてのケースが Benchmark-grade** — あなたがギャップを自己計算可能
6. **各フェーズ終了で Reference Model レーダー再訪** — あなたが構造が実際により丸くなるのを見る

**ある段落が「コンサルタント権威が決定」と感じたら、指摘してください。エビデンスを追加、公式を修正、または削除します**。

---

## 12. クロージング：本方法論自体が Reference Model

最終的な自己参照的観察：

- 本方法論は Tool 2.5 の 10 条件を適用して **自己評価**：10 のうち 9 達成（条件 6「広い業界認知」はまだ蓄積中）
- 本方法論は Tool 2.6 の 5 つの導出質問を適用して **コンポーネントを自己インベントリ**：8 ステージ + 4 層 + 5 トラッキング次元すべて存在
- 本方法論は Tool 2.7 の 4 層アーキテクチャを適用して **自己組織化**：Governance（本文書）+ Business（Stages 1-8）+ Information（toolkit + cases）+ Technical（GitHub repo + AGENTS.md + CLAUDE.md）
- 本方法論は Tool 3.5 の Cases-as-Benchmarks を適用して **再現可能性を自己証明**：7 業界ケースすべて 9 フィールドテンプレートに従う

> **これが科学的管理のクローズドループ**：方法論は他者を分析するだけでなく、**自分自身を自分のツールで分析可能** — 学術界で「自己参照的一貫性」と呼ばれ、厳密な理論の刻印。

---

## References

- Rosemann, M., de Bruin, T. (2005). *Towards a Business Process Management Maturity Model*. QUT.
- APQC (2024). *Process Classification Framework Version 7.3*.
- CMMI Institute (2018). *CMMI for Development V2.0*.
- Dragon1 (n.d.). *Enterprise Architecture Reference Model*. <https://www.dragon1.com/reference-models/enterprise-architecture-reference-model>
- Pyramid Principle: Minto, B. (2009). *The Pyramid Principle*.
- 80/20: Koch, R. (1997). *The 80/20 Principle*.
- 5 Whys: Ohno, T. (1988). *Toyota Production System*.
- Change Management: Kotter, J. (1996). *Leading Change*. Prosci ADKAR.

---

ライセンス & 引用

本ドキュメントは Apache License 2.0；[`../NOTICE`](../NOTICE) 帰属が保持されることを条件に、使用、修正、商業化可能。
