本作りもチケット駆動開発で

もうすぐ出版される『わかりやすいアジャイル開発の教科書』の出版の経緯を編集者が公開されていたのでメモ。
本作りもチケット駆動開発だったらしい。

【元ネタ】
『アジャイル開発の教科書』物語（その4） - 心との対話、技術との対話

『アジャイル開発の教科書』物語（その3） - 心との対話、技術との対話

『アジャイル開発の教科書』物語（その2） - 心との対話、技術との対話

『アジャイル開発の教科書』物語（その1） - 心との対話、技術との対話

『わかりやすいアジャイル開発の教科書』の予約が始まりました。 - mnishikawaの日記

アジャイル開発の資料作りで役立つイラスト集を公開！ - mnishikawaの日記

「わかりやすいアジャイル開発の教科書」 - Yasuo's Notebook

Sphinx+GitHub+BuildHiveで作る手軽なソーシャルドキュメンテーション環境 - Yasuo's Notebook

本作りでは、Backlogでタスク管理されていたらしい。

(引用開始)
正月が明け、ふとした疑問「「担当：三津田」と書かれたメール」について皆さんに聞いてみた。すると、私が知らないうちに、この本作りがチケット駆動開発になっていた（！）。
　打ち合わせで、「Backlog」や「チケット」という単語がよく飛び交うなぁと思いながら聞き流し、本のコンテンツや進行のことばかりに気を取られていた結果が、これであった。
　チケット管理システムのBacklogには編集が対応すべき文字・図版の直しや要望（つまり校正の指定＝チケット）が山積みになっていた（最終的にはチケット数1000件オーバー）。
　これを見て一瞬青くなったが、西河さんが冷静に一言。

「チケットこなしているとタスクがどんどん減っていきますから、おもしろいですよ」

　この一言を聞き、私も知らずのうちにアジャイルなものづくりに巻き込まれてしまっていたことに、いまごろようやく気づいた。

　本来、本作りは、

①「原稿書き上げ」
↓
②「初稿ゲラ（本のイメージに組み上がった原稿）校正」
↓
③「再校ゲラ（初校の直しが反映したゲラ）校正」
↓
④「確認校（印刷所に納めるもの。ほぼ「版」である）校正」
↓
⑤「出版」

　という5つのステップで作られる。
　著者さんの執筆作業は「①「原稿書き上げ」」でほぼ終わりになる。②以降の作業はあくまでも「確認」であり、⑤に向けてひたすら確認と直し、追加を行っていくというのが、いわゆる本作りである。
　細かな直しや追加修正は①で終わっているというのが大前提で本は作られる。
　雑誌と違って書籍は、企画書をベースにした1冊としての「総体的な整合性」が求められる。
　それゆえに本は、このような半ウォーターフォール型の制作工程で作られている。
　ところがどうだろう。
　『アジャイル開発の教科書』の本作りにおいては、②、③、④がタイムボックスになり、イテレーション（繰り返し）されまくっていた。
　制作当初、私は編集者として、いままでのやり方では本ができそうにないという直感があったが、それにしても、こんなにまでアジャイルな本作りになるとは思ってもいなかった。
　一般的に、本としての整合性・一貫性を保つために、②、③、④の工程で大きな追加・修正・変更を入れるということはあまりない。それは言い換えれば、本作りにおける追加・修正・変更は「手戻り」と認識されていたからだ。
　しかしアジャイルなものづくりの考えに立脚し、追加・修正・変更を「価値を高める作業」と、発想を切り替えたらどうだろうか。
(引用終了)

神は細部に宿る。
良い本づくりは、誤字脱字の修正だけでなく、目次やレイアウト、内容の構成も重要だし、レビューアの指摘事項を逐一反映することも大事。
とにかく細かい作業が多い。
それらを1つずつ反映していくことで、良い作品に仕上がっていく。

そのためには、チケット管理のツールが必須だろう。
とにかくタスクを上げて、1つずつこなしていく。
たくさんのチケットがあがっても、それら全てを解決するのがゴールと分かる。
ゴールが分かれば、担当を変えるなり、チケットを精査するなり、優先順位をつけるなり、色々やり方はある。

全てのタスク管理はチケット駆動開発から始めてみよう。