見出し画像

理工系のためのよい文章の書き方 読書ノート 後編【働学併進#012】

nariXcode

前編では、わかりやすい文章を書くために必要な7つの原則と文章構造についての説明があった。簡単にまとめると以下のようになる。

  • 7つの原則

    1. まず主題文から書く

    2. 読み手を意識する

    3. 大切なことは冒頭に書く

    4. 読み手の驚き最小化原則

    5. 読み手の背景知識と書き手の前提知識の差を埋める

    6. 客観的+定量的論拠に基づいて正確に書き、読み手が客観的事実と書き手の主観を区別できるように書く

    7. 実験や発明の再現に必要な「もの」だけでなく「手順」も網羅することで再現性を高め、建設的な議論の土台にする。

  • 基礎となる文章構造

    • 読み手の既有知識を拡張する形で新規知識へと展開する

    • 論文/報告書の基礎的な文章構造は「導入Context・本論Content・展開Conclude」の3C構造

    • 各モジュール(導入・本論・展開)が長い場合は、各モジュールの中でも「導入・本論・展開」構造をとる

    • 本論が複数あり、本論同士に順序/依存関係がある場合は、3つのモジュールを順番につなげて配置(順列型)し、本論同士に共通性があるなら複数の本論を1つの導入と1つの展開で挟むように配置する(並列型)

    • 本論は「課題Issue・手法Method・結果Result」IMRの3つを書く

    • 展開と次のモジュールの導入を融合した「つなぎ」で、文章の論理構造を明確にする

    • 2つの文の関係が分かりづらいなら接続詞を挿れる

    • Paragraph Writing を意識する

      • 1 idea or 1 topic per paragraph

      • 段落の核となる考え方や役割を示すtopic sentenceを冒頭に書く

      • 残りはtopic sentence を支える根拠や具体例、注意点を書く

3章ではこれらの原理原則を応用して「正確に書くための技術」を紹介し、4章では「技術の練習法と具体的な論文の書き方」がまとまっている。

余談だか、この手の本にしては珍しく、タイプセットが有効になっている(画像ベースではなくテキストベースの)Kindle本だ。さらに嬉しいことに、Kindle版は10/13まで半額の¥990なっている。

タイプセットが有効ではない技術書についてはいくつか思うことがあるので、後で気持ちを整理して投稿しようと思う。

それでは本題に入る。まずは「確実に伝えるための手法10選」からだ。

確実に伝えるための方法11選

1. 意地悪に読み返す

書き手は既有知識があるため、どうしても文章同士の論理的関係や前提条件、理由などの肝心な内容ですら補完しながら読んでしまう。
そこで、以下の3つの手法を用いて「厳しい読み手」になり、他人が読んでも意味の通じる文を目指す。

  1. 記事を3日から1週間ほど寝かせて、記憶の薄れた自分に読んでもらう

  2. 人に説明するようにゆっくり読み上げてみる

  3. 文章を読んでる途中でことあるごとに理由、信頼性、結論を確認する

    • なぜ？ Why?

    • 本当に？ How accurate?

    • それで？ So what?

2. 主題の立ち位置を明確にするための理由を補う

「導入・本論・展開」構造や、本論のIMR構造に沿っていても、ただただ書いているとつい「なぜ」が不足してしまう。
第三者が「なぜ」の不足した文章を読むときは無意識的に「なぜ」を考えてしまい、混乱や読みにくさの原因になる。
そのため、読み手が抱くであろう「なぜ」は先回りして説明する。特に「なぜ、他の方法ではなくその手法を採用したのか」「なぜ、一般的なものにしなかったのか」などの選択理由や自分の常識と読み手の常識の違いを考えてみる。

3. 「なぜ」に「なぜ」を問う

職場では、よく「なぜなぜ(分析)をしましょう」という言葉を聞く。
私たちプログラマーは「いやいや、ソフトウェアだからそのくらいのバグは許容範囲でしょ」と思っていても、仕様側は「なぜそのバグが出たのか？なぜバグが出た原因が混ざり込んでいたのか？」を知りたいらしい。
同じように、読み手は一次的な「なぜ」では満足できないことが多いと考えられるため、書き手は何重にもなぜを問い続けなければならない。

この本では、以下の手順で「なぜ」の「なぜ」を繰り返し分析するように勧めている。

  1. まずは伝えたい主張を箇条書きで記入する

  2. 読み手が納得できない/疑問に思う箇所の理由を副項目として書き連ねる

  3. 副項目の中に、読み手が納得できないような箇所の理由があればさらに副副項目を書き連ねる

  4. この作業を一般的な法則や参考文献で示せるようになるまで続ける

  5. 同じ「なぜ」が出てきたり、片方のなぜがもう片方のなぜと依存関係になっていたりする場合は「なぜ」の順番を組み替える

4. 全体像から詳細情報へ

読み手にはいち早く全体像を掴んでもらい、詳細情報へと展開するように書く。

これは2章の①「読み手の既有知識を拡張する形で新規知識へと展開する」に基づいている。
何よりも先に全体像を読み手の既有知識とすることで、それ以降の補足情報が読みやすくなることを狙っている。

×: iPhone 14 Proでは、iPhone 13 Proから搭載された、映画のようにフォーカスを変えながら映像が撮れるシネマモードに加え、激しい手振れが加えられている状況でも手ブレを修正してくれるアクションモードが加えられた。
○: iPhone 14 Pro のシネマカメラとしての機能は、従来のiPhoneと比べてより激しい状況でも使える程進化した。具体的に追加された機能はアクションモードと言い、撮影者がどれだけアクロバティックに動いても手ブレを大幅に軽減する効果がある。もちろん、iPhone 13 Proまでの機能(シネマモード)も使える。

5. 助詞を適切に使う

接続詞は文と文をつなげるために使われるが、同じように助詞も「情報の関係を示す」「読み手の予測を誘導する」「書き手の主張を込める」機能がある。

まずは「てにをは」をマスターしよう。

  • は, が

    • Google はUSB-Cを採用した
      →強調したいのはGoogleが行ったこと("は"の後)

    • Apple がUSB-Cを採用した
      →強調したのはUSB-Cを採用した企業/人 ("が"の前)

  • に, へ

    • 東京駅に向かう
      →目的地は東京駅

    • 東京駅へ向かう
      →目的地は東京駅方面

「など」は必ず複数の例を示した後で、共通の性質を読み手にわかってもらえるように書く。つまり「など」ではなく「などの」の形で使う。
e.g.
×: Apple はMacBook のMagSafe 充電ケーブルなどを追加した
○: Apple はMacBook のMagSafe 充電ケーブルやファンクションキーなどのユーザーからの復活希望の声が高まっていた機能を追加した

「が」は以下のような文章ならどちらでも成り立ってしまい、読み手の予測を誘導する役割や書き手の主張を込める役割が果たされていない。
・Appleは株価が下がっている最中だが、新製品を発表しない
・Appleは株価が下がっている最中だが、新製品を発表した
そのため、文脈に応じて「が」に別な接続詞を追加するか、なぜそうなったかの理由を追加する。

6. 文脈の流れを堰き止めている段落を治療する

文脈の流れを堰せき止めている段落はその性質上、前後の段落だけでは内容が推測できない/推測しにくい段落となっていることが多い。
そのため、段落を一つずつ隠して前後の段落から推測ができない段落があったら、隠している段落か前後の段落に問題がないかを確認する。

  • 隠した段落に問題がある
    →段落にアイディアや話題が詰め込まれすぎてないか？
    →段落を読むのに必要な前提知識の説明が抜けていないか？

  • 前の段落に問題がある場合
    →前の段落の「展開」が次の段落のトピックセンテンスへの流れを正しく作れているか？

  • 後ろの段落に問題がある場合
    →段落のトピックセンテンスがまとまっているか？
    →段落の先頭につく接続詞が正しく書かれているか？

7. 背景説明は最短経路に絞る

書き手の調査自慢話を背景にうだうだ書くのではなく、読み手が主題を理解するために必要な情報や知識をまとめた場所にする。

具体的には、本論のIMRのうち、解決しようとしている問題(Issue)を理解するために必要な背景情報に絞る。

また、次の手法「起きたことを時系列で語らない」も意識する。

8. 起きたことを時系列で語らない

文章を書く際に時系列で「語る必要はない」ということであって、実験結果を記録するときや文章を準備するときは時系列でまとめると重要な情報を取りこぼしにくくなることは間違いない。
しかし、何度も言っているが読み手は早く結論や終着点が知りたいため、研究の途中で起きたが結果には無関係だったものは捨てる。さらに、読み手が条件や原因が理解しやすいように必要に応じて説明の順番も変える。

余談だが、おそらく歴史が嫌いな人は「話の終着点が見えない」ことに強くストレスを感じる人なのではないかと思う。
特に中学高校の頃の私は世の中の大概のことは簡単であると舐め腐っており、時間をかけてゆっくり学ぶことに耐性がなかったのだと思う。
とはいえ、今でも戦国時代や三国志を読もうとは思わないが。

9. 曖昧な表現を避ける

When you catch an adjective, kill it. No, I don't mean utterly, but kill most of them—then the rest will be valuable.
"形容詞を見つけたら、消せ。全てとは言わないが、ほぼ全て消せ。
残った形容詞だけに価値がある"

Mark Twain

定量的なものに「約」とか「程」とかをつけると曖昧になってしまう。
数値で範囲を示したり、有効桁数を示す方がより具体的になる。

先述の通り、「なぜ」が不足すると読み手が納得できない曖昧な説明になってしまう。特に、例を提示するときは「などの〇〇(共通する性質)」と明言することや、分野ごとの用語を適切に使うことを忘れない。
e.g.
サイコロを振る必要があるのか、
一様分布ならなんでもいいのか
任意の方法でも何か一つを選ぶことができればいいのか

10. 修飾語と被修飾語の関係を見直す

修飾と被修飾の関係で有名なのが、「青い魚をくわえた猫の子」や「頭が赤い魚を食べる猫」がある。これは1つの修飾子が文のどの言葉につくかによって意味が異なるという問題だ。
詳しく(且つ面白く)知りたい方は以下の動画をお勧めする。

確かにマークアップ言語を使えば解決しそうだが、ここではただのテキストだけでなるべく誤解を減らせる修飾語と被修飾語の配置を紹介されていた。

  1. 修飾語と被修飾語を近くに置く
    (((頭が赤い)魚)を食べる猫)

  2. 二文節以上の就職後は分裂して解釈されやすいため、長い修飾語は前に配置する
    (魚を食べる)(頭が赤い)猫)

  3. 読点を使ったり語順を変えたりする
    頭が、赤い魚を食べる猫

11. 主語と述語の関係を見直す

修飾語と被修飾語の関係を見直すのと同様に、以下の点に気をつける。

  • 主語と述語が離れすぎていないか

  • 一つの述語に対して複数の主語候補がないか

  • 主語と述語の間を隠したときに文として破綻していないか

    • ×: Appleの発表会では〜〜〜落ちぶれたということだ

    • ○: Appleの発表会で分かったことは〜〜〜落ちぶれたということだ

文章作成の実践術7選

1. とにかく書く

Q. 主題文と構造が決まってから次は何を書くべきか？
A. かけるところからとにかく書くべき

いきなり文章を完璧な形で書くのは難しいため、まずは自分が考えていることを整理するためにも書き出してみる。
一般的には「導入・本論・展開」のうち、本論が書きやすいとされている。
また、各パーツを構成するパラグラフ(段落)のトピックセンテンスだけを書いてみるのも有効。

ただ、とにかく書いただけではいい文章とはいえないため「最低では2回でも直す時間をとるべし」

2. 箇条書きで文章の骨格を形成する

「とにかく書く」ために、文章構造の骨格を各項目1,2行で思いついた順に書き連ねてみる方法が紹介されていた。

  1. まずはパソコンやスマホで、思いついたことを書き連ねる、とにかく書く

    • 補足情報は箇条書きの段落を深くして、副項目としてまとめる

  2. 必要に応じて順番を入れ替える

  3. 意味の似ているものや共通するものをまとめる

  4. 各項目の先頭に接続詞をつけて文脈を形成する

  5. 章の異なりそうなところで区切る

  6. 骨格に肉付けをする

3. 書き直す＆削る

Only kind of writing is rewriting.
"たった一つの書き方(文章術)は書き直すことだ"

Ernest Hemingway

出来の悪い文を見つけたら、悪い文の下に新しい文を書き、少しでも改善したかやどれほど良くなったかを比較する。
納得できない文でも同様に元の文を消さずに複数の改訂候補を書いて、一番いいものを選択する。

不足していた情報の補足や表現の改善が終わったら、文章の5%を目安に余分な言葉を削る。

  • 余計な読点

  • 大袈裟な表現や不要な形容詞

  • 長い、情報量の少ない言い回し

  • 先行研究や参考文献に書かれているような話

  • 関連性の低例や先行研究への言及

非常に、過言でない、言うまでもない、だいたい、などの言葉は初めから使わないようにしてもいいかもしれない。

4. 論文の型に則る

$$
\begin{aligned}
論文&=導入+本論+展開 \\
&=(序論+背景)+IMR+(議論+結論)
\end{aligned}
$$

  • 序論: 読み手に、論文を読む意味(introduction)や読むための基礎的な背景知識(background)を提示する

    • 序論の最後ではIMRの概要と、結論を一文にまとめたもので締めくくる

  • 背景: 序論では説明しきれないもう少し専門的な背景知識や、その背景知識を自分がどのように捉えているか/どのように研究に結びつけているかを提供する

  • IMR

    • 課題と結果が1:1になるように課題か問題の範囲を調整する

  • 議論: 「本論中では簡単にはくだせなかった結果に対する判断」を自分の中で複数の視点から見た議論や論拠を示す。

  • 結論: 前提条件の範囲内ではどれほどのことが成り立つと分かったのか、どれほど以上なら成り立たないのか/不明なのかを示す。

自分の専門分野で共通している型を知りたいときは、プレプリントサービス(e.g. arXiv)や、雑誌(Nature)を活用してさまざまな論文を読んでみる。

5. 「起承転解結」な概要を書く

主題文は自分一人が分かればいいものであるが、概要は多くの人が概要を読んで論文の中身がわかるようになっている必要がある。
論文が扱っている課題、類似の先行研究、それらの問題点、解決法、結論の全てを書く。

  • 起: なるべく多くの人が読めるような研究の背景知識 1文

  • 承: より本論に近い、絞り込まれた背景 1〜2文

  • 転: 着目した問題点。先行研究で不明な点 1〜2文
    逆説の接続語を使い、流れが変わることを知らせる

  • 解: 解決のための手法とその結果1〜2文

  • 結: 結論 1文

6. 正しく引用する

引用する際は以下の3つの点を明確にする

  • 引用元

  • 引用した内容と論文との関係性
    → 一度にまとめて掲載しても関係はわからない
    → 引用した文と書き手の主張の文はつなげない方が簡単

  • 成果や意見は引用元のものか、筆者のものか

引用の種類

  • 直接引用: 引用元の文をそのまま使う「」や“”で囲むことが多い

  • 間接引用: 引用元の文を書き手が加工して使う

    • 参照: 引用元の文献に書かれている内容をごく短い語句にまとめて言及する

    • 要約: 引用元の文献の内容を書き手が要約したもの

    • 敷衍ふえん: 引用元の主張を書き手が拡張したもの

      • →書き手の都合のいい部分だけを切り取って解釈(チェリーピッキング)をしない

文献情報・書誌情報

  • 著者名

  • 題名/書名+版

  • 掲載誌名、巻、号

  • 発行元

  • 発行年

  • ページ

  • Digital Object Identifier

7. 見やすい図表を書く

大抵の投稿先で図や表の書き方は決まっているが、共通して押さえておくべき内容はこのようになっている。

  • グラフ

    • 図番号とキャプション(説明文)

    • 軸ラベルと単位

    • 凡例

  • 図

    • 図番号とキャプション

  • 表

    • 表番号とキャプション

    • 項目名と単位

    • 罫線は控えめ、数値は右ぞろえ

付録: マークアップ言語でテンプレートを作ってみた

<head>
  <title></title>
　<thesis>
    <!-- 主題文 -->
  </thesis>
  <meta name="author" content="">
  <meta name="reader" content="who is your reader?">
</head>
<body>
  <context>
    <!-- 導入 -->
    <p>
      <!-- topic sentence -->
      <!-- reasons & examples -->
    </p>
  </context>

  <content>
    <!-- 本論 -->
    <issue></issue>
    <method></method>
    <result></result>
  </content>

  <conclude>
    <!-- 展開 -->
  </conclude>
</body>

ご自由に使ってほしいが、この本で紹介されていた通りにするなら以下の流れで使うことをお勧めする。

  1. 主題文を決める

  2. 対象読者を決める/調べる

    • 対象読者の既有知識

    • 対象読者の関心

  3. 主題文を見直す

    • 課題、結果、手法、根拠は十分か？

    • 読み手に必要な背景知識と最も訴えたい部分は導入に書き込む

  4. 導入・本論・展開で書く内容を決める

  5. 本論などの書きやすい場所からとにかく書く

    • 箇条書きでも

    • 根拠があやふやでも

    • 言葉遣いが不適切でも

  6. 一通り書き終わったら文章を清書する

  7. 論理の破綻、接続詞の不足がないか確認する

  8. 3日、できれば1週間待つ

  9. 「意地悪に」読み直す

  10. 不足している根拠や情報、細かな表現を修正したら、文字量の5%を削る

MarkDownで書くなら以下のようになる。

# Title

## Context 導入

## Content 本論

### Issue 課題

### Method 手法

### Result 結果

## Conclude 展開

自分がよく使うアプリでテンプレートを作っておこう。「とにかく書く」ために

少しでもお役に立っただろうか？
雑なまとめになってしまったことは申し訳ない。
おそらく1, 2ヶ月後には、私のブログにて実践経験も含めてより丁寧にまとめていることだろう。

明日の予定は立っていない。
技術蒐集家ノウハウコレクターじみてきているため、明日は気の向くままに調べ物をして、その内容をまとめようかと思う。

この記事が気に入ったらサポートをしてみませんか？