前回のブログでも書いたとおり、僕は2017年12月6日から10日まで東京に滞在していました。
そこで出会ったRubyプログラマのみなさんからよく聞かれたのは「あの本（＝プロを目指す人のためのRuby入門）って、書くのにどれくらいかかったんですか？」という質問です。
たしかに、Rubyのコードを書く人は多くても、本を書く人はあまりいないと思います。
そこで、このエントリでは執筆の様子がある程度わかるように、「プロを目指す人のためのRuby入門」（チェリー本）の執筆裏話を書いていこうと思います。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者: 伊藤淳一
- 出版社/メーカー: 技術評論社
- 発売日: 2017/11/25
- メディア: 大型本
- この商品を含むブログを見る
ちょっと長いので先に目次を載せておきますね。
それでは以下が本編です。
執筆＆制作期間
ざっくり言うと、2016年の8月に書き始めて2017年の11月に発売されたので、執筆＆制作期間は全部で1年と3ヶ月ぐらいですね。
以下でもう少し詳しく時系列を追ってみます。
おことわり
ここに載せている進め方やスケジュールはあくまで「プロを目指す人のためのRuby入門」の実績です。
書籍の内容や編集者さんによって進め方は大きく変わってくるので、すべての技術書でこのように進行するわけではありません。
2016年6月：執筆の声がかかる
- Software Design編集部の吉岡さんから「Rubyプログラマ向けの書籍の執筆に興味はありませんか？」という話をいただく。
- それまでにSoftware Design誌で数回記事を書いていたので、「次は書籍でも」という流れはそこまで不自然ではないかも。
- ただし、それより前の「Software Design誌に記事を書きませんか？」という話は数年前に突然連絡が来てビックリした記憶がある（参考）。
2016年8月：とりあえず執筆開始
- 吉岡さんと話し合って書籍のだいたいの方向性を決める。
- 企画書のインプットとするために、僕からは目次案を出したりした。
- 「現時点ではまだ企画は通っていないのでポシャる可能性があります」と言われていたが、見切り発車で執筆開始。
- ポシャったらQiitaで公開すればいいや、と思って書き始めた。
2016年11月：企画が通る
- 企画が無事に通る。
- この時点で書籍名は「プロを目指す人のためのRuby入門」、発行時期は2017年11月になっていた。
- このときは「1年もかかるんですか！？急いだら来年の4月ぐらいに出せるんじゃないですか？」とか言っていた。このときは・・・。
2017年2月：いったん執筆完了、しかし…
- 結構ハイペースで執筆したので、いったん全部の原稿を書き終える。
- ここまでは「なんだ、書籍執筆も余裕じゃん」という印象。ここまでは・・・。
- 吉岡さんから「原稿からページ数の見積もりをしたところ、予定していたページ数を大幅にオーバーしているので100ページぐらい削減してほしい」と言われる（しまった、書きすぎた！）。
2017年3月：分量の削減
- サンプルコードの書き方を変えたり、優先度の低い内容を削除するなどして「これぐらいなら大丈夫そう」というところまで分量を削減した。
- ちなみに、この頃にカットした原稿を無償で公開しているのが、「プロを目指す人のためのRuby入門・別館 アドベントカレンダー」です。
2017年4月：構成上の大手術
- ソニックガーデンの同僚に原稿を読んでもらって感想を聞いた。
- いろんなフィードバックが上がったが、中でも影響が大きかったのは「例題が章の最後に来ると途中で眠くなるし、最初の方の内容も忘れてしまう」という感想だった（しかも1人だけじゃなく複数のメンバーから）。
- 吉岡さんやソニックガーデンメンバーとの長い議論の末、「例題に必要な知識の説明 → 例題の解説 → 例題で使わなかった知識の説明」の順で書くことに決定。それに伴い、原稿の大幅な書き直しに着手する（ひえ～～～😭）。
2017年5月：原稿の清書完了
- 書き直しと原稿の清書が完了。短期間で構成を変える必要があったため、かなりハードだった。。
- 関西Ruby会議2017にて講演の最後に「11月に本が出ます！！」と発表。本の執筆を公にしたのはこれが初めて。
2017年6月～7月：DTP作業
- この時期は編集サイドのDTP作業がメインだったので、僕の方はこれといった作業はなし。
2017年8月：1回目の校正
- 紙とPDFで最初のゲラ（試し刷り）が届く。ここから1回目の校正がスタート。
- 清書完了から時間があいたのと、原稿が本らしい見栄えにグレードアップされたことにより、原稿を読み直すと「ん？この説明だと、ちょっとわかりにくくない？」という箇所が多数見つかる。
- 校正の本来の目的は誤字や脱字を修正することだが、僕の場合は推敲や書き直しも多数リクエストしたため、吉岡さんを困らせることになった。
2017年9月：まえがきとか、表紙デザインとか
- 1回目の校正が終了。
- まえがきやあとがきの原稿を書いていたのもこの時期。
- あと、表紙デザイン案についてもこの頃に議論していた。
2017年10月上旬：2回目の校正
- 2回目の校正を実施。この期に及んで相変わらず推敲や書き直しをリクエストして、吉岡さんを困らせる。
- 索引に載せるキーワードを抽出していたのもこの時期。
2017年10月下旬：3回目の校正（最終）
- 3回目の校正を実施。吉岡さんからは「もう推敲の段階ではないため、基本的に修正はなしとお考えください」と釘を刺される（苦笑）。
- でも何点か、推敲に近い修正リクエストを投げてしまった・・・（で、結局修正してもらいました。吉岡さん、ありがとう～😂）。
- 10月31日に校正を完了。ここからあとは一切原稿を修正できません！
2017年11月：ついに発売！！
- 11月2日、印刷所に入稿。
- 11月17日、見本誌が刷り上がる＆都内にて先行発売開始。
- 11月18日、僕の手元に見本誌が届く。
- 11月25日、全国の書店で正式に発売開始。電子版も同時に発売される。
・・・と、こんな感じで執筆と制作が進んでおりました。
いやあ、長い道のりでしたねえ。
執筆や制作に関するQ＆A
それではここからは、プログラマのみなさんが疑問に思いそうなQ＆Aを以下に載せていきます。
原稿は何を使って書いていたの？
僕はMarkdownを使って書いていました（エディタはVimです）。
また、書いた内容をリアルタイムにプレビューしたかったので、Marked 2というシェアウェアを使っていました。
どうやって変更管理をしていたの？
Markdownで書いている間はGitとBitbucketを使って原稿の変更管理をしていました。
ただし、2017年6月以降はDTPでの編集に切り替わったため、制作期間の後半は僕の方では変更管理をしていません。
校正を繰り返しているとき（2017年8月～10月）は変更点の差分だけをdiffで見たかったりしたのですが、DTPだとそういうわけにもいかず、どこがどう変わったのか確認するのにちょっと神経を使いました。。
本文に出てくる図やイラストはどうやって作ったの？
図やイラストは僕が紙に手書きで書いて、iPhoneで写真に撮って、それを共有してDTP編集時に清書してもらいました。
僕の適当な手書きの図がちゃんとそれっぽい図になって出てきたときはちょっと感動しました。
たとえば、こんないいかげんな図が・・・、
編集を経て、こうなるわけですね（すごーい）。
編集者の人とはどうやってやりとりしていたの？
Bitbucketのissue（課題）を掲示板代わりに使ってやりとりしていました。
執筆時間はどうやって捻出していたの？
僕は業務時間外で執筆していたので、執筆時間の捻出は空いた時間や土日祝日の有効活用！もうこれだけですねー。残念ながら銀の弾丸はありません（苦笑）。
あとは日々のタスクをしっかり管理して、優先順位を付けていくことでしょうか。
執筆期間中は優先度的に「ブログの執筆 ＜ 原稿の執筆」になっていたので、この1年ぐらいは普段よりもブログの更新頻度が落ちていたかもしれません。
ただ、僕の場合はリモートワーカーなので通勤時間がないのと、子どもたちがある程度自分で時間をつぶせる年齢になっていたので、他の人よりも少し時間が作りやすかったと思います。
でも、パソコンに向かう時間は確実に多くなっていたので、妻や子どもたちにはちょっと迷惑をかけていたかもしれません（ごめんね）😣
執筆や制作にまつわる所感いろいろ
最後に、執筆や制作を通じて感じたことをあれこれ書いてみます。
紙の本の制作はコテコテのウォーターフォールだった
紙の本の制作は完全にウォーターフォールですね。
- 企画や目次案を考えて（要件定義）
- ページ数や販売価格を検討し（見積もり）
- スケジュールを立てて（計画）
- 執筆して（コーディング）
- 校正して（検証）
- 期日までに印刷所に入稿（納品）
・・・というように、キレイなウォーターフォールを描いております（苦笑）。
前職まではウォーターフォール型のシステム開発もやっていましたが、ソニックガーデンに入ってからはずっとアジャイル型なので、「おお、久々のウォーターフォール開発じゃん、これ！（ちょっとイヤ😫）」と思いながら執筆しておりました。
Everyday Railsのような自費出版＆電子書籍では執筆途中でも本を公開（販売）して、読者のフィードバックをもらいながら書き進めていくというアジャイルな執筆スタイルを取ることもできますが（Leanpubではこれをリーンパブリッシングと呼んでいます）、紙の本ではいろいろ難しいんだろうなあ、という印象でした。
校正作業がアナログすぎて大変だった＆バグゼロを達成できなかった
校正は紙のゲラ（もしくはPDF）を人間の目でチェックしていく、超アナログな作業です。
しかも、最初にもらったゲラの時点で思った以上の誤字や脱字が含まれており、「本当に全部見つけられるかな・・・」と心配になりました。
校正は全部で3回やりましたが、「叩けばいくらでも出てくる布団のホコリ」のように、最後の最後まで「あっ、ここにも！」と誤字脱字を発見したりしていました。
マヌケな誤字や脱字が残ったまま出版したくなかったので、目を皿のようにしてチェックしましたし、編集の吉岡さんも僕が見落とした誤字をたくさん修正してくれましたが、残念ながらバグゼロは達成できませんでした・・・。
技術評論社さんのサポートページを見てもらうとわかると思いますが、すでにいくつかの記述ミスが報告されています（涙）。
サポートページ：プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで：｜技術評論社
「経験上、これだけのページ数（472ページ）だと誤字脱字をゼロにするのは正直難しいと思います」と吉岡さんからは言われていたものの、バグゼロを達成できなかったのはソフトウェア開発者としてはちょっと悔しいです！！（いや、むしろ開発者だからこそバグゼロの難しさを理解しているはず、というべきか・・・）
索引の作成は自動的にキーワード抽出・・・ではなかった！！
技術書の巻末にはたいてい索引が付いています。
実際に自分で本を書くまでは「専用のツールかなんかで、いい感じに自動抽出してくれるんだろう」とか思っていましたが、実は違いました！！
索引の作成は著者が本文を1ページずつ確認しながら、「このページのこの用語を索引に載せてください」と1件ずつ指定していきます。
自動作成じゃなかった！ビックリ！！
本文の執筆はブログやQiita記事の延長で書けたものの、索引の作成は初めてだったので結構戸惑いました。
（もちろん吉岡さんからアドバイスはもらっていましたが）
というわけで、どのページにあるどのキーワードを索引に載せるべきか（もしくはスルーすべきか）、という判断は全部僕が1件ずつやっています。
チェリー本を持っている方は一度索引を開いて「これ、伊藤さんが1件ずつ選んでいったのか・・・」と思いをはせてやってください（笑）。
プログラマ脳だといろいろ自動化できそうな気もするけど・・・
僕の所感をここまで読んだプログラマの方は「そのへんの作業って、やろうと思えば全部自動化してイテレーティブ（反復的）にやれるのでは？」と思うかもしれません。
実際、僕もそんな気がしていました。
ただ、できあがったゲラを見たり、吉岡さんの話を聞いたりしていると、DTPの編集作業は人間の目と手による職人的な微調整があちこちに入っているようでした。
また、もし仮に一部の工程を自動化できたとしても、別の工程とのつなぎこみでややこしい問題が起きたりするのでは？と思ったりしました。
このあたりは編集者や出版社の裏事情やワークフローをしっかり理解している人でないと、安易に「全部自動化すればいいじゃん」とは言えないんじゃないかなー、というのが僕の印象です。
（たとえば、商業出版用のフォントはめちゃくちゃ高価で、あっちこっちのマシンにおいそれとインストールできない、みたいな話もあって、読者が知らないいろんな事情が絡んできそう。）
もちろん、自動化できるところはどんどん自動化してほしいんですけどねえ。
2017.12.18 追記：自動化するやり方もあるそうです
実際に自動化してイテレーティブに制作する手法も（10年前ぐらいから）あるそうです。
詳しくはこちらのブログ記事をご覧ください（当ブログの引用ありがとうございました！）。
編集者の人がいてくれるのはありがたい
商業出版であれば通常、出版社が編集者を付けてくれます。
もちろん「プロを目指す人のためのRuby入門」でも、吉岡さんという編集者の方が付いてくれました。
編集者がいるのは以下のような点で非常にありがたかったです。
- 原稿ができあがったらすぐに感想をもらえる。
- ブログであれ、本の原稿であれ、自分が書いたものに対するフィードバックは何かしらほしいので、毎回確実に反応があるというのは物を書く人間にとって非常にありがたかった。
- 説明のしかたや文章の構成で悩んだときも相談すればアドバイスがもらえる。
- 自分のブログだと1人で悩むしかないが、本の執筆だと「うーん、わからん！相談しよう」と「困ったときの吉岡さん頼み」が使えた（笑）。
- 「こんな本にしたい」「こういうことをやってみたい」という提案やリクエストを気軽に投げられる。
- ものによっては「ビジネス上の観点からちょっと難しい」と断られたケースもあったが、多くの相談事は前向きに検討してもらえた。
- 普通のプログラマは絶対に持っていない「技術書の機能性」に関する専門知識を持っている。
- 今回「開いたままにしやすい紙」を選んでもらったのは、その最たる例。
- 紙面や表紙のデザインに関しても、単純な「見た目のカッコよさ」だけでなく、「技術書としての機能性を損ねていないか」といった観点で意見をもらうことができた。
- 校正作業でも僕が気づいていないミスを多数見つけてもらった。
本の編集者は読者からすると完全に裏方ですが、著者とは最初から最後まで二人三脚で本を作ってきたので、編集者は著者にとってはなくてはならない存在だなあと思いました。
自費出版や同人誌と比べてどう？という話はなんとも言えない
最近はてなブックマークでこんな記事が話題になっていました。
まあ、比較するポイントによっては商業出版よりも自費出版や同人誌の方がメリットが大きいという点もあるかと思います。
とはいえ、観点はいろいろあって、商業出版、自費出版・同人誌ともに一長一短があるので、一概にどっちがいいとは断言できないし、本のジャンルや著者の好みによって判断が分かれるだろう、というのが僕の感想です。
まとまらない話をつらつらと書くなら、
- たしかに1冊当たりの印税は、Everyday Rails（書籍価格16ドル、約1,600円）の方が、チェリー本（書籍価格3,218円）よりも上。
- ただし、1冊当たりの印税が低くても、数がたくさん売れたらチェリー本の方が儲かる、ということもありうる。
- 商業出版の方が著者に箔が付きやすい。
- 自費出版や同人誌だと編集者が付かない（もしくはフリーの編集者を自腹で雇う？）。
- 商業出版は印税の率が低い代わりに、大コケしてしまったり、在庫を大量に抱えてしまったりしたときのリスクは出版社が持ってくれる。
- 商業出版だと自分の本が全国の書店に並ぶ。自分の書いた本が本屋さんに並んでいるのは単純に嬉しい。
- 商業出版だとネットだけでなく、僕のことを全く知らない読者さんが町の書店で自分の本と出会うこともある。
- 商業出版の方が周りの人（親戚や友人）も一緒に喜んでくれやすい。
とか、そんな感じですかねー。
いろいろ観点がある、とは言ってみたものの、一番大きいのはやはり印税面でしょうか。
大雑把にまとめるなら、
- 自費出版や同人誌は売上げの大半が自分の懐に入る
- 商業出版は印税は確かに少ない。しかしそれ以外のメリットが大きい
という感じです。
自費出版並みの印税率で商業出版ができたら最高なんですが、世の中そんなに甘くありません。
2つの選択肢を天秤にかけて、自分にとって「こっちが良い」と思った方を選択するしかないわけです。
まあ、僕自身、自費出版の電子書籍を1冊翻訳したのと、商業出版で紙の本を1冊出した経験だけなので、偉そうにあれこれ語るのもまだ早いかもしれませんが😅
まとめ
というわけで、このエントリでは「プロを目指す人のためのRuby入門」の舞台裏をいろいろと紹介してみました。
技術書を執筆する流れや大変さが、なんとなく伝わったでしょうか？
こうやって振り返ってみると、なかなかのビッグプロジェクトでしたねえ（しみじみ）。
なので、できるだけたくさんの人に読んでもらいたいし、「よかったよ！」という感想もたくさん聞きたいなーと思っています。
まだ読んでいない方はぜひ、「プロを目指す人のためのRuby入門」を書店で手に取ってみてください！
もう読まれた方も、よかったら周りにいるプログラマのみなさんにオススメしてもらえるとありがたいです。
今後とも「プロを目指す人のためのRuby入門」をよろしくお願いします😄
「プロを目指す人のためのRuby入門」について
「プロを目指す人のためのRuby入門」は「他の言語での開発経験があり、これからRubyを始めたい人」や「Rubyプログラミングの経験はある程度あるものの、まだまだ自信がない人」に向けて、Rubyの言語仕様や開発の現場で役立つ知識を詳しく、ていねいに解説した技術書です。
詳しくはこちらのエントリをご覧ください。
Rubyのプログラミングスキルを上げたい方はぜひ、お近くの書店、もしくはAmazon等のネットショップでお買い求めください。
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者: 伊藤淳一
- 出版社/メーカー: 技術評論社
- 発売日: 2017/11/25
- メディア: 大型本
- この商品を含むブログを見る
