技術同人誌の著者は、なぜKindle版を出すのか or 出さないのか
――「プログラマでありたい」視点で考える
Photo by Jovan Vasiljević on Pexels
技術書典やコミケで技術同人誌を出していると、ほぼ必ず聞かれるのが
「Kindle版（電子書籍版）は出さないんですか？」という質問です。
この記事では、実際に技術同人誌を出しているエンジニアたちの声や現場の事情をベースに、
「なぜKindle版を出す著者がいるのか」「あえて出さない著者は何を考えているのか」を、
プログラマ目線で整理していきます。
技術同人誌の「Kindle化」をめぐる3つの前提
まずは、判断の前提となるポイントを3つだけ押さえます。
1. 技術同人誌は「本」でもあり「プロジェクト」でもある
一般的な商業技術書と違い、技術同人誌は著者自身が
- 企画
- 執筆
- レイアウト
- 販売
までをほぼ1人（または小さなチーム）で回す、いわば個人プロジェクトです。
そのため、Kindle化は「出版社が自動でやってくれる追加販路」ではなく、
著者が自分の時間と技術リソースを投資して行う開発タスクになります。
2. Kindleは「フォーマットの制約」が思ったより厳しい
技術書、とくにコードや図表が多い本は、
- レイアウト固定型（固定レイアウト）
- リフロー型（文字サイズ変更に対応）
どちらにするかで制作工数が大きく変わります。
さらに、
- 行番号付きコード
- 2カラムの比較表
- 図とキャプションの関係
など、技術書ならではの要素が多く、Wordで小説を書くのとはまったく別物です。
3. 読者の「読み方」が紙と電子でかなり違う
技術同人誌の読者は、
- 机に広げて紙で読む
- タブレットでコードを見ながらPCで実装する
- スマホで通勤中にざっと流し読みする
など、シーンごとに読み方が違います。
Kindle版を出すかどうかは、想定読者がどのシーンで読むかによっても変わります。
Kindle版を出す著者が増えている理由
ここでは「Kindle版を積極的に出す」側の本音を整理します。
1. 紙の在庫リスクを減らせる
技術同人誌は、印刷部数を読み間違えると
- 在庫の山
- 自宅の押し入れが段ボール倉庫化
- フリマアプリで投げ売り
という事態になりがちです。
Kindle版であれば、
- 在庫ゼロ
- 再版コストゼロ
- イベント後も継続的に販売できる
というメリットがあり、在庫リスクをほぼ消せるのは大きな理由です。
具体的な活用シーン
- 技術書典で完売 → その場で「Kindle版もあります」と案内し、買い逃しを防ぐ
- 地方在住の読者に「イベントに来なくてもKindleで買えます」と案内
- 改訂版を出すとき、紙は少部数・Kindleはロングテール販売にする
2. 読者の「検索しながら読む」ニーズに合う
技術書は、最初から最後まで通読する人よりも、
- 必要な章だけ拾い読み
- エラーに遭遇した時に該当ページだけ探す
といったリファレンス的な使い方が多くなります。
Kindle版なら、
- 章タイトルやキーワードで全文検索
- 気になるページにハイライトを付ける
- ノート機能で自分のメモを残す
といった使い方ができるため、
「実務で何度も開く本」ほど電子版の価値が高まります。
具体例：プログラマの読み方
- エラーコードでKindle内検索 → 関連する節に一発ジャンプ
- API名で検索 → サンプルコードのページへすぐ飛べる
- プロジェクトごとにハイライト色を変えて読み返す
3. 世界中の読者に届けられる
紙の技術同人誌は、基本的に
- 日本国内向け
- イベント・BOOTH・メロンブックスなど、流通が限定的
になりがちです。
Kindle版なら、
- 海外在住の日本人エンジニア
- 日本語を読める海外開発者
にもワンクリックで届けられます。
とくに、インフラ・クラウド・機械学習など、国境を越えて需要がある分野は、
Kindle化の恩恵が大きくなります。
4. 著者の「実績」として見せやすい
プログラマとしてキャリアを積みたい人にとって、
- 「技術同人誌を出したことがある」
- 「Kindleで技術書を出版している」
というのは、立派なポートフォリオになります。
採用面談やフリーランス営業の場で、
- Amazonの著者ページ
- 書籍のレビュー欄
- ダウンロード数（ロイヤリティレポート）
を見せられるのは、GitHubとは違う説得力があります。
5. アップデートしやすく、バージョン管理もしやすい
技術内容はすぐに古くなります。
紙の版を重ねるのはコストも時間もかかりますが、Kindle版なら
- 軽微な誤植修正なら再入稿だけで完了
- 「v1.1」「v1.2」のように版を刻みやすい
- 巻末に「更新履歴」セクションを追加していく
といった運用がしやすくなります。
具体的な運用アイデア
- GitHubリポジトリで原稿を管理し、タグごとにKindle版を生成
- 書籍の最終章に「最新情報はGitHubのReleasesを参照」と案内
- Kindle版購入者限定で、リポジトリへのアクセス権を付ける
それでもKindle版を出さない著者がいる理由
一方で、「Kindleでは出さない」と決めている著者も少なくありません。
その理由は「面倒だから」だけではなく、戦略的な判断であることが多いです。
1. レイアウト再現が難しく、品質を保ちにくい
技術同人誌は、
- シンタックスハイライト付きコード
- 画面キャプチャの並列配置
- 矢印や図解を組み合わせた紙面
など、紙前提で作られていることが多いです。
これをそのままKindleに持ち込もうとすると、
- 文字サイズ変更でレイアウトが崩れる
- コードが途中で折り返されて読みにくい
- 図と説明文が別ページに飛んでしまう
といった問題が起きます。
「紙で読んでほしい前提で作ったから、電子で中途半端な品質にはしたくない」
という理由で、Kindle版を見送る著者は多いです。
2. 技術書典などイベントの「特別感」が薄れる
技術同人誌の魅力のひとつは、
- イベント会場でしか買えない
- 著者と話しながらサインをもらえる
- その場の熱量を持ち帰れる
というライブ感にあります。
もし最初からKindle版があると、
- 「あとでKindleで買えばいい」と会場で買われにくい
- 部数が読めず、印刷コストを回収しづらい
- イベントの「一期一会感」が弱まる
という懸念があります。
そのため、
- 初版はイベント・紙のみ
- 一定期間経ってからKindle解禁
という運用をしている著者もいます。
3. 技術的な制作コストが高い（特に初回）
Kindle向けの制作は、慣れていないと
- EPUBの構造理解
- 目次の設定
- 画像解像度・容量の調整
- 端末ごとの見え方チェック
など、小さな作業の積み重ねになります。
プログラマだからといって、必ずしも電子書籍制作に詳しいわけではありません。
「本業の開発に時間を使いたいから、Kindle化はやらない」という判断も現実的です。
4. 価格設定とロイヤリティのバランスに悩む
Kindleのロイヤリティは、条件付きで70%を選べますが、
- 価格帯の制約
- 配信コスト（ファイルサイズによる）
- セール時の値引き
などを考えると、紙とのバランスが難しくなります。
たとえば、
- 紙：イベントで2000円
- Kindle：1500円
とした場合、
- 「電子の方が安いから紙が売れない」
- 「紙と同じ価格だと電子が割高に感じられる」
といったジレンマが生まれます。
5. 「プログラマでありたい」からこそのこだわり
この記事のテーマにもある「プログラマでありたい」という気持ちを持つ著者ほど、
- 自分でフォーマットをコントロールしたい
- プラットフォームに依存しすぎたくない
- 将来のフォーマット変更に備えたい
と考えがちです。
その結果、
- PDF＋自家通販（BOOTHなど）
- 技術書典オンラインでの専用ビューア販売
- 自作ビューアやWeb連載＋サポーター制
など、Kindle以外の方法を選ぶケースも増えています。
結論：3つの軸で決める
実際に技術同人誌を出しているエンジニアたちに話を聞くと、
Kindle版を出すかどうかの判断は、ほぼ例外なく次の3軸で決まっていました。
その本を「何年読まれたいか」
- 1〜2年で陳腐化する内容：イベント＋PDFで十分と考える著者が多い
- 3年以上読まれたい基礎・概念系：Kindleでロングテール販売したいという声が多い
読者に「どう読んでほしいか」
- 手を動かしながら腰を据えて読んでほしい：紙を優先
- リファレンスとして何度も検索してほしい：Kindle優先
著者自身が「どこまでプロダクトとして作り込みたいか」
- 本そのものをプロダクトと見て、レイアウトやUIまで作り込みたい人は紙・PDF派
- 内容（テキスト）をサービスとして届けたい人はKindle派
つまり、
「Kindle版を出す／出さない」は、技術的な都合よりも「本の寿命」と「読まれ方」に対する設計の違いです。
プログラマとしての視点で言えば、
- 紙＋PDF：スタンドアロンアプリ
- Kindle版：クラウドサービス
くらいの違いがあり、
どちらが正しいというより「どんなユーザー体験を設計したいか」の問題だといえます。
技術同人誌をKindle化するときの具体的ステップ
ここからは、「これから技術同人誌を書いてKindle版も出してみたい」人向けに、
できるだけシンプルな手順を5つにまとめます。
ステップ1：原稿は最初から「テキスト＋マークアップ」で書く
- GoogleドキュメントやWordだけで完結させない
- MarkdownやRe:VIEWなど、テキストベースで管理する
- Gitでバージョン管理しておく
こうしておくと、
- 紙（PDF）
- Kindle（EPUB）
- Web連載
など、**複数フォーマットへの展開がしやすくなります。
ステップ2：最初は「固定レイアウト」を避ける
技術書でありがちなのが、最初から
- 紙面をそのまま画像としてKindleに載せる
- PDFをそのままKindleに変換する
というやり方です。
これは手っ取り早い反面、
- スマホで読みにくい
- 検索できない
- アクセシビリティが低い
というデメリットがあります。
初心者ほど、シンプルなリフロー型＋最小限の図表から始めた方が、
読者体験も制作コストもバランスが良くなります。
ステップ3：コードブロックは「幅」を意識して書く
Kindleでコードを読みやすくするための具体的な工夫として：
- 1行の文字数を短めに（80桁以内を目安）
- 無駄なインデントを減らし、ネストを浅く保つ
- 長い行は意図的に改行し、コメントも分割する
これだけでも、スマホでの可読性が大きく変わります。
ステップ4：図は「テキストで補完できるか」を考える
図やスクリーンショットは便利ですが、Kindleでは
- 端末によっては小さくて読めない
- 拡大すると前後の文脈が見えない
といった問題が出ます。
そこで、
- 図の要点を本文で必ず説明する
- コマンドや設定値は図に埋め込まず、本文に書く
- 図の代わりにテキストベースの図（ASCIIアートなど）を使う
といった工夫をすると、
図が多少見づらくても内容が伝わる構成になります。
ステップ5：最初の1冊は「薄く・小さく」出す
いきなり300ページの大作をKindle化しようとすると、
制作も検証も大変です。
- 40〜80ページ程度の小さなテーマ
- 1つの技術にフォーカスしたミニ本
- 「イベント頒布＋Kindle版同時リリース」でテスト
といった形で、小さく始めてからノウハウを貯めるのがおすすめです。
Kindle以外の選択肢：Kobo・PDF・Web連載という分散戦略
Kindleが強力なプラットフォームであることは間違いありませんが、
すべてをKindleに寄せる必要もありません。
Koboや他ストアを併用するケース
- 楽天経済圏で生活している読者にはKoboが使いやすい
- 楽天ポイントで技術書を買う層も一定数いる
という事情から、
- Kindle版＋Kobo版を同時展開
- セールやクーポンのタイミングをずらして販売
といった戦略を取る著者もいます。
PDF＋自家通販のメリット
- BOOTHなどでPDFを直接販売
- 購入者にアップデート版をメール配信
- DRMなしで、複数端末で自由に読める
といった形は、エンジニア読者との相性が良いパターンです。
Web連載＋サポーター制という新しい形
最近は、
- noteやZennで連載しつつ、まとめて電子書籍化
- GitHub SponsorsやPatreonで支援を受ける
- 有料部分だけを電子書籍として販売
といった、コンテンツと収益の分離も進んでいます。
フォーマット別の比較
ここでは、「技術同人誌をどのフォーマットで出すか」を、
スペック比較の形で整理します。
| 項目 | 紙（同人誌印刷） | Kindle版（KDP） | Kobo版など他ストア | PDF＋自家通販 |
|---|---|---|---|---|
| 在庫リスク | 高い（刷りすぎに注意） | ほぼゼロ | ほぼゼロ | ゼロ |
| 初期コスト | 印刷費が必要 | 時間コスト（制作・検証） | 時間コスト＋審査 | 低い（入稿はPDFのみ） |
| 検索性 | 目次のみ | 高い（全文検索・ハイライト） | 高い | 中〜高（リーダー依存） |
| 読みやすさ（スマホ） | 低い | 中〜高（レイアウト次第） | 中〜高 | 中（拡大縮小前提） |
| 読みやすさ（タブレット） | 高い | 高い | 高い | 高い |
| 世界中からのアクセス | 低い | 非常に高い | 高い（対応国による） | 低〜中（決済手段次第） |
| アップデートのしやすさ | 低い（増刷・改訂が必要） | 高い（再入稿で対応） | 中（ストアごとに対応） | 中（再配布の仕組みが必要） |
| 著者の実績アピール | イベント実績として有効 | Amazon著者ページとして強力 | 追加実績として補完的 | ポートフォリオとしては弱め |
| イベントとの相性 | 非常に高い | 補完的な位置づけ | ほぼ関係なし | 高い（DLカードなどと相性良い） |
| 技術的ハードル | レイアウト〜入稿作業が必要 | EPUB制作・検証の知識が必要 | Kindleとほぼ同等 | 比較的低い |
| プラットフォーム依存度 | 印刷所のみ | 高い（Amazon依存） | 中（複数ストアに分散可能） | 低い（自前で完結） |
まとめ：次に取れる行動
技術同人誌のKindle版は、在庫リスクを減らし、世界中の読者に届ける強力な手段ですが、
レイアウトや制作コスト、イベントとのバランスを含めた「設計」の問題でもあります。
「プログラマでありたい」著者ほど、自分の本をどんなプロダクトとして届けたいかを考え、
紙・Kindle・PDF・Web連載を組み合わせて、自分なりの最適解を探していくとよいでしょう。
これから取り組む場合は、
- 原稿をテキスト＋マークアップで書く
- 小さめのテーマで1冊出してみる
- 読者の読み方を観察しながら、次のフォーマットを決める
といったステップで進めてみてください。
技術書・電子書籍の読み方や選び方をもっと深く知りたい方は、
もあわせてご覧ください。