📖

GitHub上に構築した小説執筆環境について

2022/05/02に公開
1

要点

  • 小説執筆環境を GitHub 上に整備した
    • 校正作業を自動化できた
    • 執筆と情報管理を GitHub 上にまとめられた

小説執筆環境を GitHub 上に整備した

経緯

大学在学中や社会人 1 年目くらいまで、下記のような手法でバージョンを管理していた。

【確定版】2019 年 8 月版(2020 年 1 月 22 日改訂).docx

まったく虫酸が走る。
不快極まりない。
ただちに一掃しなければならない。

趣味で不快になっていちゃ世話はない。
せめて不快さを感じない程度の環境を整備する必要があった。

執筆環境への要求事項は次のとおり。

  • 自分でサーバ構築をせずとも使用できること
  • バージョン管理機能が実装されていること
  • クロスプラットフォーム対応であること

以上を満たし、かつ貧弱な端末やネットワークでも使用に堪える環境として、GitHub を選択した。


環境

前提条件

  • Windows10 を使用していること
  • GitHub のアカウントを所有していること
  • Git の操作をある程度自分で調べられること
    • (最低限コミット、プッシュ、プル、クローンを調べながら実行できればヨシ)
  • VSCode を既にインストールしていること

環境構築

以下のテンプレートリポジトリから、ひとまず環境が立ち上がる。
https://github.com/haoblackj/Novel-Template
リポジトリ作成方法・リポジトリ作成後の必要作業については、上記テンプレートリポジトリの README.md に記載している。


原稿を書く

ファイル命名規則について

ファイル命名規則は、8amjp 様作成の novel-builder.js を用いている関係上、以下のように定めている。
https://github.com/8amjp/novel-builder

すべての原稿は、episodesディレクトリ内に保存します。(前述の.envファイルで変更可)
原稿はMarkdown形式で記述し、ファイル名は「001.md」「002.md」…のように連番となるよう保存します。

(以上、novel-builder README.md より該当箇所抜粋)

表記規則について

表記規則についても、8amjp 様作成の novel-builder.js を用いている関係上、以下のように定めている。

ルビの記法は青空文庫注記形式とします。
傍点で表示したい箇所は**または__で囲みます。
英数字は基本的に半角で記述します。

(以上、novel-builder README.md より該当箇所抜粋)

執筆について

環境構築の段階でクローンしてきたリポジトリを開き、episodes ディレクトリへ命名規則に沿ったファイルを作成して執筆する。

VSCodeについて

執筆は VSCode で行うことを前提としている。
この際、あると便利なのが下の拡張機能だ。
https://marketplace.visualstudio.com/items?itemName=TaiyoFujii.novel-writer
VSCode には言語モードという機能があり、各言語に応じて文字や空白をハイライトしてくれたりする。
この拡張機能は、テキストファイル(.txt)や Markdown ファイル(.md)を「novel」という言語として解釈し、各種括弧やそルビ記法、数字と単位をよしなにハイライトしてくれる。
他にも編集距離や各種プレビュー機能などもあるので、ぜひ入れてみてほしい。

GitHubへのアップロード

いくら書いてもアップロードしなければ意味がない。
GitHub へのアップロード操作のことをプッシュと言う。
GitHub からのダウンロード操作のことをプルと言う。

プッシュするためには、まずコミットという操作が必要になる。
「〇✕というファイルをアップロードしますよ」と台帳に記載するようなイメージだ。
厳密には大変異なるが、ひとまずはそういう認識でよい。

ちなみに、このコミットという操作の際に記載する文言をコミットメッセージと言う。
これが適当だと、「あの時の記述を持ってきたいな」と思ったときに、あの時を探り当てるのに苦労する。
大抵の場合、(ファイル名):どこそこを修正したというような簡単な記載で問題ないだろう。

校正について

校正に関しては textlint を導入している。
textlint のルールを適宜追加インストールすることで、作品特有の表記ゆれや予測変換の暴発にも個別に対応できる。
追加ルールを入れずとも、テンプレートの段階でそれなりに校正できる。

なお、textlint の動作確認は、VSCode 拡張機能の vscode-textlint を用いて実施している。
https://marketplace.visualstudio.com/items?itemName=taichi.vscode-textlint
これもオススメ。マストと言っても過言ではない。

※追記(2023 年 1 月 23 日)
また、8amjp 様作成の novel-builder.js の機能で、以下の項目についても自動で修正できる。


  • 行頭に全角スペースを挿入します。ただし、下記と一致する行を除きます。
    • 開き鉤括弧(「『)で始まる行
    • Markdown の見出し記号(#)で始まる行
    • 既に全角スペースが挿入されている行
    • 空行
  • 全角の感嘆符(!)、疑問符(?)のあとに全角スペースを挿入します。ただし、下記と一致する場合を除きます。
    • 直後が感嘆符、疑問符、閉じ鉤括弧(」』)、半角スペースの場合
    • 既に全角スペースが挿入されている場合
  • 閉じ鉤括弧(」』)直前の全角スペースおよび句読点(、。)を削除します。
  • 三点リーダー(…)の連続回数が奇数だった場合、もう 1 つ追加します。
  • ダッシュ(―)の連続回数が奇数だった場合、もう 1 つ追加します。

(以上、novel-builder README.md より該当箇所抜粋)

なお、nove-builder.js の機能のうち、一部が適切に動作していないことがわかっている。


  • 鉤括弧の開きと閉じの書式が異なる場合、開きの鉤括弧の書式に統一します。
    • 「〜』という文が合った場合、「〜」に変換します。

(以上、novel-builder README.md より該当箇所抜粋)

このテンプレートでは、関連する部分をコメントアウトした fork 版を使用している。

textlint と上記の拡張機能によって、執筆しながら校正を完了できる仕組みが完成した。

公開について

8amjp 様作成の novel-builder.js の機能で各サイトの記法にあわせた出力が可能だ。
ただし pixiv は対応していないため、ここだけは逐次修正する必要がある。


原稿を管理する

情報をタスクとして管理する

長編作品を一気に書き上げてしまう場合を除き、大抵一度はメモを取ったりするものだ。
自分のふとした思いつき、読者からの指摘。
そういった重要な情報は、失えば取り返しがつかない。

「思い出せない情報なら重要じゃない」などというナイーブな考え方は捨てろ。

幸い、GitHub にはその類の情報を取りまとめる仕組みが備わっている。
Issue 機能を ToDo 管理ツールにするという発想は、GitHub ユーザの中ではさほど珍しくない。
私は下記の記事を参考に、原稿周りのタスク管理を GitHub に一本化した。
https://zenn.dev/t4t5u0/articles/f3aeb3895fd1fb

もちろん、込み入った設定をせずとも、単に ToDo アプリのようにタスクを起票して管理するだけで十分機能する。

世の中には、タスクのステータスを動かすだけで関連情報が更新されないと我慢ならないという、どうしようもない連中も存在するのだ。
つまり私のような。


今後の展望

ひとまず、ここでは必須となる項目のみに留める。

GitHub と VSCode を用いて小説執筆環境を持ち運べるようになれば、PC さえあれば真実どこにいても同じ小説を書ける。
思いついた情報はオンライン上の不揮発性ストレージにしまい込まれ、求めに応じてすぐに呼び出せるようになる。
PC の調子が悪くなったからといって、急いで USB メモリや外付け HDD に小説を逃がす必要もなくなる。

ぜひ試してみてほしい。

この記事の後方には、ブランチを切りPull Requestを通して、新旧をリアルタイムで比較しながら改稿する手法や静的サイトジェネレーターを通して身内向けのプレプリントページを生成し、レビューしてもらいやすい環境を整える仕組みなどのネタが控えている。

そのうち書きます。

追記(2022-08-10)

続編的立ち位置の記事を作成したので、こちらにも掲載しておく。
https://zenn.dev/haoblackj/articles/manuscript_compare_by_pr

追記(2022-08-22)

執筆環境に手を加えた。記事を分けて紹介しているため、こちらにも掲載しておく。
https://zenn.dev/haoblackj/articles/novel-codespaces

GitHubで編集を提案

Discussion