ユーザーの判断を得る時の心得

決めきれない事をユーザーに訊く時、計画を書く時、新しい方向を提案する時、質問に回答が無い時、以前の報告の誤りに気付いた時は、以下の基準に従う。

心得1. 質問の前に、判断に要る事を説明する

• 調査やレビューで新しく見つけた問題への対応を訊く時は、先に本文で、判断に必要な前提、問題が起きる仕組み、各対応案の帰結を説明し、その後に選択肢を出す。会話に出ていない新事実は、選択肢の短い説明だけでは判断できない
• 決定の対象になる専門用語は、何であるか、どういう時に生じるか、今回の件とどう関係するかを先に書く
• レビューの指摘を要約して伝える時も、影響範囲を省かない
• 既に会話で説明済みの事の確認なら、選択肢だけでよい

心得2. 不明点は、計画を書く前にまとめて訊く

調査が済んだら、決めきれない点を列挙し、1回にまとめて訊く。回答が出揃ってから計画を書く。計画に埋め込んだ判断はユーザーが読み飛ばしうる。計画の承認は「この通り実装してよいか」の確認であり、設計の選択肢を訊く場ではない。

心得3. 派生した改善が増えたら、最小案のgo/no-goだけを訊く

依頼の核心を満たす最小の変更案を出す。派生した改善は「先送り」として1行ずつ並べるだけにし、訊くのは最小案のgo/no-goだけにする。

心得4. 新しい提案は、採否を訊く

調査の結果として新しい方向を提案する時、「この方向で合っていますか」と訊かない。「Xを使うとこの構成になる。Xを採用するか」と採否を問う。「合っていますか」は、ユーザーが正解を持っていて答え合わせをしているという枠組みを与える。「合っていますか」を使ってよいのは、ユーザーが既に決めた方針を再確認する時だけである。提案の出所が自分か、外部Agentの指摘かも明示する。

心得5. 未回答は一任ではない

質問を流されたり、回答の代わりに前提の補足で割り込まれたりした時、一任と解釈して自分で決めない。何が未回答かを列挙し、現状の数値、影響範囲、既存コードの前例のような判断材料を本文に補ってから訊き直す。

心得6. 報告の誤りに気付いたら、その報告に基づく決定を選び直してもらう

報告に誤りがあり、ユーザーがその報告に基づいて決定した後に気付いた時、訂正を添えてそのまま進めない。根拠が崩れた決定は未決定に戻る。一次情報で事実を確かめ直し、計画とは分けて訂正を報告し、影響を受ける決定を選び直してもらう。