トップ «前の日記(2011年08月23日) 最新 次の日記(2011年08月25日)» 編集

KeN's GNU/Linux Diary
... 料理とDebianと雑多な記録


2011年08月24日

_ [life] IT書籍の索引について考える

矢吹さんのtweetから始まって、まとまりはないけど索引について思考実験。オチはないよ。

yabuki> …(snip)…あと、プログラミングの本で、巻末の索引が弱いのは辛いということもわかった。これも(重量が重い本が有利だが....

yabuki> Rubyの本でいうなら、「アクセサ」は入っていて欲しい。うろ覚えで、attr_accessor,reader,writerが索引から引けるように。あと、ちょっと古いけど、うさぎ表紙の達人Ruby本はかなりがんばっていたが、そこまでいかずとも

yabuki> メソッドの説明がポイントしてあって、あとは単なる説明と、コード例は分けてあるといい。ひどいのだとコード例にメソッドが使われているのかと思ってさがしても、文章のなかで違う文脈で書いてあってがっかりする。

yabuki> 総じて、機械的にあるから拾うじゃなくて、説明や活用している部分に索引はポイントしておいて欲しい。

これに対して(tweetもしたけれども)思ったことをまとめてみる。泣き言に見えるものもあるかもしれないけど、同情せよというわけではなくて生産的な方向に改善を目指したい。

悲しい現実

「IT書籍での索引が弱い」ということについては、自分も不満を持つ1人だ。ただ、制作協力という立場で実際に索引を作ることもよくある経験からすると、ほとんどの出版社、そして書き下ろしした著者にすら、「索引」は極めて軽い扱いを受けていると思う。

本来は内容を一番知っていて思い入れがある(はず)のは著者なのだが、原稿に索引を埋め込んだり、そうでなくても「索引を作らせてくれ」ということをされる著者というのはとても少ない。そもそも一度も見返さないで原稿でゴザーイと送りつけてくるようなのが…おっと、誰か来たようだ? ちなみに、索引をご自身で作るという著者はこれまでの経験上、「文章も良い著者」の確率が高い。自分が作ったもの、中身の完成度へのこだわりが強いという証左でもあるわけだし。

とはいえ、たいていの著者はそこまでは手が回らないし、終盤のギリギリの工程の中で索引を作るのはよほど慣れていないと難しい。

「終盤のギリギリの工程」と言ったが、ご存じのように、索引というのは索引語句とページ番号(ノンブル)との関係表であるのが普通だ。つまり、ページ番号が確定しないと、正しくそれを参照する索引を作れない。

しかし、ページ番号が確定するのは幸運が宿れば再校(2回目の紙出し)、下手をすると念校(印刷所に納品する前の最終確認紙出し)の時点だ。ほかにもいろいろな作業がある中の合間を縫って索引を作成するわけだが、再校辺りになると出版社側も具体的な刊行スケジュールをほぼ固めている。この中に「索引作成に十分な時間を費す」という項目は残念ながら入らないのが普通だ。かくして、索引を作成する時間猶予は1〜3日(3日は良いほうだ!)程度。

単語の拾い出しではなく、意味に由来した充実した索引を…という思いはあれども、ギリギリの中での索引抽出作業はシンドい。終盤工程ではほかにやらなくてはいけないことも沢山あるしね。実際のところ、意味ベースで作ったのと単語拾い出しで作ったのとでは報酬が変わるわけでもない。逆に、単語拾い出しだったらマッチかけて探せたものを、意味ベースで作ったばっかりにズレに気付かず、「はい、ペナルティ」ということだって最悪あり得る。

調整弁としての索引

そのように、思い入れが感じられないにもかかわらず索引がまだあるのは、「昔からあるから」という伝統と、8ページや16ページの倍数にしなければならないという台割にあるのではないかと思う。前者はともかくとして、後者について。

製本書籍の印刷では、大型印刷機で一度に印刷できる8ページまたは16ページといった数の倍数にページ数を制約することが基本だ。

ページ数が確定するのは終盤で、索引もひととおり拾い出したとしよう。索引対象範囲のページ(すなわち本文)を調整してしまっては索引を壊してしまうため、不可能だ。となると、倍数に収めるためのページ数調整は、必然的にそれ以外の圧縮や引き伸ばしの効くところ…つまり「目次」と「索引」となる。

目次はせいぜい1〜2ページ程度の変動が限度で無茶が効かないけれども、索引は項目の増減や、文字サイズ・行間などで調整がとてもやりやすい。結局こういうやり方だと、「意味ベースでどうこう」という索引が主になることはなく、「索引に割り当てられるのはnページ分だから、項目をこのくらい拾い出す」というページ逆算作業になる。

これが前付からの通しページ、つまり前書きとか目次とかにi、iiといった別数字ではなく、最初のページから込みで1から始めるとなると、目次でのページ数調整も封じられる(目次いじったら本文も変わって索引がうわあぁあぁ)ので、いよいよ索引が迫害対象だ。拾い過ぎても拾わな過ぎても駄目なので、通しページは苦労しがち。

なら電子書籍では?

電子書籍ならとりあえずページ制限はないけれども、そもそも採算取れるビジネスにどこまでなるの?(特にそれがうちみたいな下請けプロダクション業種だとどうなるの?)というのがまずあるわけだけど……。

電子書籍だと普通は単純一致な検索はできるだろうから、これまでのようなおざなり索引は無駄なだけとなる。とはいえ、意味ベースのを作るのは、たとえばePUBみたいなリフロー型だったらどこにアンカー置けばいいの?という疑問はある(繰り返すけど採算も問題)。

今思いついたけど、隠し索引みたいにして意味ベースの情報を埋め込めると面白いかもしれない。あとは大谷先生がtweetされていた「マイ索引機能」は、確かに電子書籍リーダーに実装してほしい。

索引の登録方法

ちなみにInDesignなどのDTPデータに索引を埋め込むことは理論上・機能上は可能ではあるのだけれども、実際にはそんなに簡単な話ではない。特に著者/編集と、DTPで分業している場合、索引の埋め込みはDTPオペレータの手作業になる。想像のとおりケアレスミスの温床で、範囲指定などの複雑な索引構成などは悪夢だ。索引周辺の修正のあおりで索引情報が消えてしまうことだってあるし、昔は索引を埋め込むと1字扱いになって行の文字詰めが壊れるというひどいこともあった(今のInDesignではこれはないはず)。

現在社内で広く使われている索引作成手法では、索引をDTPデータに埋め込むことはしていない。代わりに、索引語句とページ番号のペア、必要なら追加の読み、を並べたテキストファイルを自作のWebアプリケーションで処理して、DTPオペレータがそのまま索引テキストとして流し込めるものを生成するようにしている。WebアプリケーションはTeXで索引を作るmendexkと、漢字かな変換のkakasiを組み合わせたものだ。マーカーペンで紙に書き込んでDTPオペレータに渡して入力を待って……という無駄な作業がなくなり、効率的。ページが変わったときにも追従しやすい。PDFとの照合なども用意しているので、索引語句の間違いやズレなどを見落すことも少なくなった。

ReVIEW原稿の場合には、TeXのように最初から索引を埋め込んでそれを使うことができる。これはInDesignの索引ではなくてXMLで入れるようにしていて、後で専用の拾い出しスクリプトで抽出する。

で、索引はどうしたらいいのか

うーん、やっぱり索引は著者が作るべきなんでないかなぁと思う。「索引を作るまでが著者様の仕事です」ということで。ただ、ReVIEWやTeXのようにテキストからのイテレーションDTPではない、DTPデータがマスターデータになっちゃうような制作方法を取っている場合には、索引を作る時間が十分でないことが多い、というのが問題。

私自身はDebian徹底本を書いたときには5種類くらいの索引タグを使い分けて、DTPオペレータに無理を言って入れてもらった覚えがある。今だとReVIEWで書いて、もっとうまく処理できるんじゃないかなと妄想。

ということでやっぱりオチがありません。

追記

  • k16さん(オーム社編集部)の反応記事。著者・編集者必見。「時間がかかるという覚悟」は難しそうですねぇ……。大半のステークスホルダーにとっては予定どおり入稿できるかが最重要なので、再校出たらもう入稿でしょ?という風潮を変えるところから考えないといけない。