decision-clarity

Decision Clarity

このスキルは、曖昧で重要度が高く、複雑になりやすい問題を、より明確な意思決定へと導くために使用します。

このスキルでは、次の3つの思考モードを実践的な順序で組み合わせます。

1. ソクラテス式の質問で、本当の問題を明確にする
2. 第一原理思考で、問題を事実と制約に分解する
3. オッカムの剃刀の考え方で、不要な複雑さを取り除く

哲学的に聞こえることを目的に、このスキルを使わないでください。判断の質を高めるために使ってください。

中核となる目標

次のことを満たす回答を作成します。

1. 本当の問いを特定する
2. 隠れた前提を明らかにする
3. 問題を事実、制約、因果関係の構造に分解する
4. 複雑さと前提の多さを基準に選択肢を比較する
5. 見せかけの複雑さを取り除く
6. 明確な推奨事項、次のステップ、または検証方法で締めくくる

優れた回答を受けたユーザーは、次のように感じるはずです。

• 「本当の問題が、今はより明確になった」
• 「自分が見落としていた前提を見つけてくれた」
• 「思っていたより簡単だ」
• 「次に何をすべきか分かった」

基本姿勢

自信を示すことより、明確さを優先します。

次の点を問いかけます。

• ユーザーが実際に決めようとしていること、または理解しようとしていることは何か？
• 問題のどの部分が曖昧で、引き継いだままになっていて、検証されていないのか？
• 実際に重要なのは、どの事実と厳格な制約か？
• 不要な前提がより少なくて済む説明や計画はどれか？
• 現実を尊重しながら実行できる、最もシンプルな方法は何か？

特に適した用途

このスキルは、特に次の用途で役立ちます。

• スタートアップやビジネスに関する意思決定
• 製品や MVP に関する意思決定
• コンテンツやクリエイターのワークフロー設計
• 業務やプロセスの簡素化
• 複数の選択肢があり得る戦略上の問い
• 混乱、自己正当化、複雑さが判断を歪めている個人的な意思決定
• 議論や推論の監査

適さない用途

次の用途では、このスキルを使用しないでください。

• 単純な事実の検索
• 純粋に機械的な実行タスク
• 明らかで、重要度の低い選択
• ユーザーが捉え直しを望まず、一般的な指針だけを明示的に求めている場合

ワークフローの振り分け

必要最小限で役立つワークフローを選びます。

• 問題が曖昧で、要素が過剰に詰め込まれている、または適切に整理されていない → Workflows/Clarify.md
• 問題を事実、制約、仕組みに分解する必要がある → Workflows/Deconstruct.md
• 説明、手順、機能、構成要素が多すぎる → Workflows/Simplify.md
• ユーザーが推奨事項、意思決定の基準、優先順位、または検証方法を必要としている → Workflows/Decide.md

重要度の高い問題では、一連の流れすべてを使います。

1. 明確化する
2. 分解する
3. 簡素化する
4. 決定する

よりシンプルな問題では、この流れを短縮しつつ、論理は維持します。

モードの選択

意思決定の改善につながる範囲で、最も軽い回答モードを選びます。

モード A：簡潔な捉え直し

次のような短い質問に使用します。

• 「何を見落としているのでしょうか？」
• 「複雑に考えすぎていますか？」
• 「本当にこの方法でなければならないのでしょうか？」
• 「実際には、どの選択肢がより妥当でしょうか？」

出力：

• 本当の問題
• 隠れた前提
• 主な制約
• よりシンプルな結論
• 次の一手

モード B：構造化された意思決定分析

スタートアップ、製品、コンテンツ、業務、戦略に関する意思決定に使用します。

出力：

• 本当の目標
• 前提
• 基本的な事実
• 厳格な制約
• 柔軟な制約
• よりシンプルな選択肢
• 推奨事項
• 最初の検証方法、または次のステップ

モード C：推論の監査

弱点や混乱がある、または過度に複雑になっている可能性のある議論、主張、意思決定の道筋をユーザーが示した場合に使用します。

出力：

• 本当の問い
• 弱い前提
• 不足している証拠、または矛盾
• よりシンプルな解釈や設計
• 洗練された判断

短い分析で十分な場合に、長い分析を無理に行わないでください。

必須の推論ルール

1. 解決する前に明確にする

間違った問題をうまく解決しないでください。

ユーザーが現在どのように捉えているかだけでなく、目指す成果という観点から問題を言い換えてください。

例：

• 「アプリを作るべきですか？」は、実際には「このユーザーの望む成果を実現するには、どの提供方法が最適か？」という問いかもしれません。
• 「もっとプロらしくするには？」は、実際には「信頼、明瞭さ、コンバージョン、権威性を高めるには？」という問いかもしれません。
• 「なぜこんなに難しいのですか？」は、実際には「本当のボトルネックはどの部分か？」という問いかもしれません。

質問のレベルが適切でなければ、そのことを伝え、適切なレベルに修正してください。

2. 前提を明示する

次の点に潜む前提を探してください。

• ユーザーの言葉遣い
• 引き継がれてきたワークフロー
• 業界の慣習
• デフォルトのベストプラクティス
• 好みのツールや形式
• 論理として提示された感情的な好み

自問する際に役立つ問い：

• 何が必須だと見なされていますか？
• この結論が成り立つには、何が事実である必要がありますか？
• 何が根拠なしに受け入れられていますか？
• 最も大きな影響を与えている前提はどれですか？

3. 問題を事実と制約に分解する

問題を次の項目に分けてください。

• 目標
• ユーザーの行動
• インセンティブ
• コスト構造
• 所要時間
• 依存関係
• 情報の流れ
• 因果要因
• 法的または技術的な境界
• 実際のリスク

ストーリーよりもメカニズムを重視してください。

実際の仕組みを説明せずに、「これが市場の仕組みです」と言わないでください。

4. 厳格な制約と柔軟な制約を区別する

厳格な制約

反証がない限り、次の制約は現実のものとして扱ってください。

• 物理的な制限
• 法律上または規制上の制限
• 技術上の厳格な境界
• 固定された予算や処理能力
• 現実にすでに確定している動かせない期限

柔軟な制約

次の制約には、原則として疑問を投げかけてください。

• 業界の慣習
• 従来のプロセス手順
• デフォルトのツール選択
• 現在の組織の境界
• 美的な期待
• 既存のアーキテクチャ
• 「通常はこうするもの」

正当な理由なく、柔軟な制約を変更不可能なものとして示さないでください。

5. 前提をできるだけ少なくする

説明や選択肢を比較するときは、次の条件を満たすものを優先してください。

• 推測に頼る前提が少ない
• 可動要素が少ない
• 調整コストの増加が少ない
• より少ない構造で本来の目標を維持できる
• それでも事実と制約に十分適合する

現実を取り除いて単純化しないでください。単純さを保ちながら、必要な要素を満たす必要があります。

6. 最後に判断を示す

必ず次のいずれかで締めくくってください。

• 推奨事項
• 判断基準
• 優先順位
• 価値のある最小限の実験
• 最初の実装手順
• 次に確認すべき事項の短いリスト

抽象的な考察だけで終わらないでください。

情報が不足している場合

そこで止まらないでください。代わりに、次のように進めてください。

1. 重要な曖昧さを特定する
2. 最も可能性の高い解釈を示す
3. 必要最低限の前提を明示する
4. 現時点で最善の解釈に基づいて進める
5. どの事実が推奨を最も大きく変えるかを伝える

分野別の参考資料

必要に応じて、関連する資料だけを読んでください。

• references/business.md：スタートアップ、価格設定、成長、流通、戦略
• references/product.md：MVP、機能の判断、オンボーディング、ユーザーの用事、スコープ
• references/content.md：チュートリアル、クリエイターのワークフロー、コンテンツの品質、制作システム
• references/operations.md：SOP、承認、引き継ぎ、ワークフローの簡素化
• references/trigger-questions.md：曖昧なユーザーの質問を、より鋭い分析の枠組みに変換する方法
• references/output-patterns.md：安定した回答構成
• references/examples.md：具体的で価値の高い例
• references/anti-patterns.md：推論が過度に抽象的になったり、延々と質問を続けたり、誤った単純化に陥ったり、実行につながらなくなったりするおそれがある場合

品質基準

このスキルで生成される優れた回答は、次の条件を満たします。

• 実際の判断や問いを特定する
• 隠れた前提を明らかにする
• 事実と惰性を切り分ける
• 不必要な複雑さを減らす
• 十分さを保つ
• ユーザーが次に取るべき行動を明確にする

回答が巧妙に聞こえても、ユーザーの判断の質を高めないのであれば、十分とは言えません。