改この広告は、90日以上更新していないブログに表示しています。振り返り、もしくは技術書を書きたい人へ本を書いてからこっち、年度末で忙しかったり、体調がずっと悪かったりしていますが、そろそろ本気出します。正誤表も大幅にアップデートします。今日は、本を書いてみてどうだったか、ということをふり返る。これで本について触れるのは最後かな。宣伝はたまにすると思いますが。※思いがけず大量にアクセスがあったから、最後に追記を書いたので、そっちも読んでね!本を書いたきっかけ会社の方でPFIセミナーという勉強会のようなものをやっており、なぜかそれがUStreamでインターネットに中継されているのだが、そこで日本語入力の話をしたら「本書かない?」って話が来た。Pressの記事執筆依頼で記事を書いた際に知り合ったので、そういう意味では貪欲にチャンスを掴みに行った結果であると言えなくもない。PFIセミナーがUSTで中継されるようになったのは本当にたまたまで、前週の担当だった当時バイトの@sotarokが「USTは嫌だ」って返事してたらたぶんこの本の著者は私ではなかっただろう。人生は偶然に大きく左右される。いえ、USTの動画が公開してあったから依頼がきた訳で、情報を公開しておくことの重要性も伺える。以下、本を書くときに自分がやってよかったこと、悪かったことを振り返る。書くためにやって良かったこと最初に書きたい内容をリストアップした。どんな本にするかイメージが湧く。ReVIEWを使ってPDFを自動生成できるようにした。テキストエディタで見るのとPDFで見るのでは文章を読んだ時の感じが違うので、頭をリセットして文を読める。TeXで数式を書けるように改造して使った。TeX以外のことを全く考えてない魔改造なのがアレだが、自分で使う分には便利だった。文字数をカウントしてグラフ化した。残り文字数がどれぐらいなのか、一応の目安になった。最終的には当初予定文字数を大幅にオーバーしたのであんまり目安になってなかったけど...。原稿をgitで管理した。変更がどこかに行ってしまうことがない。基本的にリポジトリは3台のPCにコピーされるようにしていた。pushしたらhookスクリプトでPDFを自動生成するようにとかしていた。チケット管理システムを使った。作業忘れの可能性をだいぶ減らせた。(今残ってるチケットも実際には目を通して対応はしてある、はず...。)チケットの粒度は細かいほうがいいんだけど、そうするとチケットを切るときの手間が増えるとかそういう問題があって、そこら辺はうまく解決できなかった。共著だと、自分だけが書き上がっている状態も、逆に自分だけが書きあがってない状態もどちらもかなり辛い。共著はお互いに強い信頼で結びついた人がやるか、もしくは人数を多くして誰かがサボってもなんとかなるような状態でないとうまくいかないと思う。多くの人にレビューしてもらった。非コミュの自分としてはびっくりするぐらいの人数にレビューをお願いできた。レビューによって間違いも大幅に減ったし、分かりにくい部分もかなり減らせた。何人かにはピンポイントで見てもらいたいところをお願いした。これによって1章、2章にレビューが集中しがちであるという問題もかなり解消されたと思う。(小町さんが後ろ側からレビューしてくださったというのもある。結局小町さんには全体を相当詳しくレビューしていただいたけど...。)30インチのディスプレイを買った地味だが作業効率にムチャクチャ効いた。PDF見ながら校正のテキストを書くとか、これがないとどうなっていたことか。20万弱だったけどそんだけの価値は十分にあった。失敗したこと書きたい内容をより詳細にブレークダウンして見積もるべきであった。ページ数が100ページ近く膨らんだ。書くのに時間がかかりすぎた。具体的には2年近くかかっている。ボツとか書きなおしを入れると4倍ぐらいは書いてると思うので、スピード的にはこんなもんかという気もするのだが、とにかく絶対的な時間がかかり過ぎである。チケット管理システムを他の人に使ってもらう体制にした。操作が煩雑で負担をかけてよくなかった。(redmineだったというのも良くなかったと思う。)チケットの入力と処理は一人でやって、他の人は進捗だけ見れるような感じにしたほうが良かった。レビューの目的を明確化したほうが良かった。音引きとか全角半角等の統一に関しては編集さんのチェックが後で入ります、とか。レビューにかけてもらえる時間には限りがある訳で、情報が後出しになるようなことはできる限りさけるべきだった(結構努力はしたつもりだったけど、振り返ってみると足りなかった)。最後の方はかなり煮詰まった。最後というか、後半はずっと煮詰まりながら作業していた。見積もりが甘かったせいで、ラストスパートの精神的な負担がかなりきつかった。Readerの注釈機能が重すぎて辛かった。Windowsも使えるようにしておけば良かった。商用のフォントを買えば良かった。印刷に使うような類のフォントでPDFを見た方が、脳の違う部分を使うためか問題を見つけやすい。リュウミンかなにかを買えば良かった。書き上がる前に定期的に相談できる人を先に作っておいたほうが良かった。いう人を監修者と言うのかな。強制的にミーティングの機会とか設けないと、人には出来上がってから見せようという気持ちが強くはたらく(この辺りは修論書いてた頃からあまり進歩してないな...)。目次を細かくブレークダウンしたぐらいの状態で定期的に議論をしていく人がいたら、主に速度面で良かったと思う。全体的に見てどうだったか締め切りを破ったせいなので自業自得なのだが、後半はかなり辛かった。それ以外の点は初めての書籍執筆としてはまぁまぁうまく行ったのではないか、と思いたい。追記:自分で追い込まれていただけで、編集さんは豆腐メンタルな技術者のことをよく理解しており(さすが社名に技術と入っているだけある)、適切な対応をとっていただいた。自分にはあんな丁寧な対応はできないと思う。売れ行きけっこうよく聞かれるので改めて書いておく。Plusシリーズという時点で結構下駄を履かせてもらってる感がある)方である。実際のところ、印税生活どころではない(そしてもちろんおごるどころの話ではない、君が遊んでた時にも俺は死んだような目をしながら執筆してたんだよ!)し、技術書というのは一般論として本当に売れないものなのだなということをあらためて実感させられている。これから自分の専門書を見る目はだいぶ変わるというか、温かい視線になると思う。出しただけでもとりあえずよく頑張ったよね、的な...。嬉しかったこと当たり前だが、読んでくれた人、実装してみた人の存在が一番嬉しい。書いた甲斐があったなと感じる。本を読んでダブル配列作ってみたという人も既に2,3人見かけた。文章にするとほんの一文でしかないけれども、読者の存在が一番の理由なのだということが、書いてみて実感できた。読者がいなければ、たとえ印税が10倍になったとしても、技術書を書く人なんてこの世からいなくなるだろう。他の人に本を書くことをすすめるか?自分と同じ経験をするのであれば、勧めない。自分は明らかに失敗したところがあるので、もっと効率よく執筆できるのならば本を書くのは良いと思う。自分自身があやふやに理解しているところは全部勉強し直すことになるし、こんな長文を書く能力を磨く機会は滅多にない。ひとつアドバイスがあるとしたら、編集さんが最初に勧めてくるページ数は過去のいろいろを踏まえて計算されているから、そのページ数に書きたい内容が収まらないなら、内容の方を減らすべきである、と過去の自分に言いたい。自分はプログラミングを始めたのは遅いし、プログラミング適性も普通程度でしかないことも自覚している。そもそも大学の出身学部は情報系ではないし、査読付き論文を採択率の低い学会に通したこともないまま修士も卒業してきた。大学院を卒業できた気がしておらず、喉に小骨が刺さったような不愉快な感じがあったのだけれど、本も書けた(世間様の評価はどうあれ、自分としては本の出来には満足している、レビュア様のおかげであるけれども。)し、そろそろ自分の中でも卒業としていいかな、というよい区切りになった。はてなブログをはじめよう!tkngさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。