ということで発売されます。10月26日ごろに店頭に並ぶ予定です。Ebookも絶賛準備中です。
https://www.oreilly.co.jp/books/9784873118468/
今回、いまの職場で初めて紙の翻訳書を担当しました。そもそも書籍の編集を細々と再開したときに自分で決めていたことがあって、その中の1つが「翻訳書は担当しない」という事でした。
理由は主に2つあって、1つは僕のメインの仕事はあくまでデジタルコンテンツだということ。書籍には出すべきタイミングというのがあります。また特に翻訳書の場合、勝手に内容を書き換えるわけには行かないので、コンピューター関連のように日進月歩な分野で制作に時間をかけ過ぎると、内容が陳腐化してしまうことが結構あります。そうなるともう企画が不良債権のようになってしまい、会社に迷惑をかけてしまう。 紙の書籍を作る以外にもいろいろ仕事がある、フルタイムではない状態でそういうものを手掛ける自信がなかったという理由です。
もう1つは今の職場には他に編集者が何人もいて、原書の評価から手掛けているわけで、そこにフルタイムではない自分がのこのこ首を突っ込むのは良策ではないなと思っていたことです。
じゃあ、なんで今回と言えば、もともと翻訳者である山口さん（@ymotongpoo）から「『Concurrency in Go』がよさそうな本なので翻訳に関われたら」という話をもらって社内の編集者に紹介していたのですが、紆余曲折を経た末に社内で「瀧澤がやればいいんじゃね」という事になり、良い本だなという印象と、山口さんとお仕事ができるという点でもちろん異論もなく、編集を担当することとなりました。はい
本書の内容はGo言語でのプログラミングがある程度分かっている読者に向けて、Goの目玉機能の1つである並行プログラミング関連の機能を一通り紹介する、というもの。僕自身、Goについては『Real World HTTP』を編集した時に少しだけ触って、RFC番号を入力するとタイトルを取得してくれる簡単なプログラムを書きRFC番号のチェックをしたくらいだったので、読者対象としてちょうどよいくらいで、とても勉強になりました。
翻訳の山口さんが調べてくれたり、レビュアーの皆さんにご指摘をいただいたりして、たくさんの訳注を入れています。そういう意味でも大変よい書籍になったと思います。実務に携わる皆さんには4章とか5章の実装パターンの所が役に立つんじゃないかなと思います。個人的には6章の「ゴルーチンとGoランタイム」が、ランタイムがどうやって複数のゴルーチンをスケジューリングしているかについての概要を説明していて面白かったです。
さて、本書の制作ですが、訳者も僕もPythonによく触れているので、Sphinxを使って行われました。これまで担当した書籍でもSphinxで執筆をしてもらっていて、その時は僕の方でRe:VIEW形式に変換してからDTPをして編集という工程を経ていました。
これはこれで便利なのですが、いったんreSTからRe:VIEWに変換してしまうと後戻りができなかったという欠点がありました。実はこの制限はreSTをRe:VIEW形式に変換するビルダ、sphinxcontrib-reviewbuilder ができたことで大きく緩和されているのですが、画像のキャプションの扱いや文書内での参照関係など、両フォーマットのスキーマの違いによって、完全にイコールにはなりません。その部分でデグレ―ションを混入させることは工程管理上よろしくない。
また、著者さんや翻訳者さんはそれほどRe:VIEW形式に通じてるわけじゃないので、校正時にソースを直接直したくても手を出しづらかったり、手慣れたreSTでやりたいというフラストレーションがありました。今回、山口さんからも「できれば最後までreSTでやりたい」というご要望をいただき、これを機会にと一念発起して環境を整えることにしました。
『Sphinxをはじめよう』執筆者のお一人である若山さん（@r_rudi）が作ったSphinxプラグインにsphinxcontrib-indesignbuilderというInDesign向けXML形式（というかRe:VIEWのidgxml形式）を出力するビルダがあります。これはもともと若山さんが雑誌で執筆された時に作成されたもので、サポートされたタグがそのとき必要なものだけだったのですが、これに必要なVisitorメソッドを追加しました。またidgxmlでは脚注のテキストを本文中の脚注マーク位置に置くのですが、Sphinxの出力する文書構造とは異なるのでその部分だけ変更するTransformを追加しています。
これで出力したXMLをInDesignに読み込ませるわけなのですが、その時に別途lxmlを使ったフィルタプログラムを用意して、属性値を追加したり対応するスタイルを指定したりしています。この辺はRe:VIEWのメインメンテナである武藤さん（@kmuto）の電子書籍『Re:VIEW+InDesign制作技法』に書かれているものをPythonで書き直したというような内容です。
上記に比べると以下のような感じのフローになります。1工程減っただけですが、実作業としては山口さんにも元のテキストに手を入れていただくのが簡単になったため、ブランチを分けて作業をするのもやりやすくなったり、慣れないフォーマットについて調べたりすることもなくスムーズに作業していただけたと思います（山口さんに「やりやすかった」というコメントをいただきました）。
本書は電子書籍としてPDFとEPUBも制作しているのですが、僕がSphinxのEPUBビルダにそれほど精通していない事と、社内で使っているRe:VIEWを使ったビルドツールがあるので、書籍の校了後にこれまでは前段階で使用していたsphinxcontrib-reviewbuilderを使ってRe:VIEW形式にして、そこからEPUBを作成しました。つまりこんな形になります。
一見、非合理に見えると思いますが、reSTからRe:VIEWへの変換はほぼビルダにお任せなので、大した手間ではありません。また、いったんreSTで校了したテキストを変換しているので、バージョン管理も複雑なものにはなりません（reSTをメインのツリーとみなして、そこから派生するという考え方）。先ほどもお話ししたようにスキーマが違う箇所がいくつかあるので、その辺は手直ししていますけど、1日もかけてないので大したことはありません。
ただし、いくつか制約もあります。今回はGoのプログラミング書で、組版も割とシンプルなものだったのですが、数式が多用されているものだったりすると、現在僕が用意しているツールだけでは対応できそうにありません。また、Sphinxの脚注マークアップはauto-footnote形式（注のナンバリングをツールに任せる記法）にしか対応していません。これは実装の問題なので今後改善される可能性があります。
Sphinxプラグインの方は若山さんのリポジトリにマージしていただいているので、誰でも利用することができます（リポジトリを参照）。フィルタの方は、書籍ごとに細かく手を入れる必要があるのと、InDesignのスタイルに強く結びついているのでプラグインには含まれていません。上記でご紹介した武藤さんの書籍を読みながらご自分でフィルタを書いてみるのがいいと思います。とはいえ、僕が数式が多用される書籍をこのフローで作ることになったら、たぶん武藤さん（の所属されるトップスタジオさん）にお仕事としてご相談するだろうと思います（笑）。
こういうツールを使ったり手を入れたりすることが、書籍の質に直結するわけではないという意見もあります。僕自身もその意見には賛成です。ただし、書き手の側がそれを望んでいて、制作する側がそれに合わせることによって書き手の負担が大きく減らせる、もしくは効率が良くなるというのは事実です。この辺は書籍と雑誌、また出版社ごとの状況にもよるので唯一の解はないでしょう。それぞれの状況に応じて自分で考えるという、当たり前のことをするしかないかなと思っています。
偉そうなことを言っていますが、実のところ、ここに書いたことは森田さんや鹿野さんたちが10年近く前に実現されていたことを2周遅れくらいで追いかけているだけなんです。そういう前を走ってくれる人たちがいるからこそ、こうやって努力の方向性が定まるのだし、それで楽になった分をより本質的な部分の充実に振り向けられたらなというようなことを考えています。
ということで、Sphinxで商業出版したい場合にはぜひご連絡ください。皆さまの玉稿をお待ちしております。
