2007年11月16日
技術書を執筆される方々にお願いしたい10の項目
(話半分なので、これで青筋立てられないようにお願いします……)
- 1. 締切はできるだけお守りください。
- 耳の痛い方も多いとは思いますが、出版側(およびその下請け)も著者の承諾を基に年度や期の計画を立てており、予備期間を含めた見込み以上にズレ込むと、いろいろなところに問題が出ます。執筆続行に支障が発生したら、できるだけ早くヘルプ要請やキャンセルを出してください。一番困るのが、途中まで編集・組版まで進めてしまったけれどもそこで中断という状況で、コストを回収できないまま宙ぶらりんになってしまいます。
- 2. 執筆したものを読み直してください。
- 一見してすぐ気付く誤字脱字があったり、内情を箇条書きにしたまま放置していたり、類似の内容をコピペしたままにしていたり、といった一度読み直してみるとわかるもののままの原稿に出会すことがあります。傾向としてはWordで執筆される方、あるいはWikiで執筆される方になぜか多く見られる気がします。これらのツールでは全体を読み直しにくくさせる何かがあるのでしょうか。脱稿宣言前にピアレビュー(ユーザー会であれば仲間のメンバーなどによる査読)を受けたほうがよいかもしれません。締切を守るのはありがたいのですが、速ければ内容確認はしなくてもよいというのは困ります。
- 3. 画像は原図を添付してください。
- Wordへの埋め込みやPDF出力があったとしても、画像は個別のファイル(わかりやすいファイル名で)として渡してください。Wordからの切り出しはコストと時間のロスになりますし、PDFは印刷精度に耐えるものにするのは難しいことが多いです。原図があれば、グレイスケール化や印刷精度を落とさないままの縮小などが組版側でできます。画像には、TIFF、bmp、png、jpeg(写真系。スクリーンキャプチャには不向き)あたりのフォーマットをご利用ください。画像の上に矢印などを引いた説明図を使いたい場合には、原図と、作成した説明図の両方をお渡しください。
- 4. アスキーアートよりも手書きのほうが望ましいです。
- 説明図を作成する際、アスキーアートは不向きです。編集や組版で簡単に解釈できるものであればなんとかしますが、それよりは手書きのものをスキャンあるいはFAXいただくほうが望ましいです。ドロー系ツールで作成いただくのももちろん良いですが、結局デザイナーによって起こし直すので、あまり凝ったものにする必要はありません。
- 5. 執筆スタイルを統一してください。
- ムックのようなものならまだばらつきが許されるのですが、単行本で文体、技術語句、章の中の構成が全然違うのは、統一感を作るのが編集の仕事の1つとはいえ、ちょっと困ります。特に共著の場合にはこういったことが起こりやすいので、執筆前に入念に意思確認したり、ピアレビューを行ったりしてください。
- 6. 画像や表には基本的にキャプションを付けてください。
- 通常の書籍では、画像や表には1行キャプションを付けます。本文からも「〜(図1.2)」のように参照するようにして、みなし子のものがないようにしてください。
- 7. ジョークや時事ネタ、アスキーキャラクタの使用には注意してください。
- 技術書でユーモア感を出そうとして入れたものが、後で読んでみたら浮いて痛々しくなってしまうことがあります。単行本の場合は雑誌よりも長い制作期間がかかり、また長く書店に置かれて読者の目に触れるので、時事ネタや当時流行だったアスキーキャラクタを入れるのは避けたほうがよいです(そういう本であればかまいませんが)。また、書籍はプロポーショナルな文字詰め(Windowsのプロポーショナルフォントとは概念的には似ていますが表現はだいぶ違いがあります)を行うので、アスキーキャラクタは意図しないものになりがちです。
- 8. 章のバランスを考慮してください。
- 通常、出版社に執筆を持ちかけたり、あるいはオファーされたりするときには、「目次案」を要求されることが多いはずです。出版社はこれを見てページ(と価格)を算出しますが、構成する際には章のページ見積りのバランスを考えるようにしてください。ある1章が3ページしかなくて、別の1章は150ページ、というのは明らかに問題です(表現技法として必要であれば良いと思いますが、単に書きやすいネタの大小によるものでは困ります)。章・節・項の使い分けにも注意してください。節から項に入る前には1つ以上の段落を入れるのが通常、望ましいです。
- 9. 丸写しは避けてください。
- APIの説明などは面倒なのでコピーしたくなる気持ちもわかるのですが、調べた内容は、解釈した上で自身の言葉で言い換えるようにお願いします。デッドコピーしたものは、ほかの文体と浮いていたり検索で調べるとそのまま出てきたりするので、すぐわかります。なお、コピーと引用は違います。引用の場合には出典を文中で示して、引用箇所もはっきりわかるようにレイアウトしてください。
- 10. 読み手の気持ちになって読んでみてください。
- 想定読者の気持ちになって原稿を見返してみてください。前提知識に対して説明が不足していたり、重複する内容が出てくるわりに肝心のことが抜けていたり、図表がぜんぜんなくて退屈に思えたり、ということに気付くことがあります。ピアレビューも有効ですし、初心者向けならあなたの家族が読んでもわかるかどうかを想像してみるとよいでしょう。
なお、個人的にはこのほかに、「Wordは、編集諸々すべて面倒なので、プレインテキストのほうが嬉しい」(Wordで日常編集している人もいるのでこれは個人の嗜好ですね)、「表はアスキーアートでがんばるよりはタブ区切りにしてくれたほうが嬉しい」(編集や組版時にはアスキーアートは邪魔になるだけなので…)、「相互参照はページではなく章や節に向けてほしい」(ページの確定は進行の終盤なのでミスが怖い。組版ソフトには実は相互参照を自動化するまともな機能がない)といったこともあります。
コメント
これ売れるかなぁ。。
一万部以上売れた(IT業界ではベストセラーらしいのですが)技術本(プログラミング関連)を書いた著者ですが、この10項目を守っている著者の本って売れるか?というのが直感です。。あ、10番だけは同意。
私はほとんど守られてなかったですね。その分、編集長は大変だったと思っていますが。まず著者に好きに自由に書かせて、任せて、後は編集の方がなんとかするのが、出版社の仕事ではないかなと。その方が良いものが出来る気がします。
Posted by とある技術者 at 2007/11/23 (Fri) 23:36:00
一万部売れたからと言って
それが読みやすい良著であるとは限らないことを肝に銘じてください。>上の人。
読者は、例え読みづらくても「それしか情報源」がなかったら、忍耐強く読解を強いられるのですから。少なくともここに書いてある10箇条で本が良くなるのであれば遵守してもらいたい。そもそも「売れる為の10箇条」ではないでしょ?
Posted by とある読者 at 2007/12/02 (Sun) 12:41:01
http://kmuto.jp/d/index.cgi/computer/those-who-write-computer-books.trackback
メッセージ: Ready to post a comment.
![[hatena]](http://d.hatena.ne.jp/images/b_entry_de.gif)
![[g15.jp]](http://g15.jp/powered-g15.png)
![[RSS]](/d/rss10.png)