違いを見逃さない！小説におすすめのテキストエディタ、長編小説に必要な機能を見抜く

長編小説におすすめのテキストエディタは、作品の規模と書き方によって変わります。人気順位や機能数から選ぶ前に、自作の総文字数、章数、資料量、中断・更新の頻度、出版時の出口を測ってください。その五つの事実を、観察できる要求仕様へ変えると、必要機能を過不足なく見抜けます。

この記事の成果は、候補を合否判定したり採点したりすることではありません。自分の長編に対する「必須」「推奨」「後回し」の要求表を作ることです。既成の7条件で候補を除外する記事、同じ原稿で5機能を試して横比較する記事、選定後に執筆環境を初期設定する記事とは工程が異なります。

まず自作長編の五つの事実を測る

第一に、現在の総文字数と完結時の見込み文字数、最も長い一章の文字数を記録します。全巻を一ファイルで持つのか、章ごとに分けるのかでも負荷は変わります。「長編」という言葉だけでは候補へ同じ条件を渡せません。

第二に、章数と並べ替えの頻度を数えます。全体構成を何度も入れ替える作品と、章順が早期に固定する作品では、章管理に必要な強さが違います。

第三に、人物、用語、時系列、舞台、画像など、執筆中に参照する資料の種類と量を数えます。資料を同時に見るのか、検索で呼び出せればよいのかも分けます。

第四に、一日の中断回数、端末を閉じる頻度、過去章へ戻る回数を記録します。毎日一時間ずつ書く人は、長時間連続で書く人より再開経路の失敗コストが大きくなります。

第五に、完成原稿をどこへ渡すかを決めます。テキストやDOCXを編集者へ渡すのか、自分でEPUBを作るのか、Web連載へ投稿するのかで必要な出口が変わります。

事実を失敗場面へ変換する

測った数字をそのまま機能名へ置き換えず、「その機能がないと何が失敗するか」を一文で書きます。

たとえば総文字数が大きいなら、「表示補助が重くなったとき、本文編集、検索、保存まで止まる」という失敗場面を作れます。要求は「軽いこと」ではなく、「実規模の原稿で中核操作を残し、停止する表示補助の境界を説明できること」です。

章数が多いなら、「章を分けた結果、作品全体の表記揺れを検索できない」という失敗を置きます。要求は「章ごとに編集でき、同じ正本集合を全体検索できること」です。単にタブ数が多い、ファイルを開ける、といった機能名では不足します。

資料が多い場合は、「原稿を直しながら設定の根拠を探し回る」を失敗場面にします。要求は「原稿と資料の所在を一つのワークスペースで確認でき、必要なら見比べられること」です。

Rune Studioで第一章と第二章を同じワークスペースのタブに開いた画面 — 第一章と第二章を同じワークスペースのタブで開いた画面。

観察可能な文に直す

要求仕様は「使いやすい」「高機能」「長編に強い」のような形容詞で終わらせないでください。候補を触ったときに確認できる文へ直します。

代表一章と全体規模の複製を開ける
作品全体から固有語を検索できる
一文を変更し、保存後に再検索できる
閉じて開き直した後、正本と資料の所在を説明できる
必要な出版形式へ同じ正本から渡せる

ここでは候補を実際に試して合否を付けません。要求が観察可能な形になった時点で、次のスクリーニングや比較工程へ渡します。

必須・推奨・後回しを分ける

各要求に、発生頻度と失敗時の復旧時間を付けます。週に何度も起き、失敗すると正本を見失う項目は必須です。毎日使うが代替手段がある項目は推奨、完成直前に一度だけ使い、別ツールでも安全に渡せる項目は後回しにできます。

たとえば、章を毎日行き来する人には全体検索が必須です。資料を一画面で見なくても検索で間に合う人には、分割表示は推奨または後回しです。縦書きで推敲しない作品へ縦書きプレビューを必須にする必要はありません。

出版出口も同じです。毎週EPUBを更新するなら原稿からの再生成経路は必須になりやすく、最終稿を一度だけ外注するなら、標準的な原稿形式で安全に渡せることのほうが重要です。

要求表を一枚にまとめる

要求表は「作品の事実」「失敗場面」「観察する動作」「優先度」「代替手段」の五列にします。製品名や点数はまだ書きません。

製品名を先に書くと、知っている機能へ作品を合わせがちです。要求表を先に完成させれば、候補にない機能を本当に諦められるか、逆に不要な高機能へ料金や学習時間を払っていないかを判断できます。

総文字数や章数は執筆中に変わるため、初稿50％、初稿完了、校正開始の三時点で要求表を見直します。優先度が変わっても、測った事実と失敗場面が残っていれば理由を追えます。

rune Studioを要求項目へ対応させる

rune Studioの現行Mac版は、フォルダをワークスペースとして扱い、原稿と資料の所在を管理します。機能資料にはファイルツリー、分割ペイン、用途別レイアウト保存があります。これらは資料量と参照方法から導いた要求への対応候補です。

既存の段階4検証では、919,514文字の原稿を検索し、1件を限定置換、手動保存、再検索、close/reopenしました。保存後は919,517文字でした。別の境界検証では、299,999文字は大容量判定なし、300,000文字と300,001文字は判定ありでした。資料上は30万文字以上で重い表示処理を止め、検索や保存などの中核操作を残します。