以前、『数学文章作法 基礎編』の記事を書きました。
【感想】『数学文章作法 基礎編』――論文やレポート、数式やコードの説明における読みやすさとは - LEFログ：学習記録ノート
今回は、その続編である『数学文章作法 推敲編』（以下『推敲編』とします）を取り上げたいと思います。
TL;DR（結論）
正確で読みやすい文章こそが、自分の考えを読者に伝えられます。
そのためには推敲時に、次の要素を意識することが重要です。
- 読者を迷わせない文章にする
- 客観的な視点で読み返す
- 余計な情報を削る
- 足りない情報を付け足す
- 文章全体のバランスを考える
- 他の方にも読んでもらう
「簡潔で読みやすい文章」かつ「誤解されない正確な文章」を両立させることが、推敲の一番のポイントです。
次の節では、自分（LEF）にとって学びが多かった箇所をピックアップしつつ、自分なりにまとめたいと思います。
読みづらい文章とは？
どんな文章が読みづらいかを考えたとき、基本的には次の３つの要素に分類できると思います。
- 一文一文が長すぎる
- 複数の意味を取れる
- 説明が足りなすぎる
一番分かりやすいのは、「一文一文が長すぎる」です。あるいは、余計な情報が多すぎるときも、読みづらく感じます。
そのため、迷ったらまずは削ることを意識したいと思いました。
まずは削ってみる
『推敲編』では、次の４つの例を削除すべき対象として挙げていました。
- 意味の分からない文章
- この文章には不必要な言葉
- 無意味に繰り返した言葉
- 主張をぼかす言葉
本書から、具体例をひとつ引用してみたいと思います。
［改善前］
Factory Methodパターンでは、スーパークラスの側でインスタンスの生成の方法およびどのような種類のインスタンスを作るかを定義していますが、生成するインスタンスの具体的なクラス名は定めません。
この文章は正確です。もし具体例として提示されていなければ、問題ないと思ってしまいそうです。
しかし、文章を追いかけていて、脳にスッと入ってこないような気もします。
次に、改善後の文章を見てみましょう。
［改善後］
Factory Methodパターンでは、スーパークラスでインスタンスの生成法を定めます。しかし、具体的なクラス名までは定めません。
改善後の文章は、改善前の正確さを保ちつつ、簡潔で読みやすい文章に変わっています。文章を読んだとき、脳でイメージを描きやすい文章になっています。
この改善によって「詳細さ」は少し失われてしまったかもしれません。しかし、読者が読みやすい文章（意味が伝わる文章）という点では、改善後のほうに軍配が上がると思いました。
表現方法を変えてみる
文章を削った結果、逆に読みづらくなったり、正確さが失われる場合もあります。
その場合は、表現方法を変えてあげれば良いことが分かりました。
例えば、「それぞれ」「同士」「一種」という便利な語句を使ったり、鉤括弧（これのこと→「」）を使うことで文章にメリハリをつけることもできます。
また、個人の主観ではなく客観的なデータに基づくように、定量的表現*1を使うことも大事だと分かりました。
他にも、否定文を避けたり、語順を変えてみたりするだけでも、文の印象は変わってきます。
［改善前］
［改善後］
『リーダブルコード』の「7.2 if/elseブロックの並び順」でも出てきましたが、否定文はコードを読むうえで、思考を停滞させる恐れがあります。
条件は否定形よりも肯定形を使う。例えば
if (!debug)ではなく、if (debug)を使う。
自然言語においても、コードにおいても、否定形を使うときには気をつけようと思いました。
付け足してみる
「文を削る」「表現を変える」でも、文章が読みやすくならない場合はあります。また、正確さが失われる場合もあります。
そのような場合は、「付け足す」必要があることが分かりました。
主語を補うとき
日本語では、文に主語がなくても意味が通ることがあります。しかし、主語が抜けている文は、誤解を生んでしまいます。
［改善前］
待ち行列を介してデータを渡します。データを入れようとしたとき、もしも空き領域がなかったら待機します。データを取り出したところで再開します。
［改善後］
スレッドAは、待ち行列を介してスレッドBにデータを渡します。スレッドAが待ち行列にデータを入れようとしたとき、もしも空き領域がなかったら、スレッドAは待機します。スレッドBが待ち行列からデータを取り出し、空き領域ができたところで、スレッドAは実行を再開します。
改善後は文章が長くなっていますが、読みやすいです。
これは、主語を明確にしたからです。
以前、別の本で次のような一節を目にした記憶があります。「英訳しやすい文章は、日本語でも読みやすい」。この観点で改善前の文章を読んでみると、英文に訳しづらいことが分かると思います。
また、「スレッドA」と「スレッドB」という２つの主語が登場しています。動作を行っているのがそれぞれ別のスレッドであることを明示しているため、更に分かりやすくなっています。
疑問を解消するとき
あまりにも文章が簡潔すぎると、複数の解釈を持ってしまう場合があります。
例えば、本書では次の例が示されていました。
スイッチａは、スイッチｂと同時にオンにしてはいけません。
この文はとても分かりやすいです。
しかし、もしもこれだけしか書かれていないと、次のような疑問を抱かせてしまうと書かれていました。
- スイッチｂはダメだけど、スイッチｃの場合なら、同時にオンにしても良いのだろうか？
- スイッチａとスイッチｂを、時間差で両方ともオンにするのは可能だろうか？
こうした疑問の解消が重要であれば、情報を付け足すことが必要です。
ただし、補足説明が長すぎると今度は主旨が不明瞭になってしまいます。その辺りのバランスは、匙加減が大切であることも理解しました。
バランスを考える
文章のバランス
「理由・具体例・結果」がそろっていると、文章のバランスが整っているそうです。
確かに理由がないと、その文章の説得力が無くなってしまいます。根拠を示すことで、相手に信頼を持ってもらえます。
具体例があると、読者が理解しやすくなります。
自分はプログラミングの学習をする際、公式ドキュメントを読むことが多いですが、実際のコード例が書かれているほうが、素早く情報をキャッチアップできています。
具体と抽象を行き来することで見えてくる概念もあります。そのため、具体例を提示することの重要性を再認識しました。
結果は、「結論」とも言いかえられます。
このブログ記事だと、最初に「TL;DR（結論）」の見出しを作りました。全体として何を伝えたいのか・何が書かれているのかを明瞭にするためです。
分量のバランスと品質のバランス
今自分はこのブログ記事を書いているのですが、その際にも分量のバランス・品質のバランスについて考えています。
分量については、「このブログ記事は、最後まで読み通すうえで長すぎないか」とか「それぞれの節ごとの文章量は同じくらいだろうか」とか「見出しや強調箇所を読んだだけで理解できるか」とか、そうしたことも意識しながら書いています。
品質については、「それぞれの節で具体例を提示できているか」や「表現に重たいところはないか」を意識しています。ブログは基本的に読み飛ばされるものなので、斜め読みにも耐えられるように作りたいと思っています。
この本では、分量と品質、その両方の推敲について、具体的な方法が載っていました。
しかし、頭では分かっていても、実践するのは難しいです。
このブログ記事だと、「記事の最初のほうに箇条書きが集中しちゃってるな～。でも箇条書きをやめると、もっと読みづらくなるな～」という葛藤がありました。
時間が無限にあれば、徹底的に推敲して最上の文章を目指すべきですが、どこかで「えいやっ」と区切りをつける必要があります。
この本では、「第７章 推敲のコツ」「第８章 推敲を終えるとき」という章があり、その内容も参考になりました。
レビューして頂く
GitHubでのPull Requestもそうですが、自分の文章（コード）を、他者に読んでいただいて初めて分かる気づきがあります。
例えば、単純な誤字・脱字、事実誤認、誤解を生みそうな箇所、意味が取れない箇所について、アドバイスを頂くことができます。
自分で書いた文章は、言外の意味（行間）を、脳が勝手に補完してしまいます。客観的に読もうと思っても、そこには限界があります。執筆してから時間を開けたほうが、自分の文章の間違いに気づきやすいのはそのためです。
他の方に読んでいただけば、真に客観的な視点から文章を評価していただけます。自分が書いたわけではないので、思い入れもなく、「この文章は要らないかも？」ということを遠慮なく教えてくれるかもしれません。
ただし、誰かにレビューを依頼するときには、次の３つが大事であると分かりました。
- 謙虚
- 信頼
- 責任
これらについて、簡単にまとめてみます。
コメントは謙虚に受け止める
「この文章は要らないかも？」とコメントを頂いたとします。
そのとき、そのコメントから、必要以上の解釈をしてはいけません。疑問は疑問であり、文章そのものに向けられています。
勝手に脳内で「これは自分に対する批判ではないか」と解釈するのは間違っています。
レビューは、より良い文章のためのアドバイスです。文章を変更するにせよ、そのままにするにせよ、謙虚に・理性的にコメントを聞くことが大切です。
信頼関係が大切になる
上記の「謙虚であること」とも関係します。
レビューする側も、される側も、お互いを信頼する必要があります。
これは最近読んだ『小さなチーム、大きな仕事』にも書かれていましたが、信頼関係が築けていないと、レビュー（指摘）することができなくなります。
言い換えれば、お互い「批判」だと誤解されるのが怖くて、ありきたりなやり取りしかできなくなります。
良い文章のためには、率直なコメントが欠かせません。だからこそ、信頼関係を築くことが重要になります。
最終的な責任は筆者が負う
自分の文章に対して、誰かからアドバイスを頂いたとき、それをそのまま鵜呑みにして反映するのは危ないです。
あくまでその文章を書いているのは「筆者」であり、「レビューしている方」ではありません。
どのコメントを取り入れて、どのコメントを取り入れないか。反映する・反映しないの判断を筆者が負うからこそ、その文章はまとまりを持ちます。
文章の全体像を知っている「筆者」だからこそ、フィードバックの反映は見極めなければなりません。
素直に意見を聞きつつ、どの程度フィードバックするかは、文責を持つ筆者にゆだねられているということが分かりました。
おわりに
自分はあまり推敲が得意ではない気がします。
というのも、推敲をする暇があったら、もっと新しい情報を取り入れたいと思ってしまうからです。
しかし、そもそも文章を書くということは、他者に読んでもらうために行います。読みづらくて、誰にも読んでもらえない文章をアウトプットするくらいなら、アウトプットしないほうがマシかもしれません。
せっかくアウトプットするからには、推敲して、少しでも読みやすく、正確な文章を心掛けたいと改めて思いました。
また、GitHubのPull Requestでコメントするときも、簡潔で正確で理解しやすい文章を書くように気をつけたいと思います。
*1:パーセントやグラムなどの具体的な数値
