【技術書典7 出展レポート】エンジニアとして初めて本をつくり、頒布してみて、いま思うこと

こんにちは。DeNAヘルスケア事業本部の馬場です。

突然ですが、みなさんは技術書典をご存じでしょうか？

技術書典は、 TechBoosterと達人出版会が主催する技術書の頒布イベント。毎年2回開催され、アプリ開発、機械学習、電子工作など、さまざまな分野に携わる方が自分で書いた本を持ち寄っています。

エンジニア以外の方にはなじみが薄いかもしれませんが、最近では「技術書のコミケ」としてニュースメディアなどで取り上げられる機会も増えてきているようです。

2019年9月22日（日）、池袋サンシャインシティで開催された「技術書典7」に、わたしはKotlinについて書いた自分の本を出し、ブース出展してきました。

本を書くのも、自分で頒布するのももちろん初めての経験。その過程で本づくりの楽しさや難しさなど、わたしなりにいろいろな発見があったので、この場を借りて共有したいと思います。アウトプットの仕方に悩んでいるエンジニアの方や、技術同人誌を作りたい方の参考になればうれしいです。

技術書典を知ったきっかけ

そもそもわたしが技術書典を知ったのは、Twitterがきっかけでした。

Twitterでフォローしているエンジニアが「技術書典行ってきた」と書き込んでいるのを見て、「なんだろ、これ...…？」と。そこで2018年10月に開催された「技術書典5」へ行ってみたんです。

会場で受けた印象は、まさに「すごい！」のひと言。わたしとそれほど年齢が変わらないエンジニアが、自分で書いた本をブースに並べ、人だかりをつくっているのを目の当たりにして、「本は有名な人が出すもの」という先入観は消え去り、「自分も書きたい」と思うようになりました。

テーマ選びから参加申し込みまで

とはいえ、本を書くには相応のテーマが必要。何について書こうか悩んだ末、候補にあがったのがKotlinです。

Googleが推奨言語に指定したこともあって、Androidアプリの開発において使用される言語は、従来のJavaからKotlinがスタンダードになりつつあります。わたしが担当している歩数計アプリ「歩いておトク」でも元々はJavaで書かれていましたが、2018年の夏頃からKotlinへの移行を行なっています。

JavaからKotlinへの移行を進めるなかで少しずつKotlinへの理解が増し、Javaから書き換えるメリットも実感できるようになり、「自分がいま本を書けるとすれば、Kotlinについてかな…...」と考えるようになっていきました。

そうした背景から、「技術書典7」への参加を申し込んだのが今年の6月。本のタイトルは、テーマに沿って「Java to Kotlin to better Kotlin Handbook」としました。

1冊の本ができるまで

ここからは実際に本ができるまでの流れを、わたし自身の体験談をもとにご紹介していきます。

Step1. 全体の構成＆執筆

技術書典の事務局から参加OKのお返事をいただいたのは2019年7月10日。それまで何となく「書けたらいいな」と思っていたのが、突如具体的な話になり、「やばい！」と慌てて本づくりをスタートすることに（笑）。

まず着手したのは全体の構成です。本はKotlinに関するTipsを集めたノウハウ集にしたかったので、日ごろの開発業務で得た気づきや思うところをピックアップして40項目に絞り、さらに難易度別に3つのパートに分けました。

そこから本文を書き始めていったわけですが、この時の進め方で正解だったと思うのは、全体を少しずつ底上げしていったこと。

1から40までの章を1つずつ完璧に仕上げるのではなく、全体のバランスを見ながら少しずつ加筆・修正して完成度をあげていったことで、限られた時間のなかでも無理なく進められたと思います。

Step2. サンプルコードの作成

次に着手したのが、サンプルコードの作成です。ノウハウがより具体的に伝わるよう、40項目それぞれに対してBefore/Afterのサンプルコードを加えました。さらにAfterには「こうすることで、こんなメリットが得られる」、「より安全性が高い実装にできる」といったコメントも加えていきました。

Step3. 組版

全体の構成を決めて本文を書き、サンプルコードを加えたら、次はいよいよ組版、本文を本のフォーマットに流し込んでいく作業になります。わたしの場合、「ReVIEW」（レビュー）というフリーの電子組版システムを使いました。

「ReVIEW」では、ソースコードを書くようにテキストを打ち込むと、本の体裁に仕上げることができます。

Step4. 校正

「ReVIEW」によって本としての体裁が大方整ったところで、日本語として不自然な表現はないか、読みやすい文章になっているかチェックしていきます。

校正は辞書をチェックしながら自分でもできますが、わたしはここでもWebの無料ツールに活躍してもらいました。「同人誌校閲　フリー」といったワードでググると、フリーの校正ツールがたくさん出てくるので、それにテキストを貼りつけ、出てきた指摘は基本的にすべて修正するという進め方です。

また、この段階でさらに読みやすくなるよう、全体に小見出しをつけていきました。

Step5. 最終チェック

校正が終わったら、すべてプリントアウトして最終チェック。わたしは紙で出した方がより俯瞰的に見られるので、大学の卒論でも同じ方法をとっていました。読む人の目線で不自然な表現はないか、内容に過不足がないか、細かい部分までチェックしていきます。

また、今回の本では40章それぞれにBefore / After、計80種類のサンプルコードを載せていたので、それが実際にシステムとして動くのか、構文エラーはないか、あわせてチェックを行ないました。

本づくりは書くだけじゃ終わらない

ここまでで技術書としての形はだいたいできあがったものの、実際にイベントにブースを出展し、紙の本として頒布するとなると、まだまだ終わりません。

わたし自身、本をつくること＝書くことだと思っていたのですが、実際はそれ以外にもやるべきことが本当に多く、そこに本づくりの奥深さや、工作的な楽しさ（もしくは難しさ）があると知ったのも、今回の大きな発見でした。

そのうちいくつかをご紹介します。

・表紙のデザイン

本の第一印象を決める表紙のデザイン。人によってはデザイナーに外注することがあるようですが、わたしはできるだけ自分の手で本をつくりたかったので、自分でやってみることに…...。

技術書典と提携している印刷所のテンプレートをベースにして、初めてのフォトショップ・イラストレーターと格闘しつつ、何とか仕上げることができました。日ごろからPCと向き合っているエンジニアでも、デザインに苦手意識を持っている方は意外と多いような気がします。

ちなみに、わたしは家族がソフトを持っていたのでそれを使いましたが、キンコーズさんの店舗へ行くと、フォトショップとイラストレーターがインストールされたPCを借りられるようです。

▲ デザインした表紙

・入稿と印刷

紙の本として頒布するためには、印刷も欠かせない工程です。

わたしはイベント主催者のTeckBoosterさんが提供しているテンプレートを使ってPDFの入稿データを書き出したのですが、表紙の裁断サイズやノンブル（ページ数を示す数字）の付け方など、それでもわからないことだらけ（笑）。

そこで、技術書典と提携している印刷所（お茶の水にある日光企画の工房）に直接足を運び、職員さんの丁寧なサポートを受けながら、何とか印刷までもっていくことができました。

入稿はオンラインでもできるものの、Webだとわからないところはわからないまま。差し戻されてしまうケースもあるようなので、本をつくりたいエンジニアの方は印刷所に直接持ち込むのがおすすめです。

ちなみに、技術書典と提携している2つの印刷所（前述の日光企画と、ねこのしっぽ）に印刷をお願いすると、刷り上がった本を当日会場まで搬入してくれるので便利。さらに日光企画ではイベント参加者の特典としてA2判のポスターもつくってもらえます。

▲ 出来上がった本が届いた時の様子

・ブースの制作

技術書典のブースは長机半分ほど。限られたスペースでも「ちゃんとやっている感」が出せるよう、見本誌を用意したうえで、机の上に表紙と同じデザインのぬいぐるみを飾るなど工夫しました。

また、人だかりでブースが埋もれてしまわないよう、ブースの背後には先ほどのA2ポスターを貼り、机上にはキンコーズでラミネートしたPOPを立てかけることに。

・ダウンロードカードの制作

技術書典は基本的に紙の本を売るイベントなのですが、そこはやはりエンジニア。紙ではなくPDFなどのデータで読みたいという人もいます。わたしの場合、印刷所にお願いして名刺サイズのダウンロードカードをつくり、パスワードを付けたうえで本の購入者特典として配布しました。

・宣伝

自分のTwitterアカウントでの告知のほか、技術書典の公式サイトでも宣伝ができたので、そこに表紙と目次の画像を掲載し、あらかじめどんな内容の本なのかわかるようにしました。

▲ 出典：私のサークル紹介ページ

イベント当日の様子

こうした準備を経て迎えた9月22日当日、会場には約600のブースが集まり大盛況。そうしたなか、事前の宣伝やブース装飾の効果がどれほどあったかはわかりませんが、多くの方に自分が書いた本を手に取ってもらえました！

▲ 開場前の様子

ちなみにブースはお手伝いをお願いしていた方と2人で運営してギリギリでしたが、他のブースも見て回りたいので少しの時間だけお任せして回ることに。ひと通り見たところ、個人での参加は少なく、友達同士やサークルでの出展がほとんどでした。

本の内容としては、いまのトレンドを反映しているのか、クラウドや機械学習、AWSに関するものが主流。また、組織論やプロジェクトマネジメントに関する本も多く、わたしもそういった本のいくつかを購入しました。

その一方、Androidアプリに関する本を頒布しているブースは全体600のうち10か所ほど。さらにそのなかでわたしの本のように1つの言語に絞ったものとなると、かなり少なかったような気がします。

本をつくり、頒布してみて、いま思うこと

本をつくり、自分で頒布してみて、いま強く感じるのは、「歩いておトク」においてKotlinへの移行プロジェクトをスタートさせてから約1年間の自分の成長を見える化できたという達成感です。

日ごろの業務のなかで「知識が身についてきた」、「スキルアップしている」と感じることはあっても、それを目に見える形でまとめられる機会は多くはありません。そういった意味で、自分の成長を本という形できちんとアウトプットできたことが、今回の何よりの収穫だったと思います。

たとえば今後、1年ごとに本を出していくとしたら、そこにはやはり1年かけて自分がやってきたことがあらわれるはずです。逆に本にするだけのネタがないのなら、それだけの1年だったということ。エンジニアにとって、本は自分の成長を確かめる指標のようなものになるのではないでしょうか。

一方、本という媒体ならではの難しさを感じたこともありました。その1つが読んでくれた方からのフィードバックが得られにくいという点です。

たとえば、エンジニア向けのカンファレンスでは、プレゼンを聴いてくれている方の反応をリアルタイムに見ることができますし、登壇後もTwitterを遡って反応を確かめることができますが、本の場合、買ってくれたとしても、読んでくれたかどうかまではわかりません。仮に読み終わっていたとしても、感想をわざわざ著者まで送ってくれる人は稀です。

どうすればフィードバックを得られやすくなるか、書き手のアウトプットと読み手のインプットの間の溝をどうやって埋めていけるか、わたしも模索していきたいと思います。