こんにちは、吉岡([twitter:@yoshiokatsuneo])です。
先日の記事のように、Dockerの技術書『Docker実戦活用ガイド
(現在、Amazonではサーバ、ネットワーク書籍のベストセラー1位になっているようです。)
今回、はじめて技術書を出版したのですが、 どのような流れで書籍を出版するようになったか紹介してみたいと思います。 実は、書籍の出版はソフトウェア開発の流れと似ていることもわかります。
企画
技術書を書く予定は全くなかったのですが、機会は突然やってきました。
まず、今年の1月はじめに出版社の方からDockerの書籍執筆について、問い合わせをメールでいただきました。 以前にデブサミでDockerについて発表したことがあり、その資料を見たとのことでした。
paizaのオンラインジャッジを支えるDockerとその周辺
まずは話をということで、1月半ばに打ち合わせさせていただきました。 paizaではDockerを使ったオンラインジャッジシステムを実運用しており、その構築・運用経験を元に書籍という形でまとめるのはどうか、という提案です。 出版社との打ち合わせでは、Dockerの解説に、発表資料の内容、簡単なオンラインジャッジシステムの作り方を組み合わせ、中級レベルの方向性で書籍を作りましょう、という感じになりました。
書籍を書いたことがなかったので、まず量が書けるかが気になります。ページ数は300ページ程度、文字数としては、コードや図も入るので10万文字程度とのことだったと思います。期間は3ヶ月程度を考えてるとのことでした。 ちょうど少し前に、かなり長めのブログ記事３本を書いていたのですが、それがあわせて160KB、日本語で半分にすると約8万文字でした。量的にはこれより少し長めなので、書けない量ではないし、どれぐらいの労力かもおおよそ目処を立てることができました。
また書籍にするだけのネタがあるかも気になります。 まずは目次をということで、Dockerで必要なことがら、デブサミ発表資料、オンラインジャッジシステムの作り方、ツール、など思いつくことを並べて作ってみると、全部で200行ぐらいになりました。1項目2ページぐらい書けば行けそうです。
目次をお送りしたところ良さそうとのことで出版社の中の企画にあげていただき、無事に通していただきました。
契約
書籍執筆にあたっては、形態として業務で行うのか個人的に受けるのかを考えることになりました。今回の書籍はpaizaの事業に関係する話ですし、とても家や空き時間でできる範囲ではないと思いました。会社としても、業務として行っていいのではないか、との話でしたので、今回は100%業務として執筆することになりました。(印税は会社が受け取る形です。)
実際、執筆はかなりの集中力と労力が必要で、執筆期間はほとんどの時間を費やしていました。会社員で本業をしながら、別に執筆されている方もいますが、とてもできないことで頭が下がります。
印税は、技術書の初版は7-8%程度のことが多いようで、今回もその範囲です。初版分の印税は保証してくれますので、一冊も売れないから一円も入らない、ということはありません。電子出版は印刷がいらないためか、印税は高くなります。
そもそも書籍を書けるような環境かを含めて、どのような形態で書くかは会社・個人の仕事のあり方、柔軟性、方針などともよって様々で、個人契約で業務の空き時間に書く場合や、会社と個人で印税を半分にする場合などもあるようです。雑誌の短めの記事なら、個人契約で業務の空き時間などを含めて書くことは多かとは思います。
執筆準備
さて、いよいよ執筆です。 といいたいとことですが、実際にはなかなか執筆をはじめず、最初の話から2ヶ月経った3月半ばまで1ページも書いておらず、編集者には迷惑をかけてしまいました(申し訳ありません(.))。原稿が少しでもあれば、表紙のデザインもできるので送ってほしいとのことですが、1ページも書いていないので何も送れません。。。出版社としても1ページも書けていないものにデザインできるわけがありません。
言い訳にはなりますが、まず、進行中のプロジェクトをある程度まとまってから書き始めたいと思っていました。実際、執筆中は他のことがほとんどできていなかったです。 また、発表資料を作成してから、かなり時間がたっており、最新情報にあわせるためにDocker関連を一通り調べなおすこともしました。
他のDocker書籍も一通り目を通しておきます。日本語の書籍はそれほど数が出ていないので、ほとんど確認しました。英語は数が多いですが、オライリーを含めて有名どころを確認しておきます。 多くの書籍を読んでいくと、これだけ情報があれば新しく書籍を書く必要はないのでは、と思うときがあると同時に、自分だったらこの項目を入れる、このように書く、など方針も見えてきます。
さらに、書籍の中で作るDockerを用いたオンラインジャッジシステムのサンプルも作っておきます。
執筆
3月半ばになって、ようやく１ページ目を書き始め、編集者に送らせていただきました。最初の数日は1日1章のペースで書いていきました。図などは飛ばして、文章の見直しもほとんどなしで、どんどん書いていきます。普段しない集中して書く作業をするので、かなり疲れます。まだ先が長く、完成に向かって進んでる気がしないとモチベーションも落ちそうなので、量を増やすことが最優先です。
また、ちょっとしたことで集中力が落ちてしまうのと気分を変える意味でも、図書館にお世話になりました。幸い、オフィス近所の図書館には、WiFi完備で電源も用意されたパソコン対応の席がありました。 国会図書館も行ってみましたが広くてよかったです。 静かに集中したいときには図書館はいいですね。自分のタイプの音やマウスホイールを動かす音が騒音になってないかと思うほど静かです。
1日1章のペースは保てませんが、数日で1章ぐらいまでで間違いなど気にせずにとにかく書いていきます。書いていくうちに目次とずれる部分もありますが気にしません。だんだん疲れてくるので、まずは最後まで行きたくなってきます。
数週間で一通り(13章)書き終わります。 大きな山は越えた、、、けどまだまだです。
まず、図が全くないので、書いていきます。発表資料なども元にします。これも、まずはざっとした図を書いていきます。
フォーマット・ツール
フォーマットはWord、Markdownなど何でもいいとのことでした。ブログはMarkdownで書いていたので、Markdownを使いました。章ごとにMarkdownファイルを作り、GitHubで編集者と共有しました。 図は章ごとにKeynoteで書いておき、イメージとしてエクスポートしていきました。 図は丁寧に書いていなかったのですが、出版社の方で書籍に合わせて書き直していただいたり、調整・配色・配置、していただきました。
推敲
一通り書いたこの段階は、ソフトウェアで言うとアルファ版ぐらいでしょうか。なんとか形がおぼろげに見えてくるところです。 自分で最初から読み直すのですが、読めた文章ではありません。。。
まず、一回目の見直しです。どんどん直していきますが、かなり書き換える必要があり、見直しでも1日1章ぐらいはかかります。とにかくどんどん直していきます。
図も見直していきます。図と本文を分けて作っているので、図の内容と本文をあわせるのが難しいです。
締め切り
そうこうしているうちに、4月後半になってきます。編集者から来月中には発売したいので、最悪でも5月半ばには印刷したいとのことです。 もう日がありませんが、逆に締め切りという目標ができると進めやすくなります。入れようかどうか考えていたところも、どんどん決めていきます。はじめに、おわりに、などもまとめていきます。
校正
出版社では、Markdownの原稿をきれいにレイアウトして書籍にしていきます。その間もこちらはGitHubで修正を加えていますので、変更点を見て反映していただきます。レイアウトしているものに変更を適用していくので、２度手間をかけてしまってはいます・・・
構成ツールとしては、Microsoft Wordの校正機能や、ATOKクラウド文章校正がかなりミスを見つけてくれるので使えました。
それぞれ、Markdownをコピー＆ペーストして確認します。Mac版Wordは校正機能はないようですので、VMware上のWindowsでMicrosoft Wordを動かしました。 「ATOKクラウド文章校正」は「Just Right」というATOKの校正ソフトのクラウド版です。Just Rightは４万円するのですが、476円/月(ATOK Passportプレミアム)で基本的な校正機能が使える優れものです。
校正では文章を読みあげるのもいいと書いている方もいたので、Macの読み上げ機能を使って文章を読み上げてもみました。
社内の人にも、時間がある範囲で目を通してもらいました。
最後の段階では、試しにランサーズでも校正してくれる方を2000円/時程度で募集してみました。今日の夕方までとお願いして、経験者を含めて3人の方に応募いただけましたので数時間お願いしてみました。
量が多く全部通しで読む間集中するのが難しいので、あの手この手を使ってみたというところです。
ネットの記事などでは後でいくらでも修正できますが、書籍では後から修正することはできませんので緊張感があります。
また、書籍の最初の方のページは何度も読みなおすのですが、最後の方のページは読む回数が減ってきます。均一に校正するという意味では、気持ち後半を重視した方が良いような気もしますが、最初の方のページは多くの人に読まれるので重視した方がいい気もします。
ゲラ
一通りレイアウトができると本の方になったPDFファイル(ゲラ)をDropBoxで送ってもらいます。味気なかったテキストがきれいにデザインされています。
きれいにデザインされたテキストを見ると、まだまだ間違いがあります。本の原稿での間違いですので、GitHubを修正していきます。
直前に、ほぼ同じタイトルが他の情報誌の特集タイトルとかぶることも発覚。。。タイトルを微調整します。
印刷
これで行く！となると印刷です。当日まで変更をしていたのですが締め切りギリギリだったと思います。
最終的にMarkdownファイル300KB程度(約15万字)になりました。
印刷に回すと原稿についてできることはもうありません。出版を待つばかりです。
出版
印刷に回してから１週間程度で見本誌をいただきました。 Amazonや書店に並びます！ 読者の役に立ちますように！
(
paizaの中の人による2016年のDocker本『Docker実戦活用ガイド』が本日発売！ - paiza開発日誌
より)
何のために書くか?
それでは、技術書を書く利点はどのようなものがあるでしょうか？
多くの人に情報を伝える
技術書を読むのは、その分野に興味がある人です。 技術書では、ある技術に興味のある人に、まとまった量の情報を文章として伝えることができます。 社内で使っている技術について書いている場合は、社内での情報共有のベースや参考資料にもなります。 さらに、社内だけでなく、世の中のエンジニアの技術力向上に貢献できる機会になります。
印税が入る
本が売れると、売れた数に応じて印税が入ります。 ただし、あの「リーダブルコード」でも3年かけて５万部で、1万部を超えるとヒットでこれは一握りのようです。正直、仕事として元を取ることは非常に難しいとは思います。 ただし、エンジニアは営業とは違い、会社などではエンドユーザの購入がダイレクトに収入に結びつくことは少ないと思います。売れた数に応じて目に見える形で印税が入るのは魅力的とも言えます。(個人契約の場合)
技術に詳しくなる
知っていることでも文章という形で明示することで、より理解が深まります。
業務では直接関係のない項目は飛ばしてしまいがちですが、書籍としてまとめることで全体的に把握して理解する機会にもなります。
書いていることは本当に正しいのか確認する機会にもなります。(マサカリが飛んでこないように...)
ポートフォリオになる
書籍のような形にまとめることで、その技術について知っているということを知らせることができます。
経験値
書籍のような長い文章をまとめるのは、短い文章とは違った難しさなどがあります。 まず、自分で全体を読むのも忍耐力がいりますし、構成・前後関係・用語などを全体として まとめることが必要になります。 100行のプログラムを10個書くのと、1000行のプログラムを書くことの違いと言えるかもしれません。 エンジニアの仕事一般にも応用できる知見が得られると思います。
エンジニア採用
社内エンジニアが技術書を出すというのは、ブログ・セミナー・Twitterなどの情報発信の一環とも言えます。どのような技術に取り組んでいる会社か伝えることもできますし、エンジニアの技術習得に力を入れていて、様々なことにチャレンジできる風土があるというメッセージを伝えることもでき、エンジニアの採用にもつながるかもしれません。
Connecting dots...
結局、利点はあるかもしないし、時間もかかるのは欠点にもなり、その間に他のことをしたほうがいいかもしれません。ありきたりですが、おもしろそうなら書いてみる、ということになると思います。
書籍とネット
書籍を書いている間にもバージョンアップや新しいツールなどもでてくるので、必要なものは取り込みアップデートしていきます。 とはいえ、速報性ではネットにはかなわず、リアルタイムでアップデートすることはできません。
一方、ネットの情報は断片的な情報が多く、全体を見通すことが難しいことがあります。 書籍のようにまとまった形で情報を得られることは非常に少ないです。 あることについてまとまった情報を提供することが書籍の大きな価値とは感じました。
書く側からしては割りに合わないといいましたが、逆に読む側からするとお得に情報が得られる手段と思います。
その他の技術書執筆記事
本記事以外で、技術書を描かれている方の記事は以下のようなものがありました。
Embedded Software Manufactory: 技術書の現在と未来
WordPressやSEOに関する書籍を書かれています。
Embedded Software Manufactory: 技術書の現在と未来
20年の経験を元に、組込みソフトウェアについての書籍を書かれています。
エンジニアが初めて書籍を執筆するにあたって | 外道父の匠
『たのしいインフラの歩き方』という本を書かれています。本記事と同じく、本職がエンジニアの方の初執筆についてです。
まとめ
以上、技術書を書くまでの流れを書いてみました。 実際に本を書くかどうかは別にしても、今取り組んでいることをまとめるとどのようになるか考えてみるのも面白いかと思います。ふとしたことで本にする機会もあるかもしれませんので考えてみてはいかがでしょうか。
今回書いた本についてです↓ paiza.hatenablog.com
Amazonはこちら↓
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
自分のスキルを磨いていきたいと考えている方におすすめなのが「paizaラーニング」。オンラインでプログラミングしながらスキルアップできる入門学習コンテンツです。初心者でも楽しくプログラミングの基本を学ぶことができます。
そして、paizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
