Date: 2017-11-24
Tags: bpstudy, 執筆

#bpstudy 123: 技術書籍執筆の実際、ノウハウ

BPStudy #123 技術書籍執筆の実際、ノウハウ に参加しました。

第１部 まず、共著からやってみよう〜Pythonエンジニアファーストブックで学んだノウハウの共有

../../../../_images/python-firstbook.jpg

  • Pythonエンジニアファーストブック

  • 共著からやってみよう

    • 執筆ノウハウを知っている共著者がいると大変良い

    • ノウハウを知ってる人がいると進め方やツールを教えてもらえる

  • ツール

    • term-validator: 用語揺れを指摘してくれるSphinxの拡張。便利

    • DropboxのPDFレビュー: 超すごい

    • Slack: 執筆後もblogや出版状況などの情報をシェアしている

  • 執筆の見積もり

    • 開発と流れが違う

    • レビューには書いたのと同じくらい時間がかかる

    • かけた時間分しか日本語は増えない

  • 知識を補完しあえる

    • 知ってる章は、自分の知識を元に正しい情報かレビューできる

    • 知らない章は、初学者として分かりやすいかレビューできる

  • 共著の強みを活かそう

    • 〇〇さんがレビューしてるから大丈夫だろう、はだめ

    • 気を遣い合わずに、率直に意見を言おう

    • だれがどこを書いてるかは読者には関係ない、全ての章が自分の責任だと思おう

    • 親にとっては、1冊全部息子の本（たしかに・・！）

  • 共著に参加するにはどうすれば？

    • 一部の人に最初に声が掛かる傾向が見えるので、その人と仲良くなろう

    • おれこんなことできるんだぜ、ちゃんとやれるよ、というアピールをしよう

    • 信頼貯金をためよう（あいつ前に約束ぶっちしたしな・・とかあると選ばれない）

Q&A

  • Q: （？）PDFにコメントを書ける機能はDropboxの機能ですか？PDF自体？

    • A: (takanory) Dropboxです。

    • (haru) DropboxとAdobeが提携したから実現できた機能らしいですよ

  • Q: (cocoatomo) なんでBottleからDjangoに変えたんですか？

    • A: (takanory)関根さんの考え一つだったんですが、実際には業務で使うのがDjangoだろうということで選んだ茨の道。実際茨の道でした

感想

  • @takanory がしゃべってる横で @hirokiky がちょいちょいツッコミ入れてるのが面白かった

第２部 技術書を書くということ。商業誌を書くということ〜Jupyter 実践入門執筆プロジェクトを終えて

  • 最初に技術書に関わったのがtakanoryさんとの共著だったので、takanoryメソッドを使っている。なので、今日の発表でメソッドはもう話されたので、別の観点で発表します

  • 技術書を書くと言うこと

    • 執筆の輪を広げる

    • 技術や専門知識を世に広める

    • 後世に記録を残す

      • 今なら、人類最古の技術書籍を残すチャンス！

  • 商業誌を書くと言うこと

    • 慈善事業ではないので売れる本でないと出版できない

    • ニーズがある分野を持ち込んだ

    • 売れる本=質の良い本とは限らない

      • 入門向けの方が裾野が広い

      • 新入社員がみんな買うExcel入門のような本とか

    • 本の評価はいまのところ、売上と利益で測るしかないのではないか

      • （読書会が開催されているかとか、blogで言及されてる量とかもあるかなと思うけど、定量的ではないからなあ）

    • 売上を向上させる

      • ニーズに応える

      • 販促活動への参加

      • マーケットの大きいところを狙う

    • 利益率を向上させる

      • 執筆のコストを下げる

      • 執筆ノウハウの共有

Q&A

  • Q: (?)いままさにRubyとRailsの本を1冊ずつ書いてるところなんですが、某社さんとやりとりしていて、紙媒体の業界だなあと感じている。そこについてどうすると良いかなにかありますか？

    • A: IT技術者だとCIで自動ビルドして・・・という常識があるけど、それができないのがつらくて、つらいと本を書くモチベーションがなくなってしまいそうですよね。なにかIT技術者からの知見やtakanoryメソッドみたいなのを広める方法がないですかねー。

第３部 はじめての執筆でわかった技術書ができるまでの流れ

  • 執筆者になった理由

    • 声を掛けられた

    • #pyhack への参加とblog書きを両方継続していたところがポイントだったらしい

    • 「こいつならやれそう」と思ってもらえたらしい

  • 序盤

    • 企画を作る

    • 書き方（プラットフォーム）を決める

    • 置き場所（リポジトリ）を決める

  • 執筆期間

    • 担当章をひたすら書いてgitlabにpushする

    • 書く場所と時間を確保する: 習慣化するスイッチ

    • 筆が進まない.. 頭から書いていくと詰まる

    • アクティビティを共有する: 始めるときにSlackにアクティビティを流す

  • 事件

    • GitLabが2017年2月に消滅した...!

    • 運良く、失ったモノはなかった

  • レビュー期間

    • 執筆関係者のみ？ゲストレビュアー含む？ 本によって色々

    • 本格的なレビューは原稿が完成してから

    • DropboxでPDFにコメントするレビュ－はよかったけど、ESCキーでファイル一覧にもどっちゃうのがつらかった。Vimmerなんで。（笑）

    • プロレビューアーのみなさんに手伝ってもらった

  • 実際に執筆してみて

    • もう少しうまくやりたかったこと

    • 日本語力ほしかった

    • 用語揺れチェック自動化したかった

    • 自動ビルドしたかった

  • さいごに

    • 家族の協力は不可欠。いま1歳の子供がいるけど、なんとかなった

    • 本は多くの人に影響を与えるもの

    • 挑戦する価値は多いにある！

Q&A

  • Q: (cocoatomo) レビューで指摘をもらったときの反映管理や、指摘内容の確認や議論などはどうしましたか？

    • A (laugh_k) 確認や議論はそれほどなかったけど、どうしても必要な場合はSlackで議論していた

    • A (寺田) 漏れチェックは有能な編集者がやってくれた

感想

  • 「家族の協力は不可欠」。ほんとそう思います。

第4部 LT大会

  • @patraqushe: Jupyter Publishing

    • スライド: https://slideship.com/users/@driller/presentations/2017/11/MwvuhqpyccTpSskM5xmpwh/

    • 本当にあった怖い話

    • 原稿を入稿したときに、最後のコミットをpushし忘れてた!

      • コードと画像が全然あってない！

      • レビューで見つけてもらって事なきを得た

    • 技術書を書いていてコードと実行結果が一致しなくてこまったことは？

      • Jupyter Notebook なら、文章も画像もコードも実行結果も一元管理！

      • 技術書はJupyter Notebookで書こう！

      • (terada)えええーーーーー

  • @koseki48724805: 偵察に来た

    • スライド: TBD

    • 編集は、我流

    • 合う人とは合う。合わない人とは合わない。

    • 本は書きたいと主張している人にしか声が掛からない

    • 出版社は新規の著者を信用していない

      • 新規の著者は逃げる確率が非常に高い！！

      • 著者の紹介は受け入れるが、紹介者がケツもってね

  • @kanako_ubukata: 技術書の原稿はWordで書いちゃダメゼッタイという話

    • スライド: TBD

    • 執筆フォーマット

      • プレーンテキスト

      • Markdown

      • Word

    • Word

      • 版組 -> 印刷用データになる

      • Wordから変換したらソースの半角が全て全角に...!

      • Word原稿のアップデートを行っていなかった!!

    • diffで見易いテキストフォーマットをお勧めします.

    • これからやる方は、私の屍を超えていって下さい

    • （最後、闇だった。Amazonレビューつらいなあ）

おまけ