Markdown原稿をGitHubで管理して本にする仕組みが出版社で導入されないわけ

これ、FAQっぽいんで、ちょっと私見を書いておこうと思います。

とくに技術書に関しては、Markdownで原稿を書きたいとか、修正はPull Requestでもらえると楽とか、そういう便利な世界を知っている人たちが執筆者なので、 「MS Wordで書いてもらった原稿を、こちらでDTPの担当者に組版してもらいます。修正は紙に赤字か、PDFをメールで送るので、そこにコメントを入れてください」という古き良き時代の出版社のやり方を目にすると、 「出版社って遅れてるよなー」という感想を抱かれることが多いのだと思います。 その結果、「自分たちはITのプロとして出版のためのプラットフォームを作れるだろうから、それを使ってもらえないものか」という方向の考え方に至るのはよくわかります。

しかし、これには、二つの面から「ちょっと認識が違うから待って」と言いたい。

まず「認識が違う」と思うのは、プレインオールドでない方法も部分的にはすでにけっこう導入されているという事実です。 とくに自分は、全面的に「マークアップ原稿を最後の最後までGitHubで管理する」ための仕組みをもう何年も実際に運用して売り物の本を作ってきました。 なので、「出版の中の人は現代的なプラットフォームを使えない」と言われると、どうしても「ぼくはちがうもん」と言いたくなるんですが、なんで自分はできてるのか、という点についてはあとで改めて書きます。

もう一つ、「出版のための現代的なプラットフォームが必要」という話に対して「うーん」って感じてしまうのは、 ルールが決まってる組版で自由な表現をするための仕組みはどうするの？という点に対する回答がないことです。 これは、原稿の形式と版管理ではどうにもならない問題です。

実際にそういうプラットフォームで売り物の本を制作してきた経験からすると、毎回いちばん頭を悩ませるのは、 プラットフォームをチューニングして、「今回のプロジェクトで作りたい形の本を作れるようにする」部分です。 毎回同じ体裁で似たような本を作るなら、yamlなどの設定を書き換えることによるシステム的なチューニングだけで済むかもしれません。というか、実際に済んでいます。 それでも、そのチューニングができる人が出版社の中に必要になるんですが、その程度なら、まあ、システムのお守りをする人がプロジェクトごとに担当者に要件を聞いて調整すればいいでしょう。 頭が痛いのは、「この本では見出しでこんな表現をしたい」とか、「強調をいくつか使い分けたい」とか、「標準的ではない構成にしたい」とか、そういう個別の本の中身に対する要求に合わせたチューニングです。

そういう要求を吸収できるようにシステムを作りたいということであれば、Markdownの原稿では絶対に無理（無理）なので、素直にLaTeXでもなんでも既存のプラットフォームを使おうよ。。（本音）

勝手が許されない「組版」と、自由な「レイアウト」と、それを吸収するプラットフォーム

出版物は、特に紙の本は、歴史がそれなりにあるので細部のルール（いわゆる組版）がわりときっちりしてます。 そのルールを逸脱していると、単純に読みにくい本になります。 このへん、ブラウザのレンダリングに任せればいいという発想でWebページを作るのとは違っているので、 たとえソースがXMLベースの原稿でも、本気のページ組版のためには、通常のブラウザエンジンではなく専用のフォーマッターが使われています。 もしブラウザのレンダリングエンジンでJavaScriptとCSSを使ってきちんと組版しようと思ったら、専門の会社を一つ作らないといけないレベルで大仕事です。

そんなわけで、出版物というのは、組版というミクロな部分の見た目についてはあまり融通が利きません。 誰でも使えるInDesignというアプリケーションがあるのにDTPがプロの仕事として成立してるのは、 一昔前の業種がいつまでも生き残ってるのでも、デザインセンスが必要だからだけでもなく、組版という仕事が本質的に専門知識を要求されるものだからです。

そうはいっても自動組版したい人、軽量マークアップの原稿を機械的に組版したい人にとっての選択肢は、いまは主にバックグラウンドでLaTeXを使うプラットフォームになると思います。 で、そのLaTeXですが、ご存じのとおり鬼門ですよね。 もっとも、Markdown+PandocやSphinx、Re:VIEWでとりあえずページ組版されたものを出すなら既成のスタイルを使うだけなので、とくに苦労はいりません。

問題は、ちょっと違った見た目にしたり、新しいレイアウト要素を追加したかったりする場合です。 これにはLaTeXのコマンドを使って自分でスタイルを書くしかありません。 しかも、新しいレイアウト要素を追加するにはそれだけでは済まず、ソースにおける構造とレイアウトとのマッピングを定義する必要があります。 自分は、このような拡張が簡単にできないと死ぬと思ったので、かなり早い段階でそのためのDSLを開発してました。 これまで十年くらい、「マークアップしたテキスト原稿を版管理」しながら「本として最後まで作り込む」という環境を実現できてたのは、こういう仕組みを作ったからです。

なお、これは自分だけでなく、「マークアップしたテキスト原稿を版管理」しながら「成果物として最後まで作り込む」を実現している人は、だいたいこのような構造とレイアウトのマッピングをする仕組みを自分たちで作り上げてるようです、というのを昔開催した「版管理＋自動組版」という勉強会で知りました。

厄介なのは、そういう仕組みを「誰もが使える」ようにする点です。 GitHubのようなベースとなるプラットフォームを使い始めてもらうためのハードルが高いわけではありません。 自分の経験だと、毎回の書籍原稿における文書の構造とレイアウトを実現するメカニズムの両方をそれなりに理解しないといけないのが唯一の障壁です。 そういうことを考えたい人が中に常駐していないと、プラットフォームがあったところで、多様な個々の本に対してそれを適用し続けることができないのです。

むしろ問われてるのは出版ビジネスの考え方かも

というわけで自分は、軽量マークアップのテキスト原稿をGitで管理して本にするという簡単な仕組みが出版社の中に普及しないのは、 そういうプラットフォームを使って勝手が許されない組版かつ自由なレイアウトを実現しながら本を作り込もうとする人が足りてないことが大きな理由だと思っています。

もっとも、これは「出版する本は作りこむべきだ」という個人的な思いによる分析なので、 単純なプラットフォームで実現できる形の本だけで出版というビジネスを回してやろう、という大胆な発想もありえると思います。 そういう発想を追求したい場合は、米O'reillyのAtlas+Safariのような仕組みや、Pragmatic Bookshelf社の取り組みについて調べてみるとよいと思います。