http://www.ebook2forum.com/members/2011/10/next-generation-pub-standard-epub-3-supports-japanese-typesetting-rules/
EPUB 3の標準化を進めてきたIDPFは10月11日、会員による投票の結果、提案どおりに最終仕様(IDPF勧告)として採択し、公開したと発表した。EPUB 3は2010年5月に着手され、今年5月に勧告提案として決着して正式採択を残すだけとなっていた。最新のWeb標準であるHTML5をベースとし、リッ チメディアや対話機能、日本語縦組みを含む多言語表現、スタイルとレイアウトの拡張、メタデータファシリティ、MathML、アクセシビリティなどを含み、プリミティブだった従来の面目を一新した。
新世代の世界標準に日本語組版仕様が入った奇跡
IDPFのビル・マッコイ事務局長は「デジタル出版は、電子テキストから拡張E-Bookや新しい形の表現形態へと進化していますが、EPUB 3は、様々なデバイスやブラウザ、アプリを利用する読者に豊かな体験を届ける上での著者と出版者の能力を劇的に広げるでしょう」と述べている。彼が要約し たように、それは構造化され、信頼性が高く、デバイス非依存でアクセシビリティを備えた、新世代のツールをサポートする標準といえる。EPUB 3の機能に対応した製品の開発は、昨年5月以降に本格化しており、一部はリーディング・システムやオーサリング・ツールで実装され実用されている。
日本からみると、初の本格的E-Book標準ともいえるEPUB 3の中に日本語組版仕様を含められたことは、じつに画期的な成功といえる。事情を知る者からすれば、奇跡とも言えるものだ。成功の要因を3つあげておきたい。
第1は、大改訂のタイミングを的確に捉えたこと。大きな改訂は5年に一度のイベントで、1年～1.5年の集中的な活動の中で行われる。こんなチャンスはそうない。
第2に、国際舞台でチャンスを生かす上で必要な、実績あるエキスパートがいたこと。W3Cなど過去の活動の、有形無形の遺産がないと不可能である。
第3に、JEPAを中心によくまとまり、困難とみられた「公的支援」も得て、最も重要な日本国内での理解・支持・要求のとりまとめに成功したこと。
「国際標準」に対する日本の産業界（それにメディア）のリテラシーは高くない。そのため「日本 vs.…」とか「日本発」という間違った期待が、エンジニアを縛り、ITの標準化の場では最も必要とされる調整能力（＝リーダーシップ）の発揮を妨げる傾向があり、そのために「独自利害」にのみこだわる日本人という風評が定着しているからだ。ただでさえ英語でのディベートというハンデがある上に、有難くない風評まで立っているのだから、国際舞台で活動する日本のエキスパートは、技術、人格、実績、調整能力のいずれでも高い水準が求められる。しかし、逆にそうした人物は日本では煙たがられることが多いのだから、成功率が低いのは当然だろう。
EPUB についても、日本の理解は高くなかった。最もITから遠いところにいる出版界がユーザーなのだから当然でもある。出版界の関心は、対話機能でもマルチメ ディアでも、アクセシビリティでもない日本語組版、それも「縦組・ルビ」に集中していた。文章に正書法がなく、文字にも組版にも標準というものがない（整合性のない無数のルールが存在する）日本語というユニークな言語文化を前提にしつつ、そうした渾然たる表現をサポートする「標準」を仕様化しようとするの だから、あらゆるレベルの議論が噴出するのも無理もない。誰しも「日本語」については熱くなる傾向があるが、それは言語生活が混沌としており、また日本語 以外を知らないからでもある。そして日本人以外は、そうした熱い話に付き合ってはくれない。
EPUB 3の日本語仕様を、まだきちんとチェックしたわけではないが、標準に「完全」ということはあり得ない。標準はあくまで技術経済的に解決する手段を規定する ものだからだ。それに飽き足らず、経済的余裕があれば、別の道はいくらでもある。日本語組版は、木版、活版、写植、DTP、Webと、実現技術が変化する 間に変化してきた。出版社や編集部ごとに違う無数の「ローカルルール」はその遺産であり残骸である。この際、「仕分け」が必要だろう。EPUB 3に日本語仕様を盛り込むことでわれわれが勝ち取ったものは、E-Readerやタブレット、Webブラウザ、E-Bookオーサリングツールを含む世界のIT製品での日本語組版のサポートだ。これにより、日本語の国際化を進め、日本語作品をそのまま海外に輸出することも容易になる。これをどう生かすかは出版界の仕事だ。
2011年10月14日金曜日
2011年10月13日木曜日
ACCESS、EPUB 3準拠の電子書籍ビューワを発表
http://ebook.itmedia.co.jp/ebook/articles/1110/12/news093.html
ACCESSは10月12日、EPUB 3に準拠した電子書籍ビューワ「NetFront BookReader v1.0 EPUB Edition」を発表した。同日から10月14日まで東京ビッグサイトで開催される「Smartphone ＆ Tablet 2011」の同社ブースでは、Android端末上で動作する同ビューワが披露されている。
EPUBはHTML5やCSS3などのWeb標準技術をベースにした電子書籍のファイルフォーマット。AppleやGoogleなども自社の電子書籍サービスでEPUBを採用しており、グローバルでは標準的な電子書籍フォーマットとなっている。10月11日には電子書籍標準化団体の1つであるInternational Digital Publishing Forum（IDPF）がEPUBの最新版「EPUB 3」について、Final Recommendation版として委員会で正式に承認したと発表しており、EPUB 3を基にしたビューワやオーサリング環境などが今後数多く登場するとみられている。
ACCESSでは、組み込み向けソフトウェアで培った技術力、2011年4月に発表した電子出版プラットフォーム「ACCESS Digital Publishing Ecosystem」のノウハウを活用、プラットフォームを問わず動作するフットプリントの小さなEPUBビューワを完成させた。国内ではイーストがEPUB 3.0に準拠したPC向け電子書籍リーダー「espur」を7月に無償公開しているが、商用目的あるいはAndroid上で動作するEPUB 3準拠の電子書籍ビューワは国内初となる。同ビューワはACCESS Digital Publishing Ecosystemでも利用されるという。
同ビューワの開発には、朝日出版社、NHK出版、学研ホールディングス、河出書房新社、幻冬舎、主婦の友社、新潮社、日経BP、早川書房、丸善出版、メディアファクトリーなど出版社18社が協力、EPUB 3で可能になった複雑な日本語組版――縦書き、ルビ、禁則、傍点など――が本当に出版社のニーズを満たせるのか評価をこの数カ月重ねたという。名前が明かされていない出版社の中にはいわゆる「御三家」と呼ばれる小学館、集英社、講談社のいずれかも含まれるとみられるが、いずれにせよ、多くの出版社がEPUBの評価に取り組んでいることが分かる。
.bookやXMDFからEPUBへの変換もワンクリックで
この発表で注目は、技術支援を行ったワイズネットの存在。同社は電子書籍のオーサリングなどで知る人ぞ知る業界では有名な会社だが、同社の協力の下、.bookやXMDFなど国内で有力な電子書籍フォーマットからEPUBへの変換がワンクリックで忠実に行える（正確には直接の変換ではなく、HTMLを介した変換）。過去にイースト代表取締役社長の下川和男氏もeBook USERのインタビューで、「（どれもHTMLベースで作られたものなので）.bookやXMDFからEPUBへの変換というのはそれほど難しくない」と話しているが、既存資産のEPUB化はすでに現実的なレベルで機能しているといえる。
EPUB 3はHTML5やCSS3などのWeb標準技術がベースとなっていることは上述のとおりだが、それぞれの仕様は非常に膨大なものとなっている。出版社などからすれば、どうやって使えばよいか分からないような仕様も少なくない。そのためACCESSでは、最大公約数的に必須と思われる仕様をまずはしっかりカバーし、細かな仕様は出版社のニーズを拾いながら逐次対応する姿勢でいる。また、EPUB 3ではまだ難しい表現などは独自拡張で対応しているようだが、長期的にはそうした部分をEPUBの仕様に盛り込むため、今回の発表に併せてACCESSはIDPFへの加盟を発表している。
この発表の数日前には、ヤフーもEPUBを採用した電子書籍配信サービス「Yahoo!ブックストア」を今冬にも開始すると発表している。EPUBの仕様は公開されているため、EPUB 3に準拠したビューワは今後数多く登場するだろう。GoogleがAndroidにGoogle謹製のEPUB 3ビューワを用意したとしてもさほど不思議ではない。そうなると、ビューワだけの提供では大きなビジネスとならない可能性があるため、周辺環境まで含めた包括的なソリューションを各社が今後打ち出していく可能性が高い。製作から販売まで急速に整備が進むEPUB 3関連のトピックはしばらく注目を集めるだろう。
ACCESSは10月12日、EPUB 3に準拠した電子書籍ビューワ「NetFront BookReader v1.0 EPUB Edition」を発表した。同日から10月14日まで東京ビッグサイトで開催される「Smartphone ＆ Tablet 2011」の同社ブースでは、Android端末上で動作する同ビューワが披露されている。
EPUBはHTML5やCSS3などのWeb標準技術をベースにした電子書籍のファイルフォーマット。AppleやGoogleなども自社の電子書籍サービスでEPUBを採用しており、グローバルでは標準的な電子書籍フォーマットとなっている。10月11日には電子書籍標準化団体の1つであるInternational Digital Publishing Forum（IDPF）がEPUBの最新版「EPUB 3」について、Final Recommendation版として委員会で正式に承認したと発表しており、EPUB 3を基にしたビューワやオーサリング環境などが今後数多く登場するとみられている。
ACCESSでは、組み込み向けソフトウェアで培った技術力、2011年4月に発表した電子出版プラットフォーム「ACCESS Digital Publishing Ecosystem」のノウハウを活用、プラットフォームを問わず動作するフットプリントの小さなEPUBビューワを完成させた。国内ではイーストがEPUB 3.0に準拠したPC向け電子書籍リーダー「espur」を7月に無償公開しているが、商用目的あるいはAndroid上で動作するEPUB 3準拠の電子書籍ビューワは国内初となる。同ビューワはACCESS Digital Publishing Ecosystemでも利用されるという。
同ビューワの開発には、朝日出版社、NHK出版、学研ホールディングス、河出書房新社、幻冬舎、主婦の友社、新潮社、日経BP、早川書房、丸善出版、メディアファクトリーなど出版社18社が協力、EPUB 3で可能になった複雑な日本語組版――縦書き、ルビ、禁則、傍点など――が本当に出版社のニーズを満たせるのか評価をこの数カ月重ねたという。名前が明かされていない出版社の中にはいわゆる「御三家」と呼ばれる小学館、集英社、講談社のいずれかも含まれるとみられるが、いずれにせよ、多くの出版社がEPUBの評価に取り組んでいることが分かる。
.bookやXMDFからEPUBへの変換もワンクリックで
この発表で注目は、技術支援を行ったワイズネットの存在。同社は電子書籍のオーサリングなどで知る人ぞ知る業界では有名な会社だが、同社の協力の下、.bookやXMDFなど国内で有力な電子書籍フォーマットからEPUBへの変換がワンクリックで忠実に行える（正確には直接の変換ではなく、HTMLを介した変換）。過去にイースト代表取締役社長の下川和男氏もeBook USERのインタビューで、「（どれもHTMLベースで作られたものなので）.bookやXMDFからEPUBへの変換というのはそれほど難しくない」と話しているが、既存資産のEPUB化はすでに現実的なレベルで機能しているといえる。
EPUB 3はHTML5やCSS3などのWeb標準技術がベースとなっていることは上述のとおりだが、それぞれの仕様は非常に膨大なものとなっている。出版社などからすれば、どうやって使えばよいか分からないような仕様も少なくない。そのためACCESSでは、最大公約数的に必須と思われる仕様をまずはしっかりカバーし、細かな仕様は出版社のニーズを拾いながら逐次対応する姿勢でいる。また、EPUB 3ではまだ難しい表現などは独自拡張で対応しているようだが、長期的にはそうした部分をEPUBの仕様に盛り込むため、今回の発表に併せてACCESSはIDPFへの加盟を発表している。
この発表の数日前には、ヤフーもEPUBを採用した電子書籍配信サービス「Yahoo!ブックストア」を今冬にも開始すると発表している。EPUBの仕様は公開されているため、EPUB 3に準拠したビューワは今後数多く登場するだろう。GoogleがAndroidにGoogle謹製のEPUB 3ビューワを用意したとしてもさほど不思議ではない。そうなると、ビューワだけの提供では大きなビジネスとならない可能性があるため、周辺環境まで含めた包括的なソリューションを各社が今後打ち出していく可能性が高い。製作から販売まで急速に整備が進むEPUB 3関連のトピックはしばらく注目を集めるだろう。
2011年10月11日火曜日
電子書籍アプリ開発者は要注目、米FacebookがHTML5 Webアプリ販売インフラをiOS向けに正式稼働
http://hon.jp/news/modules/rsnavi/showarticle.php?id=2785
SNS最大手のFacebook社（本社：米国カリフォルニア州）は現地時間の10月10日、同社が会員ユーザー向けに公開しているiPhone版アプリを大幅アップグレードし、iPadにも対応した。
今回Version 4.0として公開されたこのiPhone／iPad版「Facebook」アプリでは、ここ半年ほどサードパーティ開発者たちの間で噂されていたHTML5アプリ配信サービス（コード名：Project Spartan）に対応。これにより、ゲームなどのアプリデベロッパーや一般のWebデザイナーが、iOS版Facebookユーザー向けに自作のHTML5アプリを配信・販売できるようになる。ただし課金システムは、Apple社の規約により、Facebook独自の「Facebook Credits」ではなく、Apple社のInApp課金を使う必要がある模様。
なお、すでに「Magic Land: Island」「Huffington Post」など一部のHTML5アプリが検索で引っかかるようになっている。さらにFacebook社では、Apple社への配慮から、HTML5形式アプリだけでなく既存のネイティブiOSアプリ（iTunes App Store上で販売されるアプリ）へリダイレクト誘導する機能も提供している模様だ。
SNS最大手のFacebook社（本社：米国カリフォルニア州）は現地時間の10月10日、同社が会員ユーザー向けに公開しているiPhone版アプリを大幅アップグレードし、iPadにも対応した。
今回Version 4.0として公開されたこのiPhone／iPad版「Facebook」アプリでは、ここ半年ほどサードパーティ開発者たちの間で噂されていたHTML5アプリ配信サービス（コード名：Project Spartan）に対応。これにより、ゲームなどのアプリデベロッパーや一般のWebデザイナーが、iOS版Facebookユーザー向けに自作のHTML5アプリを配信・販売できるようになる。ただし課金システムは、Apple社の規約により、Facebook独自の「Facebook Credits」ではなく、Apple社のInApp課金を使う必要がある模様。
なお、すでに「Magic Land: Island」「Huffington Post」など一部のHTML5アプリが検索で引っかかるようになっている。さらにFacebook社では、Apple社への配慮から、HTML5形式アプリだけでなく既存のネイティブiOSアプリ（iTunes App Store上で販売されるアプリ）へリダイレクト誘導する機能も提供している模様だ。
ビューワ開発者から見た、電子書籍業界のいま 電子書籍覆面座談会
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も研究はしているでしょうが、今すぐ始められる状態じゃないわけで、その辺りが実際に立ち上がるのは来年、再来年といったところではないでしょうか。
―― 今年来年といわず、もう少し長いスパンで見ていく必要があるということですね。今日はありがとうございました。
電子書籍において、ビューワの操作性が読書体験に及ぼす影響は大きい。ユーザーとコンテンツの出会いを演出するのがビューワ開発者の力量だ。本企画では、電子書籍ビューワの開発者に集まっていただき、覆面座談会という形で電子書籍市場の今を聞いた。
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も研究はしているでしょうが、今すぐ始められる状態じゃないわけで、その辺りが実際に立ち上がるのは来年、再来年といったところではないでしょうか。
―― 今年来年といわず、もう少し長いスパンで見ていく必要があるということですね。今日はありがとうございました。
Kindle Fireの裏側
http://www.ebook2forum.com/members/2011/10/business-model-behind-kindle-fire/
アマゾンの新製品発表(9/28)に関して、同社のKindle事業担当デイブ・リム(Dave Limp)副社長（写真＝下）がシアトル・タイムズ紙に行っていたインタビューには、Kindle Fireに関して注目に値する論点が含まれていた。たとえば、$199という価格は「出血価格」ではない、EPUBはサポートしていない、OSは「Gingerbread (2.3)ベースのHoneycomb (3.0)変種」、iPadとは競合しない、Netflixアプリを搭載していること、などだ。アプリ内決済の問題など、iPadとの比較上問題となることは順次明らかにされていくだろう。
デバイスでもサービスでも利益を上げる
Fireの原価についてはiSuppliが部品ベースで約199ドルという推定を発表し、赤字はほぼ確実と思われているが、リムVPは、「それは私たちのビジネス観とは違う」と否定し、「デバイスでもサービスでも利益を上げ、それを持続可能にすることが株主に対する責任でもある。」とした。慎重な答えだが、これは
•採算ラインをかなり高く設定し（たとえば100万～200万台）
•台湾メーカーからの調達価格を他より安く抑えた
ことを意味しているものと考えられる。100万台以上をコミットすれば、部品ベースで100ドルに近いものとすることも不可能ではない。部品の中で最も高いのは液晶パネルとメモリだが、Fireのメモリは2GBと最低水準だ。2007年12月発売の初代Kindleでも利益は確保していたと考えられている。
「Gingerbread (2.3)ベースのHoneycomb (3.0)変種」
この表現は、オープンソースのAndroidを独自に拡張し、Googleがソースコードを公開していないHoneycomb相当品を開発したことを意味している。最新版ではないが、現在のAndroidアプリのほとんどが使用可能だ。リム氏も互換性を重視していると述べている。これは次のことを意味する。
•Googleのライセンス(統制)は受けず、互換性はアマゾンが保証する
•アプリ開発者はAndroidの開発環境をそのまま利用することが出来る
この「付かず離れず」というスタンスは、まだ成長途上のAndroid Marketに大きな影響を与える。膨大な顧客を擁するアマゾンの引力は大きく、開発者はGoogleよりもアマゾンを見て開発するようになる。それに、開発者はiPad (iOS)と同時に開発しなければならないから、Androidの方言には付き合いたくない。両手10本指(iOS)、片手2本指(Kindle)というタッチスクリーンの操作性の違いに対応するだけでも簡単ではない。
EPUBはサポートしない：外部環境・ファイルへの対応
外部ポートはUSB (とヘッドフォン端子)しかないが、という質問にリム氏は、Kindleと同様、Fireの外部接続はすべてUSBを通じて行うことを明らかにした。PCやMacと接続するとフォルダーが立ち上がり、他で購入したDRMなしのコンテンツ(たとえばiTunesの音楽ソース)をドラグ＆ドロップで移せばFireで再生することが出来る。これはローカルだけでなく、クラウドでも対応する。他のデバイスのMP3音源や画像はこうして保存・利用することも想定されているようだ。
ではE-Bookはどうか。「EPUBはサポートするのか」という質問に、リム氏は「当社はサポートしない。」と答えた。これでアマゾンがEPUBをサポートするのではという観測は否定されたことになる。その代わり、デスクトップ級の強力なPDFエンジンを搭載し、書籍・雑誌に対応する。これを解釈すれば、アマゾンの認識は次のようなことであろう。
•今後ともEPUBファイルを受け入れ、自社でKindleコンテンツ化する
•商業的コンテンツは、ほとんどすべてがKindle対応になっている
•EPUB仕様は、実用上問題のない範囲でKindleフォーマットに吸収可能
周知のように、EPUB仕様はHTML5/CSS3を土台としたEPUB3に移行しつつある。通常の欧文書籍に関する限り、EPUB2とKindleが使っているMobiの違いは僅かで変換も可能だが、たとえば日本語組版を含めたEPUB3をサポートするとなると、Mobiもそれに対応した拡張を実装する必要がある。アマゾンはEPUB3対応の実装をすでに行っている可能性が高い。つまり、Acrobat PDFではない独自のPDFビューワでいくPDFの場合と同様、EPUB 3対応のエンジンをを開発してサポートするということだ。
出版社にとっては実質的な影響はない。アマゾンの独自仕様を気にする必要もないだろう。つまりアマゾンの独自フォーマットは、著者・出版社・読者がいちばん気にする文書構造の記述と表現に関することではなく、独自のWhisper Syncや図書館からの借り出し、DRM認証、SNSなど、もっぱらサービス・インタフェースに関連するものなのだ。アマゾンのロックインの仕掛けは巧妙だ。
アプリ開発者への条件提示は近日発表
Kindle FireとiPadの違いは、iPadがPCを代替することも可能な全方位タブレットであるのに対して、Fireはもっぱらメディア・コンテンツの消費に特化しているということだ。リム氏はそれが$500と$200という価格の違いでもあり、「おそらく比較の対象にはならない」と述べている。もちろん、額面どおりに受け取る必要はない。Fireは現在のiPadの用途の大半をカバーしているからだ。Fireはフルブラウザとメールソフトを搭載し、メールソフトではWordとExcelファイルを読むことが出来る(PowerPointは不明)。
外部のネットサービスとの関係では、Netflix、Pandora、Facebook、Twitterに関してはアプリの搭載で合意した、としているがその他については近日中に明らかにされるという。つまり有償サービスを受け入れる場合には売上の一部をシェアするのだが条件はまだ提示されていない。アップルiOSでのアプリ内決済を経験したアマゾンが、どんな条件を提案するかが注目される。
アマゾンの新製品発表(9/28)に関して、同社のKindle事業担当デイブ・リム(Dave Limp)副社長（写真＝下）がシアトル・タイムズ紙に行っていたインタビューには、Kindle Fireに関して注目に値する論点が含まれていた。たとえば、$199という価格は「出血価格」ではない、EPUBはサポートしていない、OSは「Gingerbread (2.3)ベースのHoneycomb (3.0)変種」、iPadとは競合しない、Netflixアプリを搭載していること、などだ。アプリ内決済の問題など、iPadとの比較上問題となることは順次明らかにされていくだろう。
デバイスでもサービスでも利益を上げる
Fireの原価についてはiSuppliが部品ベースで約199ドルという推定を発表し、赤字はほぼ確実と思われているが、リムVPは、「それは私たちのビジネス観とは違う」と否定し、「デバイスでもサービスでも利益を上げ、それを持続可能にすることが株主に対する責任でもある。」とした。慎重な答えだが、これは
•採算ラインをかなり高く設定し（たとえば100万～200万台）
•台湾メーカーからの調達価格を他より安く抑えた
ことを意味しているものと考えられる。100万台以上をコミットすれば、部品ベースで100ドルに近いものとすることも不可能ではない。部品の中で最も高いのは液晶パネルとメモリだが、Fireのメモリは2GBと最低水準だ。2007年12月発売の初代Kindleでも利益は確保していたと考えられている。
「Gingerbread (2.3)ベースのHoneycomb (3.0)変種」
この表現は、オープンソースのAndroidを独自に拡張し、Googleがソースコードを公開していないHoneycomb相当品を開発したことを意味している。最新版ではないが、現在のAndroidアプリのほとんどが使用可能だ。リム氏も互換性を重視していると述べている。これは次のことを意味する。
•Googleのライセンス(統制)は受けず、互換性はアマゾンが保証する
•アプリ開発者はAndroidの開発環境をそのまま利用することが出来る
この「付かず離れず」というスタンスは、まだ成長途上のAndroid Marketに大きな影響を与える。膨大な顧客を擁するアマゾンの引力は大きく、開発者はGoogleよりもアマゾンを見て開発するようになる。それに、開発者はiPad (iOS)と同時に開発しなければならないから、Androidの方言には付き合いたくない。両手10本指(iOS)、片手2本指(Kindle)というタッチスクリーンの操作性の違いに対応するだけでも簡単ではない。
EPUBはサポートしない：外部環境・ファイルへの対応
外部ポートはUSB (とヘッドフォン端子)しかないが、という質問にリム氏は、Kindleと同様、Fireの外部接続はすべてUSBを通じて行うことを明らかにした。PCやMacと接続するとフォルダーが立ち上がり、他で購入したDRMなしのコンテンツ(たとえばiTunesの音楽ソース)をドラグ＆ドロップで移せばFireで再生することが出来る。これはローカルだけでなく、クラウドでも対応する。他のデバイスのMP3音源や画像はこうして保存・利用することも想定されているようだ。
ではE-Bookはどうか。「EPUBはサポートするのか」という質問に、リム氏は「当社はサポートしない。」と答えた。これでアマゾンがEPUBをサポートするのではという観測は否定されたことになる。その代わり、デスクトップ級の強力なPDFエンジンを搭載し、書籍・雑誌に対応する。これを解釈すれば、アマゾンの認識は次のようなことであろう。
•今後ともEPUBファイルを受け入れ、自社でKindleコンテンツ化する
•商業的コンテンツは、ほとんどすべてがKindle対応になっている
•EPUB仕様は、実用上問題のない範囲でKindleフォーマットに吸収可能
周知のように、EPUB仕様はHTML5/CSS3を土台としたEPUB3に移行しつつある。通常の欧文書籍に関する限り、EPUB2とKindleが使っているMobiの違いは僅かで変換も可能だが、たとえば日本語組版を含めたEPUB3をサポートするとなると、Mobiもそれに対応した拡張を実装する必要がある。アマゾンはEPUB3対応の実装をすでに行っている可能性が高い。つまり、Acrobat PDFではない独自のPDFビューワでいくPDFの場合と同様、EPUB 3対応のエンジンをを開発してサポートするということだ。
出版社にとっては実質的な影響はない。アマゾンの独自仕様を気にする必要もないだろう。つまりアマゾンの独自フォーマットは、著者・出版社・読者がいちばん気にする文書構造の記述と表現に関することではなく、独自のWhisper Syncや図書館からの借り出し、DRM認証、SNSなど、もっぱらサービス・インタフェースに関連するものなのだ。アマゾンのロックインの仕掛けは巧妙だ。
アプリ開発者への条件提示は近日発表
Kindle FireとiPadの違いは、iPadがPCを代替することも可能な全方位タブレットであるのに対して、Fireはもっぱらメディア・コンテンツの消費に特化しているということだ。リム氏はそれが$500と$200という価格の違いでもあり、「おそらく比較の対象にはならない」と述べている。もちろん、額面どおりに受け取る必要はない。Fireは現在のiPadの用途の大半をカバーしているからだ。Fireはフルブラウザとメールソフトを搭載し、メールソフトではWordとExcelファイルを読むことが出来る(PowerPointは不明)。
外部のネットサービスとの関係では、Netflix、Pandora、Facebook、Twitterに関してはアプリの搭載で合意した、としているがその他については近日中に明らかにされるという。つまり有償サービスを受け入れる場合には売上の一部をシェアするのだが条件はまだ提示されていない。アップルiOSでのアプリ内決済を経験したアマゾンが、どんな条件を提案するかが注目される。
登録:
投稿 (Atom)