githubを使って本を書くノウハウの共有

わたしがこれまでにgithubを使って本を10冊以上書いてきたノウハウを共有します。書いた本のほとんどは私と編集者の2人で作った数十ページの同人誌でしたが、それ以外の2冊は数百ページある、書店に並ぶような大物でしたので、本格的に本を書きたい人にもある程度役立つ内容かと思います。

まずは全体的な話。原稿を管理するフォーマットについていうと、わたしはgithub上でのプレビューが楽なこともあってmarkdownで書きましたが、これは自分の好みと出版社が許容するものによって自由に決めてもらえればいいと思います。続いて編集者やレビューアなどの関係者とのデータ共有方法については、単にgithubのアカウントを教えてもらってCollaboratorに追加するだけです。一般的には原稿を管理するリポジトリはprivateにすることになるかとおもいます。

本作りにはさまざまな工程がありますが、わたしはざくっと以下のように考えます。

1. 関係者たちと相談しつつ、「この本は誰に向かってどのような価値を提供したいのか」というポリシーを作っておく
2. 一人でガーっと原稿を書いて、ある程度形にする。
3. 形になった原稿をいろいろな人にレビューしてもらって磨き上げる
4. 磨き上げた原稿を、それ以降のDTP作業に回す。ここから先は編集者を含めた出版社の仕事が主で、かつ、ドラスティックな変更はしない。

わたしがgithubで管理するのは工程1,2,3だけで、工程4は著者校を除き、ほとんど出版社にお任せです。出版社とネゴることも含めて頑張ればDTP作業以降もgithub管理できるのかもしれませんが、わたしはやってないし、この手の知識がないので今後もやる気はないです。

工程1についてはちゃんと決めておかないと後々の工程で苦労します。具体的には、ひたすら「自分は一体何を書いているんだ？」「ゴールはどこだ？」「完成できたとして目的を達成できているのか？」などと、ひたすら悩み続けることになります。

工程2では「本の原稿はコードではない」と意識するのが重要になってきます。コードの場合は「一つの変更は一つの論理的な単位にまとめる」とか「コミットメッセージはなくwhyを必要最小限書く」などのベストプラクティスがありますが、それは原稿には当てはまりません。適宜編集者のかたにアドバイスをもらったりもしますが、だいたいは孤独な作業です。全体的な構成を練るときなど一部例外はありますが、切りがよかろうと悪かろうと作業を中断するときにはmain branchにpushします。branchを切ったとしても、「ああでもないこうでもない」と構成をいじくりまわしているうちに他のbranchと変更がconflictする可能性が高いので、やっても得るものがあまりないです。コミットメッセージは、そもそも変更が論理的な単位にまとまってないので全部「update」とか「fix」などのやっつけなものです。

工程3からは話が変わってきます。具体的には、この段階ではクオリティは置いておいてひとまとまりの文書になっていますし、レビューアなどの関係者が増えています。ここからはissueやPRが活躍するようになります。基本的にはレビューアからまとまった指摘をもらって、その指摘に対処するのを繰り返すことになります。自明な修正についてはPRを発行してもらってマーします。反論があればその旨をPRのメッセージに書いて、変更対象から外してもらったり、変更方法を変えてもらいます。人によって判断が分かれるようなものについてissueを発行してもらって議論して、方針が固まれば自分でissueに対応するPRをつくってマージします(場合によって指摘した人が作ることも)。工程1でポリシー決めをしっかり決めておかないと、「好みの問題」に属するPRを言われるがままにマージしてしまったり、さらに違う人からの「好みの問題」に属するPRをマージして…などなど、とにかく風見鶏のように迷走します。

最初から上記のようなやりかたをしっかりできたいたわけではないのですが、現在はこのようなスタイルに落ち着きました。これから本を書きたいというかたにとって、本記事がなにかの役に立つことを願います。最後に、私のやりかたが唯一絶対の正解とは毛ほども思っていないので、みなさんのスタイルも教えていただけると嬉しいです。