ここのところ本業の編集が忙しくて、電子書籍関係の仕事を頓挫していたのだが、それでも、ある会社と共同開発した語学用のフォーマットも完成し、じっさいのコンテンツをのせる作業を開始している。そのうちに紹介もするつもりだが、これは、もうじき発売される新刊と連動し、書籍、CDブック、オーディオブック、ブログ、Podcast、電子書籍というマルチな展開の商品になる。内容はそれぞれに同じようなものだが、それぞれのメディアに展開をさせている。

http://mimikara-french.seesaa.net/?1298738928

http://itunes.apple.com/jp/podcast/id418126897

これはそもそも語学書というのが、つねに音を商品にしているにも関わらず商品としての音を売ることに困難があったことがそもそもきっかけだった。詳しい話はいずれすることにして、この本が画期的なのは、そもそもiPhoneの画面でみても十分に堪えうるサイズで版面を構成していることである。まさに本が、電子書籍という別の枠のために作られたという例にあたる。ぜひできたら見て欲しい。書店発売は3月1日頃だと思う。

そのほか、新刊と同時に電子書籍化するものが別にあるが、それもいずれ紹介することにする。

今回、書くことは、電子書籍ということから離れて、もっとじつは版元が手をつけなければならないことがあるという話。

先日、ある機会にJPO、日本出版インフラセンターのE氏にお会いする機会があって、最近始まっている近刊情報センターのことについて話をした。

じつは、うちの版元も、新文化の記事が載ったのをきっかけに登録をした(前から話していたのに乗ってくれなかったのに…)。これにより近刊情報センターが情報を提供しているネット書店やリアル書店に近刊情報が自動で配信されることになる。ここまで話を聞いて、あれ?って思う人がいるかもしれない。出版業界の人間なら驚かないのだが、一般の人にしてみれば「近刊情報って共有されてないの?」というところだろう。

そう、されていない。書店への書籍の情報は、通常、取次が作成する「流通情報」でしかない。そのほかはチラシとか版元のサイトとかで近刊の情報を知るほかない。当然ながらチラシで知る場合には、本当にいつでるのかわからない。だから、ときには版元に電話をかけて問い合わせていたりする。

どういうことなのか。まず情報を共有するインフラがない。書店が得る情報は、流通情報として取次から与えられているので、当然、近刊の情報でなく、リアル本の情報である。なぜ近刊の情報ではダメかというと、本というのは完成してみないと正確な情報が作れない、とされてきたからだ。タイトルやサイズが変わることもよくあることで、作る側も、それでよいと思っていた節はある。値段だって予価は大いに変わる。ようするに計画性がないということにつきる。

ましてや大手から小出版社までを含んだ版元の情報を作るわけだからアバウトな部分がどうしても必要となってくる。統一的にどうこうすることはできない。こうしたことを解決しようとこれまでいろいろな人たちが頭を悩ませて来たのだが、いかんせん出版人はアナログだ、結局のところ今日まで、ほとんど改善されることなく連綿と続いてきた。

しかしそれが変わる。近刊情報センターの稼働によって、こうしたことは大きく変わるはずである。これにはE氏の貢献は大きい。

私は、この1年近くをかけて書誌情報まわりの整備を行ってきた。まず、社内で書誌情報の重要度を理解してもらい、アルバイトを入れ、書影のスキャンにはじまり、項目の整理などをやってきた。一方で、システム開発も急いだ。

そもそもは、ある書誌データベースと社内のデータベースを連結していくことが最終目的にあった。これはもう3年近く前からある構想で、その書誌データベースが、つぎのホームページになるというわけである。これが、昨年の12月に接続に成功、外部データベースがシームレスで繋がった。そして、いよいよ来週の月曜日に、完全な形のデータベースとしての運用がはじまる。

完全な形とは、このデータベースでは近刊情報に関しては、編集者が作業のステータスを設定することにより(初校とか印刷とか)、もし発行年月日が近づいてきたときに自動的に年月日をずらす仕組み、そして在庫ステータスの変更、画像の登録をすべて自動で行うことのできるということである。

朝、最初に立ち上がったときに、在庫ステータスを検証して情報の書き換えを行い、新刊の登録、情報修正の処理、本社在庫をチェックして倉庫の出荷を指示、発売のチェック、ログの書き出しを行う。おそらく5分近くはかかるのではないかと思っているが、これによって商品のデータを完全にリアルタイムに変更して行ける。

この段階を待っていた。この段階を待って、近刊情報センターに登録をした。つまりは、版元がどれだけ商品の情報を正確に出して行けるのかということなのだ。それが出来ない以上、やはり近刊情報は出せない。

近刊情報センターはアマゾンへもデータの提供をはじめる。そうなったときのためにこれまで開発を進めてきたといっても過言ではない。

さて話がそれたようだが、E氏と話していたのはこの話と大いに関係がある。
E氏のもとに、P社の方が訪れて、近刊情報センターを利用したいという旨を伝えたという。どうすればよいかという話にでは御社のデータベースはどうなんですか?という話をされてたじたじになったという。じつはこの会社かなり大きな会社であるのだが、商品情報の一本化ができていないようなのだ。

つまり商品の情報は営業が作り、制作の情報は制作が作る、編集は編集で情報を作り、そうしたものがすべてバラバラにデータベースを持っているということなのである。じつは近刊情報、というよりも、いま書誌情報と呼ばれる物は、これまで取次が作ってきた値段やサイズといった流通情報だけではなく、目次などを含む書誌情報が必要となっている。しかしこれを実現するには、データベースの統合が不可欠である。それだけではない、それぞれのネット書店は、それぞれの形式でデータをほしがる。それに対応するためには、いか通りにでもデータを書き出せる仕組みが必要となる。

現状では、編集者がそれぞれのサイトにアクセスして入力するなどの手間をかけている。こうした手間は、とくにさまざまなサイトが乱立するなかでは、どこか限界を感じてしまう。いまはネット書店間の情報共有はかなり図られているのだが、それでも自社のサイトとネット書店とで二つに登録するのだって簡単なことではない。

こうした状況は、大手だからというのではなく、小さな出版社ほど深刻な悩みになっている。人手がない分、社内の人間の作業になるわけだから負担も大きい。でもここを乗り越えなくては近刊情報センターは利用できない。

もう一つ。近年のネット社会の急速な進化と発展のなかで、ネット上に正確な情報がないものは、信用さえされない状況になっている。ただでさえ書店で売るということ、つまりは書店というメディアでうることは、ほとんどマイナーなメディアで売ることに等しくなってきているなかで、ネットの周知力をあなどってはいけない。しかもネットというメディアは、きわめて細分化されたセクトを多く持ち、そこへの情報提供は、かなりの手間と困難がともなってくる。

これまでは新聞という大きなメディアがあったことで、新聞に広告を打てば周知できていたのだが、いまの現状では、新聞は大きなメディアなどではない。

そういう時代にあるからこそネット対策、商品情報の大切さが必要になっているのである。しかし、出版社の多くはそうしたことに対応できていない…。

P社の方は、帰りがけに、「電子書籍どころではないですね、社内のデータベース一本化をしなくては」と言ったそうである。

この言葉は重い。

じつはそんなに簡単なことではない。地味な作業であると同時に、根気が必要な作業だ。データベースはできあがってもありがたがられないが、中途半端なものを作れば使われなくなる。インフラの整備と同じで、じつに目に見えないものでもある。

と同時に、根気とは、会社をきちんと説得して作業をすすめる努力である。それと、どこまでも方針を曲げずに実現することにある。データベースほど、構想通りのものを作ることほど重要なことはない。方針はぶれてはならない。ぶれが不整合なデータベースを生む。

何度も体験したことだが、やっつけで作っている部分はあらい。値のやりとりがずさん。とてもじゃないが、できあがってしまったものを直すことは困難。いっそのことゼロから作る方が早い。そうしたことを避けるためにもしっかりと構えてじっくりと取り組まなくてはいけない。

それだけの根性をもって変えられる人材が果たしてどの会社にもいるのだろうか?
結局は、電子書籍云々ではなく、この部分が一番いま版元が電子化していく努力をすべき点なようなきがしている。

システムについても追々紹介をしたい。
三省堂書店でEspresso Books Machineというのが稼働する。これは、その場で本を印刷製本してしまうというマシーンで、所謂、オンデマンド印刷の、究極の形といってもいいものだ。本のデータは、ネットからダウンロードしてくる。PDFならばどんなデータでもいいそうだ。ただし、原則的にはこのマシーンを作っている会社のサーバーのものか、三省堂が運営するサーバーにあるものということになるのだが、PDFを持ち込んでの印刷もできる。

このビジネスの特徴は、お客さんが注文してその場で1冊づつ作って販売するというもの。どの程度、ニーズがあるのかわからないが、とりあえずは、今後のラインナップによるだろう。現在は、Google Booksにある洋書を中心に行うのだそうだ。

現在の段階では、三省堂チェーンないでは他店での受け取りというのは検討中で、通販などは行う予定はないという。三省堂の神田本店でしか受けられないサービスというのが、いいことか悪いことか。

私は、割とこのマシーンに可能性を見いだしている。理由は、1部から刷れるという点である。そもそも教科書販売をやっていると、ずいぶんと昔に出ている教科書なのに、ずっと使ってくれている先生がいる。しかし重版する場合に、ようやく200、300部という部数での対応はできるようになったけれど、仮に5冊しか使わない場合に、200でも300でも何十年というスパンで消化していく必要があり、結局のところ赤字となる。

もし仮に5冊から対応ができるのであれば、こうしたニーズに答えることができる。

かつてロングテールという言葉が流行った。確かに長く細く売れることというのは、いいことなのかもしれないが、現実問題、版元にとっては倉庫料など見えないようで、厳密な意味で費用がかかっているのだ。確かにアマゾンのような巨大な書店にとってみれば、例え一年に1冊しか売れないような本が1万冊ぐらいあっても利益になるだろうが、1年に1冊、あるいは2年に1冊のような本は、在庫として抱えるべきか考えてしまう。もちろん、予測をたててかりに10冊ばかり在庫をとっておいたとして、上の例のように、いきなり5冊あるいは10冊、それ以上の注文が入ったときに対応できない。これが悩ましき問題でもある。

しかし,Google BooksあるいはGoogle Editionに代表されるPDFによる書籍データの閲覧および販売は、この部分をかなり大きくカバーできることになる。加えて、もし仮にそれが書籍という体裁をとれるとすれば、書籍を殺さずにおくことさえできると言っても過言ではない。

問題はこれをどう運営に組み入れていくかということだろう。

このあたりの問題は、出版社の一つのサービスの一つとして位置づけられるのではないかという気がしている。
先週の木曜日、現在の社内のシステムから外部のデータベースへのアクセスをするためにP社のHさんが設定に来てくれた。要は、現在のシステム(FileMakerベース)をSQLを使って某システムとやり取りをするというもの。これは、うちの会社のHPリニューアルには欠かせない作業で、もう3年以上も前から計画だけがあるのに実現しない、HPリニューアルの一つの大きなステップである。

これでどういうことができるようになるかというと、書誌情報の転送だけでなく、在庫情報のリアルタイム更新までが可能になる。私がいま考えているのは、編集サイドが必要とする情報も集約して、ステップごとに自動的に発売日などを変更していくことである。というのも、結局のところ印刷のオーダーがでないことには販売日が確定しない。反対に印刷にさえ入れば、見本だし、配本等は簡単にきまる。

現在、書誌情報の公開に関して進められている議論の中でもっとも難しいのは、この発売日の確定である。本来は出来てから考えてもいいようなものだが、慣例として、印刷に入る前に決定をしておく必要がある。しかしたいてい事故等でのびたりするのだが。

いずれにしても、できるだけ業務内で作られる情報は、情報として発信ができる環境づくりが今回のテーマである。

しかし驚いたのは、たった一つプラグインを入れるだけで、ネットを越えて向こう側にあるデータベースがまるで、自社のデータベースでもあるかのように見えることである。これはすごい。見えるというより、ほぼシームレスで使える、ということである。

フィールドの追加等はできないが、計算式だけは保存ができる。つまり、SQL上のデータベースの表現としてFileMakerが使えるということである。すごい。

これはたぶんデータベースを扱ったことのある人しか感動しないかもしれないが、とにかくこれまでのデータベースのあり方を考えさせることだ。

さて。知っている人は知っていることだが、自社のシステムは私の手作りである。納品書のシステムはすでに2年以上しっかりと稼働しており、短冊ソフト(書店からの電話注文等を管理するシステム)は、ようやく1年を経過して、まあ、ほぼ順調というところすでに5000レコード以上の注文をさばいている(冊数にするとうん万冊)。

今後の予定としては、前回作り込んだ倉庫の出庫管理システムの不具合を直すこと。これは今月末に棚卸しが控えているために急がなくてはいけない。加えて、この外部データベースへの接続だ。書誌情報の入力はだいぶ進んでいるが、接続部分とそのインターフェイスができていないために、そこを作り込む必要がある。

そこまでいけば、あとはホームページの立ち上げのみという流れだ。

なんだか事実だけを書いても仕方がないので。雑感。

時代というのは、確かに変わったなという気がする。これまでは自作のシステムにこだわってきた。理由は、業務内の特殊性をそのまま反映できるからで、確かにその点ではすぐれている。とくに採用注文を処理する部分は、これまでの労力を三分の一程度まで抑えることができた。それにより、ぐっと編集などにかけられる時間が多くなった(何せ自社出荷なもので)。

しかし、時代が変わったように思う。それは、あまりにも変化が早すぎて、システムの開発に1年なんて時間がかけられないということだ。データのシステムじたいも変化する。そもそもいまのシステムは、FileMakerが大きく変化したことから作り直しをしなくてはならなかったために1年足らずの運用実績になっている。

またこうした開発に時間をかけているあいだに、もっと力を入れるべきものがあるようにも思う。もっとネットを駆使することに時間を使うべきだという気がする。システムは、別にまかせ版元としては、販売のほうへネットやデータを駆使する方向に力を注ぐべき気がする。しかもそれは、いまリアルタイムに変化しているメディアにもっと積極的にコミットしていくことなのだ。

既に中核のシステムとして稼働している以上、メンテも拡張も必要だ。しかしその時間と、はたしてこれからの戦略としてのITについて時間を使うとすればどちらが得なのだろう。悩むところだ。