書籍「実践バグ管理」執筆体験記

• 執筆プロジェクトのミーティング
• 執筆の開始と出版社への提案
• 見積もり（工数とスケジュール）と執筆環境の構築
• 執筆プロジェクトのための合宿
• 原稿のレビューと校正

どうも、あかさたです。本記事は、「実践バグ管理」の執筆の流れを時系列に追いながら、書籍執筆プロジェクトをどのように進めていくか紹介する連載の第二回目です。前回は出版社への提案の流れを書きました。今回は、本の見積もり（工数とスケジュール）、目次の検討、執筆環境の構築について紹介します。

本の見積もり（工数とスケジュール）

さて、出版社で企画が正式に通過したのは（正確には、出版社から通知があったのは）、2008/8/12でした。八角研究所の技術顧問といえども、お盆休みというか夏休み期間はお休みしていたので、本の執筆を実際に開始し始めたのは8月下旬からでした。

最初に行ったことは、目次の設定と作業見積もり及びスケジュールの確認です。本としては春頃が一番売れやすい内容（想定される読者が新社会人などであるため）ですから、デッドラインは春としました。ただ、あまり長く引っ張っても仕方がないので、10月末までに下書きを完了させたいということになりました。

見積もり

本執筆プロジェクトの規模を計るために、見積もりを行いました。全体サイズは、企画時点で250ページくらいと決めていたので、それをどのように分解するかを考えました。分解した手順は以下の通りです。

• 本を5章構成にする
• 1章は5節で構成する
• 1節は5項で構成する
• 1項は2000文字で構成する
• 1ページ1000文字（1項は2ページ）
• 5章×5節×5項＝125項
• 125項×2ページ＝250ページ（250,000文字）

結論を言うと、上記の見積もりは多すぎました。実際に書いた文字数は「230,298文字（目標250ページに対して実績367ページ）」でした。つまり、大幅に超過しています。レイアウトとしては、1ページキツキツにして1300文字だったので、30万文字以上書かなくてはならない・・・はずなのですが、実際にはそうはなりません。

まず、1ページに必要な文字数は、見出し、改行、段落分けなどによって、多いページでも1000文字を切ります。図表がなくても700文字程度のページもあります。当然図表が入ればさらに文字数は減ります。本書では、図やイラストが50枚程度（もっとあったかも）、表や列挙などが多数入っているため、さらに必要なページ数は減ります。また、章の扉や、目次・索引など、本として体裁を整えるために必要なページ数というものもあります。

結果としては、16～7万文字程度（100項構成なら、一項あたり1600文字程度）書けば良かったことになります。

スケジュール

前述の通り、クジラ飛行机さんと私は、10月末までに下書きを完了させたいと話していました。2人で書くので、1人67.5項書くことになります。9月10月で1日2項ずつ書き進めれば、十分に完了するだろうと予測を立てました。また、別の機会になるのですが、平常時であれば、実践バグ管理のような内容の文章は、1時間1000文字程度書けることを実際に計って確認しました。ノっているときは、1時間4000文字くらい書けることもありましたが、かなり例外ケースになるので、見積もりの根拠は1時間1000文字とすることにしました。

1人125,000文字ですから、計算上125時間で書き上がることになります。打ち合わせ（実績値は計23回約40時間・・・かなり大きくなってしまいました）、校正、内容検討などなどで倍の1人250時間程度はかかるだろうと見積もりました。この見積もりはそれほど間違っていませんでした。私は作業時間の全てを記録していますが、本執筆のためにかけた時間は241.25時間（はてなダイアリーに書いた紹介文を含めてです）でした。クジラ飛行机さんも同じようなものでしょう。

9月10月で下書きを終わらせるとすれば、150時間程度（月当たり75時間）を費やすことになると想定していました。一応それができるスケジュールということになっていたのですが・・・。

見積もりと実績

見積もり（工数とスケジュール）と実績値は以下の通りです。工数がかなり精度が高く見積もれている割には、スケジュールはかなり延び延びになってしまいました。見積もりに詳しい方は、スケジュールと工数は別ものであることをよく知っているはずです。

クジラ飛行机さんも私も別件で入った仕事が原因で、本執筆の時間が非常に少なくなってしまいました。たとえば、私は2008年9月は100時間程度本執筆に費やすと宣言していたのですが、実際には32.5時間しか作業していませんでした。2人ともフリーランスであり、仕事にはある程度自由度があります。しかし、一度仕事の交通整理に失敗すると、比較的締め切りの緩い執筆業にしわ寄せが来やすいということでしょう。

見積もりと実績

※ ただし、実際に版を組んだ際にかなり構成が変わっている（節が項になったりしている）ので、あくまで執筆者が書いた時点の項ベースでカウントしました。

※※ 出版は2009/3/16でした。

言うまでもないことですが、見積もりは作業を最小単位（本の場合は1項、打ち合わせ1回など）まで分解してから行えば精度は非常に良くなります。本執筆のように締め切りが比較的緩い作業の場合は、作業を進めながら計測を行い、時間をかけて見積もると良いでしょう。

目次の検討

2008/8/29のミーティングから9/5、9/12、9/19、9/26とミーティングを重ねて、9/26のミーティング時には見積もりが完了し、目次構成が8割方（97項/125項）決まっていました。この間、9/12に試しにそれぞれ1項ずつ書いてレビューをしたり、9/19に章構成の確定、9/26に項レベルの目次を決めました。

目次を決定するに当たって以下のことを考えながら検討を行いました。

• どのように読んでもらうか
• 何を書いて何を書かないか
• 誰に読ませたいのか
• 量的なバランス

どのように読んでもらうか

本書は1章から順々に読んでもらうことを想定して書きました。しかし、本書にはケーススタディなど、ある程度経験を積んだエンジニアにとっては飛ばしても構わない内容も含まれています。3章4章には経験を積んだエンジニアにとって有用なノウハウを記述しているので、最初の方を飛ばして読んだ人でも読み進められるように、3章4章はある程度どこから読み始めても理解できるように書きました。

ベストは最初から最後まで読み進めてもらうことですが、目次を決定する際には、さまざまな読み進め方を検討する必要があります。（検討した内容は本の最初、第1章の前に書くと良いでしょう。）

何を書いて何を書かないか

バグ管理はプロジェクト管理と密接に関わりがあります。とはいえ、プロジェクト管理のことを細かく書き始めてしまったら、それこそいくらページがあっても足りなくなります。また、テスト技法（ここで言うテストは開発者のテストではなく品質保証のテスト）や品質管理にも踏み込まないように心がけました。やはり、ページ数がいくらあっても足りません。また、どの分野も既に良書があります。

バグ管理に関する本については類書が無く、バグ管理とは「リリース管理、バージョン管理、バグ管理（レポート管理）の集合である」という仮説を立てて本の目次を決定しました。また、管理作業だけでは困るので、レポートの書き方などこれを読むであろうエンジニアの実務的な内容も含めることにしました。

類書がないため仮説を立てていますが、この仮説はTracなどのバグ管理システムの実装を抽象化したものと言えます。基本的に、類書がない（少ない）場合は仮説を立てるしかなく、この仮説の検討が浅いと読み手にとって意味のない内容を書いてしまうことになりかねません。実装や実務内容をよく検討してできるだけ正しいと思われる仮説を選択するようにしましょう。

仮説の検討を進めていくうちに、クジラ飛行机さんと私の本書に対する認識も合うようになっていきました。共著の場合は、この段階で認識を合わせないと、ちぐはぐな内容になってしまいがちです。

誰に読ませたいのか

実践バグ管理を新人のエンジニアが手に取ってくれるかどうかはわからないのですが（内容的には一番読むべき層でもあるのですが）、新人のエンジニアもしくは経験の浅い若手エンジニア向けに書くことが決まっていました。こうしたエンジニアが手に取りやすいように、新人研修をテーマにしたケーススタディを含めるようにしました。

それと同時に既に現場で活躍しているエンジニアにも面白く読めるように、コラムや実務のインタビュー・記録などを多数挟み込みました。類書がないことと本の対象範囲を考えると、管理方面に意識の高いエンジニアであれば手に取る可能性がかなりあるためです。やや八方美人的な書き方になっていますが、類書がないことを考えると幅広い層をカバーすることも間違いではないでしょう。

量的なバランス

ウェブ媒体に記事を書くケースと異なり、本というものは質はいうまでもありませんが、まとまった量がなければ出版できません。多少量が超過しても出版することはできます。私の知っているケースでは、企画時想定の倍近くなった本でも出版されていました。量を書くことはとても大切なのです。

とはいえ、あまり増えると出版社側の手間が増える（校正、版組）ので、できるだけ企画時想定に近づけたいものです。想定の1.5倍になってしまった自戒を込めて書いておきますが、量的なバランスは常に意識すると良いでしょう。

執筆環境の構築

目次の検討時は、いわばプロジェクトのスタートアップ時でもあり、執筆環境の構築を並行して行うことになります。執筆は、クジラ飛行机さんが開発した KonaWiki（関連記事）を使用しました。KonaWikiには、執筆に便利な機能（文字数やページ数のカウント、一行に入る文字数が本などの紙媒体に近くなるように設定されている、引用や埋め込みのために便利なプラグインがある、などなど）が多数含まれています。ウェブアプリケーションですから、共著にも使いやすいツールです。打ち合わせの議事録、ブレインストーミング、技術情報の調査結果などさまざまな情報をこのWikiに書き込みました。

また、図の作成には私が開発した Kodougu を利用しました。実践バグ管理には 30 枚近くのアクティビティ図・ステートマシン図が登場しますが、これらは Kodougu を利用して書いています。打ち合わせのときに、一つの図を10分～15分位で、わいわい話しながら描きました。

書き上がった文章は、一度Wordの校正にかけました。簡単な日本語の間違いであれば自動的に指摘してくれるため、大量の文章を書く際には非常に重宝します。

使ったツールの一覧

• KonaWiki
• Kodougu
• Microsoft Office Word

共著における執筆環境の構築には以下の点を考慮すると良いでしょう。

• 共同作業を行いやすいか
• 簡単に使えるか（入手が簡単か）
• 生産性を確保できるか

ウェブアプリケーションで執筆を行ったことによって、レビューワの皆さんにレビュー参加してもらう際には、URLと認証用の情報を送るだけで済みました。今時の執筆はウェブアプリケーションで行うと良いのでしょう。本を書いていると結構バグが出てくるので、Tracを使っても良いかもしれませんね。

まとめ

今回は、本執筆プロジェクトの見積もり、目次の検討、執筆環境の構築について紹介しました。次回は実際の執筆の様子と打ち合わせのやり方などについて紹介します。それでは！