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