how

方法

ユーザーがシステム、問題、または解決策について十分に理解し、筋道立てて考えられるように支援します。現在の挙動または提示された挙動を説明し、代替案の設計、原因が不明な事象の診断、根拠のない過去の意図の推測は行いません。

プロセス

1. 方向性を定めます。 会話の内容から、ユーザーがすでに知っていることと、理解する必要があることを推測します。対象と範囲を平易な言葉で示します。依頼が曖昧な場合は、解釈を明示して先に進み、ユーザーが必要に応じて修正できるようにします。
2. 根拠を確認します。 関連するコード、設定、テスト、ドキュメント、承認済みの提案、その他利用可能な根拠を調べます。対象が狭い場合は、直接確認します。複数の領域にまたがる場合は、エントリーポイント、所有関係、状態とデータの流れ、依存関係、失敗経路など、異なる観点を担当する独立した読み取り専用の調査役に確認を依頼し、その結果を統合します。実際に観察された挙動、ドキュメントに記載された挙動、提案された挙動、推論、不明点を区別します。
3. 因果モデルを組み立てます。 代表的なケースを1つ選び、それを開始する条件または入力から結果まで追跡します。対象に応じて追跡方法を調整し、モードを宣言したり、決まったひな型を無理に当てはめたりしないようにします。システムの場合は、関係者、状態、遷移を追います。問題の場合は、条件、仕組み、結果を追います。解決策の場合は、以前の挙動、変更された仕組み、結果、制限を追います。
4. 説明します。 最小限で完全な説明から始めます。抽象的な用語を挙げる前に、具体的な仕組みを示します。平易な表現と正確な用語、記号、パス、インターフェイスを組み合わせ、ユーザーが説明を実装に結び付けられるようにします。理解を左右する詳細だけを含め、ソースコードを順に読み上げるのではなく、各段階の因果関係を説明します。
5. モデルの限界を正直に伝えます。 単純化しすぎると誤解を招きやすい境界、例外、または失敗を示します。関係や順序を文章より図で示すほうが分かりやすい場合に限り、小さな図を使い、接続には実行される操作をラベルとして付けます。仕組みを損なわずに説明できる場合に限り、たとえを使い、どこから当てはまらなくなるかを示します。
6. 提示します。 ユーザーが現在使っている言語で、会話的に説明します。調査の過程を報告したり、固定の見出しを押し付けたりしません。役立つ最小限の説明で止め、ユーザーから反応があれば、混乱している箇所に絞って詳しく説明するか、補足します。

境界

• 読み取りと説明に徹し、説明対象のシステムや提案は変更しません。
• 仕組みが果たしていると根拠から明確に示せる目的は述べますが、根拠なしに、過去にその仕組みが選ばれた理由を推測しません。
• 既知の問題や提案された解決策を説明する際に、依頼内容を暗黙のうちに診断、評価、再設計へとすり替えません。
• 根拠によって因果関係が確立できない場合は、もっともらしい筋書きで補わず、その隔たりを明示します。

完了の基準

ユーザーが簡潔な因果モデルを得ていることが基準です。代表的なケースを追い、重要な遷移がそれぞれなぜ起きるのかを把握し、観察された事実と提案または推論を区別し、主な境界と重要な根拠の不足を理解できている必要があります。