moai-foundation-philosopher

MoAI Foundation 哲学者

すばやい計算よりも深い分析を重視する、戦略的思考のフレームワークです。体系的な問題解決のために、実証済みの3つの方法論を統合しています。

基本理念：行動する前に深く考えます。前提に疑問を持ちます。代替案を検討します。トレードオフを明確にします。認知バイアスを確認します。

クイックリファレンス（30秒）

哲学者フレームワークとは？

複雑な意思決定のための構造化されたアプローチで、次の要素を組み合わせています。

• 第一原理分析：問題を基本的な真理にまで分解します
• Stanford デザイン思考：発散と収束による解決策の創出
• MIT システムエンジニアリング：体系的なリスク評価と検証

5段階の思考プロセス：

1. 前提の監査：当然と考えていることを明らかにし、疑問を持ちます
2. 第一原理による分解：根本原因まで分解します
3. 代替案の創出：複数の解決策を作成します
4. トレードオフ分析：選択肢を体系的に比較します
5. 認知バイアスの確認：思考の質を検証します

有効にするタイミング：

• 5つ以上のファイルに影響するアーキテクチャ上の意思決定
• テクノロジーの選定（ライブラリ、フレームワーク、データベース）
• パフォーマンスと保守性のトレードオフ
• リファクタリングの範囲に関する意思決定
• 破壊的変更の検討
• 長期的に大きな影響を及ぼすあらゆる意思決定

クイックアクセス：

• 前提を問い直す手法：Assumption Matrix Module
• 根本原因分析：First Principles Module
• 選択肢の比較：Trade-off Analysis Module
• バイアスの防止：Cognitive Bias Module

---

実装ガイド（5分）

フェーズ1：前提の監査

目的：隠れた前提が見落としにつながる前に、それを明らかにします。

5つの重要な質問：

• 証拠がないのに、真実だと仮定していることは何ですか？
• この前提が誤りだと判明したら、どうなりますか？
• これは絶対的な制約ですか、それとも単なる希望ですか？
• この前提を裏付ける証拠は何ですか？
• この前提を検証すべき人はほかにいますか？

前提の分類：

• 技術的前提：テクノロジーの能力、パフォーマンス特性、互換性
• ビジネス上の前提：ユーザーの行動、市場状況、予算の確保
• チームに関する前提：スキルレベル、対応可能性、ドメイン知識
• スケジュール上の前提：納期への期待、依存関係のスケジュール

前提の記録形式：

• 前提の記述：仮定している内容を明確に説明します
• 確信度：証拠に基づき、高・中・低で示します
• 根拠となる証拠：この前提を裏付けるものを記載します
• 誤っていた場合のリスク：前提が誤りだと判明した場合の結果を記載します
• 検証方法：確定する前に検証する方法を記載します

理由：検証されていない前提は、プロジェクトの失敗や手戻りの主な原因です。 影響：早期に前提を明らかにすることで、プロジェクト途中の方針転換を40～60％防げます。

フェーズ2：第一原理による分解

目的：複雑さを切り抜け、根本原因と基本要件を見つけます。

「なぜ」を5回繰り返す手法：

• 表面化している問題：ユーザーまたはシステムが認識していること
• 最初の「なぜ」：直接的な原因の分析
• 2つ目の「なぜ」：根底にある原因の調査
• 3つ目の「なぜ」：システム上の要因の特定
• 4つ目の「なぜ」：組織的またはプロセス上の要因
• 5つ目の「なぜ」（根本原因）：対処すべき根本的な問題

制約の分析：

• ハード制約：交渉の余地がない制約（セキュリティ、コンプライアンス、物理法則、予算）
• ソフト制約：交渉可能な希望（スケジュール、機能範囲、ツール）
• 自己課題型制約：要件に見せかけた前提
• 自由度：創造的な解決策を実現できる領域

分解するための質問：

• このリクエストの本当の目的は何ですか？
• 実際に解決しようとしている問題は何ですか？
• 制約がまったくなかった場合、解決策はどのようなものになりますか？
• 実用最小限の解決策は何ですか？
• 目的を達成しながら、何をなくせますか？

理由：ほとんどの問題は、誤った抽象化のレベルで解決されています。 影響：第一原理思考により、解決策の複雑さを30～50％軽減できます。

フェーズ 3：代替案の生成

目的：最適とはいえない解決策に早々に収束するのを避けます。

生成ルール：

• 明確に異なる代替案を最低 3 つ用意します
• 少なくとも 1 つは型破りな選択肢を含めます
• ベースラインとして必ず「何もしない」を含めます
• 短期的および長期的な影響を検討します
• 段階的なアプローチと抜本的なアプローチの両方を検討します

代替案のカテゴリ：

• 保守的：低リスク、段階的な改善、使い慣れたテクノロジー
• バランス型：中程度のリスク、大幅な改善、一定の革新
• 積極的：高リスク、抜本的な変革、最先端のアプローチ
• 急進的：根本的な前提に異議を唱え、まったく異なるアプローチを採用

創造性を高める手法：

• 逆転：この問題を悪化させるにはどうすればよいでしょうか？次に、その逆を行います。
• 類推：他の分野では、同様の問題をどのように解決しているでしょうか？
• 制約の撤廃：予算、時間、テクノロジーに制限がなかったらどうなるでしょうか？
• 単純化：考えられる最もシンプルな解決策は何でしょうか？

WHY：最初の解決策が最善であることは、ほとんどありません。 IMPACT：3 つ以上の代替案を検討すると、意思決定の質が 25% 向上します。

フェーズ 4：トレードオフの分析

目的：暗黙のトレードオフを明示し、比較できるようにします。

標準的な評価基準：

• パフォーマンス：速度、スループット、レイテンシ、リソース使用量
• 保守性：コードの明瞭さ、ドキュメント、チームの習熟度
• 実装コスト：開発時間、複雑さ、学習曲線
• リスクレベル：技術的リスク、失敗の確率、ロールバックの難易度
• スケーラビリティ：成長への対応力、柔軟性、将来への備え
• セキュリティ：脆弱性の範囲、コンプライアンス、データ保護

加重スコアリング手法：

• プロジェクトの優先事項に基づいて評価基準に重みを割り当てます（合計 100%）
• 各基準について、各選択肢を 1～10 で評価します
• 加重総合スコアを計算します
• 各スコアの根拠を記録します
• 重みを変更した場合のスコアの感度を特定します

トレードオフの記録：

• 得られるもの：選択したアプローチの主なメリット
• 犠牲にするもの：受け入れるコストと制限を明示します
• 許容できる理由：これらのトレードオフを受け入れる根拠
• 軽減計画：欠点に対処する方法

WHY：暗黙のトレードオフは、後悔や迷いにつながります。 IMPACT：トレードオフを明示すると、ステークホルダー間の合意度が 50% 向上します。

フェーズ 5：認知バイアスの確認

目的：よくある思考上の誤りを確認し、推奨事項の質を確保します。

主に確認するバイアス：

• アンカリングバイアス：最初に得た情報に過度に依存すること
• 確証バイアス：既存の信念を裏付ける証拠を求めること
• サンクコストの誤謬：過去の投資を理由に続行すること
• 利用可能性ヒューリスティック：最近の出来事や印象的な出来事を過大評価すること
• 過信バイアス：自分の判断に対する過剰な確信

バイアスを検出するための質問：

• この解決策にこだわっているのは、自分が最初に思いついたからでしょうか？
• 自分の好みに反する証拠を積極的に探したでしょうか？
• これまでの投資が何もない状態で一から始めるとしても、これを推奨するでしょうか？
• 当てはまらない可能性のある最近の経験に影響されていないでしょうか？
• この推奨を考え直すとしたら、何がきっかけになるでしょうか？

軽減策：

• プレモーテム：意思決定が失敗したと想定し、何が原因だったか考えます
• 悪魔の代弁者：自分の推奨に反論します
• 外部の視点：成功率の基準値から何がわかるか確認します
• 異論を求める：自分に異議を唱えそうな人に相談します
• 逆転テスト：反対の案が提案されたら、何と言うでしょうか？

WHY：専門家でさえ、時間に追われると認知バイアスに陥ります。 IMPACT：バイアスの確認により、技術的な意思決定の誤りを 20～30% 防げます。

---

高度な実装（10 分以上）

MoAI ワークフローとの統合

SPEC フェーズとの統合：

• /moai:1-plan 中に前提の監査を実施します
• spec.md の問題分析セクションに前提を記録します
• plan.md に検討した代替アプローチを含めます
• acceptance.md に検証基準を定義します

DDD フェーズとの統合：

• 第一原理を用いて、主要なテストシナリオを特定します
• レガシーコード向けに特性テストの代替案を生成します
• 新機能向けに仕様テストの代替案を生成します
• テストカバレッジの判断にトレードオフ分析を適用します

品質フェーズとの統合：

• コードレビューのプロセスに認知バイアスチェックを含めます
• 実装後も前提が妥当であることを確認します
• 最終ドキュメントに受け入れたトレードオフを記録します

時間配分のガイドライン

複雑な判断における推奨作業配分：

• 前提の監査：分析時間の 15%
• 第一原理による分解：分析時間の 25%
• 代替案の生成：分析時間の 20%
• トレードオフ分析：分析時間の 25%
• 認知バイアスチェック：分析時間の 15%

分析と実装の合計時間：

• 単純な判断（1～2 ファイル）：分析 10%、実装 90%
• 中程度の判断（3～10 ファイル）：分析 25%、実装 75%
• 複雑な判断（10 ファイル以上）：分析 40%、実装 60%
• アーキテクチャの判断：分析 50%、実装 50%

判断記録のテンプレート

戦略的判断の記録：

判断のタイトル：決定内容を明確に記述します

背景：この判断が必要になった理由

検討した前提：

• 前提 1 の確信度と検証状況
• 前提 2 の確信度と検証状況

根本原因分析：

• 特定した表面的な問題
• なぜなぜ分析を通じて特定した根本原因

検討した代替案：

• 長所、短所、スコアを含む選択肢 A
• 長所、短所、スコアを含む選択肢 B
• 長所、短所、スコアを含む選択肢 C

受け入れたトレードオフ：

• 選択したアプローチによって得られるもの
• 犠牲にするものと、それが許容できる理由

バイアスチェックの完了：

• バイアスを軽減するために実施した手順の確認

最終判断：主な根拠とともに選択した選択肢を記載します

成功基準：判断が正しかったかどうかの測定方法

見直しの契機：再検討につながる条件

---

相性のよいもの

エージェント：

• manager-strategy：SPEC 分析と計画の主要な利用者
• expert-backend：テクノロジー選定の判断
• expert-frontend：アーキテクチャとフレームワークの選択
• expert-database：スキーマ設計のトレードオフ
• manager-quality：コードレビューでのバイアスチェック

スキル：

• moai-foundation-core：TRUST 5 および SPEC ワークフローとの統合
• moai-workflow-spec：SPEC 形式での前提の記録
• moai-domain-backend：テクノロジー固有のトレードオフ基準
• moai-domain-frontend：UI/UX の判断フレームワーク

コマンド：

• /moai:1-plan：仕様作成中に Philosopher Framework を適用します
• /moai:2-run：実装中に記録済みのトレードオフを参照します

---

判断の早見表

各フェーズを使用するタイミング：

単純なバグ修正：Philosopher を省略します（直接実装） 機能追加：フェーズ 1、3、4（前提、代替案、トレードオフ） リファクタリング：フェーズ 1、2、4（前提、根本原因、トレードオフ） テクノロジー選定：5 つのフェーズすべて（完全な分析が必要） アーキテクチャ変更：ドキュメントを拡充して 5 つのフェーズすべてを実施

---

モジュールの詳細：

• 前提マトリックス
• 第一原理
• トレードオフ分析
• 認知バイアス

例：examples.md 外部リソース：reference.md

起源：Claude Code Philosopher Ignition フレームワークに着想を得ています