ビューワ開発者から見た、電子書籍業界のいま 電子書籍覆面座談会

http://ebook.itmedia.co.jp/ebook/articles/1110/06/news006_1.html

電子書籍において、ビューワの操作性が読書体験に及ぼす影響は大きい。ユーザーとコンテンツの出会いを演出するのがビューワ開発者の力量だ。本企画では、電子書籍ビューワの開発者に集まっていただき、覆面座談会という形で電子書籍市場の今を聞いた。

2人の開発者が電子書籍ビューワ開発の苦労や葛藤を明らかに

電子書籍にまつわるさまざまな課題点が指摘される中で、コンテンツの内容に次いで言及される機会が多いのが「ビューワの操作性」。操作の分かりやすさ、カスタマイズ性など、ビューワの使い勝手がそのまま電子書籍という媒体の評価につながることも少なくない。

ビューワ開発者からすると、世代やリテラシーを問わない実装や、キャリア側が要求する仕様との兼ね合い、さらにiOSやAndroidといったプラットフォームの仕様に依存する制限など、さまざまな葛藤があることだろう。こうした点について、国産の電子書籍ビューワの開発者お二人に覆面座談会という形で事情を伺った。

一人は、ケータイキャリアを中心に採用されている著名な電子書籍ビューワの開発者「T氏」、もう一人は、iOSやAndroid向けに電子書籍ビューワアプリを開発する「X氏」だ。それでは早速ご覧いただこう。ビューワの設計思想、デバイスやターゲットユーザーに応じた設計の違い、さらに各キャリアや出版社との日ごろのやりとりなど、ビューワ開発者から見た電子書籍業界を。

ビューワ開発者かく語りき

――　今日はよろしくお願いします。まずはお二人の自己紹介からお願いできますか。

T　もともとはガラケー向けのビューワの開発をやっていまして、その後Android向けのビューワの開発を手掛けるようになりました。最初は様子見でガラケーの移植版から始めたのですが、世の中の携帯がAndroidに急速に移行しているのと、Android自身のバージョンアップの速さもあり、順次ビューワの機能追加、および各種サービス事業者向けへの展開をしています。

――　いまはAndroidの案件が中心ですか。

T　そうですね。自社のソリューションをカスタマイズしてキャリアさんに出すという形です。ガラケーはもう何年もやっていますが、今後販売台数が減っていくのは間違いないので、ビジネスとしてAndroid向けに注力していかなくちゃいけないというところです。

――　Xさんは、最初はiOS向けにビューワをリリースし、その後Android向けにも展開されていますよね。

X　はい。ここ数年でネットワーク周りの状況がいろいろ変化し、そこに追いつこうとしている間に、どんどん変わっていったというのが実情ですね。

ユーザーの感覚が落ち着くまでもう2～3年掛かる

――　今、お二人が開発されているビューワも含めて、世間にはさまざまなビューワがありますが、インタフェースや挙動はバラバラです。例えば画面の右側をタップしたときに、ページが進むものもあれば戻るものもあったり、タップにすら反応しなかったり。お二人はこうした部分の設計をどう決めてらっしゃるんですか。

X　今は何がいいかという正解がありませんし、みんな「どうしたらいいんだろう」といいながらあがいている、そういう時期だと思うんですよ。「こういうのが常識だろう」というユーザーの感覚が落ち着くのにもう2～3年掛かると思うので、その過渡期といったところでしょうね。

T　出版社と話をしていると、最初は「このページめくりのエフェクトはいいね」となるんですが、しばらくして「すいません、やっぱり飽きました。やめときましょう」みたいな展開になることが多いですね。出版社の方はどうしても紙の本のイメージを前提にめくりの話をされますが、慣れてくるとやっぱり邪魔なんですよね。

――　ビューワを開発されるとき、そういった仕様は、出版社からの依頼で決めるのか、それともご自身でいろいろ調べて実装していくんでしょうか。

T　まずはOSの作法に合わせます。iPhoneとAndroid、ガラケーもそうですが、OSやプラットフォームならではの作法があるので、それを守るのが第一ですね。例えば、Androidだと1.6まではピンチに非対応なので、ピンチ前提で作ってしまうとUIが破たんします。だからやっぱりプラスマイナスボタンを出さなきゃダメだよね、とか。
また、「画面タップでメニューを出す」というiOSアプリによくある操作は、Androidの作法からするとNGなんです。Androidはメニューボタンを押してメニューを出すから、それに合わせてUIを変えなきゃいけない。ただ、たいていの出版社はiPhoneを前提に話をするんですよね。「そこは違う」と伝えるんですが、押し切られることもあって難しいところです。

――　Xさんのビューワは「使われないから機能から省く」ではなく、「設定でオフにする」という方向で対処されていますよね。

X　ページめくりの機能が必要か否かという議論でいくと、僕たちではなくユーザーが判断すればいい話だと考えています。先ほどお話ししたように今は過渡期なので、いろいろなやり方を「まずはトライしてみてよ」という意味であえて残しています。設定項目が多すぎるとダメという話もあるので、シンプルにしたいのは山々ですが、これは僕が決める問題ではないかなと。

T　Android向けの仕事だと、キャリアやサービス側が絡むので、いろんなビューワベンダーに「これは共通仕様として最低限守ってくれ」と言われてその仕様に合わせざるを得なくなることが多いですね。

――　つまり、ある電子書籍ストアで、見た目は1つのアプリだけど、買ったコンテンツの種類によってアプリに内包されているビューワが立ち上がるようになっているので、それぞれで操作性を統一するよう要求されるという、そういうことですよね。

T　そうです。同じストアから買ったコンテンツなのにフォーマットごとに作法がバラバラというのはユーザー視点で考えれば確かに大変なので、これはしょうがないかなと思います。
それと、長い歴史を持つXMDFや.bookにも独自の作法が存在しますが、それをひっくり返されちゃうのも逆にあります。例えば右左をタップしたら進むとか、上下で1行ずつ進むとか、ビューワごとの作法があります。XMDFに至ってはザウルス以来の作法があるので、XMDFを使い慣れた人間からすると、「何でこんなに使い方が違うんだよ」みたいになったりもしますね。さらに最近はタッチ操作などUIの前提条件が変わってきているので、それをどこまで踏襲しつつOSの作法に合わせるかが難しいところです。

iOS、Android、Windows Phone 7……UIの設計はますます困難に

――　iOS向けのビューワアプリだと、設定画面の呼び出し方も、画面中央をタップするタイプもあれば、例えば「理想書店」のように上もしくは下にドラッグしたら出てくるタイプもあったりとバラバラですが、これはAndroidのようなメニューボタンがないから、そうせざるを得ないということなんでしょうか。

T　そうです。特に電子書籍のビューワは、とにかく全画面にコンテンツ表示させたいというのがあるので、そうした設計になるんですよね。ほかのアプリだとタイトルバーに置かれたボタンから辿れますけど、全画面でコンテンツを出されちゃうともうどうしようもない。iOS系はもう百花繚乱ですよね。Android端末をメインで触っているわたしなんかがたまに触ると、どうすればいいんだろう？　てなっちゃう（笑）。

X　全画面表示で使えるボタンはホームボタンしかないということになると、操作としては完全に詰んでいるんですよね。だから、何か操作方法を考えなくちゃいけなくて、その中で一番単純なのが、真ん中タップだということです。どうしようもないんで、とりあえず何かたたいたら起こる、という範ちゅうで収めるしかないですよね。

T　だから、既存の電子書籍ビューワの多くが「タップ＝進む」なんですよ。気軽に読み進めたいっていうニーズがあるわけですよね。先ほどの理想書店の場合は、タップにそういう割り当て済みの操作が存在するので、ほかの操作にしなくちゃいけなかったんでしょうね。
画像系のビューワは特にそうですが、フリックのつもりが動いちゃったり、逆だったりすることが多いですね。慣れている人と慣れてない人、はらうスピードが速い人と遅い人がいるので、チューニングが難しいんですよ。最大公約数もありませんし。
また、特に問題になりやすいのが、「タップとロングタップの差」です。スマートフォンに慣れている方は使い分けられるんですけど、そうじゃない方だと震えてしまってうまく押せなかったりで、微調整が大変です。画面サイズにも関係するので、なおさらですね。

X　僕もユーザーからメニューが出ないとか、結構クレームが来ましたね。いったいどんな操作をしているんだろうと。

――　例えばそれは年齢による違いとか、リテラシーの違いとか、有意な傾向はあるものですか？

T　やっぱり年配の方は、ロングタップが難しいようですね。後はユーザーのPC歴。慣れてない人の方が、操作中に手がぶれてしまっている印象はありますね。

X　「母親が操作していたら、操作のたびに何か動くといわれた。これをオフにする機能を付けろ」って言われて、機能を付け足したことがありました。タップしてめくろうと思ったら指が当たったみたいで、ピンチになって拡大になっちゃうから、こんな機能は要らないって言われて。

T　サービス提供社側から、この機能は使わないから要らないとか言われることもあります。ありすぎて分からなくなるとか、どうせ使われないとか。確かに、そういうオン／オフの設定を触る人ってあまりいないんですよね。そもそもメニューまでたどり着かなかったりするので。だったら取っ払ってくれと。恐らくサポートが大変なので、できるだけ制限して問い合わせがこないようにしてくれということだと思います。

――　なるほど。サポート絡みの事情ですか。概して、Tさんの場合はITリテラシーが低い人に合わせて仕様の部分で切る、といったところでしょうか。

※写真
Metro UIを採用したWindows Phone 7.5。OS間で異なるUIが開発の障壁に？

T　そうですね。Androidだと、OSの作法に合わせるというのも心掛けています。普通にブラウザを触っていれば、OSの作法に慣れてくるはずなので。逆にビューワ側で勝手なことをやってしまうと、「何か違う」って違和感を覚えるはずなんですよ。

――　OS標準の操作に合わせておくことが、ITリテラシーが低い人への対策にもなるということですね。Androidもこれから初心者がどんどん流入してくる可能性が高いわけですけど、そこはもうOSの作法で学んでくれと。

T　はい。ただ出版社の方はiPhoneに合わせて話をしてくるので、Androidのユーザーが本格的に使い始めたら、お互い違う意見を言ってくると思うんですよ。今後そこは揉めるかもという懸念はあります。しかも、Windows Phone 7が新しく出てきたじゃないですか。あれはMetro UIというまったく別のUIなので、iOS、Androidと三つ巴になってきたらとてもじゃないですが共通化できないでしょうね。そうした事情が分からない出版社の方の意見は、今後もっと増えるとみています。

ユーザーに「要らない」と言われる機能は、見せ方に問題があるだけかもしれない

――　ビューワの機能で、本全体のどのくらいの割合を読んだかという、既読表示の機能がありますよね。あれなんかはどう思われますか？

T　「あんまり画面にごちゃごちゃ出さないでくれ、うざったいから」ってユーザーから言われちゃうんですよね（笑）。

――　それに敢然と立ち向かっているのがiBooksなんですけど（笑）。先日の漫画家さんの座談会でも話題に上りましたが、iBooksだとページの左右に紙の厚みを示すデザインがあります。こういうのはXさんの設計思想からするとどうでしょう？

X　厚みが変わらないやつですよね（笑）。こうした縁を付けようと思ったら、その分ページの面積を減らさなくちゃならないので、ちょっと違うかなと思います。

※写真
iBooks

T　余白というのは本来、印刷などの都合であって、コンテンツは関係ないですから。もっとフルに見せて、情報量を増やしてくれと思いますね。
そもそも、既読の割合を気にするコンテンツと、気にしないコンテンツがあると思います。長編作品なら「どのくらいまで読んだかな」というのがあるでしょうけど、短編だとあまり気にしなかったり。ガラケーはどこまで見てるか表示できないことも多いのですが、閉じたときにどこまで読んだかページ位置を保存していることもあってか、あまり批判は聞かないですね。特に漫画は1話売りが多いですし。

X　僕は結構ユーザーから言われますね。

T　ただ、声の大きい人が大多数というわけじゃないですよね、実際のところ。

X　つまり「要らない」と自信を持って言える人と、「要る」と自信を持って言える人、どっちなんだってことですよね。「どっちでもいい」という人と「要る」人だったら、それは「要る」ってこと。「要らない」と「どっちでもいい」なら「要らない」。その考えでいったら、やっぱり「要る」になるんじゃないかなと。

T　ただ、「要る」と思ったけど、消してみたら気にならなかったという人もいる（笑）。
X　それは「どっちでもいい」人ですよ。問題なのは「要らない」という人の中に、僕ら開発者の見せ方が下手くそだから要らないといっている人が含まれていることなんですよね。「こんなウザいのは要らない」という声、それが怖いんですよ。それさえクリアできればもちろん付けたいですし。どういったアプローチがいいのかは、開発ですごく悩むところです。

――　例えばシャープのGALAPAGOSだと、ページ番号の表示は文字サイズを変えても変わらないんですよね。最初全部で500ページって表示があったとするじゃないですか。それで、文字サイズを小さくして1ページに収まる文字量が倍になったら250ページに減るはずなのに、500ページのまま変わらない。どうなるかというと、1ページめくるたびにページ番号が1つずつスキップされるという。

X　おお、考えましたね。

T　XMDFはザウルスのころからやってて、ノウハウはあるはずなんですけどね。どうやって計算してるんだろう。デフォルトのフォントサイズでやってるってことですよね、それって。

――　デフォルトのフォントサイズでページ数をカウントして、大きくなったり小さくなったりしたら、分母を変えずに分子をいじるということですよね。だから考え方としてはパーセンテージに近い。結果として、めくった次も同じページというケースが発生するわけですよね。1、1、1、2、2、2とか。

X　電子教科書になったときに「教科書の何ページを開いて」って言われてページを開けたところ、みんな違うところを開けていたという笑い話がありましたけど、その辺りを考慮した結果かもしれませんね。

――　それにしても、操作性に多少なりとも共通項のあるページめくりに比べて、既読位置の表示方法はバラバラですよね。デジタルコミックに至ってはコマ単位表示でページという概念もないわけですし。

T　そうですね。デジタルコミックではしおりを保存したときや、目次のところに「何コマ目」というのを表示していますね。コマ系だったら何コマ目、ページ系だったら何ページ目というように。

――　なるほど。「何コマ目」なんですよね。そう考えても、ページングで考えられているものとは作り方がまったく異なりますね。

「書庫に保存したい」「買ったらすぐ読みたい」、相反する2つの需要

※写真
写真はezPDFreader（Android版）。画面下部に各ページのサムネイルを表示していることが分かる

――　最近のビューワのトレンドとして、画面下部に各ページのサムネイルを表示できるというのがありますよね。国内でもそうですし、海外のPDFビューワ、例えばezPDFreaderにもあります。読み込みが遅いのが残念なんですが。

X　読み込みの遅さは、デバイスのハードウェアスペックが高くないので、どうしても出てきます。でもそれは過渡期ゆえのことであって、もう1～2年もしたら解決するんじゃないかと。CPUを2～3個に増やせば済みますから（笑）。

T　ヤッパのビューワなんかは、ページをめくったら必ず全体表示するので、それ用に低い解像度の画像を用意していて、ペラペラめくる分にはかなり高速です。キャッシュもしているようですし、そこが1つの売りですよね。頻繁に拡大するユースケースが多いから、そうなっているんでしょうね、恐らく。

――　ガラケーでも、スペック依存の問題はありましたか？

T　ガラケーは、auだとコンテンツサイズが1.5Mバイトまでという制限があるので、そこに縛られますね。よく「なぜコミックスを話数単位で分割するんだ」といわれるんですが、それは容量制限の問題です。コマ分割は画面サイズの問題で、コンテンツの分割は配信側の問題ということになります。また、スマートフォンでコンテンツサイズの制限が解除になったからといっても、例えば3G回線で50Mバイトのデータを落とすのはきついですからね。
読者からすると「買ったらすぐに読みたい」なんですよ。繰り返して読む方はコンテンツを書棚に残しておきたがるんですけど、読み捨て的な需要も実は多くて、ストリーミングで今すぐ読みたいという相反する需要があったりして、とても難しい問題です。

――　ストリーミングだと、例えばマガストアですね。そういった仕様を最終的に決定しているのは誰なんですか。

T　サービス側です。ストリーミングだとダウンロード側よりもDRMを考えなくて済むので、提供する側としては実装が楽なんですよ。DRMを考え出すと、結局出版社がコンテンツを出したくないとか、そういう話も出てくるので。
E Ink採用端末向けには設計に違いも

――　少し話は変わりますが、電子書籍端末は液晶以外にE Inkを採用した製品もあります。E Ink向けのビューワでは、液晶の場合と設計を変えざるを得ないところがあるそうですね。

T　ボタンを押したときの操作性ですね。普通ならボタン押しっぱなしでパッパッとめくるじゃないですか。ところがE Inkは画面の書き替えに時間が掛かるので、表示が間に合わなくてめくれないんですよ。E Inkを採用しているソニーの「Reader」やKDDIの「biblio Leaf SP02」では、液晶の端末と違って、ボタンを押していったん離すことでページがめくられますよね。

――　なるほど。押すだけじゃなくて、押して離さなくちゃいけない。
T　ええ、離したときです。だから、押しっぱなしでは連続めくりができません。製品によって多少違いますけど、E Inkはページが切り替わるまで確か0.8秒くらい掛かるので、自然とそうした設計になります。

「デジタルコミックはコマ区切りが標準」という人も実は多い

――　画面サイズについてはどうでしょう。Tさんだと、これまではガラケー、いまはAndroid中心ということで、サイズの種類も多そうですね。

T　そうですね。ガラケーでは多少の大小はありますがだいたい同じ画面サイズで、解像度は基本的にQVGAとWVGAの2種類ですが、スマートフォンになってから、さまざまな画面サイズと解像度のものが登場しています。片手で持てる小さいものから、GALAXY TabやXOOMなどの大きなものもありますし。物理的な画面サイズが違うと、やっぱり世界が変わってきますからね。
基本的には表示倍率を変えて画面に合わせるのですが、何でも無限に拡大すると粗くなりますし、さらにオーサリング時に「最低限この範囲は表示」「最大はここまで」という設定があるのでそれらを基に表示を計算しています。もともとガラケーは、各キャリアごとに標準とするサイズが違います。コンテンツを作る側はそれぞれのサイズ向けに生成する手間は掛けたくありませんから、1つの元データから別々に最終データを作るという概念を導入しているわけです。
出版社の編集の方からは、「ページで作る方が楽なのは分かっているが、ガラケーで漫画を読んでいる人たちは『デジタルコミック』としてその動きに慣れてしまっているので、ページでは売れない」とよく聞きます。つまり、コマ区切りが標準というデジタルコミックならではの動きに慣れている層が一定数いるわけです。だからといって最初からコマ区切りで制作してしまうと、いざ売れたから単行本化しようという段階で困るわけですが（笑）。
――　今、デジタルコミックは幾つか種類があるじゃないですか。ページ全体を見せるタイプもあれば、ページを拡大しながら右上、左上、右下、左下という逆Ｚの順序でスクロールするタイプ、完全なコマ単位で横に長ければスクロールするタイプ、だいたいその3パターンですかね。

T　そうだと思います。スクロールについては逆Ｚに限らず、コマに合わせて読む順番をオーサリングできますね。スクロールするスピードも制御できます。

――　こうしたスタイルが出てきたのは2003年前後ということですが、7、8年経ってこのスタイルに慣れたユーザーが増え、漫画の読者の中でも、コマ分割タイプに慣れているユーザーもいれば、1ページ単位で決められたレイアウトがなじむユーザーもいると。

T　そうですね。「携帯で見る漫画はこう」みたいな。ガラケーに関しては、9割はコマ形式での配信だそうです。実際に編集者の方に聞くと、「だってコマが売れるんだもん」という（笑）。製作コストが10倍ぐらい違うらしいので、できればコマ形式で配信はしたくないというお話はよく伺います。
実際に使っていても、iPhoneサイズぐらいだと、まだコマ分割タイプの方が見やすいですよね。ページだと頻繁に拡大しなくちゃならないので。GALAXY Tabぐらいの画面サイズになると、まあいいかなという気になるんですけど。

X　元の漫画がどういう形で描かれているかですよね。元からデジタルコミックを前提に制作されているのならともかく、ページング前提で制作されたものを無理やり切り貼りして、バイブのところでブルブルブルっていうのはちょっと。個人的には、ページングで作られたものはそのまま見たいですね。

――　携帯漫画のバイブ機能、あれは誰がディレクションしてるんですか。

T　出版社によって外注のオーサリング会社に丸投げもあれば編集者がやることもあったりとさまざまなようです。TVアニメを静止画で取り込んで漫画風に見せるコンテンツなどでは、アニメの演出家の方が絵コンテみたいな感じで細かく演出を入れているそうです。

――　その一方で「これ、やっといて」みたいな感じで紙の単行本をポーンと渡されて、自炊みたいな感じで裁断して、後はお任せというパターンもあると。

T　あるようですね。聞くところでは、吹き出しが切れているのをくっつけたり、足らないコマを勝手に描き足しちゃうケースもあるそうです。それはちょっとどうかなとは思うんですけど。海外のオーサリング業者に出したらひどいのが返ってきたという話も聞きますね。

EPUB 3はあくまでもフォーマットで、運用フローはまだない

――　今、EPUB 3という新しい規格が出てこようとしています。お二人はEPUB 3についてどのような見解をお持ちですか？

X　EPUB 3はHTMLの拡張でしょ。HTMLの拡張ということは、HTMLを表示しなくてはいけない。HTMLを正確に表示するためには現状WebKitとかのライブラリを使うしかない。
でも、文字を表示して横にルビを打つだけなんて、文字を書ければ出ますよね。そこに対してHTMLのレンダラを持ってきて、CSSのレンダラを持ってきて……となると、初めから書けないくらい実装難度が高いんですよね。オープンソースのソフトウェアを持ってきたらいいと簡単に言う方もいますけど、どうやって使っていいか分からないものを持ってきても、うまくはまるか分かりませんしね。今のビューワをEPUB 3対応させたいとは思いますが、実装するのはコストが高いので悩ましいところですね。

T　わたしは直接EPUB 3にはタッチしていませんが、組版をそこまで意識しなきゃいけないのかな、という気はします。それと、あんなに仕様が大盛りだと、果たしてそれに合わせたコンテンツが作れるのかなという。
あと、例えばiBooksは今のEPUB 2でも独自拡張していますよね。だからEPUB 3といっていても、昔のブラウザ問題みたいな、例えばIEだけスクロールバーの色を変えられたりとか、そうなる懸念はありますね。特にEPUB 3はJavaScriptも全部動いちゃうんで、高機能なものを作ろうとすると、挙動もみんな違うし、作るコストも高くなるという。

――　コンテンツについては、紙を前提に制作されたものと、これから増えるであろうボーンデジタルの違いもあるかと思います。例えば漫画なら、既存のものはPDFやZIP圧縮JPEGで見せるとか、あるいはEPUB 3で一手間掛けてコマ単位で切って見せていくかという。それに加えて、今後、何か出てくるかもしれないけど、現時点ではまだ見えてないと。

T　そうですね。作り手側もいきなり作れるわけじゃないですからね。EPUB 3はあくまでもフォーマットであって、アウトプットをEPUB 3にする標準的な運用フローはまだないじゃないですか。

X　ユーザーにとってはフォーマットなんてどうでもいいですしね。ましてやDRMが掛かっていたらどのフォーマットも無理ですからね（笑）。

T　そこがFlashが支持される理由の1つですよね。凝ったものが確実に作れて、しかも実行モジュール込みだからDRMも掛けられる。結局のところ、リッチなコンテンツで作るんだったら、じゃあ、みんな「やわらか戦車」つくるのか、という話になってきますよね。あれは全然違うものじゃないですか。アニメでもない、まあ、パラパラアニメですよね。

X　個人的には、漫画家さんにはそういったものにチャレンジしてもらうのではなく、その時間を使って、好きなように描いてほしいですね。
T　漫画家さんは本を出して初めてまとまった収入になるわけですし、もちろんデジタルコミックがお金になるのならやる人は増えるでしょうけど。何だかんだ言って電子書籍単体で収益を上げている方はそうそういないですしね。

1年でこれだけ変わったら、むしろ十分

――　最後に、ビューワに限らず、電子書籍界隈で最近気になっていることがあれば。

T　これからの新しいサービスですが、楽天の「Raboo」は、すでに楽天市場でECとしての実績がある分、ほかの電子書籍ストアとは違うかなと思います。楽天で買い物しました、楽天スーパーポイントが500ポイントある、じゃあ電子書籍でも買おうかみたいな。配送料も要らないですし、そういう強みがありますよね。

X　僕は、日本に来るといわれていたAmazonやGoogleに何の動きもないのが「まだ来ない」なのか、それともこのままスルーされてしまうのかが気になっています。もしかして、日本という狭い市場に対してコストが合わない、やるだけの価値がないと判断されたのかなと。

T　ある会社で電子書籍のコンテンツ制作をやっている人から、彼らから打診があってテストコンテンツを作ったという話は聞きましたね。

X　ええ、いろいろなところに打診は行ってるようですが、Goしないというところがやばいのかな、という気がしますね。

T　Amazonは流通から課金から何から全部抑えているわけで、普通に考えると出版社がちょこちょこやったところで勝ち目はないので、出版社はあれを使って商売するしかないのかなと思います。特にKindleはマルチプラットフォームでやっていますから、あれに勝つのは難しいですよ。
ただ、日本の出版や流通は複雑で、出版社に話を持って行っても、コンテンツがそろうわけじゃなかったりもしますし。本来は出版権であって著作権ではないはずが、出版社が全部握っている。そういう日本特有の構造があるから「面倒だな」ってなると思うんですよね。

X　出版社としては、黒船が来たので身を潜めて「過ぎ去れ」と思ってるんでしょうけどね。たいていの出版社は電子書籍なんか望んじゃいないですからね。望んじゃいないものはやりたくないですよね。

T　いままでの仕組みと違うものになっていくと、既得利権を持つ方はどうしても抵抗しますよね。ある印刷会社は、極端な話、既存の印刷工場などを縮小していきたいらしいんですけど、電子を全面的に推進して人を切れるかというとそうもいかないので、そこはソフトランディングしていくしかないと。

――　なるほど。

T　ただ出版自体が下り坂であるのは間違いないので、新たな媒体ができたつもりでやっていくしかないと思います。ある総合書籍ストアは、電子書籍サービス側でユーザー情報を取りながら紙の本と電子書籍で総合的にマネタイズしていくという話をされていて、それはそれで正しいと思いました。
ただ実際は、パブーのような新興勢力がやるか、Amazonのような大きいところがやるか、そのどちらかだと思います。特にAmazonは本屋であると同時にIT企業なので、あそこまでできるという。ただ、どんなにいいサービスを作っても、コンテンツを集めないことには誰も振り向いてくれないので。問題はそこですよね。

X　構図はこれからいろいろ変わってくるでしょうが、いきなり勢力図が変わることはないでしょうし、焦らずもうちょっとゆっくり見ていても構わないんじゃないかなと。「1年たってこれだけしか変わらなかった」ではなく「1年でこれだけ変わったら十分じゃない？」という。紙の印刷を始めて何十年、何百年ってやってきたわけですからね。Amazonだって、いきなりKindleをバーンと売り出したわけじゃなくて、それまでに書籍通販として経験を積んできたからできたわけで。

――　確かに、総括を急ぎたがっているような感はあります。

T　電子書籍ビジネスって、例えば電子書庫パブリやeBookJapanなどは2000年ぐらいから、パピレスは1995年にサービスインしているわけで、別に去年はじめて出てきたわけじゃないですか。出版社からするとXMDFや.bookでいままで培った運用フローがあるので、当面はそれでモノを出していくしかないんですね。だからこそ角川とかはひとまず.bookでやろうとなったわけで。
要するに今現在、できる運用フローはそれだけなわけです。EPUB 3も研究はしているでしょうが、今すぐ始められる状態じゃないわけで、その辺りが実際に立ち上がるのは来年、再来年といったところではないでしょうか。

――　今年来年といわず、もう少し長いスパンで見ていく必要があるということですね。今日はありがとうございました。