Hatena::ブログ(Diary)

さぼり記 このページをアンテナに追加 RSSフィード

 
好評既刊

2011-10-25

[]なぜ絶版本が電子書籍になりにくいのか?

「なぜ絶版本は電子書籍になりにくいのか?」

このエントリーに色々追加した内容がkindle本になりました(というか、2013年3月からなりつつあるところ)。

2011年から2013年までの間に進んだ変化なども盛り込んで進化した内容に!

でもなんか、言ってることは前とあんまり変わんねえ!という気もするような。

それだけ電子書籍を巡る状況ってのは、停滞してるのだろうか?

いや!

というわけで、解決策なんかも示していく方針です。

第一巻、99円です。ちょっとお試しを。

なぜ絶版本は電子書籍になりにくいのか?(Kindle本)

\99

加藤一(AZUKI)著



今週は電子書籍シンポ週間(主にTwitterで)。


「絶版になった旧刊こそ、電子書籍にしてほしい」

これは電子書籍もっとも大きく期待されるところで、旧刊蔵書を電子書籍化できたらどんなにか……というのは深く深く賛同する。

一方で、旧刊は電子書籍にしにくいという現実もある。


まず、著作権者(作者)の問題。

電子書籍化を嫌がる作者がいる、というのは避けられない問題で、やはり「複製可能媒体になることで収益が減少するのでは」という警戒心を持っている作者は少なからずいる。

これはレコードCDになったときCDダウンロード販売になったときにも散々言われた話。複製対策(DRM)が進んでも、この懸念を持つ作者は一定数はいると思う。


次に、作者そのものが見つからないケース。

絶版本ではこれが大きなネックで、「全ての作者は常にベテランで現役なわけではない」。

1冊だけ出して姿を消した作者、消息不明の作者は多い。

かつては編集者と作者の結びつきが強く、編集者が転属、転職退職してしまうと、その特定作者とのチャンネルが完全に途絶えてしまうということは珍しくなかった。

今は支払いなどのために一度でも仕事をしたことがあればその出版社の経理に「作者情報」が登録管理されているのだが、作者もナマモノというか生き物なわけで、携帯を変えることもあれば引っ越しだってする。

10年前に登録された1冊しか本を出さなかった作者の情報が、10年後にも新鮮だとは限らない。作者の引っ越し先について、作者が常に出版社に通知している、とも限らない。

また、今はTwittermixifacebookがあるから……と考えがちだが、今50代以上の作家の全てが必ず確実にそのどれかに「実名、または当時のペンネーム」で登録しているとは限らない。てか下手をすると今も手描きにこだわってPC持ってない高齢の作家だっているんだし。作家の全てがコンピューターおばあちゃん、おじいちゃんではないわけで。

1冊しか本を出さなかった、しかもそのことを家族も知らない、本人は既に逝去

このパターンとなるともはやお手上げで、「作者の生前交流があり最後まで知っていた人」が名乗り出ない限り、ほとんどわからない。

探偵を使う、本名から行政で辿る、方法はもちろんあるだろうけど、それはコストが見合わない。


そして運良く作者が見つかったとする。存命で、電子書籍化にも前向きで、作者の問題が解決した――としても、電子書籍化にはまだハードルが残る。

現在の出版物の製作現場は、ここ20年くらいの間に急速に「電子化、電算化」が進んだ。僕が小僧だった時代はまだ手引きのデザイン、手入稿、手で組版したアナログからフィルムを作る……という製版方法が主流だった。今も一部には残っているだろうが、この2010年の間に、新聞、雑誌、書籍のほとんど全てが「コンピュータ上でデザインをし、データを流し込み、出力したデータから版を直接作る」というDTP*1で作られている。

DTPオペレーティングデザイナーがやる場合もあれば印刷所が請け負う場合もある。僕のように作家/編集者が請け負い、自筆原稿をデータで納品するケースもある。

が、20年(下手すると10年)以上前の本は現在のようにDTPで作られていないので、データ存在しない。DTPで作られていたとしても、そのデータが紛失していて現存していない可能性が高い。HDDがある日突然憤死するのは珍しいことではないし、10年、20年前の「もうとっくに終わった使い途のないデータ」をきちんと保管し続けている所ばかりではない(^^;)*2

まり

「出版社に底本、コンテンツの出版権がある」

「作者が電子書籍化に合意し、許可を出す」

この条件が揃っても、

「本を電子データ化する」

という作業が必要になる。

自炊で旧刊を電子書籍している人は、「そんなの一冊ばらしてスキャナで吸えば済む話」と思うだろうが、文庫や雑誌などをそのままスキャンしたものは、はっきり言ってスマホで読むのはめっちゃキツイ。というか読めない。

iPhoneの画面サイズは960×640*3Androidは800×600が主流だが、もっと高精細のものもある。あるが、実際のディスプレイの大きさそのものは、せいぜい4.3インチ以下。

手元のスマホの画面を見れば一目瞭然だが、文庫1頁の大きさよりずっと小さい。

そこに文庫のページをスキャンしたものをまるまる表示したら、文字が潰れて読めない。

いちいち拡大して読むのは、激しく面倒くさい!

OCRスキャンすればよい、という意見もあろう。

実際そうなっていくだろうけど、その場合はまた別の問題が出てくる。

スキャンだけすればいいなら、作業も半自動化できるので、データ化作業は飛躍的に短く安くなるだろうが、OCRとなると「識字ミス」の補正必要になる。

かつてに比べOCRの精度は高くなったが、かといって常に100%なわけではない。個人で楽しむならまだしも、商品としてお金を取る商材にしようというのなら、誤字は本来はあってはならない*4

となると、OCR取り込みした後、校正作業が必要になる。校正については精度のいいソフトもないではないが、これらの校正ソフトは間違いを自動的に直してくれるのではなくて、間違い「かもしれない」ものを指摘してくれるだけ。それが間違いかどうかの判断は人間が下すわけで、結局のところソフトを使っても人力が必要なことに替わりはない。

それでも人力を投入すれば技術的には可能だ。

底本からOCRデータを吸い出し、それを人力で校正してデータデジタル化するということそのものは、青空文庫などで何年も前から有志が行っている。

が。

青空文庫は有志のボランティアで成り立っているが、商業コンテンツデジタル化となると、ボランティアにタダ働きをさせるわけにはいかなくなる。誤字誤植(商品としての瑕疵)がないものを目指すとなれば、作業に対する責任報酬保証することが求められるわけで、要するに【金が掛かる】。

ePub、XMDFなどユニバーサルデザイン念頭に置いたものを目指すのであっても、やはりテキストの完全性は重要になってくるわけで、フォーマットビルダーが無料であっても、その「実質的編集作業の発生」には金が掛かる。

著者の印税は売り上げ(実DL数)から出るが、現在電子書籍の製版編集作業工程では、編集作業費を捻出できない。つまり、「社員編集者が給料の範囲内で実質持ち出しで作る」以上のコストを、商品コンテンツに上乗せできないというか、上乗せしても大多数の本は恐らく必要分を確保できない(^^;)*5

現在電子書籍の多くは「紙の本の編集作業と並行してデータも確保し、そこから作る」というサービス業務的な趣がある。なので、新刊本が紙の本の発刊とあまり時を置かずに電子書籍化されるという流れはできてくるだろう。

しかし、旧刊は「再編集コスト」という壁があるため、一朝一夕にはいかない。

さらに、電子書籍特有のコストとしてライセンス料とインフラの維持コストがある。

ライセンス料はXMDF、ADPSなどにあるが「そのビルダーで電子書籍コンテンツを作った場合コンテンツ1本につき○○○円のライセンスビルダーの権利を持つ会社に支払う」というもの

XMDFは3.0からビルダーが無償化された*6が、3.0になった後もライセンス無償ではない。

インフラは、要するにサーバやペイシステムの維持コスト。ストアサイトに丸投げして自社では独自のものを持たない場合でも、間接的にストアサイトに料金を支払う*7ことでコストは発生する。

紙束という実体がなくても、電子書籍存在するのに金が掛かる。


それでも「現役のベテラン人気作家で過去作品にも需要がある」のであれば、それらを電子書籍化する意義はあるし、また電子書籍化することによって新たな需要も掘り起こせる。そうなれば、再編集コストライセンシーを掛けても回収できるかもしれない。


ここで本日の主題に戻ると、期待されているのは【絶版本の電子書籍化】である

作者が行方不明、一冊だけで消えてしまった作者の、重版も掛からないような不人気本の電子書籍化、である

不人気だから売れず、売れないから重版が掛からず、売れないから作者は一冊で筆を折り、売れないから作者は行方不明

絶版本というのはそういう宿業を背負っているコンテンツなわけで、電子書籍化しても売れない可能性が非常に高い。

ましてや、電子書籍の出版点数が増えていった場合、【不人気で絶版になった本】はあっという間に埋もれてしまい、気づかれず、積極的な検索もされない。

となると、まったくダウンロードされないので、再編集コストライセンシーインフラ維持コストなどが回収できない。もしくは、回収に非常に長い時間が掛かる。

投資効果が非常に低く、魅力がない。


「著者が自分で底本から校正してデータ化したものを持ち込み、ライセンシーを著者自身が負担する」

というところまで調えば、絶版本の電子書籍化配信のハードルはだいぶ下がると思う。

出版社、電子書籍配信社のリスクコスト負担を作者自身が負うことで下げ、配信に掛かる収益を分担しよう、ということになるわけだ。


が、この提案というか、そこまで作者の負担が大きくなるなら、出版社を介さずに作者が直に電子書籍配信社に掛け合ったほうが儲けが大きくなるのではないか。

そこに粉掛けしているのがAmazonKindle)やGoogleということになる。出版社を飛ばして直接作者と取引しましょう、でもデータ自分で用意してね、ということだ。


2010年来、「これからは出版社を飛ばして作者が直接電子書籍を売る時代になる」と取り沙汰されてきたが、実際になかなかその方向には進んでいない。

理由として、「文章を書く才能、マンガを描く才能と、編集する才能、――それをプロデュースして宣伝して売る才能は全く別個のもの」だから、というのがあるんじゃないかと思う。

「何もかも一人でできる人」というのはもちろんいる。でも、そういうマルチスキルの人ってのは、何か一つが抜きんでてできる人よりも圧倒的に少ない。

自分で書いて自分宣伝して自分で売って自分で売り上げ管理とか、何もかもをうまくやれる個人は、それほど一般的ではないってことであるわけで。

電子書籍を出版社というノウハウを持った組織集団の助力を得ずに個人が広く宣伝し周知していくというのは、とんでもなく困難だ。


歌えるから踊りもうまいとは限らない。

しかし、歌も踊りもうまくないと売れないとなると、歌唱力のみ秀でた人、ダンスだけ秀でた人は、両方できる人に比べて露出の機会が減る。まして「しかも曲も自作できないと」となるとますます減る。

特定分野のスキルが秀でた人が他の分野の才能も持っているとは限らないから

「絵を描く画家」と「絵を売る画商」、

「歌手」と「レコード会社」、

ボクサー」と「プロモーター」、

「小説を書く作家」と「編集者」と「書店営業」、

が、それぞれ分離しているわけで。

しかし異業種専門家が増えれば増えるほど「分け前は減り、分け前の元になる売り上げは増やさなければならない」ということになる。


電子書籍*8紙の本に比べてマーケットが非常に小さい。桁が幾つも低い。価格が紙の本より安く設定されているのだから、同じ売り上げを得るためには紙の本より多く売れなければならないにも拘わらず、現実には紙の本より小さいマーケットで、安い価格であることを期待される。

故にコストは掛けられない。

売り上げが期待できないタイトルは優先されない。


このへんが、「絶版本が電子書籍になりにくい」理由の説明として自分なりに腑に落ちる話、だと思っている。

*1Desktop Publishingの略。今はデジタルなんとかとか、いろいろ違うかもしれんがw

*2:僕のとこは90年代初頭からデータがほぼ残っている。PCで仕事を始めたのが早かったのと、ハヤニエ癖のせいか。

*3Retina

*4:でもどうしてもなくならないのが誤字、誤植ですorz

*5:理由は後述

*6:かつてはビルダーもアップデートメンテも全て有料でしたorz

*7:というか、売り上げからパーセンテージで払う

*8:現状では、という制限は付く

nemonemo 2011/11/01 19:59 とても勉強になりました。
「それらを電子書籍化する異議はあるし」→「それらを電子書籍化する意義はあるし」
あと,「粉掛け」ってなんですか?

azuki-glgazuki-glg 2011/11/02 01:13 異議>意義は修正済み。
粉掛け=粉を掛けるは、「秋波を送る」と似たような意味です。
本意は「気を引くために軽く口説く」。

bb 2011/11/02 21:48 絶版本の著者が野良の編集者とかに編集してもらうってのはどうすかね。
売り上げの取り分から40%なりもらう契約にして。
逆に言えば野良編集が知り合いの絶版本著者に営業かけて小銭を稼ぐという。

azuki-glgazuki-glg 2011/11/03 00:07 >b
多分必要になるのは、そうした絶版本著者と野良編集、出版社などのマッチングをするサービスじゃないかなあ、と。
青空文庫は絶版本著者の権利が消滅するのを待って、野生の入力者・野生の校正者が篤志でそれをする、というものですが、これをマッチングサービスを介在させて有償化する、とかですね。
ただこれは、読書メーターか、Amazonか、パブーあたりがやり始めて、話題になったところでGoogleが全部持ってくパターンではないか、という気がしないでもないw

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証