readchk

実行に移る前に読み取りを確認してください。作業に取りかかるだけの十分な理解ができていますか？

目標

readchk は、指示の読み違いによって、意図した対象とは異なるものに対して筋の通った作業を進めてしまう前に、それを検知します。現在のメッセージ、セッション履歴、プロジェクトのメモリ、ディスク上のファイル、確立された慣例など、利用可能なコンテキストと照らし合わせて、依頼者の意図についての理解を検証します。

これは factchk ではありません。問われているのは、世の中の事実が正しいかどうかではなく、何を意味していたのかです。

ワークフロー

1. シグナルを認識します。長文または複数部分からなる指示、曖昧な範囲や指示対象、意図的に幅を持たせた表現、または読み違えると実作業に大きな損失が生じるほどの重要度がある場合です。
2. 指示を自分の言葉で言い換えます。ユーザーの表現をそのまま自分に繰り返して、それを理解したことにしてはいけません。
3. 言い換えた内容を利用可能なコンテキストと照合します。矛盾、先行詞の欠落、またはコンテキストから判断できない複数の妥当な解釈がないか確認します。
4. コンテキストによって解釈が定まる場合は、何も尋ねずに進めます。利用可能なコンテキストですでに答えが出ていることについて、依頼者に確認を求めてはいけません。
5. 本当に解釈が分かれる場合は、言い換えた理解に基づく具体的な確認質問を一つ提示します。選択肢を明示し、「これでよさそうですか？」のような曖昧な質問はしないでください。
6. 大規模な作業では、着手前に「理解した内容：…」という、後から確認できる記録を一行残します。後から読む人が、作業が確認済みの解釈と一致していたか監査できるようにします。

ルール

• 繰り返すのではなく、言い換えます。 言い換えは依頼内容のモデルを組み立てた証拠になります。逐語的な繰り返しでは、ほとんど証明になりません。
• コンテキストで解決する場合は、黙って進めます。 望ましい結果は、何も表面化しないことです。すでに解決済みの質問や曖昧でない依頼について質問を提示するのは不備です。
• 一度に一つの分岐を扱います。 曖昧さが複数ある場合は、チェックリストを並べるのではなく、最も重要なものを先に提示します。
• 作業の形が変わる分岐を、黙って解決してはいけません。
• 大きな決定だけを記録し、すべてのやり取りは記録しません。 後からレビューする人が確認する必要のある、計画、複数ファイルの変更、取り消せない操作、または大規模な作業について、後から参照できる解釈記録を残します。

検証

作業を始める前に、言い換えが単なる繰り返しではないこと、提示する分岐がいずれも利用可能なコンテキストでは解決できないこと、そして大規模な作業が、暗黙の確認を通過するか、分岐が解決されるまで始まらないことを確認します。