無事、12月26日に拙書のKotlin実践プログラミングが発売されました。
この記事では「どういう経緯で本を書くに至ったのか」「どういう方法で本を書いたのか（ツールとかマネジメントとか）」「反省点」についてまとめます。
本を書くことになった経緯
6月に酢酸先生( id:ch3cooh )から slack で「『kotlinで作るAndroidアプリ入門』的な本を出したいって秀和システムの人から連絡があったので、 numa さん書いてよ」って来たのがきっかけでした。人脈大事。同じ週くらいに秀和システムに直接行って打ち合わせをしました。
実際に編集の方とお話をしたり、都内某書店のAndroidやkotlin本の販売部数を見せてもらっていると面白いことがわかりました。Androidアプリの入門書って割りと飽和しているんですよね。毎月のように入門書が様々な出版社から出版されて、同じような販売部数で終わるような。ここにAndroidの入門書を投入するのは面白くないなーと感じました。
プログラミング言語kotlinは、3月に発売された長澤太郎さんの「kotlinスタートブック」が5月のGoogle I/O以降に売上が顕著に上がっていることも教えてもらえました。Androidの開発言語として正式に採用されたことの影響が非常に大きかったようです。
これらの情報を見るに市場が求めているのは入門書じゃないように思いました。kotlinの入門をするのであれば「kotlinスタートブック」は非常に優れた内容です。さらにWeb上にも一次ソースとしてリファレンスやQiitaの記事なども色々とあります。Androidについても同様。ここに本を一冊書くのであれば、特に自分が書くのであれば、kotlinをプロダクトのコードに導入してすでに1年以上を経験している自分の経験を活かして、今後おそらく増えてくるであろう「javaで書かれたコードをkotlinにリプレースする人」をターゲットとした本を書くのがベストなのではないかなと提案を行い、企画として上げてもらいました。
初めての本なのでそんなに上手には書けないだろうとは思ってましたが、それでも自分にしか書けない内容のものを書いたほうが価値があるのでは？と考えました。
どういう方法で本を書いたのか
re:View とか tex とか使うのかなー？って最初は思っていましたが、もっと原始的なプロセスで作業を進めました。マークダウンで執筆した原稿を編集の方と共有し、wordに整形をしてもらって校正。最後に印刷用の整形をしたものをpdfで見せてもらってレイアウトを含めて校正を行って完了でした。ファイルのやり取りはGoogle ドライブで行い、原稿や整形されたwordやpdfについては特にバージョン管理を行っていません。
校正はwordやpdfを利用したので、それらの校正機能やコメント機能を利用しました。
サンプルコードに関しては、githubでリポジトリを作って章ごとにコミットをしていました。この本のサンプルコードは第2章から5章では1つのアプリのプロジェクトに対してコードの改変を行ったり追加を行う進行になっています。そのため、章ごとにディレクトリを作るわけではなく、コミットを章ごとに行って読者は自分の進捗に応じて checkout してもらう方法を意識しています。
また、サンプルコードの校正については奥さんに手伝ってもらいました。原稿を渡してサンプルコードのコンパイルが通るのか、説明文がおかしい場所はないかという点について見てもらいました。彼女はAndroidアプリのエンジニアでもないしkotlinも触ったことがないのでちょっとハードな作業だったかとは思いますが。印税入ったら食洗機を買おうと思います。
割りと地味な方法で執筆をしたので反省点も多いです。
反省点
ページ数の見積もりを盛大に間違えました。特に深い考えもなく原稿を書いていたので、当初想定していたページ数に届かないことが校正作業の後半の10月くらいに分かりました。たぶん、レイアウトの整形を行う段になって編集で気がついたのでしょうね。4章と5章に加筆としてテストコードを追加することでなんとか対応をしました。原稿を書いている段階でページ数がどうなるのかを何も考えていなかった自分も悪かったかなと思います。文字数からのページ数見積もりがもうちょっとできたらなぁと思いました。
加筆が必要だとわかったのが10月くらいだったので、実はこの時点で5章までの1回目の校正は終わっていました。そのため、加筆をした原稿をどうやって共有するのが良いやり方なのかなとちょっと悩みました。手元には最初に渡した原稿のファイルと校正指示をしたwordファイルしかありません。この時点での最新の状態の原稿が編集にしかなく私の手元にはありませんでした。これはちょっと困るなぁと。結局、校正指示をしたwordに追加をしてコメントを付けて送付しました。wordのコメントはタイムスタンプが自動で入るので。追記作業をする前にこの時点での最新のファイルを共有してもらえばよかったですね。
また、加筆でソースコードに対して大幅な追加が行われました。今回、サンプルコードは章ごとにコミットしているので章の内容が変わればその変更に追従するコミットも必要になります。しかし、何も考えずにHEADにコミットしてしまうと読者的に分けがわからない・・・。という事で、rebaseが発生します。4章と5章の内容に対してソースコードを追加・変更してrebase。ときどきコンフリクト。仕方がないとは言え、もうちょっとやり方あったかなー？と思いました。バージョン管理は捨てて、冗長になっても章ごとにプロジェクトのディレクトリを作った方が親切だったかもしれません。
原稿共有と整形に関してはどうなんだろうなぁ。re:Viewとか使ってみたかったし、利用実績に秀和システムがまだないので、第1号になれたかもしれないですがタイトなスケジュールと教育コストを天秤にかけて今回は不採用に。vcsと組み合わせて校正作業をやりやすくできたのかもしれないですが、ちゃんとチーム体制を組み上げて自分自身も運用ノウハウを身に着けないとまだ採用しにくいかなって感じです。1人でやるのなら即採用なんだけどね。
kotlinバージョンアップ早い問題もあるかな。執筆開始時点でv1.1だったけど、先日v1.2がリリースされてまぁまぁの変更が。Android Studioも3が出ました。どうすっかなーと思ったけど、コードの差し替えをやるわけにも行かないので「執筆時のバージョン」ということで執筆開始時点のバージョンをキープ。本として出す上で避けることのできない悩みなんでしょうね。これがあるからリファレンス的な内容の本をやりたくないとも思ってたのはある。
そして一番やばかったのが、11月に入ってから「本文中のソースコードの行が長い場所があるので、改行をしてくれ」という依頼が編集から来たことです。何も考えずにAndroid Studioで書いたコードを原稿ファイルにコピペしていただけだったので、本にすると改行がおかしくなってしまう可能性があるのでしょうね。これもたぶん、印刷用の整形を行ったタイミングで発覚したのでしょう。さて、プログラマーの皆様ならお分かりかとは思いますが、単純に改行をすれば良いというものではありません。文法上問題のない箇所で改行をする必要があります。とは言え改行自体はAndroid Studioの整形機能とかを利用してサクサク進めることができたのですが、変更したコードを本文に掲載する部分のみを抽出してテキストファイルにする作業が地味で面倒くさかったです。地味作業嫌い勢なので。思えば変更のあったソースコードを本文に反映させる編集の作業も大変だったでしょう。そう言えば、大学のときのレポートでもコードを印刷するときは適当に改行をしていたような気がします。最初に、コードの改行について意識合わせをしておくべきでした。
最後に来た作業としては索引作りがありました。索引なので、印刷用レイアウトが出来上がらないと作ることができないジレンマ。わりとシビアな締め切りに対して気合で乗り切りました。索引にする単語リストだけでも最初から作っておくのがよかったかなと思いました。
後やっぱり、契約についてもちょっとなぁと。契約書を取り交わしたのは実は10月になってからなので、原稿を書き始めてから3ヶ月以上経過してからでした。こういうの、良くないんだろうなぁと思いつつ執筆作業。もしも契約締結できなかったら技術書展あたりで供養するかという気持ちで原稿書いてました。これに関してはどうすれば良いんでしょうかね。他の人もそうなのかな？
感想
初めての書籍執筆で編集の方にかなり迷惑をかけたんだろうなぁと思いつつ、最初に意識合わせをやっておくべき項目も割りとあるなあという学び。今後もしも本を書くことがあればもっとうまくできると良いな。
