閑話其弐

　とりあえず書くことは書いたのだが、実のところ書きたいことの半分しか（それも数の上ではちょうど半分しか）書けていない。

　本当は書きたかったのだ。本当は、 VS Codeの話や、 Gitの話、 GitHubの話を書きたかったのだ。

　これらのツールも使いこなせば、執筆体験はさらに素晴らしいものになるはずだ。

　しかし、 VS Codeは素の状態ではただの高機能エディタだし、 Gitは管理ツールだし、 GitHubに至っては GitHub社が運営しているサービスである。これをカクヨムに持ち込むのは流石にどうかと思ったので、泣く泣く諦めたのだ。もちろん、これも書くと文量がさらに爆発するので敬遠したことも否定しない。

　とはいえ、書きたいことには違いないので、ここで少しだけ紹介させていただく。

　・ VS Code

　Vimを紹介するときにチラッと「 VS Codeの話はしません」とだけ登場させたが、我慢できずに書いてしまう。不品行な筆者と笑いなさい。

　さて、この VS Code（Visual Studio Code）は WindowsでおなじみのMicrosoftが開発しているエディタである（https://code.visualstudio.com ）。

　あのMicrosoftが開発しているだけあって、かなり堅牢かつ堅実な作りで、ユーザー数も多い（おそらくVimより）ため、機能追加のためのプラグインも多い。

　似たようなエディタには Sublime Textや、かつてはAtomが居たが、 Sublime Textは有料（一応無料で使い続けることはできる）であるし、少し力不足感もある。 Atomは死んだ（開発終了。後継者は居るらしいが、使っていないので良くわからない）ので、事実上 VS Code一強と言っても良いかもしれない。

　そして、 VS Codeは普通のエディタのようにファイルを開き、編集し、保存することができる上に、執筆用のプラグインも充実している（本来コーディング用に開発されたのに！）。

　例えば、「テキスト校正くん」（https://marketplace.visualstudio.com/items?itemName=ICS.japanese-proofreading ）というプラグインは素人の校正よりも強力に文書のチェックをしてくれるし、段落の字下げなどをやってくれる「Format Novel」（https://marketplace.visualstudio.com/items?itemName=8amjp.formatnovel ）が存在したり、「テキスト小説」（https://marketplace.visualstudio.com/items?itemName=gearsns.text-novel ）は縦書き横書きに対応したCSSでプレビューを表示してくれる（融通が利かないなど、それぞれのプラグインにデメリットもあるが、それはそれとして有効である）。

　もちろん、LaTeX形式の入力を補助するプラグインの「LaTeX Workshop」（https://marketplace.visualstudio.com/items?itemName=James-Yu.latex-workshop ）や、 Markdown形式の入力を補助する「MarkdownAll inOne」（https://marketplace.visualstudio.com/items?itemName=yzhang.markdown-all-in-one ）も存在する。

　また、後で触れる GitやGitHubとの連携もばっちり可能だ。

　これらのプラグインは VS Codeの中から取得することができるのだが、更に恐ろしいことに、 VS Codeには悪魔のプラグイン、「Vim」（https://marketplace.visualstudio.com/items?itemName=vscodevim.vim ）が存在する。実際に使ってみると本物のVimのようには使えないのだが、「思考の速度で」書くには十分である。さらに、 Vimから生まれたNeoVimというエディタ（出来ることは殆どVimと変わらない）を中で動かすことでvimrcが使えるプラグイン「NeoVim」（https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-neovim ）すら存在するのだ。

　しかも、動作も（流石にVimほどではないが）軽快で、まさにエディタ界の帝王のような奴である。

　では、どうしてこいつを紹介しなかったのかって？

　だって、これ紹介したらみんなVim使ってくれないだろうし…… 。

　真面目に答えると、確かにVim-likeに操作はできるのだが、 VS Codeのキーマップとの兼ね合い上、かゆいところにいまいち手が届かない。キーマップについてはNeoVim対応の方を使えばかなり改善されるらしいが、筆者がいまいちNeoVimに詳しくないため触れないでおく（実のところ、 NeoVimの方が開発が活発なのだが、 undoの管理の仕様をVimに飼いならされてしまった …… ）。

　また、高機能なアプリケーションの宿命として、立ち上がりなどは少し遅めである（と言っても、長くて数秒だが）。 Vimはその点早いのだが[要出典]、操作の面でやはり重い。そのため、本当に一行二行だけ追記しようという場合にはOS付属のエディタか、第三のエディタを使った方が良いだろう。

　筆者はこの用途にWindowsではNotepad++、macOSではCotEditorを使っているが、これらを特に布教しようとは思っていない。第三のエディタは本当になんでも良いだろう。

　そして、普段の執筆では、深く考えながら書く場合はVimを使い、さらさらと半ば手癖で書けるような場合は VS Codeをデフォルトのキーマップ（もしくはVim-like）で使うのが良いだろう。

　・ Git

　このあたりから、執筆に本格的に関係なくなってくるため、少し自重しながら進めよう。

　しかも、 Gitは大抵の物書きにとっては有っても無くても変わらないだろうから（実際、筆者も短編はもちろん、この原稿の執筆にも使っていない）。

　ただし、公募などで書籍化を目指す物書きは知っておいたほうが良いかもしれない。なぜならば、 Gitは非常に強力なバージョン管理ツールだからだ。

　そもそも、バージョン管理ツールとはなんだろうか。それは、「バージョンを管理するツール」である。情報が6 byteしか増えていないが、少なくとも「バージョンの管理されたツール」ではないことが解るだろう。

　さて、真面目に説明すると、バージョン管理ツールとはファイルの変更を記録しておいて、好きなときに記録された状態に戻れるようにしておくためのツールである。

　これがなぜ必要かというと、もう、おわかりですね？

　自重の定めるところに従ってここで終わってもいいのだが、もう少し説明しておこう。

　なぜ必要かというと、変更は必ずしも望ましいものではないからだ。

　例えば、思いつくままに小説を書いたとして、陰惨な復讐劇が出来上がったとしよう。もしも、あなたがこの展開を気に入らなければ、気に入っている部分までは残して、残りの展開は削除してしまえば良い。しかし、もしその結果できあがった小説がパルプ小説がソクラテスの言葉に見えるような出来上がりであったらどうだろうか。

　念の為言っておくが、筆者はスターウォーズも嫌いではないし、カストリ誌に載っているような文章もなんだかんだ好きである。とはいえ、本体を読んだのは（特に三合で潰れる方は）はるか昔に一度きりで、今は画像検索で調べてみた限りにおいてだが（余談だが、ルーカスフィルム版の小説は正史に入らないらしい。文庫版を図書室から借りては良く読んだものだが、天下のディズニーには逆らえないということか）。

　カピカピの話は置いておくとして、もしも前に書いた復讐劇の方がまだマシな出来だと考えるならば、前の小説を時の彼方から求め呼びかけることになるだろう。その際に、強力な味方になるのがバックアップである。もしも三文小説に書き換える前のファイルをコピーして保存しておいたならば、あなたはハードディスクの肥やしを1つ減らしてバックアップを正史にしてやれば良い。

　この例のように大きな変更ならばバックアップを意識して取ることもあるだろうが、通常の変更はもう少し些細な、例えば主人公がヒロインを呼ぶ言葉を「オイ」から「女王様」に変えると言ったような、些細な変更だブヒィ。

　その度にファイルをコピーしていてはあなたのフォルダには …… 少なくともそのファイルの編集でタイピングしたキーの総数よりは少ないだろうが、それなりの数のファイルが保存されることだろう。数が多いということは基本的に嬉しいことだが、少なくともこの場合と自分を恨んでいる人間の数については、もう少し控えめな数であることが望ましいだろう。

　この目的で使われるツールを一般にバージョン管理ツールと呼び、 Gitはその中でも特に利用者が多いためオススメなのである。しかも、 Gitは例えば、タイムマシーンの行き先にどんな変更をしたかのメモも残せたり、どこを変更したかの比較を出してくれたりと、なにかと器用なツールだ。

　筆者個人としては特に「git revert」と「git reset」で巻き戻した履歴を残すか残さないか選べるのが好みである。

　とはいえ、厳密さをそこまで求めない、娯楽用途の小説をポイと投げるぐらいならバージョン管理はそこまで気にしなくていいだろう（管理のために作成されるファイルも意外とサイズが大きいのだ）。

　しかし、 100万文字の超長編を書いてやろうだとか、あるいは真剣に書籍化を目指すという場合にはバージョン管理はやっておいた方が良いかもしれない。 100万文字は流石に管理しておかないとどこで何を変えたか覚えきれなさそうである。

　書籍化については、一冊あたり10万文字程度なのでそこまで（100万文字に比べれば）大変ではないだろうが、むしろこちらの書籍化勢の方が必要になりそうである。なぜならば、公募で賞を取ったとして、多くの場合はそのまま出版するわけではなく編集と共に推敲するであろうからだ。推敲すれば確かに文章は研がれていくのだが、その分元の表現が薄れて文章の意図が迷子になることがありそうである。そんな場合にタイムマシーン（Git）を使っていれば、過去に戻って元の原稿を確認できるだろう。なぜこの段落が推測ばかりなのかというと、筆者に書籍化の経験がないからであろう（あるいは、である）。

　導入に関してはオフィシャル（https://git-scm.com ）からインストーラ持ってくるかパッケージ管理システムでぶち込んで「git init」したら適宜「checkout」して、たまに「status」見ながらひたすら「add .」と「commit」したら、たまに「merge」して、リモートにmaster乗せてるなら「fetch」しろ（特に複数人で編集しているなら）。と、言いたいのだが、流石に冷血が過ぎるので少し探してみた。

　正直なところ VS Codeのプラグインで十分じゃないかという気もするのだが、 GUIで調べると早々に Sourcetree（https://www.atlassian.com/ja/software/sourcetree ）というものが見つかった。次に述べるGitHubと同じ会社が作っているだけあって、 GitHubとの連携も強そうであるし、 Gitがcommitの向き付きリンクで出来たツリーと言うのが視覚的にも解って大変よろしいんじゃないかと思う（ Gitガチ勢ではないので間違っているかもしれないが、多分こんな感じである）。

　ついでに、「冷血」な導入法で出た単語も簡単に解説しておこう。

　まず、インストールは前提として必ずしないといけないのだが、パッケージ管理システムというのはインストールの細かい部分を自動でやって、更新なども管理してくれるツールである。 macOSならばHomebrewかMacPorts、Debian系ならばaptかapt-get、 Windowsならばwingetかchocolateyあたりだろうか。

　ただし、これらを使うのにもインストールが必要な上に大抵shell上で導入するので、深く触れたくないならば（Gitも本来shell上で動くCLIツールなのだが）素直にインストーラで入れるのが良いだろう。

　次にgit init。これは、今居るフォルダ（Shellで使うと言った通り、 Shellが開いている場所）でGitを使うという宣言である。これを宣言しないと、 Gitはこれ以降の命令で何をすればよいか解らなくなる。

　次に checkout （以降のコマンドではgit "command" argsの"command"以外書いていない）だが、これはバックアップを取る操作である（厳密には、バックアップを取ってそれを編集するようにする操作）。

　statusについては、変更があるかを確認するだけの操作（本当はもう少し色々わかる）。

　その後のaddとcommitは変更した内容をGitに教えて（add）実際にバックアップに反映させる（commit）操作だ（重要ですね）。

　mergeはcheckoutとは逆で、バックアップの内容を本流に戻す操作である（厳密には流れを2つ統合する操作）。本流に戻しても、バックアップに施した変更の履歴などは残るので心配する必要はない（実はこっちも重要）。

　その後のfetchというのは少し特殊で、複数人でフォルダを管理したい場合はコンピュータの外にフォルダを置いておいて、各自の手元で変更した内容をそれぞれ外のフォルダに反映していくということをする。このコンピュータ外のフォルダの状態を確認するのがfetchで、大抵の場合はpullと呼ばれる、確認後に自動でmergeするコマンドの方がよく使われるらしいが、中身だけ確認したい人もいるかも知れないのでこちらを紹介しておく。

　fetch/pullと逆に手元の変更を外のフォルダに反映させるのはpushという操作をするのだが、このあたりは実際に多人数で管理する場合に編集の担当にでも頼んで、 fetchも含めて一緒に勉強したほうが良いだろう（外のフォルダの管理に追加で知識が必要になるので）。

　このように、具体的に何を履歴に残していくのかというのを見ると、何となく便利さが解るかもしれない。つまりGitは、過去に戻ってやり直したり、並行世界を支配することができるツールなのだ。

　なんとなく自重できていない気もするが、気にしないことにしよう。どのみち次の紹介は短くなるから。

　さて、この時点で究極の思考表現ツールであるVimと悪魔の知恵を持った VS Codeを用いて、完璧に意思を汲み取る召使であるLaTeXと素晴らしい仕事をする庭師のMarkdownを伴い、 Gitで過去と並行世界を支配する用意ができたわけだが、次に紹介するGitHubを用いると、空間を支配する力を手に入れ、同胞の支援を受け入れる準備が整うので、これを見ていこう。

　・ GitHub

　と、言いつつ申し訳ないのだが筆者もあまり詳しくない。というのは、筆者がGitHubを使うのは主にcloneで pushしたことがほぼない（何なら、GitHubのアカウントもほぼ動いていない）からだ。

　これにはいくつか理由があるのだが、一番はGitHubが管理「サービス」である事が大きい。

　筆者も何人かでファイルを共有することは良くするのだが、 WWW上に公開されているファイルをまとめて共有するならまだしも、それ以外のファイルは基本的に外に見られると困る、非常に困るファイルである。 GitHubも少人数での管理ならばメンバー制で閲覧を管理できるプライベートなフォルダを作ることができるのだが、組織外に実体（ファイル）が存在してしまうので、いまいち使用を提案しにくいのだ。

　なら組織内でサーバを立てれば良いという識者の意見が聞こえてきそうだが、正直言い出しっぺの法則で管理をやりたくないのである（あと、その分の勉強も興味がない）。

　しかも、Issueを見つけても、大抵誰かが先に見つけているし、解決してやろうという気概も大抵の場合はなく、有っても先を越されるのでプルリクすら飛ばしたことがない。私は寄生虫です…… ごめんなさい…… 許してください…… 。

　そして、基本的にマシンをまたいだ編集をしない（パブリックとプライベートのマシンを分けているので）ので、プライベートリポジトリにpushすることすらないのである。

　こんなことを書くと「この人の言葉を信じて大丈夫かしら」という読者の声が聞こえてきそうだが、実際信じなくて良い。

　というよりは、実際に使う段階ならばリテラシーとして当然なのだが、いくつかの資料を元に言っていることが正しいのか調べることが基本なので、そこまで信憑性を重要視していないのだ。もちろん、できる範囲内で確認はしているが。

　そんなわけで、このGitHubについては相当にふんわりとした紹介になってしまうことを容赦願いたい。

　さて、初学者に伝わらない懺悔も終わったところでGitHubについて簡単に説明したいのだが、重要なことは上の懺悔でほとんど言っているし、筆者がその恩恵を受けていないことがバレているので用語の解説に留めておこう。

　まず、GitHubはGitHub社が提供するオンラインサービス（https://github.com/ ）である。ふざけているわけではなくて、本当に社名とサービス名が同じなのだ。サービス内容は、上で触れた「外のフォルダ」、正式名称はリポジトリを置くための場所を提供するサービスである。この場所を用意するのが実は大変で、他所でやってくれるならそれが楽だということで、企業もこのサービスを利用しているようだ。

　次にclone。これは gitのコマンドで、リポジトリを自分の手元のマシンに丸ごとコピーするコマンドである。 fetchやpullとの違いは、 fetchは変更分だけ持ってくるのに対し、 cloneはとりあえず全部持ってくる。なので、ファイル一式を共有する場合はまずcloneで手元に持ってきてやる必要があるのだ。

　Issueというのは文字通り問題のことである。 GitHubは本来プログラムの設計図を管理するために使われることを想定して作られているため、設計図のどこに問題があるのかを編集者全体で共有するための機能がついており、これに問題を報告することを「Issueを上げる」と呼ぶようだ。

　プルリクは正式にはプルリクエストのことで、 Issueに対して解決策を見つけた人がリポジトリの管理者に連絡し、その解決策を使うように提案することだ。もちろん、管理者がその解決策を気に入らなければ、却下しても良い。

　最後に、プライベートリポジトリと言うのはその名の通り、個人的なリポジトリである。つまり、許可していない他人からは見ることも編集することもできないリポジトリだ。昔はこのプライベートリポジトリを作るのに有料会員である必要があったが、 2020年ごろに機能開放され、共有できる人数に制限はつくが、無料会員でも作成できるようになった。

　さて、紹介したいものはこれで紹介し終えた。

　本当はLaTeXの表組みや、 Vimのgrepやdiffなどについても書きたかったが、際限がないのでやめておこう。

　ここまでで紹介したすべてを使いこなせば、あなたは思考の速度と悪魔の知恵で文書を書き、文書のレイアウトは忠実な従者達に任せ、過去と並行世界、そして空間を支配し、新たな仲間を迎える余地すら残している。

　ここまでツールを揃えておけば、心置きなく執筆という未来を創造する仕事に集中できることだろう。

　もちろん、これらのツールが肌に合わなければ使いやすいツールで執筆すれば良い。それが適していると感じたのならば、 Google Docsで小説を書いて、手作業でバックアップしても、 Google driveの機能でバックアップしても、なんならバックアップしなくても良い。そこに不満が出ないのならば、新しい不便を受け入れてまで環境を更新する必要は、まったくない。本当に、書き方は個人の自由だ。

　それに、面白い小説を書くために何よりも必要なものは、あなたの外側には取り付けることはできない。