電子書籍出版を経て、はじめて実感した本を書くことや作ることの苦悩
こんにちは。すうちです。
少し前にはじめて電子書籍の出版（Kindle）を経験しました。
はじめてだったのもあり、何とか１年がかりでやりとげましたが、振り返ると無駄に時間を使ったことや失敗もありました。
今回は、将来的に電子書籍出版（特に技術書）を考えている方に向けて、私の体験談を書きたいと思います。
ーーー
※タイトル画像：ia19200102さん
はじめに
前述の電子書籍は、以前noteに投稿したいくつかの記事が元になっています。
最初の記事は、2022年後半に投稿したPythonでGUIを作る過程の話です。今回の書籍化は「これをふくらませて本にできたらいいな…」と妄想したのがきっかけでした。
２番目は、本を書く過程で足らない所を書いてた時に（noteを書く時間が取れなかったので…）当時の下書きの一部をnoteに投稿したものです。
本に着手した１年前は「既にnoteの記事もあるわけだし上手くつなげれば３ヶ月くらいで書けるのでは？」と安易に考えていました。
しかし、当時は知らないこともあったとは言え、この考えがとんでもなく甘かったことを後々思い知ることになります。
以降、その内容と経験から得た気づきです。
なぜそんなに時間かかったのか？
本の構成の検討が十分でなかった
これは（自分としては）全く考えてなかったつもりはなく、目次や大まかに書きたいことは決まってました。
最初に導入、１章はプログラム環境の構築、２章でPythonの基礎を書いて、その後、本題に入っていく…みたいな実際の目次を想定して書き始めました。
ところが、実際やってみると。。。途中で頭がフリーズしてしまい、全然書けなくて進まないことに何度も遭遇しました。
目次や各章のキーワードは決めていましたが、その中で具体的に何をどのレベル（深さ）まで書くか？そして何を書かないか？本全体のストーリのつながりを事前に決めてなかったことが要因でした。
また、noteの投稿を本の構成に沿って並べると、もともとnoteは連載形式で書いてたとはいえ、単発記事で完結する書き方だったため重複する内容もあり。本を通して読むことを想定するとつながりがイマイチだったり説明が足らない所も多々あって、思ったより内容が薄いと感じました。
そのたびに、本の構成やストーリのつながり（各章の粒度も）を一度白紙に戻して考え直すことを３回以上やってたので時間がかかってました。
他に１年のうちトータル２か月くらいは忙しくて時間取れなかったり、書くのに行き詰まり実質何もやれなかった期間もあります。
電子書籍の作成環境を失敗した
こちらも事前にざっくり「WordやGoogleDocsを使えばいい」程度は調べて、最初はGoogleDocsを使っていました。
GoogleDocsは、Googleアカウントがあれば誰でも無料で使えて、他のデバイスと同期できる点は良かったです。
また、テキスト以外にキャプチャ画像も直接貼り付けできて便利でしたが、私の場合、これが後々ハマりました。
完成した電子書籍はEPUB形式で、アップロードする必要があります。
GoogleDocsで書いた文章はEPUB形式で保存できますが、これをKindle Previewer（完成品を閲覧できるビューワー）で確認すると、なぜかレイアウトが崩れたり意図した表示にならない所が多々ありました（通常の文章は問題ないと思います）。
ちなみに、そもそもKindle本は（noteと違って）ソースコードの表示は向かず、勝手にスペースや改行が入って読みずらいため、基本的にソースコードは画像で取り込んだ経緯があります。
昨年８月頃に７割程度は本を書きあげましたが、前述のレイアウト調整問題に直面したため、途中から思い切って作成環境を見直すことにしました。
調べた結果、Kindle Unlimitedに当時探してた内容にぴったりな本がありました。
著者の方もエンジニアでいくつか技術書を手掛けられているようです。
Kindle出版で技術書を考えている方には実用的な内容が多くおススメです。
この本の情報を参考に本の作成環境をマークダウン(md)とcss連携に切り替えてレイアウト問題は調整できるようになり、さらにEPUBの出力はPandocにして何とか落ち着きました。
ちなみに、GoogleDocs用に作った画像は元画像をファイルとして保存せず、直接貼り付けていたので、また最初から作り直すはめになりました…泣
最初に技術書はハードルが高かった
技術書の場合、本文の文章に加えて、目的のソースコードを書いてテストしたり、説明の図や表の画像を準備したりして、普通に書く作業と比べて３倍以上やることが多いです。
本のソースコードは、ゼロから全て書いたわけではなく、noteに投稿したベースがありましたが、本の構成や説明に合わせて半分以上は書き直したり、新しく作りました。そして、当然コードが変わるとその分追加のテストも発生します。
最終的に本の内容（全体のストーリと着地点）が決まるまでは、上記の作業を繰り返していたので、当初考えていたより時間もかかりました。
総じて私の場合は、事前の準備や構成の検討が足らなかったのが一番の要因ですが、最初に書きたいと思ったテーマが技術書だったので、相乗効果で時間がかかる方向に倒れたのだと感じています。
もし、今後Kindle出版を考えている方は、一番最初はできるだけ作業のハードルを下げる目的で技術書以外のテーマから選んだ方が良いと思います。
最後に
いわゆる出版という意味では、小説や漫画、一般書籍がイメージにあると思います。
Kindle出版は、個人で活動されている方や一般の本では扱いにくいニッチな内容もありますが、Amazonの戦略として、世間では一見ニーズが少ないジャンルも書籍で揃えることで、あらゆる人のニーズを満たすことを考えているそうです。
その意味では、私のような有名でない一般人も本を出せるという、ひと昔前では考えられなかった世の中になったと感じます。
また、今回まがりなりにも本を作るという過程を経験したことで、世の中の小説家や漫画家の方の苦悩もちょっとだけ実感できた部分もありました。
勝手な想像ですが、世の中の作家やクリエータの方々は裏では膨大な資料を集めて読んでいたり、目的に合わせた勉強もされていたり。創作の結果は、それらの氷山の一角が本やストーリにあらわれているのだと思います。
そう考えると、やはりそういう創作活動の仕事は、一般の人では味わえない喜びもある反面、相当なエネルギーがないと続けるのは難しいと改めて思いました。
今回は全体的に大変さに終始した話になりましたが、電子書籍出版を経験して得られたこともあるし、個人的にはやってみて良かったと思います。
これからKindle出版を考えている方に、少しでも参考になれば幸いです。
最後まで読んで頂き、ありがとうございました。
PythonでGUIを作りたい
仕様検討から実装まではじめての動画・静止画編集ソフト
Kindle Unlimited会員の方は無料で読めます。
この記事が気に入ったらサポートをしてみませんか？