Critical Thinking

目的

相手の言うことを正しく理解し、そのうえで相手を助ける。この skill は、相手を問いただすためのものではない。

誤解は、確かめたつもりの前提が誤っているときに起きやすい。誤った前提のまま返信や方針を出すと、あとで「実は誤解していました」と取り消すことになる。そこで、結論を出す前に、結論が頼っている前提を批判的に検討する。

使うタイミング

相手の発言、資料、コード、ユーザーとの合意をもとに返信や方針を出すときに使う。場面は限定しない。

次の場面は誤解が起きやすいため、ユーザーに言われるのを待たずに使う。

PR のレビューコメントへの返信や、指摘への対応を考えるとき
方針を決めるとき。ユーザーに示した論点への答えをもとに、作業を進めるときも含む

方針とは、ユーザーの判断が必要な事項の決め方を指す。例えば、利用者から見える振る舞い、公開インターフェース、互換性、データの扱いが当たる。既存の仕様やコードから判断できる技術的な事項は、方針に含めず、自分で決める。

それ以外の場面では、ユーザーから呼び出されたときに使う。

次のことには使わない。

ユーザーがやりたいことの良し悪しを問う
やりたいことの背景を聞き出す
不具合の原因を調べる

Workflow

結論が頼っている前提を書き出す
前提を確かめる
確かめきれない前提を見極める
返信や方針を出す

手順 1 で書き出した前提のうち、誤っていても結論の変わらないものは、確かめずに進めてよい。ユーザーとの合意の確認は省かない。

1. 前提を書き出す

出そうとしている返信や方針が頼っている前提を書き出す。前提は、次の 3 種類に分けると見つけやすい。

相手の意図: レビュアーやユーザーが何を求めているか
事実: コード、仕様、ツールがどう動くか
合意: ユーザーが何を決め、何をまだ決めていないか

ユーザーやレビュアーの発言にも、取り違えやすい前提は含まれる。例えば「この値は必ず渡される」「この関数はどこからも使われていない」などの言い切りが、それに当たる。発言した人を疑うのではなく、発言に含まれる事実を確かめる。

2. 前提を確かめる

確かめたと言えるのは、原文、コード、実際の動きを直接見て裏づけたときだけとする。推測でつないだだけの前提は、確かめていないものとして扱う。

次の場合は、確かめたつもりでも確かめていない。

記憶や要約をもとにしていて、原文を読み直していない
名前やコメントから振る舞いを推測しただけで、処理を読んでいない
「〜のはず」でつないだ箇所がある
最初に思いついた解釈と合う根拠だけを集めた

最初の解釈とは別の読み方を、少なくとも 1 つ考える。別の読み方を否定する根拠が見つからなければ、最初の解釈は確かめられていない。

レビューコメントでは、次を確かめる。

スレッドのすべての発言を、最後まで読んだか
コメントが付いた行と、その時点のコードを読んだか
問い、修正の依頼、提案のどれか
修正案が書かれているか。書かれていれば、その案で何が変わるか

例えば「なぜ X にしたのですか」という書き方には、修正案が書かれていない。この場合は、修正の依頼ではなく理由を知りたいという問いの可能性がある。修正の依頼と決めつける前に、別の読み方を否定できるか確かめる。

ユーザーとの合意は、次のように扱う。

合意とは、ユーザーが依頼や会話で明示した事項か、提案を承認した事項を指す
ユーザーに示した論点のうち、答えがなかったものを未合意とする
一部の論点への答えを、残りの論点への承認とみなさない
ユーザーに示していない事項は、未合意の論点に含めない。ユーザーの判断が必要なら、新しい論点として示す

ユーザーは長い文を読むと、答えやすい論点から答えるため、答え漏れが起きやすい。答え漏れを責めず、未合意の論点だけを短く聞き直す。

3. 確かめきれない前提を見極める

確かめきれない前提とは、確かめる手段がないか、確かめても読み方が 1 つに決まらない前提を指す。そのうち、違っていたら結論の変わる前提だけを、ユーザーへ示す対象とする。

確かめた前提の一覧や、確かめた経緯は、ユーザーに見せない。ユーザーには、判断に必要なことだけを読んでもらうため。ただし、推奨や結論の理由になる事実は、理由として短く書く。

4. 返信や方針を出す

確かめきれない前提があれば、返信案や方針の前に、前提ごとに短く示す。その文を読むだけで、ユーザーが調べ直さずに判断できる形で書く。

前提: レビュアーは X の削除を求めている
確かめきれない理由: 「X は不要では」とだけ書かれ、修正案がない
違った場合: 削除せず、X が必要な理由を返信する

相手の意図を読み切れないときは、返信案で断定しない。自分の読み方を短く示し、それで合っているかを相手へ確かめる文面にする。

「X は使われていないので削除してほしい」という意味で合っていますか。
Y の処理から呼ばれているため、残す必要があると考えています。

未合意の論点があれば、その論点に関わる作業を進めない。未合意の論点だけを、選択肢と推奨を添えて短く聞き直す。

前提が誤っていたと分かったとき

作業の途中で前提の誤りに気づいたら、その前提に頼った作業を止める。次のことを短く伝え、ユーザーの判断を待つ。

誤っていた前提と、正しい事実
それによって変わること
誤った前提で加えた変更と、その状態。状態は、未 commit、commit 済み、push 済みのどれかで書く

誤った前提で加えた変更は、勝手に取り消さない。取り消すかどうかはユーザーが決める。判断を待つ間は、その前提に関わる作業を進めない。誤った前提で書いた返信案や方針は、そのまま使わない。

すでに送った返信が誤りを含む場合は、訂正の文面を返信案として示す。送るかどうかはユーザーが決める。

やり取りの書き方

相手の言うことを理解するための確認として書き、問いただす書き方をしない
確かめた前提の一覧や、確かめた経緯を並べず、判断に必要なことだけを書く
1 文に 1 つのことを書き、前置きを省く
専門用語や内部の事情を前提にしない

Rules

結論を出す前に、結論が頼っている前提を確かめる
原文、コード、実際の動きを直接見ていない前提を、確かめたものとして扱わない
ユーザーやレビュアーの発言に含まれる事実も、自分で確かめる
答えのない論点を、合意とみなさない
確かめきれず結論が変わる前提だけを、ユーザーに短く示す
相手の意図を読み切れないときは、断定せずに確かめる
誤った前提で加えた変更を、勝手に取り消さない
ユーザーの確認なしに、レビューへの返信を送らない

critical-thinking

SKILL.mdskills/critical-thinking/SKILL.md