概要
本記事は情報提供を目的としたブログ記事を気合を入れて書くときに、私が避けている点を集めた tips 集だ。 読者のブログ執筆の助けになれば幸いだ。
最後の仕上げとして記事のテーマを決めない
記事を書き始める前には、自分が何のために何の情報を伝達したいのかしっかり決めなければならない。 私はＩＴエンジニアなのでプログラミングの比喩を挟むのだが、プログラミングではプログラムが満たすべき仕様とそれをどう実現するかの詳細である実装はしばしば別物と捉えられる。 仕様がなければどんな実装が目的を満たしているのか判断することすらできない。つまり、実装のゴールや正解がどこにあるのか分からない。実装に先立ち仕様が決まっているべきなのである。
文章執筆もこれに似ていると私は捉える。文章のテーマ・文章によって達成したい目的は仕様であり、それを満たす実装として本文を書くのだ。仕様が決まって初めて本文が推敲できる。 自分の書いた文章によって目的は達成できるのか。不足している文はないか。目的達成に寄与していない不要な文を書いていないか。文章を完成させるためにはまず「完成」の定義を最初に決めなければならない。
直線的なトピックの羅列として捉えない
伝えたいテーマの下にその根拠が5、6個雑然と並んでいる状況を考える。この5、6個が本当に並列ならこう書くしか仕方がないかもしれない。だがたいていの場合は違う構造が隠れているのではないか。
たとえば、次のような文章を考える。
西の町が雨だ。ここでは偏西風が吹いている。天気は西から東に変わる。ここの雲が厚くなってきた。厚い雲は雨の前兆である。傘を持って行った方がいい。
この文章は十分短いので理解は容易だろうが、この調子で１ページも２ページも書かれたら文章の全体像をつかむのは難しくなる。 ではどうすればいいのか。文章をトピックの羅列ではなく、大きいトピックが順に順に小さいトピックとして細かく枝分かれしていく構造（しばしば「木構造」と呼ばれる）*1で考える。 上の文章に対しては以下のような木が組み立てられる。*2
この木の枝分かれ部分構造も一緒に言語化して、構造をくどいくらいに際立たせると以下のようになる。
傘を持っていくべきだ。なぜならば雨が降りそうだからだ。根拠は２つある。まず一つ目の根拠。一般に天気は西から東に変わる。これは偏西風の影響だ。そして今、西の町は雨だ。したがってここもじきに雨になる。次に２つ目の根拠。一般に雲が厚くなってくるのは雨の前兆だ。ここら辺の雲が厚くなってきたので、これも雨が降りそうな理由だ。以上から、傘を持っていくべきだと結論する。
どのくらいくどく書くかはスタイルによると思うのだが、私は文章の構造を明徴にするためならくどく書きがちだ。
このスタイルがあまり当てはまらない文書もある。例として、今回の記事は tips 集のようなものなのであまり木構造で考えておらず、リスト形式で大枠を作っている。
先頭から順に書き始めない
上の木構造を仮定した場合、先頭から順に文章を書き始めると、木の大元に近い重要度の大きい話と木の末端に近い重要度の小さい話を激しく行き来しながら執筆することになる。 私はこの書き方をすると全体の構造を見失ってしまい文章の目的を合致する構成が作りづらい。
その代わり私は先頭から順に木構造でアウトラインを書く。なるべく重要度の高いトップの項目を書き、それをより細かい項目に分け、さらに細かく分け... みたいな要領である。
markdownであったら # の行を最初に書き、全体の構成が変でないか眺め、 # の中の ## の行を書き # の主張を補強できているか眺め、それから地の文を書き始める... といった具合だ。
結論を最後だけに書くない
結論がわからないまま話を進めると、読者はどこに連れていかれるかわからない状態が長くなって話の骨格（木構造）を見失いがちになる。なのでゴールを最初に示す意味で各枝分かれ部分の 結論・要約はセクションの最初に書く 。
黙読だけで済ませない
私の経験だが、声に出して読み上げてみるとリズムがおかしいところ、文がまどろっこしいところ、誤字脱字などに気づきやすい。なので、積極的に 音読 している。
まとめ
情報提供を目的としたブログを書くにあたって私が気を付けていることの tips を紹介した。肯定形で書き直すと以下のとおりである。
- 文章のテーマ・目的は最初に決める
- 文章を木構造で捉える
- ノードの構造を根本から順に書き始める
- 結論を最初に書く
- 音読して確かめる
もちろんこの書き方が馴染まないであろう分野もある。たとえば随筆や日記などに対してこういう書き方が straightforward に適用できるような気はあまりしない。読者のみなさんがブログ記事作成の上で気を付けていることがあったらコメントで共有してほしい。
