Media Do Tech Do Blog

株式会社メディアドゥのエンジニアによるブログです。

電子書籍の会社のエンジニア有志がはじめての技術同人誌を執筆した話

はじめに

技術書典6お疲れ様でした!!(遅)

こんにちは、エンジニアの芹澤です。メディアドゥは去る4月14日に、技術書典6にてシルバースポンサーとして協賛しました。

techdo.mediado.jp

当日は自分たちでも合同誌『Tech Do Book #1』を頒布しまして、なんと900部持ち込んだ厚い薄い本を1時間で全てお配りすることができました。当日弊社ブースにお越し下さった皆さん、改めましてありがとうございました!

当日の模様はイベントレポートにも記載がありますのでこちらもご覧ください。

techdo.mediado.jp

さて、170ページもの厚さとなった『Tech Do Book #1』ですが、こちらは弊社エンジニア有志10名で執筆した合同誌となります。私はその編集長として、記事の執筆だけでなく執筆者の公募や印刷までの手配、協賛にあたっての手続きなど裏方を進めていました。

今回は、「技術同人誌の執筆って何をするの?」というど素人状態だった私が、今回の合同誌企画を経て得た小さな経験を皆さんにも共有します。

「同僚と技術同人誌を書いてみたい!」「これから技術合同誌を書くぞ!」と思っている方のお役に立てれば幸いです。

図解 技術合同誌執筆フロー

『Tech Do Book #1』の製作は、以下の形で進めてきました。

編集者タスク 執筆者タスク
執筆者集め
工数確保
執筆テーマ決め 執筆テーマ決め
イベント申し込み 執筆のための学習
執筆環境整備 執筆、レビュー、校正
印刷所手配 執筆、レビュー、校正
イベント準備

「執筆、レビュー、校正」のサイクルを素早く回すことで、よりクオリティの高い原稿を、より素早く執筆することができます。

今回は、そのサイクルを回すために編集者が何を心がける必要があるのか、ということと、編集者が執筆以外に抱えているその他のタスクについて、注意点をお伝えします。

執筆サイクルを回すために必要なこと

まずは編集者が良き「読者」であるべし

これから編集をするあなたは、「技術同人誌」や「技術書」を読んでいますか?

今読んでいるテックブログのようなライトなメディアとは異なり、本には独特な表現、作法があります。

編集者として技術同人誌を書いてみたい!と思い立ったら、まずは実際に「技術同人誌」「技術書」を何冊か読んでみましょう。そうすることで、執筆者に対して「章全体の構成を変えてみよう」「ここの表現は変えよう」といった、linterでは検出できない提案ができるようになります。

読者の属性を決めるべし

執筆者から「こんなテーマで書きたい」という相談がきたら、書き始める前に想定する読者の属性を決めておきましょう。

事例として、『Tech Do Book #1』に収録されている拙作『Apache POIとヒープの生きる道』は、以下の点に着目して属性を決定しました。

  • 読者はその領域にどの程度習熟しているか?(Javaの初心者?中級者?チョットデキル?)
    • Javaの中級者くらいのレベル。GCのメカニズムをふんわり知っている人向け。
  • テーマに対する前提知識をどこまで求めるか?(Apache POIでのExcel操作についてどの程度知っているか?)
    • 実務で使ったことはあるしハマった経験もあるが、ライブラリの実装について深く調べたことはない人向け。

この内容を言語化しておくことで、「Excel操作の初歩的な方法は書かない」「Javaのインストール手順、ローカルでの実行手順などは書かない」「ライブラリの実装の差異から発生する、メモリの使用状況の変化についてを書く」という制約をつけることができます。

何事もそうですが、分かりきっていて興味のないことをいつまでも説明されるのは苦痛ですよね?逆に、初心者向けだと思って読んでいるのに前提知識がわからなければ、読み進めるのが苦痛になってしまいます。(※初心者向けの内容であれば、「プログラミング自体の初心者かどうか」も重要な観点です)

執筆を始める前に、執筆者と編集者で属性を合意しておきましょう。章の冒頭に、「対象読者はこんな人です」というのを入れ込んでおくのもおすすめです。

環境整備は、「執筆者に自走してもらえること」を目標に小さくスタートすべし

パソコンで執筆する原稿も、最終的に「本」になるものですので、様々な技術で「組版」を行うことができます。こういった技術は、例えば「InDesign」、「LaTeX」、「Re:VIEW」が挙げられます。

私たちは今回Re:VIEWを利用し、当初はMarkDownで書かれた原稿をmd2reviewでRe:VIEW形式に変換した後、Re:VIEWの機能でPDFに変換する、という方法を採用しました。その後、Re:VIEW形式のファイルを直接編集して、PDFに変換する方法に転換しました。

github.com

github.com

技術基盤は数多くあり、それをどう組み合わせて運用するかもまた多くの知見があります。ただし、こうした技術的な内容をいつまでも調査し続け、原稿が書き始められなかったり、原稿を書いてはいるものの最終的にどういった形でアウトプットされるかわからないまま、という状態は絶対に避けましょう。

今回得た教訓は、執筆者が「自走」できることを目標に環境整備して、できる限り小さくスタートするべき、ということです。すなわち、執筆者が書いた内容をすぐにPDF(=印刷できる状態の原稿)として出力できる状態にするのを優先して、他の整備はバックグラウンドで少しずつ進めるのが良いかと思います。

「執筆開始したいけど、そのために学ばないといけないことがありすぎるよ!」という場合は、

  • 執筆者・編集者それぞれがRe:VIEW記法に慣れる
  • PDFへの変換は、Re:VIEW標準の機能(review-pdfmaker)をローカルで手打ちする

このくらいまでセットアップできたら、執筆を開始してもいいと思います。

PDF変換のフローをCIに載せて、GitHubと合わせて継続的にアウトプット確認ができる状態になるとより良いですが、そこは執筆開始時期と相談で。

執筆以外に必要なこと

執筆者の工数確保と時間管理

今回の執筆では、原稿を書くために学習する + 実際に執筆をする時間として、40時間必要ということで上長と交渉しました。企業勤めで、工数を使って合同誌を執筆する場合は、この交渉は優先的に行いましょう!!

概ね全員が時間を守ってくれましたが、忙しい時期が重ったりと、当初の計画通りに執筆活動をするのには困難が付き物です。私たちはGitHubのマイルストーンを使って進捗や時間の管理をしていましたが、メンテナンスを怠って進捗が見えにくくなったりもしたのでここのやり方は次回に向けて洗練したいですね。

表紙・裏表紙・背表紙

言わずもがな、本のイメージに大きく関わるところです。弊社では所属のデザイナー、イラストレーターに協力を仰いで作成してもらいました。

実際に入稿する表紙データについては、印刷所が用意しているテンプレートに沿って作成する場合がありますので、下記の印刷所の選定と同時並行で進められると良いと思います。

印刷所と印刷費用

オプションは専門的な内容が多いので、早め早めに店頭で実際に相談してみましょう。印刷所に訪問して、「技術書典で合同誌を執筆したいんです」と伝えたところ、とても丁寧に一つ一つのオプションについて教えていただけました。

紙質についても実際の紙を見せていただきながら説明してもらえるので、やはり店頭で相談するのがおすすめです。

印刷費用はオプション、発行部数、ページ数で大体決まるようなので、「原稿のボリュームがどの程度になりそうか」は早めに掴めるといいですね。そのため印刷所の検討については、まず執筆環境を整備して、書き始めてもらって少ししてから始められるかと思います。

入稿日も印刷所ごとに異なりますので、相見積もりなどが必要な場合はイベント1ヶ月程度前にはページ数を概ね確定させて、印刷所に相談を始めておく必要があります。

イベントの申し込み・ブース造作

イベントに参加するのですから、当然申し込みが必要です!「どうやって協賛の申し込みをするの?」「会社の説得方法は?」といった点は、今後 id:ariaki からノウハウをお届けしますので、今回は割愛します。

当日の造作物ですが、テーブルクロス、お品書き、スケッチブック、ブース背後のバックパネル、卓上ポスターといったブースの造作物の用意が必要です。同人イベントに詳しい人がいたら、どういった物が必要か頼ってみるのもいいでしょう。

おわりに

いかがでしたか?「技術合同誌を執筆するぞ!」と思い立った際に、執筆以外にもタスクが多くあるように見えたかと思います。

実際、編集タスクをこなしながら自分の執筆のサイクルを回すのは、慣れていなかったため思ったより負担でした。

上述したように、「まずは執筆者の活動が自走できるように環境整備してあげる」ことを目標にしましょう。初期に執筆サイクルを作ってしまえば、執筆者とのやりとりの回数を減らすことができるので、他の編集タスクや自身の執筆活動にも専念できる時間が取れるかと思います。

次回の技術書典7に向けて、私たちと一緒に頑張っていきましょう!