技術書・専門書の書き方と出版方法
【個人でもできる】

「技術書を書いてみたい」と思ったことはありませんか。自分の得意分野の知識を体系的にまとめ、書籍として世に出すことは、エンジニアとしてのブランディングにもなり、副収入にもなります。しかし、ブログ記事と書籍は根本的に異なります。この記事では、技術書のテーマ選びから構成の作り方、コードの扱い方、出版プラットフォームの比較、そして校正・レビューの進め方まで、個人が技術書を出版するための実践的な手順を解説します。

技術書のテーマ選び

技術書を書くうえで最も重要なのがテーマ選びです。どれほど文章力があっても、需要のないテーマでは読まれません。逆に、テーマさえ正しければ、多少文章が荒削りでも売れます。

テーマ選びの3つの軸

良いテーマは、以下の3つの条件を満たします。

• 自分に専門性がある: 業務で1年以上使っている技術、OSS開発に貢献している分野など、実践的な知識があるテーマ
• 既存の書籍が不十分: Amazonで検索して「これだ」という本がない、あっても情報が古い、入門書ばかりで中級者向けがないなどのギャップがある
• 学習需要がある: プログラミングスクールのカリキュラムに含まれている、求人に頻出する、SNSでよく話題になるなど

避けるべきテーマ

一方で、避けた方がよいテーマもあります。

• 変化が激しすぎるもの: 特定のフレームワークのバージョン依存が強すぎると、半年で内容が古くなる
• 公式ドキュメントで十分なもの: APIリファレンスをなぞるだけの本は、無料の公式ドキュメントに勝てない
• ニッチすぎるもの: 市場が小さすぎると、努力に見合った読者数を確保できない

売れている技術書ジャンルの傾向

Kindleストアや技術書典で売れている個人出版の技術書を分析すると、以下のジャンルが安定した人気を持っています。

• Web開発（React、Next.js、TypeScript、Go、Rustなど）
• インフラ・DevOps（Docker、Kubernetes、Terraform、AWS）
• AI・機械学習（Python、LLM活用、プロンプトエンジニアリング）
• データベース設計・SQL
• セキュリティ
• キャリア・エンジニア組織論

技術書の構成パターン

技術書の構成は大きく分けて3つのパターンがあります。テーマに応じて最適なパターンを選びましょう。

パターン1: チュートリアル型

読者がゼロから一つのプロダクトを作り上げる過程を追うスタイルです。「ハンズオン」とも呼ばれます。

このパターンは入門者〜中級者向けに最も効果的です。読者が手を動かしながら読み進められるため、満足度が高くなります。注意点は、途中で環境差異によるエラーが発生しやすいこと。OS別の差異やバージョンの違いについて丁寧にフォローする必要があります。

パターン2: リファレンス型

特定の技術領域を網羅的にカバーするスタイルです。「逆引き辞典」や「○○大全」のような本がこれにあたります。

リファレンス型は「困ったときに開く本」として長く使われるため、ロングテールで売れる傾向があります。ただし、網羅性が求められるためページ数が多くなりがちです。

パターン3: 設計・思想型

特定の設計手法や開発思想について深く掘り下げるスタイルです。「Clean Architecture」や「リーダブルコード」のような本がこの系統です。

このパターンは中級者〜上級者がターゲットです。コードよりも「なぜそうするのか」という思考プロセスが重要で、著者の実務経験が直接的に価値になります。

コードブロックの取り扱い

技術書においてコードの見せ方は読者体験を大きく左右します。紙の本とは異なり、電子書籍では端末のサイズやフォント設定が読者によって異なるため、特有の工夫が必要です。

EPUBでのコード表示の基本

EPUB形式では、コードブロックは通常<pre><code>タグで記述します。リフローレイアウトの電子書籍では、長い行が折り返されて読みにくくなることがあります。対策として以下の点を意識しましょう。

• 1行は60文字以内に収める: スマートフォンでも折り返しなしで表示できる目安
• インデントはスペース2つに統一: タブや4スペースだと横幅を消費しすぎる
• 等幅フォントを指定: CSSでfont-family: monospaceを指定する
• 背景色をつける: コードブロックと本文の境界を視覚的に明確にする

コード量のバランス

技術書でありがちな失敗が「コードを載せすぎる」ことです。数百行のコードをそのまま掲載しても、読者は読み飛ばしてしまいます。以下のルールを目安にしてください。

• 1つのコードブロックは最大30行まで
• コードの前後に必ず説明文を入れる（「何をしているか」「なぜこう書くか」）
• 重要な部分だけを抜粋し、全体のコードはGitHubリポジトリで公開する
• 差分表示（変更前→変更後）を活用して、変更点を明確にする

サンプルコードのリポジトリ管理

本に掲載するコードは、GitHubなどのリポジトリで管理することを強く推奨します。読者がコードをコピーペーストしやすくなるだけでなく、誤植の修正やバージョンアップにも対応しやすくなります。リポジトリのURLは本の冒頭（「はじめに」の章）に明記し、各章のコードをディレクトリで分けておくと親切です。

出版プラットフォームの比較

個人が技術書を出版できるプラットフォームは複数あります。それぞれの特性を理解して、目的に合ったプラットフォームを選びましょう。

KDP（Kindle）で出版する場合

最も読者数が多いプラットフォームです。Amazonの検索経由で技術書を探す人は非常に多く、長期的に安定した売上が期待できます。70%ロイヤリティプランなら、980円の技術書で1冊約684円の印税です。KDPの始め方については別記事で詳しく解説しています。

デメリットは、EPUB形式への変換が必要なことと、コードブロックの表示が端末によって崩れる可能性があることです。ただし、EPUB生成はDraftZeroなどのツールを使えば自動化できます。

技術書典で頒布する場合

技術書典は年に数回開催される技術書の同人即売会です。オフラインイベントでは紙の本を直接手渡しで販売でき、完売すれば100%が収益になります。1冊1,000円の本を200部刷って完売すれば20万円です。コミュニティとの交流ができ、著者としての知名度向上にも効果的です。

デメリットは、印刷費がかかること（200部で3〜5万円程度）、イベント当日に現地参加が必要なこと、そして落選する可能性があることです。オンラインマーケットなら落選リスクなしで出店できます。

BOOTHで販売する場合

BOOTHはpixivが運営するクリエイター向けマーケットプレイスです。PDF形式で手軽に販売でき、手数料も低めです。技術同人誌のPDF販売に多く利用されています。決済手数料を含めても実質的な手数料は10%前後で、KDPの30%と比較すると有利です。ただし、Amazon ほどの集客力はないため、SNSやブログからの誘導が必要です。

複数プラットフォームでの同時販売

最も効果的なのは、複数のプラットフォームで同時に販売することです。ただし、KDPの「KDP Select」に登録するとAmazon独占販売が条件になるため注意が必要です。KDP Select未登録なら、KDP + BOOTH + 技術書典オンラインマーケットの3つで同時販売するのがおすすめです。

技術書の執筆環境

技術書を書く際の執筆環境も重要です。エンジニアならではのツールを活用しましょう。

原稿のフォーマット

技術書の原稿を書くフォーマットにはいくつかの選択肢があります。

• Markdown: 最もシンプル。GitHub上で管理しやすく、多くの変換ツールが対応している
• Re:VIEW: 技術書典で広く使われている組版システム。PDF・EPUBの両方を生成可能
• Asciidoc: Markdownより表現力が高く、O'Reillyの書籍でも採用されている
• LaTeX: 数式が多い本に最適。学術系の技術書向け
• Vivliostyle: CSS組版でPDFを生成。Webの技術で本を作りたい人向け

バージョン管理

原稿はGitで管理するのが鉄則です。章ごとにファイルを分け、意味のある単位でコミットします。共著の場合はプルリクエストベースでレビューを回せるため、品質管理がしやすくなります。また、過去のバージョンに戻せるため、「やっぱり前の構成のほうが良かった」という場面でも安心です。

校正・レビュー依頼

技術書において校正とレビューは出版前の最も重要な工程です。技術的な誤りがある本は信頼を失い、低評価レビューがつくとリカバリーが難しくなります。

技術レビューの進め方

技術レビューは、その技術に詳しい人に原稿を読んでもらい、技術的な正確性を確認してもらう工程です。

文章校正のポイント

技術的な正確性に加えて、文章そのものの品質も重要です。技術書にありがちな文章の問題点を挙げます。

• 用語の表記ゆれ: 「サーバ」と「サーバー」、「JavaScript」と「Javascript」など。一冊を通して統一する
• 主語と述語のねじれ: 技術的な説明が長くなると、文の構造が崩れやすい
• 受動態の多用: 「〜される」「〜が行われる」が続くと読みにくい。能動態に書き換える
• 説明なしの専門用語: ターゲット読者のレベルに合わせ、必要な用語は初出時に説明する

電子書籍の校正方法については、別の記事でさらに詳しく解説しています。

技術同人誌から商業出版への展開

個人で技術書を出版して実績を作ったあと、商業出版に展開する道もあります。実際に、技術書典で頒布した本が出版社の目に留まり、商業出版化されたケースは数多くあります。

商業出版化のステップ

1. 同人誌で実績を作る: まずは技術書典やKDPで出版し、販売数とレビュー評価の実績を積む
2. 出版社からの声がかかる: Amazonランキング上位や技術書典での完売は、出版社の編集者がチェックしている
3. 自分から企画を持ち込む: 技術系出版社（技術評論社、翔泳社、インプレス、オライリージャパンなど）に企画書を送ることも可能
4. 加筆・修正して商業版を刊行: 同人版を大幅にアップデートし、プロの編集者のサポートを受けて出版

商業出版の印税率は通常8〜12%で、KDPの70%と比べると低いですが、出版社の流通網とブランド力による販売数の増加が見込めます。また、「○○出版から本を出した」という実績は、エンジニアとしてのキャリアにもプラスになります。

技術書の執筆スケジュール

技術書は一般的なビジネス書と比べて執筆に時間がかかります。コードの動作確認やスクリーンショットの撮り直しなど、技術書特有の作業が多いためです。現実的なスケジュールの目安を示します。

合計で3〜6ヶ月が現実的なスケジュールです。本業と並行して執筆する場合は、毎日30分〜1時間でも書き続ける習慣が大切です。週末にまとめて書こうとすると、モチベーションの維持が難しくなります。

DraftZeroを技術書執筆に活用する

技術書の執筆でもDraftZeroを活用できます。たとえば、技術書の構成案（目次案）を素早く生成してたたき台にしたり、各章の導入文や概念の説明部分の下書きを作成したりできます。また、生成されたEPUBをベースに、自分の専門知識やコードを加えて仕上げるというハイブリッドなアプローチも効果的です。

特に「技術の概念を初心者にわかりやすく説明する文章」はAIが得意とする分野です。専門家は「当たり前」だと思っている知識を言語化するのが難しいことがありますが、AIに説明文の下書きを作らせてから自分の言葉で修正する方法なら、初心者にも伝わる丁寧な解説を効率的に書けます。