なぜ「シュミレーション」表記を含む技術書が世に出てしまうのか

あるいは、「シュミレーション」表記から考える技術書の効果的な校正。

「技術書の誤字脱字は気にするな。技術的な部分で間違っていなければいいじゃないか」ということを、IT 系技術書の著者が言っているの? よくある IT 系技術者の傲慢以外の何物でもないと思う。自分の分野がどれだけ特別だと誤解しているのか。他の分野を見下していることに気づいてほしい。
— suno (すの) (@suno88) 2015, 2月 18

最近こういうツイートが流れていて、丁度手元に1冊の本に対する150箇所の誤植メモがあったので書いてみます。なお、元ツイートには前後の文脈やら色々ありそうなので、以下でこのツイートに関する話はしません。

上のキャプチャは、2014年11月に出版された「ARM Cortex-A9×2! ZynqでワンチップLinux on FPGA」のp.210に記載されているVHDLコードの解説部分です。
技術書にあるまじき趣味レーション、もといシュミレーションという記述があります。

デバッグをデバック、ベッドをベット、東京ビッグサイトを東京ビックサイト、ビックカメラをビッグカメラとか、よく見かける間違いですね。口語で曖昧になりがちな濁音や拗音を文字にすると目立ちます。別の系統ではダイアモンドとダイヤモンドはどちらもアリ、鉄道ダイアとは言わない、カラトリーじゃなくてカトラリー、などなど、こういう微妙な表記は日常でもよく見かけます。

アボカドをアボガドと発音したり、文字で書く時もアボガドって書く人も結構いるわけです。大半の場合に会話は英語音をベースにしてるはずなので、"avocado"のどこに「ガ」の音があるんだ、となりますが、スペイン語では「アボガード」っぽい発音のようなので単に本格派なだけかもしれません。

それでも書籍へまとめる際は、一般的または出版社の規定にあわせて単語や文体を揃える作業がおこなわれ、きっと「アボガド」表記は絶滅して「アボカド」へ整えられます。

FPGA本の話に戻ります。

誤植一覧記事でも書いたように、本の構成と内容はとても良いです。もしもこの本無しでVivadoを使い始めていたら、入門部分で1ヶ月は軽くかかったでしょう。

この本のガイドによってそれを1週間へと短縮できました。非常に高い価値を感じます。

しかし、この本のいくつかの章はおそらく編集者さんの手元で校正を受けずに世へと出ています。

原稿の提出がギリギリだったとか、編集フェイズの中で校正内容が巻き戻ったとか、ひょっとすると章立てをだいぶ作業の後半で変えることになったとか、急遽章を付け足したとか、そういう事情があるのかもしれません。

それを推測するのも一興ですが、せっかく生原稿に近いものが5,832円で入手できたので、ここでは編集と制作と校正に関する話で骨までしゃぶり尽くすことにしましょう。

原稿執筆時に起こりがちなミス

校正を考えるためには、先に頻度の高いミスとその発生理由を知る必要があります。まずは「ARM Cortex-A9×2! ZynqでワンチップLinux on FPGA」の誤植一覧(150箇所)をざっと眺めてください。

私が見つけた150箇所の誤りは、大きく3つに分けられます。

日本語をテキストエディタで書いている際に混入しやすい誤り
英単語のつづりミスや語変形ミス
図版のキャプションミス

日本語をテキストエディタで書いている際に混入しやすい誤り

この本に限らず、単純なタイプミス以外と思しきものでよく見かけるのは

「これは」を「これはは」、「それを」を「それをを」、「には」を「にはには」とする
「ライブラリプロジェクト」を「ラブライブプロジェクト」とする

などでしょうか。

前者は、テキストエディタでのコピペやカット&ペーストの結果かな、と推測しています。とりわけ列挙文などで列挙順を切り貼りして差し替えた際にミスって重複文字が残る、ということが起こりがちです。
また、ミス部分がエディタ内で折り返し表示されて行末と行頭に分かれたりしたら、案外と見つけ出しにくいです。

後者は日本語IMEの進歩による予測変換の事故です。直近に変換したものが上位に出てくることも多く、文字数が一致している候補はぱっと見で区別がつきません。Tabキーで補完してしまったのを誰が責められようか。

そういうわけで、文脈と全く関係ないような文字列が唐突に入っていて驚くというケースもしばしばあります(驚きのあるものは逆に言えば見つけやすいのですが)。

指がすべることもよくあります。「Unify」と書くつもりで「Unity」と書くなんて日常茶飯事です。

英単語のつづりミスや語変形ミス

文字を落とす、余分に書く、lとrを間違える、-erと-orを間違えるなどさまざまです。特に技術用語の略語やツール名などでは敢えて普通とは綴りを変えているものもあるので、正確な記憶をしていないと大体間違います(Xilinx社のVirtexシリーズのような罠もあります)。

図版のキャプションミス

書籍は通常、著者と編集者だけでは完成しません。組版行程と図版作成をおこなう制作者さんが組版してくれて晴れて本になります(編集者さんがInDesignをゴリゴリ触って組版することもあります)。

著者がテキストエディタなどで書いた文章は、編集者さんの手元で編集を受け、制作指示が伝わるような独特の記号を付与されて制作者さんに流されます。
この時点で、原稿がWordで書かれていようがMarkdownだろうが、出版社ごとのルールにしたがった独自プレーンテキスト形式となることが多いようです。

図版についても著者が作成したものをそのまま利用することは稀で、制作者さんの手元で印刷上都合のよいフォーマットのものが起こし直される場合が多いです。

そうすると、制作指示の誤りや図版起こしでの勘違いによる誤りが結構頻繁に発生します。そして、この手の誤りは関わるワークフローが複雑なだけに訂正をしっかりと反映するのが難しいです。

書籍制作の現場はおそらく一般的なエンジニアが想像する以上にアナログです。

(著者)「図のキャプションに間違いを見つけました。直したやつをgit pushしておいたからInDesign側にマージしといてください」というようにはいかない場合がほとんどでしょう。

前述のように組版データを触る人が編集者さんか制作者さんかという点がまず大きなネックとなり得るのに加え、制作作業が進んでいる途中で訂正を差し込んでも仕上がりのファイルには反映されていなかったなど、編集行程が佳境に入りバタバタするとヒューマンエラーも増えがちです。

また、編集者さんが原稿の誤りをどの程度カバーしてくれるかは、人によります。進行の余裕度合いにもよります。
執筆エリアによっては「著者の記述を可能な限りそのまま紙面にする。変更を加える際には著者へ許可を取る」という運用がされることもありますし、別のエリアでは「著者は原案出しに近い。編集者の手元でほぼ書き直しに近いレベルで文章が再編される」ということもあります。

初めて仕事を一緒にする出版社・媒体で事前にこのさじ加減を掴むのは難しいでしょう。

なぜ『シュミレーション』表記を含む技術書が世に出てしまうのか

そういうわけで、FPGA本の著者が原稿に「シュミレーション」と記載した可能性は低いと思います。

9割方は編集または制作工程での混入でしょう。

しかしその状態で本が出版された原因を編集者さんや制作者さんの無知ゆえと結論づけておしまいにするのは非生産的です。

さて、ここで書籍制作において著者の持つ価値とは何でしょう。
私見ですが、著者は脳内の価値がある(他の人の脳内にはあまり無い)知見や解説を、想定読者を立てた上でその読者達へ伝わるように構成して文章や原図へとアウトプットすることが主要な仕事であり、主要な価値です。

場合によっては構成部分で編集者さんが相談に乗ってくれたり、そもそも構成案込みで執筆依頼がおこなわれることもありますが、基本的にこれです。

日本語力がイマイチだから記事を書かないとか、ミスタイプ多かったり英語の間違いが多かったりするから本を書かないとか、そんな遠慮は社会にとってマイナスです。間違いは誰かが気付いて直せばいいので、どんどん書いて欲しいと思います。

一方で、誤植訂正によって本の価値が本来よりも高まることはありませんが、確認不足によっては容易に価値が毀損されます。

原稿がさっさと仕上がって、余裕を持って制作フローへと流せて、余裕を持って初校が仕上がり、余裕を持って編集者および著者による確認がおこなわれ、また著者の連れてきたレビューアなどのチェックを受ける時間を十分に取れたならば、このような誤りを含んだ技術書が世に出ることはないはずです。

そんなわけで、表題に対する答えは次のようになります。ここでは私の独断で重要度順に並べました。

文章をレビューする人が居ない/少ない
進行(原稿、編集、制作)がギリギリ
進行フローが複雑

多くの目でしっかりと読めば見つけられるはずのミスが多く残った状態で出版されるというのは、人の問題というよりマネジメントの問題である可能性が高いです。
しかし現実には、著者は本業を抱える中で時間を作ってフラフラの状態で執筆していたり、編集者/制作者さんは複数の本/雑誌を掛け持ちしていたりと、作業がカツカツになることは避けがたくもあります。
人の目を増やす面では紙出版よりも電子書籍を先行させる(Effective Modern C++とか見て下さい) などの方法で改善できる箇所もありますが、それは別の機会に考えてみます。

要は、私にレビュー依頼して1日でも時間をもらえたらFPGA本はこう酷いことにはならなかった的なお話で、技術書のレビュー依頼は時間の許す限りお受けしますのでtwitterなどでコンタクトくださいまし。