お客様から雑誌のバックナンバーについてお問い合わせを受けることがけっこうあります。
多くの場合、お客様はそれが何月何日号であったかということは覚えていません。覚えていると思いこんではっきりとおっしゃっていただいても、勘違いである 場合も非常に多いです。（これは雑誌の号数が実際の発売日より先行しているという業界の慣例が引き起こしやすい混乱で、ある意味、仕方がありません）。
さらにもちろん、特集のタイトルや小見出しは覚えておられません。
「ここ数ヶ月以内に××についての記事があったはずなんですが」という曖昧なケースが一番多いといってもいいでしょう。
版元さんに問い合わせの電話をします。
最初に尋ねられるのは「何月号ですか？」ということです。まあこれは尋ねる方としては当然です。
それが分からないとなると、事態は一気に混沌としてきます（笑）
書店員の側も内心は「まあ、無理かな」と思いつつもお客様がくれた数少ない情報を必死で伝えます。
親切な版元さんの場合、必死でバックナンバーの目次一覧を調べてくれたり、編集部へまで電話を回してくれたりもします。
でも判明する確率は低く、判明するとしても非常に長い時間がかかります。
雑誌のバックナンバーについてのお問い合わせは実に難しく、苦労の多いものです。書店としても、出版社としても。
全文検索
ここから先はあくまでも「提案」です。
こうでなければいけないとか、こうであれば完璧だというような話しではありません。
非常に単純な話です。
雑誌の内容の全文をどこか社内のサーバに蓄えておいて、必要な時全文検索をかけられるようにしておくだけで、上述したような場合にある程度対処できるはずです。
最近はほとんどの場合デジタルで入稿されているはずですから、記事が確定した段階で全文を単純なテキストファイルにしておくだけでよいのです。
お客様の問い合わせは「多彩」です。
記事そのもののテーマには一切関係なく「○○氏が出ていた」ということのみがそのお客様にとっはて最も重要だという場合も、しばしばあります。しかも（こ れは実際に経験したことですが）○○氏はその記事の著者でも、主たる対象者でさえなく「参照」として脚註内に出てきている人だったというような極端な場合 も、あります。
こうなるとテーマや小見出しで分類や整理がなされていてもどうせ役に立たないという場合も多くなります。
ですから、非効率的で低機能、「スマートではない」ように思えても、ただひたすら全文をなめ回していって特定の単語に引っかかるものを拾い出してくる方が、最終的には目的のものが見つかる可能性が高くなります。
とりあえず完璧なシステムなんか目指さない
「こんなテーマ」というような曖昧な問い合わせだった場合、記事に分類インデックスやキーワードのようなものをつけておいた方がいいのではないか、とか、 音引きひとつで検索にかかる/かからないという問題も出てくるから曖昧検索の設定を作り込んでおかなくてはいけないのではないか、というような話も出てく るでしょう。
でも、とりあえずいりません。
完璧でスマートなものを目指すと、ただ全文をテキストでサーバに放り込んでおくというわけにはいかなくなり、いわゆる「データベース」を作らなくてはならなくなります。
データベースを作ることに反対するわけではありません。もちろんです。しかし、それをメンテナンスしながら維持していくのは楽ではありません。
しかも不出来なデータベースは、場合によっては全文検索よりも的中率が悪くなります。ある言葉が確かに存在しているのに拾い出してこないということが起こりやすくなります。
不完全なかたちでもいいからまずそれが使えるようにしてしまうことを優先した方がいいです。
御社のデータを外部から直接検索できるようにする（つまりは、書店が勝手に調べられるように公開する）ところまでは求めません。それはそれで手間も投資も必要です。
とりあえずは、問い合わせの電話が入ったら自社内のデータを全文検索出来る、というだけでけっこうです。
書店側からの要望でもありますが、おそらく版元さんにとっても業務上大幅な時間の節約になるはずです。お互いに「頭をかきむしる」ハメになることがずいぶん減るでしょう。
書籍もせめて目次だけは
出来れば書籍についても検討していただきたいところです。
データの全体量が膨大なものになってくるという問題もあるかもしれませんが、タイトルも著者も分からないという問い合わせに対してかなり威力を発揮するでしょう。
せめて目次だけでもデータ化して検索出来るようにしていただきたい。
短編集などで「どの作家が書いたか。短編のタイトルは何か」までは分かっているのに、ある短編集にどの作品が収録されているかという情報が完全な形で公開されていない、というケースにいまだにぶつかります。
「xx、○○、他何篇。傑作短編集！」などと言われても、分からないのです。
完全な形でデジタルデータが存在しない過去の書籍についてはとりあえず仕方がありません。しかし「xx年以降のものは可能」というふうには出来ると思います。
Amazon.comでは書籍内本文の検索を積極的に進めています。Search Inside This Book: の機能を実際に自分で一度でも使ってみれば、その便利さが実感できます。
グローバルなサービスが信条の企業ですから、おそらく日本でも近いうちにサービスが始まるでしょう。
ここで私が提案したことと Amazon がやろうとしていることは若干意味合いが違いますが、読者は書名・著者・簡単な紹介文以外のものも情報として求めている（少なくとも、求めていると Amazon は信じた）ということは間違いありません。
そして、読者はまさにそういう方面から、しばしば書店にも問い合わせをしてくるわけです。
単純な全文検索であってもそのような問い合わせにある程度は応えられる（ある程度しか応えられない、のではなく、全文検索が出来ないよりも数倍も良い）のです。
追伸：技術に詳しい方へ
シンプル・イズ・ベスト
このようなことに少し詳しい方に申し上げておきます。
あなたがそのようなことに知識と実践的な技術を持っていたとしても、シンプル・イズ・ベストな場合が多いのだ、ということは決して忘れないようにして下さい。
MS の Access などで素敵なインターフェイス、高度な絞り込み等々を作り込んで賞賛されても、あなたが出張中にどこかが壊れたり、予期していなかった条件追加が必要になったりした場合、おそらく誰もそれをいじることが出来ないでしょう。
さらに言えば、あなたが退職したあとはもはやメンテナンスできないでしょう、おそらく。
Namazuなどのシンプルで堅牢なシステムを導入してしまえばメンテナンスにかかる手間はぐっと減るかもしれません。
けれどもあなたが退社したあとに Namazu が稼働していたマシンの再インストールなどが行われた場合、背後で Perl が動いていたということに誰も気付かないかもしれません。
Namazu を動かしていたのが Unix 系マシンなら、あなたが退職した時点でそもそも誰も手をつけられなくなるだろうからです 🙂
検索のシステムを（そのままパッケージとして外部に売れるくらい）徹底的に作り込んでしまうのでない限り、そのシステムは半永久的にあなたに依存します。
中途半端に凝らない方がみんな幸せになれます。
また、運用開始時点では検索条件は * や ? が使えるだけでじゅうぶんです。
正規表現が使えた方が便利かもしれませんが、おそらく社内の 99％の人はそもそも正規表現の検索式は書けません。
いや私自身にしても、正規表現の検索式を考えるより、とりあえず単純な and あるいは or で幾つかの単語を並べて検索してみることから始めると思います、残念ながら。
最低の環境でも「使えはする」ことの力
単純なテキストデータに対して、単純な全文検索をする、という方針を勧めるのは、万が一の時にも「使えはする」からです。
検索を実行する窓口は、Office ソフトなどで用意してもいいですし、カスタマイズしてよけいなメニューを全部非表示にしてしまった grep 専用ソフトなどを流用しても良いでしょう。
しかしそれらが使えない時でも、極端な話ですが、OSに備わった標準の検索機能でデータがあるフォルダ（あるいはファイルサーバのディレクトリ）を指定して検索してみることは可能です。使いにくくても、遅くても。
万が一の場合でも「使えはする」…「ショボさ互換」とでも言うんでしょうかね。
そういう仕様になっていることが、本当の対障害性能の高さだと思います。
※ご注意：一部の記事は書かれた時期が古いために現状と合わない場合があります
「この文書の趣旨」でもご紹介しているように当コーナーが本にまとまったのが2008年（実際に原稿をまとめたのは2007年暮）なので、多くの記事はそれ以前に書かれています。
そのため一部の内容は業界の常識や提供されているサービス・施設等、また日本の世間一般の現状と合わない可能性があることにご注意下さい。
