文が長すぎる問題とその対処

文（センテンス）の長さについて関心が払われていない技術文書は読むのに時間がかかります。特に日本語の長い文の内容が掴みにくく感じるのは、英語の節のように文内のブロックが明示的に分かれていないせいなのでしょうか。このあたりは私は専門でないので、正直よくわからないです。

残念ながら技術文書を書いた経験が十分でない執筆者（初学者）が書く文は高い確率（ほぼ百パーセント）で文が長いです。かくいう私が十数年前に書いた文も、今と比べて五割以上長かったことを覚えています。本稿では、なぜ文が長くなってしまい、どう解決するのかについて解説します。

# なぜ文は長くなるのか

では**なぜ初学者の文は長くなる**のでしょうか。私は**文を接続するのが怖い**という理由が多と考えています。怖いというのは、文と文のつながりが悪くなってしまうのではないかという恐怖です。文と文が接続できる自信がないので、文自体を長くして接続部分を減らそうとするのです。

# どうやって文を接続するのか

ではみなさん、文と文はどうやって接続していますか？初学者が書く文書をみると接続詞や副詞を多用して、文と文を接続しようという試みがみられます。しかし、接続詞や副詞の多用は無駄に文を長くしますし、文書の話の流れが遷移しすぎて、記述内容が掴みにくくなってしまいます。多くの技術文書の指南書では、文はこうあるべきという話は出てくるのですが、文と文の接続方法についてはあまり書かれていません。

私は文と文は**トピック**で接続しています。トピックを平たく言えば、**単語**です。単語を使って文を接続するルールはシンプルです。ただ**前の文で使われた単語を、次の文で再び使う**だけです。

たとえば、前の節で利用した二つの文について考えみます。

1. 私は「文を接続するのが**怖い**」という理由が多いと考えています。
2. **怖い**というのは、文と文のつながりが悪くなってしまうのではないかという恐怖です。

第二文で、第一文の文が利用したトピック、**怖い**を再利用しています。これは意図的に同じ単語を利用して二文を接続した例です。**人間は一つの文を読んでいるとき、次の文も同じトピックと予想します**[^1]。ですので接続詞を利用しなくても、**単語を文頭付近で再利用してあげる**と文が接続できます。

上記の接続を図で表すと以下のようになります。

![topcs2.png](https://qiita-image-store.s3.amazonaws.com/0/61252/471271f1-859b-e9aa-8a78-676a9efabe88.png)


文書を書き慣れてくると、同一の単語ではなく同じ意味の別単語で接続します。同じ単語を使いまわすよりも、ちょっとエレガントに見えますので試してみてください。たとえば、本文書で使われている以下の二文は、第一文の**恐怖**という単語と第二文の**自信がない**で文を接続しています。

1. 怖いというのは、文と文のつながりが悪くなってしまうのではないかという**恐怖**です。
2. 文と文が接続できる**自信がない**ので、文自体を長くして接続部分を減らそうとするのです。

上記の接続を図で表すと以下のようになります。

![topics3.png](https://qiita-image-store.s3.amazonaws.com/0/61252/9487ef71-d5af-453d-69ea-f004180ab713.png)


# 長い文が接続を阻害する

前節で述べたように、**単語を使いまわすと文間を接続できます**。しかし、このトリック（単語の使い回し）を使用する上で一つ守るべきルールがあります。守るべきルールは「**各文を短く保つ**」です。文を短く保たないと使用したトリックは機能しません。以下、サンプルを利用して解説します。

> サポートベクタマシンはパーセプトロンのような、二値分類器であるが、性能はそれらに対して高いといわれているだけでなくさらにパーセプトロンと同じくカーネル法を利用できる。パーセプトロンに代表されるニューラルネットーワークは古典的な手法と考えられてきたが、近年の...

上記のサンプルは二つの文からなります。

1. サポートベクタマシンはパーセプトロンアルゴリズム（ニューラルネットワーク）のような、二値分類器であるが、性能はそれらに対して高いといわれているだけでなくさらにカーネル法を利用できる。
2. パーセプトロンに代表されるニューラルネットーワークは古典的な手法と考えられてきたが、近年の...

上の例では第一文が長いのがわかります。第二文で共通単語、パーセプトロンを使っているのですが、二文を続けて読むと接続がよくありません。というのも第一文に多くのトピックが出現しすぎているため、読者が二文目にくるであろうトピックを予測できないのです。

つまり第一文を読んでいる読者は、次にくる文のメイントピック（パーセプトロンなのか、カーネル法なのか）について予測がつかないのです。

# 文を分割して、問題に対処する

長い文を短く分割すると、読者は次にくるトピックが予測しやすくなります。以下、文を短く分割したサンプルとなります。サンプルの各文では、接続に利用した単語をハイライトしています。

1. サポートベクタマシン（SVM）は**二値分類器**である。
2. SVMの性能は他の**二値分類器**（**パーセプトロン**など）に比べ高いと言われている。
3. さらにSVMは**パーセプトロン**と同じくカーネル法も利用できる。
4. そのため**パーセプトロン**に代表される**ニューラルネットワーク**は古いと考えられていた。
4. しかし、近年の**ニューラルネットワーク**...

短くなって各文のトピック数が限られているため、文間のトピック遷移が掴みやすくなっているのがわかります。上の文書ではトピックは以下のように遷移していきます。

![topics2.png](https://qiita-image-store.s3.amazonaws.com/0/61252/43a236e1-c104-b796-5f8c-02082fc3b9f0.png)

サンプルで利用されている文は少々ぎこちないので、正式な文書（書籍など）では修正が必要かもしれません。しかし各文は短くなっているので、読み間違いや、文を理解するのに時間がかかるという問題は避けられています。

# 議論というか四方山話

以下、四方山話です。

## ワンパラグラフ・ワントピック

技術文書についての指南書をみると、**一つのパラグラフは一つのトピック**だけを記述するべきと書かれています。このルールについて学生時代の私は、「一つのトピックってなんだろう」と得心がいかなかったのを覚えています。現在の私は、このルールを**同じトピックの単語を少しずつ変更しながら文を接続する**と読み替えています。ルールを読み替えたことで、すこし取り入れやすくなったと考えています。

## プログラミング言語

プログラミング言語を使っていると、**関数は短く**とか、クラスの**メンバは少なく**などのルールに気をつけます。このようなルールは後で別のプログラマがソースコードを理解するを阻害してしまうのを防ぎます。これらプログラミングの問題は文長と同じ問題だと考えています。積極的にリファクタリングしていきましょう。

## 関連資料

昔「プログラマのための作文入門」という資料を作りました。参考にしていただければと考えています。

http://www.slideshare.net/takahi-i/ss-13429892

## スライドにおける問題

口頭発表のスライド間のつながりについて資料、「スライド作成入門」を作成しました。参考にしてください。

http://www.slideshare.net/takahi-i/ss-15986330


# ということで

文書を書くときには、文の長さに気をつけて書く癖をつけましょう。[RedPen](http://redpen.cc)は文の長さを自動で検査してくれますよ ;-)


# 参考文献

[^1]: Beyond Bullet Pointsという本が認知のメカニズムからわかりやすい資料を作るという内容をカバーしています。ぜひご一読ください。