緊デジ事業とEPUB制作環境

メディアシステム・ディレクター／グラフィックデザイナー
深沢 英次 氏

緊デジ事業とは?

去年1年間、出版デジタル機構に依頼されて、経産省の補助金事業を手伝い、緊デジで作る電子書籍の仕様書を書いた。その性格とか権利のシステムなどを作ってきた。今日はその経験をもとに話したい。

緊デジは「コンテンツ緊急電子化事業」が正式名称である。「電子書籍事業の拡大及びそれに伴う被災地域の知へのアクセスの向上に向けて、書籍の電子化作業に要する制作費用を国が補助する」ものである。

実際何をやったかというと、大手から中小、零細までの出版社にタイトルを出してもらう。最終的に出版社は総数300社くらいになったと思うが、各制作会社に、紙の本を電子化してくれと依頼する。
制作会社は、もちろん凸版、大日本もメインになっていたが、2、3人規模の制作会社も数多く、最終的には合計で90社程度の制作会社に依頼して、1年間で約6万タイトルの電子書籍を制作した。6万はタイトル数で、ファイル数にすると約8万になる。日本で今まで作られた電子書籍の数としては、おそらく最大規模の作業をしたのではないかと思う。

経産省から最初に提示があったとき、「総額20億円の事業で、1年間に6万冊の電子書籍を作る。そのうち10億円を国が補助する」といわれた。残額の10億円はそれぞれタイトルを出す出版社が負担するか、もしくは出版デジタル機構が代理店として立て替え払いをして、後から売上金で返済していくビジネスモデルであった。

総額20億円で6万冊という制作費の提示があったわけだが、そうなると1冊あたり33,333円になる。この金額をベースに、「これで電子書籍をどうすれば作れるのか考えてくれ」といわれた。

具体的な電子書籍の制作費用

緊デジは去年の春から今年の春までの1年間だったが、以前の電子書籍作りは1冊あたり一体どのくらいかかっていたのか調べた。特に電子書籍を専門にやっているところとか印刷会社とか、あちこち聞いて回った。
もちろん出版社との関係、大量にやっているところ、少部数を手作業でやっているところ、コンテンツにもよって大いに差がある。それでも大まかな相場はわかった。200ページのコミックをドットブックで作った場合の費用だが、フィックス型という1ページずつスキャンして1マスにする電子書籍だと、原稿を1枚ずつスキャンするのに大体1ページあたり500円かかる。スキャンした画像をレタッチしてゴミ取りやモアレの処理をすると、大体500円かかる。そうなると、1ページ1,000円、200ページだとそれだけで20万円かかる。
それをさらにドットブックとしてひとまとめにするのに、ドットブックの制作料金は大体5万円くらいとっている。もっと安いところも、もっと高いところもあると思うが、フィックス型の場合、私が聞いたところでは大体25万円かかるのが多かった。

それではリフロー型といわれるテキストを使った電子書籍はいくらかかるのか。300ページのXMDFを作ってみた場合、電算写植からのデータを持ってきて、それをXMDFに変換、制作をする。もしくはDTPのデータから取ってきて作る。XMDFの制作は、目次もタイトルも見せ方が全部一からやり直しになるので、20万円くらいかかる。
作ったものが、テキスト全くそのままではなく、電算写植から持ってくると約物などはほとんど使いものにならない。ルビもほとんど消えてしまったりするので、校正は必須である。編集者が校正をしてくれれば、この部分の金額はかからないが、普通に校正会社に出すと、本1冊、小説1冊で最低でも15万円かかるのが相場である。

両方見てみると、コミックだろうが小説だろうが、どちらも数十万円の単価がかかってしまう。そこに歴史小説などで外字の制作がたくさん出てきたり、中国ものの文字がたくさん出てきたり、目次のリンクがものすごく多くてリファレンス的になっているような作業があると、どんどん値段が追加されていく。

また、書籍のDTPデータから容易に持ってこられることはほとんどなく、DTPデータが古いと、そもそも開きようがない。また、電算写植のデータも、例えば8インチのフロッピーしかないという話になると、どこでも作れるわけではない。そうなってくると、書籍を見ながらもう一度入力し直すとか、OCRでスキャンしたものを自動読み取りさせることになるが、そうするとそれにももう1回校正が必要になってきて、とにかくテキストを作るだけで数十万円の金額がかかってしまう。

先ほどの33,333円という金額は、もう全然話にならない。この金額が経産省から提示されたが、実際どうすればいいんだという、そこから我々は仕事を始めた。まず、「どこでこの金額が出てきたのか」をいろいろ聞いてもらったが、お役所の中の話なので、結局よくわからない。

自炊の現実に向き合って行う電子書籍化

いろいろな人に聞いたところ、いわゆる自炊の影響があったのではないかと想像できる。自炊というのは、本を断裁機で、背の部分を切り落とし、ドキュメントスキャナで自動スキャンし、そのページ画像をPDFに自動化でまとめてしまうものである。

iPadが出てきてから自炊がブームになって、自炊を代行する業者も出てきて、出版業界や著作権者とひと悶着あったのは、皆さんもご存じだと思う。この自炊代行業者が一時期増えたので、そういうところに本の電子化を依頼すると、大体200～300円でやる。安いところになると100円でやるところもある。

自炊業者を、何軒か訪ねて回って、どういうやり方をしているのか、話を聞いた。自分たちでシステムを組んで、スキャンの精度とか、スキャナを徹底的にカスタマイズしたり改造したりして、プログラムも自分たちで全部作り、品質を高めて書き出す解像度を何パターンも選べるようにしていた。そうやって1冊あたり200円、300円の電子化されたPDFを作っている。

やっているところは、年間数億の売り上げや利益を出している。通常注文しても、自分の本を電子化してくれるまでに3ヵ月かかる。そんな中にあって、人気のある本とちょっとした代行業者は、自炊をやっているところがあると思う。ユーザーも、「これで十分じゃないか」と思った人も多かったのである。
それが正しいとか正しくないとかではなく、ユーザーのニーズがそこにあった。ただ、自炊はあくまで自分でやるから自炊なので、他人がやったら他炊になってしまう。他炊になってしまったら、もうそれは日本の法律では違法である。

先日も、東京地検で判決があったが、いまだに業者と著作権者の争いはずっと続いていて、当分、明確な答えは出ないだろう。自炊が必要とされないように、出版社が自分たちで電子化しなければいけないという機運があったのではないかと思う。

自炊の電子書籍であれば、制作費3万円の必要はない。そこで我々は全体のコストを考えたときに、ある程度自炊のようなドキュメントスキャナを使ったフィックス型の電子書籍を一定数作れば、安いものができる。それで済むものもあるだろう。しかし、ちゃんとしたテキストを使ってリフロー型で1冊何十万円もかけてやらなければいけない電子書籍もある。

それなら、質を求められる売れそうなコンテンツは、リフロー型で作っておいたほうがいい。売れ行きだけではなくて、これは出版社として、読者としてもすごく重要だとか、出版業界全体として価値があるコンテンツを選んでリフロー型を作っていく。リフロー型の数は少なく、フィックス型を大量に作ろうと計画した。

選択肢はリフロー型とフィックス型

緊デジの事業は今年の春でほぼ終了したが、正確な数字は公開されていない。そこが非常に不満である。実際に聞いたところでは、リフローが25％、フィックスは75％が最終的な割合だったという。4分の3はフィックス型で、要するに自炊のようにドキュメントスキャナを使って作ったものである。

その中にはコミックもかなりの数入っているが、それだけではない。レイアウトの複雑なものとか、カラーの図版があるもの、ハウツーもので写真を挟んでいくものはフィックス型になっている。
一昨年の秋ごろ最初に緊デジを始めたときは、「フィックス型はPDFでいいのではないか、リフロー型はEPUBでいいのではないか」と比較的軽く考えていた。
「とりあえずPDFでいいだろう」と思っていたが、いろいろリサーチしてみると、電子書籍の書店から「PDFを売るのは勘弁してくれ」といわれた。書店は大体自分たちのお抱えのビューアを持っている。そのビューアの中で課金したりDRMといってセキュリティをかけたり、コンテンツのコントロールをしている。
ところが、PDFになってしまうと、ビューアがなくても読めるので、「ビューアの中で読ませるのが自分たちの商売なのに、それが成立しなくなってしまう」という話が書店からあった。

制作する側からは、「PDFにするのは自炊みたいな形でできるし、テキストものであってもDTPデータをフォント埋め込みの形でできるが、その後に解像度や文字を修正するのは非常に大変だ」といわれた。
また出版社からは、「PDFで作るのはいいかもしれないが、将来的に別の展開ができるのか。PDFでテキストを取りだすことはできるのか」という話があった。それを、いろいろ試してみるとやはり無理である。特に、縦組のPDFから取りだすのはほとんど不可能に近い。もちろん、画像の入るものも、テキストはそこにはないし、OCR化したとしてもそのまま使えるレベルではない。

PDFは完全なマイナーになってしまうので、部分的な修正もしにくい。それに対して、ドットブックとかEPUBは、中身はテキストとJPEG画像なので、何か入れ替えするとか変更するとき、特に専用のツールも必要ない。そういう意味では楽である。お店でも売ってくれないし、PDFは諦めようということになった。PDF自体には利点がたくさんあったと今でも思っているが、わりと早い段階で緊デジのフィックス型からはPDFを外した。

リフローは、その当時「これからはEPUBだ」という話があったが、去年前半の段階でも日本語縦組のEPUB3を表示できるビューアやそれを売ってくれる書店は皆無だった。

EPUBを見据えた「XMDF」「ドットブック」

緊デジは期間が1年限定で、それまでに作れなかったものは予算として消化できないので、無駄になってしまう。EPUBの環境が整うのを待っていることはできない。
そのために、とにかく今すぐに作れるもの。実績があって、売ってもらえるものを考えて、残ったのがXMDFとドットブックの2つになってしまった。

最初に私は「PDFとEPUBでいい」と考えたが、結局、XMDFとドットブックになった時点で、頭を抱えてしまった。しかし、逆に制作側からは、「新しいものや難しいことをやらずに、今までどおりにやればいいのだから、それでいい」という声もあった。

ただ、将来性はやはりEPUBにあると思っていたので、市場でEPUBが動き出したらすぐにEPUBに変更できるような、XMDF、ドットブックを作ろうと考えた。先ほども言ったように、EPUBやドットブックの中身はタグを付けたテキストとJPEGの画像ファイルなので、変更が比較的可能だろう。
制作途中の素材も一緒に納品してもらえば、EPUBが始まった時点ですぐに切り替えたり、追加で一緒に作ることも可能になるから、電子書籍の計画を開始した。それが去年の4月頃である。

苦労したフィックス型における見開き

タイトル募集して、出版社に声をかけたが、なかなかうまくいかない。タイトルを集めるのも問題があったし、制作もトラブルが続いた。私の認識にも甘いところがあった。
テキストを扱うようなリフロー型に比べたら、スキャン画像を並べただけのフィックス型は、自炊でもやっているくらいだから作るのは簡単だと想像していた。

しかし、今振り返って全体を通してみると、実際のトラブルは、フィックス型のほうが圧倒的に多かった。制作コストが明らかに限られているので、結局手の打ちようがない。
フィックス型のどころが苦労したかというと、見開きである。リフロー型の電子書籍は巻物のようなもので、テキストがずっと流れていて、右ページとか左ページという見開きの概念がない。左右のページを見開きで表示するという指定ができなかったし、できても無視されたことがあった。

ところが、絵本やコミックを扱うようになると、この画像はどうしても見開きで見せないと意味がなくなるものや、書籍として成立しないものが出てくる。電子化してXMDFとかドットブックで作ってビューアで見てみると、ずれてしまう。どうしてもきれいにならない。いろいろ指定を変えてみたり、テストしても見開きにならないことが、あちこちでたくさん出てきた。

今はもう見開きで電子コミックを見るのは当たり前に扱われているが、3年前にiPadが出るまでは、電子書籍に見開きの概念はほとんどなかった。例えばリブリエとかソニーリーダーとか、その当時の電子書籍は大体ガラケーベースだった。

当然、横文字だけだったが、キンドルも、横位置にしても見開きにはならない。ただ単に横になるだけである。電子ペーパーのデバイス、KoboタッチとかKoboグローとかキンドルペーパーホワイトはいまだに横にしても見開きモードにはならない。タブレット型のものは、Androidも見開きになるようになった。

少し古い話をすると、パナソニックが10年くらい前にシグマブックという電子書籍のデバイスを出していた。シグマブックには液晶が2つ付いていて見開きになった。あれはあくまでも液晶を2つ使ってというところがミソだった。覚えている人は、多分ほとんどいないだろう。そのくらい日本では電子書籍の見開きは冷遇されていたし、基本的にちゃんと考えられていなかった。

また、見開きの他にも、余白の扱いがデバイスによって違う。フィックスの場合はページすべてが底本をスキャンしたものなので、余白は既に入っていて、さらに付ける必要はないが、リフローの場合は版面に対して余白を指定しなければいけない。

余白を考えたときに、マージンを制作時にコントロールするべきなのか、ビューアとかデバイスがコントロールするべきなのか。それともユーザーがコンテンツに合わせて見るときに自分で設定をするべきなのかは、いまだに決まっていない。

だから、自分が読むデバイスによって、同じコンテンツであっても余白が付いたりなかったりしている。余白があると、その分文字が小さくなるので、余白をできるだけ減らしたいという考え方もあるし、余白がないとデザインがおかしいという考え方もある。

リフロー型における校正や外字のトラブル

リフローの場合のトラブルは、校正とか外字のところである。校正や外字の問題なら、校正をもう1回入れるという想定が入っている。だが、見開きがつながらないとか、真ん中のノドのところを断ち落とし過ぎて広くあいてしまうといった問題があった。解像度やデバイスによってはぼけてしまい、ルビや図版の中のキャプションが読めなくなった。ほかにもカラーの色味がおかしいとか、写真の色がおかしいとか、古い本なのでシミがたくさん残っているといったクレームが出版社や営業からものすごくたくさんきた。

そもそもは、自炊レベルのものを想定していた。カラー写真ページと文字だけのページを1枚ずつスキャンを分けて、それぞれ設定を変えれば当然それなりのものになると思うが、断裁時に一度にやるので、どちらかに合わせなければいけない。そうでなければ中間に合わせる。それを写真の部分だけ選んで色を調整し直すとか、文字の部分だけコントラストを上げるなどとやっていたら、3万円の金額ではとても足りない。

そのコストを用意することができないので、トラブル処理に手間がかかった。結局は、「そういうものなのだということで納得してもらうしかない」といったが、なかなか首を縦に振ってくれない人もいて、このトラブル処理は今思い出してもやりたくない。

電書協が発表したEPUB3の制作ガイド

また、XMDFとドットブックを作ったが、XMDFにはバージョン2と3があり、使われているのはZDFというバージョン2である。LVFというバージョン3は数年前に出たが、ほとんどビューアに組み込まれていないので、バージョン3のXMDFが見られるビューアは書店にもいまだにほとんどない。ガラパゴスではないか。

我々はバージョン2で制作を始めたが、バージョン3でないと見開きとか目次も指定できないといわれてしまった。見開きには何とかなるが、ちょっとした都合でそれがおかしくなったときに、バージョン3ならちゃんと直せても、バージョン2は直してもいないし、これから直す体力もない。もうサポートも終わるようなものに対して修正をかけることはできないということだった。

そんなこともあったので、フィックスのXMDFは制作して2ヵ月くらいで緊デジの中では辞めた感があった。これはあまり正式なアナウンスはしていなかったが、XMDFはリフローだけにして、フィックスはドットブックに回して制作を続けた。それが去年の夏くらいである。

その頃、楽天からKoboが発表された。ネットでもKoboはサービスのやり方が叩かれて炎上したりしていたが、Koboそのものに対しては出版社や制作側からの評価は悪くなかった。EPUB3は何とかこれでいけそうだということがちょうど見えてきた時期でもあったし、発売のすぐ後に電書協、日本電子書籍出版社協会からEPUB3の制作ガイドが発表された。

それまでEPUB3の記述ルール、書き方のようなものは、イーストとかボイジャーなどあちこちが提案していた。しかし、どうも出版社が考えるのはどれも自分たちの望むものと違う。

出版社としてはいくつも出てこられると困るので、自分たちのルールを作り、一つの方式でやりたい。だからどこの書店でも同じように表示して売って欲しいと明言して、そのためのEPUB3の制作ガイドを発表した。

具体的には角川、講談社、それからデジタルコミック協議会にいた集英社などが中心となってEPUBの書き方を作った。このEPUBガイドができたので、緊デジで検討して、「これはいい、これでやろう」と決めた。

今後の流れはEPUBになる

EPUBに切り替わっていくきっかけとなった電書協ガイドの最新版は、今でもサイトからダウンロードできる。
最大の特徴はRS(リーディングシステム)を絞り込んだところにあると私は思う。リーディングシステムというのはビューアのエンジン部分である。それまでEPUB3のRSにはウェブキット系列のものとRMSDK系列のものがあって、それぞれに表示結果が少しずつ違う。厳密なものを作ろうとすると、それぞれのために別のものを作らなければいけなかった。このEPUBはウェブキット用なら表示できるが、RMSDKのソニーリーダーに表示ができないがiBooksでは表示できることがあったので、両方をやろうとしてもなかなかできなかった。

電書協ガイドは、その解決を自分たちでやろうとするのをやめて、RMSDKを切ってしまった。これはものすごく大きな決断だったと思う。RMSDKのソニーとかアドビは出版社の中にもつながりがあるところもある。切られるほうだって指をくわえて見ているわけにはいかないので、いろいろあったと思う。
しかし、とにかく「これからの私たちが作るEPUBはウェブキットベースで、ウェブキットに合わせて作る」と宣言した。

その他に独立系として、紀伊国屋のキノッピーとか一番大きなアマゾンのキンドルもあるが、実際に表示させてみると、キンドルやキノッピーはほぼウェブキット互換みたいな感じで比較的近い。そんなに大きな変更をしなくてもなんとかなりそうだと、電書協ガイドベースと切ってしまう形に出版社の総意で決めた。

現在でも、電書協ガイドで作った、緊デジで作成のEPUBはソニーリーダーでは開かない。それはソニーリーダーのメモリの扱い方もある。先週新しいものが出たが、そちらはどうなっているか、まだチェックしていないのでわからない。しかし、先週まで売られていたソニーリーダーでは開かない。

また、RMSDKが今後どうなるのか、あまり大きな声ではいえないようなことも聞こえてきている。「どうも開発者たちはウェブキットのほうに流れていくのではないか」という話をぽつぽつ聞く。

ただ、彼らも最初は「自分たちのほうが正しいはずだ」と頑としてやっていたが、「もう電書協ガイドに合わせたものがメインとして出てくるのであれば、ある程度自分たちも我慢してそれに合わせなければいけない」という方向に進んでいるという話は聞いている。

最初に電書協ガイドが出たときは、リーディアムとか紀伊國屋とか、有名なビューアも完全に電書協ガイドをきれいに表示できるわけではなかった。ガイドをきちんと出したことによって、早く対応をしていただけたと思っている。

特にアマゾンのキンドルとかアップルのiBooksも電書協ガイドの発表の後に出てきたが、全然問題ないようになってきている。細かいところはあるが、大きな作り方としては当初の目的に達しているのではないか。

今後の流れは必ずEPUBなので、EPUBで電子書籍の制作をしていこうと考えるのであれば、この電書協ガイドを丹念に読み込むことが、今、日本の電子書籍で何ができて何ができないのかを理解する近道だと思う。

電書協ガイドのCSS

電書協ガイドの中には、リフロー版のサンプルの中のスタイルシートという、レイアウトを決めるファイルがあるが、そこにはいろいろな項目が設定されている。スタイルスタンダードCSSはソースコードが1672行という、CSSファイルとしては壮大なファイルになっている。

普通、スタイルシートはWebでも電子書籍でも、そのコンテンツの中で使う指定だけが規定される。しかし、電書協ガイドのCSSは、とにかく使いそうなものを全部書いてある。本を作る側は、その中から選んで適用していくだけである。そのためにCSSファイルが大きくなっている。

この方法だと、ビューアとしては、実際に書籍の中で使用している項目はわずかなので、使う設定を最初に読み込んで理解しなければいけない。そのためにメモリがパンクしてしまうので、無駄が多くて、「こんなやり方はやめてくれ」というのが多かった。

作る側としては、用意してあるものをいちいち自分たちでカスタマイズしなくても、その中から選んで適用していくだけでよく、制作が楽になるので、最終的にはビューア側が折れた。

今後はメモリもだんだん増えていって、多少無駄なものも許容していかなくてはいけないのではないか。現在のEPUB3ビューアでは大体この長いCSSを最初に読み込んで表示できるようになっている。

DTPや出版、Webをやっている人はわかると思うが、ここで規定されているものが今の電子書籍では安心して使えるという項目である。逆に言うと、ここに載っていないものは危ない。何とか表示できたとしてもお勧めしないということである。

どんなものがあるかというと、段組とか表組。表組というのはEPUBの中で表示できる。ただ、同じような表示になるか、こちらのビューアによって表示の仕方が全然違うとか、あとは文字のセンター揃えができない。中扉などで、真ん中の1行だけ縦のタイトルがある場合、今のEPUBではものすごい裏技を使わないと表示できない。

もちろん特定のターゲットを絞って細かく自分でカスタマイズしていけば、そういう組版を実現することは可能である。動画を埋め込んだり、インタラクティブな仕掛けをする先駆的な、実験的な電子書籍が商品価値を高める傾向も当然あるので、それ自体やってはいけないとか悪いことだというわけではない。

ただ、そうやって作られたEPUBは使い回しがきかない。他のビューアとか販売店で売ってもらえないことがある。あとはビューアがアップデートしたり、OSがアップデートすると開けなくなることも出版社側がなかなか理解できていない。

制作者側も出版社側も、それをとにかく共通の理解としていくべきだ。特に制作者の人たちは、できないといわれると何とか無理をして裏技でも実現してしまおうとすることがあるが、お互いにとって不幸な結果を招くことになるので注意したほうがいい。

EPUB制作のために必要なスキルとは

それでは、EPUBを作るとき、制作する人にはどういうスキルが必要になるのかというとが、EPUB制作の基本的なスキルはWebデザインのスキルとほぼ同じだと思う。逆にDTPのスキルとはかなり考え方が違うので苦労が多いが、Webのスキルは、具体的にはXHTMLとスタイルシート、CSSのスキルである。XHTMLとCSSを理解できないWebデザイナーはほとんどいないだろう。そういう人であれば、EPUB3は中身がわかって、作り直しができると思う。

おそらくWebで今流行り出したHTML5のサイトを作るのに比べたらEPUB3の電子書籍を作るのは簡単である。ただ、DTPしかやってきていない人は、一からそういうことを理解するというのは難しいかもしれない。
だからといって、例えば「テキストを読み込んでクリック一発でEPUBを書き出せる」というツールやサービスもあちこちから出てきているが、最初にそういうものを使って覚えるのはあまりお勧めしない。少なくともXHTMLとかCSSについて、テキストエディターを開いてコードを自分で追いかけてということをやった経験がなければ、全く応用がきかなくなってしまうと思う。

DTPではInDesignやQuarkXPressといった専用ツールがあり、使い方さえ覚えてしまえば、ある程度の制作は可能だった。しかしWebでは、CMSというサイト構築システムを使って作ることが最近増えている。そのデザインをするにしても、テンプレートのデザインをするにしても、ほとんどのデザイナーは専用ツールを使わずに、設計図を文字で追いかけて、コードを自分で書いてはビューア、ブラウザで確認することを繰り返してやっている。

中にはDreamWeaverのようなものもあるが、ハンドコーディング、手作業によるコード記述の補助作業をするためのツールである。そこでDTPのように画面で作っておいてWYZIWYGの考え方でボタンを1つ出せばEPUBができることをやってしまうと、最終的にはツールに全て託さざるを得なくなってしまう。

Webの世界にも専用ツールはたくさんあるが、あまり使われていない。ハンドコーディングをやったほうが実は効率的で融通が利くからである。Webの場合はしょっちゅう仕様が変わって、ビューアとかブラウザも変わるしルールも変わる。そのたびに新しいツールが対応するのを待っていたら商売にならない。どんなものが出てきても自分たちの技術で、テキストエディタとPhotoshopくらいあれば何とかなるというような制作環境を作ってきた。

EPUBの制作環境とビューア

また、制作環境に左右されるのがDRMの存在である。
XMDFとかドットブックは電子書籍ファイルを形作るときに制作時にDRMも書く。それに比べてEPUBは作るときにはDRMは一切関係ない。作り上げたものにはDRMがないものがある。DRMはどこでかけるかというと、それを受けとって売る人が売るときにかけるという考え方である。

XMDFやドットブックは専用のライセンスとか専用のリーダーが必ず必要になるが、EPUBは必要ない。誰でも、何のツールもなくても、テキストエディタと、あとはまとめるような圧縮ソフトと画像を扱えるソフトがあれば作ることができる。それで作ったものを受け渡しするので、逆に実機での検証も楽にできる。

ドットブックやXMDFを作った場合、実機での検証は非常に大変である。XMDFで作ったものを実機で検証したいと出版社からいわれても、もうどうしていいのかわからないくらい、大変である。できなくはないが、裏技に次ぐ裏技のような感じになってしまう。一般の人ができるレベルではない。

それに対してEPUBは、EPUBファイルを作ったら、複数のビューアで開いて見ることができる。ただ、専用ツールが不要で制作環境がWebに近いといっても、WebよりもEPUBのほうが定型的な繰り返し作業が圧倒的に多いので、スクリプトとかマクロ等を使った自動化は効果的である。テキストを一からというのは、考え方とか作り方を覚える上では重要だが、実際に日常の業務の中でEPUBをやるときは、スクリプトを活用して自動化をいろいろなところで考えていくことが必須になってくる。

ただ、スクリプトはプログラムなので、書ける人、書けない人、得意不得意がある。いちいち自分たちでプログラムを書いているのは難しいときは三陽社の田嶋さんが作ったスクリプトファイルや、プログラマーの大江さんが作った「電書ちょこっとツールズ」があって、検索すればすぐにヒットする。

このように、ネットを手繰っていけば便利な自動化のツールがたくさんある。特にEPUB専用ソフトを買わなくても何とかできてしまうので、逆に効率的ではないか。
画像はPhotoshopでいいとして、あとはテキストエディタと、ツールを探して作るので十分だと思う。ただし、作ったものはしょっちゅう確認、検証しないと最後は進まない。検証には必ずビューアが必要である。

検証環境だが、ここで使用するEPUBビューアは表示結果に信頼性がないといけない。標準的なビューアとして、リーディアム、iBooks、Kobo、キンドル、キノッピーという5つを用意しておくといいと思っている。
これらのビューアは、その内部とかショップで購入した電子書籍ではなくても、自分が作ったEPUB3のファイルを送り込んでダウンロードして開くことができる。XMDFやドットブックのときはそれができなくて苦労した。
ビューアを厳密にいうと、Koboもタッチ、グロー、iOS、Androidとあるし、キンドルにもペーパーホワイトとかファイヤー、HD、それからPC上のキンドルプレビューアなど、それぞれがいろいろ違う。1つを見ればいいというわけにもいかないが、ある程度、大きな傾向は見られる。全部を揃えるのはなかなか難しいと思うので、自分の手元におけるもの、Mac1台とiPadがあれば、この5つは大体できる。

それにさらに追加するなら、ネクサス7のAndroidくらいで大体いいのではないか。MacではなくWindowsでもいいが、電子書籍とかDTPの環境はMacのほうが揃っているのでやりやすいと思う。

そういうものを使って、実際の制作はコードを見ながら直してやるので、リーディアムを使うことがメインになる。作業が完成したら、例えばPC上のキンドルプレビューアとかiPad、iBooks、キノッピーなどに送り込んで確認するといい。実機なら最悪の場合クライアントに見せることもできるので、話が早くなることもある。

ただ、どれも今の時点では印刷はできない。そこが今EPUBの校正とか確認でネックになっていて、スクリーンキャプチャを苦労して1枚ずつとってまとめている人もいるが、スクリーンキャプチャと印刷では見た目も違う。
アドビのデジタルエディションなどは印刷の機能がある。そちらで電書協仕様の本も読めるようになれば、使えると思うが、まだそこまでなっていない。

EPUBでできることできないこと

電書協ガイドにとっては、EPUBはできないことがたくさんある。やってしまうと結局こちらの書店では売れなくなるとか、こっちのビューアでは見られなくなるとか、それを全部調べていくのも煩雑な作業になってしまう。
先ほど、検証ビューアのところでそれぞれに細かな違いがあるといったが、田嶋さんの電書魂の中ではEPUBビューア別表現チェック表を公開している。また、電流協もEPUBビューアのそれぞれの機能や見え方の違い、「外字はこれだときれいに出るがこっちはだめ」といったものを公開しているので、情報を集めてみるといい。

EPUBには、まだできないことがたくさんある。ドットブック、XMDF、PDFではもうできたものが、EPUBではまだできないことが実はたくさんある。さまざまなビューアが出てきたときに共通で考えると、どうしてもレベルの低いところに合わせざるを得ない。トラブルがないように考えていくと、本当にシンプルなもの、簡単なものに揃ってしまう。
ただ、現状、書籍コンテンツの場合は、細かなレイアウトの微妙な違いとか再現性よりも、読者が求めているもの、読んで面白いかどうかが第一義である。現在の電書協ガイドでも文庫本とか新書と同等の表現力は十分あるので、今はまだあまり無理なことをせずに、コンテンツ自体を増やす時期だと思っている。

著作権の管理やテキストの保存管理が重要

DTPや組版をずっとやってこられた人たちからは嫌がられるが、少し前に携帯小説があった。一時期はベストセラー上位の半分以上を占めるようなときもあった。
ガラケーの携帯小説は、カタカナは半角だし、禁則処理はできないし、句読点とか閉じ括弧が行頭に来たりして、組版とは呼べない。まともにこれを書籍や小説といえるのかという話があったが、それでもそのコンテンツを中学生、高校生は毎日読むのを楽しみにしていた。

一時は携帯小説だけで100億円以上といわれるくらいの市場を作ったりした。スマホやタブレットが出てきたことで携帯小説は下火になった。振り返ってみると、今あまり細かい組版にこだわって、それが保証されるまで待つよりも、見栄えはいまいちでも、読者が読んでくれるコンテンツをすぐ提供できるのは、ビジネスの上で大切なことなのではないか。

私も古いタイプの出版側の人間で、EPUBでも電子書籍でも、組版とかレイアウトとかフォントにできるだけ手をかけたくなる。ただ、それをやるコストやそれをやる意味を同時に考えなければいけない。

今求められているのは、もしかしたらそれよりも先に、著作権の管理とか、最終校正が終わったテキストを保存管理することを考えるほうが電子書籍の上では大事なのではないか。

紙の場合、校了はInDesign上でやることがほとんどである。となると、校了したテキストを持っている出版社とか著者はいない。ゼロではないかもしれないが、ほとんどいないと思う。

世の中にInDesignでテキスト書き出しするのはない。XMLにして書き出しすることはあるかもしれないが、簡単に書き出す機能は基本的にはない。だから校了した後のテキストを持っているのはすごい財産になる。

それをワークフローとしてどうやって組み立てて考えていくか、出版におけるアセットの管理がこれからますます重要になっていくと思う。電子書籍を作っていく上ではそういうところにも目を向けていかないと、ワークフローは管理していけないのではないか。

まだまだこれからの日本の電子書籍市場

緊デジは、東北の復興支援で始まったこともあって、いろいろ批判もあったが、やはりタイミング的に難しい時期の事業だったことは理解してもらいたい。ちょうどレガシーなフォーマットから新しいものに切り替えの時期であった。

我々の準備不足とか説明不足という問題もあるが、コミックを含めて一定のタイトル数をその事業で増やして、またこの時期の電子書籍の市場に送り込んで、今も送り込んでいる最中である。おそらく8万作ったということになっているが、実際にそれが書店に並んでいるのはまだ半分くらいではないか。
具体的な数字は伝え聞く範囲でしかわからないが、一定のタイトル数を増やしてこの時期に送り込んだことは、日本の電子書籍市場をこれから何とかしていこうという時期には必要なことだったのかなと思っている。その答えは、電子書籍をもっと当たり前に皆さんが使うようになってから、わかるようになるのではないかと思う。

緊デジは外から語られることが多くて、中の人間は語っていない。補助金事業なので、語るといろいろ誤解を受けやすいから黙っているのだと思う。その中でも私などは、最初は何とかもっとオープンにしようとしたが、そういう動きをした人間は睨まれてしまった。

誰が悪いわけではなく、公共事業というのは、期間が決まっているなど難しい面がある。何かを余らせて翌年に持ち越すことができない。システムを作ることでも、その年に全部それが消化できるようなシステムを作る。

人材を集めるにしても、今年1年だけという条件でいい人材が集まるかというと、それも難しい。出向の人を集めるにしても、その道に長けている人の手が空いていることはないし、派遣会社から集めるといっても、1年限定で来てくれるエキスパートはなかなかいない。
そうすると、どうしても電子書籍に関してわからない人間たちの集まりになる。それが、もっと公開したらいいのではないか、ツイッターで今やっていることを発表したらいいのではないかということを怖がってしまう最大の原因だと思っている。

東北の話も、当時三陸には凸版、大日本も含めて、印刷関係、製紙関係、インク関連の大きな工場がたくさんあった。そこが津波でものすごい被害を受けて、実際に職を失った人もたくさんいる。
そこに国が何らかの援助をするときに、レガシーな工場をもう一度建てても将来性がないのではないか。それなら電子化を推進することでそちらにラインを作ってもらって、という話があった。

したがって凸版、大日本はかなり大がかりなラインを東北に実際に作った。それ以外でも、どういうコンテンツを選ぶかも「最終的にコンテンツを出したことが公になるのは構わないが、著者名とコンテンツのタイトルを全部リストで出してしまうのは勘弁してもらいたい」という出版社が多かった。
それは多分、著者との権利関係が口約束であったなど、難しいところがあるのだと思う。税金も入っているわけだし、私個人は全部公開するべきだと思った。しかし、「公開するなら出さない」といわれてしまうと、「それだったら、とにかくタイトル出さないといけないのでお願いします」という話もあったように聞いている。

悪党が自分たちの懐を儲けるためにというイメージで語られる。実際、そういう補助金事業もあると思うが、少なくとも私が見る限り、緊デジで儲かったというところは本当にごく一部の電子書籍のライセンスをやったメーカーくらいではないか。

そこもそれなりに苦労しているし、参加した人たちは大変な思いをして、それが将来的な勉強だと思って、これから市場を立ち上げるためだと思ってやった人のほうが多かったことは伝えておきたい。その中でできなかったことや間違ったこともたくさんあるが、それは今後いろいろ歴史的に評価が出てくるものだと思う。

（質問）
フォーマットのような話ではなく、テキストのリフローが作れるのは、大きな成果だと思う。実際それに向けてのサービスとか動きはあるのか？

（深沢氏）
まとまった動きはないと思う。私が見ていたのは、どちらかというとWeb業界を見て、Webの制作環境を見ても、Web業界で1つのまとまった報告みたいなものはない。ウォッチをしている人間が書いている。
何か報告書が出ていると、報告書というのは作るのにタイムラグがかかるので、それを受けとっていたら、もう負けてしまうという世界である。

電子書籍も、アップル、グーグル、アドビ、アマゾンが考えているが、どこかが全部まとめた全体の傾向が出ているなどということはない。制作環境であっても、とにかく自分たちの環境でやる。その代わり、この環境でないと作れないような作り方はしないというのが答えなのではないか。

（質問）
アマゾンやアップルが電書協仕様で作っておけば遅れることはないということか。

（深沢氏）
電書協仕様というのは、でこぼこがあるものを下のラインで揃えたものである。すごくいいものだ、理想的なものだという考え方で作られたものではないと理解してもらいたい。

電書協仕様も多分今後もアップデートされていくし、EPUB3が3.1になると、フィックスとかリフローとかいう作り分けがなくなって、おそらく1つのものの中にフィックスとリフローがちゃんと作れるようになると思う。
ただ、まだEPUB3.01が、とりあえずドラフトが決まったのがこの間出てきて、そこでフィックスという定義が出てきた。今まで、フィックスというきちんとした定義がなかったが、それが出てきた。
要するに、まだまだこれからという感じである。例えば数式とかリストとか多言語の扱いとかがきちんと出てくるのには、まだ時間がかかる。そうなってくると、先駆的なことをやるのはそれはそれで意味があるが、それと同時に、ビジネスとして考えるときは、とにかくシンプルなものを数多く作っていく。

EPUBのいいところは、また先駆的なものになったとき作り直すのは、完全にがちがちに作ってしまうともうできなくなるが、比較的やりやすいと思う。そういう意味では、仕組みさえわかっていけばオープンな世界で、参入障壁も特にない。逆に言うと、大手で人を揃えていたところは逆に厳しくなる可能性もある。頭を柔軟にしてウォッチしていかないと、なかなか紙の印刷とは違うやり方を要求される。

私が今、普段日常的に付き合うのは大体IT系の人たちで、彼らがやっていることをずっと見ていると、とにかくどんどん新しいことを吸収している。勉強してやっていくだけではなく、自分たちで新しいものを生み出す気概がないと今の時代はなかなかかなわない。

ただ、もちろん今までの出版、印刷が持っている文脈とか技術があるので、それをどう使うのか、どう生かしていくのか。サービスとか技術とか商品とかではなく、この道に関する付加価値がどんどん下がっていってただに向かっていってしまう。量産したりコピーすると、それにお金を払う人がいなくなってしまう。そこで最終的に価値の転換が生まれるといわれている。

それは量産をなんでみんなが求めるのかという意味みたいなものである。そのときに、文字組が得意だった人、DTPが得意だった人は、「なぜこういう見せ方をするとみんながきれいだと思ってくれるのか」といったところまで落とし込んでいかないといけない。それを自分たちの今やろうとしているサービスに当てはめていかないと、生き馬の目を抜くようなIT業界の連中と対抗していくのは難しくなってしまう。

2013年10月8日TG研究会「電子書籍の最新事情とEPUB制作環境の進展」より（文責編集）