本の原稿のバージョン管理を始めて20年たちました

「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。

目次です。

前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。

なんで「テキスト原稿のバージョン管理」の話をしなくなったか

いまからちょうど10年くらい前までは、「このスタイルでの書籍制作を自分以外にも広めるべきだ」という考えがうっすらありました。 当時在籍していた出版社の中でほかの編集者に勧めたり、外で発表したりすることも何度かありました。

Our docsys-pyfes-2012-11 from Keiichiro Shikano

www.slideshare.net

しかし、今はもうこのスタイルでの編集をあんまり内外で特別に喧伝することはなくなっています。理由は3つ。

1. 自分の中では当たり前になってしまったので
2. テキスト原稿のバージョン管理を個人ではじめる編集者がぽつぽつ増えてきたから
3. その一方で、出版業界という粒度で見ると、ちっとも変わる気配がないし…

1つめの理由は、ようするに、自分が外向けに積極的に情報発信するくらい強い関心をもつ対象がもっと別のところにいった、ということです。飽きたともいう。

2つめの理由は、いい話です。中には、自分が過去にした情報発信を見てくれているような人もいて、ふつうにうれしい。そういう人たちが自分よりうまいことやってくれたら、それを真似できるので、さらにうれしい。

3つめの理由は、かっこよくいえば、諦観です。いくら情報発信しても変わらないなら、その人たちには不要ということです。 現状のまま、つまり「誌面レイアウトしたPDFとか紙に赤字を入れる」というスタイルでの編集でうまく回っているなら、自分がしゃしゃり出て「テキスト原稿のバージョン管理のノウハウとか共有します」って言っても迷惑なだけだろうなって。

「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理…

なんか最近になって再び、文芸系の著者サイドから「誌面レイアウトしたPDFとか紙に赤字を入れる」というスタイルについての恨みつらみが漏れ聞こえてくるようになりました。 編集者との赤字の共有が大変とか、手元ではテキスト原稿をバージョン管理しているけれど編集部には使ってもらえないとか、組版されるともうバージョン管理できないとか、そういう声です。

「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集のスタイルには、編集者や著者による濫用で、組版をお仕事にしている人たちが泣き寝入りすることになるという問題もあります。 これは組版業界では昔ながらの恨みつらみなので、SNSで顕在化されやすくなっただけではありますが、むしろ課題としては根深いやつだと言えます。

同じような恨みつらみは、著者や組版担当者だけでなく、編集者サイドの目線でももちろん存在しています。

• 初校に対する著者の赤字を転記しそこねて、再校出しで平謝りすることになった
• 組んだ状態で読んで文章構成から直したくなった著者が全面に赤を入れ、ほぼ組み直しになってしまった
• 赤字が意図通りに反映されていなかったので、指示をやり直すことになった
• 校了後にはじめて編集による修正に気づいた著者とトラブルになった
• 全体に同じパターンの修正指示が必要だが、数百カ所すべてに赤書きするのも、その赤字引き合わせをするのもつらい…

従来、これらのありがちな事態を防ぐために取られてきたのは、「著者との円滑なコミュニケーション」や「組版担当者との責任境界の明確化」、あるいは「余裕をもった入稿スケジュール」といった「人間の心がけ」ベースでの対策でした。 紙への赤字をスキャンしてやり取りできるようになったり、PDFのコメント機能の導入でテキストのコピペができるようになったり、パソコンやDTPソフトの機能向上で作業が効率的になったり、そういう意味では「コンピューターを活用」することで緩和している面もありますが、問題そのものの氷解には程遠いのが現状です。

そこでテキスト原稿のバージョン管理

上記に挙げたような各種の問題を根本的に消滅させるには、「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集の進め方を捨てるのが手っ取り早そうです。 なので、ぼくは20年くらい前に「誌面レイアウトしたPDFとか紙に赤字を入れる」という編集スタイルを本づくりから段階的に廃止しました。 その代わりとして採用したのが、「テキスト原稿のバージョン管理」という編集スタイルです*1。

テキスト原稿のバージョン管理による編集の最大の強みは、「一連の編集フローにおいて徹頭徹尾コンピューターを活用できること」です。 おかげで、上記のような辛い事態が原理的に起こりにくくなります。

ただし、編集スタイルが従来とはまったく違うので、書籍に携わるステークホルダー全員がその変化を抱擁する必要があります。 実際、自分もいきなり従来の編集スタイルからこの編集スタイルに切り替えたわけではなく、最初の数年間は自分が直接関与する部分だけで小さく始めました。 そこから徐々に「自分が直接関与する部分」を増やしていって、完全に切り替えできるまでにはおそらく数年かかっています。

具体的にどうすればいいのさ

こういう話をすると、往々にして、「そうはいってもGitのようなバージョン管理システムは本の編集には向かないのでは？」という方向に議論が進みがちです。 実際、「Gitでテキスト原稿を共有してみたけど、著者とのコラボレーションがうまくできてる気がしない。どうすれば…」と感じたことのある編集者は少なくない気がしています。 これまでの自分の経験でも、バージョン管理システムをそれまでの編集フローに導入しても、新たなフラストレーションを生むだけに終わることが多々あります。

しかしこれは「Gitのようなバージョン管理システムは本とかの編集には向かない」ことは意味していません。 あくまでも、「従来の編集フローをサポートしてくれるツールではない」というだけです。 というか、前節で触れたように、ぼくがテキスト原稿のバージョン管理を採用しているのは、もともと「誌面レイアウトしたPDFとか紙に赤字を入れる」という従来の編集のやり方を捨てるためです。 従来のやり方を捨てる勢いがなければ、テキスト原稿のバージョン管理も、そのためのツールであるGitのようなシステムも、本領を発揮できないというだけです。

従来のやり方を捨てるといっても、具体的にはどうすればいいんでしょうか？

ここで、編集という仕事がそもそも何をする仕事だったかに立ち返りましょう。

私見では、編集とは「原稿のありうべき形」をいろいろ検討し、そのなかで最適な姿を著者と選択していくという仕事です。 原稿→脱稿→初校→再校→…という進行をこなしていると、どうしても「原稿を段階的に改善していく」という発想になりがちですが、実際にそのフローの各段階でやっているのは、原稿を修正しうる無数の可能性を吟味し、それを赤字やコメントという形にして著者や組版担当者と共有しつつ適用する、という作業なはずです。

バージョン管理システムが有効なのは、この作業、つまり「原稿にありうる無数の可能性を追求する」という部分です。 無数の可能性は、Gitのようなバージョン管理システム上では「ファイル間の差分」という形をとります。 「原稿にありうる無数の可能性」を、コメントや赤字のようなコンピューターで管理しにくい形でなく、ファイル間の差分として見ることが、テキスト原稿のバージョン管理という編集スタイルの勘所です。 言ってみれば、「修正案を作りまくっても、Gitが勝手にうまいこと管理してくれてるんだから、なにも気にしなくていいぞ、ひゃっはー」という感覚です。

まとめます。

• 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する
• そのために、「原稿はコンピューターで差分を自動取得可能な状態でなければならない」という感覚に慣れる
• それらの「差分」をうまいこと管理してくれるのがGitのようなバージョン管理システムだと理解する
• 著者と編集者が互いにこの感覚を持てるようになれば、「テキスト原稿に対する書き換え案を出しまくる」ことで編集ができるようになる

最後に宣伝です。もし「自社で積極的にテキスト原稿のバージョン管理を検討したいから、このへんのノウハウを聞かせてほしい」という出版社がありましたら、[email protected] にぜひお声がけください。

*1:実際にはこれに加えて「自動組版」という技術も重要なんですが、今日はこの話はなし。