自分の間違いを見つけてもらう使い方

• 自分では、自分の抜けが見えない
• 観点を1つ指定して、指摘だけ求める
• 指摘を読んで、直すかは自分で決める

半年使って、一番役に立っているのはこの用途だった。やり方を書く。

自分では見えない

書いたものを自分で読み返しても、抜けが見つからない。

• 書いた流れで読んでしまう
• 前提が頭にあるので、抜けに気づかない
• 時間を置いても、同じ

2つ目が原因だ。書いた本人には、省略した前提が見えない。

観点を指定する

漠然と聞くと、役に立たない。

• 「前提の説明が足りない箇所を挙げて」
• 「根拠が無い断定を挙げて」
• 「同じ内容の繰り返しを挙げて」

1つ目が最も効く。自分が省略した前提が、具体的に出てくる。

よく使う観点

一覧にして持っている観点を書く。

• 前提の説明が足りない箇所
• 根拠が無い断定
• 同じ内容の繰り返し
• 見出しと中身が合っていない箇所

4つ目も毎回使う。書いているうちに、見出しとずれる。

1つずつ聞く

まとめて聞かないようにしている。

• 1回に1つの観点だけ聞く
• まとめると、どれも浅くなる
• 順に聞いて、1つずつ直す

2つ目が実感だ。観点を並べると、目立つものだけ指摘される。

直させない

指摘だけ求めて、直させない。

• 「指摘だけ。直さなくてよい」と書く
• 読んで、直すかは自分で決める
• 直すときは、自分でやる

3つ目を守っている。全部直させると、自分の文章でなくなる。

次の内容を点検してください。表現の良し悪しには触れないでください。

探してほしいもの（この順で）
1. 事実として間違っている記述
2. 根拠を示さずに断定している箇所
3. 前後で食い違っている記述
4. 「全て」「必ず」「絶対に」のように、例外を許していない言い方

見つからない項目は「該当なし」と書いてください。

該当箇所を示させる

指摘には、場所を書かせている。

• 「該当する文を引用して」
• 場所が無い指摘は、確認できない
• 引用があれば、自分で判断できる

3つ目が目的だ。引用を読んで、納得できるか判断する。

納得できない指摘

指摘をそのまま受け入れないようにしている。

• 自分の感覚と比べる
• 納得できなければ、直さない
• 納得できないまま直すと、後で分からなくなる

3つ目が理由だ。なぜそう書いたか、自分が説明できる状態を保つ。

当たっていた指摘

振り返ると、当たっていた指摘には傾向があった。

• 前提の抜け
• 説明の順番
• 同じ内容の繰り返し

どれも形の問題で、内容の判断を含まない。

外れていた指摘

逆に、外れる指摘も傾向がある。

• 内容が正しいかどうかの判断
• 重要度の判断
• 読む人にとっての価値

どれもこちらの状況を知らないと判断できない。

コードでも使う

同じやり方は、コードでも使っている。

• 「空の入力で落ちる箇所を挙げて」
• 「件数が増えたとき遅くなる箇所を挙げて」
• 指摘を読んで、自分で確認する

3つ目が必須だ。指摘を読んだだけでは、確認したことにならない。

見落としを防ぐ使い方

確認の抜けを防ぐ用途でも使っている。

• 自分の確認項目を渡す
• 足りない項目を挙げてもらう
• 追加するかは、自分で決める

2つ目が役に立つ。項目を考えるより、抜けを指摘してもらうほうが速い。

自分の確認項目を先に作る

渡す前に、自分で考えている。

• まず、自分で項目を書き出す
• それを渡して、抜けを聞く
• 白紙から聞かない

3つ目を避けている。白紙から聞くと、一般的な項目が返る。

指摘が無い場合

指摘が出ないこともある。

• 指摘が無いことは、問題が無い証明ではない
• 別の観点で聞き直す
• 自分でも確認する

1つ目を忘れないようにしている。見つからなかっただけの場合がある。

量を絞る

一度に渡す量も決めている。

• 1記事、または1つの機能まで
• 量が多いと、指摘が浅くなる
• 分けて渡す

2つ目が実感だ。全部渡すと、目立つ箇所だけ指摘される。

この用途が残った理由

半年続いた理由を書く。

• 材料がこちらにある
• 指摘の正しさを、自分で確認できる
• 間違っていても、影響が小さい

2つ目が条件だ。確認できる作業は、任せられる。

まとめ

• 書いた本人には、省略した前提が見えない
• 観点を1つずつ指定して、指摘だけ求める
• 該当箇所を引用させて、自分で判断する
• 納得できない指摘は、直さない
• 指摘が無いことは、問題が無い証明ではない