2019-05-08 DevRel Meetup in Tokyo #41 〜書籍の企画から執筆、編集まで〜 #DevReljp
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 なだけあって、懇親会の繋がり方もすごいですね！私は人見知りなので、知り合いに挨拶だけして帰ることが多いのですが、周りの方に会話のきっかけをつくっていただけたおかげで、いろいろな方とお話できました。
登壇者の皆さん、運営の皆さん、すてきな場をありがとうございました！
いいなと思ったら応援しよう！
