タイトルは釣りではありません。
- 最近、小説の執筆にあたって Git を導入して原稿の進捗履歴を管理しました。めちゃくちゃ便利でした。
- GitHub を使って友人と一緒に校正校閲の作業をしました。めちゃくちゃ捗りました。
- 短編 SF 小説が短期間で完成しました。でも広告が目的ではないのでリンクは貼りません。
Git のことを何も知らない奴が Git と GitHub の使い方を覚えたら便利だったし捗ったので、記事にしてしまおうぜという試みです。
2019年1月4日 追記
本記事は「執筆」および「校正・校閲」の段階における Git と GitHub の有用性を主張する記事です。
「組版」や「デザイン」の段階における Git の有用性については言及していません。
組版においても Git を活用するのなら LaTeX との相性が良さそうだとは思っています。
2019年1月8日 追記
#### 4.3.2. 君が編集者なら
にて、「GitHub のプライベートリポジトリは有償プランで利用できる」と記述しておりましたが、1月7日(米国時間)より無料プランでも GitHub のプライベートリポジトリが利用できるようになりました。共有人数は3人までで、レビュー機能には制限があるようです。
これにより、 GitHub を試験的に導入するハードルが下がりました。プロジェクトが本格的に動き始め、関係者が多くなったら有償プランに乗り換えてスケールさせる、というスマートな運用が可能になりそうです。
有償がハードルだった方々も、ぜひ試してみてください。
Pricing · Plans for every developer
2020年2月11日 追記
文章に関わる全ての人のための Git & GitHub 入門 1-1「Git と GitHub を使うメリット」
Git ＆ GitHub の講座を始めました。読んだ人がひととおり Git と GitHub を扱えるようになるまで終われない連載です。
0. この記事はこんな人が書いています
-
片倉青一（以下、片倉）
- この記事のファーストオーサーです。
- 主に SF 小説を書く作家です。
- プログラムはちょっと書けるけど理解はしてません。
- 8月から12月にかけてゆっくり Git を覚えました。
-
acple（以下、リンゴ）
- この記事のラストオーサーです。
- C# チョットデキル。
- Git 完全に理解してる。
- いつも片倉の小説を読んで校閲とかしてる。
- @acple@github
1. きっかけ
2018年の8月に、ＳＦ雑誌『オルタニア』という電子雑誌に短編小説を寄稿することになりました。そのことをリンゴに話したところ、
「Git で原稿管理しようぜ！！GitHub で校正校閲しようぜ！！！」
と強く強くプッシュされました。
実はそれまでも何度か「片倉ぁ、 Git で原稿管理しようぜー」とは言われていたのですが、導入していませんでした。
というのも、正直に言うと聞かされていたメリットについて、いまいちピンと来ていなかったからです。
作家あるあるだと思いますが、以下のようなやりとりがありました。
リンゴ「Git を使えば変更履歴が追えるんだよ！」
片倉「変更履歴を見返すことが無いからなあ……」
リンゴ「それは変更履歴を残してないからだよ」
片倉「はい、そうですね」
リンゴ「日付ごとに何十枚もファイル作るの面倒くさくない？」
片倉「面倒くさい」
リンゴ「ワンポチバックアップできたら強くない？」
片倉「一般的には強いと思う」
リンゴ「Git ならバックアップ機能も兼ねているんだ」
片倉「バックアップね……小説ってのは書いている最中に最適な表現がひらめくから、意義が見いだせないかな……」
リンゴ「後になって『あの表現、捨てたけどここで再利用したい！』ってならない？」
片倉「それはまあ、ある」
リンゴ「そこで生きるのが変更履歴だ」
片倉「なるほど」
リンゴ「それに Git なら今日は何文字進んだ、っていう進捗管理もできる」
片倉「一元化できるのは便利だな」
リンゴ「僕が君の原稿を査読して修正提案をするとき、いちいち別のファイルに記述する必要もない」
片倉「そいつも便利だろうな」
リンゴ「メリットは絶対にあるからやってみてくれ。全力でサポートする」
片倉「君がそこまで言うなら……」
というわけで導入しました。
ごめんなさい。めちゃくちゃ便利でした。
実はこの記事も GitHub のプライベートリポジトリにブン投げて、リンゴの監修を受けています。
2. Git と GitHub の使い方を覚えるメリット
作家目線で Git と GitHub の使い方を覚えるメリットを書いていきます。
2.1. 進捗が一発で分かる
Git は高機能 diff （差分比較）ツール付きのデータベースです。いつ、何を、どれくらい書いたのか、一発で確認できます。
進捗管理用のファイルを別途用意して、作家が手作業で管理する必要はありません。
コミットメッセージに「mm月 dd日 x,xxx字」と書くだけで進捗が分かります。
どのくらい進んだか、視覚的に確認することも簡単です。
下図は GitKraken という Git 操作ツールで、2018年9月25日に執筆した文章と、それ以前の文章を確認したものです。
図2-1-1 コミットログ
その日に執筆した履歴はこんな感じで積み上がります。
（このアホ、文字数をコミットメッセージに記録してませんね……）
図2-1-2 差分表示
どう変更したか、どのくらい進んだか、視覚的に分かります。
git diff --word-diff とかのコマンドを使えるようになれば増減した文字数も分かります。
ツールの詳細については後ほど
4.1. 初学者が Git を導入するにあたって最低限必要なもの
にて述べますが、初学者が Git に触るならまずは上図に示した GitKraken 等の GUI 操作が可能な Git 操作ツールを導入するのが良いと思います。
初学者がいきなりコマンドラインで Git を操作するのはハッキリ言って無理です。無理でした。
残念なことに GitKraken のインターフェースは英語ですが、大した障壁ではありません。
10 年前に TOEIC 400 点を記録してから更新されてない 英語力 / ZERO の片倉が言うのですから安心してください。
2.2. 過去に書いた文章を再利用しやすい
小説書きにはあるあるだと思うんですが、あるとき「ここ全部要らない！」となってバッサリ切り捨てることがあります。
そして後になって「あ、ここはあの時の文章が使えるのでは？」という時が必ず来ます。1割くらいの確率ですが。
そんな時のために退避場所として「退避ファイル」を作るのもひとつの手ですし、片倉もそうしていますが、切り捨てる際に「退避させなかった」文章は掘り返せません。
でも Git なら大丈夫。全部記録しているからね。
図2-2-1 ファイルの履歴表示
見てください、このバッサリ切り捨てた 8,000 字弱の文章……
後になってここから拾い上げた文章も実際にありました。
小説における文章は確かに水物なのですが、「あの時にあの文章を書いた自分の感性を思い出せ！」となる瞬間もあります。
そんなとき、切り捨てた過去の感性を Git の履歴から拾い上げ、現在の原稿へ合うように整形して収めることができます。
2.3. 校閲するとき GitHub の諸機能がめちゃくちゃ便利
GitHub のレビュー機能や、 Git の差分比較機能を利用することで、
- 修正提案
- 実際の修正
- 修正内容の確認
- 修正を受けての再提案
というサイクルを高速回転させられます。
実際の画面を見てもらったほうが早いでしょう。
図2-3-1 issue 機能を用いた議論
これは GitHub の issue 機能を使った例です。
原稿ファイルの「論理行」に対してリンクを張ることで「ここをこう直してはどうだろうか」と提案しています。
図2-3-2 Pull Request 機能を用いた議論
これは GitHub の Pull Request 機能を使った例です。
変更された箇所に対してコメントを付けています。
図2-3-3 Suggest Change を用いた議論
これは「Suggest Change」という GitHub の Beta 機能です。
Diff の形で「こう変えてはどうだろうか」という提案がなされています。
Pull Request を立てた人が GitHub 上で直接ファイルを更新できます。
運用している最中に、 Pull Request におけるコードレビュー機能を使った方が良いと判明したので、現在はほぼ全ての校閲を Pull Request にて行っています。
今回は片倉とリンゴの二人だけが、片倉の原稿に対して校閲を実施しました。
だいたいは
- GitHub にてリンゴが小説を読みながら修正提案を片っ端から挙げる
- 片倉が GitHub にて片っ端から修正の候補を挙げる
- 合意が得られた内容は片っ端から原稿に反映する
というものでした。
言葉にするとこれだけのことなのですが、「片っ端から」という点が重要なのです。
「Word の校閲機能とか Google Document の提案機能でいいじゃん？」と思う方もいらっしゃるでしょう。
結論から言うと、ダメではありませんが、 Git と GitHub の方が数倍から数十倍は快適です（個人の主観です）。
プログラムを書き慣れている方なら「Word とか Google Document のレビューは原稿データと密結合だからダメ」と言えば一発で伝わるでしょうか。
-
Word や Google Document の場合
Word の校閲機能や Google Document の提案機能は、「原稿ファイルそのもの」に修正提案の内容が記載されてしまいます。原稿が余計なデータで汚れる、と言ってもいいでしょう。
印刷するためのマスターデータを考えてみましょう。提案内容がファイルそのものに記載され、もしその提案内容を解決・削除し忘れたとき、印刷するためのデータに提案内容が残ってしまいます。
これがいかにヤバいか、細かく説明する必要はないでしょう。
人間は忘れますし、必ずミスをします。忘れたりミスをしたりしても問題が無いような仕組みを使った方が良いでしょう。
また、いったん修正提案が記載されたファイルを作成した場合、それらが全て解決・削除されるまでは、新たな修正提案ができなくなります。
反論に対する反論も書いておきます。-
原稿ファイルをコピーして新たな提案をすればいいじゃん
どのファイルが修正されたのか、どのファイルが解決済みなのか、どのファイルが最終版なのか、誰が管理するんですか？
管理者がミスをしないと言えますか？ -
ファイル名で変更履歴を管理すればいいじゃん
ファイル名を変更し忘れたらどうするんですか？
ファイル名の命名規則はどうやって決めるんですか？
その命名規則を遵守できる保証はありますか？
どのファイルがどう変更されたのか、どうやってチェックするんですか？
目視で確認する？やめてください死人が出ます。
-
-
GitHub の場合
GitHub を利用した修正提案は、原稿ファイルそのものは変更しません。 GitHub のシステムが原稿ファイルを参照し、修正提案の内容を外部データとして記述するため、原稿が汚れません。
原稿ファイルそのものに修正提案をしないということは、著者が修正提案に対応している間に、校閲者からの新たな修正提案が追加されても衝突が起こらない、ということでもあります。
そろそろお分かりの方もいらっしゃるかとは思いますが、「複数人」が「非同期的」に校閲を実施する際、 GitHub はめちゃくちゃな威力を発揮します。
もし Word の校閲機能を使っていたら、校閲者であるリンゴの修正提案が終わるまで著者の片倉は待ちぼうけを食らっていたことでしょう。逆に、著者の片倉が修正している間は校閲者のリンゴが待ちぼうけを食らっていたことでしょう。
つまり無駄な時間が発生せず、校閲者は修正提案に集中することができ、著者は修正内容を考えることに集中できます。
Google Document の提案機能はもう少しマシですが、校閲者から見ると「著者が何をどう修正したか」ということまでは分かりません。 Google Document のバージョン管理機能は実際のところ「操作の履歴」なので、例えば全文をコピー＆ペーストしたら「全行が更新された」という扱いになります。つまり「何がどう修正されたか」という詳細なポイントは全く分からなくなります。
残念ながら現在のところ Google Document にはデータの「差分」を比較する機能がありません。
2.4. Git や GitHub を使えない人に査読を依頼する時も楽
誰かに査読を依頼するため、原稿ファイルを投げたとしましょう。ファイル名を仮に「Genko.txt」とします。
そして原稿ファイルに指摘が追記された査読結果が返ってきたとしましょう。ファイル名を仮に「Sadoku.txt」とします。
さて、査読結果をどう反映したものでしょうか。
二つのファイルを並べて開いて目視で確認？やめてください死人が出ます。
答え：「Genko.txt」の内容を「Sadoku.txt」の内容で上書きして、 Git の編集履歴に積む。
どういうことなのか。 2.1 で示した図をもう一度示します。
ここで
「古いファイル」は査読前の「Genko.txt」に相当します。
「新しいファイル」は査読後の「Sadoku.txt」に相当します。
Git の機能を使えば「編集対象を古いファイルにする」ということもできます。
そして、機械的に表示される査読結果との差分を確認しながら修正し、新たな編集結果を Git の先頭に積めばおしまいです。
先述しましたが、これは現在の Google Document には存在しない差分比較機能です。
また、新たな編集履歴と、査読結果の差分を確認することで「指摘された内容を修正し忘れる」という悲しいミスも防げます。
2.5. 何か思いついたら GitHub の issue 機能で共有する
雑誌に寄稿する際、同じく寄稿する方々の原稿を読んでいました。相互校正を実施し、原稿の品質を高めることが目的です。
もちろんこれにリンゴが参加することはできず、 参加者全員による相互校正は Google Document で実施されていました。お察しください。
まあそれはそれとして、相互校正を実施している最中に、校正・校閲の基準を明確化する必要があることに気付いたので issue にスレッドを立てました。
片倉とリンゴの間でもこの基準によって提案がなされたなら、感情的な言い合いにならず、より建設的な議論ができると思ったためです。
図2-5-1 issue に書き込んだ思いつき
これは片倉がスマホから書き込んだ覚えがあります。
図2-5-2 思いつきに対する反応と追記
リンゴからの追記提案があったので追記しました。
議論が盛り上がってまとまったら、新たなファイルを作成して Git の編集履歴に積み、ドキュメント化すると良いでしょう。
issue から生まれたドキュメントが積み上がると、良い感じのプロジェクトに育っていきます。
そういえば、 GitHub で参加者全員の原稿を共有して、参加者全員で相互校正ができたら捗っただろうな、と、今になって思います。
できなかった理由はいくつかあります。
- 他の参加者の原稿をリンゴに見せるわけにはいかなかった
- 片倉が GitHub の使い方を学習している最中で他の人に教える余裕がなかった
- 他、色々な力学の影響
今回は無理でしたが、今後はやっていきたいですね。
3. Git が必要でない人と必要な人
実のところ、 Git なんて使わなくてもいいぜ！って人もいます。
この記事を書いている片倉は Git 使わなきゃダメでしょ、って人です。
3.1. Git が必要でない人
人間性能がお化けな人です。
ちょっと前に SF 作家の小川一水さんが WinMerge を使って驚いていらっしゃいました。
WinMerge、実際の使用画面です。作家の人はこれ見ただけで飛びつくんじゃないかな。 pic.twitter.com/o1eoRZcnJs
— 小川一水 (@ogawaissui) 2018年12月1日
これについて色々な声がありますが、ご本人がこのように仰っています。
なお、gitどうよという声もありますが、私はさっきひのきの棒の代わりに鉄の槍を得て、さまよう鎧なんかを喜んで倒しているところなので、ロトの剣を探すのはもうちょっと冒険が進んでからにさせてください。
— 小川一水 (@ogawaissui) 2018年12月1日
あの……皆さん、この方が「小川一水」さんであることをお忘れなのではないでしょうか。
これって実のところ「ひのきの棒で歴代の魔王を倒してきた」という、人間性能が化け物めいている勇者が発した言葉なんですよね。
あるいはレベルカンストした格闘家が「俺ってもしかして鉄の槍持ったら強いんじゃね？」って言ってるようなものです。
強いに決まってるだろ！！！
これを小説の執筆（厳密には文章全般）に置き換えて考えましょう。
彼らは肉眼で grep とかできちゃうわけです。機械に劣らぬ精度で。しかも即座により良い文案をサジェストする超高級な機能まで備えてるんですよ。
そんな人たちにとってはパソコンもワープロもタイプライターも「ペンより速く書けるし修正も楽な筆記用具」なので、 Git なんていうややこしい道具は要りません。
Git の学習コストを執筆コストに充てた方がいい、選ばれた人々です。
3.2. Git が必要な人
人間性能が並みの人です。
ご安心ください、だいたいの人は人間性能が並みです。
片倉なんて並み未満です。具体的にはフィジカルとかメンタルとかが。
そうです。人間性能が並み、あるいは並み未満な我々は、テクノロジーの力を借りて人間性能お化けな人々に食らいつくのです。これをダークサイドと言います。
4. 導入方法
4.1. 初学者が Git を導入するにあたって最低限必要なもの
-
Git
当たり前っちゃ当たり前なんですが、お使いのパソコンに Git をインストールする必要があります。
https://git-scm.com/ -
GitKraken
本来、 Git はコマンドライン (CUI) で操作します。
でも GUI に慣れきった初学者がコマンドラインなんて操れるわけがないので、とっとと GUI で基本的な Git 操作ができるツールを導入しましょう。
GitKraken は Windows でも Mac でも Linux でも動作します。Git の操作を直感的に理解しやすくなるため、初学者にお勧めです。
なお、GitKraken は個人利用、オープンソース、非営利、教育目的の場合、無償で利用できます。また、商用の場合でも条件付きで試用することができます。
https://www.gitkraken.com/
利用条件
他の優秀な方々が紹介しているので、細かなインストール手順はここでは書きません。
例えば以下のような記事があります。参考にしてください。
GitKrakenを試してみる - Project Unknown
本記事では GitKraken を Git の学習目的で使うことを想定しますが、他にも「Git GUI」等のキーワードで検索してみると、多くの GUI ツールがあります。
例えば Sourcetreeにも無料評価版があります。
自分に合うツールを探してみたり、 Git を使っているよという人に尋ねてみるとよいでしょう。
ちなみに、必須ではありませんが Visual Studio Code (VSCode) も一緒に導入すると便利です。
VSCode は Microsoft が提供している無償のソースコードエディタです。
シンプルな設計でありながら、単なるテキストエディタに留まらない汎用エディタです。
VSCodeの利点
-
軽快に動作するテキストエディタである
プログラマがよく利用する IDE と違って、ブラウザを起動するくらいの速度で起動します。
メモリはそこそこ食います。 -
Git の管理下にあるファイルが少しでも更新されるとバッヂが付く
こんなふうにね。
4.2 初学者がまず覚えるべきこと
4.2.1. 使い方より仕組みだ
Git の初学者がまず覚えなければならないことは、 Git の仕組みです。
Git の操作？そんなものは後回しです。
片倉
Q. Git とは何ぞや？リンゴ
A. Git とはデータベースであり、その実態はコミットを一つのブロックと見なしたブロックチェーンである。
ブランチとは、コミットに付けられたラベルである。
これらブロックチェーンとラベルを利用することで、ファイルのバージョン管理を行う。
……念のために書いておきますが、本記事は Bitcoin や暗号通貨の解説記事ではありませんよ。
4.2.2. ブロックチェーンについて少しだけ
少しだけと言いつつちょっと長いのですが、大事なことなので。
そもそもブロックチェーンは Bitcoin で初めて採用された技術ではありません。
ブロックチェーンの基礎となる技術は NTT データが 2006 年に実用化しています。
また 2009 年には ISO/IEC 18014-2 にも「ファイルをセキュアに保存する規格」として同技術が制定されています。
つっても、リンク先を読んでる暇なんてありませんよね。ISOのサイトなんて英語ですし。
誤解を怖れず、極端に簡潔化して書いてしまいましょう。
ブロックチェーンとは、
「改ざんがめちゃくちゃ困難な、片方向連結リスト」
のことである。
……これも念のために書いておきますが、この記事を書いている片倉青一なる者の本業は、エンジニアではありません。主に SF 小説を書くので、一応は技術を追いかけているだけです。
10 年以上も前に実用化された技術なので、片倉が概要を知っていてもおかしいことはありません。プログラマではないので実装はできません。
さておき、理解を促進するために図解してみましょう。
図4-2-2-1 超大ざっぱなブロックチェーン
図4-2-2-2 あるデータが壊れた場合
図4-2-2-3 データ破壊の連鎖が起こる
Git はこのブロックチェーンを、次に示す図のように利用しています。
図4-2-2-4 Git はブロックチェーンである
1つのコミットは、 Git 管理下にあるファイル群のスナップショットです。
具体的には以下のような対応関係にあります。
図4-2-2-5 コミットとファイル群の対応関係
さて、最初とはちょっと違う言葉で、 Git の概念を表現してみましょう。
Git とは、コミットを1つのノードと見なす、片方向連結リストである。
コミットに付与されたラベルをブランチと呼ぶ。
4.2.3. 操作より概念が先である理由
Git がブロックチェーンである、という概念を理解していないと、トンチンカンな操作をしてしまいます。
どれほど優秀な道具でも使い方の基本を知らないと凶器になるのは同じです。
具体的には
- 存在すべきファイルを消してしまったり
- 本当は存在するのに、必要なファイルが存在しないと言って騒いだり
- 特定のブランチで編集しなければいけないファイルを別のブランチで編集してしまったり
します。
察しの良い方はお気づきでしょうが、片倉は全部やりました。ごめんなさい。
一応、最初の頃に「ああ、ブロックチェーンなのか！」と言って基礎的な概念は理解したんですが、 Git の理解が不十分だったり、 Git の文化を知らなかったり、単なる操作ミスだったりと、色々な原因で間違いをやりました。
Git に慣れてくると好きなようにブランチ（ラベル）を特定のコミットに付け替えたり、ブランチ間を飛びまわったり、特定のコミットに戻って好きなファイルを抜き出してきたりと、安全に遊ぶことができるみたいです。
片倉はまだできません。やれるようにはなりたいと思っています。
4.3. なるほど Git の概念は理解したよ。次はどうしたらいい？
役割によってやることがちょっと違ってくる。
4.3.1. 君が作家なら
さあ原稿を書くんだ。
原稿を書いた1日の終わりに、変更をかけたファイルを git add . してgit commit してコミットメッセージに「mm月 dd日 x,xxx字」と書いて積み上げるんだ。
もちろん git fetch とか git status で常に状態をチェック……
おっとそうだった、 GitKraken を使っているのだった。
その日の執筆を終えてファイルを保存したら、 GitKraken を起動しよう。
そうすると画面上部に // WIP: ... と書かれた空欄が現れるはずだ。
図4-3-1-1
- そこに「mm月 dd日 x,xxx字」と入力する（赤字）
- その日に変更したファイルを全てステージする（橙字）
- コミットする！！（水色字）
以上だ。積み上げるだけならだいたい問題はない。
それだけで、バックアップ、進捗状況、変更した履歴の差分、全部が Git に保存され、 GitKraken で確認できる。おしまいだ。
最初はそれだけでいい。
4.3.2. 君が編集者なら
もう少し Git について詳しくなろう。
ブランチを作成したり、ブランチを切り替えたりできるようになろう。コマンドラインを使った操作も覚えよう。
リモートリポジトリ、具体的には GitHub の管理方法を覚えたりもしよう。
そうしてもう少し詳しくなったなら、 GitHub の有償プランを購入してプライベートなリモートリポジトリを作成し、作家には「定期的にここへ push してくれ」と伝えよう。
一応、無償プランでもパブリックなリモートリポジトリなら作れるけれど、売り物のデータをパブリック（公開）にするわけにはいかないと思う。プライベート（非公開）のリポジトリを作るなら有償プランを購入しよう。最も安いプランなら1ヶ月にたったの7ドルだ。
ものすごい円安ドル高にでもならない限り、お値段以上の効果を発揮してくれるはずだ。
4.4. 執筆が終わったよ。どうすればいい？
いつの間にか変てこになっていた口調を元に戻します。
執筆作業が終わってからが Git の本領発揮です。
にて述べたように、いつ、なにが、どのように変更されたのか、ということが分かると、先述したように実に色々なことができます。
- 進捗が一発で分かる
- 過去に書いた文章を再利用しやすい
- 校閲するとき GitHub の諸機能がめちゃくちゃ便利
- Git や GitHub を使えない人に査読を依頼する時も楽
- 何か思いついたら GitHub の issue 機能で共有する
きっとこれら以外にもメリットがあるのでしょう。
5. なぜ小説作家や編集者は Git を導入しないのか
小説を書いている人で Git を導入しているという話はあまり聞きません。
もちろん、いくつかの事例は存在します。
-
円城塔『文字渦』出版インタビュー
これは GitHub を活用して円城塔さんへのインタビュー記事をパブリックリポジトリにて管理し、 type.center へ掲載する、という野心的な試みです。パブリックでやっちゃうの凄いな。 -
編集者に原稿送ったらGithubに取り込まれて、修正はPullreqになり、方針はIssueで相談「これだよ、現代の編集は」
ちょっと前にバズってた奴です。色々な意見があって「ザ・ツイッターランド！」って感じですね！ -
小説をGitでバージョン管理する。そして、GitHubでコラボレーション…… - おーびるの原稿用紙
Git は良いぞ！という記事。実際に運用していらっしゃるようです。ただ、「ガルパンは良いぞ！」と言えば観る人は観ますけど、「Git は良いぞ！」と言って見せても見るだけで終わるんですよね。
片倉の知り合いにも何人か Git で小説を管理している人がいます。本業は IT 屋さん、という方が多いような印象があります。
ですが、全体としては Git が小説作家や編集者には浸透している、とは言いがたい状況です。
これまで片倉が述べたように、作家視点から見ても Git はとても便利です。
では、なぜ小説作家や編集者は Git を導入しないのでしょうか。
実例（サンプル数1）と推測を述べてみましょう。
5.1. 新しいツールの導入が面倒くさいと思っている
はい、これは片倉のことです。
確かに新しいツールを導入するのは面倒です。
ツールを使うための環境を整備しなければいけません。
ツールの使い方も覚えなければいけません。
Windows から Mac に移行することが億劫に感じられるのと同じようなものですね。
これまで使ってきたツールを放棄することにもなり、これはいささかもったいない気もします。
ただ、これは単純にものぐさなだけです。
仕組みを理解して、実際に手を動かせば、できます（サンプル数1）。
5.2. プログラマのためのツールだと思っている
確かに、 Git はプログラミングに最適化されたバージョン管理ツールです。
そもそも Git が作られたのは Linux という OS のバージョン管理を行うためでした。
ですが、よく考えてみてください。
Git の操作そのものは、実のところプログラミングではありません。
Word や Google Doc においてマウス (GUI) で行っている操作を、コマンドライン (CUI) で実施しているだけのことです。
PC に命令を与えている、という点では同じなのです。
もちろんインターフェースの違いは大きいでしょう。
片倉も GUI に慣れきっていたので、いきなり CUI に移行することはできませんでした。
ですが、現在では GitKraken のように優秀な GUI ツールがあります。
それでも Git がプログラマのためだけのツールだと言い張る方は、 WEB サイトを閲覧する人のほとんどが使っているツールが何か、ちょっと考えてみるといいのではないでしょうか。
5.3. Git の初心者向け解説を読んでも理解できない
これには2通りのパターンが想定できます。
5.3.1. 解説記事が悪い
これは実のところリンゴがぼやいていたことです。
世の「初学者向け Git 解説記事」的なものを漁っても、だいたい
Git とは分散型のバージョン管理システムである。
としか書かれていません。
いやまあ、そりゃそうなんですけど、初学者に解説するなら
Git はデータベースであり、その実態はコミットを単位としたブロックチェーンである。
ブランチとはブロックに付与されたラベルである。
という本質的な仕組みに言及するべきでしょう。
職業が IT エンジニアであるにもかかわらず Git は難しい、理解できない、という方が、現実にいらっしゃいます。
このような方々は、データ構造などについては片倉よりも詳細に理解しているはずです。片倉はクラスとか継承とかポリモーフィズムとかを使いこなせませんから。
にもかかわらず、なぜ IT エンジニアの方々が Git を難しいと感じるのか。
これはおそらく Git の初歩を解説するにあたって
Git とはバージョン管理システムである
と言ってしまう人がいるからです。
この定義、めちゃくちゃ広すぎますし、 Subversion (SVN) にも当てはまるので、不適切です。
「自動車は人を乗せて走る内燃機関式の機械である」くらい広い定義です。
リンゴいわく「SVN なんてクソシステム使ってられるか！」と言った人が Git を作ったらしいです。
同じ範囲の定義にしちゃったら Git の制作者がキレると思います。
5.3.2. データ構造という概念に親しみがない
これもリンゴが指摘したことです。
Git を理解して使うためには、おそらくブロックチェーンがどのような振る舞いをするのか、くらいは知っておく必要があるでしょう。
片倉は大学の情報工学科にいたので、何とか卒業できる程度には「データ構造 is 何」ということを知っていました。
でも、世の中にはデータ構造の理解どころか、グラフを読むことさえ難しい人がいるのでした。
片倉は、そういった人々をくさしたいわけではありません。
そういった人々に「データ構造 is 何」と説明できる方法を、片倉は思いつかないのです。
一方、文学部文学科で文芸思想を専攻した後、 Git とか Backlog とかを使いこなしてフロントエンドの WEB 開発をしている人もいます。片倉の知り合いです。
その人は小説の原稿管理も Git でやっているそうです。
これ、どうしたらいいんでしょうね。
そのうちインタビューでもしますか。
5.4. 本当に Git が必要ではない
でも述べましたが、 Git を必要としない人は確かにいます。
ですが、それはその人の人間性能が機械（PC）の性能をあらゆる面で上回っているからであって、そんな人はごく少数です。
5.5. 本当は Git が必要だけど必要ないと思っている
ご自身のことを人間性能お化けであると信じている方です。
この手の方には何を言っても無理なので無理です。
ファイル名に日付を入れて管理しててください。
5.6. 執筆にあたってパソコンを使っていない
なるほど。いわゆるモバイル端末で書いている人は Git に触れる機会が少ないかもしれません。
ソフトウェア開発は現在でも PC で行うことが標準的です。
4.1. 初学者が Git を導入するにあたって最低限必要なもの
でご紹介したのも PC 用の Git クライアントです。
ですが、主要なモバイル端末の OS である iOS と Android では Git のクライアントがリリースされています。
ちょっと調べただけでも、以下のように評価の高い Git クライアントが見つかりました。
-
iOS
Working Copy -
Android
Pocket Git
モバイル端末で書いているならプレーンテキストの方が扱いやすいでしょうから、むしろ PC よりも Git との親和性が高いのではないでしょうか。
いまどきネットに繋がっていないタブレット端末なんてほとんど無いでしょうから、 GitHub も普通に利用できます。
ポメラ？ いえ、知らない子ですね……
5.7. Git の学習コストが高いと感じている
確かに Git はいささか難解に感じられます。
コマンドラインで操作する文化、より厳密には「目に見えないものを操作する文化」にそもそも馴染みが無い、という方は多いでしょう。 Git のコマンド名もちょっと意味が分からないものがあったりします。何やねん rebase て。
プログラミングと小説の執筆はあまりにも異なる文化を歩んできたので、文化のハードルを超える、という最初の一歩を踏み出しにくいのかもしれません。
片倉もまだ完全には理解していませんし、しょっちゅう操作ミスをやらかします。
TeraPad や秀丸など、プレーンテキストのエディタだけを扱う、という方から「学習コストが高い」と言われるのは仕方のないことかなと思います。
ですが、 Word や G Suite 、一部で人気な Scrivener については、 Git より学習コストの方が高いと思います（片倉の主観）。
小説を執筆する、というポイントに限って Word を使う場合を考えてみましょう。
ご存じの通り Word はとてもとてもお節介な奴です。
- デフォルト設定において行頭でスペースキーを叩くと、自動的に「書式として」段落字下げしてくれます。更に、その段落においてエンターキーを叩くと「書式として」の段落字下げを継続してくれます。
- 段落字下げをしないように設定することもできますが、めちゃくちゃ分かりにくいところに設定項目があります。
- 最近、設定したはずの設定が反映されなかったり何だりとトラブルが続いてうんざりしてしまい、片倉は Word を心の倉庫に放り込みました。ファイルを受け取るためにやむなく使う程度です。
- 「見出し」「目次」「本文」などなどで、異なる書式を勝手に設定してくれやがります。
- その書式設定が現在編集している行だけに適用されるのか、編集中の文書全てに適用されるのか、それとも全ての文書に適用されるのか、ちょっと分かりづらいです。「ちょっと」が積み上がると凄い量になるんですよ。知ってました？
- 書式のようなメタデータが見えないことが最大の原因なのですが、 WYSIWYG なエディタはメタデータを見せないことが売りなので、お手上げです。
- 「見えないけど存在する文字列」とかがあってもお手上げです。
- 例えばうっかり白背景に白文字で書いてしまったら？
- しかもその手の構造的欠陥を「ノウハウ」として日常的に使っている人がいたりします。
- あまり悪く言うと自分に返ってくるので止めます。
Word のお節介を排除しつつ自在に扱えるようになるまでに必要な期間は、たぶん数ヶ月ではきかないと思います。
それでも Git の学習コストが高いと感じられているのは、おそらく Git の本質を正しく解説できる人が世に少ないためです。
この記事を書いている片倉は、小説の原稿管理に必要な機能に限って言えば、 Git を4ヶ月ほど、ゆっくりと学んで覚えました。
リンゴという良質で熱心な教師がいたからだと思います。
5.8. 個人ではどうにもならない大いなる力が働いており Git を導入できない
あるいは個人で Git 管理していても、後の工程において Git 管理の労力は無駄になる。
とても悲しい話です。
でも、そうはならなかった。ならなかったんだよ、ロック。
だから――この話はここでお終いなんだ。
BLACK LAGOON, 003, #15 Bloodsport Fairy tale PT.5. 広江礼威. 小学館. 2004.
6. それでも Word や Google Document を使ってしまう理由
まず、以下の記述は片倉の憶測でしかないことを断っておきます。
WYSIWYG（見たままが得られるの意）が売りのエディタは、紙でやっていたことを再現できる、という点が嬉しいのではないでしょうか。
この記事を書いている片倉自身、原稿をプリントアウトして赤ペンを持って校正校閲を実施することはあります。
でもそれは紙でやればよいのであって、 PC でやる必要は無いのでは？と思います。
……これ以上の議論するとなると、思想も絡んでくるのでやめましょう。
片倉は、原稿データ（オブジェクト）と書式データ（デザイン）は別々であることが望ましいと思っています。
そして Word や Google Document ではちょっと難しいかな、と思っています。
7. まとめ
-
小説作家と編集者は Git と GitHub を覚えるべきだ
- メリットは以下の通りだ
- 進捗が一発で分かる
- 過去に書いた文章を再利用しやすい
- 校閲するとき GitHub の諸機能がめちゃくちゃ便利
- Git や GitHub を使えない人に査読を依頼する時も楽
- 何か思いついたら GitHub の issue 機能で共有する
- たぶん他にも色々なメリットがある
- 難しいと思われているが、それは仕組みを正しく理解していないからだ
- 理解にあたって英語を読む必要は（あまり）無い
- 理解の道筋が付けば Word や G Suite よりよほど学習コストが低いのだ
- メリットは以下の通りだ
-
あなたが人間性能お化けであるならこの記事の対象外である
- 個人の力ではどうにもならないことがあるなら、それも諦めていい
以上です。
どえらく長い文章になりました。15,000字くらいあります。ワオ。
間違ってたら指摘してください。直します。
完全なる余談
現在は新しい小説の企画書をマークダウン記法で記述し、 Git のローカルリポジトリにぽいぽいとコミットしています。
設定資料を作っている段階なのですが「前に記述した後に捨てたけど、やっぱ必要だったわ」という設定内容を掘り起こすときなんかに役立ってます。
コマンド操作にもそこそこ慣れてきました。
コミットした後に思いつきでちょびっと追記したけど、コミットするほどの修正でもないな……という内容は --amend オプションで書きかえてます。
こちらは Git 操作の監視役がいません。自分でやらねば。がんばろう。