Posted at

2015年の小説執筆環境

More than 3 years have passed since last update.


TL;DR

分散バージョン管理システムと、リポジトリのホスティングサービスを使う。


前置き

私の現在の執筆環境まとめ。

趣味で小説を書いてPixivに投稿しているだけで、同人誌の販売経験もない。なので、ここに書くノウハウがプロの作家や書籍化にまで通用するかは不明。


エディタ


保存形式: プレーンテキスト (UTF-8, BOM無し, LF)

おそらく最も汎用性が高い。

BOMとCRは役に立った経験が無いので、とりあえず無しで。

バイナリよりもテキスト。

Microsoft OfficeもXMLをzipするようになったのだし。

他のソフトウェアやWebサービスもたいていUTF-8なので、連携しやすい。シフトJISやEUC-JPに対応してないツールを使ってハマることもない。

将来、別の文字コードが普及するかもしれないが、そのときにはUTF-8から変換できるはず。


テキストエディタ: "Atom"

https://atom.io/

日本語まわりの処理を快適にするため、以下のパッケージを導入。

・japanese-wrap ( https://atom.io/packages/japanese-wrap )

・show-ideographic-space ( https://atom.io/packages/show-ideographic-space )

かつてパッケージはホームディレクトリ下のcoffeeスクリプトが動いてたので、bracket-matcherのソースコードを直に編集して、を入力すると自動でが補完されるようにしたり、対応する鉤括弧をハイライトしたりできて便利だったが、バージョンアップでできなくなった。

MacならSublimeTextもよい。 http://www.sublimetext.com/

WindowsならEmEditorをダウングレードして無料で使えるのもよい。 https://jp.emeditor.com/


カラースキーム: "Solarized" (dark)

http://ethanschoonover.com/solarized

Atomの場合は標準で入っていて、Syntax Themeで"Solarized Dark"を選ぶだけ。

長時間作業しても目が疲れにくい、気がする。白背景だと目がチカチカして、しんどい。

モダンなテキストエディタなら、Solarizedでなくとも目に優しげな暗めのカラースキームが何かしら入っている。


フォント: Migu

http://mix-mplus-ipa.osdn.jp/migu/

M+の派生フォント。

長時間作業でずっとMSゴシックを眺めているとなんだか損した気分になるので。

プログラミングで等幅フォントを使っているので、小説を書くときもなんとなくそれを使っている。等幅だと原稿用紙を埋める感覚に近いので、それなりに有用かもしれない。


バージョン管理


分散バージョン管理システム: "TortoiseHG" ("Mercurial")

http://tortoisehg.bitbucket.org/ja/ ( https://mercurial.selenic.com/ )

プログラミングに限らず、以下の条件に当てはまるなら、バージョン管理は必須である。

 ・分量がある

 ・長期間にわたって編集される

ショートショートしか書かず、一度発表したら手直ししない、というならば不要。そうでないなら、小説においてもバージョン管理は必要。

diffを確認してコミットできるのは本当にありがたい。

どこからどこまでを、どのように変えたか、把握できる。大胆に書き直せる。

EvernoteやOneNoteなどは、これに相当する機能が足りないように思う。

バージョン管理システムがないと、手動でファイルコピーして過去のバージョンを残すことになる。コミットログに比べて信頼性のない記録しか残らないし、バックアップが絡むとさらに面倒になる。diffのチェックも手作業で面倒。


リポジトリのホスティング: "Bitbucket"

https://bitbucket.org/

主にバックアップが目的。

ここで分散バージョン管理システム(DVCS)であることが効いてくる。中央リポジトリ形式だと単一障害点ができてしまうが、DVCSだと全履歴が各拠点に残る。

イシュー管理やWikiなども使えるが、あまりそこに情報を残すと、サービス乗り換えが億劫になるので、永続化したい情報はリポジトリ内のファイルに書き込むようにしている。

一人きりなら、リポジトリをDropbox管理下に作ればそれで足りる気もする。

この方法は、複数人になると、コミットなどの操作が競合する危険がある。


バージョン管理とホスティングサービスがもたらす安心感

バージョン管理により、編集ミスによる消失がなくなる。

ホスティングサービスの利用により、HDD,SSDの故障やUSBメモリの紛失などによる消失がほとんどなくなる。

原稿を失う心配がない。


運用


リポジトリのファイル構成

3つのファイル:


  • text.txt

  • memo.txt

  • reject.txt

text.txt

小説の本文。テクスト。

作品の題名はこのファイルの一行目に書く。ファイル名に日本語を入れると、OSやファイルシステムやバージョン管理システムをまたいだときにハマる恐れがあるので。

memo.txt

本文に書けないものをここに。

作品の設定。意思決定の根拠(なぜこっちの展開を選んだのか、など)。

Pixivで発表する際のキャプションやタグなども書いている。

reject.txt

いちど本文に書いたものの採用されずボツになった断片を、場合によってはここにコピペして残しておく。

基準は曖昧だが、ある程度コンテンツとして強度があり、コミットログから掘り出すよりはファイルを開いて見返したいと思うものはここに入れる。

形を変えて本文に残るものは、ここには入れない。

サブフォルダは不要。


リポジトリ構成

ホームディレクトリ直下にrepositorysというフォルダを作る。

 ~/repositorys

ここにリポジトリをフラットに配置する。ホスティングサービス上でフラットに配置されているので、階層を作っても散らかるだけ。

ちなみに会社ではSubversionを使っているので ~/checkouts となっている。

一作品で一リポジトリ。

中短編は、ひとつのリポジトリの中にサブフォルダを作って入れてもいいかもしれない。人が一生のうちに書ける作品の本数などたかが知れているので、一リポジトリで運用しても破綻しないだろうけど。


テキストフォーマット: なし

現状、気に入った記法が無いので、素のテキスト。

Markdownは改行が見た目通りにならないので避けている。行末にスペース二つなども厳しい。

Pixivの記法に依存するのもなんとなく避けたい。

ルビとコメントがうまくできる記法があれば使ってみたい。

改ページや章の区切りを意図した自分ルールを決めた。


text.txt

本文

 ※

本文(改ページ後)

 ※ ※ ※

本文(新章)


Pixivの場合、 ※ ※ ※で挟まれた部分をシリーズの一話ぶんとし、 ※[newpage]に置き換えて投稿する。

将来的に普及する可能性があるのは、小説専用の軽量マークアップ言語だと思う。

XML,JSONを手書きするとかありえないし、YAMLは小説に向いてない。

バイナリ形式が普及する可能性もゼロではないが、そのときにはテキストから変換する方法が用意されているだろうから、今現在はテキストで保存しておけば間違いないだろう。

もともと手書きの原稿を活字に起こす仕事があったわけで、これからもテキストデータからレイアウトを起こす仕事があるだろう。


執筆


辞典

国語辞典 http://dictionary.goo.ne.jp/jn/

類語辞典 http://thesaurus.weblio.jp/

類語辞典がこんなに役立つとは思わなかった。


誤字脱字の対策

たとえば「龍」という字を見るときに、普通は一角一角を意識したりはしない。全体でひとつの文字として認識している。実は細部に書き間違いがあったとしても、おおむね同じ形をしていれば、その文字は「龍」だと認識してしまう。

これは文章も同じで、普通は一文字一文字を意識したりはしない。多少の誤字脱字があっても脳が勝手に補正して文意がとれてしまう。特に自分が執筆している場合は、頭の中にあるイメージと目の前の文字列が合わさり文意は非常に明快なため、誤字脱字に気付きにくい。

第三者に見てもらうのが一番だと思うが、とりあえず一人でどうにかするためのTipsとして、表示形態を変える、というのがあると思う。

執筆中は、ずっと同じものを見ている。同じエディタ、同じフォント、同じ色、同じ折り返し幅。これにより記憶が強化され、一文字一文字を意識しなくても執筆できるようになり、作業効率は上がるが、その代償として誤字脱字に気付きにくくなる。なので、チェックするにあたり、これらを変えることで、一文字一文字を意識しやすくする。

自分が今利用しているのは、Pixivに小説を投稿する直前のプレビュー画面。執筆中とは見た目がずいぶん変わるので、いろいろと気付くことが多い。

紙に印刷するのも有効かもしれないが、確認したあとゴミになるのが微妙。

Kindleに表示するのもいいかもしれない。


整合性確認

たとえば、登場人物二人が食事をしているシーンで、Aが身を乗り出してBにものを手渡す、という描写があったとする。

後から、シーンの冒頭に、Aが食堂に来てBの隣に座る、という描写を加えたとする。

このままでは、隣に座ってるのに身を乗り出すことになり、整合性がとれなくなる。身を乗り出した、という表現を修正するか、AはBの向かいの席に座った、ということにしなければならない。

このような不整合は、一文単位で意味がねじれてしまうというものから、作品全体で設定が矛盾するというものまで、あらゆるレベルで起こり得る。

対策としては、読み直して不整合がないか確認するしかない。

コミット前に、更新される部分の前後を読み直す。誤字脱字チェックを章単位で行っているので、ついでに整合性もチェックする。章をまたいで影響することはmemo.txtに書いておく。

小説はプログラミングと違ってエラーが起きないので、人力で確認するしかないところがつらい。テストコードが書けない。NovelUnitとかNovelSpecとかあるといいのに。


心がけ

ディープな機能は使わない。

複雑なブランチ運用は行わず、将来別の何かが台頭したときにもコンバートしやすくなるよう心がける。

いざとなったら、コミットログを全部捨てて、新しくリポジトリにaddすることを覚悟する。

ソフトウェアやサービスの乗り換えを常に考える。

心血を注いだ作品が、アプリが廃れたら読めなくなった、というのでは虚しい。

すくなくとも自分が死ぬまでの間は作品が読める状態を維持できるよう心がける。