技術書を作るための技術スタック

Mercari Advent Calendar 2017の3日目はmhidakaがお送りします。
Advent Calendarで空いてるところに収まったら12月3日は日曜日ということで、エンジニアの趣味的な話です。

筆者は技術的なブログや書籍を書くかたわら、技術書のためのイベントなどを開いてます。

技術を追求すること、プログラミング、まとめることが好きでモバイル分野で継続的に書籍を出版しています。
内容はおおむね同人誌作りへ適用している技術の話です。

書籍の作り方は出版社によっても違いますが、紹介する内容と同様の作り方をしている商業書籍もたくさんあります。
ここでは著者の目線から出版業界のテクノロジーをのぞいてみましょう。

作る楽しみと読者の視点

著者が本を書く動機は人それぞれですが技術を広めたい、たくさん売れたい、自分の知識をまとめたいなど目的を持って書き始めます。
また一方で書籍の目的は読まれることでもあります。読者としては、面白い本が読みたい、勉強したい、技術を習得したいなどが目的で、自分にあう本を探しています。

作る楽しみと読者の視点が上手くバランスできると良い本です。読者がタイトルや表紙から内容を想像できて、読んでみた結果、期待値どおりだと感じる書籍はやはり評判がいいように思います。
今回紹介する手法は著者が楽しく書いた文章を整え、読者の「こんなはずじゃなかったのにな」というギャップを防ぐためのアプローチです。

自分が書いた本を読んでもらえるというのは想像以上に嬉しい体験です。感想を貰えれば改善にも活かせて一石二鳥ですね。

両立のためのテクノロジー

面白い本という基準は人それぞれですが読みやすいという部分は一定のルールがあります。

• 安易な表現を使った文章にする
• 漢字の閉じ開き、用語を統一する
• １つの文章を短く、平易にする
• 主語と述語をそばにおいて理解しやすくする

などルールにしたがって書くと読みやすい文章ができあがります。
漢字の閉じ開きとは、漢字で書くかひらがなで書くかの違いです（全て→すべて、など。いま出版されてる本は会社ごとのルールにしたがって書かれています。これを校正と呼びます）。
筆者の環境では執筆ツールにRe:VIEWを使い、校正ツールのprhや自動文書検査ツールのRedPenを導入しています。

このように文章が指定した校正ルールに反していればLintで教えてくれます。いい感じですね。
筆者自身、日本語の自由度は高すぎると思うことが稀によくあります。
適当に書いても読めてしまうし、「稀によく」という稀なのか頻度が高いのか分からない文書を書いてもなんとなくわかってしまいます。パーサー側が優秀すぎる。

prhやRedPenといったLintツールの利用は、ちょっとした工夫ですが適切に内容を伝える点において有効に機能します。
特に大人数でドキュメントを書くときには揺らぎが減り、文章が整います。このあたりはソフトウェア開発におけるコード規約と似ていますね。
小さなつまづきがなくなるだけでも、俄然読みやすくなります。

技術を活かす

技術を活かして効率化している部分は、執筆以外にもあり、書籍をビルドするための継続的インテグレーションも工夫のひとつです。
GitHubやBitbucketなどリポジトリで原稿をホストしてコミットごとにPDFを出力しています。

CIビルドがコケた場合は、執筆者へメールが飛び、悲しみの中で修正します。自動的に行われる点が大事で、
人が介在しないためストレスになりにくいです（締切に追われている中でのやり取りは、やはり神経を使います）。

実際に内容を評価する部分の自動化は流石に難しいため、レビューでフォローしています。
身近なひとから意見をもらいつつ、内容をブラッシュアップしていきます。
筆者の場合は1人で書くよりも複数人で書くことのほうが多く、ソフトウェア開発のフローを参考にプロジェクトっぽく制作しています。
ひとりで作業していると心も折れがちですし、終わりが見えたほうが手を動かしやすい事情もあります。

経験的に、同じ内容をエディタで読むよりPDFや紙で読んだほうがより書籍らしく感じます。
常に最終出力を確認しながら執筆できる環境は、読みやすさはもちろん、よいレビューを貰ったり、文章のおかしな所に気づいたりできます。

この環境を構築するまでは、自分がどれだけ書いたか進捗がわからない、最終出力の収まりが不明なまま書き終えたあとに、足りないところに気づくなどがよくありました。
出版においてもCIは大事な要素なのです。

筆者が執筆を通じて得た知見やCIサーバーなどツール、出版を支援する開発内容はOSSとしてリポジトリで公開しています。

おまけ：書籍のワークフロー

書籍をかくときは企画をたて、目次を考えて、章ごとに書き始めます。
実際に書店までならぶワークフローをみてみると思いの外、長い工程がみえてきます。
このあたりの事情もソフトウェア開発と似てるかもしれません。

最近では重版出来!など出版業界を扱ったマンガなどもありますが、それぞれの作業は馴染みがないものも多いですね。
簡単に説明すると次のような形です。

• 企画: 企画は著者が持ち込んだり、出版社が考えたり。概要や大雑把な目次はこの段階で用意します
• 執筆: 原稿を書きます。終わるまで書きます
• 編集: 文章を読みやすく推敲します。初稿、2稿、3稿、決定稿がでるまで繰り返します。おおむね3回ぐらいやります
• 組版: 紙または電子でレイアウトして版を作ります。DTPとも呼ばれます。編集と同時に進むことが多く、その場合、初校、2校、3校と使い分けることもあります
• 印刷: 色の校正など調整したあと印刷します。紙面にtypoをみつけても後戻りはできません。
• 製本: 印刷物を本の形に加工します。
• 配送: 取次が担当します。倉庫や書店へ届けます
• 販売: 書店やオンラインショップ、即売会があります

ここまで筆者が経験してきた技術スタックについて紹介しました。執筆環境や組版については他の手法もあります。執筆ではSphinxやAsciiDocなど、TeXも論文ではおなじみです。
組版においては技術書ではTeXを使うこともありますが、InDesignの場合もあります。同人誌の場合はB5やA4など一定のフォーマットがありますが、
商業書籍はサイズやフォント、画像やソースコードの埋め込みなどなどレイアウトの自由度が高く、シリーズで統一している場合もあれば、
本のサイズの時点でまったく違う場合もあり、統一規格がありません。手元の技術書を見比べてみると面白いかもしれません。きっと読みやすくする工夫が散りばめられています。

Mercari Advent Calendar 2017次回は4日目、Orakaroさんです。お楽しみに。