layered-reasoning

階層的な推論

---

よくあるパターン

パターン 1：30K → 3K → 300 フィートへの分解（トップダウン）

該当する場合：ビジョンや原則から始めて、具体的なアクションを導き出すとき

構造：

• 30,000 フィート（戦略）：なぜか？ 中核となる原則、不変条件、制約（例：「顧客のプライバシーは絶対に譲れません」）
• 3,000 フィート（戦術）：何をするか？ アプローチ、アーキテクチャ、ポリシー（例：「ゼロトラストのセキュリティモデル、エンドツーエンド暗号化」）
• 300 フィート（運用）：どのようにするか？ 具体的なアクション、手順、コード（例：「保存データに AES-256 暗号化を実装する」）

例：製品戦略

• 30K：「最も信頼されるプラットフォームになる」（原則）
• 3K：「SOC 2 準拠を達成し、セキュリティレポートを公開し、24 時間 365 日のサポートを提供する」（戦術）
• 300 フィート：「MFA を実装し、四半期ごとに監査を実施し、サポートエンジニアを 5 人採用する」（アクション）

プロセス：（1）戦略レイヤーの不変条件を定義する、（2）不変条件を満たす戦術的な選択肢を導き出す、（3）戦術を選択する、（4）戦術を実行する運用手順を設計する、（5）運用レイヤーが戦略上の制約に違反していないことを検証する

パターン 2：ボトムアップでの集約

該当する場合：観察結果やデータから始めて、原則を組み立てるとき

構造：

• 300 フィート：具体的な観察結果、測定値、インシデント（例：「ユーザー A は 5 回クリックし、ユーザー B は途中で離脱した」）
• 3,000 フィート：パターン、傾向、カテゴリ（例：「チェックアウト時に 40% が離脱し、読み込みの遅さが離脱と相関している」）
• 30,000 フィート：原則、理論、根本原因（例：「パフォーマンスはコンバージョンに影響し、100 ミリ秒ごとにコンバージョン率が 1% 低下する」）

例：エンジニアリングの事後分析

• 300 フィート：「午後 3 時 42 分にサービスがクラッシュし、メモリ使用量が 32GB まで急増し、500 エラーが返された」
• 3K：「負荷がかかった状態で特定の API 呼び出しパターンが発生し、キャッシュレイヤーでメモリリークが起きた」
• 30K：「当社のキャッシュ戦略には削除ポリシーがない。すべてのキャッシュに TTL ベースの有効期限が必要である」

プロセス：（1）運用データを収集する、（2）パターンを特定して分類する、（3）戦術レイヤーで仮説を立てる、（4）追加データで検証する、（5）戦略上の原則を抽出する

パターン 3：レイヤー間の翻訳（レイヤーを越えたコミュニケーション）

該当する場合：同じ概念を異なる相手（CEO、マネージャー、エンジニア）に説明するとき

手法：中核となる意味を保ちながら、抽象度を調整して翻訳する

例：技術的負債の説明

• CEO（30K）：「初期には迅速に構築しました。今後、近代化に 200 万ドルを投資しない限り、成長率は毎年 20% ずつ低下します。」
• マネージャー（3K）：「モノリシックアーキテクチャが、チームの独立した開発速度を妨げています。6 か月かけてマイクロサービスに移行しましょう。」
• エンジニア（300 フィート）：「ユーザーサービスをモノリスから切り出す。API レイヤーを作成し、サービスメッシュを実装して、トラフィックを移行する。」

プロセス：（1）相手のレイヤーを特定する、（2）中核となるメッセージを抽出する、（3）そのレイヤーに関連する概念や指標を使って翻訳する、（4）レイヤー間の因果関係を保つ

パターン 4：制約の伝播（トップダウン）

該当する場合：高レベルの制約が低レベルの意思決定を導く必要があるとき

仕組み：戦略上の制約が下位に伝わり、各レイヤーで選択肢を絞り込む

例：医療アプリの設計

• 30K の制約：「HIPAA 準拠は絶対に譲れません」（戦略）
• 3K の導出：「すべての PHI を暗号化し、監査ログを必須とし、アクセス制御を義務付ける」（戦術）
• 300 フィートの実装：「暗号化に AWS KMS、監査に CloudTrail、アクセス制御に IAM を使用する」（運用）

ガードレール：下位レイヤーは上位の制約に違反できません（例：暗号化を省略するという運用上の判断は、戦略上の制約に違反します）

パターン 5：創発的な特性の認識（ボトムアップ）

適用場面：下位レイヤーでの相互作用によって、上位レイヤーに予想外の振る舞いが生じる場合

例：チーム構成

• 300 ft：「各チームがマイクロサービスを担当し、独立してデプロイし、連携には Slack を使用する」
• 3K emergence：「コンウェイの法則：アーキテクチャはコミュニケーション構造を反映する。チーム間にまたがる機能の開発は遅い」
• 30K insight：「組織構造がシステムアーキテクチャを決定する。サービス単位ではなく、製品ライン単位でチームを再編する」

プロセス：(1) 運用上の振る舞いを観察する、(2) 戦術レイヤーで創発するパターンを特定する、(3) 戦略上の意味を認識する、(4) 必要に応じて戦略を調整する

パターン 6：レイヤー間の整合性チェック

適用場面：すべてのレイヤーが整合していること（矛盾がないこと）を検証する場合

チェックの種類：

• 上向きの整合性：運用は戦術を実現していますか？ 戦術は戦略を達成していますか？
• 下向きの整合性：この戦術で戦略を実行できますか？ 戦術を運用レベルで実装できますか？
• 横方向の整合性：並行する戦術上の選択が互いに矛盾していませんか？ 運用手順が互いに衝突していませんか？

矛盾の例：戦略では「迅速に動く」としている一方、戦術では「広範な承認プロセス」、運用では「リリースサイクルは 3 週間」としている → 矛盾

修正：レイヤー間の整合を取ります。(1) 戦略を変更する（「慎重に進める」）、(2) 戦術を変更する（「簡素な承認プロセス」）、または (3) 運用を変更する（「毎日リリースする」）のいずれかです

---

ワークフロー

レイヤー化された推論を適用する際は、次の体系的なアプローチを使用します。

□ Step 1: Identify relevant layers and abstraction levels
□ Step 2: Define strategic layer (principles, invariants, constraints)
□ Step 3: Derive tactical layer (approaches that satisfy strategy)
□ Step 4: Design operational layer (concrete actions implementing tactics)
□ Step 5: Validate consistency across all layers
□ Step 6: Translate between layers for different audiences
□ Step 7: Iterate based on feedback from any layer
□ Step 8: Document reasoning at each layer

ステップ 1：関連するレイヤーと抽象度を特定する（詳細） 必要なレイヤーの数を決めます（通常は 3～5 層）。レイヤーを各領域に対応付けます：ビジネス（ビジョン／戦略／実行）、技術（アーキテクチャ／設計／コード）、組織（ミッション／目標／タスク）。

ステップ 2：戦略レイヤーを定義する（詳細） 維持すべき高レベルの原則、不変条件、制約を定めます。これらは譲れないものであり、すべての下位レイヤーの指針となります。

ステップ 3：戦術レイヤーを導き出す（詳細） 戦略上の制約を満たすアプローチ／ポリシー／アーキテクチャを作成します。複数の戦術的な選択肢がある場合は、トレードオフに基づいて選びます。

ステップ 4：運用レイヤーを設計する（詳細） 戦術上の選択を実現する具体的な手順、実装、またはアクションを作成します。実行はここで行われます。

ステップ 5：すべてのレイヤー間の整合性を検証する（詳細） 上向き（運用は戦術を実現しているか？）、下向き（戦略を実行できるか？）、横方向（並行する選択が衝突していないか？）の整合性を確認します。

ステップ 6：対象者に応じてレイヤー間の表現を変える（詳細） 各ステークホルダーに適した抽象度で伝えます。CEO には戦略的な概要が必要で、エンジニアには運用上の詳細が必要です。

ステップ 7：どのレイヤーからのフィードバックにもとづいて反復する（詳細） 運用上の制約によって戦術が実現不可能な場合は、戦術または戦略を調整します。戦略に変更が生じた場合は、その変更を下位レイヤーへ反映します。

ステップ 8：各レイヤーの推論を文書化する（詳細） 各レイヤーについて、上位／下位レイヤーとの関係を説明する明確な根拠を記述します。これにより前提が明らかになり、今後の反復にも役立ちます。

---

ガードレール

1. レイヤー間の整合性を保つ

危険：戦略目標が運用の現実と矛盾する、または実装が原則に違反する

ガードレール：上向き、下向き、横方向の整合性を定期的に確認します。変更は双方向に反映します（戦略の変更 → 戦術／運用を更新、運用上の制約 → 戦術／戦略を更新）。

危険信号：「戦略は X ですが、実際には Y をしています」はレイヤーの不整合を示しています

2. コミュニケーションではレイヤーを飛ばさない

危険：30K ftから300 ftへ飛ぶと、聞き手が混乱し、文脈を見失います。

ガードレール：レイヤーを順番にたどります。経営幹部に説明する場合は、30K ftから3K ftへ進みます（求められない限り、そこで止めます）。エンジニアに説明する場合は、まず30K ftの文脈を示してから、300 ftまで掘り下げます。

テスト：聞き手は「なぜこれが重要なのか」（上位レイヤーとのつながり）と「これをどう実現するのか」（下位レイヤーとのつながり）に答えられますか？

3. 各レイヤーはそれぞれ単独で役立つものにする

危険：組み合わせて初めて意味を成し、単独では理解できないレイヤー

ガードレール：運用を見なくても、戦略レイヤーが意思決定の指針となるようにします。コードがなくても、戦術レイヤーを理解できるようにします。戦略を再導出しなくても、運用レイヤーを実行できるようにします。

原則：優れたレイヤーは、異なる対象者がそれぞれ独立して活用できます。

4. レイヤーは3～5段階に抑える

危険：レイヤーが多すぎると負担が増え、少なすぎると細かな違いが失われます。

ガードレール：ほとんどの領域では、3レイヤーで十分です（戦略／戦術／運用、またはアーキテクチャ／設計／コード）。複雑な領域では4～5段階が必要になることもありますが、それ以上になることはほとんどありません。

経験則：各レイヤーに明確な名前を付けられますか？付けられない場合は、レイヤーが多すぎます。

5. 上位レイヤーは制約を定め、下位レイヤーは実装する

危険：レイヤーを階層ではなく、互いに独立したものとして扱うこと

ガードレール：戦略レイヤーが制約を定めます（「HIPAAに準拠しなければならない」）。戦術レイヤーは制約の範囲内でアプローチを選択します（「暗号化＋監査ログ」）。運用レイヤーはそれを実装します（「AES-256＋CloudTrail」）。上位レイヤーの制約に違反してはなりません。

アンチパターン：運用上の判断（「速度を優先して暗号化を省く」）が、戦略上の制約（「HIPAA準拠」）に違反する

6. 変更を双方向に反映する

危険：戦略を変更しても戦術や運用を更新しないこと、または運用上の制約が判明しても戦略を変更しないこと

ガードレール：トップダウン：戦略の変更 → 戦術を再評価 → 運用を調整。ボトムアップ：運用上の制約 → 戦術を再評価 → 必要に応じて戦略を調整。

例：「プライバシー優先」への戦略変更 → 戦術を更新（エンドツーエンド暗号化） → 運用を更新（暗号化を実装）。または、運用上の制約（パフォーマンス） → 戦術を調整（別のアプローチ） → 戦略を明確化（「パフォーマンスの制約内でプライバシーを優先」）

7. 各レイヤーの前提を明示する

危険：暗黙の前提は、その前提が崩れたときに一貫性の欠如を招きます。

ガードレール：各レイヤーの前提を記録します。戦略：「競争のある市場を想定」。戦術：「クラウドインフラを想定」。運用：「Python 3.9+を想定」。

メリット：前提が変わったときに、どのレイヤーを更新する必要があるかが分かります。

8. 創発的な特性を認識する

危険：設計した特性だけに注目し、意図しない結果を見落とすこと

ガードレール：下位レイヤーを定期的に観察し、中位レイヤーで生まれるパターンを探り、戦略への影響を検討します。創発的な特性によって、戦略上の前提が無効になることがあります。

例：マイクロサービス（運用） → 調整のオーバーヘッド（戦術上の創発） → 機能提供の遅延（目標が速度だった場合の戦略上の失敗）

---

クイックリファレンス

領域別のレイヤーマッピング

領域	レイヤー1（30K ft）	レイヤー2（3K ft）	レイヤー3（300 ft）
ビジネス	ビジョン、ミッション	戦略、目標	戦術、タスク
プロダクト	市場でのポジショニング	機能ロードマップ	ユーザーストーリー
技術	アーキテクチャの原則	システム設計	コードの実装
組織	文化、価値観	ポリシー、プロセス	日々の手順

整合性チェックの質問

チェックの種類	質問
上位方向	これらの運用は戦術を実現していますか？ 戦術は戦略を達成していますか？
下位方向	利用可能な戦術でこの戦略を実行できますか？ 戦術を運用面で実装できますか？
横方向	並行する戦術上の選択肢は互いに矛盾していませんか？ 運用手順は競合していませんか？

対象者別の翻訳ヒント

対象者	レイヤー	焦点	指標
CEO／取締役会	30K ft	理由、成果、リスク	売上、市場シェア、戦略的リスク
VP／ディレクター	3K ft	内容、アプローチ、リソース	チームのベロシティ、ロードマップ、予算
マネージャー／リード	300-3K ft	方法、実行、スケジュール	スプリントのベロシティ、マイルストーン、品質
エンジニア	300 ft	実装、詳細	コード品質、テストカバレッジ、パフォーマンス

---

リソース

リソースへの移動

• テンプレート：レイヤー化された推論ドキュメントのテンプレート、整合性チェックのテンプレート、レイヤー間コミュニケーションのテンプレート
• 方法論：レイヤー設計の原則、整合性検証の手法、創発の検出、双方向の伝播
• 評価基準：レイヤー化された推論の品質に関する評価基準（10項目）

関連スキル

• abstraction-concrete-examples：抽象と具体を行き来するために使用します（関連していますが、レイヤーほど体系化されていません）
• decomposition-reconstruction：複雑なシステムを分解するために使用します（レイヤー化アプローチを補完します）
• communication-storytelling：異なるレイヤーの対象者間で伝えるために使用します
• adr-architecture：レイヤーをまたいだアーキテクチャ上の意思決定を記録するために使用します
• alignment-values-north-star：戦略レイヤーを定義するために使用します（価値観 → 戦略）

---

コンテキスト内の例

例 1：SaaS 製品戦略

30K（戦略）：「小規模企業にとって最も使いやすい CRM になる」（ポジショニング）

3K（戦術）：「シンプルな UI、5 分でセットアップ、モバイルファースト、1 ユーザーあたり 20 ドルの価格設定、セルフサービス型のオンボーディング」

300 ft（運用）：「React アプリ、認証に OAuth、課金に Stripe、オンボーディングの流れ：登録 → 連絡先をインポート → 最初のメールを送信」

整合性チェック：20 ドルの価格設定は「最も使いやすい」という位置付けを支えていますか（はい、参入障壁が低い）？ 5 分でのセットアップは現在の実装で実現できますか（実際に測定）？ モバイルファーストは React アーキテクチャと整合していますか（はい）？

例 2：技術アーキテクチャ

30K：「ダウンタイムを 1% 未満に抑え、トラフィックの 10 倍の増加に対応する高可用性システム」

3K：「マルチリージョンデプロイ、自動スケーリング、サーキットブレーカー、ブルーグリーンデプロイ」

300 ft：「AWS のマルチ AZ、ターゲット追跡を使用する ECS Fargate、Istio サーキットブレーカー、CodeDeploy によるブルーグリーンデプロイ」

創発：観測事項：リージョン間のレイテンシが 200ms → 戦術的な調整：リージョン間のデータレプリケーション → 戦略の明確化：「リージョン内では高可用性を実現し、リージョン間では結果整合性を採用する」

例 3：組織変革

30K：「顧客からのフィードバックが意思決定を左右する、顧客中心の文化を築く」

3K：「毎月の顧客諮問委員会、各インタラクション後の NPS 調査、経営幹部向けダッシュボードに顧客サポートの KPI を表示」

300 ft：「CAB ミーティングを毎月第 1 月曜日に設定、チケット終了後に Delighted を使って NPS を自動収集、担当者別の CS CSAT を表示する Looker ダッシュボード」

整合性：毎月の CAB は「顧客中心」を支えていますか（それとも頻度が低すぎますか）？ サポート KPI は適切な行動を促していますか（指標の操作がないか確認）？ 自動化によって対人的なやり取りが減っていませんか（潜在的な矛盾）？