デジタルの画面の狭さをどう克服するか

iPadの発表を見ていちばんびっくりしたのは、大きさ（ハードウェアスペック）が筆者の使っているNECのタブレットPC VersaPro VJ11F/GL-Rに酷似していることでした。

なんか、ほとんどおなじマシンに思えます。6年待ってこれかと思います。6年分の進歩はもちろん少なからずないわけではないです。動作時間とか。これでiPadが売れたりすると、Tablet PCの失敗の原因はなんなんだって話です。成功するとすれば、やっぱりサービスなんでしょう。

さて、前回までの本のデジタル化の話に戻しましょう。今回取り上げるのは、本をデジタル化するときにもっとも不満なことのひとつである、デジタルゆえの制約、特に画面の狭さによるオペレーションの困難さです。

前回紹介した1行を満足に表示できないようなブックブラウザは論外として、本が厚みをもちながらもぱらぱらと高速にめくれるのに対して、デジタル化した書籍にはそういうアナログ的な軽快さがありません。モノの紙とデジタル化した紙は、ぜんぜん別物なのです。

デジタル化した書籍の読み方とは、ページをめくって順繰りに読むか、検索して該当ページを表示するか、2種類しかない、と考えるほうがよいでしょう。ストーリーをもつ書籍であれば、順繰りに読むのでもよいのですが、検索して読む場合にどうしたらよいかを考えてみました。

プログラム関係の本のような実用書の場合、もっとも重要なのは、目次と索引であると考えられます。索引が充実しているのであれば、索引がもっとも重要です。

筆者は、約1年半ほど前からC#をゼロから勉強していて、C#とWPFの書籍を13冊手元に置いています。13冊にもなった理由は、ほんとうにゼロから、ある本に書いてあることと、別の本に記載されてあることを総合しながら理解する、みたいなかたちで勉強してきたためです。もちろんWebも併用しています。

さて、13冊という分量は、いざなにかを探そうとすると、すこし考えてしまう多さです。C#かWPFかでおおまかに9：4に分けられ、おおむねメインで使うのは2冊ときまっていますが、それにしても、なにかふと思って検索するときに、あちこちの索引を見て回るのはまどろっこしいのです。

紙で索引検索システム

そこで、勉強を始めたときからいちばん最初に作ったのは、C#に関する用語集というか横断検索のできる索引集でした。

疑問に思ったり必要になった言葉と、その解決ページ（あるいは直接の回答）を、基本的に1行1項目で、タブ区切りで並べたテキストファイルです。

まずなにか疑問を感じたら、ここに書き、13冊の本を横断的に探して、その該当ページを書き写しておくわけです。索引集によって、全体を統合した索引を作ることができるようになり、調べて探すことが格段に効率的になります。

本ごとにばらつきのある索引の表記「Process」と「プロセス」とかを、気にせずに検索できるメリットもあります。

書籍をOCRすればいいじゃないかと思われるかもしれませんが、図版入りの複雑な段組みの本をOCRしても、校正作業の手間のわりに、なかなか良い結果を得られないと筆者は考えます。先ほどの表記のばらつきなどは、OCRでは解決しない問題です。ある程度でいいじゃないかと、OCR派の方はおっしゃるのですが、いざ必要なことを探して検索するときにある程度でいいと美崎は考えないみたいです。

紙で索引検索システム

勉強もまずまず進み、だいたいほしいソフトは自分で記述できるようになってきました。こうなると、書棚の一等地を占める13冊はいかにも邪魔です。そこで、この13冊をデジタル化することを考えました。重要なことは、この13冊は、まだひんぱんに「引く」ことがあるということです。したがって、デジタル化したあとの利用頻度がほとんどない小説などに較べると、より活用しやすいかたちにしておく必要があります。

先のように、横断索引は作っていますが、それは必要に応じて作っただけです。行数は1000行ほどありますが、13冊の索引ぜんぶを網羅しているわけではありません。OCRはだめで、全項目手入力するのも気乗りしません。紙の索引には、必要に応じて項目を追記したりもしているので、それはそれでメリットもあると考えられます。

そこで考えたのが、索引部分だけを紙で残し、ファイル名をページ名と一致させることで、索引から容易にそのページを呼び出せるようにする『紙で索引検索システム』です。

紙のよさ（広げられ書き込みがたやすい）と、デジタルのよさ（場所を取らず検索性が高い）の両方を兼ね備えたハイブリッドシステムとして、より索引を充実させながらデジタルの紙を引けるようにしようと考えています。