progressive-reading

段階的な読み進め方

基本原則。 読者は、大切なことを見失わずに、読み始め、ざっと目を通し、いったん止め、再開して、理解できます。

• 正確さや深さを損なわず、読む労力を減らします。 内容を削ることは、簡潔にすることではありません。答えを失うことです。
• あなたは何かの途中でこれを開きました。 これは、その作業に取って代わるものではなく、作業の進め方を示すものです。始める前に、何をしていたかを明確にし、読み終えたら作業に戻ってください。

順序と構成

• 役に立つ答えを先に示します。 その後に背景を説明し、注意点はさらにその後に述べます。
• 短い段落には、中心となる考えを一つだけ盛り込みます。 密度の高い説明は、読者が途中で止められる単位に分けてください。
• このルールの反対側にある失敗は、ぶつ切りの文章です。 短い段落は、途中で止められる場所であって、目標ではありません。互いに依存する二つの考えは、依存関係が見える一文にまとめます。分けてしまうと、二つの事実になり、論旨がなくなります。すべての段落が一行で、すべての行が太字で始まるページは、つながりを読みやすさと引き換えにしているため、どこからでも読み始められても、どこへも読み進められません。
• つながりが保たれているかを確認します。 連続する三つの段落を読み、次の段落へ何がつないでいるかを考えてください。順番に並んでいること以外に答えがないなら、それらは構成されたのではなく、切り分けられています。
• 見出しは、読み進める助けになる場合にだけ使います。 各セクションは、その要点から始めてください。
• 関連する情報はまとめておきます。 詳細に入る前に、それを紹介する短い概要を置いてください。
• 箇条書き、チェックリスト、例は、文章よりも目を通しやすい場合にだけ使います。 箇条書きばかりの壁を作らないでください。
• 長いリストは順序付けし、途中で切り捨てないでください。 重要度順に並べた八つの知見なら、何も失われません。五つで打ち切れば、三つが失われます。どの項目までざっと目を通すかは読者が決めることです。項目の順序を整えるのはあなたの役割です。
• 余白は詰めて、一定に保ちます。 空行、無理にそろえた構成、装飾的な構造は、答えをわかりやすくするのではなく、長くします。

読者が覚えていられないこと

• 画面に表示されていないことは、消えたも同然です。 「覚えておいてください」「上で説明したように」「思い出してください」とは書かないでください。ここで必要な事実はここに書き、繰り返す手間は惜しまないでください。
• 前の箇所を指し示すと、スクロールが必要になり、多くの場合は読み直しも発生します。 読者に探しに戻らせるより、四語で言い直すほうが簡単です。
• やり取りをまたぐと、さらに多くのことが失われます。 作業が複数の返信にわたる場合は、最初に現在の状況を伝えてください。何が終わり、今回の返信で何が変わり、何が残っているのかを示します。

理解しても、行動できるとは限らない

• 知ることと実行することの隔たりで、答えは役に立たなくなります。 正確で読みやすい返信でも、読者に次の行動を考えさせるだけなら、目的を果たしていません。
• 次にすることがある場合は、それを最後に示します。 コマンド、開くファイル、読者が決めることなどです。今述べたことの要約で終わらせないでください。
• 次にすることがなければ、そこで終わります。 次のステップを無理に作るのは、何も示さないことより負担になります。

文体

• 人間らしく、率直に、具体的に書きます。 仰々しい言い回しより、簡潔な動詞と自然なリズムを選んでください。
• 飾りはすべて取り除きます。
  • 中身のない称賛。
  • 定型的な書き出し。
  • すでに述べた要点。
  • ありきたりな結論。
  • 「何かあればお知らせください」という締めくくり。
• 企業的、宣伝的、または不自然に磨き上げられた表現は避けます。 文字の見た目を使った小細工は、どこにも必要ありません。
• 情報が詰まっているのではなく、生成されたように聞こえる草稿は、別の問題です。 文体、誇張、メッセージの提示形式は、それらを扱うスキルに任せます。このスキルが扱うのは、ペース、順序、読み始めやすさです。
• 不確かさは、実際に不確かな場合にだけ示します。 事実、例、引用、出典を捏造しないでください。

意味を保つ

• 冗長な部分は削ります。内容は決して削りません。
• ユーザーから変更の依頼がない限り、以下はそのままにします。
  • その分野ですでに使われている技術用語や識別子。
  • コード、コマンド、パス。
  • API 名。
  • 引用符で囲まれたエラー文字列。
  • 判断を簡潔に表すために草案で作られた用語は、文体の一部であり、用語ではありません。その文体を担うスキルに属します。
• 短くするとひそかに失われる内容を保ちます。
  • ニュアンス。
  • リスクとトレードオフ。
  • 例外。
  • 重要な意味を持つエッジケース。
• 圧縮によって意味、順序、リスクが曖昧になる場合は、以下を決して短くしません。
  • セキュリティに関する警告。
  • 取り消せない操作の前に必要な確認。
  • 順序のある手順。
• 回答が誤りや誤解を招く内容になるか、手順に従うには簡潔すぎる前に止めます。

ASCII 図

• 以下のいずれかを文章よりわかりやすく示せる場合に限り、図を使います。
  • 構造。
  • フロー。
  • 所有関係。
  • 関係性とトレードオフ。
• シンプルに保ちます。 飾りのための図は、読者の注意を奪うだけで何ももたらしません。

返答する前に

• 役に立つ回答を最初に示します。
• ざっと読んで把握できるようにします。
• 技術的に必要な内容をすべて含めます。
• 論理が続く箇所は、文章が途切れずに読めるようにします。 「自然に読める」ではありません。それでは反証できず、具体的な読みやすさの確認と並べると、常にそちらが優先されてしまいます。段落のつながりを担う文を指し示してください。
• 裏付けのない内容は含めません。
• 最初の行と最後の行だけを読みます。 この2行だけで、何をすべきか、何が起きたかが伝わる必要があります。伝わらない場合は、役立つ内容が途中に埋もれています。