Novel Supporter作者に聞く、読み手に優しい文章

仕様書、進捗報告、障害報告、再発防止策……それがメインではないはずなのに、エンジニアは意外と文書を書く機会が多いもの。コードなら書けるのに日本語となると「何が言いたいかわからない」と言われてしまう方も少なくないのではないでしょうか。

いっそプログラムが文章を直してくれたらいいのに……と思いたくなりますが、実は小説の世界には「Novel Supporter」(ノベルサポーター)という小説推敲補助ソフトが存在します。その機能は、文書を解析し、わかりにくい点や読みにくい箇所を教えてくれる……というもの。

この「Novel Supporter」を開発したのは、プログラマーであり小説家でもある柳井政和さん。いったいどのようにして、「わかりにくい文章」をプログラムで定義していったのでしょうか。お話をうかがうと、文章の書き方とプログラムの書き方に、いくつもの共通点が見えてきました。

柳井 政和(やない まさかず)さん
クロノス・クラウン合同会社代表。大学卒業後ゲーム会社勤務を経て起業し、ゲームやアプリケーションの企画・開発、プログラミング系技術書などの執筆を行う。2016年、松本清張賞最終候補作を改題改稿した『裏切りのプログラム ハッカー探偵 鹿敷堂桂馬』で小説家デビュー。小説推敲補助ソフト「Novel Supporter」の開発者としても知られる。
クロノス・クラウン:https://crocro.com/
Twitter:https://twitter.com/ruten

自分では気づかないミスは、プログラムに指摘してもらおう

――柳井さんが開発された「Novel Supporter」は、小説の推敲を補助するソフトだと伺いました。どうやってプログラムで「良い文章」と判断しているのでしょうか?

柳井さん:「Novel Supporter」は、小説のテキストファイルを解析して、見落としがちな問題のある箇所を見やすく強調するソフトなんです。同じフレーズを繰り返し使っていないかをチェックする「単語近傍探索」や、同じ文末が重複していないかチェックする「文末重複確認」といった機能を備えています。

私はよく、眼鏡に例えていますね。視力が低いと見えにくいものも、眼鏡をかければはっきり見えますよね。「Novel Supporter」も文章の”眼鏡“として、自分では気づきにくいポイントをはっきり見せることを目的にしています。

▲「Novel Supporter」で「単語近傍探索」を実施したところ。同じ言葉を繰り返し使っていないかをチェックできる。同じ言葉は同じ色でマーキングされるため、使いすぎている言葉も一目瞭然

――確かに、自分では全然気にならなかったのに、他の人に指摘されると「ここも、確かにここも……」と気になってしまうことってありますね。

柳井さん:まさに、自分も同じような経験をして「Novel Supporter」を作りました(笑)。口頭でしゃべるような感じで書いてしまうと、”こそあど”が多かったり、同じ語彙が続いたりしがちなんですよね。同じ言葉が続くなら、それは検索で見つけられます。自分で気づけないのなら、プログラムに気づいてもらえばいいだろうと

他の機能も、ほとんど自分の経験則から作っています。「画数ヒートマップ」は、難しい漢字を使いすぎて読みづらくなることを防ぐため。「文長ヒートマップ」は、“。”から“。”までが長くなりすぎていないか確認するために作りました。ポジティブな単語とネガティブな単語をピックアップして、読み手の感情の動きをグラフ化する「センチメント分析」というのもあります。

▲「画数ヒートマップ」。画数の多い漢字ほど赤く表示される。真っ赤な文字が塊になっていたら読みづらい証拠。同じように、長い文章ほど赤く表示される「文長ヒートマップ」もある

▲「センチメント分析」。「安心」といったポジティブな言葉と、「裏切り」のようなネガティブな言葉を検索し、それぞれの単語が使われている量をグラフで表示する。小説の内容とグラフを比較して、楽しい場面なのにネガティブな言葉が多かったり、逆の現象が起きている場合は要注意

――「Novel Supporter」自体が文章の良し悪しを判断するのではなく、「ここが良くないかもしれないよ」と提案してくれるツールなわけですね。

柳井さん:その通りです。スポーツでも、自分のフォームをビデオに撮ると欠点に気づきやすいと言うじゃないですか。

客観的な視点から文章を見ることで、直すべきところをチェックできるわけです。「ここがまずいかもしれませんが、文章自体を直すのはあなたですよ」というスタンスですね。ソフトに指摘された箇所でも、「ここは意図的にやっているから、このままで」というのだってアリです。

――柳井さんご自身も小説を書かれますが、「Novel Supporter」はいつごろ、どんな経緯で作られたのでしょうか?

柳井さん:小説家デビューする前から、自分用にちょこちょこと補助用のツールを作っていました。いくつもあった小さなツールたちを、小説家デビューするタイミングで1本にまとめてリリースしたのが「Novel Supporter」なんですね。これを自分の小説の広報用に出してしまおう、と。

――だから無償提供されているんですね!

柳井さん:新しいジャンルに参入するときは、そのジャンルの方に喜ばれる「お土産」を持っていくと決めているんです。おかげ様でいろいろなところで取り上げていただき、「Novel Supporterの人」として認識してもらえました。少しでも露出を増やして興味を持ってもらわないと、本も読んでもらえませんので……。

実際にツールを使った人からは、「自分の苦手なところをフォローしてくれるので、助かる」と感想をいただいています。文章を書くのが難しいのは、書く人と読む人が違っているからなんですよね。これはプログラマー的な言葉にすると、「エンコードとデコードを違う人が行っている」状態。この両者のギャップを、Novel Supporterを通して少しでも埋められれば、と思うんですが。

書き手に求められるのは、読み手の「負荷」を減らすこと

――データを他の形式に変換するのが「エンコード」、エンコードされたデータを元の形に戻すのが「デコード」ですよね。それぞれ、文章を書くこととどのように似ているのでしょうか?

柳井さん:文章では、書き手の脳内に浮かんだイメージを文字にするのが「エンコード」に、読み手が文字からイメージを膨らませるのが「デコード」にあたります。そう考えると、書き手の方でエンコードしたあと、読み手の方で「マシンスペックが足りなくてデコードができない」「ライブラリがインストールされていないのでデータが読み込めない」……ということが起きてもおかしくないですよね?


――普段から本を読み慣れていなかったり、言葉が難しすぎて理解できなかったりすると、文章を読むのが辛くなるし、正しく意味が読み取れないこともある、というわけですか。

柳井さん:はい。そう考えると書き手が意識すべきなのは、「デコードにかかる処理の負荷を下げる」ことになります。例えば、長すぎる文章は読み手の”脳内メモリ”を消費してしまうので、一文を短くする、といった具合ですね。

――完全にプログラムの考え方ですね。

柳井さん:難しい言葉は、思い出したり辞書を引いたりといった参照コストがかかるので、なるべく減らします。「これ」「それ」などの多用も、この言葉はどこを指しているのか……と参照先を探すことになるため、負荷を上げる原因になります。

また、内容がAともBとも取れてしまう文章は解釈に時間がかかるため、誤り訂正(※)が必要になります。読点を適切に打つなどして、適切に対処しないといけません。ひらがなだらけ・漢字だらけの文章も、誤り訂正を減らすために避けたいですね。

※ データの送受信などで発生した誤りを検出し、正しいデータに訂正すること。

――読み手が正しくデコードできないと、書き手のイメージがきちんと伝わらないですもんね。


柳井さん:そうですね。物書きとして、ついつい「どう書くか」を考えてしまうんですが、実は「どう読まれるか」のほうが重要だと思っています

先ほど挙げたのは文章の例ですが、読まれる環境も大事です。紙の本で読むのか、スマホの画面で読むのかでも、1行の長さや段落のボリュームが変わってきます。ゲームでもそうじゃないですか。ドラクエのメッセージ欄が毎回1文字だけ余ったらイライラしますよね?

――「おお ゆうしゃよ! しんでしまうとは なにごと」で改行されて、次のページが「だ!」だけの状態……。確かにイヤですね。


柳井さん:そうなんですよ! なので、最終的にどんなデバイスでどう読まれるかは確認しておきたいですね。私が小説や技術書を書くときも、1行の文字数や、1ページの行数を確かめて推敲するようにしています。

そのうえで、1ページ内に入れる情報量も調節します。情報を詰め込みすぎると、読み手が疲れて手が止まってしまうんです。読者が「本をさくさく読み進められて、気持ちがいい」を味わえるくらいの、ほどほどの情報量になるよう考えています。

要素ごとに内容を切り分けて、「保守性の高い文章」を目指す

——他に、情報のコントロールで注意すべきことはありますか? 例えば技術書を書くときは、「読み手に負荷がかからない」作りがより重要になると思うんですが。

柳井さん:本文に入る前に「アウトライン」を見せておくことでしょうか。他の方が書いた技術書を参考にするときは、目次を意識して読むようにしています。技術書のアウトラインって、要するに目次のことですからね。

技術書は「どの情報を、どの順番で積み上げれば理解してもらえるか」を考えて作られているので、目次を見れば、その本がどんな内容かなんとなくわかるんですよ。本文に入る前に目次で全体像がつかめれば、読み手も、アウトラインを把握したうえで文章を読みはじめることができますから。

——確かに、文章の最終的なゴールが示されていれば、途中にわからない箇所があってもなんとかついていくことができそうです。

柳井さん:書き手にとっても、中身の文章を書きはじめる前に目次を作るだけで、内容にだいぶまとまりが出てくると思いますよ。少なくとも「ここで何を書いていたのかわからなくなってしまった」とか、「このブロックでは何をかけばいいんだっけ」という状態を避けられるようになります。

――「メモリ消費を抑える」「誤り訂正を減らす」といった文章を読む負荷を減らす方法は、章立てや全体の流れのような、構成づくりのレベルでも同じように役立てられそうですね。

柳井さん:通じるものがあると思います。ソースコードだって、ダラダラと長く書くより、短く分けたほうが読みやすいですから。私がプログラムを書くときは、1ファイル100行くらいで納まるように構成しています。各ファイルを束ねた構造が、そのままそのプログラムの「目次」になるわけです。

▲ 目次に目を通すことによって、「この技術書が誰に向けて書かれたのか、自分に向けたものかそうでないのかがわかる」(柳井さん)とのこと

――なるほど! プログラム全体が一冊の本のようになりますね。

柳井さん:処理を適切に切り分ければ、個別にテストを行うのも楽ですし、後からアップデートがしやすくなります。これをプログラムの世界では「保守性が高い」と表現しますが、文章の世界でも「保守性の高い文章」を目指すといいかもしれませんね。

一度作成してから、数カ月や年単位でアップデートしていく文章ファイルもあるじゃないですか。目次にそって内容がまとめられていれば、構造をつかみやすいだけでなく、アップデートの際に段落の追加や削除も楽になると思います。

書く技術が高まれば高まるほど、文章は「空気」になってしまう

――ところで、柳井さんご自身は「こうすれば読みやすい」という要素を、どのように学ばれていったのでしょうか?

柳井さん:やはり「自分が書いたものを人に読んでもらって意見を聞く」というのが一番だったと思います。

小説を書き始めたころ、読書が好きな先輩にチェックをお願いしていました。その人がものすごく厳しくて、せっかく書いたページにまるごと「×」を付けられたりしたんですね。「このページはダメ」「このページもダメ」みたいに。

――厳しいですね……。どうして先輩はそのページに×を付けたんでしょう?

柳井さん:「さっき読んだ話とかぶっているからページ丸ごといらない」と言われました。同じ内容が繰り返し出てくると。自分では全く意識していなかったのでショックでしたね。

同じことの繰り返しは、単語やフレーズ単位でも頻発していました。そうした被りは、機械的にチェックできます。実際にプログラムを書いてみると、たくさん見つかるわけです。そうしたチェックをするツールが増えていき、それらが、「Novel Supporter」の原形になりました。

――そこにつながってくるんですね!

▲ 柳井さんの代表作のフリーソフト「めもりーくりーなー」。Windowsのメモリを掃除して、余分なデータを解放してくれる。2001年度オンラインソフトウェア大賞を受賞。筆者も会社から貸与されていたPCのメモリが足りず、会社員時代にとてもお世話になった

柳井さん:あとはプロの作家の「写経」もやりました。プロの文章って、何気なくスラスラ読めてしまうんですけど、書き写してみたら読点(「、」のこと)がすごく少ないことに気づいたんですね。でも素人が同じレベルで読点なしの文章を書いたら、とても読めたもんじゃないんですよ。プロは情報の出し方が上手で、読み手に「先読み」をさせてくれるんです

——物語の先が読めてしまう……ということですか?

柳井さん:いえいえ、あくまで文章単位での「先」という意味です。人は文章を読むとき、この内容なら次にどんな単語や言い回しが来そうなのか、なんとなく予測しながら読むと思うんです

例えば、PCの前にプログラマーが座ったらキーボードに手を伸ばして、イラストレーターが座ったらペンタブレットに手を伸ばすと思うんです。単語レベルでも「車が走る」のように、この名詞のあとには、ふつうはこの動詞が来るといった繋がりがあります。接続詞についても、「しかし」のあとには相反する内容が来て、「そして」の場合は前の内容を受けます。そういった予測に沿った内容が書かれていると、読む側もとても楽ですよね。

逆に、「例えば」の後に例示がされなかったり、ビジネス書だと思って読んでいたのに急にアクロバティックな比喩が来たりしたらびっくりするじゃないですか。プロの文章はそうした引っかかりがなく、先読みのエラーが起きにくい。スルスルと空気のように読めるわけです。

——文章が空気のようになっているから、逆に技術に気づきにくいんですね……。

柳井さん:丁寧に読むと、本当に技術の塊だとわかりますよ。音楽と同じで、盛り上げるところはじっくり読ませたり、早い展開のときはテンポよく読ませたり、自由自在に緩急をつけていますから。そういう意味で写経はおすすめですね。

——小説でもビジネス文書でも、「相手がどのように読むのか」を考えながら書く……。お話を聞いていると、「読みやすさを意識してコードを書ける人は、読みやすい文章も書ける」と言えるのではと感じました。

柳井さん:そうですね。当たり前ですが、読みやすい文章は読む時間を減らせます。これはプログラマーにとっても見逃せない利点だと思うんです。

柳井さん:プログラマーは「無駄な時間をいかに省くか」を常に意識しています。今まで1時間かかる処理が、1分に短縮できたら嬉しいわけです。文章も同じで、読み終わるまで10分かかっていた文章が、5分で読めるようになったら嬉しいはず。その文章を読まなければならない人が1,000人いるなら5,000分、つまり約83時間もの時間を生み出せたことになります。1万人なら833時間です。

読みやすい文章が書ければ、みんなが使える時間が増える。それはとても素晴らしいことだと、プログラマーやエンジニアの皆さんに伝えたいですね。

文=井上マサキ/編集=伊藤 駿(ノオト)/図版とイラスト=藤田倫央

この記事が気に入ったらいいね!しよう

いいね!するとi:Engineerの最新情報をお届けします

プライバシーマーク