こんにちは、16卒入社の堤下です。仕事ではジョブセンスリンクのiOS/Androidアプリを開発をしています。

みなさん、本を作ったことはありますか？
「もっと外に技術発信していきたいね」と話していたところ、4/29,30に超技術書典が開催されることを知り、有志で集まりサークル参加して本を頒布してきました。

テーマは「それぞれ自由に書く！」ということで、以下のようになりました。

GoogleAppsScriptのライブラリ開発
MySQLで色々なグラフを書こう！
自然言語処理によるフレンズ語生成
エンジニア職務経歴書の書き方
PHPのORマッパーを調べてみた
iOS アプリ開発の色々

本を書くのは技術を発信する1つの手段でしたが、書き始めてみると自分の持っている知識やノウハウを文章化する必要があり、後回しにしていた調べ物や曖昧だった部分を知る・理解する良い機会になりました。
今回は、その時の本を製作する流れと得たノウハウとを共有したいと思います。

本製作の流れ

1. テーマ・人数を決める

複数人で本を作ろうと思っている場合、まずはチャットや人伝で仲間を集めましょう。参加する側はテーマ・期間・ページ数がわかると参加しやすいです。

また、人数が集まったらキックオフミーティングをして、全体の流れや共著者それぞれのモチベーションも共有しておくことをおすすめします。

テーマ

アプリ開発や機械学習など特定の技術領域・分野で絞ることをおすすめします。テーマを絞らずに技術雑誌のような本も良いですが、タイトルや事前告知・会場で本の内容を伝えるのが難しくなってしまいます。

実際に今回作った本のテーマはバラバラで、一体なんと説明すれば良いんだ…？と悩んだ結果、会場ではポップを書いて対応しました（笑）

期間

本を出すイベントに合わせる形になります。

ページ数

本の制約として、ページ数は4の倍数にする必要があります。
また、本を作るということは表紙が必要だよね、と腰が重くなるかもしれませんが、技術書であれば表紙にイラストを利用しないパターンもあります。ただ、本を手にとってもらう第一歩にもなるため、少しでも目を惹くことを意識した方が良いでしょう。当日会場ではシンプルな本〜可愛いイラストの本まで様々でした。

2. 執筆環境を整える

著者は全員エンジニアかつ本の執筆は初めてだったので、出来る限り手軽かつ普段使っている環境に近くするため、Github + Re:View + md2review を利用しました。
執筆環境は開発環境を共通化しておくことと同じように重要なことです。インストール用のスクリプトやGemfileなど置いておくと良いでしょう。

まずはreview initコマンドで生成した状態のプロジェクトをPDF化できることを確認します。
※PDF化する際にはMacTexをインストールし、入稿用ファイルにはPDFにフォントを埋め込む必要があります。

$ review init article && cd article
$ review-pdfmaker config.yml
$ ls | grep book.pdf
book.pdf

続いて、執筆する際にはMarkdownで記述するため、md2reviewを利用してRe:View用の形式に変換した後にPDF化します。
また、基本的なアウトプットの設定は、config.yml, catalog.ymlで行います。

$ vim contents.md
# 記事を書く
$ md2review contents.md > contents.re
$ vim catalog.yml
# CHAPS: に contents.re を追記
$ review-pdfmaker config.yml

これでbook.pdfにcontents.mdの内容が入っていれば、執筆環境の構築は完了です。

TechBoosterさんがRe:Viewを利用して出版しているリポジトリを公開しており、とても参考になります。
GitHub - TechBooster/C89-FirstStepReVIEW-v2: 技術書をかこう！はじめてのRe:VIEWは技術書の執筆ノウハウ本のリポジトリです

3. 執筆する

さて、いよいよ執筆作業です。
執筆し始める前にいくつか決めておいたほうが良いことがあります。

ページ数
文章の文体
文章のレビュー
締め切り

ページ数

全体ページ数から1人あたりのページ数目安を決めておきます。ある程度書いたところで、PDF化するとページ数の感覚を掴めると思います。
ただ、最初からページ数の目安に収まるように書くのではなく、多少超えるぐらいで書くと良いでしょう。
理由は、ページ数調整の際に追記するより、部分的な削除や言い換えや画像・コードのレイアウトによってページ数合わせる方が比較的調整しやすいためです。

文章の文体

大きくは「です・ます」調 or 「だ・である」調のどちらかになると思います。
必ずしも全ての文章を統一する必要はないですが、ベースはどちらでいくのかを決めておいたほうが読みやすいと感じました。全く統一できていない本を作った結果、身に沁みて感じています。

文章のレビュー

次項の「締め切り」にも関わってきますが、スケジュール的に余裕があるのであればお互いの文章をレビューすることをおすすめします。エンジニアなら見慣れているPullRequestで文章をレビューしても良いでしょう。ただ、レビューの遅れにより進行が遅くなってしまっては本末転倒です。
そのため、

文体は整っているか
筋の通った文章になっているか
技術的な間違いが含まれていないか

など、レビューの粒度・項目も重要です。

締め切り

執筆の最終締め切りは、入稿締め切りより数日余裕を持たせておく必要があります。入稿締め切りは、印刷所や印刷方法によって違ってきます。

また、最終締め切りとは別に初稿締め切りも決めておきましょう。
理由は、文章を書き終えたとしてもそのまま完璧な状態にするのは難しくPDFで確認すると、ページ毎の文章の切れ目・画像の大きさなどのレイアウトや誤字脱字などを調整しないといけない場合が多いためです。文章を全員が書き終えた時点で1冊の本としてPDFを作り、チェックすることをおすすめします。

締め切りに追われないと書かない人もいるので、締め切りには余裕を持たせましょう（笑）

4. 入稿する

「入稿する」といっても表紙＋本文が完成していれば、利用する印刷所の入力フォームを埋めていくだけになります。
ここで失敗したら、意図しない状態の本になってしまう、と思うかもしれませんが明らかなミスがあれば印刷所から連絡が来ます。そこで修正すべき内容を聞いて、再度修正済みのデータを送ることができます。
日光企画さんを利用したのですが、初回入稿時に表紙データで不備があり、電話で丁寧に教えていただきました。

完成した本は、自宅に宅配することも可能ですがイベントと印刷所によっては、会場に直接搬入できる可能性もあるので、そうした場合には当日会場で確認することになります。