フリーソフトウェア/オープンソースソフトウェアの集合体としてのシステム

ePUBの作成にはいろいろな手法がありますが、制作を支えるシステムを構築する上で最も重視したのは、できる限り自動化し、手作業による調整を最小限にするということでした。そのため、このシステムでは原稿を常に最新マスターデータとしてそこから一方向にePUBを作成するバッチ型としており、たとえばSigilなどでePUBを後で細かに手直しする、といった手法は採用していません。

また、将来にわたって保守・改良が制作関係者自身の手でできるよう、中核部分をフリーソフトウェア/オープンソースソフトウェアで構成し、原稿の形式もオープンなものであることも当然の前提です。

さらに、訳者や編集者など制作にかかわる人たち（このシステムのユーザ）は、文章についてはプロフェッショナルであるもののソフトウェアについてはそうではありません（逆もまた真なり、ですね）。新しくツールを導入したことでそれに振り回されないように、ユーザ側から見て新しく導入するものを最小限にし、面倒な部分はできるだけシステムの内部に置くとともに、原稿の文法エラーチェックなどを自動化し、原稿更新に合わせて即座にePUBやHTMLのプレビューもできるようにする必要もありました。

こうした背景からできあがったのが、次の図に示すシステムです。

オライリー・ジャパンのePUBを制作しているシステム

このシステムで採用している技術やソフトウェアの概要をまとめてみます。

• Debian GNU/Linux

  保守性・ソフトウェアの多様性に優れたフリーソフトウェアのOSです（筆者はこのOSの開発元Debian Projectの公式開発者ですから採用は当たり前ですね ;-)）。各書籍のデータを集約し、ePUB制作の自動化を担います

• ReVIEW

  簡易なマークアップ言語およびその変換器（テキスト、HTML/ePUB、LaTeX、InDesign XMLに変換できます）。ePUB化のための原稿形態の1つとして採用しています。Ruby開発や技術系書籍の執筆者として著名な青木峰郎さんが設計・実装され、現在は筆者や高橋征義さん（達人出版会代表、日本Rubyの会会長）、角正典さん（ワイクル株式会社）が保守・改良を続けています

• DocBook

  SGML/XMLベースの構造化文書形式。このXMLバージョンを、ePUB化のための原稿形態の1つとして採用しています。OASISプロジェクトの委員会が保守しています

• dbtoepub

  DocBook XSLTを利用して、XMLファイルからePUBを作成するツール。Rubyで実装されていますが、中核はXSLT側にあります。オライリー・ジャパンの紙面構成に近い読書感が得られるよう、いくぶん改変しています

• Ruby

  言わずとしれたプログラミング言語です。システム内のいくつかのフリーソフトウェア/オープンソースソフトウェアでも使われているほか、それぞれのソフトウェアのパイプ役としても利用しています

• Ruby on Rails

  RubyによるMVCフレームワークです。このシステムでは、各書籍のリポジトリ（作業プロジェクト）およびユーザーをWeb上から管理するページを提供するのに使っています。このRailsで管理する範囲の規模は小さく、即応性もさほど要求されないため、利用データベースバックエンドには軽量なSQLiteを使用しています

• dRuby

  Rubyの分散オブジェクト実装ライブラリです。Railsアプリケーションと特権の必要な操作（Subversionリポジトリやユーザ情報ファイルの作成・変更・削除、Apacheの再起動など）とのつなぎ役として使用しています

• Apache

  Unix系での事実上の標準と言えるWebサーバです。内部動作しているRailsページやビルド成果物、WiKiを、インターネットを通して共同作業者に公開します

• Wiliki

  Schemeで書かれたWiKiツールです。自動生成には関係していませんが、制作関係者の情報共有のために運用しています

• Subversion

  サーバ/クライアント型のバージョン管理システムです。仕組みの理解が容易で、Windowsクライアント「TortoiseSVN」を始めとする優れたクライアントソフトウェアが揃っていることから、各書籍はそれぞれこのSubversionの「リポジトリ」として管理されます。何か変化が起きるたびに、「フック」という機構を使い、メーリングリストへの差分通知およびJenkinsの自動ビルドが動くように設定しています

• Git

  分散型のバージョン管理システムです。現時点では制作工程で分散型を導入するメリットが低く、また制作関係者への教育コストが高いことから、書籍データのリポジトリとしては採用していません（システムとして対応すること自体はそれほど難しくはないはずですが）。現在の用途としては、Railsや内部ツールのバックアップ先として利用しています

• Jenkins

  継続的インテグレーションツールの代表的存在です。このシステムでは、Subversionのリポジトリに更新があるたび（つまり原稿に修正が入るたび）に、最新のePUBの制作およびプレビュー用のHTMLをビルドし、アップロードします。何らかのミスでビルドに失敗すると、すぐにメーリングリストに通知が飛ぶので、どの時点で壊れたかがすぐにわかります

• GNU Make

  ルールおよび依存関係に基づくバッチ処理ツールで、Jenkinsから呼び出されます。ソースコードやコンパイル済みオブジェクトといったファイルが多数発生してその新旧の判断が重要なソフトウェア開発においては細かなルール設計が大切ですが、このシステムにおいてはほぼ単純なバッチ処理にとどまります

• QuickML

  作成・登録・廃止のコストが低いメーリングリストです。書籍ごと（リポジトリごと）にQuickMLメーリングリストが自動で用意され、制作関係者を収容して互いの連絡をしやすくします。Subversionリポジトリの更新差分やJenkinsのエラー通知もここに届きます

• Trac

  バージョン管理システムと連携したチケット管理ツールです。Subversionリポジトリとセットで自動で用意されます。現時点では少人数による短期の制作作業のため、チケットを実際に使う場面はほぼありませんが、大規模な書籍（紙の書籍）では査読者のコメントなどをチケットとして登録管理することがあります

• Google Docs

  これだけはフリーソフトウェア/オープンソースソフトウェアではありませんが、オライリー・ジャパンとトップスタジオの間の各書籍の進行状況を一覧表にして、「これは編集が終わっている」「これはカバーのファイル待ち」といったことが一目でわかるようにするという補助的な役割として利用しています。いずれはRails上に同等機能を実装できるとよいのでしょうが、リモート同士で同期して入力・保存がシームレスなテーブルを実現するというのは、このシステムを作るよりもたいへんな作業に思えます

聞いたことがあるものもあれば、初耳というものもあるでしょうか。いずれにせよ、オライリー・ジャパンのePUBは特別な魔法で生み出されているのではなく、既存のたくさんのフリーソフトウェア／オープンソースソフトウェアの組み合わせと、ちょっとしたスパイスでできているのです。

原稿からePUBができるまで

前記のように、このシステムではePUBを生成するための原稿データ形式として「ReVIEW」と「DocBook」の2つをサポート対象としています。このたび発表した最初のePUB電子書籍ラインナップ3冊のうち、『Flex 4.5によるAndroidアプリケーション開発』『スケーリングMongoDB』がReVIEW、『マネージャーのための仮想化ガイド』がDocBookを採用しています。ある書籍についてどちらの形式を採用するかは、制作関係者の作業スタイルに大きく依存しており、またそれぞれに利点・欠点があります（次表）。

まずはReVIEWの場合の工程から説明しましょう。

ReVIEWのサンプル

翻訳者または編集者は、ReVIEW形式の翻訳原稿を、まずその書籍専用のSubversionリポジトリに登録（コミット）します（SubversionにもReVIEWにも抵抗ない、という翻訳者はまだそういないので、これを行うのはほぼ編集者ですが）。編集作業も同様に、原稿ファイルを修正してはSubversionリポジトリにコミット、という作業を繰り返すだけです。

さて、何らかのコミットが行われると、Subversionリポジトリにあらかじめ設定してあるフックで、制作関係者のメーリングリストにコミット内容（以前のバージョンとの差分）が送られるとともに、CIサーバのJenkinsに通知が届きます。これを受けてJenkinsは、該当リポジトリに付随するMakefileをGNU Makeで実行します。Makefileの中では、ePUBを生成するために、次のような手続きを呼び出します。

1. ReVIEW形式ファイルを別形式に変換する「review-compile」コマンドを実行し、汎用XHTML形式に変換する
2. 1.で生成されたXHTMLファイルは汎用的なもので、オライリー・ジャパンの電子書籍のデザインとは異なる部分が多いため、フィルタスクリプト（Rubyで記述したもの）に通して加工する
3. リポジトリにあるメタ情報ファイル（YAML形式のファイル）に従い、カバーや奥付などを生成する
4. リポジトリに特定の最終調整プログラムが存在するなら、ファイル群をePUBとしてパッキングする直前に、それを実行する（たとえば「カバーの書名の特定箇所で改行する」）
5. ePUBとしてパッキングする
6. 制作関係者のためのWeb公開領域に、ePUBファイルおよびその展開物をプレビューのために配置する

この手続き中に何らかの失敗が起きた場合は、警告とともにその経緯のログが自動でメーリングリストに送付されます。これにより、ユーザはどの時点のコミットで問題が発生したかがすぐにわかるわけです。

続いてDocBookのほうの工程も見てみましょう。

DocBookのサンプル

こちらもほぼReVIEWの場合と変わりません。翻訳者または編集者がDocBook形式の翻訳原稿をSubversionリポジトリにコミットし、編集作業ではやはりこの原稿ファイルを修正してコミット、を繰り返します。ただし、DocBook形式はまだ作業者にタグのミスや、当初は想定していなかった要素処理が必要になることもあり、度重なるJenkinsのエラーにユーザが落胆してしまう恐れがあります。そのため、現時点ではJenkinsのビルドを有効化する前に、筆者がまずデータの検証と大まかな調整をかけるようにしています。

コミットに対するSubversionリポジトリのフックで、メーリングリストへの通知と、Jenkinsへの通知が行われ、Jenkinsは次の手続きを行うmakeを実行します。

1. DocBook形式ファイルをePUB形式に変換する「dbtoepub」コマンドを実行する。オリジナルのdbtoepubコマンドに各種のフックやパラメータ指定の機能を加え、カスタマイズしたものとなっている
2. dbtoepubコマンドでのePUB形式への変換の実体は、XSLTによるものである。オライリー・ジャパンの電子書籍のデザインに合わせたXSLTのセットを呼び出し、XHTMLへの変換を行う
3. リポジトリにあるメタ情報ファイルに従い、カバーや奥付などを生成する
4. リポジトリに特定の最終調整プログラムが存在するなら、ファイル群をePUBとしてパッキングする直前に、それを実行する
5. ePUBとしてパッキングする
6. 制作関係者のためのWeb公開領域に、ePUBファイルおよびその展開物を配置する
7. DocBookの場合、原稿のXMLの書き方によっていくつかの問題（リンクテキストが空になるなど）が発生することがあるため、チェッカーを実行して可能性のある問題を検査する

こちらも、途中で何か問題があれば経緯のログが自動でメーリングリストに送付されます。

ユーザはこうしてできたePUBファイル、あるいはプレビュー用のHTMLファイルをWebブラウザやePUBリーダで確認し、修正すべき箇所があれば原稿ファイルに手を入れてコミットする、ということになります。そして、読者の皆さんに販売できる品質になったとオライリー・ジャパンが判断した時点で、そのときの最新のePUBファイルがそのまま販売用のePUB電子書籍商品となるわけですね。

まとめ

いかがでしたでしょうか。「ReVIEWあるいはDocBook形式の原稿ファイルからePUBファイルを作る」という工程だけ見れば自動化は果たせたものの、選定、翻訳、編集といった大半の部分は、現代のテクノロジーでは（そしておそらく今後とも）人間の手が必要です。今後のePUBフォーマット電子書籍制作を継続させていくためにも、シリーズの順調な販売を祈りつつ、読みやすさのさらなる向上や、ePUBバージョン3への対応なども進めていきたいと思います。本稿やePUB電子書籍についてのご意見・ご感想、お待ちしております！

参考

本稿で紹介したシステムで制作した書籍と、関連する書籍を以下にご紹介します。

本稿のシステムで制作した書籍

Flex 4.5によるAndroidアプリケーション開発

スケーリングMongoDB

マネージャーのための仮想化ガイド

入門 ソーシャルデータ

関連書籍

GNU Make 第3版

Head First Rails

初めてのRuby

実用 Subversion 第2版

武藤健志

株式会社トップスタジオ執行役員。編集業務のほか、自動DTPシステム構築、社内インフラ管理、技術コンサルティング、3時のおやつ作り、その他諸事雑用と手を広げて自分の首を絞めている。Debian Project公式開発者だが、最近その作業に充てる時間を取れないのが悩み。Twitter: @kmuto