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

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

どうも、あかさたです。本記事は、「実践バグ管理」の執筆の流れを時系列に追いながら、書籍執筆プロジェクトをどのように進めていくか紹介する連載の第五回目です。前回は実際の執筆をどのように進めたのかについて紹介しました。今回は、できあがった原稿のレビューと校正をどのように進めたのか紹介します。

レビューと校正

執筆が完了すると、レビューと校正作業が始まります。といっても、実際には全ての原稿が完了してからレビューが始まることはあまりありません。ある程度原稿の完成にめどが立ってから（つまり原稿が書き貯まってから）レビューは開始しますが、レビューそのものは執筆と並行して行われるものです。

例を挙げると、1章の下書きが完了すると、レビューワの方々によるレビューが開始されます。執筆者は、1章のレビュー期間中に2章の下書きを完了させるという感じです。

レビューは、2008年12月末から2009年2月頭まで行われました。ただ、漫然と2ヶ月弱行ったわけではなく、期間を一週間単位で区切り、毎週約1章分ずつくらいにレビュー対象を限定することで、レビュー作業にメリハリをつけるようにしました。

レビューについて言えば、レビューワを見つけることも大変な作業です。レビューは、所属している会社やコミュニティにお願いしたり、クジラ飛行机さんの過去の著書の執筆時にレビューして下さった方々にお願いしたりしました。（レビューワのみなさま、本当にありがとうございました。）

さて、レビューをすると当然本のバグとも言うべき修正箇所が見つかります。実践バグ管理の執筆である以上、ここも本書で紹介されているバグ管理手法を用いました。

「実践バグ管理」執筆におけるバグ管理

実践バグ管理の執筆におけるバグ管理は、本書で言うところのスレッドパターン（p241）を採用しました。スレッドパターンとは、メーリングリストやスレッド型の掲示板を用いてバグを管理する方法です。

本書にも書かれていますが、スレッドパターンのメリットは外部のユーザーが参加しやすいことです。tracなどの専用バグ管理システムは、専門家やチーム内部の人間がバグを効率よくあるいは正確に扱うことに向いています。それに対し、スレッド型のバグ管理は、心理的、技術的（ツールに対する習熟的）な障壁が低いため、外部のユーザーに一時的に参加してもらうことに向いています。

スレッドパターンでは、スレッドの立て方として、「一つのバグをスレッドとして扱う」方法と「一つの成果物をスレッドとして扱う」方法の二つがあります。前者のスレッドタイトルの例を挙げると、「××画面の●●ボタンをクリックしたら、エラーメッセージが表示された」のようになります。後者の場合、「××画面について」というようなタイトルになります。

実践バグ管理では、後者の方法を採用しました。執筆の項別のWikiページの下部にコメント欄を設け、ここにバグの内容を書き込んでもらいました。以下に一つ実例を紹介します。

• スレッド名：コラム/バグがどうしても直らない時
  • レビューワA氏：「徹底敵」→「徹底的」
  • レビューワA氏：「ニアミスを連発」→「ケアミスを連発」
  • レビューワA氏：「データを疑う」「コードの全角半角、1バイト系2バイト系を確認する」等も実行しています。（参考として）
  • 著者：誤字脱字の指摘と、アドバイスありがとうございます！！内容が厚くなりました！感謝です！！
  • レビューワB氏：「バグを誘発する可能性が高めてしまいます」　→　可能性「を」高めて
  • レビューワB氏：「適度な急速や気分転換」　→　適度な「休息」
  • 著者：変換ミスの指摘など感謝です！二点、修正しました。

バグ管理というと、バグ毎にレポートを作成するイメージがありますが、執筆のような小規模プロジェクトの場合、バグの発見件数そのものが少ない（せいぜい数百）ため、成果物（修正箇所）に近い場所に修正項目と修正履歴を集める方が効率よくバグ管理することができます。

本書の執筆時、レビューワの方が見つけて下さったバグは200程度になりますが、tracなどを使ってバグレポートを200も作るとしたら、大変なコストになります。執筆は、クジラ飛行机さんと私を合わせて500時間程度です。200のバグレポートの管理は、100時間近くかかる可能性もあり、この規模のプロジェクトでバグ管理コストが2割に及んでしまっては、管理のための管理と言わざるを得ないでしょう。プロジェクトの規模や難易度に応じて適したバグ管理パターンを選択する必要があります。

ちなみに、修正漏れがないように、2ch風に全てのスレッドを一覧表示する機能（KonaWikiにはあるのです）を使って、レビューワの方の書き込みに未反応なスレッドがないか目視で確認しました。絶対数が少ないので、ときにはこのような原始的な方法が有効だったりするのです。

校正

さて、Wiki上の執筆作業が完了すると、印刷のために版を組まなくてはなりません。この作業は編集の方が行うわけですが、できあがったものをPDFにして、校正作業が行われます。

レビューが完了した原稿は、編集部に送り版を組んでもらいます。つまり、レビューと同じく毎週原稿を送り、毎週のようにPDFができあがって著者と編集で校正作業を行いました。PDFは章ごとに作られるので、レビューと同じ要領で、章ごとにバグをとりまとめて編集部に送信しました。

校正時に見つかったバグと修正案は以下のようにWikiに書き出しました。

• 4章（抜粋）
  • p170 「思います」が残っていた。「すぐに結果に反映されるのは大きいと思います」→「すぐに結果に反映されるのは大きいです」
  • p184 見出しの間違い。「TODO リストの活用事例」→「TODO パターンの活用事例」
  • p190 脱字。「組み合わせる必要がありまが、」→「組み合わせる必要がありますが、」

ただし、スレッドパターンではなく、バグの一覧を編集部に送信して完了です。このやり方は、編集者と著者のコミュニケーションコストはかからないのですが、バグ管理を著者側で行えないため、修正漏れなどが発生してしまいました。コストとの相談なのですが、品質を考えればここもしっかりと管理しておけば良かったと後悔しきりです。

レビューと校正に関する数字

レビューと校正に関する数字は以下の通りです。

表「見つけたバグ数」

正確な記録がない（執筆時間とレビュー・校正時間を分けて記録しておかなかった）ので、推計になってしまうのですが、私がレビューと校正に費やした時間は（文章の修正作業時間を含めて）、20 ～ 30時間程度でした。クジラ飛行机さんも同程度だとすれば、50時間程度使ったことになります。中には項を半分近く書き直すような修正も混ざっていました。

執筆というと、原稿を書く作業が多くを占めるように感じるのですが、このような周辺作業を無視してはいけません。

まとめ

今回は、原稿のレビューと校正作業について紹介しました。一見するとこれで書籍執筆作業は終わりのように見えますが、そうではありません。次回は出版後の作業などを紹介します。それでは！