技術記事とかを書くとき、推敲をする。僕がどういうロジックで推敲をしているかの話。
前提知識
想定読者をまず決める。この記事を読むには前提知識としてこのぐらいは知っていてね、のライン。例えばJavaの記事を書くなら基礎的な構文は分かってる前提とする、とか、マニアックな記事なら、もっと深い知識を持っている前提とする、とか。一般向けの記事だと高校までで習うような前提知識があれば良いとするとかとか。
これは、前提知識の部分なら解説なしに「知ってるよね」の前提で話をする。知ってるかどうか危うい時はちょっと注釈をつける。知らない想定の部分は丁寧に解説をする。そのラインを決めるのが想定読者の前提知識。
知識は前提知識の上に積みあがる。積み重ねていく積み木のようなもので、この記事は既にここまで積んである人に対して、追加で何個の積み木を積ませよう、みたいな目標を定める。
記事内での時系列と積み木
記事と言うのは上から下に読まれる。方向があり、読者は上から下に読む。下から読んでも構わないがそういう読者は対象外なのでそういう読者への配慮はしない。
上から順に読んだ場合、記事の中でも知識が積みあがっていく。一段落目で説明したことは二段落目で使っても良い。一段落目で積み木を積んだから、二段落ではその上に何かを積んでも良い。
でも、逆はダメ。
プログラミングで言えば、宣言せずに初期化せずにいきなり変数を使うようなもので、これはコンパイルエラーにならなくてはいけない。自然言語はコンパイルできないのでしょうがないから自分で推敲してエラーとして処理しなければならない。
推敲のロジック
技術記事であることを説明しようとする場合、この前提知識の積み上げを意識する。
枕の話として、Aを解説し、Bを解説し、AとBが揃えばCを解説でき、Cを前提知識としたDについて語れる、といった具合に。
文章の上から下に向かって順に積んでいくようになっているか？唐突に未解説の概念を投入していないか？
こうしたことをチェックするためには、自分が知っていることを「知らない体」で読み返す必要がある。自分が書いた文章なら当然自分は結末まで知っている。知っているのだけど知らないことにして、ここでこのAの概念が出てきた、ここで読者はAを知る、ここでCの概念が出てきた。おや？Cの前提のBの解説がされていないな？などとやる。
この宣言順の前後チェックをしっかりやる。そのうえで、それらの前提知識で自然な論理展開にできているか？などを考える。前提知識の積み木が正しく積みあがっているか？を検証するだけでも文章はずっと良くなる。
雑誌記事などはかなり気合を入れて推敲をする。ブログ記事は割と適当。Twitterなんかは思い付きで散文を書いている。
