昨年度までの電子書籍関連トピックスの軽いおさらい

　昨年度は緊デジなどを含めて、電子書籍関連の大きなニュースがそれこそ日替わりで飛び込んできた感がありました。ここで緊デジ、EPUB3を中心として、昨年度までの出来事を時系列順に軽く振り返ってみたいと思います。

登壇者の発表内容

　今回は私が登壇者の一人ということもあり、他の登壇者の方の発表内容のメモが追いつかなかった部分があります。記述に間違いなどありましたらご指摘ください。速やかに修正させていただきます。

（株）三陽社メディア開発室　田嶋セッション

　最初は私のセッションからでした。
　私の所属する三陽社という会社は、創業が1949年の比較的古い活版印刷系の印刷会社で、学術系や文芸系を中心として比較的伝統的な出版社さんからお仕事をいただいています。その関係で社内に保管されている大量の印刷データの電子書籍化をどうにかしようというのが会社としての電子書籍の取り組みのスタートラインでした。また、クライアントさんからも比較的古い時期にSONYのリブリエ用データ制作の依頼などもあり、そういう経緯を踏まえて2012年にメディア開発室という部署を立ち上げ、電子書籍制作の研究を本格的に始めています。

　2011年あたりに危惧していた点としまして、私の会社の場合、メインの組版ソフトがAdobeのInDesignではなくモリサワのMC-B2であるため、これを起点としてのEPUB3制作はちょっと一般ルートで進みそうにないということがありました。そのため、自社である程度まで進めるしかないと考えていました。そこでまずはMC-B2のデータをInDesignタグテキストに変換してInDesignで読み込める形にし、当時、将来できるであろうと想定していたInDesignからのEPUB3制作ルートに乗れる形を整えました。
　ただ結局、InDesignからの電子化もそう簡単ではないことが徐々に判明し、かなりの部分を自力でワークフロー構築することとなりました。

　電子書籍の形式としては最初はモリサワのMCBookの研究から始めています。これはMC-B2／Indesignのデータを読み込めることが売りのひとつでしたが、結局元データの事前の整備が必要になり、かえって手がかかることから、MC-B2→InDesignでデータを整備→XMLでタグ付けして書き出し→PerlでMCBook用XMLデータに変換、の形でデータの制作フローを整えました。
　MCBookは注や異体字関係の機能が充実しており、また組版も非常にきれいだったためかなり期待をしました。しかし、当初Appleのアプリ型ソリューションだったことから外資相手の契約が必要になり、出版社サイドの会計処理が煩雑だったこと、結局特定メーカーへのロックインになってしまうことなどの問題点もありました。
　このため、結局残念ながら会社的にはビジネスには結び付いていません。

　ただ、このMCBookの制作の際に開発した変換スクリプトをもとにして、JBasic08準拠のEPUB3用にInDesignデータからXHTMLを生成するワークフローを発表したりしまして、EPUB3制作のノウハウに結びつけることはできました。

　緊デジについては受注価格的には会社的に厳しいラインになるのはわかっていたのですが、ノウハウの蓄積を考えると貴重な機会と思えましたので、業務の延長線上にあるリフロー型の制作のみに絞って受注を目指すことにいたしました。当初はEPUB3のみを想定してフロー構築をしていたのですが、XMDFもしくはドットブックでの納品が求められるとの話が3月末にあり、また独自形式のXMLでの納品も必要との話もあったため、InDesignからXMDFにも変換できるようにスクリプトを制作しました。

　2012年の6月には電子書籍の外字問題に関するエントリをブログに書いたのをきっかけにしまして、当時出版デジタル機構の技術アドバイザーだった深沢英次さんにお声がけいただき、InDedignから電子書籍を制作した際に文字化けを起こす文字のレポートを書きました。これは非常に勉強になりました。こちらのレポートは今、出版デジタル機構さんのホームページの「技術部だより」にありますので、興味がある方はぜひご覧いただければと思います。

　8月には緊デジ正規受注会社の発表があり、私の所属する会社は結局正規受注会社には選ばれなかったのですが、もともとお付き合いがあり、紙の書籍の制作をさせていただいていた出版社さまからの「制作会社指定」の形で緊デジ事業に参加することになりました。
　従って私の所属する会社で緊デジで制作したコンテンツの元データはほとんど自社に保存されていたもので、MC-B2のデータや、古いものでは電算写植のデータもありました。後から数点、他社制作データの電子化依頼もいただいたのですが、これもMC-B2のデータがほとんどでした。

　電子書籍の形式としては全てリフロー型のEPUB3なのですが、学術系などの組版の複雑な書籍が中心でしたので、底本に割注が含まれていたり、多数の索引があったりして、それのリンク設定にかなりの時間を取られました（文書内の注リンクは緊デジでは出版社独自仕様拡張の扱いでした）。
　また、もともと付き合いのある出版社さんのコンテンツが中心ということで、正字対応など字形にもかなり細かく対応する必要があるのはわかっていましたので、底本と引き合わせて校正をしたりもしました。そのあたりの厳密な校正はもともと会社的に強い部分なので、ここは社内リソースをかなりアテにすることができました。

　制作上大変だった点として、もとのデータの作り方が制作者によって異なるので、制作時に適宜判断しなければならなかったといったような点が挙げられるのですが、これはおそらく全ての制作会社にとって労力が必要だった部分なのではないかと考えています。
　InDesignに限らずDTPソフトというのは「紙の本」を効率良く制作するために機能拡張を繰り返してきています。紙の書籍の制作というのは結局書籍として完成した状態の見た目が全てで、そこに至る経路はどんな道を辿ってもいいという世界なので、当然制作会社ごとにノウハウも違いますし、人によっても違ってきます。100人オペレータがいれば100通りのやり方があるくらいに考えても良いくらいだと思います。

　もちろんきちんとした印刷会社は社内でミスを減らすためにワークフローを統一しているとは思いますし、私の会社もそれはやっているのですが、例えば緊デジのようにどこで作られたかわからないデータを受け入れて電子書籍にするような話ですと、元データがどう作られているのかをそれぞれ分析し、必要に応じて修正することを考えなければなりません。見かけは同じでもどの機能を使ってそれを実現しているかというのは正直データを開けてみないと分かりません。そうしないと例えば、意図しない箇所で改行がかかり、ビューア上で組版が大きく乱れるなどといったことが起きてしまいます。まずこの元データ整理の部分の自動化はできないと思います。

　また、全般に「紙の本の組版をそのまま再現したい」という出版社サイドの要望が強く、これの対応も大変でした。正確な組版の対応は「ページの概念がない」リフロー型電子書籍ではどこまでいっても限界がありますし、当然できないことや「やらない方がいいこと」も沢山あります。それを出版社さんに説明し納得してもらうために、何故やらない方がいいのかを説明して、代わりの選択肢を箇条書きにして送って選んでもらうなど、かなり神経を使いました。

　校閲用のビューアに関しては、Kobo touchとReadium、Kinoppyを併用する形で制作を進めました。KoboとKinoppyで校閲を行った理由は、この二つのストアは当時すでに出版デジタル機構からのコンテンツ供給が確定していたからです。また、ビューアが当時もうかなり組版的に安定していたという事情ももちろんありました。他にはiBooksなども使っていましたし、社内での読み合わせ校正用としてはMurasakiからプリントアウトし、底本と引き合わせたりもしていました。

　また当時は、それぞれのビューアごとに表示が微妙に異なるといったようなことがあり、あるビューア向けに表現を追い込んでも別のビューアだと崩れてしまうといったようなことがありました。これはWebが辿ってきたのと同じ道だと思います。電書協ガイドはそういうビューア間の「方言」を吸収するために作られた側面があり、電書協や出版デジタル機構が各ビューア開発会社にガイドに沿った形でビューアの改訂を要請し、同時に制作者としてはこの電書協ガイドの仕様に沿ってコンテンツを作ることで近い将来にはほぼ全てのビューアで同じ表示が得られる、というのが緊デジでの電書協ガイド仕様採用の意図だったと思います。
　しかし、ビューア自体の改訂が緊デジの制作期間内に間に合うかと言えばそれは無理なわけで、校正者としてはどうしても目の前の、まだ表示が不完全なビューアの表示に引っ張られます。これはまあ仕方ないことだったかなとは思います。
　今は大分各ビューアの改訂も進んできており、まあ正直当時この状態だったらなと思わなくもないのですが、これはいわゆる「鶏と卵」的な話でもあるので、生みの苦しみ的な部分はやはりくぐる必要はあったのかなと思います。

　スケジュール的には当初は出版関連業における閑散期にあたる夏場に人数を割いての作業を想定していたのですが、結局冬場の繁忙期に完全に重なってしまったことが痛かったように思っています。

　EPUB3制作の流れのおおざっぱなまとめとしては、MC-B2のタグテキストをPerlでInDesignタグテキストに変換し、タグ付けを行ってXMLで書き出し、それをまたPerlで変換してXHTMLにし、自社制作ツールでOPFパッケージングファイル、目次ファイルなど必要なファイルを生成してEPUB3に、というような感じで制作を行っています。
　このあたりの流れについては7月に出展の決まりました電子出版EXPOでも展示を行っておりますので、ご来場の際はぜひお立ち寄りいただければ嬉しく思います。

　今後は印刷物の制作とも連携させたワークフローを整え、会社全体で効率良く電子書籍を作れる体制を整えたいと考えております。

（株）デンショク　営業部課長　石倉章晴さんセッション

　デンショクさんは私が所属していますJAGATの研究会でお世話になっている会社さんなのですが、もともとモトヤの関連会社で、InDesignでデータベース組版の仕組みを構築し医学書を中心とした制作を行われています。また、書籍だけではなく、同じデータベースからiPadや各種タブレット類へのアプリ制作などもされているとのことです。必ずしも一般販売される書籍だけではなく、病院内で医師や看護スタッフが利用するソリューションの提供がかなりの比重を占めるとのことで、こうしたマルチな展開はぜひ見習いたいところです。

　緊デジではドットブックとEPUB3の制作依頼、技術指導の依頼があり、主担当1名ほか、システム開発・タグ付け担当各1名で作業を行ったとのこと。
　元データは電算写植機データからのドットブック制作がかなりの冊数にのぼった他、EPUB3も6点ほど制作されたとのことでした。エディタとしては当初はFUSEeを検討したものの、結局Dreamweaverをメインに使ったとのことです。また、私の作ったスクリプト・アプリ類をかなりご活用いただいたとのことで、これは作成者として嬉しい限りです。

　制作時の問題点として、技術的には「確認したい箇所を底本から探す手間」を挙げておられました。これは大いに頷けるところです。元データがInDesignであればDTPデータをPDFに変換し、検索するなどの方法も考えられますが、もとが電算写植機のデータなどではちょっと方法が思いつきません。

　また、営業面での課題としては、Web制作会社なども電子書籍制作に進出してきていることなどからすでに電子書籍制作の値崩れが始まっており、効率を良くして人件費を落としても利益が出せそうにないことなどを指摘されており、これに対する対策として、「電子書籍技術を含めたビジネスモデルの開発」、「会社における電子書籍の位置づけの明確化」、「印刷物と電子書籍が効率的に制作できるワークフローの確立」などを挙げておられました。このあたりは大いに参考にしたいです。
　さらに、「非販売系書籍の電子化」も将来的には対象になってくるのではないか、と話されておられ、特定組織内でのみ流通する文書類や、役所などが無料配布する資料などの存在を考えると、確かに決して軽視できない分野であるように思いました。

（有）眺（ティアオ）　代表　野知潤一さんセッション

　九州で電子書籍制作の会社を営まれている野知さんのセッションです。電子雑誌トルタルにも参加されています。今回は私からお願いしてご登壇いただきました。
　電子書籍の制作には2001年から関わっておられ、最初はメディアワークスのライトノベルHPでの立ち読み版制作だったとのこと。縦書き、ルビ対応が必要だったため、当時その技術を持っていたボイジャーのソリューションを採用し、2年間で200冊ほど制作されたとのことでした。
　2003年には九州のシティ情報誌の文芸賞の電子化、2004年から始めた自社文芸サイトの作品をドットブックにして2005年から理想書店で販売、2007年には女性向け官能小説（ケータイ向け）などのお仕事をされていたものの、どれも大きな売り上げには結び付かず、iPhoneの上陸を機に現在の流れに至るとのお話です。

　緊デジでは九州の出版社に積極的に営業をかけたのですが、参加したのは海鳥社だけで当初は50〜70冊というような話だったものの、出版社サイドでの著作者への許認可に時間がかかり、最終的に16タイトルの電子化という話になったのが12月末とのこと。

　データ形式としては旧バージョンのEDICOLORデータがほとんどで、中国や九州の歴史ものが多く、文字コード外の地名・人名がたくさん出てくるもので外字対応に追われた他、ルビの点数がとても多く、大変苦労をされたとのことでした。外字に関しては、当初出版社から要望のあった形式が文字コードがShift_JISのドットブックだったため、文字コードがUTF-8のEPUB3なら外字化しないで対応できるJIS第3・第4水準の漢字まで外字画像化して対応せざるを得なかったとのお話でした。

　さらに画像が350点以上ととても多い本もあったとのことで、画像をコンテンツ内のどこに配置するかにかなり苦心をされたようです。
　現状EPUB3でも画像の回り込みの対応は十分とは言えず、どうしても文章が画像で寸断される箇所が出てしまいます。これは結局文字の拡大縮小ができる「リフローの利便性」と「厳密な組版」がぶつかる部分なので、多分将来的にも完全な対応は難しいのではないかと思います。

　全てドットブックのコンテンツを納品したところで制作業務が終わったと思っていたところ、2月28日の時点で「EPUB3も作って欲しいという要望が判明」し、対応に大わらわだったとのこと。ここではドットブックからEPUB3への変換および、UTF-8で外字から外れる文字の非外字化が技術的課題になったようです。
　聞くだに大変なお話で、本当に苦労が忍ばれました。

　野知さんが語っておられたことで特に印象的だったのが、「単純に広く読者を獲得する目的でパブリッシュ（出版）するのなら無料のWebベースの方が、Kindle Direct Publishingのような有償コンテンツ販売よりも向くのではないか」という言葉で、さらに「パッケージで固め、値付けしたとたんに圧倒的に読者が減るのが大きな問題」とも言われていました。今後はブラウザベースでタテ書きでコンテンツを公開できる方向性を考えたいとのこと。

　私も現在のセルフパブリッシング（プチ）ブームがどこまで続くのかは少し疑問には思っており、まずWebベースで無料公開し、一定の人気を集めた後に有償コンテンツ販売に移行するというルートが定着する可能性は十分にあると考えています。

（株）シーティーイー　新規事業推進プロデューサー　鎌田幸雄さんセッション

　シーティーイーの鎌田さんのセッションです。鎌田さんもJAGATの研究会でお世話になっており、今回登壇をお願いしました。シーティーイーさんは43年の歴史を持つDTP制作会社とのことで、鎌田さんはQuarkXpress向けのAppleScriptをかつて積極的に発表され、著書も書かれている方とのこと。私は不勉強で知らなかったのですが、どこかでコードのお世話になっていたかも知れません。

　モリサワのMCBookを中心にし、現在MCBook、EPUB3の同時納品フローを構築しているとのこと。理由として、もともとシーティーイーはDTPの制作会社であり、会社全体としてCSSの知識は浸透していないことを挙げておられました。緊デジは主に価格面での判断で受注は見合わせたとのことで、現在月産50冊程度の電子書籍制作体制を構築しておられるそうです。

　DTPを中心とした制作会社にとってCSSの知識が壁になるのは私も痛感しているところで、緊デジが電書協ガイド仕様を採用した理由も「CSSがあらかじめ規定されているフレームワークだから」という部分が大きかったように思います（担当者が勉強すれば、という声も聞こえてきそうですが、「社内に一人詳しい人がいる」のと、「会社としてほぼ全員に一定レベルの知識が期待出来る」のは大違いです）。
　また、MCBookでのフロー構築は私も検討はしたのですが、鎌田さんのお話によると結局MCBookが電書協ガイド仕様のEPUB3書き出しにきちんと対応できたのは5月あたりだったとのことなので、これは見送って正解だったようです。

　出版社さんとあらかじめ相談して作り方を規定し、異体字はMCBookの機能で対応、現在WordからMCBookへのフローも構築しているとのこと。人員としては管理スタッフは2名ほどに留め、制作自体は単価の安い地方で行っているとのお話でした。
　また、最近は電子と紙の同時発行の依頼が増えているとのことで、今後増えてくるタイトな制作スケジュールに対応するために、DTPも含めたデータ作成のあり方を考えておられるとのことでした。

　とても興味深かったのは、MCBookは結局プロプライエタリ（特定メーカー依存）のツールなため将来的に継続してのコンテンツ制作のベースにするにはコピー＆ペーストができないなどの問題点もあり、IDML経由でのコンテンツ制作を考えているとのお言葉です。
　IDMLはInDesignから書き出せる互換ファイル形式の一種で、通常はCS5→CS4など下位バージョンへの互換目的などで使用します。これはZIPパッケージ内にXMLが収められているもので、一応原理的には全ての要素をXMLで書き出すことが可能です。ただし、あまりに複雑すぎるため、私などはこれをハンドリングすることは早々にあきらめ、InDesign内でXMLタグを付加し、書き出して変換する方法を選びました。もしIDMLから変換してEPUBを制作できるのであれば、タグを付加する手間を省くことができ、かなりの省力化が期待出来るのではないかと思われます。