タイトル
BPStudy#123〜技術書籍執筆の実際、ノウハウ - connpass （2017.11.24）
bpstudy.connpass.com
主催
会場
国際英語学校代々木教会ビル会場 大会議室6Ｆ
東京都渋谷区代々木1-29-5 （教会ビル）
全体の感想など
最近、何か技術本を書きたいなぁ、と思い始めていました。
というのも、
techbookfest.org
というのを少し前に知ったからです。
こういうアウトプットのし方もあるのね、と。
あと、ちょうど最近、
常に書け。現在の自分の最前線を書け。いまを逃せば、いまの自分は書けない。だから、いま、書くしかないのです。理解も不十分、経験も少ない、世の中もわからない、こんなこと書いたら恥ずかしい、批判がたくさん来るかも。という状態で書くしかない。いまを逃せば、チャンスはない。
— 結城浩 (@hyuki) 2017年11月16日
というのもホットエントリーになっていたり。
ちなみに結城浩さんは、過去に自身のブログでこういったことも書いています。
本を出版するのは、一冊目が一番たいへんだ。 ほんとうに、ほんとうに一冊目はたいへん。 二冊目以降は（一冊目に比べれば）夢のように楽だ。 何が楽になるかというと、自分の中に生じる不安を吹き飛ばすのが楽になる。 「こんなに大変で、自分はやりとげられるだろうか」という不安に対しては、 「うん、大丈夫。こういう大変さはいつもと同じだ」 と答えられるようになる。 「こんなに一冊の本に時間をかけても大丈夫なのだろうか」という不安に対しては 「気持ちが前向きになっているから大丈夫。この時間は品質向上に必要な時間なのだ」 と自分に対して答えられるようになる。 いつも、祈りは必要だ。いつも、呼吸が必要なように。 それはそれとして、 二冊目以降、 自分の不安な気持ちをなだめるためのエネルギーを、 具体的な仕事に向けることができるのはとても楽なことだ。
一冊の本の7分目ほどで、何か大切なものがキラキラッと見えることがある。 本を書き始める前には知らなかった何か、 ささやかではあるけれど本質的な何かを見つかる瞬間だ。 それは著者にとって大きな報酬の1つだ。 物語をつかむ瞬間。 大きな喜びの瞬間。
でも、一番大きな喜びは、出版後にやってくる。 それは、読者から送られてくる「なるほど、わかりました！」というフィードバックだ。
私自身はこれまで本を書いたことはありませんが、この一年ほど某会報誌に毎月10ページほど寄稿していたこともあり、書くことの辛さ、難しさは多少は理解しているつもりです。でもどうせ書くなら、多くの人に届けられるものを書きたい。そんなことを悶々と思っていたときに偶然見つけたこの勉強会。これは行くしかないでしょうと。
そして今回感じたこと。本を書く人は、人に何かを伝えるのが上手い。
というか、話の「構成」がうまいのかなあ、と感じました。きちんと伝えられるような構成をまず考えているというか、伝えたいことを中心に話を作っているというか。技術書とは言えど、本を買った人に何かを残す、という使命をきちんと意識しているように思いました。
まず、共著からやってみよう 〜 Pythonエンジニアファーストブックで学んだノウハウの共有
鈴木 たかのり 氏（株式会社ビープラウド）
Slide：Pythonエンジニアファーストブックの紹介
- 6章を5人で書いた。
- ターゲットは、これからPythonを仕事で使うエンジニア
- Pythonエンジニア養成読本を改訂
- Pythonのバージョンを3系に
- Bottle → Djangoに変更
- ライブラリ、ツールを最新に
- スケジュール
- 2016年12月に改訂を打診
- 3月にキックオフの飲み会
- 6月に Web以外脱稿
- 7月に Web脱稿
- 9月9日発刊
- 打ち合わせでストーリー作成
- LEGOのデータを使おう！
- 実際に Scrapy で LEGO のデータをクローリングしている人がいる *1
Pythonエンジニアファーストブックで学んだノウハウの共有
清原 弘貴 氏（株式会社ビープラウド）
Slide：共著からやってみよう 〜Pythonエンジニアファーストブックで学んだノウハウの共有
- 初めてなら共著をオススメ
- 今まで他の本をやってきた人の執筆ノウハウが使える
- 執筆の流れが理解できる
- 執筆ノウハウ
- Sphinx で書く
- term-validator でビルドのたびに漢字や表記の揺れを自動でチェックしてくれる
- TODOや指摘をプルリクでやり取り（GitLab？）
- Dropbox で PDFファイルを直接レビュー（すごい！！オススメ！）
- PDFにコメントを付けられる
- Dropbox と Adobe が提携してるから実現してる？？
- Slack でやりとり
- コードは GitHub で公開している
- 執筆の流れ
- 意外と時間が掛かるし、流れや見積もり感覚が開発と少し違う
- 良かったところ
- 知識を補完し合える（得意・不得意）
- よく知ってる人としてのレビュー、知らない観点からのレビュー
- 著者みんなで告知できる
- Twitter、POP行脚、イベント発表、打ち上げ
- 積極的にレビューするのが大事
- 共著に参加するには？
- 声が掛かりそうな人と仲良くなる
- 私できますよ的な雰囲気をアピール
- 信頼貯金を貯めよう
- 「意見は率直に」
- by「ピクサー流 創造するちから」
技術書を書くということ。商業誌を書くということ 〜 Jupyter 実践入門執筆プロジェクトを終えて
池内 孝啓 氏（株式会社 slideship）
- 技術書を書くということ
- 動機
- 利己的
- 自己や自社のブランディング
- 経験
- 印税
- 利己的
- 世に広める
- 後世に記録を残す
- 利己的
- ブランディング
- キャリアの方向性と書籍の領域がマッチしていればブランディングになる
- 実績として分かりやすい
- 技術の輪を広げる
- コミュニティに還元（Pay it forward）
- 印税？
- 300頁／1時間あたり1.5頁＝200時間
- 一冊 120万円とすると、割に合わない？
- 納本制度
- Jupyter本も納本済み
- 知識や技術が陳腐化しても、当時の考えや歴史は覆らない
- 商業誌を書くということ
- 利益を出す必要がある
- 良い本かどうかはマーケットが判断
- Jupyter本は、2016年2月頃に技術評論社へ企画を持ち込む
- 紆余曲折を経て2017年に企画スタート
- テーマ選択の理由は「行ける！」と思ったから
- ベネフィットを届ける
- 読者は高度な専門知識に対してお金を払っている
- 正確な情報
- 妥当な方法
- 読者がどれだけ利益を得たかが全て
- 知らなかったことが知れる。分からなかったことが分かる
- 学習のきっかけ
- 売上の向上のために
- ニーズに答える
- ベネフィットを提供
- マーケットの大きなところを狙う
- 利益率を上げるために
- 執筆コストを下げる
- 執筆ノウハウを共有
- 執筆プロジェクトは、ステークホルダーの利益をどう最大化させるかという視点をもっと持つ
- O'Reillyのアトラス？どうなったか不明
- テキストからコンバート？
- GitBook？（Sphinx の代替として）
- Markdown を束ねるツール
はじめての執筆でわかった技術書ができるまでの流れ
岩崎 圭 氏（株式会社 SQUEEZE）
- スケジュール
- 2016年10月キックオフ
- 2017年6月が本来の〆切 → 8月に完成
- 形式は Markdown
- GitLab の git で管理
- やり取りは Slack
- pyhack の常連 ＋ ブログも書いていたので？ 声をかけてもらったのかな？
- まずは企画を通す
- 最初のキックオフMTGでアウトラインを出す
- ツールは、Sphinx, Re:VIEW？
- 執筆が上手くいかない問題
- 書く時間を上手く確保できない
- 平日仕事が終わったら必ず「コワーキングスペースに行く」を習慣化
- 筆が進まない問題
- 各章で最初にアウトラインを書くようにした
- 執筆のアクティビティを Slack に流す
- 執筆が死んでる感を出さないように
- 書く時間を上手く確保できない
- 1章あたりどんなに短くとも2週間は掛かった
- 原稿消滅事件
- レビューはDropboxコメント機能を利用
- 修正は時間と体力との戦い
- もう少し上手くやりたかったこと
- 日本語力不足の解消
- 最低限の校正の自動化（textlint x CI など）
- 原稿の自動ビルド（テンションが違う）
- 原稿の時点である程度レビューしたかった
- 素のMarkdownがつらい
- コラム、Note、Point など書籍ならではのブロックの表現
- とんでもない量の時間と体力を費やして本当に疲れた
- 技術的な内容を日本語に変換するのが難しい
gitlab.com の原稿消失事件は、2月のコレらしい。
結局大丈夫だったとのこと。
GitLabがデータ消失。バックアップ設定に誤りが存在。最初にシス管が誤ったサーバのディレクトリを削除。300GBの実運用データが消えた。削除をキャンセルした時点で残ったデータは4.5GB。その後、5系統のバックアップが全て働いていないか最初から構築されていなかったと発表。 https://t.co/EPwO45fiuU
— 高梨陣平 (@jingbay) 2017年2月1日
LT
技術書は Jupyter Notebook で書けばいいんじゃない？
driller / どりらん 氏
- Jupyter Notebook とドキュメントビルダーだけで OK！
- nbconvert で変換
- Shpinx, Pelican 等
- nbsphinx
- PDF や ePub を作成するなら ⇒ Sphinx
- HTML形式だけでよいなら ⇒ Miyadaiku
- ただし、テキスト校正ツールが使えない、コーディング規約のチェックが使えないなどの問題も
技術書査読・校正の現場から
Hayao Suzuki 氏
一流のエンジニア／経営者になるため基礎力を磨け！
高崎健太郎
- 一流になるためには学びが重要
- 自習、経験、環境
- ぶれない軸
- 一緒に学び合える仲間
- 学びを与えてくれるもの
- 歴史、スポーツ
- 同じテーマで議論できる
- 葛藤、挫折、新たな挑戦。組織論、戦術論
- 歴史、スポーツ
技術書の原稿はWordで書いちゃダメゼッタイという話
生形 可奈子 氏（アシアル株式会社）
- スラスラわかるJavaScript は単著
- 増刷で修正する場合は、軽微な修正であっても原稿データと同期を取る
- Amazonレビューの「違反を報告」はヤバイ
