初めて技術書を書いてみたので、始めから最後まで細かくレポートしてみる

はじめに

こんにちは。CTO室の @kgmyshin です。

4/22（日）。天気は晴れ。秋葉原UDXにて技術書典4が開催されました。

ご存知の方も多いと思いますが、もともとの想定来場者数の約2倍も来てしまうほどの大盛況でした。

今回、初の試みだったのですが、サークル側（本を売る方）として参加してきました。

知見の少ないなか、行き当たりばったりで入稿まで漕ぎつけて、当日は多くの方に買っていただきました。そして、なんと完売させることもできました。

本記事では、当選が決まった当時の自分が読みたかったことでもある、 どのタイミングで何をしたら同人誌ができるのかについてのまとめ を書いていきます。

この記事のゴール

この記事を読んで「これなら、自分にもできそう」と思ってもらうこと。 ひいては、この記事を読んだ誰かが同人誌を書いて技術書典などに出すこと。

目次

応募した経緯

2018年1月5日に申し込みが開始しました。

こちらとしては新年早々なので「今年はしっかりアウトプットやっていくぞ」という意気込んだばかりの時であり、DroidKaigiが翌月に迫って来ていて精神的にも昂ぶっているタイミングでもありました。 「本なんて出したことないし知見は全くないけれど、今年はやっていく気満々だし、今DroidKaigiの資料作りの勢いで本も書けちゃったりするんじゃないか（？）」と思い、気づいた時にはサークル参加ボタンを押していました。年末でなく、意識高めな新年に公募開始するあたり、スタッフの中に孔明でもいるのでしょうか。

そして2018年2月4日、当落についてのメールが届き、マイページを確認すると当選しておりました。

何を書くか

同人誌即売会の良さは好きなものを好きなように書いてしまっていいところにあると思います（もちろん守るべきルールはあります）。 私の場合は、Androidの設計に関する本にしました。

今までさまざまなところで設計に関する発表をしたり、ブログで記事を書いてきたものの、やはり限られた時間とスペースではその全体像を伝えることはできませんでした。 本であれば、全体像を丸っと書くこともできるのかなと以前から思っており、書くと決まった時点でこのテーマで書くことは確定しておりました。

巷では設計に関する良書が出てきています。そのため、商業出版だったならばバッティングを懸念して、書かなかったかもしれません。 しかし、そこは好きなことを書いてもいい同人誌即売会ということで、まったく気にせず筆を取った次第です。

執筆

ツールは Re:View を使用しました。 はじめは慣れるのに苦戦していたのですが、公式ページを見たり、技術書をかこう！ ～はじめてのRe:VIEW～ 改訂版【C92新刊】を見たり、知り合いに聞いたりなどしながら、実際に書いていくことで徐々に慣れていきました。 pdfの作成のためにTex周りのセットアップが必要で、かなり面倒だと思ったので、用意されているdocker imageを用いて作ってました。

次に進め方についてです。 執筆環境が整ったら、githubでプライベートリポジトリを立てました。 そして、まず最初に書きたいことをエディタに箇条書きにしていき、内容が思いつくところはネストして、その中でまた箇条書きにしていきました。 そこまでできたら書き漏れはないか、構成や順番に違和感はないか、書きたかったことを書けるようになっているかなどを確認しました。 下記は実際のその時のメモの抜粋です。

: - レイヤードアーキテクチャで実装する - レイヤーごとにもモジュールを分ける - infra / domain / usecase / ui - さらっと説明 - 作る順番で詳しく説明 - Domainを作る - model - entity - value object - service - lifecycle - repository - test - Infraを作る - domainの実装 - repositoryの実装 - cache - apiClient - local - test :

確認と調整が終わったら、表にまとめて上記のメモとともに「目次案」issueに載せました。

その後、各章をまた個別のissueにしていき、その中でさらにより詳しく書きたいことを箇条書きにして、また深掘りしたいところはネストして箇条書きにしていき、issueの説明欄に載せるということをしました。

すべての章でそこまでできれば、あとはもう書くだけです。 好きな順で実際にRe:Viewで執筆をして、終わった章からクローズしていくという進め方でやっていきました。 ただし、締め切りが近くなると優先順位を決めて、落とせないところを率先して書いたりはしておりました。

ちなみに、自分が登壇などで発表資料を作る場合にも同様のやり方でやっております。 先にinterfaceだけ決めて繋げて、最後に中身を実装していくイメージに近いです。

校正

いつも校正される側で、校正する側をやったことはなかったのですが、見よう見まねでやってみました。 全ページを印刷して赤ペンを用意し、あとは言い回しや文に違和感があるところにチェックをいれていきます。 私の場合はディスプレイで見るよりも、リアルの紙で見た方がスッと理解できました。 印刷して赤ペンチェックする校正方法、試したことのない方は一度でいいので試してみることをお勧めします。

表紙

やっぱり表紙は同人誌らしさ溢れる可愛い、かっこいい表紙にしたいですよね。 私はどうしても可愛いキャラクターを表紙に載せたくて、当初は自分で描くことも考えました。 ただ、どう考えてもスキル習得するための時間が年単位で足りてません。 そのため、自分で描くことはすっぱり諦めて、プロの方にお願いすることにしました。

今回は、誰でも絵師さんにイラストを依頼できるSKIMAというサイトを使用しました。 このサイトでは、コンペ形式や直接依頼する形で絵師さんに発注することができます。 私は初めはコンペ形式で募集しようとしていたのですが、自分が好きだと思った絵柄の人に書いてもらいたいという思いが強くなり、最終的には一覧を眺めてて一目惚れした絵師さんにお願いすることにしました。

お願いしたい絵師さんが決まったら、金額・スケジュールを聞いてみます。 「今、仕事を受け付けているか？」「どのくらいで、いつぐらいだったらできそうか？」を丁寧に聞いて、自分のスケジュールや予算と照らし合わせます。 双方問題なさそうであれば、〈仕事を依頼する〉メニューから正式に依頼します。

仕事の進め方はそれぞれの絵師さんによって違うと思いますが、依頼時は後々変なことでトラブルにならないように、何事も確認しておきましょう。 自分の場合は、下記の流れでした。

[私] 構図やイメージを伝える [絵師さん] 確認 [絵師さん] ラフを描く [私] 確認 [絵師さん] 仕上げ [私] 確認 完成

個人的には、特に（１）の構図やイメージを伝えるのには苦労しました。 どんな情報があれば書き始めることができるか聞いてみると「キャラクターの参考画像、構図の参考画像、絵柄などあると書きやすいです」という回答をもらい、自分なりに考えてみました。 最終的に送った要件のようなものが下記です。

絵柄は絵師さんが書いていたものの中で一番イメージに近いもので（絵師さんの画像のURLを添えて）

ベレー帽を被っている（googleの画像検索でイメージに近い画像のURLを添えて) 当時自分がやっていたゲームのキャラが被っていたのに引っ張られてます

髪型はXXXの〇〇（とある池袋を舞台にしたアニメの女性キャラクター）のような感じで

表情は口開けて、考えてる感じで

服装はボーダーに、下はスカート （服装に関してのボキャブラリーがなかったため）

構図 (これです😇)

また上記の指定以外にも、すでにいくつも同人誌を出している参考となるような技術書のリンクを送りました。

この時ばかりは、エンジニアと話したいが共通言語を持ってないプロデューサーの気持ちがすごくわかりました。 これからはもっと歩み寄りたいと思います。

また、まだまだ絵師さんに対して無茶振りをしている感を拭えないので、次回までには何かしら絵師さんとの共通言語を得られるようデッサンなどの勉強をしてみようと思いました。

サークルカット

サークルカットというものを作る必要があります。 何を売っているのか、どんなサークルなのかがわかり、そして数あるサークルの中に埋もれないものであるといいと思いました。 私は、絵師さんに書いてもらったものをベースに作りました。

入稿

印刷所は栄光さんにお願いしました。 友人がそこに依頼するからという理由でした。 サイトには初心者向けのページや説明が丁寧にされてあってすごく助かりました。 「初めてのお客様へ」「ご注文方法」「原稿の作り方」などは入稿する前に熟読することをオススメします。

この時に初めて知ったのですが、表紙と本文は別々に入稿することが多いそうです。 表紙はテンプレートのPSDファイルが用意されているので、背表紙の幅を計算して（サイトに計算できる機能があります）、適切な場所に表紙と裏表紙の画像を配置します。 普段フォトショを使っていないため、ここが地味に苦戦しました。

注文時（および背表紙の幅を計算する時）に、表紙と本文にどの紙を使うのかを選ぶ必要があります。 全く知らない単語ばかりですごくテンパってしまったので、事前に紙の種類で検索して調べておくことをオススメします。 私は表紙に「コート 180kg」、本文に「上質 90kg」を選びました。

ひと通り入稿が終わると、印刷所側で確認され、問題なければ印刷されて搬入という流れです。 入稿が完了しても、印刷側で問題があれば電話やメールが来ると思うので、手の届くところにスマートフォンを置いておくといいと思います。

見本誌提出

新刊である場合、運営に見本誌の提出をする必要があるようです。 今回から電子データ（実物と差分がないもの）を事前に提出することができるようになったので、表紙データと本文PDFをzipに固めて提出しておきました。

事前に提出しない場合は、当日の開場前にスタッフの方が回ってくるので、そこで提出すれば良さそうでした。

ブース準備

実のところ、開催日の前々日まで全く考えが及ばなかったところです。 本を積み上げただけでは値段はわかりませんし、ブースに近づかなければ何を売っているのかさえわかりません。 これらを解消するために、下記を急いで準備しました。

敷き布

ポップスタンド

ポップ（下記を用意しました）

購入方法についても準備が必要です。 弊ブースでは「かんたん後払い」と「kyash払い」に対応しました。 その準備として、それらのQRコードを一つの紙にまとめたものを印刷しておきました。

最後に一番重要なお釣りの準備です。 今回自分は一冊1000円としていたので細かいお釣りは用意しませんでしたが、細かいお釣りが出る場合はコインケースを用意する必要があります（一部コミケ熟練者の方によると、タクシードライバーの方々が使うような釣り銭ポーチが最強だというお話も聞きました）。

取り置き

友人や同僚から取り置きをしてほしいと言われることがあって、途中から管理できなくなったのでトリオキニというサービスを使い、取り置き窓口を一般にも公開しました。

当日、取り置きされてる方か普通に買いに来てくれてる方か、聞いてみないとわかりづらかったので、そこはフローの見直しが必要そうです。

ただ事前に取り置き依頼をもらうことによって「全く売れなかったらどうしよう」という不安は一切なくなったので、次回もやろうとは思います。

搬入

今回は全部で150部刷り、前々日に全てを自宅に送るようにしてもらいました。 どんな出来なのか一刻も早く見たかったという思いが強かったのです。 ただ、これは正直失敗でした。 「一冊60ページくらいなので、そんなに重くないのでは？」と変な自信を持っていたのですが、実際はすこぶる重かったです。 当日、自宅から秋葉原まで手で抱えて運んだのですが、本当に心が折れそうになりました。 前日必着会場宛てでサークル名とスペースを備考欄に書いておけば、ブースにダンボールを置いておいてくれるようです。 公式サイトを確認のうえ、お試しください。私も来年は会場に直接搬入にします。

出来が気になるという方は、数冊だけ自宅に送るということもできるようです。

当日

当日の様子です。

結果

無事完売です！

以下に、もろもろの数字を載せておきます。

まずは部数に関する数字です。

数字 結果 持ち込み部数 138冊 （140持っていき、2冊を見本誌としました） 売れた部数 138冊 取り置き数 約20冊

次に、被チェック数に関する数字です。技術書典4のサイトではユーザーはサークルチェックリストを作ることができます。 被チェックリストとはサークルチェックリストに自分のサークルを入れているユーザーの総数です。

数字 結果 被チェック数（2週間前） 約70 被チェック数（当日） 223

会計方法に関する数字です。

数字 結果 現金払い 95 かんたん後払い 39 Kyash払い 4

正直、現金払いが一番スムーズに会計ができていました（1000円なのでお釣りがほとんどでないことも大きい）。 次回はQRコードの配置やオペレーションを工夫して、それ以外の会計でもよりスムーズにできるようにしたいと思います。

全体スケジュール

実際の今回のスケジュールをプロットしてみると、こうなりました。ただ、自分はなんとか間に合った一人なので、ダメかもしれないスケジュールの一つとして参考にしてくださいませ。

反省点

悪かった点

事前にもっと調べるべきだった

スケジュールの都合で書きたいことすべてはかけなかった

スケジュールがギリギリだった

良かった点

完走できた！

完売できた！

まとめ

一人で技術書作りはできる！ もし興味を持っていただけて、実際に作る点で何か不明点など出てきましたら、ご連絡ください。相談のります！

採用情報

現在、CTO室では、エンジニアメンバーを募集しております！ 興味のある方はぜひ下記募集ページをご確認下さい！ dmm-corp.com

その他のエンジニアメンバーの募集はこちら！ dmm-corp.com