電子出版時代にふさわしいワークフローとは? ── JEPAセミナー「電子書籍実務者は見た!」レポート

JEPAセミナー「電子書籍実務者は見た!」登壇者

2013年12月18日に行われたJEPAセミナー「電子書籍実務者は見た!」のレポートです。動画やプレゼン資料は epubcafé にアップロードされていますので、詳細はそちらをご覧下さい。2時間半くらいのセミナーです。「今のワークフロー、ここがヘン」「ここさえ気をつければ、もっと効率的にできるのに」「せめてこれだけはやめてほしい」といったディープな情報が公開されていました。

登壇者は、上の写真で向かって左から田嶋淳さん(三陽社メディア開発室)、林智彦さん(朝日新聞社)、大江和久さん(株式会社ラング)、梅屋文彦さん(SBクリエイティブ)、安井一弥さん(Office KZ)です。

このセミナーは、「電子書籍」が日本でブレイクしない理由の1つとして「『電子書籍』にふさわしいワークフローが確立されていない」ことを挙げ、紙の書籍に最適化されたワークフローで現場にどんな問題が起きているのか、どんな見直しを図るべきなのかを提案するものでした。

林智彦さんのプレゼン

※セミナー資料はこちら(Googleドライブ・プレゼンテーション)

林智彦さん(朝日新聞社)

林さんはセミナーの冒頭で、某教授に「『電子書籍』はコストゼロで作れるんだよ!」と説教されたというエピソードを紹介しました。「いやいや、いまはまだ紙の制作よりコストかかってるくらいですよ」と反論すると、「何言ってるんだねキミは。もっと勉強しなさい!」と言われてしまったそうです。

ワークフローが定型化されていないので電子化の方が手間がかかるということが、現場を知らない人にはなかなか理解されづらい現状があるようです。まあ、実際に現場で苦しんでいる方の声に耳を傾けない人は、案外多いですよね。

林さんのプレゼンでは、次の3点が結論として挙げられました。

  • 紙の制作プロセスに手を付けないまま、ただ最終成果物だけを電子コンテンツに置き換えるやり方では、全体最適化が図れず、「電子書籍は儲からない」で終わってしまう。
  • 電子書籍をきっかけとして、「プロセスの電子化」としての電子書籍革命を推進する
  • そのための一里塚として、メディア中立な最適データを作ることを心がける必要がある

まず現状把握として、いまの「電子化」は、紙の制作プロセスに手を付けないまま、最終成果物を「電子書籍」にする状態になっているそうです。「出版プロセスの電子化」は、既に30年以上前から進んでいます。

出版のプロセスは、執筆、編集、校正、組版、印刷、製本、流通、販売。電子化されているプロセスもあれば、電子化されていないプロセスもあります。とくに、校正、流通、販売プロセスの遅れが目立つそうです。

林氏の資料

例えば、EPUBの校正はワークフローが確立していないので、電子ペーパー端末の画面をコピー機でコピーして紙に赤入れ、といったやり方が発明されているそうです。コストが余計にかかってしまうけど、他にやりようがないという状態なんですね。

まだいまは「電子書籍0.9」と呼ぶべき段階だろうと林さんはいいます。これを「電子書籍1.0」にするには、紙と電子の両方のワークフローを見なおして最適化を図るしかありません。ところが、紙の出版のやり方をなかなか変えられないのが現状です。だから林さんは、「みんながハッピーになれるやり方を考えよう」と提案します。

梅屋文彦さんのプレゼン

※セミナー資料はこちら(Googleドライブ・PDF)

梅屋文彦さん(SBクリエイティブ)

梅屋文彦さんはSBクリエイティブ勤務ということで、出版社の電子書籍業務フローの現状についてプレゼンを行いました。

制作以外の主要業務としては、契約書雛形作成・編集部対応・電子書店営業・プロモーション実施・電子書籍仕様書作成・電子書籍リーダー動作確認・著作権者への売上報告書作成などがあるそうです。数年前に電子書籍が騒がれた時は、交渉契約で困ってた人が多かったそうですが、今は次のフローに移っているとのこと。

梅屋さんが会社から要求されていることは、「低コスト、少人数、大量生産」の3つ。売上を増やすためにはタイトル数が必要なので、年間480タイトルがノルマ。しかし、そこに人件費はかけられないため、月40タイトルを3人で回しているそうです。また、制作費を低減するために、大量生産と仕様統一が求められています。

梅屋氏の資料4ページ目

現状の制作フローは、“電子書籍の仕様に合わせた「再組版」”になっているそうです。底本・DTPデータ・制作指示書を制作会社に送り、基本は再校で終了。1冊作るのに約1ヶ月かかり、そこから数週間〜1ヶ月で配信開始というスケジュールとのこと。

省力化しつつもクオリティーを維持するため、目次・奥付の共通化や、電書協フォーマットに準拠した制作仕様書、画像は単ページ表示、注釈を一箇所に固めるといった工夫をしているそうです。

底本ママで雰囲気を踏襲するため、段下げ、ルビ、ダーシー、強調、縦中縦、縦中横、注釈、ゴシック、明朝、フォントサイズはもちろん反映。見出し・柱の飾りは極力反映という形になっているそうです。とくにライトノベルは、ゴシック・明朝で意味が違うので気をつけているとか。

校正は、基本はMobiに変換してKindle Fireで見ているそうです。まずAmazon優先なんですね。「Kindle Previewer」は行間が実機と異なるケースがあったので使わないとのこと。「プレビューアは所詮プレビューア」と。また、DTPベースだとカーニング(文字詰め)で空白を入れてる場合がある(テキストになると空白が消える)ので、注意しなければならないとか。

また、本文ママの処理を複数の端末、複数のリーダーでもチェックするそうです。問題が起きる頻度は結構高く、回避策を制作仕様書に落とし込み、制作会社と共有しているそうです。

梅屋氏の資料7ページ目

現状、EPUB 3 ビューワのリフロー対応にかなり不満があるそうです。IDPFの定めたEPUBの仕様に、対応しきれていないビューワもまだまだ多い(※そのためXMDFや.bookでの制作フローを残さなければならなかったり、「EPUBしか作らない!」という方針の出版社作品が未配信になったりしているのが現状)とか。だから、この表現がダメだというクリティカルなものは、必ず書店側に伝えるようにしているそうです。「かなり口うるさく言ってる方だと思う」とのこと。

例えばダーシがダーシじゃない(短い・繋がっていないなど)ケースが見つかった場合などは、制作会社に底本を渡して「これで」というやり方をしているので、「底本準拠が絶対」というルールになっているそうです。とくにライトノベルは表現力が大切なので、そうせざるを得ないようです。

ボクも先日、「——(U+2014)」や「――(U+2015)」ではビューワやフォントによってはダメ(iBooksだとOKだけど、Kindleだと切れちゃう、など)なので、罫線素片「──(U+2500)」を使うしかないということを学びました……。

田嶋淳さんのプレゼン

※セミナー資料はこちらこちら(Googleドライブ・PDF)

田嶋淳さん(三陽社メディア開発室)

田嶋淳さんは、「InDesignからの電子化で問題になるポイント」についてのプレゼンでした。問題点として挙げられていたのは、次の5点です。

  • テキストボックスが同一ページ内に複数配置されているケース
  • 見出し等が画像として作成され、配置されているケース
  • フォントが添付されていない/添付されているフォントが使用できないケース
  • 強制改行、タブなどの特殊キャラクタ文字
  • カーニング・トラッキング・アキ量調整を利用したスペース表現

InDesignは初心者でもとっつきやすいツールなので、製作方法が非常にいろんな形で多岐にわたっている(同じことを表現しようと思った時に、やり方がいろいろある)そうです。そのデータから「電子書籍」を制作しようと思うと、結局、人間が必ずチェックして判断しなければならないとか。

これはInDesignに限った話ではなく、WSYWIGエディタ(What You See Is What You Get)はみんな同じ問題を抱えているそうです。身近なところで分かりやすいのは、Excel方眼紙かな……?

だから、「InDesignのデータがあるから、すぐ電子化できますよ」というのは「嘘」だと田嶋さんは断言します。実際、電子出版EXPOに出展していた業者のほとんどは、フィックス型での書き出しだったそうです。それ画像じゃん

大江和久さんのプレゼン

※セミナー資料はこちら(HTML)

大江和久さん(株式会社ラング)

大江和久さんのプレゼンは、2つありました。

電書ファイルのチェックシステムの実例について

「緊デジ」では大量のタイトルを処理しなければならなかったので、人力でチェックしている時間がありませんでした。そこで、バリデータツールによるチェックというのを提案したそうです。

チェック内容は、以下のとおりです。

  • 構成ファイルの過不足
  • XMDF、dotbook、EPUBの各バリデータの自動実行
  • ID不正、メタデータの不整合、ページ構成の不整合
  • 使用文字チェック
  • 使用画像外字の抽出
  • これらの夜間一括バッチ処理
  • ログファイルのCSV書き出し

このようなチェック・校正支援システムの重要性として、以下の点を挙げていました。

  • 一括処理できる
  • 目視チェックの項目を減らす
  • 自動で直せるところは自動で
  • 単純作業から人間を開放

人間がやることには必ずミスが起こるので、コンピュータが自動でできることは自動でやらせればいいという話ですね。

電書制作における文字問題

「電子書籍」で使用できる文字コードが、SJIS → CP932 → Unicode と遷移してきた歴史があります。ところがその文字コードがシステマティックにチェックできていないことと、電子書籍リーダで使用できる文字の範囲が明確に仕様として公開されていない点が問題になっているそうです。

印刷データから変換した場合、Adobe-Japan1が事実上の標準となります。そこでは「底本準拠主義(見た目が同じならいい)」と「セマンティック(その文字のもつ意味が重要)」という考え方があり、どちらが絶対というわけではないそうです。

制作時点での具体的問題点としては、次のようなものが挙げられるそうです。

  • 使える文字は?
  • Adobe-Japan1の範囲でどこまで使える?
  • SJIS(JIS X 0208)の範囲でつくられた電子書籍(画像外字を戻す処理)
  • どこまでを画像外字にするか?(異体字の包摂問題)
  • 記号類の正立問題(UTR#50と実装の乖離)

また、画像外字の問題として

  • 検索できない、読み上げできない(非セマンティック性)
  • 版面に違和感がある、反転表示できない
  • 制作、表示ともにコストや負荷が余計にかかる

といったことを挙げ、「画像外字なくさない?」という提案をします。どうしても画像外字にせざるを得ないケースは、数式・化学記号や、IVS異体字(人名で限定的に用いられる)くらいだとか。

林さんの勤務先は「文字を直しちゃえ」という方針の会社だからこういう問題にあたったことないそうですが、実際のところ昔の本を電子化しようと思うと、著作権者に無断で使用文字を変更できない(同一性保持権の侵害になる)ため、いろいろと苦労があるようです。

安井一弥さんのプレゼン

※セミナー資料はこちら(Googleドライブ・PDF)

安井一弥さん(Office KZ)

安井一弥さんのプレゼンは、商業出版と産業出版の違いについて。

産業出版の世界では、例えばメーカーのマニュアル制作などでは、直前に製品の仕様変更が入ることが結構あるので、テキストが校了するまで一切レイアウトには入れないそうです。

翻訳はセンテンスごとに全部ナンバリングして管理したり、コスト削減のためテキスト&ラフ図版で校了したり、PDF校正を徹底したりするとか。また、産業出版の場合、著作権はクライアントに帰属する(著作権買い取り)という違いがあります。

「電子書籍元年」のころから感じていることとして、出版社がInDesignという環境に非常に依存しているということに驚かされるそうです。過去の資産がしがらみになるケースをたくさん見てきているので、とにかくそういう作り方をしないこと。いずれWebデザインとDTPが一緒になるから、環境依存にしないことが大切だと安井さんは語ります。

例えばPDFは、既にISO規格になってるから問題ないそうです。同じように、標準仕様(例えばHTML)としてオープンになっているものは、先々「読めなくなる」ことはないと断言します。

また、「『効率化』を考えるべきなのでは? 出版ってアートなの?」と問いかけます。執筆者が「この文字を何が何でも使いたい」といったら、それを実現するのがこれまでの紙の出版だったそうです。しかし、「わかっていない執筆者」の方が多いのだから、出版社に有利なルールへ誘導してあげることが大切なのではないかと安井さんは言います。

ちなみに、ブックウォーカーの青空文庫EPUBは、外字をUnicodeに直してるそうです。

なお、詳しいことは「憂鬱なe-Bookの夜明け(仮)アトムとビットのメディア考現学」に書かれているそうです。

憂鬱なe-Bookの夜明け(仮)アトムとビットのメディア考現学

憂鬱なe-Bookの夜明け(仮)アトムとビットのメディア考現学

posted with amazlet at 14.02.16

Office KZ (2012-10-24)
売り上げランキング: 55,025

討論編

続いて、パネルディスカッションが行われました。このパート、話題がいろいろあって正直まとめきれないので、取材メモを少し手直ししてそのまま載せておきます。

林:上流で済ませておけばいい話が、下流にいくほど労力がかかるんですよね。

安井:そこが産業出版と商業出版の一番大きな違い。制作プロセスそのものにはITが結構浸透してますよね。

林:OSやアプリが進化しすぎてますね。サムライ系の著者が、Wordで完全に作りこんだ「完成原稿」を送ってくる。編集が、きた原稿をそのまま受け取る、みたいな感じになっちゃってる。手で索引作る!?みたいな。

安井:校正記号とか覚えても、もうしょうがないですよね。

梅屋:校正はPDFでくるけど、そのままPDFで校正するか、紙で打ち出すかはその人次第ですね。

梅屋:電子オリジナルはまだほとんどないです。

林:もし電子オリジナルをやるとしたら?

梅屋:元データの時点で校正は終わらせておきます。

林:電子だと手離れが悪くなってますよね。責了した後に端末でのQCしなきゃいけないとか。QAの段階が後の方の工程にあるのはおかしい。

梅屋:ひとり印刷屋みたいになってますね。

大江:個人出版でやってる人は、執筆段階から電子端末での表示をすでに意識してますよね。

林:結果的に産業出版へ近づいていくのではないでしょうか。

林:先日「PDFでゲラを送りつけるけしからん編集者」みたいな話をTwitterで見かけました。

大江:印刷はそれが最終形態、電子書籍はリーダーで見た状態が最終形態。

安井:Webはずっとそうやってやってきてますよね。

田嶋:「○○ページ参照」みたいな表記や句読点も、勝手に直さず随時聞くようにしてます。または、「直しましたよ」というのがわかるようにしておきます。

林:ハーパーコリンズの投資家向け資料で “However, profitability increases significantly”「紙より電子のほうが利益が出ます」と言ってるんですね。”Manufacturing Costs” “Cost of Return(返本)がなくなる” と。

安井:電子書籍だとインハウスでやるところが多いけど、それでもまだ外注使っちゃってるところもありますよね。メーカー系はある時期、一斉にインハウスにしはじめました。

林:「著者にそんなこと言えない!」というのが結構多いんですよね。いまは「電子書籍のために必要なんです!」という言い訳ができるので、プロセスを合理化できるチャンスだと思います。アメリカのDTP革命(80年代)は、ある程度ディグリードしてコストを下げたのに、日本は器用に無理やり実現しちゃったから。

安井:ツールは変わったけど、使ってる人の意識が変わってないんですよね。

大江:セマンティック性を著者レベルから意識させなきゃいけないですね。「見出しは<h1>タグなんだよ!」みたいなのを教育していかなきゃ。

安井:産業出版は著者も生活がかかっているのでプロ化していますけど、商業出版はプロが書いてるわけじゃないんですよ。そこで鍵を握ってるのは「編集者」だと思います。

梅屋:出版社からすると、日本の印刷会社は非常に優秀なんです。だから「電子書籍」の制作会社は、印刷会社が増えてきています。「印刷物でこの書き方はないよね?」という最低限の作法が、業界外からきた会社ではダメでした。実は出版社があまり困っていないのが現実かもしれません。ただ、紙と同時発売ということを考えると……安井さんが言われる方向に寄っていかないと、コスト的に無理でしょうね。

大江:オライリーなんかはもうやってますよね。

林:DTP革命が日本で起きなかったことの繰り返しを再現したくないですよね。このままだとイノベーションのジレンマみたいなことをもう一回やってしまいそうで。「ある程度、紙の版面の美しさを諦めよう」みたいな合意はできないものでしょうか?

梅屋:凝ったレイアウトの場合、電子書籍では実現できないので、必ず編集に説明をしています。場合によっては、著者まで戻すような場合も。

林:ある程度限界は理解してもらえるんです?

大江:ラノベみたいな特殊な表現は難しいですよね。

梅屋:妥協というより「説得しました」みたいな。

田嶋:元データチェックと作業の振り分けですよね。

梅屋:本来、元データがきちんとしていれば、書き出し一瞬で終わるわけですよね。

田嶋:手間がかかるのは最初と最後ですね。

梅屋:そういう事情なんですよ!

林:こないだ紙と電子が同時発売できていないことを文句言ったら怒られましたよね。

林:書誌情報が一元化されてない問題というのもありますね。直前にタイトル変更したら、書誌情報が変わっていないとか。

大江:それって本来システムで解決できることですよね。JPOから引っ張ってくるとか

林:最後にひとことお願いします。

田嶋:いまお見せしているのは、電子書籍1.0のためのものです。

安井:5年、10年先を見据えた作り方をしましょう。

梅屋:ここで2年前に「電子書籍」の契約についてのセミナーをしましたが、当時はこのレベルの話まで全くたどり着いていませんでした。ここまで頑張ってきたんだから、もうちょっとがんばりましょう。

大江:コンピュータに使われないようにしましょう。書誌情報のコピペとか、「コンピュータの奴隷」になってますよね。

タイトルとURLをコピーしました