更新日2025年5月8日

技術書を執筆する流れや思い

ありがたいことに、技術書と呼ばれる分野の書籍をいくつか執筆する機会に恵まれました。書いた本も増え、知見がたまってきたので、流れや使用ツール、メリットやデメリットなどまとめてみます！

これまで執筆した本

主に初心者向けのWebデザイン、Webサイト制作に関する書籍を書いてきました。

執筆の流れ

主な流れはこんな感じです：

企画
調査
目次作成
執筆
表紙デザイン・タイトル
校正
予約開始
発売後

企画から出版まで、早ければ6ヶ月、長くて1年くらいかかるでしょうか。ジャンルによって執筆期間はばらつきそう。

それではそれぞれの段階でどんなことをしているか紹介していきます！

1. 企画

誰を対象にしたどんな本になるか？という企画ですね。ご自身で企画して出版社に持ち込む人もいるらしいのですが、私は編集者からの依頼があってスタートしました。

ZoomやGoogle Meetなどのオンライン通話で担当編集さんと打ち合わせます。私は初心者向けの入門書を書くことが多いのですが、初心者と言ってもレベルや前提知識、本に対する期待感なども異なるので、そういった細かいところまですり合わせていきます。

2. 調査

企画内容をもとに、競合や必要な内容を調べたりまとめたりしていきます。調査する対象は書籍のみならず、対象読者層に人気の動画やWebサイト、アプリなども参考にします。そこで人気コンテンツや、逆に不評なものもチェック。このあたりで読者の顔が徐々に明確になってきます。

3. 目次作成

調査内容を元に、目次を作成します。最初はざっくりと必要な内容のタイトルを並べていき、後から最適な章に振り分けたりもします。

目次作成や執筆で使うツールは、出版社から指定があればそれを使います。指定がなければ基本的にNotionを利用。編集さんとも共有します。詳しい使用方法は過去記事「Notionで複数ページの文書管理がはかどる！執筆、授業計画、レポートにもおすすめ！」にまとめているので読んでみてくださいね！

目次は後から変更もできますが、なるべくこの段階に出来上がった目次にそった内容にします。そうすることで編集さんとの認識のずれが減らせますし、何より自分自身の執筆の指針となります。

4. 執筆

ついに執筆開始！まずは書籍の最初のページにあたる「はじめに」をざっくりと書いておきます。この段階ではメモ程度に、対象読者層や、どんな気持ちで書いているか、読んだあとどうなって欲しいかなど。執筆途中でどう書けばいいか悩んだときに見返して、方向性が間違っていないか確認するのに便利です。

その後、1章から順に書いていきます。書きやすいところ、得意なところから書いていきたいところですが、順番に執筆していかないと、最初から順に読んでいる読者と話が噛み合わなくなったりするからです。

執筆する節ごとに「ORDIWの順」という順番にそって作業すると効率が良いとわかったので、最近ではそのようにチェックリストも設けています。

Outline（アウトライン）
Research（調査）
Demo（デモ）
Image（画像）
Write（本文執筆）

の、頭文字ですね。勝手に名付けましたが、我ながら覚えにくい…（素敵な命名緩募）。DemoとImageは書籍や章・節によってはあったりなかったりです。

Outline（アウトライン）

ブログの執筆でもそうですが、最初に見出しやざっくりとした内容を書いておくだけで、後から肉付けもしやすくなります。最近ではひとつの節を書き終えたら、次の節のアウトラインまで書いておいてから休憩なり作業終了なりしておくと、次に執筆作業に入るときにスタートしやすいなと感じております。「RDIWOの順」でしょうか。もっと覚えにくくなってしまいますね。

Research（調査）

Webと違って間違ったことを書くと修正が大変なので、最新の情報なのか、情報に間違いや偏りはないのか、日本と海外で捉え方は異なるのか…などなど、ブログ以上に念入りに調査します。執筆時と出版時で情報が異なるあるいは更新されそうな箇所はメモしておき、出版前に再度確認します。

Demo（デモ）

コードを紹介する系の書籍ではデモが必須。私の場合は文章より先にデモを用意し、そのコードを元に解説していくパターンが多いです。

デモのためのコードはわかりやすさが一番。装飾のための余計な指定はなるべく避け、今解説している部分にのみ注目できるよう構成を考えます。

作成したデモファイルはGitHubで管理。CodePenにて共有することもあるので、そちらも合わせて作っていきます。コードに修正が入ると、書籍・デモファイル・CodePenと、すべて修正になるので、どこかしらで修正漏れがあったりしてプギャーします。

Image（画像）

解説用の画像を用意したり、出版社側で用意してもらえるときは指示するためのラフ画を描きます。デザインメインの『1冊ですべて身につくWeb ＆グラフィックデザイン入門講座』という書籍では、デモがない代わりに大量の作例画像が必要でした。ものすごく楽しかったのですが、時間もかかるしとにかくコード書くよりはるかにしんどかった…！！いや、楽しかったんですがね！

作例画像でいうと、「良い例」と「悪い例」の絶妙なバランスが難しかったです。悪い例と言っても「いや今どき誰もこんな装飾しないだろ！」という例ではなく、絶妙にアンバランスな、かつ誰しもがやりがちな、あるあるラインを突く必要があります。「良い例」も、これが正解！という答えを与えるのではなく、今説明している箇所に限ってはこうした方がよく見えるよね、なぜなら…と文章につなげることも大切。んー難しい！

Write（本文執筆）

ここまで材料がそろっていれば、あとは比較的ラクに執筆できます。ただ、言い回しなどは何度も考えます。同じ内容を解説した書籍やWebサイトは多々ある中で、「私が直接説明するならどう言うかな？」を常に意識しています。

本文の執筆が終わったら、最初にメモ書きしていた「はじめに」を書き上げます。技術書で唯一著者の味が出せる場所だと思っているので、特に思いを込めた1ページになっているはず。中でも『ほんの一手間で劇的に変わるHTML ＆ CSSとWebデザイン実践講座』や『1冊ですべて身につくJavaScript入門講座』は、我ながら渾身の文章を届けられたと思っております…！

5. 表紙デザイン・タイトル

執筆中や執筆終わり頃になると、本の表紙のデザインやタイトル案が編集から送られてきます。デザインに関しては、だいたいのレイアウトや色合いが微妙に違うデザイン案を2〜4点くらい送ってくださるので確認して選んだりします。基本的には丸投げですが、それはどうでもいいのではなく、私よりも書籍販売に詳しい方に信頼して任せているというスタンスです。

6. 校正

ひとまず執筆が終わり、著者のできることが一旦終了します。ようやくのんびり。3日は仕事しないと決めています。

しばらくすると、原稿の内容を紙面にあてはめた状態のPDFが送られてきます。編集さんからのありがたきツッコミ付きです。ファイルはBoxやGoogle Driveで共有することが多いでしょうか。ひとつひとつ修正を入れたり、文章や図版を追加したり。意外と締切がタイトだったりもするので、もうひとふんばりです。

この確認・修正の作業を2、3回くらい繰り返し、ようやく完成！ふひー！

7. 予約開始

校正と同時期または終盤あたりから、書籍の予約が開始されます。とは言え、著者のすることはSNSやブログなどでの告知くらいです。タイミングよくイベントやセミナー登壇などあれば、本のPRも交えた内容を考えたり。

逆にイベント主催者さんで、登壇してくれる人を探しているときは、書籍の出版予定がある人にアプローチするとすんなりOKもらえたりする…かもです。

8. 発売後

無事出版ー！お疲れ様でしたー！発売後もできることは限られていますが、送られてきた見本誌を関係者や家族、知人友人に配ったり、書店に行って並べられている拙著を見てニヤつくくらいでしょうか。

そして、昨今の技術書あるあるかもしれませんが、読者からの質問が意外と多くきます。各種SNSからDMで送られてくると気づかずスルーしちゃっても申し訳ないので、私はDMは閉め、受付窓口は出版社Webサイトのひとつに絞っています。このへんの応対も事前に出版社と考えておくと良さそうです。

執筆のモチベーション的な何か

「モチベーションなんてなくても仕事はできる」と考えているタイプなので、時間になれば机に向かい、その日すべきことを淡々とこなしていくのみです。作業に取り掛かってから、徐々にやる気が出てきたりもしますよね。

ただ、仕事前の午前中に必ず運動することを習慣化しています。以前時間がなくて運動できない日が続いた時期があったのですが、その時期は集中力が下がって生産性が著しく低下。なので、それからは短時間で必ず運動するようにしています。運動しなければ仕事はできないとすら思っています。

あとは、Notionで執筆管理するときは「進捗」という欄を設けて「未着手」「執筆中」「完了」のラベルを選択できるようにしています。アウトラインだけでも手をつけたら「執筆中」にし、「完了」ラベルには自分の好きな青をセット。全体のラベルの色が少しずつ好きな色に変わっていく様子を見ていると、ちょっとずつ楽しくなってきますよ！

技術書を執筆するメリット・デメリット

メリットやデメリットについては、数ある著者さんがおっしゃっていることとだいたい同じなのでさっくりと。

自由にスケジュールが組める

言ってしまえば締切を守ればOKなので、あとは旅行にいこうが1日中寝ていようが問題なし！ただそのスケジュールを自分で組み、自分で守る必要があるので、そこが苦手な人には厳しいかも。

知見をまとめられる

これまで自分がインプットしてきた知見をがっつり盛り込めます。誰かに伝えたいこと、自分の中で整理したいことが形になるおもしろさ。また、説明が長くなりそうなときに「詳しくはこれ読んで」と自分の書いた本に丸投げができます。

自分自身の宣伝になる

著作リストを見せることは、自分がどんな知識や技術を持っているのかを紹介するのと同じです。「こんなことできます！」と言うよりも、「こんな本書きました！」の方が記憶に残りますよね。

誰かの自慢になる

本として形に残る、というのは、自分以上に自分の周りの人にとって喜ばしいことのようで。私の家族や友人はWebやデザインのことはよくわからないため、本の内容に興味をもってくれる人はあまりいないのですがw 彼らにとっては「Manaちゃんの書いた本！」ってことで記憶に残り、周囲の人に自慢しているようです。ありがたいことです。

技術書を愛おしく感じるようになる

他の人が書いた本にまで感情移入してしまいます。同じように苦労したんだろうなぁ、この説明難しかっただろうなぁ、少し前にアップデート入ったから差し替え大変だっただろうなぁ…などなど。そのせいか、これまで以上に技術書を読んだ時の理解度が上がったような気がします。

時間を取られる

逆に、デメリットは時間を取られる。これだけかも？執筆にはかなりの時間を有するので、その時間を他の仕事にまわせますし、本業が別にある人は本業が忙しくて手が回らないこともあるでしょう。価値観はそれぞれですが、上記メリットに見合う時間の支出なのか、事前に考えておく必要があります。

「自分が書く」意味を考える

最後に、最近では執筆そのものというより、「自分が書く」意味はあるんだろうか？と考えたりします。決してネガティブな負のスパイラルに陥っているとかそういうんじゃないんですが、AIでライティングができるなら、自分ならではの、自分が書くからこそ意味のある本とは何だろう？という思考ですね。

AIも、ネット上にも自分が持っているよりはるかに多彩で大量の知識があります。そこで自分にしか書けないのはやはり自分の経験かなと。多くの技術書を読む中で、読んでいて引き込まれる技術書は不思議と中の人の表情が見えてくるんですよね。楽しそうだなー！好きなんだなこういうの！というのが伝わります。そんな書籍を書いていけたらいいなーと、ほんのり考えていたりします。

書き終わったら「もう二度と書かない」と思うくらい大変なんですが、なぜかまた別の書籍を書いているんですよね。不思議ですね。マラソンを終えた後「もう二度と走らない」と思いつつ、また走ってしまうのと似たような感覚です。たとえがわかりづらすぎてすみませんw 今もまた別の書籍を書き始めたところです。今後とも応援よろしくお願いします！