技術書の誤植伝説 - 1 文字の間違いが引き起こした事件簿

この記事は約 5 分で読めます。

たった 1 文字が命取りになる世界

一般書籍の誤植は、読者が文脈から正しい意味を推測できることがほとんどです。「東京タワー」が「東京タワ」になっていても、意味は通じます。しかし技術書の誤植は事情が違います。

コードの世界では、セミコロン 1 つの有無がプログラムの動作を左右します。console.log("hello") が console.log("hello" になっていたら、それはもう動かないコードです。読者がそのコードをそのまま写経すれば、エラーが出る。初心者であれば、自分のタイプミスなのか本の誤りなのか判断がつかず、何時間も悩むことになります。

技術書の誤植は、一般書籍の誤植とは深刻さのレベルが根本的に異なるのです。

伝説の誤植エピソードたち

技術書の歴史には、語り継がれる誤植エピソードがいくつもあります。

セミコロンの消失事件

ある C 言語の入門書で、for ループのサンプルコードからセミコロンが 1 つ抜け落ちていました。初版の読者たちは「自分の環境が悪いのか」と悩み、出版社には問い合わせが殺到。正誤表が出るまでの数週間、ネット上では「あの本の 127 ページのコードが動かない」という報告が飛び交いました。

変数名のタイポ

Python の入門書で、あるサンプルコードの変数名が途中から変わっていた事例があります。最初は user_name だったのに、数行後には username になっている。Python はこれを別の変数として扱うため、NameError が発生します。著者が執筆中にリファクタリングした痕跡が、そのまま残ってしまったのです。

インデントのずれ

Python のようにインデントが文法的な意味を持つ言語では、インデントのずれは致命的です。ある書籍では、組版の過程でコードブロックのインデントが 1 段ずれてしまい、if 文の中に入るべき処理が外に出てしまいました。コードの見た目は正しそうなのに、実行すると意図しない動作をする。これは読者にとって最も厄介なタイプの誤植です。

正誤表の裏側

技術書の正誤表は、著者と編集者の苦悩の結晶です。初版の発売後、読者からの指摘が集まり始めると、出版社は正誤表を Web 上で公開します。

驚くべきことに、初版の正誤表が 10 ページを超える本も珍しくありません。300 ページの本に対して 10 ページの正誤表。約 30 ページに 1 つの誤りがある計算です。正誤表には「致命的な誤り」と「軽微な誤り」の区別があり、コードが動かなくなる誤りは最優先で修正されます。

読者が誤植を見つけたら

技術書を読んでいて「これは誤植では?」と思ったら、出版社に連絡するのが最善です。多くの出版社は Web サイトに誤植報告用のフォームを用意しています。ページ番号、該当箇所の引用、正しいと思われる内容を添えると確認がスムーズです。

GitHub でサンプルコードを公開している書籍なら、Issue や Pull Request で報告できる場合もあります。誤植を報告すると増刷時に修正が反映され、正誤表にあなたの指摘が掲載されることも。地味ですが、技術コミュニティへの立派な貢献です。

紙と電子のジレンマ

電子書籍の最大の利点の 1 つは、誤植を修正できることです。著者や出版社が誤りに気づけば、データを更新するだけで全読者に修正版が届きます。

一方、紙の本は一度印刷してしまうと修正できません。増刷のタイミングで修正を入れることはできますが、初版を購入した読者の手元にある本はそのままです。正誤表を確認してもらうしかありません。

この非対称性は、技術書の出版形態に影響を与えています。近年、電子版を先行リリースし、読者のフィードバックを反映してから紙版を出す「アーリーアクセス」方式を採用する出版社が増えています。校正・校閲に関する書籍を読むと、出版物の品質管理の奥深さが分かります。

誤植を見つけられる人は優秀である

技術書の誤植を見つけられる読者は、実はかなり優秀です。

コードの誤植に気づくためには、そのコードが何をしているのかを理解している必要があります。変数名のタイポに気づくには、前後の文脈を把握していなければなりません。インデントのずれに気づくには、言語の文法を正確に知っている必要があります。

これはまさに、コードレビューで求められるスキルと同じです。他人のコードを読み、意図を理解し、誤りを指摘する。技術書の誤植を見つけられる人は、優れたコードレビュアーの素質を持っていると言えます。

もし技術書を読んでいて誤植をよく見つけるなら、それは読解力とコードリーディング能力が高い証拠です。自信を持ってください。

著者が校正で見落とす理由

著者自身が校正しても誤植を見落とすのは、脳の仕組みに原因があります。自分が書いた文章を読むとき、脳は「書いたつもりの内容」を記憶から補完してしまうのです。実際の文字列ではなく、意図した内容を「読んで」しまう。だからこそ、技術書の校正は著者以外の人間が行う必要があります。

技術書の校正プロセス

技術書の校正は、一般書籍よりも多くの段階を経ます。

1. 著者による自己チェック: 原稿を書き終えた後、著者自身が通読して明らかな誤りを修正します
2. 編集者によるチェック: 出版社の編集者が、文章の構成や表現を確認します
3. 技術レビュアーによるチェック: 技術的な正確性を専門家が検証します。コードを実際に実行して動作確認することもあります
4. 校正者によるチェック: 誤字脱字、表記の揺れ、句読点の使い方などを専門の校正者が確認します

この 4 段階のチェックを経てもなお、誤植はゼロになりません。

それでも誤植がゼロにならない理由

4 段階のチェックを経ても誤植が残る理由はいくつかあります。

まず、各段階で異なる観点に集中するため、別の観点の誤りを見落としやすい。技術レビュアーはコードの正確性に集中するあまり、文章中のタイポを見逃すことがあります。

次に、修正作業自体が新たな誤りを生むことがあります。レビュー指摘を反映する際に、修正箇所の周辺で別の誤りが発生する。これは「回帰バグ」と同じ構造です。

さらに、組版の過程でコードのインデントがずれたり、特殊文字が化けたりすることもあります。技術書の誤植をゼロにすることは、バグのないソフトウェアを作ることと同じくらい難しいのです。

関連記事

• 技術書の版と刷の違い - 改訂版・第 2 版の読み方
• 技術書が書店に並ぶまで - 企画・執筆・印税の裏側
• 技術書あるある - エンジニアなら共感する読書体験

まとめ

技術書の誤植は、一般書籍の誤植とは次元の異なる深刻さを持っています。セミコロン 1 つの欠落がプログラムを動かなくし、インデントのずれがロジックを破壊する。著者、編集者、技術レビュアー、校正者の 4 段階チェックを経てもゼロにはならないのが現実です。しかし、誤植を見つけられる読者は優れたコードリーディング能力の持ち主であり、その指摘は技術コミュニティへの貢献です。次に技術書で誤植を見つけたら、ぜひ出版社に報告してみてください。