2019/05/08 に開催された DevRel Meetup in Tokyo #41 〜書籍の企画から執筆、編集まで〜 のイベントレポートです。

●イベント概要
書籍、雑誌ができあがるまでの流れを学ぼう

Amazon、Google、Facebook、Evernote、GitHub…多数の企業が実践しているマーケティング手法がDevRel（Developer Relations）です。外部の開発者とのつながりを形成し、製品やサービスを知ってもらうこと、さらに彼らの声を聞くことでサービスの改善や機能追加に活かしていく活動になります。

日本でもエバンジェリストやデベロッパーアドボケイトと呼ばれる方が増えており、製品やサービスを紹介しています。DevRel Meetup ではそうしたエバンジェリスト、DevRel活動を行っている方が集まり、知見を共有したり情報交換をする場にしたいと考えています。イベントを繰り返すことでDevRelやエバンジェリスト、アドボケイトの認知度向上をはかりたいと考えています。

今回は書籍の企画、執筆、編集までの出版に関わるステップを学ぶ内容になっています。DevRelにおいて書籍を出版するのは新しいユーザ層へのアプローチにつながります。最近は書籍以外にもムック本、同人誌など様々な形態があります。今回はそんな出版にフォーカスを当てます。

■技術書典 6 参加者からみた「技術書とイベント」

長内さん

●技術書典とは
・技術者のための「コミケ」
・新しい技術に出会えるお祭り

●参加した理由とモチベーション
・ライター & 売り子 として参加
・当事者になったほうが楽しそう
・経験や知見を形にしたい
・自己アピール

●思わぬ技術との出会い: セレンディピティ
・普通に本を買う場合
　　明確な学習目的がある
　　-> Amazon、本屋
　　　 目的を持って検索する
　　自分の知識・脳内にある範囲しか手が出ない

・技術書典での購入動機
　　前から気になっていた
　　　　-> 潜在意識と反応して購入へ
　　衝動買い
　　　　->鉄道、バスの接近情報はopen dataで提供されているらしい!
　　知っていることの再確認
　　-> Amazonや本屋では出会わなかった

●未知の技術の「道案内」
・httpの仕様を、一度勉強したいと思っていた
・RFCは読みづらい
-> フロントエンジニア向けにまとめてくれている本に出会った

●時間的なショートカット
・技術書にある情報は、大抵ネットにある
　　タダで手に入るなら買わなくてもよいのでは？
・探す、体系的に理解するには、相当な時間と労力が必要
　　2000〜3000円で済むならやすいのでは？

●プロと同人書籍の違い
・販売書籍のほうがクオリティは高い
・プロの書籍は、コース料理
　同人書籍は、屋台料理

●技術文章を書く意義
・頭の中の棚卸し
　　言語化できるかどうかで、理解を確認する
・文章化の練習
　　文章は自分が出る
　　テーマは同じでも、人によって内容が変わることに驚いた

■技術書の出版って？

大内さん

●出版社ではたらく人を知ろう
・作る人
・売る人
・サポートする人

●出版社で働く：売る人と取次
※新刊委託のさわりだけ
・取次
　　全国各地の書店に配本
・書店
　　買い切りもあるが、たいてい委託で販売
　　3ヶ月なら返品可能
　　-> 3ヶ月経つと返品がどっと来る
・出版社の営業
　　刊行前から、各地の書店に営業をかけて注文を集める
　　　　都市部は足で回る
　　取次の新刊見本受け付け日
　　　　完成品と事前注文を持って、部数の要望を伝える
　　-> 取次が実績や事前注文から配本部数を決定
　　-> 刷部数決定

・新刊委託では出版社はコントロールできない
　　仕組み上、実売数もわからない
・新刊に合わせた書店トークイベント、ブックフェア
　　初速が命！

・作る人、売る人、配る人、直接売る人
　　いろいろまだるっこしい
・大量に撒いてもらえるのはありがたいがデメリットも
　　書店の棚問題
　　　　これ、どの棚で売るの？
・本が売れないため、本が増える
　　 1冊 で 10,000部 売れないなら
　　10冊 で 1,000部 出しましょう

●技術書ができるまで を知ろう

・企画をGOまでもっていくプロセス
　　・思いつく
　　・リサーチ
　　・著者候補にアタック
　　・企画書 <-> 編集部打診
　　・本としてのイメージを明らかにしていく
　　　　企画概要
　　　　コスト試算 etc
　　・企画会議 -> 刊行会議
　　・実作業スタート

・原稿を書いてもらう
　　・著者に原稿を書いてもらう
　　・編集はできるだけ会う
　　　　ほっとくと書いてない人も
　　・仮アップ <-> レビュー でフィードバック
　　・最終原稿
　　・本文フォーマット
・本にする
　　・DTP開始
　　・初校出
　　・カバーデザイン
　　・印刷所入稿
　　　　青焼き、白焼き
　　　　チェック
　　・見本出し

●本にする
・技術系の人だと、Re:VIEWなどで自動組版が多い
　　DTP作業を編集者がやることもある
　　編集側が適応できていることは少ないのではないか
・自分はデザイナーにページを組んでもらう
　　テキストと画像を分離
　　テキストで原稿整理
　　このあとで直したいと思うと校正に対する修正指示
　　著者とフローをすり合わせておく

●技術書を作る方法を知ろう
・同人誌なら技術書典が盛り上がっている
・電子書籍はプラットフォームが増えた
　　先細り感はあるが
　　個人出版は増えている
・オンデマンド出版も高品質に
・技術書のクラファン Peaks

・なぜ、今、その企画なのか
　　なぜつくりたいのか
　　それを誰に届けたいのか
・書店に置く
　　「出版社〜取次〜書店」に乗るのがてっとり早い
　　書店直販に動いてみるのもアリ
・書店に置かない
　　版型はもっとチャレンジしても良いかも

・編集者の立場で、どんな本をつくりたいか？
　　誰かの何かしらの心情に、少しでも響く本
　　これまでもこれからも変わらない
　　※売れるに越したことはないが

●動き出すモチベーションとして「なぜ」が共有できること
・企画の相談は「なぜ、今、その企画なのか」から
　　「なぜ」はニーズでなくても良い
　　自分が伝えたいコレは、今の時代に必要なんだ！という信念でも
　　出版社で通せるかは分からない
・「おもしろいか」に尽きる

●DevRel本 8月に出版予定！

■ITエンジニアならば本を書いて稼ごう！ [2019年版]

池本さん

かわいい本をつくることに命をかけていますw
男社会なので、女性に読んでほしい

●技術書執筆の心得
1. 勉強して書かないこと
　　お客様が読むので、事実に基づいた経験
　　再現性も大切
　　　　コードならば動くことが最低限
　　溜まった経験と知識、技術を書く
　　　　勉強して書いたことはバレる
　　勉強せずにかける
　　　　他人にスラスラ教えられることが、あなたの技術
2. 読者を意識すること
　　第三者目線で書く
　　共感を生む
3. スタイルにこだわらない
　　マークダウン、Re:VIEW いろいろあるが
　　商業出版を前提にすると、最後にInDesignで作り直す
　　見出しなども全部編集者が作成することもある

●それでもスタイルにこだわりたい方へ
・結城浩 先生
　　数学文章作法 基礎編
　　数学文章作法 推敲編
-> これがあれば良い本をつくれる

●なぜこんなことをまとめてみたのか？
・2000年代初頭ITバブル
　　調べてかけば当たった
　　某月刊誌は広告収入が毎月1億円だった
　　月刊誌の広告枠がいっぱいになったから隔週になった
-> クオリティとファクトが必要になった

●執筆のメリット
・自分の中をさらけ出す
　　知識と技術の棚卸し
　　ためておくと古くなる
・なぜを極めれば売れ続ける
・良いループを回せば時間ができる

●根本的な問いかけに答える本が売れる
　　Spring でDIの本 の10倍は、ネットワークの本が売れる
　　仮想化の公演を聞いて、Linuxについての執筆を依頼

●スキマ時間の有効利用
　　移動時間、仕事の合間で書ける

●得意を伸ばす。特化する
・DB
・OSS -> 英語文献を自分で翻訳
・プログラミングがだめならSQL
・多くの人がまだできない技術
・ハードウェア
・数学
-> 稼げるようになったら編集に相談

●「得意と好き」は違う。「出来ると使える」は違う。
　　他の人が苦労することを
　　楽々と苦労なくできることが得意

■感想

普段関わりのない業種のお話だったので、リアルタイムでの理解は難しかったですが、レポートにまとめながら「なるほどー」と感じられる部分がたくさん出てきました。

・業種それぞれの成長経緯に沿って、サプライチェーンも成長してきた
・ものづくりという観点だと、システム開発と近いプロセス構造
・扱うモノが違うから、モノに合わせた職種が必要になる

・技術書典に行ってみよう！
・「苦手なことを埋める」考えが先行してしまうので
　「得意なことを伸ばす」発想を癖づけてみよう！

DevRel なだけあって、懇親会の繋がり方もすごいですね！私は人見知りなので、知り合いに挨拶だけして帰ることが多いのですが、周りの方に会話のきっかけをつくっていただけたおかげで、いろいろな方とお話できました。

登壇者の皆さん、運営の皆さん、すてきな場をありがとうございました！