オーム社開発部での開発体制

2008/1/16

オーム社開発部さんでの本の作り方を取材させて頂きました。社内で自作ツールをバリバリ作って、出版作業の効率化を行っているのが凄いと思いました。ただし、今回取材をした内容が行われているのは、オーム社開発部のうちの1グループ(グループは約3名)です。全体的にこの体制で行われているわけではないそうなので、ご注意下さい。取材実現の経緯は「オーム社開発部の方とのやり取り」をご覧下さい。

Subversionでバージョン管理

著書の原稿は、XML管理されており、そのXMLはSubversionで全ての著者(監訳者)と共有されているそうです。 Subversionのサーバはインターネット上にあり、各自がリモートで作業を行える環境が整い始めているため、最近では著者と一度も会わずに本が完成するという案件もあるそうです。

フォントなどの問題から、本番環境でのPDF作成はオーム社開発部で毎日行っており、毎日のPDFはSubversionサーバに蓄積されていくような運用をしているそうです。

通常の方式である場合、出版社は原稿確認を著者に依頼し、その結果を反映させるためにDTP業者に外注をするそうです。そのため、確認⇒反映⇒確認の作業に非常に時間がかかり、製本までに確認できる回数は最大でも3回ぐらいだったそうです。

現状では、PDF作成までをツールで行えるようになったため、DTP作業が軽減され、開発期間とコストが大幅に短縮できるようになったそうです。

使っているツール

使っているツールは自作だそうです。 Schemeで書かれており、処理系はGaucheを使っているそうです。

一昨年の年末年始の休みの間に一気に作り上げたそうです。その後は、徐々にソフトを成熟させながら利用していて、現在に至っているそうです。

先月発売された「アジャイルプラクティクス」は、この手法でアジャイルに作られたそうです。

ツール詳細

書籍用の原稿は全てXMLで書かれているそうです。このXMLの仕様はPragmatic Bookshelf社で利用しているものを利用しているとの事でした。本当は、処理ツールも使わせてもらいたかったそうですが、非常に高い金額だったので断念して自作してしまったそうです。

このツールは、「make」コマンドを実行するとXMLで書かれた原稿をLatexへ変換します。そして、そのLatexをコンパイルし、dvipdfmxでPDFを出力するそうです。

このツールの欠点としては、現状ではUNIX系環境でしか動作しないかもしれない点があるそうです。これは、KAKASHIやGaucheなどでシステム依存する機能を使っているかも知れないからだそうです。

XMLで記述してからTEXへ自動変換しているのには理由があるそうです。例えば、ソースコード例の最初に行番号を入れるような場合であっても、TeXでは全行の先頭に数字を入れなければならないそうです。しかし、このシステムを使うと、XMLでattributeを使って指定するだけで行番号アリ/ナシを切り替えられるそうです。さらに、プログラミング言語指定をattributeで指定して予約語だけを強調するようにしたり、メソッド名(関数名)を自動的に索引に入れたりすることもできるそうです。例えば、language="cs"はC#を表し、language="ruby"はRubyを表しているそうです。

アジャイルプラクティス 106ページより、サンプルです。

XMLコード



<code number="yes" language="cs">
  public int compute(int val)
  {
    int result = val << 1;
    //... その他コード ...
    return result;
  }
</code>

中間TeXコード


\begin{cs}1 \codebf{public} \codebf{int} compute(\codebf{int} val)
  {\protect\lsquash}
    \codebf{int} result = val << 1;
    //... その他コード ...
    \codebf{return} result;
  {\protect\rsquash}
\end{cs}

最終出力



1 public int compute(int val)
2 {
3   int result = val << 1;
4   //... その他コード...
5   return result;
6  }

単語を索引に入れるための専用XMLタグというのもあり、範囲を指定するとKAKASHIで漢字からかなに変換して、アイウエオ順の索引が平仮名を指定しなくても自動的に出来上がるそうです。このような事をするにもXMLからTexの中間コード生成は便利だそうです。なお、XMLタグを使用して読み仮名を手動で指定することも可能だそうです。

この体制が行い難かった書籍

マンガでわかる系の本では、この手法は使えなかったそうです。例えば、漫画家が紙派であった場合、作業の多くが紙ベースで行われます。

このマンガでわかるシリーズは、専門家である原著者に文章を依頼することから始まるそうです。出来上がった文章をシナリオ家に渡し、出来上がったシナリオを元に漫画家に発注するそうです。これらの、漫画系の書籍はプロダクションに依頼して作る事が多く、オーム社開発部が関わるのは、専門家である原著者との文書作成、シナリオ確認、漫画家選定、キャラデザイン選定、マイルストン毎のチェックなどであり、subversionで細かくチェックするような作業が行われる事はあまりないそうです。

仮に、マンガでわかる系の本には以下のようなものがあるそうです。

オープンソース

オーム社開発部には、個人のオープンソースプロジェクトとして汎用ツールを作っている人もいらっしゃるそうです。 IdeoTypeというXHTMLをPDF化する出版用ツールを公開しているそうです。 IdeoTypeは、最初に紹介した原稿管理システムとは別のもので、開発者も別です。

このオープンソースプロジェクトは2003年ぐらいにプロトタイプを作っており、去年と今年を未踏プロジェクトの支援を受けているとのことでした。 PMは公立はこだて未来大学の美馬先生だそうです。

IdeoTypeは、現在使われている社内ツールとは完全に別の実装で、すべて個人がプライベートな余暇で進めているオープンソースプロジェクトであるとのことでした。

現在使われている社内ツールは、現状の出版業務を効率化するために社外から入手した野良XMLをリバースエンジニアリングしたものである一方、IdeoTypeは広く使われる事を想定した設計にしてあるとのことでした。 IdeoTypeは、野良XMLを使うのではなくXSLTなどの汎用性のあるものを使ったものにしてあるそうです。「LISPを使えれば楽なんだけどなぁ」と思うこともあるそうですが、そこで手を抜かないようにしているそうです。ただ、社内ツールでのノウハウなどをIdeoTypeに生かしていき、完成度を向上させていく予定であるそうです。

最近では、やっと社内の業務にも利用できそうな完成度になってきたとのことでした。今後が楽しみなソフトウェアだと思いました。

IdeoTypeを作り始めたきっかけですが、XHTMLで書かれたものを印刷したかったというところから来ているそうです。 XHTMLをブラウザで印刷してもイマイチであり、最初はTEXに変換してから印刷というのをしていたそうです。それを発展させていったら、XHTMLをコンパイルしてPDF化するようなBook Compilerを作り始めていたそうです。

「ツールを使って一発で最終的なのものが出てくるというのを目指している。マウスのオペレーションが入っている限りはうまくいかないと思う。」という意見が印象的でした。

海外では、Book Compilerという分野はある程度認知されている分野であるそうです。国内ではまだあまり知られていないそうです。例えば、USのオライリーでは、原稿データをXMLでデータベースに入れてしまって、必要に応じて取り出して、パイプラインに入れるという事を行っているそうです。 (参考:O'Reilly TOC Conference : Evaluating and Implementing Tools and Processes for a Digital Workflow)

最後に

色々と話を伺いましたが、当初予想していたよりも、ずっとずっと深い話が聞けて驚きました。「深いですね」と聞くと「関わる著者の方々の影響が強いですね」というのが非常に印象的でした。

なお、この記事はオーム社内部で机をお借りして書いています。取材をして、その場で原稿確認、そしてリリースを数時間で終了！！！。。。の予定が最後の記事UPがProxyに阻まれてしまったので帰ってから投稿しています。

追記

このシステムを利用して本を書きました。

svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！