なぜ技術書を書いたのか?

この記事は何?

過去に技術書を5冊書きました。
この記事ではなぜ技術書を書いたのか?、書いた結果、どのようなことがあったか?について書きます。

書いた技術書について

技術書典オンラインマーケットで5回技術書を頒布しました。オンラインマーケットの参加のみでオフラインイベントの参加は経験がありません。

書いた技術書はつぎのとおりです。

1. EVカートで始めるモデルベース開発
2. GCC開発環境構築入門(EVカート編)
3. CからRustにモータ制御ロジックを移植する
4. Spresenseデジタルカメラ開発
5. Spresenseでオリジナルゲームをつくる

なぜ技術書を書いたか?

なぜ技術書を書こうと思ったか振り返ってみました。

自分の知見を整理できると思ったから

本を書くことで自分の知識を整理できると思いました。
矛盾があることや不明な点は調べて本を書くので本のテーマについてより深く学ぶ機会となり、自分の成長につながります。

技術書執筆ツールRe:VIEWを使ってみたいと思ったから

技術書執筆ツールRe:VIEWを使ってみたいと思いました。

以前、Re:VIEWについて簡単にですがまとめて社内勉強会を実施しました。
よければ見てみてください。

技術書を技術書執筆ツール(ReVIEW)で書いてみよう
https://www.docswell.com/s/juraruming/5D4WVK-2022-07-25-172543

Re:VIEWを環境構築すればテキストベースで本を書けます。
テキストベースであれば、GitHubに書籍のリポジトリを作成し、変更管理していくことも可能です。
ソフトウェア開発のように本も執筆できることを知り、俄然、興味を持ちました。
執筆環境の構築、執筆、変更管理の一連の作業を経験したいと思いました。
私は1人で本を書きましたが、チームで書くのも良いですね。

書いた結果、何が良かったか?

本を書いた結果、良かったことです。

本をダウンロードしてくれた方のリアクションが嬉しかった

本をダウンロードしてくれた方がXで感想をポストしているのを確認すると嬉しかったです。
執筆作業は苦しい時間帯もありますが、ダウンロード、感想を見るとやってよかったと報われた気持ちになりました。

電子書籍の執筆ノウハウが身についた

Re:VIEWの使い方も身につきましたが、執筆作業のノウハウも身についた気がします。
本の全体構成をイメージし、章立てを考え、章の名前を考えることをしっかりすれば、後は執筆に集中できます。
これは技術記事を書くときにも使えるスキルと考えており、本の執筆作業でスキルアップできたと考えています。

書いた結果、何が改善点だと思ったか?

本を書いた結果、改善点も見えてきました。

表紙

本の中身に集中し、表紙作成に注力できませんでした。
5冊中4冊が真っ白な表紙で味気ないです。
本の中身が良くても目に留まり、ダウンロードしてもらえなければ読んでもらえないため、届けるための努力が必要だと考えています。
今はAIで表紙つくりの敷居も下がったと思うので次回、技術書を書くことがあれば表紙作成にも注力したいと思います。

告知

執筆が終わった後は本の告知をして、本の存在を知ってもらうことも必要だと思いました。
苦しんで生み出した技術書なので読んでもらいたい、という気持ちがあります。
表紙と同様、届ける努力が必要だと考えています。

Xで朝、昼、夜に告知はしていましたが例えば次のような告知をしている方もいるので真似したいと思いました。

• 自身のブログで本の紹介をする。ブログのエントリを何回かに分けて各章の説明を書き、購買欲を刺激するような告知に見えた。
• 仲間に本を渡し、自分ではなく第三者に感想を発信してもらう。商業の技術書でも良く見かける手法だと思った。

スケジューリング

仕事と執筆活動のバランスに苦労しました。極力、仕事に影響ないように動きましたが締切が近くなると夜遅くまで、出社時・昼休みに執筆することもありました。
余裕を持った計画を立てて執筆することが健康面でも重要だと思いました。