八角研究所 : 書籍「実践バグ管理」執筆体験記（1）

書籍「実践バグ管理」執筆体験記（1） - 執筆の開始と出版社への提案

どうも、あかさたです。最近、クジラ飛行机さんと一緒に実践バグ管理という本を書きました。提案から出版まで一連の流れを進めていくうちに、共同作業による本の執筆もまた、ソフトウェア開発プロジェクトと同じくライフサイクルを持った一連のプロセスと思うようになりました。技術系の本を執筆するプロセスを詳細に書いた記事もそうそうないもの（全くないわけでもないですが）ですから、本連載で詳細に紹介します。

実践バグ管理とは？

実践バグ管理とは、ソフトウェアライフサイクル（開発プロセス）全体を見渡しながら、バグ管理に必要なバックグラウンドや考え方を紹介した本です。個人の改善（コミュニケーションやバグレポートの書き方）とチームの改善（チームビルディングやプロジェクト管理）の二つの視点から書かれていて、プロジェクト立ち上げ時のリーダークラス、メインエンジニア、助っ人、新人に活用できる内容になっています。

・・・と、一応の紹介をしたものの、さっくりと言えば「長い目で見ると、エンジニアの基礎体力（？）を向上する養分になる本」です。このため、ソフトウェアライフサイクル全体を見通して、バグ管理、リリース管理、バージョン管理の実践だけではなく理念も紹介しています。

本執筆のライフサイクル

本執筆のライフサイクルは、執筆者から見れば、提案に始まって出版で完了すると考えるのが普通でしょう。しかし、ソフトウェアと異なり、保守フェーズがないと考えるのは「間違い」です。実践バグ管理は出版したばかりなのでまだ保守フェーズに入っていませんが、出版したあとも正誤表の作成や、もし増刷/重版などがある場合は、（修正できる場合は）内容を修正する必要もあります。

以上を踏まえて本執筆のライフサイクルを図にすると以下のようになります。本連載はこの図をベースに紹介します。

本執筆のライフサイクル

さて、本連載では本執筆のプロセスを紹介していくのですが、一つ確認をしておきます。本連載で紹介するのは、効率よく同じような多数の本を書くための方法論ではありません。本を書くことを生業とした人のためのプロセスではなく、開発が主体の現役エンジニアが、内容を吟味して書くためのプロセスです。（本を書くことを生業とするには、量産する必要がありますが、そのために必要になるであろうテクニックには触れていません。私自身が開発中心のエンジニアですからね。）

また、個人作業ではなく共同作業に適した方法を紹介しています。開発中心のエンジニアが一人で本を書くこともあります。しかし、執筆が本業でない以上、複数人で書く場合も多いのです。実践バグ管理も共著という形態を採っており、本連載ではその際に積み上げたノウハウを公開します。

提案と検討

連載初回の本記事では、執筆環境の整え方や会議の手法などといった技術的な話題は次回以降に回し、まずはこれなくしては始まらないという意味では最も重要な「提案の流れ」を時系列に沿って紹介します。

「実践バグ管理」の執筆は、2008年7月頃にクジラ飛行机さんから八角研究所の技術顧問で本を書かないかと誘われたことから始まりました。

出版社から本を書かないかという打診があった
本の企画内容はまだ決まっていないので提案する必要有り
時事に流されず長く読める本が欲しい

そこで、八角研究所の技術顧問の間で提案を出し合うことにしました。提案書の書式は以下の通りです。技術系書籍のマーケットについては出版社の方が詳しいので、どのような読者にどのような価値を提供するかわかりやすく書くことで、その本を出版する妥当性があるかどうか判断しやすいように提案します。

提案書の書式

タイトル

【概要】

【対象読者】

【目次】

複数人でアイディアを出し合うと、結構多くの提案が集まります。比較検討がしやすいように、書式は極力合わせると良いでしょう。

まず技術顧問の間で、メールで提案内容のやり取りをしました。合計 5, 6 個案を出し合って、メールで検討してからクジラ飛行机さんから出版社に提案書を提出してもらいました。8月上旬に「実践バグ管理」が企画会議を通過したというお知らせをいただき、執筆が開始されることになりました。実は他の企画でも通過していたものがあったのですが、本に期待される規模感（ページ数）などから、実践バグ管理が選択されました。

はっきり言えば、通過した他の企画はかなりページ数が多くなってしまうため、当時の執筆者のスケジュール感から書くことを回避したという感じです。（実践バグ管理もまた大規模な本になってしまったので、結果論的にはどちらの企画を選んでもあまり変わりありませんでしたが・・・。）

実践バグ管理の当初の提案書は以下の通りでした。現在の目次と比較すると、提案当初は「あまり書かれていないバグ管理というニッチなジャンルを狙いにいっている」ことがわかります。（最終的には開発ライフサイクル全体をカバーした王道っぽい本になったのですが。）

それにしても、最初の本のタイトルは、「バグ管理徹底入門」・・・うーん、売れなさそうなタイトルですね。タイトルは出版直前に執筆者ではなく出版社側の営業的視点で決めるものなので（執筆者も案は出しますが）、ここでは提案の内容が重要です。

でも、本執筆プロジェクトを進めていく上での呼び方（我々は「バグ管理本」と呼んでいました）は大切です。アジャイルプロジェクトにおけるメタファに近い考え方ですが、略称でもあだ名でもいいので、呼びやすいようにすると、打ち合わせの場合などに便利です。

当初の提案書

● バグ管理徹底入門

【概要】

どのようなシステム開発プロジェクトでもバグ管理は必要なものです。
ウェブアプリケーションの普及によって、優れたバグ管理システムを
ほぼ無料で入手することができるようになり、バグ管理システムを
使用するプロジェクトは急速に増えています。

反面、バグ管理は以下のような難しい問題を抱えていますが、バグ
管理に焦点を当てて解説したまとまった情報が得られにくいことも
事実です。

・バグの重大度・優先度管理とメンバー間の共有
・バグ管理ワークフローの整備
・バグの状態管理とメンバー権限の設定

バグ管理システムを取り扱った本は既にありますが、どうしても
システムの機能の紹介やインストール方法の解説にとどまって
しまう本が多く、実際の運用方法にまで踏み込んだ本はあまり
存在していません。

＜＜・・・中略・・・＞＞

テスト技法や開発プロセスには踏み込まず、バグ管理のみを新人や
経験の浅い若手エンジニア向けにわかりやすい解説を提供します。

【対象読者】

・ システム開発プロジェクトの参加メンバー（若手）
・ テストチームに配属されたエンジニア（若手）

【目次】

● 第1章 バグ管理とは？
・ バグ管理とは？
・ バグ管理システムについて
・ なぜバグ管理システムを使うか
・ この本で扱わない内容

● 第2章 バグ管理の大まかな流れ
・ バグ管理の全体像
・ バグ管理で登場するワーカー
・ バグ管理の基本用語集
・ バグを見つけたときの基本的なシナリオ

● 第3章 バグの状態管理とワークフロー
・ ワークフローを定義する
・ バグの状態管理
・ 優先度と重大度
・ 再現性とその取り扱い
・ 解決状況の把握
・ システムのバージョンとの整合性

● 第4章 バグ管理のシナリオ
・ 一人プロジェクト
・ テストチームが分かれていない小規模プロジェクト
・ 開発とテストチームが分かれている中規模プロジェクト
・ テストチーム以外にバグを登録するプロジェクト
・・サポート組織
・・ユーザー・コミュニティによる登録

● 第5章 バグ管理ツール
・オープンソースのバグ管理システム
・ Bugzilla
・ Trac
・ RedMine
・ Mantis

出版社の方との打ち合わせ

さて、出版社側の企画会議を通過すると、執筆開始・・・というわけにはいきません。まずは出版社の方と打ち合わせを行います。議事録によると、2008/8/7に打ち合わせを行ったようです。（どんな打ち合わせでも議事録を作ることは大切です。）これは、企画の内容を確認するという意味もあると思うのですが、執筆者が本書の内容を企画の意図通りに書けるかどうかの確認もあったと思います。（クジラ飛行机さんはともかく、私はこの出版社で執筆するのは初めてでした。）

実際には以下のような内容を打ち合わせしました。