3. チームで執筆を行うということ
ここでは「プログラミングGROOVY」の執筆経験を題材として、複数人によるチームで執筆を行う際に注意すべきことや、執筆活動に役立つツールなどを紹介します。
3.1. 最も重要なこと:ビジョンの統一
どんなプロジェクトにおいても重要なのは、プロジェクトの目的を明確にし、プロジェクトメンバー全員がそれを共有することです。書籍を世に出すということもプロジェクトの一つなので、開始時点で次のような点を明確にしておくことで、書籍の内容や装丁、販売戦略などに統一的な価値観をもたらすことができ、方向性がブレることを抑制できます。
- 想定するターゲット（読者）
- 利用形態：入門書、じっくり読む本、レシピ本、リファレンスなど
- 書店でどのような分類の棚に配置されてほしいか？
- 出版タイミング：書籍の内容はいつごろ世に出るのが適切か？
「プログラミングGROOVY」の場合、以下のような位置づけでした。
- ターゲットはJavaエンジニア：Javaを知っていることを前提とする。
- 利用形態：Groovyの入門書。既に翻訳書「Groovy イン・アクション」が刊行されていましたが、こちらはいわゆる「バイブル本」であり、内容は素晴らしいのですがやや難易度が高く、さらに分厚くて高価であるため、敷居が高くなってしまっていました。Javaエンジニアが気軽に持ち歩いて現場でさっと読める本を目指しました。
- 書店での配置：Javaのコーナーに置いていただけることを目指しました。これも「Groovy イン・アクション」のジャンルが判別しづらかったために、ある書店ではJavaのコーナー、ある書店ではLL言語のコーナー、という置き方をされたことからの反省です。
執筆開始前にこのようなビジョンを編集者・執筆者の間で共有することができていたため、書籍の内容について大きくぶれることなく作業を進めることができ、書籍の装丁や販売についても意図通りに進めることができました。
3.2. コンテンツの設計
複数人で執筆を分担する場合、書籍のコンテンツ全体の構成をきちんと設計しておくことが重要です。特に、章節ごとの記述内容に漏れやダブりがない（MECE=Mutually Exclusive and Collectively Exhaustive）か、また章節間の関連性が考慮されているか、執筆に入る前に検討しておく必要があります。とはいっても、実際に書いてみないと分からないこともありますので、まずは概要レベルの原稿を書いてみて相互レビューを行うことをおすすめします。
3.3. スケジュール管理とコミュニケーション
失敗談のところで言及したことの繰り返しになりますが、技術書の場合は専業のライターではない著者が、本業の傍らで執筆するというケースが割と多いのではないかと思います。「プログラミングGROOVY」の著者4名もすべて本業を別に抱え、主に平日夜や土日を利用して執筆するという状況の上、地理的に離れていてすぐに顔を合わせることができませんでした。そこで、スケジュール管理と相互のコミュニケーションのために以下のような工夫をしました。
- 進捗管理
執筆開始前にミーティングを実施し、章節の設計を集中的に行いました。その上で章節毎の担当者を決め、Google Spreadsheetで章節単位での進捗状況を管理しました（Google Spreadsheetは複数人での共有や同時編集に対応しており、チームで共同作業を行う際には便利なツールです）。とはいえ、状況は常に変化していくものです。そのような変化に対応するため、毎週オンラインでチャットミーティングを開催し、進捗状況の確認と作業分担の調整を行いました。
チャットサービスはいくつかありますが、私たちはFresh Meetingのサービスを利用しました。参加者がオンラインになったらメールで通知ができ、後でログを参照することもできるので便利です。
- コミュニケーション
Google Groupsに著者間のコミュニケーション用のグループを作成し、細かいやりとりはその上で行いました。ただ、オフラインのコミュニケーションだけでは効率が悪い面もありますので、著者が所属しているコミュニティ（JGGUG）の月次勉強会で集まる機会があればface to faceでのミーティングを実施しました。また、執筆の節目節目で執筆合宿を開催し、集中的な議論を行ったり、また執筆に専念できる環境を意識的に確保したりという努力をしました。
3.4. 成果物の管理
- バージョン管理システムの活用
一人で執筆する場合はあまり問題になりませんが、複数人での執筆の場合はどのように成果物を管理・共有するかということが課題です。特に、地理的に分散したメンバー間で効率よく成果物を共有するためには、何らかのクラウド・サービスを利用するのが効果的です。
シンプルな管理で十分であれば、Dropboxなどのファイル共有機能を利用するのも一つの方法でしょう。しかし、メンバーの数が多い場合や、担当箇所が入り組んでいて単純なファイル管理ではうまくいかない場合などは、バージョン管理システムを利用する方がよい場合もあります。バージョン管理システムを使うために多少の学習と環境構築が必要ですが、慣れてしまえば非常に効率的な管理が行えますので、複数人で共著を行う場合はぜひお試しください。
我々は今回BitBucketというサービスを利用しました。BitBucketはMercurialという分散バージョン管理システムのホスティングサービスで、5ユーザーまでの共有リポジトリであれば無償で利用できます。BitBucketによる原稿の共有は以下のようなイメージになります。
MercurialやGitなどの分散バージョン管理システムを利用すると、ローカルリポジトリに対して変更内容を随時コミットできるため、オフラインの状態でもバージョン管理を行いながら安全に執筆を進められるのが良いところです。 ただし、自分の作業結果を共有する際には、中央リポジトリ（今回はBitBucket）から最新のファイルをpullしてローカルリポジトリを更新してから自分のコミットをpushするという手順が必要になりますので、不慣れなメンバーがいたら運用手順を周知しておいた方がよいでしょう。
- 原稿のフォーマットと執筆のためのツール
原稿の執筆にどのようなツールを使うか、また出版社への納入はどのようなフォーマットで行うかなどは執筆開始前に決めておく必要があります。
技術系文書の場合、文章だけでなく、図表やソースコードなどを含む場合がほとんどです。また、相互参照や脚注なども多用されます。MS Wordなどのワープロソフトであればこれらの要件を満たしますが、ファイルフォーマットがバイナリ形式であるためバージョン管理との相性が良くありません。かといって、プレーンテキストでは図表や相互参照などの表現が難しく、原稿執筆者や編集者への負担が大きくなります。原稿をプレーンテキストとして編集可能で、ワープロ並みの表現力を持ったドキュメント作成ツールを利用することを検討すべきです。
このような観点から、我々は今回、原稿執筆にSphinxというツールを使いました。SphinxはPythonベースのドキュメント作成ツールで、プレーンテキストに簡単なマークアップを付加するだけでHTMLやDocBookなど複数のフォーマットのファイルを出力できます。例えば、本記事の著者紹介の部分は、Sphinxでは次のように記述できます。
============================ 執筆者紹介（共通の質問項目） ============================ ---------------- 筆者プロフィール ---------------- 須江 信洋（すえ のぶひろ）。 エンタープライズJava関連のSIやプリセールスを経験し、2007年より日本アイ･ビー･エムにてWebSphereのプリセールスを担当。 プライベートでは、SIの現場でGroovy関連の技術を活用する方法について日々試行錯誤している。 JGGUG（Japan Grails／Groovy User Group）サポートスタッフ。 JJUG（Japan Java User Group）幹事。 * nsue@e-mail.ne.jp * http://d.hatena.ne.jp/nobusue * twitter: @nobusue * facebook: http://www.facebook.com/profile.php?id=732337788 * LinkedIn: http://www.linkedin.com/in/nobusue ------------------------------------ 代表的な執筆の成果物を教えてください ------------------------------------ 書籍 ****
ご覧いただいて分かるように、SphinxのソースはWikiなどとくらべてプレーンテキストとしても可読性が高いのが特徴です。ここでは詳細は割愛しますが、興味のある方はぜひSphinxユーザー会のWebサイトを参照ください。
- 用語や表現の統一
共著の場合、同じことを表すのに異なる用語や表現を用いていると、全体の統一感がなく読みづらい文章になってしまう上に、読者の理解の妨げとなります。執筆開始前に著者間でルールを決めておくとともに、執筆が進んだ過程で新たに出てきた用語などを一元的に管理する仕組みが必要です。
一般的な文書表記ルールをゼロから決めていくのは大変ですので、市販の書籍や、ソフトウェア・ベンダーが公開している表記ルールを参考にするのが良いと思います。
用語の統一のためには、用語とその意味を管理するための用語集が必要になります。我々は今回、Google Spreadsheetで用語集を管理しましたが、専用のWebアプリケーションなどを作成してもよいと思います。重要なことは、関係者（著者・編集者・レビューアーなど）が常に参照でき、かつ必要に応じて容易に追加変更ができるツールを用意することです。用語集のメンテナンスがおろそかになると、執筆終盤で大混乱になります。
