出展レポート】エンジニアとして初めて本をつくり、頒布してみて、いま思うことこんにちは。DeNAヘルスケア事業本部の馬場です。TechBoosterと達人出版会が主催する技術書の頒布イベント。さまざまな分野に携わる方が自分で書いた本を持ち寄っています。エンジニア以外の方にはなじみが薄いかもしれませんが、最近では「技術書のコミケ」としてニュースメディアなどで取り上げられる機会も増えてきているようです。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月。Handbook」としました。1冊の本ができるまでここからは実際に本ができるまでの流れを、わたし自身の体験談をもとにご紹介していきます。技術書典の事務局から参加OKのお返事をいただいたのは2019年7月10日。それまで何となく「書けたらいいな」と思っていたのが、突如具体的な話になり、「やばい!」と慌てて本づくりをスタートすることに(笑)。着手したのは全体の構成です。本はKotlinに関するTipsを集めたノウハウ集にしたかったので、日ごろの開発業務で得た気づきや思うところをピックアップして40項目に絞り、さらに難易度別に3つのパートに分けました。そこから本文を書き始めていったわけですが、この時の進め方で正解だったと思うのは、全体を少しずつ底上げしていったこと。1から40までの章を1つずつ完璧に仕上げるのではなく、全体のバランスを見ながら少しずつ加筆・修正して完成度をあげていったことで、限られた時間のなかでも無理なく進められたと思います。次に着手したのが、サンプルコードの作成です。ノウハウがより具体的に伝わるよう、40項目それぞれに対してBefore/Afterのサンプルコードを加えました。Afterには「こうすることで、こんなメリットが得られる」、「より安全性が高い実装にできる」といったコメントも加えていきました。全体の構成を決めて本文を書き、サンプルコードを加えたら、次はいよいよ組版、本文を本のフォーマットに流し込んでいく作業になります。わたしの場合、「ReVIEW」(レビュー)というフリーの電子組版システムを使いました。「ReVIEW」では、ソースコードを書くようにテキストを打ち込むと、本の体裁に仕上げることができます。「ReVIEW」によって本としての体裁が大方整ったところで、日本語として不自然な表現はないか、読みやすい文章になっているかチェックしていきます。校正は辞書をチェックしながら自分でもできますが、わたしはここでもWebの無料ツールに活躍してもらいました。フリー」といったワードでググると、フリーの校正ツールがたくさん出てくるので、それにテキストを貼りつけ、出てきた指摘は基本的にすべて修正するという進め方です。この段階でさらに読みやすくなるよう、全体に小見出しをつけていきました。最終チェック校正が終わったら、すべてプリントアウトして最終チェック。わたしは紙で出した方がより俯瞰的に見られるので、大学の卒論でも同じ方法をとっていました。読む人の目線で不自然な表現はないか、内容に過不足がないか、細かい部分までチェックしていきます。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を遡って反応を確かめることができますが、本の場合、買ってくれたとしても、読んでくれたかどうかまではわかりません。仮に読み終わっていたとしても、感想をわざわざ著者まで送ってくれる人は稀です。すればフィードバックを得られやすくなるか、書き手のアウトプットと読み手のインプットの間の溝をどうやって埋めていけるか、わたしも模索していきたいと思います。さいごに実は、今回の技術書典への参加が決まった後、エンジニアを支援する技術企画という社内の部署から「コスト面を含めてサポートしたい」というお話をいただきました。わたしはできるだけ自分の手で本をつくりたいという気持ちが強く、このお話はお断りすることに。普通なら「じゃあ、それで......」となりそうなところですが、技術企画の方はその後、社内Slackに技術書典チャンネルを開設してくれたんです。そのチャンネルから「もくもく会」(同じ場所に集まって自分の作業をもくもくと進める会)も始まり、ケータリングしていただいたお寿司をつまみながら、他の執筆者と一緒に楽しく本づくりを進めることができました。DeNAには、今回のような社外活動に様々な形で協力してくれる環境がありますし、それらをきちんと評価してくれる風土もあります。何より、エンジニアのアウトプットを応援してくれる気持ちを感じられるこの働きやすさには感謝です!今後もいろいろなアウトプットに取り組んでいきたいと思います。サービス開発グループ1995年、群馬県生まれ。そこで初めてプログラミングに触れ、iOSアプリ開発に出会う。2017年、DeNAに新卒として入社し、「歩いておトク」のクライアントサイド開発に携わり始める。現在は主にAndroidアプリ開発を行っている。※本記事に掲載の情報は、公開日時点のものです。