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

以前、オーム社開発部の出版体制を取材しましたが、今回、私自身がそのシステムを使って本を書きました。 Subversionでバージョン管理をしつつLaTeXで本を書く形式です。 複数人で本を書く時にバージョン管理ツールを使わないと、誰がどこをどういじったのかがわからなくなったり編集箇所が競合する場合が多いのですが、Subversionを使うことでそれらが解決可能です。

さらに、筆者か編集者のうちの誰かがsvn commitを行って最新版を更新すると、それに連動して最終原稿として印刷所に入稿されるものと同じ形のPDFが自動的に生成され、DTP作業がゼロになるとともに、筆者がアウトプットを細かく確認ができるという特徴もあります。

しかも、Subversionのコミットメールを編集者側も見ていて、該当部分に対する編集やコメントがすぐに投入され、こちらが文章を書いた数分後に編集側意見が含まれるPDFが返って来ることもありました。 常にそのようにリアルタイムであったわけではありませんが、今回の書籍執筆活動は著者側から見て「編集者が凄く見える」、可視化が進んだ出版でした。

今回は、システムを利用した立場から、それらの解説をしようと思います。

一般的な出版の流れ

オーム社開発部のシステムが「他社とどう違うのか？」を説明するには、一般的な出版の流れを説明する必要があります。 ということで、まずは一般的な書籍出版までの流れを紹介します。

通常は、最初にどのような方向性の本を執筆するのかに関してのミーティングを行った後に、著者が一度全ての原稿を書いてから編集者が以下のような編集作業を行います。

• 全体的な流れのチェック
• 誤字脱字の発見/修正
• 初出単語の確認
• わかりにくい部分の指摘
• その他、索引の整備など

これ以外にも必要に応じて文章を書く場合もありますが、編集者の個性によって作業は結構大きく違います。 さらに、「どこまで踏み込んで意見を言うか」に関しても編集者ごとに大きく異なります。 個人的には、自分の性格に合った編集者と巡り会えるかどうかで成果物の品質が大きく変わると思っています。

著者が書いた原稿に対して、このような「編集」が行われ、その結果が赤入れされた紙もしくはPDFなどの形で著者へと渡されます。 どこでどのような「編集」が行われたか著者に明示されずに、編集後の文章全体が渡される場合もあります。

そのようなフィードバックをもとに著者は加筆や修正を行い、編集者へ返します。 このフィードバックは、全体で1度もしくは2度が一般的です。 2度目のDTP作業の前後に外部レビューを依頼してのチェックもあります。

この流れを図にすると以下のようになります。

なお、これは著者数が一人や二人といった少ない書籍の場合です。 著者数が10人を越えるような書籍や、雑誌は、また違った方式です。 さらに、企画を出版社側で考えて執筆者を探すか、それとも執筆者側による持ち込みなのかによっても多少変わります(「インターネットのカタチ」は著者側からの持ち込みでした)。

オーム社開発部の方式

オーム社開発部の仕組みでは、一般的な仕組みよりも「著者」と「編集者」の位置づけはフラットです。 システム上だけを見れば、双方の行っている作業は「書き込む内容が違うだけ」だけであり、編集者が著者に近いとも言えます。

「インターネットのカタチ」の場合は、執筆者二人と編集者二人というチームでの書籍創作活動でした。 オーム社開発部システムには、XML風のタグ言語で書く方法と、LaTeXで書く方法がありますが、執筆者二人がLaTeXでの執筆を望んだので、LaTeXでの執筆になりました。 LaTeX用スタイルファイル等はオーム社で用意してくれました。 たとえば、コラム部分の表現など、ほぼ本書専用にスタイルファイルが作り込んであります。 「書籍中でこういった表現をしたい」という筆者側からの要望応じてスタイルファイルがバージョンアップしていく様子をsvn commitメールで見るのは非常に楽しかったです。

svnサーバやメーリングリストはオーム社開発部で用意したものを利用しました。 svnでcommitする度にdiffがメーリングリストに投稿され、PDFも自動的に生成されます。 通常だと文章が出来上がってから出版社側でDTP作業が発生して、その後はじめてPDFが執筆者側に提供されますが、それと比べると異常に早いスピードでPDFが生成されていることになります。 通常編集作業だと2回か3回ぐらいしか行われないPDFでの確認が、1000回以上に分けて細かく可能になるぐらい違います。

全体的な流れですが、まず一番最初の企画段階に編集者と執筆者で集まってミーティングを行ってざっと章立てを決めました。 次に、第一稿の各章が出来上がるごとに軽い編集及び構成チェック等が行われました。

その後、1年ぐらいかけて執筆者側で一通り書き終わり、編集作業がワンパス終了した時点で、様々な方々にレビューをお願いしました。 通常は2〜3名ぐらいが多いのですが、今回は書籍に含まれる内容が広範囲だったこともあり、10名以上の方々にレビューをお願いし、フィードバックを頂きました。 それらのフィードバックを反映させつつ、2ヶ月ぐらいかけて書籍を完成させていきました。

レビューワからのフィードバック反映を行い始めたころから、Tracによる進捗管理が開始されました。 どのような問題が残っていて、誰がどの部分に取り組むかに関して等がTracで管理されました。 Tracは、主にソフトウェアのプロジェクト管理に使われますが、このように書籍執筆の進捗管理にも大変有用です。

最終的に、印刷所にデータ入稿する二日前に編集部以外のcommitが終了し、入稿前日に編集部が最終的なチェック及び編集作業を行いました。 印刷所提出前日に行われた微調整等の詳細な内容もsvn commitされる度にdiffがメールで送られてくるので、編集内容の細かい部分も著者側は全てリアルタイムに確認が可能でした。

そして、印刷所にデータ入稿され、本が出来上がりました。

編集作業の「見える化」

このように、全ての執筆内容及び編集内容が全て「見える化」されています。

編集者と筆者は双方ともに「何が行われているか」と「いつ行われたか」が全て筒抜けです。 今回、このように「誰が何をしているか」が非常に良く見えたので、個人的には編集者に対する信頼度が非常に高く感じましたし、安心感もありました。 また、この書籍のために本当に凄い労力をかけて頂けているのが良くわかりましたし、「編集者がいないと本って成り立たない、もしくは品質実現は難しいなぁ」と強く感じることができました。

ただ、副作用としては「今やってます」という蕎麦屋の出前方式での作業ができないことがあげられます。 〆切ぶっちぎりに定評がある遅筆な私としては、その点は辛かったと言えます。 「じゃあ、途中でもいいので全部commitして下さい」と言われてしまうと、バレバレだからです。

PDFの注釈によるコメントのやり取り

svnやメールでの意見交換とともに行われたのが、PDF上に貼付けられた「注釈」でのやり取りです。 LaTeXにPDF注釈をつけるための専用マクロが用意され、それにコメントを入れることで編集側からの意見や修正案等が執筆者側に伝えられました。 さらに、今回は、それまでの経緯を知れるように、注釈内にコメントと返答を繋げて行くという方法を採用しました。

実際に、この注釈が扱われている様子をメールで送信されたsvn logで見ると次のようになっています。

ctakao	2010-07-14 23:38:02 -0400 (Wed, 14 Jul 2010)



  New Revision: 88



  Modified files:

    trunk/Chapter01.tex



  Log:

    add comment ch01



  Modified: trunk/Chapter01.tex (+4 -3)

===================================================================

--- trunk/Chapter01.tex	2010-07-14 23:34:48 +20:00 (rev 87)

+++ trunk/Chapter01.tex	2010-07-14 23:38:02 +20:00 (rev 88)

@@ -34,7 +34,7 @@



 -このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。

+このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao}

編集者側による、このsvn commitはrevision 88でしたが、このcommitが行われた12分後にrevision 89として私が次のような変更をcommitしています(注釈の変更部分以外は割愛)。

-このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao}

+本書でもいくつか紹介していますが、たとえば＼ref{protocolchapter}章で紹介する仕様に関する公開された議論を見る事で、様々な「試行錯誤」を知る事ができます。

+このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao : 補足する文章を追加してみました -akimichi}

さらに、その26時間後に、revision 98として以下のようなsvn commitが編集者側から行われました。

 
-この現状の「動いている」という状態を維持し続けるために、”インターネットの中の人”が、様々な試行錯誤を繰り返しています。

-本書でもいくつか紹介していますが、たとえば＼ref{protocolchapter}章で紹介する仕様に関する公開された議論を見る事で、様々な「試行錯誤」を知る事ができます。

-このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao : 補足する文章を追加してみました -akimichi}

+この現状の「動いている」という状態を維持し続けるために、”インターネットの中の人”が、さまざまな試行錯誤を繰り返しています。

+本書でもいくつか紹介していますが、たとえば＼ref{protocolchapter}章で紹介する仕様に関する公開された議論を見ることで、たくさんの「試行錯誤」を知ることができます。

+このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao : 補足する文章を追加してみました -akimichi：ありがとうございます。「様々な」が連続使用されていたので、少し文章をいじりました。ご確認ください。（「こと」の重複も気になったのですが、うまい文章が浮かばなかったのでママにしてあります。） -ctakao}

このときは、この状態のまま注釈が残され、他の部分の執筆を続けていました。 この注釈に関しては、revision 98の半年後のrevision 415で以下のような変更が行われ、その後注釈は「解決済み」となりました。

-このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao : 補足する文章を追加してみました -akimichi：ありがとうございます。「さまざまな」が連続使用されていたので、少し文章をいじりました。ご確認ください。（「こと」の重複も気になったのですが、うまい文章が浮かばなかったのでママにしてあります。） -ctakao}

+このような試行錯誤を知ることも、インターネットのカタチを探求することの面白みだろうと思います。＼edcom{インターネットの中の人の試行錯誤は、どこで知ることができるのでしょうか？？ 「本書でもいくつか紹介していますが、このような試行錯誤を知ることも……」？　-ctakao : 補足する文章を追加してみました -akimichi：ありがとうございます。「さまざまな」が連続使用されていたので、少し文章をいじりました。ご確認ください。（「こと」の重複も気になったのですが、うまい文章が浮かばなかったのでママにしてあります。） -ctakao : 最初の「知ること」を「アクセス」に変えてみました -akimichi}

このような細かい作業を複数まとめて行いつつ、区切りの良い所でsvn commitが行われ、最終的なrevisionは約1200になりました。

今回よかったこと

今回の本で個人的に非常にありがたかったのが、二人の編集者の方々に見て頂けたことです。

LISP/数学/LaTeX/その他色々を非常に好み、オーム社開発部の編集システムを正月休みに作ってしまった技術者指向な男性編集者(@golden_luckyさん)と、「理解できない」「自分なりの理解は、こうだけど、それは正しいですか？」という非技術者的な視点で内容を見て頂いた女性編集者(@ctakaoさん)のお二人です。

特に女性編集者からの「こういう意味ですか？」という質問は、自分の文章で説明不足な部分が非常に明確にわかったのでありがたかったです。

さらに、特に感謝したいのが「筆者のこだわり」に理解を示して頂けた事です。 当初、半年ぐらいで一次脱稿を目指す予定でしたが、結局完成まで1年半かかってしまいました。 ところどころで「状況を教えて下さい」という連絡を頂いたりしていましたが、全体的には「急いで品質の悪いものになるよりも、品質の高い書籍が出来るようにして下さい」という有り難いお言葉を頂けたため、今回の本は細部にまでこだわれました(ただ、社内では「いつできるの？」と突き上げもあったようです。すみません。)。

「インターネットのカタチ - もろさが織り成す粘り強い世界」

このような体制で執筆したのが「インターネットのカタチ - もろさが織り成す粘り強い世界」です。

この本では、過去に実際に起きた「インターネットが壊れて復旧した」事件を端緒に、「粘り強いが壊れやすく、壊れやすいが粘り強い」という視点でインターネットの形を探っていきます。

インターネットを構成する基礎技術TCP/IPを解説した書籍は非常に多くありましたが、そのTCP/IPを使ってインターネットがどのように運用構築されているのかに関しては、あまり知られていません。これまで、本書のような内容は通信事業者やISPなどインターネットの運用に関わるエンジニアだけが知るような世界でした。本書は「TCP/IPを知っていてもインターネットはわからない、一方でインターネットを知るにはTCP/IPの細かい話を全て知る必要もない」という思想です。

さまざまな規模で絶えず起きている水面下の活動を切り口に、現状のインターネットがインターネットとして機能している不思議さを共有しつつ、「ネットワークのネットワーク」であるインターネットをマクロな視点から教科書臭くならないように読み物として解説していきます。

各章で違った切り口での「インターネットが壊れた」を紹介しています。 たとえば、「ネットワークのネットワーク」という話題では、YouTubeがハイジャックされた事件や、世界中のネットワークがバラバラに分断された事件と、その回復に関して説明しています。

インターネットと国境というテーマでは、今年に入ってからエジプト全体が「インターネットから離脱した」という事件と、それがどのように観測可能であったかなどを紹介しています。 国境に関する話題では、中国のネット検閲の仕組みなども紹介しています。

物理的な構成に関しては、台湾地震による光海底ケーブルの損傷とその影響や、その他、物理的な障害がインターネットに与える影響を紹介しています。 クマゼミが光ファイバを損傷したり、窃盗などによる障害などの話題もあります。 その他、漁業権や立地条件などによって特定の重要地点が出来上がってしまう仕組みも解説しています。

その他、名前空間を司るDNSの話題、興味の集中やDDoSなどの攻撃による「インターネットの大渋滞」、商業的なネットワークとして階層化されたお金の流れとそれに従ってインターネット網が構成されることによる通信の集中や寡占化の流れなども解説しています。

参考のために、はじめにと1章の草稿、目次、参考文献を公開しています。 興味のある方は是非ご覧下さい。

• 「インターネットのカタチ - もろさが織り成す粘り強い世界」資料公開ページ

最近のエントリ

• 日本のIPv6採用状況が50％を超えている件について
• 「ピアリング戦記」の英訳版EPUBを無料配布します！
• IPv4アドレス移転の売買価格推移および移転組織ランキング100
• 例示用IPv6アドレス 3fff::/20 が新たに追加
• ShowNet 2024のL2L3
• ShowNet 2024 ローカル5G

過去記事

過去記事一覧