thinking-socratic

ソクラテス式質問法

基本ルール： 作業に取りかかる前に、成果を左右する前提や未定義の用語を明らかにします。自分では解決できないことだけを尋ね、次のアクションを決定できる段階になったら質問を終えます。

使用する場面

• 依頼の内容が不十分で（「速くして」「ダッシュボードを追加して」「バグを直して」など）、推測で進めると誤ったものを作ってしまう場合。
• 明示されていない前提に依存しており、それが実際の問題である可能性がある場合。
• 誰かが前提を「明らかだ」とみなしたり、問題を定義する前に解決策へ飛びついたりする場合。
• 調査を始める前に、確認可能な具体的事項を特定する必要がある、曖昧な症状のデバッグ。

使用しない場面

• 仕様がすでに明確で実行可能な場合。質問するためだけの質問はせず、作業を進めます。
• コードを読んだり、コマンドを実行したり、ドキュメントを確認したりすれば解消できる曖昧さがある場合。自分で解決します。
• 合意済みの計画を実行している途中の場合。各段階で質問し直すのは、厳密さではなく妨げになります。
• 行動に必要な重要事実が一つだけの緊急時。その事実を確認してから行動します（ooda を優先）。
• 明確化ではなく、最も有力な反対意見が必要な場合。スティールマン法を使います。
• 定義済みの障害について因果関係を深く調べる必要がある場合。five-whys-plus または scientific-method を使います。

手順

1. 不足点を示します。 未定義、仮定されている、または確認できないことを明示します。ツールやリポジトリを使ってユーザーに尋ねずに補える場合は、自分で補い、そこで止めます。
2. 成果を左右する質問を最初に尋ねます。 作るものを最も大きく左右する答えが得られる質問を一つ選びます。質問の種類は、不足点に必要なものだけを使います。
   • 明確化：「X とは何ですか？」「誰にとってのものですか？」「成功とはどのような状態ですか？」
   • 前提：「何が真である必要がありますか？」「それが偽ならどうなりますか？」
   • 根拠：「何がその根拠ですか？」「何が分かれば誤りだと判断できますか？」
   • 視点：「誰が影響を受けますか？」「誰が異議を唱えそうですか？」
   • 影響：「これを実施すると、どのような結果になりますか？」
   • メタ：「そもそも、これは適切な質問ですか？」
3. 解決するか、分岐します。 答えに基づいて、（a）明確になった要件や決定を記し、作業を進めるか、（b）作業の前提としてなお必要な質問を一つだけ追加します。毎回、六種類すべてを尋ねてはいけません。
4. 前提を明示します。 「これは X を前提とします。成功とは Y を意味し、Z は対象外です」と言い直します。言い直しても曖昧さが残る場合に限り、確認を求めます。
5. 次のアクションを決められる段階で止めます。 次のアクションが隠れた前提に左右されなくなったら、質問を終えて実行するか、引き継ぎます。ユーザーへの質問は必要最小限に抑え、本当に作業の前提となる質問だけをまとめて尋ねます。

出力

gap: <what was vague or assumed>
resolved_by: self | user | mixed
questions_asked:
  - <only questions actually needed>
assumptions_made_explicit:
  - <X must be true / success = Y>
clarified_requirement: <decision-ready statement>
next_action: <build | investigate | re-scope | stop>
stop_reason: clear_enough | self_resolved | blocked_on_<fact>

検証

• 反証／中止： 答えによって計画が変わらないなら、成果を左右しない質問をしていたということです。質問を止めます。「明確化」したつもりでもまだ推測に頼っているなら、作業を進めず、残っている障害を示します。
• 過剰適用を防ぐ： 十分に仕様が定まっているタスクに対して、ソクラテス式の質問を重ねてはいけません。読んだり測定したりできる事実をユーザーに調べさせてはいけません。作業の各段階で新たな質問を繰り返してはいけません。