　投稿するためのデータについては、全てＰＣ上で作成しています。長編作品の原稿作成を始めた際に、どのようにテキストデータをバックアップするかについて悩みました。幾つか検討した結果、「作品名_yyyymmdd.txt」のような命名規則とし、作品一つにつきファイルも一つとすることに決定しました。テキストデータを更新する際は、コピーを作成し、コピーしたファイルの「yyyymmdd」の部分をそのときの年月日に変更します。ファイル名のイメージは以下のようになります。

――――

作品名_20180716.txt

作品名_20180721.txt

作品名_20180729.txt

作品名_20180803.txt

――――

このようにしておけば、少なくとも前回の更新までのデータを残すことができますので、過去の状態に戻ることもそれほど困難ではありません（戻したことは今までほとんどありませんが）。

　また、作成を続けるにつれて徐々にファイルサイズが増加していくため、「ここまで書いたか」と自己満足に浸ることができます。文字コードが「シフトJIS（Shift_JIS）」の場合は、全角文字は一文字あたり二バイトですので、十万文字であっても二十万バイト＝二百キロバイトとなります。二百キロバイトであれば、それほど大きなファイルでもありません。ファイルサイズとディスク上の使用領域とに差異は生じますが、昨今の大容量なディスクでは大した問題ではないでしょう。百万文字であってもファイルサイズは二メガバイトですので、フロッピーディスク二枚分程度のデータ量です（ファイルサイズ等については、十進数で数えるか、二進数で数えるかによって差が生じますが、本論への影響は軽微であるためそれほど考慮していません）。

　なお、文字コードが UTF-8 の場合は全角文字一文字あたりほぼ三バイトですので、同じ文字数であっても、文字コードが Shift_JIS の場合に比べてファイルサイズは約一．五倍になります。文字コードが UTF-8 の場合は、ファイルサイズを当てにしていると「これだけ書いたのに（ファイルサイズが増えたのに）、文字数は大したことない……」となるため、現在使用しているテキストデータの文字コードは全て Shift_JIS にしています。

　　　　◇

●失敗例……一話ごとに一ファイルとし、ファイル名を「話名_yyyymmdd.txt』とする

　前述の「作品一つにつきファイルも一つとし、ファイル名を『作品名_yyyymmdd.txt』とする」に決定する前に、「一話ごとに一ファイルとし、ファイル名を『話名_yyyymmdd.txt』とする」という方法を試していたのですが、すぐに立ち行かなくなりました。原因は、ファイル管理の煩雑さでした。一話ごとに一ファイルとしようとした際、当初は「修正する場合は、そのファイルだけを修正すればよいから、手間もかからないだろう」と思っていたのですが、話数が増えていったときにその考えが甘かったことを思い知らされました。一話ごとに一ファイルの場合、それぞれの話の最新のテキストデータを見分けるのが面倒である、ということに直面しました。ファイル名のイメージは以下のようになります。

――――

第一話_20180716.txt

第一話_20180721.txt

第一話_20180722.txt

第一話_20180803.txt　←★最新

第二話_20180721.txt

第二話_20180722.txt

第二話_20180728.txt

第二話_20180729.txt　←★最新

第三話_20180722.txt

第三話_20180728.txt

第三話_20180729.txt

第三話_20180804.txt　←★最新

――――

第一話の最新データは「第一話_20180803.txt」ですが、二話の最新データは「第二話_20180729.txt」です。さらに、第三話の最新データは「第三話_20180804.txt」です。必ずしも「yyyymmdd」の部分のみで最新のデータを見分けることができず、「話名」の部分も含めたファイル名の全体で見分ける必要があります。上述の例は第三話までですが、これ以上に話数が増えた場合にさらに面倒になることは想像に難くありません。

　加えて、ある語を作品全体で検索したい場合、あるいは、一括置換したい場合、全ての話の最新のテキストファイルを開く必要がある、ということもありました。加えて、履歴を残すためには、全てのファイルのコピーを事前に作成しておく必要もあります。話数が数十に及ぶ場合、コピーするファイルも同じだけになります。テキストデータ作成にはテキストエディタを使用していますが、そのテキストエディタには複数のファイルを同時に管理するような機能は搭載されていないため、前述のような場合、作業が非常に煩雑になってしまい、執筆に集中できないことが判明しました。ですので、一話ごとに一ファイルとすることは早々に諦めました。

●不採用の例……バージョン管理システムを使用する

　バージョン管理システムとして、Git や Subversion などがあります。これらは、プログラム開発に於けるソースコードなどの管理のために使用されるものです。バージョン管理の機能を原稿作成にも使用できるだろうと思い立ち、機能を調べてみたところ、どうやら日本語文字の扱いに難があるということに行き当たりました。その他、初期設定もそれなりに手間であること、別のマシンへのデータ移行もそれなりに手間であること、これらのシステムを使うためにはコマンドや管理方法を含めた使い方を覚える必要があること、バージョン管理システムが使用するデータそのものもバックアップする必要があること、などから、本末転倒になりそうな気配が見えました。さらに、Windows 上で使用するにしても、Windows 上で操作を完結させるのが面倒そうだったこともあります。Windows とは別にサーバをわざわざ立てるのも手間です。「ただ単にテキストデータを作成したい、そこそこに履歴管理もしたい」という、ぼんやりとした要件に対しては、バージョン管理システムの使用は大仰でした。

　バージョン管理システムを使用する際には、管理対象とするデータ（ここではテキストデータ）をシステムに登録する必要があります。面倒くさがりという自身の性格からして、登録し忘れる、故意に登録しない、古いデータで最新のデータを上書きする、などの事態も予想されました。そうなると、システムを使う意義も無くなってしまいます。バージョン管理システムを使用するのであれば別の機会にしようということで、原稿作成での使用を諦めました。

※バージョン管理システムを使用するのであれば、一話ごとに一ファイルでもよいかもしれません。履歴についてはバージョン管理システムにて管理できるため、それぞれのファイルのコピーを保持する必要もなくなります。Visual Studio のような統合開発環境を併用すればさらに管理の手間は減らせるかもしれません。ですが、Visual Studio に組み込まれているエディタには一行の折り返し設定やページ数のカウントなど、原稿作成の際に便利な機能については実装されていなかったはずですので、この方法を採ることは今後もないと思います。