はじめに
先日開催された「技術書典6」にサークル参加してきました。
技術書典自体には一般参加もしたことがなかったので、完全に初めての参加でした。
以下のような本を出させていただきました。
BOOTHにて、PDF版も販売しています。
https://booth.pm/ja/items/1317078
執筆環境を構築して、印刷所に入稿するまでまとめた記事も書きました。
https://qiita.com/uchiko/items/c99f6ad46ad3d226985f
本記事では、初めて技術書を執筆して、なんとか本を完成させた過程をまとめています。
「良い本を書くこと」よりも 「本を完成させること」 を優先しています。なんとか形にして、印刷所に入稿しました。
「こんなノリで本を作ってサークル参加していいんだ。自分はもっと上手くできるだろうし、やってみるか」 と感じていただければ幸いです。
※注意点として、「完成させるために間違ったことや適当なことを書いてしまっても良い」と推奨しているわけではありません。本に書く技術的なこと関しては、できる限り正確になるように気をつけることを推奨しています(その上で間違ってしまった場合は、訂正してお詫びしましょう)
入稿日を確認しておく
まずは入稿日がいつ頃になるのか確認しておきます。締切がいつになるか分からないと、執筆しているときにペースが分からなくなってしまいます。
入稿日はイベントの1週間前くらいで考えておくと良いです。
以下の記事でも入稿日について書いています。
印刷所を決めて、締切日を確認する
対象読者を考える
同人誌は、自分の書きたいように書くのが基本だと思います。誰にも役に立たなかったとしても自分が書きたいものを書く。そこが同人誌を作る魅力なのではないでしょうか。
しかし、まずは 対象読者 を考えます。これは どこから説明すれば良いか を決めるためです。ここが定まっていないと、すべて1から説明しないといけないのでは？と思ってしまい、途方に暮れてしまう場合があります。
つまり、対象読者を考えることは、何を説明しなくてもいいのかを決めることとも言えます。
一番楽な設定は 「これから書く内容を知らなかった頃の自分」 だと考えています。これであれば、どのくらい説明しなければならないか想像しやすいです。
今回の本の場合は、以下のような前提を記載しています。
- 普段からMacで開発している
- Gitを使っている
- 何かしらのウェブフレームワークでAPI開発経験がある
- プログラミング言語を1つ以上は慣れ親しんで使っている
- AWSの知識がある程度ある、または興味がある
- Go言語を使ったことがある、または興味がある
- RDBやNoSQLなどのデータベースを使ったことがある
- MVCを知っている
つまり「これらのことは1から説明しないですよ」と宣言していることになります。実際に本ではこれらのことについては細かく書いていないか、全く触れていません。その分、執筆するのは楽になります。
以下のような要望を持った人にとっては、役に立たない本になっています。
- スクラッチで1から構築方法を丁寧に解説して欲しい
- Go言語の解説をして欲しい
- AWSのサービスについて1から丁寧に解説して欲しい
「万人に満足してもらうこと」や「自分の立場とはかけ離れている人を想像すること」などは難しいことなので避けます。
本の内容を考える
ぼんやりと書きたい内容を箇条書きしていきます。一度書き出してみると、全体像がだいたい分かるようになってきます。今回の本では以下のような内容にしたいと考えていました。
- サンプルプログラムでまずは動作する状態にするところまでを解説する
- サンプルプログラムを改造する方法を解説する
- サンプルプログラムを詳細に解説する
- Dockerとdocker-composeの使い方を解説する
- 開発環境で使っているDockerコンテナの構成を解説する
- 漫画付きで解説する
- AWSの各種サービスLambda/DynamoDB/CloudWatch/S3の解説をする
- DynamoDBのデータ設計について解説する
結構なボリュームになりそうですね。おそらく200ページは超えるでしょうか。この時点で、自分がやろうとしていることに対して「結構大変じゃね？」と感じてきます。
最低限どこまで書くか決める(内容を削る)
結構たいへんかも。。。と思ったら、保険をかけておきます。つまり、「これぐらいだったら、まあ余裕でできそうかも」というところまでハードルを下げます。
「ここまで書いていれば大丈夫だろう」という最低限のボーダーを決めます。今回は以下のように削りました。
- サンプルプログラムでまずは動作する状態にするところまでを解説する
- サンプルプログラムを改造する方法を解説する
サンプルプログラムを詳細に解説するDockerとdocker-composeの使い方を解説する開発環境で使っているDockerコンテナの構成を解説する漫画付きで解説するAWSの各種サービスLambda/DynamoDB/CloudWatch/S3の解説をするDynamoDBのデータ設計について解説する
最終的に完成した本は80ページも行きませんでした。当初の予想通り 単純に時間もモチベーションも足りなかったからです。
目次を考える
載せる内容を考えたら、どのような流れで説明していくのか考えていきます。
この時点で Re:VIEWに実際に大項目と小項目を書いて目次を表示させると、本を作っている感が出てテンションが高まります。
 |
 |
|---|
とても本っぽい(ただし中身がない状態)。
書いていく
あとは本文を書いていきます。最初の章から書いていく必要はないです。一番書きたい内容をいきなり書いてしまって良いと思います。
また私の場合は、以下のようなことを意識していました。
- スクショや図などの画像は一気に作る。(表示箇所にはTODOとして後回して)
- 文章がおかしくても、とりあえずガンガン書いていって、後で直す
- 気分によって「サンプルプログラムを作る(プログラミング)」「本文を書く(エディタを立ち上げる)」「画像を作る(画像ソフトを立ち上げる)」のいずれかをやる
目次を作っているので進捗が見えやすくなっています。
また、締切を確認しているので、あとどれくらいのペースでやらなければならないか分かりやすくなっています。
とにかくコツコツとやる感覚で進めていきました。
表紙を考える
本の表紙のデザインをどうするか、結構悩みどころです。
私の場合は、以下のようなことを意識してやっていました。
- 書店で売られている技術書や他のサークルさんの本の表紙を見る
- 自分が好きだと思う表紙をピックアップし、なぜ好きだと思うか言語化してみる
とりあえず自分が好きだと思える要素を入れるようにしました。そのうえで以下のようなことに気をつけてデザインをしていきました。
- どういった単語に目を留めてほしいか考える
- 大きめの文字にしておく(「サーバレス」や「WebAPI」など)
- ひとまずどういう構成のシステムを構築するのか全体像が分かるようにする
- 構成図を入れておく
- どういった技術を使っているのか分かるようにする
- 単語を羅列しておく
推敲する
全体的に書き上がったら、最初から読んでみます。書いているときは順不同なので、つながりがおかしくなってしまっている場合もあります。また、より良い表現方法が思いつく場合もあります。そういったところをチョコチョコと直していきます。
校正してくれる同僚や友人がいたら、やってもらうと良さそうです。(筆者にはいませんでした。。。
)
入稿する
表紙と本文ができあがったら、印刷所に入稿しましょう。印刷所のオペレーターにデータのチェックをしてもらえるので、余裕を持って入稿すると安心です。分からないことはどんどんオペレーターに訊いてしまいましょう。
無事にオペレーターのチェックが通れば、本が完成します
その他注意点
執筆環境整備を頑張りすぎない
エンジニアなので、執筆環境でもCI/CDとかしたくなりますが、それをやっていると工数が膨れ上がってしまうのでやりませんでした。エディタで書いたら、手元でrake pdfして都度チェックしていました。
まとめ
とにかく本を完成させることを目標としたときの考え方について、まとめてみました。とにかく難しいことはやらないようにする、ということを意識しています。
ただし、今回は初めて執筆する場合ですので、慣れてきたら各々のクオリティにこだわっていきたいですね。
この記事をきっかけに、執筆してみようと思われる方が出てきたら幸いです。