分かりやすい文章の書き方（本質論）

## 本記事の要約
文章を分かりやすくするためには、文章の前に、まず文章が表す「情報」を構造化したほうがよい、という話。

## なぜ文章を分かりやすくすべきか
「分かりやすい文章の書き方」を解説した本やネット記事は、そのほとんどが「分かりやすい表現の仕方」について解説するものである。一文は短く、結論を最初に、主語と述語を対応させる、等々。しかし考えてみてほしい。読み手はなぜ「文章を読む」というアクションを起こしたのだろうか。それは、自分が知らない情報を知りたいからである。**読み手は「情報」を得たいから文章を読む**のであって、**あなたの文章を読みたいから読んでいるわけではない**。読み手にとっては、文章表現そのものよりも、文章が表す「情報」のほうが関心事なのである。

情報伝達とは「自分の脳内にある情報を、相手の脳内にコピーすること」である。残念ながら我々はエスパーではないので、相手の脳内へダイレクトに情報を転送することは不可能である。そこで文章を媒体として、自分の脳内にある情報を相手の脳内に疑似的にコピーするのである。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51871/2ae653d4-d039-7391-6730-a695d046bde0.png) ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51871/da9ffae0-7b03-cf79-32a7-659d8095df0d.png)

この時、自分の脳内にある情報Aと、相手の脳内にある情報Bにおいて、AとBのギャップが小さいほど「情報が正確に伝わった」と言える。我々はこのギャップの解消を目指して「文章」を分かりやすく書こうと努力する。DNAという設計図をもとに人体が構築されるように、文章は、相手の脳内で情報を再構築するための唯一の設計図だからである。

## 「情報」に意識を向ける
プログラムコードは読みやすく書かれるに越したことはないが、現実は、プログラミングのセンスの無い人間が設計する立場にいることが少なくない。仕様自体がスパゲッティであれば、その仕様を表現したプログラムコードをいくら弄っても、**ちまちまとした盆栽の剪定作業に終始**するのみで、本質的なソフトウェアの複雑性は解消されない。コードをリファクタリングする前に、仕様をリファクタリングする必要があるだろう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51871/62ebbbe7-b979-21b0-6855-da0ff477c0e7.png)


文章を分かりやすく書こうとする時も、我々はつい文章をあれこれ弄りがちだが、じつは文章の前に「情報」を分かりやすく構造化する必要がある。文章をブラッシュアップする際、我々は何時間も文章とにらめっこして、もっと気の利いた言い回しを探しがちだが、「文章」へ意識が誘導されてしまっている状態ではブラッシュアップは小手先のものになりやすい。思い切って、文章を削除してしまって「情報」に意識を集中したほうがよい。

では、「情報を分かりやすく構造化するノウハウ」は何だろうか。一般の文章ハウツーは、そのほとんどが文章表現のハウツーであって、文章以前の「情報」の構造化について触れられているものは（自分が知る限りでは）無い。なので既成のノウハウには頼らず、自分が今まで習得してきた概念モデル（数学の集合の概念、具体と抽象、二項対立、MECEなど）を使い倒して、プログラムコードを書くように情報を構造化することをお勧めする。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/51871/c51a1428-2bb7-23ce-0b77-1c6e17f2b0d7.png)

ところで、「情報を構造化する」と聞いて、PREP法やパラグラフ・ライティングなどの文章構成法を思い浮かべた人もいるかもしれない。ここで言う情報の構造化とは、そうしたフォーマットではなく、フォーマットにはめ込むコンテンツの構造化を指している。例えば、PREP法にしたがって、結論、理由、具体例、結論の順で構成したとする。これにより「どこに結論が書かれているか」が一目瞭然になったが、結論や理由、具体例の中身そのものの分かりやすさの度合は変化しない。お弁当箱に仕切りをつけて、ごはんやおかずを綺麗に整理したとしても、ごはんやおかずそのものが美味しくなるわけではないのと同様である。中身は中身で、分かりやすく表現するための工夫が必要である。その工夫が、上記で示した概念モデルの利用である。

## 言語化する、推敲する
情報が構造化できたら、つぎにその情報を言語化する。言語化の段階では、文章のネタを書き留めたうえで、あーでもない、こーでもない、とネタの位置を入れ替えたり、退屈なネタ、文章のキーメッセージにとって不要なネタを差っ引いていく。

つぎに推敲だが、プロのライターも口をそろえて言っているように、推敲は「自分が書いた文章を音読してみる」のを強くおすすめする。不思議なことに、冗長だったり、論理展開がおかしかったり、情報価値が薄い退屈な箇所を通過するとき「ひっかかる」感覚がある。他にも、Webブラウザの自動音声による読み上げ機能を利用したり、書いた文章をA4用紙に印刷して第三者目線で読んでみることも推敲の精度を上げるのに役立つ。

また、本題と関係が薄い情報は積極的に削除したほうがよい。「せっかくだから残しておいた」「念のため書いておいた」部分は文章読解のノイズになるからだ。せっかくのネタを削除してお蔵入りするのが勿体ないと感じるのは人情だが、思い切って削除してみると、Tシャツ一枚になった時のような爽快さを感じるだろう。これも削除前の文章と削除後の文章をそれぞれ音読してみて、違和感の有無を比較検証するとよい。

他にも削除したほうがよいものを、以下に示す。
* **知識のひけらかし**。自分が書きたいことではなく、相手が知りたいことを書くべきである。
* **自明な主語**。しっかり主語を明示する親切心は良いことだが、自明な主語をあえて書くと、くどい印象を与える。
* **無くても意味が通る接続詞**。特に「なぜなら」「つまり」は、意外と無くても支障は無い。
* **文を繋ぐ以上の役割がない「そして」**。読み手は接続詞を手掛かりに展開を予想するので、意味の広い接続詞は読み手を迷わせる。接続詞を置くなら「なぜなら」「したがって」など意味の狭い接続詞に変える。
* **並列関係でない「また」**。文を繋ぐ目的だけで「また」を使用しない。
* **アニメや漫画などのネットミーム**。内輪受けのジョークは外野から見ると寒い（ごめん）。「いつから〇〇だと錯覚していた？」とか言って喜ぶのが許されるのは小学生までだよね！
* **何も言ってないに等しい結論**。「政府は一丸となって、この課題に真摯に取り組むべきだ」といった、あくびが出るような締めの文は新聞の社説でしばしば見かけるが、取り組むべき問題だからこそ社説のテーマとして取り上げたのだろう。読み手に新情報を提供しないなら、書かないほうがよい。
* **「〇〇すぎる」**。「食べすぎは体によくない」など。「適切量を超えた量を食べることは適切でない」は恒真命題である。

逆に「読み手にとって必要な情報だが、しばしば書き忘れがちなもの」を以下に示す。
* **具体的な動作**。「対応をお願いします」など、読み手にアクションを依頼する文章では、具体的な動作が想像できるように書く。
* **その話題を取り上げる至った背景**。なぜ今、この話題をしているのか背景を書く。背景が無い文章は、読み手にとって唐突である。読み手にアクションを依頼する文章も、読み手がそのアクションを起こさなければならない理由を書く。
* **抽象語の（その文章内で閉じた）定義**。「焼肉」「体重計」などの具象語について書き手と読み手との間で定義にギャップが生まれることはまずないが、「連携」「処理」「適応」などの抽象語はそうではない。抽象語は、その文章におけるローカルな定義を示す必要がある。

## 分かりやすい文章を書くためのトレーニング
精神論になってしまうが、分かりやすい文章を書くには、ノウハウよりも「相手に情報を正確に分かりやすく伝えたい」という心的指向性が大切なのではないかと思う。僕は文章を書くのが好きな方であるが、文章を書くというよりも「相手に解釈の負担を与えず、情報をいかに正確に無駄なく伝達できるか」を競うゲームとして楽しんでいる。仕事で書くメールや報告書、サービスデスクへの問い合わせや、顧客問い合わせへの回答も、情報伝達ゲームとしてとらえると、楽しく文章力を向上させることができるのでオススメである。プログラミングと同じく、文章の上達も筋トレ的な側面があるので、実践の中で自分なりの気づきを得てスキルアップしていくのが近道だと思う。

## まとめ
* 文章とは、読み手の脳内に情報を再構築するための設計図である。
* 文章を分かりやすくするためには、文章の前に「情報」を構造化したほうがよい。
* 推敲には音読が有効である。
* 削除できるところは積極的に削除したほうがよい。
* 日常の文章作成を情報伝達ゲームとして楽しむ。