2010-09-26

談話室沢辺 ゲスト:深沢英次「電子『雑誌』フォーマットの可能性」

製作者側からみた電子書籍は、タグ付きテキストを基本とした電子書籍と、
デザインが保持された電子雑誌と、整理されて議論されるべきではないだろうか。
電子雑誌には、大きく分類すると、動画や3Dなどに注力したもの/
紙の誌面のPDF版などに分けられるが、それはどちらも「画像」としてデバイスに表示される。
だが、電子化する以上、検索性や、コピー&ペースト機能、
障害者などにむけた読み上げを可能にする、など、電子データならではの
機能を実装することも重要ではないだろうか?
電子「雑誌」の現状、HTML5を始めとする、新フォーマットの可能性、
そして、現在の雑誌編集現場からみたそれらのワークフローの見通しを
デザイナー/メディアシステム・ディレクターの深沢英次さんに伺う。
(このインタビューは2010年8月26日に収録しました)
USTREAMで中継された映像はこちらで視聴できます。

プロフィール

深沢英次(ふかさわ・えいじ)
1961年東京生まれ。京浜工業地帯の大田区・蒲田で育つ。都立工芸高校デザイン科を卒業後、自宅の自動車修理工場に勤務。26歳のときに工場が廃業。目指していたデザインの道へ進む。写植版下から広告代理店の制作部などを経て、30歳のときにフリーのグラフィックデザイナーとして独立。デザイン業の傍ら、取材・執筆や編集なども行うようになり、まだ珍しかったMacintoshを購入してDTPやシステム構築の仕事を始める。1994年、小林弘人氏に誘われ「ワイアード日本版」の創刊に参加。テクニカル・ディレクターとして日本初のフルDTPによる6色印刷の月刊誌を作成。その後、副編集長とWebサイト責任者も兼任した。1997年に友人の森孝史と有限会社ノラを神田神保町に設立、代表取締役に。2004年より3年間、武蔵野美大デザイン情報学科の非常勤講師として「Webコンテンツ編集」の授業を担当。2005年9月にフリーランスへ戻るため有限会社ノラを解散し、現在はフリーでグラフィックデザインの他にデザイン系書籍の執筆や編集、システム構築、Webサイトの作成などを行っている。日本グラフィックデザイナー協会(JAGDA)正会員。(深沢英次氏のブログ「pictex.blog」より転載)

ブログ「pictex.blog」
Twitterアカウント:@pictex
P1040230.JPG

●「WIRED日本版」テクニカルディレクター

沢辺 今日は「電子『雑誌』フォーマットの可能性」というテーマで、深沢英次さんにお話しを伺いたいと思います。

深沢 なぜ今日、僕がここに呼ばれたのかというのも本当はあまりよくわかってなくて(笑)。
今回は、最近の電子書籍絡みの話題が多い中、電子雑誌のフォーマットについてちょっと意見を、という感じで沢辺さんからお話があったんですけれども、実際に僕が電子雑誌をつくって世の中に出している、いうことをしているわけでもないです。
僕はもともと紙で本をつくるデザイナーをしていて、それから雑誌づくり、DTPからwebに移っていって、今はwebや編集システムのインフラづくりをしています。どちらかというと現場の人間ですので、あまり偉そうなことはいえないんですけども、何か一緒になって、これから考えていくきっかけになればいいかなと思って、今回ここにのこのことやってきました。

沢辺 僕が一番最初に聞きたかったのは、深沢さんといえば、雑誌「WIRED日本版」のテクニカルディレクター。

深沢 はい、やりました。

沢辺 ということは、アートディレクターがいたわけですよね。

深沢 はい、そうですね。「WIRED」の日本語版をつくったのは1994年なんですけど、小林弘人編集長(現インフォバーンCEO)が、編集長とアートディレクターとテクニカルディレクターの3人体制、トロイカ体制でやろうと。コンテンツについては編集長が、見せ方については、今「ASYL」をやっている佐藤直樹アートディレクターで。まだ当時はコンピュータを使って雑誌をつくるっていうのはほとんどなかったんですね。メインは写植版下の時代だったので。

沢辺 1994年にコンピュータでDTP。

深沢 フルDTPです。コンピュータ雑誌なんかでは一部DTPを使っていたところもありますし、雑誌の中でこの特集だけをDTPでっていうのはあったと思うんですけど、毎月の一般誌をフルDTPでつくったっていうのは「WIRED日本版」が初めてだと思います。

沢辺 テクニカルディレクターというのは、コンピュータや、アプリケーションは何を使うとか、フォント関係はどう統一するか、印刷屋には何のかたちで渡すとかを、

深沢 はい。そこを僕がコントロールしていました。考えて、こういうふうにやろうや、みたいな感じで(印刷所の)凸版のほうにもプロジェクトチームをつくってもらって。──アメリカでは、もうDTPが進んでいたんで、それをどういうふうに日本でもやっていくのかっていうのを。

沢辺 (会場に)今日のテーマとずれちゃうから、興味ない人は面白くないかもしれないんだけど、すごく突っ込みたくなっちゃうんだけど。

深沢 はい、突っ込んでください(笑)。

●黎明期のフルDTP作業の実状

沢辺 当時、アプリケーションは何を使っていたんですか? QuarkXPress(Quark社が開発しているDTPソフト。1987年にバージョン1が発売された。日本語に対応したのは1989年発売のバージョン2.0Jから)の3ぐらいですか。

深沢 QuarkXPressの3が出るか、出ないかぐらいじゃないですかね。当時僕はQuarkXPressをあまり使ってなくてPageMaker(Aldus社から1985年に発売された、最初のDTPソフト。その後、AldusはAdobeに買収され、PageMakerはAdobe InDesignに引き継がれていった。最終バージョンは2001年のバージョン7.0)を使っていたんですよ。

沢辺 「WIRED」は?

深沢 だから「WIRED」のために、本格的にQuarkXPressに乗り換えるかっていう感じでしたね。

沢辺 それで、佐藤直樹さん以下、デザイナーはどこまでDTPを知っていたんですか?

深沢 みんなコンピュータは「触ったことがある」程度でしたね。だから、QuarkXPressの細かい使い方とか、ページネーションのやり方は誰も知らなかった。

沢辺 深沢さんも自分で実験してみて。

深沢 そうです。大体、僕、もともとが独学の人間なんで。コンピュータもそうだし、デザインもそう。こうすればいいだろう、それで駄目だったら、印刷屋に聞こうとか、知っている人に聞こうとか、アメリカに聞こうって、人に聞きながら何とかやってきました。

沢辺 (会場に)つまらなかったらすみませんね。僕、好きなんですよ。
じゃあ、佐藤さん以下、デザイナーはどこまでやっていたんですか。たとえば最近だと、InDesignでデザイナーがデザインして、そのデータに編集者やライターが書いたテキストをオペレーターが流し込む、みたいな分業になっていたりするんですが。

深沢 はい、はい。分業ではなくみんな自分でやってました。

沢辺 たとえば、写真類はどうしていたんですか?

深沢 うん。その当時は結局、まだデジカメがない時代なので。

沢辺 スキャニングなの?

深沢 そうです。だから、自分たちでスキャンした紙焼きとか、ポジのデータをアタリとして(低解像度でスキャンした画像データを)はめ込んで。本格的なスキャンは凸版に。でも凸版に頼むのはいいんですけども、「WIRED」は「写真をデジタル処理する」っていうのが見せ方のひとつに入っていたんですよ。だから、スキャンしてもらったデータをまた戻してもらってPhotoshopで色を変えたりっていうのをやったんですね。
ただ、その当時のコンピュータには、高解像度の写真をレタッチできる能力ってほとんどない。だから、たとえば、ぼかしの命令を掛けて飯を食いに行ったり、色をちょっと変更したかったら命令かけたまま一度帰って寝て、また戻ってきて続きをやったりっていうことをやったんですよ。

沢辺 それ、とんでもないね(笑)。

深沢 もうメモリが足りないんで、MOを2つつなげてMOをスクラッチディスクにしてやったりしていました。

沢辺 で、デザイナーが入稿データまでつくったわけ。

深沢 そうです。もう完全に入稿データまでやっていましたね。

沢辺 フォントはどんなものがあったんですか。

深沢 フォントはモリサワの5書体(細明朝、中ゴシックBBB、太ゴ、太ミン、じゅん)に、最初はロダンなどフォントワークスの書体をちょっと使いましたね。でも、じきに、モリサワがMB101シリーズを出したので。

沢辺 そんなに早かったでしたっけ。

深沢 MB101シリーズはじきに出たんですよ。実は、僕は妹がモリサワに勤めていたので、普通の人よりは早めにそういう情報をもらったりしてたんですけどね。

沢辺 ネットワークは?

深沢 ネットワークは、「これからすべてインターネットで世の中変わるんだ、デジタル革命だ」っていうのがメインコンセプトの雑誌なんだけども、編集部に9,600bpsのモデム(MODEM〈MOdulator-DEModulator〉/電話回線のアナログ信号とコンピューターのデジタル信号を相互に変換する機器)がひとつあっただけという状態ですね(笑)。

沢辺 電話をかけていたわけだよね。

深沢 最初はそうですね。じきに広告のバーターで専用回線を引いてもらった。専用回線はまだ月に何百万とかっていう時代ですよ。

沢辺 俺、一番最初にISDNの専用回線を引いたの、98年だったかなあ。

深沢 98年だったら、もう全然問題ないでしょう。

沢辺 あれが月額3万ぐらいで常時接続。

深沢 だって、94年当時は日本でwebサイトを持っているところはほとんどなかったですからね。大学とかそのぐらいで、一般の企業とかではなかった。僕らの編集部ぐらいだったんじゃないかな。

沢辺 (会場に)この話、もうちょっとだけ、もうやめますから(笑)。社内のマシンのネットワークはつなげてた?

深沢 つなげていた。AppleTalkですね。

沢辺 サーバーは置いてたんですか。それとも、各マシンにMOをくっつけて、こうやって持ち歩いていたんですか。

深沢 あの……「フリスビーネットワーク」っていってたんですよ。当時は。
とにかくネットワークが遅いんで、何かデータを取ったらフロッピーとか、MOに取って「ほいよ」って投げる。それを僕らとか、アメリカでもそういう言い方をしていたんですけど、フリスビーネットワークっていってたんですね。
でも、それじゃあ、やっぱり駄目だってとにかく何とかネットワーク上でやろうということで、インターネットの専用線を引いて、中にサン・マイクロのサーバを入れて、webやメールサーバを乗せて。その当時、サンのサーバを立ち上げるのに小飼弾(ブロガー/プログラマー。元オン・ザ・エッヂ〈現ライブドア〉取締役最高技術責任者)さんを呼んで手伝ってもらったりしてましたね。

沢辺 印刷所への入稿はどういう形態で?

深沢 MOで。

沢辺 QuarkXPressのデータ。

深沢 (会場に)関係ない話ですみませんね。そういう感じです。

沢辺 そうなんだ。「WIRED」はIllustratorでアウトラインを取って、ということは。

深沢 いや、アウトラインはない。もうほとんどそのままの状態。で、またもうひとつ問題があったのは「WIRED」っていう雑誌は商業誌なんですけども、本文を特色6色印刷とか平気でやったんですよ。蛍光とか、銀とかを使って。それも雑誌のひとつの売りにしたんです。
その当時のQuarkXPressは、基本的に内部では特色は扱えなかったんです。だから、結局、QuarkXPressでひとつ(CMYKの)データをつくったら、それをコピーして別版(特色で印刷する版)用のファイルをつくったんですよ。

沢辺 デジタルでやっているんだけど、すごくアナログな発想、思考ですね。

深沢 そうです、そうです。

沢辺 フィルムがデータに置き換わっているけど、フィルムって全部黒ですもんね。

深沢 そうです。だから、さっき言ったフォントの問題もそうですけども、初期はフォントが足りないんで、じゃあ、ひとつのフォントをぼかしてコントラストを変えて太くしたり、要するに昔でいう写植、紙焼きでぼかしてちょっと太めにしてタイトルに使ったとか。

沢辺 写植機のレンズにティッシュペーパーをかませたり、みたいな。

深沢 そうです。そういうのと同じようなことを散々デジタルでやったわけです。それ以外にも、写植を打ってもらったものをスキャンしてはめ込んだりとか、それからEPSデータだとQuarkXPressで色は変えられないけど、TIFFのモノクロ2階調にすると、QuarkXPress上で色を変更することができるんですね。そういうことをいろいろ自分たちで考えては試して、何とか質を良くできるところまで持っていって印刷して雑誌として売る。それをずっと繰り返してたんですね。

沢辺 当然、イメージセッター(組版データを印刷用の原版に高解像度で出力=製版する機械)でフィルム出力と。

深沢 当時は凸版だったんで、ほとんどがサイテックス(Scitex)です。イメージセッターでフィルム出力だと色味の調整がけっこう転んじゃうんで、恐らく6色印刷ができなかったと思うんですよ。フィルムのアナログ部分が、濃かったり薄かったりするんです。そうすると、もうやっぱり色味がめちゃくちゃになっちゃうんです。

沢辺 じゃあ、その時の深沢さんの役割は、たとえば、デザイナーが「このタイトル、ちょっとぼかしたいんだけどさ、どうやったらいいと思う?」とか。

深沢 そんな感じです。それで、じゃあ、こうやってやろうよと。ちょっとこれ、時間がかかるから俺やっとくわ、とかしていたわけです。あとは、アメリカとメールがつながらなくなったとか、送られてきたのが文字化けしちゃったとか。

沢辺 「MO読まないよ!」とか。

深沢 そうです。そういうトラブル処理みたいなことをずっとやってたんです。「デジタルで雑誌をつくる」ことの原点みたいなものですね。

P1040200.JPG

●webサイト創設の経験

沢辺 なるほど。なので、今日の電子書籍、電子雑誌のできるだけ現場的なアイデアを聞けたらいいんじゃないかということで深沢さんをお呼びしたわけです。

深沢 1年後、2年後ぐらいになってくると、だんだん落ち着いて、ほかの雑誌なんかでもDTP化が進んできたんですね。そのぐらいになってくると、大体、もうDTPよりも今度はwebのほうをやろうということで、僕が本格的に取り組むようになったんですね。webもその時に勉強したり試したり。最初はwebで「スプラッシュページ」っていうのをつくったんですよ。僕らが、おそらく日本で一番最初だと思うんだけども。

沢辺 それ、何?

深沢 要するに、「www.wired.co.jp」とアクセスすると、最初にWIREDのロゴだけ浮かび上がってくるんですよ。それをクリックすると、いろいろと細かいページに行く。
トップページ(index.htmlページ)で、そのロゴだけを見せるっていうのをやったんですね。それは僕がやったんですけど、ものすごく世界中から非難を受けました。「何て無駄なことをするんだ。おまえ、インデックスっていう意味をわかっているのか」って。インターネットにアクセスするのが1分いくら、っていう時代だったので、トップページにアクセスした時に、必ず目次のインデックスが出てこないといけないのに、ロゴだけしか見せない。

沢辺 そんな時代。

深沢 それでものすごくたくさん非難のメールをもらったんです。その時に、だから、インターネットのwebっていうのは一体どういうものなんだろう。どういうふうに見られるべきなのかっていうことをすごく悩んで考えたんです。それが今の僕のwebサイトをつくる上での基礎になってくるんですね。

沢辺 (会場を見渡し)今日来ていただいた方々は当然、ほとんどわかっている世代だと思うんですけど、たとえば、写真をホームページに、どのくらいの大きさで載せるか、ということを気にしなくなったんですよね。

深沢 はい。リソースをね。

沢辺 だけど、昔はものすごく気にしてつくってましたよね。

深沢 同じソフトでも日本語版と英語版がある場合だったら、僕らは英語版を使ったんですよ。なぜかというと、英語版のほうが軽いんです。日本語化することによってソフトウェアが重くなっちゃうんですね。そうすると、本来、1日で終わる仕事が結局、2日、3日掛かっちゃうんです。嫌だなって言いながらも英語版を使ったんです。そのほうが仕事が早く終わる。
メッセージが日本語で出るとか、メニューが日本語で出るとかっていうのは、まずあきらめて。とにかく最終的に日本語の雑誌をつくるんだったら、できあがりで日本語が印刷されていればいいと。それをつくる上でのソフトとか、そういうのは全部英語でも構わない。そういう感じでとにかく、スピードや軽さを追い求めていきました。
で、そのためにいろいろコンピュータの仕組みだとか、ファイルシステムだとか、どこかにバグが残ってないかとか、そういうのを調べてつぶしていってっていうことをやったんですね。
その当時はAdobeにも協力してくれる人がいたし、モリサワにも妹がいたし。こっちはわからないから、こういうのをつくっているんだけど、どうすればいいかって直接行って聞いたりとか、そういう感じだったんですね。そういう意味では黎明期だったんですよ。
僕は高校を出て、8年ぐらい自動車の修理工をやっていたんで、デザインやDTPの世界にお師匠さんがいるわけでもないし、そういうことを教えてくれる学校があったわけでもない。何かコネがあるわけでもない。もうとにかく独学で、わからなければ、とにかく誰かに聞けばいいや、自分たちで出来るところまでやろうという感じでした。

●電子「書籍」と電子「雑誌」

沢辺 今日は電子雑誌の話をしようということなんですね。何でそう思ったのかというと、今、電子書籍と電子雑誌がぐちゃぐちゃに語られているような気がするから。たとえば、僕、電子書籍と電子雑誌ってどう違うっていうと、リフローさせるもの/リフローしないもの、それから、デザインがそれほど重要じゃないもの/かなりデザインを見せたいもの、みたいな違いが基本的にあると思ってる。
電子書籍のほうについては相変わらず三省デジタル懇談会が「フォーマット」を研究する、なんていうようなことをいってるけど、でも、もうこれは決着着いてるじゃん、って思うんです。
基本的にはタグが付いたテキストであればよくて、そのタグがボイジャーのドットブック(ボイジャーが2000年に発表した電子書籍フォーマット。HTMLベースで、縦書き表示やルビに対応している。閲覧ソフトはT-TIme)なのか、シャープのXMDF(シャープが開発した、縦書きやルビなどの日本語組版に対応した電子書籍フォーマット。「電子文庫パブリ」などで採用されている)なのか、そのタグの名前が違うだけなんだから一括置換してしまえばいい。それはブラウザ側でも解消できるんじゃないの、最初に宣言しておけばいいんだから。
「私はドットブックファイルです」って宣言されたら、こういうタグがくるはずだから、このように表現するっていうふうになればいいって。ほとんどけりが着いていると思うんです。
けりが着いていないとしたら、写真や表組みは、相変わらず画像で入れなければいけない。だけど、表に関しては文字だからね。表を画像にして入れちゃうと検索できなくなっちゃう。たとえば、ドットブックは文字の検索はできるわけですよね。それが表のところはできないというのはいやなので、それがどうにかできないかなっていう問題が少し残っていますが。
あるいはEPUBは日本語の仕様がないからつくらなきゃいけないっていう問題が残ってたりしているぐらい。だけど、それだって、もう日本では先行事例があって、ドットブックやXMDFでも、ほぼ「ルビどうします?」とか、「禁則処理はどうします?」ということに関しては、それぞれ解決案は、もう持っていると。だから、それを共有すればいい。だから、電子「書籍」については、ほぼ決着が着いていると思うんです。
ただ、電子雑誌のような、つまりデザインを生かすようなものはものすごい混乱期にあって、決着が着いてない、解決策はまだ誰も示せていないと思う。
今ある、たとえば、本国の「WIRED」がiPad版で評判になったけれども、あれだって要は画像を毎ページ見せられているだけみたいな状態なわけですよね。全部画像でやるよっていうのは、それはそれで解決策のひとつである可能性はもちろん持っているとは思う。けど、まだまだだと思うんです。

深沢 そうですね。

沢辺 画像だと、本文に「深沢」という文字が入っているかどうかっていうようなことの検索のしようがない。「菅首相」というのが検索できないわけじゃないですか。そのへんがまだまだ解決できていない。
こういう状況の中で、いったん電子書籍を離れて電子雑誌、つまりデザイン性が強くあるものの電子化の解決策を考えていくと、結果、回り巡って電子書籍にもいい影響を与えられる可能性があるんじゃないかということで、主に今日は雑誌ということについて突っ込んでいろいろ聞いてみたいと思います。

●書籍フォーマットでは雑誌のデザイン性に対応できない

沢辺 僕はさっき言ったように「電子書籍と電子雑誌は区別して考えたほうがいいんじゃないの」って思っているんですけど、深沢さんはどうお考えですか。

深沢 基本的には、要するに雑誌なのか、書籍なのかっていう言い方の問題っていうのはあっても、たとえば、同じ雑誌といってもそれこそ文字ばかりの雑誌ってあるじゃないですか。『文藝春秋』とか。ああいうのはさっき言った電子書籍的な方法論で成り立つわけですよ。逆に、ファッション誌であるとか、複雑にレイアウトが入り組んでいるようなものに関しては、もうEPUBなんかではどうしようもないわけですね。ただ、今のwebを見たところでも、たとえば、それこそ表組みを全部画像にして張り込んじゃったり、文字を画像にして張り込んであるようなwebはけっこうありますよね。何が正しくて何が間違いなのかということは、やっぱり今はまだ始まってもいないようなところだと思う。

沢辺 電子雑誌に関しては。

深沢 うん。だから、あまり限定的に考える必要はないと思うんだけども、ただ「今それで何ができるのか」っていうことはやはり明確にしたほうがいいと思います。今、電子書籍というもので言われていること、EPUBであったり、それこそドットブックにしても青空文庫のXHML形式にしても、ただ単にテキスト、例えば小説のテキストを、パッケージングして読ませるというようなフォーマットとしては、もう本当に完成の域にいっていると思うんですね。
そのフォーマットの方の問題と、ブラウザ、リーダーの方の問題がありますよね。で、それが今けっこうごっちゃになっている。EPUBの日本語対応がどうのという時も、EPUBの方の問題なのか、それともリーダーの方の、実装の問題なのかっていうのがごっちゃになって語られていることが多い。
たとえば、複雑なレイアウトを、文字をざっと流し込んで読むような、よくいわれるリキッド的なやり方の中で表現していくことが、実際にどの程度必要になるのかどうなのかということを、もっと洗い出したほうがいいと思うんです。
実際問題として、今のEPUBとか、XHMLでもドットブックでも、そういう複雑なレイアウトは無理なんですよね。
何とかやろうとすると、さっき言った画像ではめ込むとかいうレベルの話になっちゃう。でも、画像ではめ込むのが最適解で、もうそれでいいですよというふうには誰も思ってないですよね。

P1040249.JPG

●今/これからの対応策は別々のフェーズで考える

深沢 じゃあ、どうすればいいのかということを考えていった時に、「今すぐだったらどういう解決策があるのか」「これからどういう解決方法をしていけばいいのか」それから「つくる時に、まずどういう準備をするべきなのか」と、全部フェーズが違うと思うんです。本当はそれを別々のフェーズで考えていかなければいけなくて、今あるものをすぐに、たとえば、iPadなり、Windowsの画面なりで見たいという場合の解決策と、これから何年後か、2年後、3年後とかにうちで出している雑誌を電子化して、何かデバイスに乗せて売りたいんだという場合の解決策というのは、意味が違うはずなんですよ。そういうのをひとまとめにして考えるべきではない。
たとえば今、電子書籍で何ができるのかということに関して言うと、僕自身はPDFがもう少し注目されてもいいと思っているんですね。最近、スキャンスナップとかで「自炊」する人が多いと思うんです。自炊というのは雑誌とか書籍の、のり付けのところを断裁して、全部スキャンした画像をOCRかけて、ひとつのファイルとして束ねてPDFにしちゃう。それを電子化した雑誌ということでモニタ上で見たりとか。

沢辺 あれ、自分でつくるから自炊っていうんですか?

深沢 そうです。出版社が用意したものじゃなくて自分でやりましたよっていう意味ですよね。それがけっこう受け入れられているんですね。(会場に)この中で自炊されたことがある人っています? (手を挙げた人に)やってみてどうですか。

会場 手間は掛かりますね。

深沢 でも、そのつくったものに関しては満足していますか?

会場 見る人が見ると、「これ、自炊したよね」って言われます。切り傷が残っているって。それはちょっと嫌だなと思います。

深沢 ただ、自分で紙で取っておくよりは便利というふうに思っています?

会場 場所を取らないっていうのと、それなりの検索ができるのが便利ですね。

深沢 検索、はい、そうですね。僕の周りでも自炊する人間ってけっこういるんですけども、やっぱり、やりだしたら「これでいいよね、これ便利だよ」っていう声のほうが圧倒的に多い。確かにもっときれいにならないか、もっとこういうふうにならないか、という話は聞くにしても、ベーシックなところでは「これで済んじゃうじゃん」っていう声をよく聞くんですね。
そうすると、じゃあ、電子書籍、電子雑誌って何だろうって、またそこに立ち返るんですけども。スキャンして、それで束ねただけでも、自動的にOCRの中にテキストを持っているんですね。そのためにある程度の検索ができる。それからテキストを抜き出したりすることができる。そうなってくると、最低限そのぐらいあったら何となく雑誌としての定義は保てるんじゃないのかなという話があちこちで聞こえるんです。
そうなってくると、じゃあ、どうしてリキッドじゃないと駄目なのか。もちろんリキッドの利点があるんですけども、リキッドじゃないものでも、電子書籍、電子雑誌として成立しちゃう場合があるんじゃないかな、ということをここのところ考えています。

●ページネーションがあるか、ないか

深沢 たとえば今、「電子書籍」と「webマガジン」では、イメージがすごくかけ離れたものとして考えている人が多いような気がするんですよ。僕が今日、こういう場に呼ばれているのもそうなんですけども、電子書籍とか、電子雑誌っていうのは今後、新しいビジネス展開があるんじゃないかとか、新しくマネタイズができるんじゃないか、新規参入ができるんじゃないか、今までの取次のシステムとは別の流通の方法があるんじゃないかとか、そういうみんなの思惑とか、希望だったり、今までの不満だとか、そういうのがあって。
で、何とか今のうちから勉強しておきたいというのがすごく多いと思うんですね。それはもっともなことだと思うんですけど。じゃあ、実際に今話題になっている「電子書籍」と「webマガジン」で何が違うのかっていうことを考えると、技術的にはほとんど同じようなものなんです。さっき言ったEPUBも、青空文庫のXHMLも、ファイルの作り方っていうのはwebとそんなに大した違いはない。
でも、どうもみんなのイメージの中では、webブラウザで青空文庫を読むのと、iPadやキンドルで青空文庫を読むのとは、ものすごく違う印象の持たれ方をしている。それはなぜなのかということをずっとここのところ考えていたんですね。
「マガジン航」っていうボイジャーさんのところでやっているwebマガジンでもちょっと書いたんですけども、僕の個人的な考えでは、やっぱりそれってページネーションなんじゃないかなと思うんですよ。
要するにページめくりがあるかどうかですよね。ページめくりがあるかどうかっていうのはものすごく重要だと思うんです。ページネーションではなくて、とにかくスクロールでもリキッドでも、テキストがちゃんと読めればいいんだっていう考えをする人も多いんですが、実はそうじゃなくて1ページの中、つまり1画面の中で最初から最後までが全部見通せる、縦組みであっても横組みであっても、1画面の中で最後まで見通して、最後にいった時点で何か自分で操作することによってページがリロードされて、また一から、左上から右下でもいいんですけども、目で追い掛けて読んでいく。写真とかそういうのが間に入ったとしても読んでいく。またページめくりをする。同じように読んでいく。その繰り返しのリズム。それが身体性とか、アフォーダンス(affordance)に直接かかわってくる。そうすると、何かパッケージングされた「もの」として評価して、じゃあ、それにだったらお金を出してもいいという人が出てきているんじゃないかなという感覚が僕の中にあるんです。要するに、マネタイズできるか、「商品」になるかどうかなんですね。

沢辺 ひとつはね。

●PDFの可能性

深沢 それがすべてではないんですけども、僕は大きいんじゃないかと思っています。で、そうやって考えていくとPDFってもう少し注目してもいいかなと思っているんですよ。今はまだ、PDFを徹底的に追求して、これが「今の時代の最高峰のPDFの見せ方だ」っていうのはほとんどないんじゃないかと思うんですよね。僕はけっこうPDFが好きでいろんなことを試してやっているんですけども、PDFってけっこういろいろ面白いことができるんです。みんな知らないんだけど、PDFはリキッドレイアウトもできるんですよ。
Adobeリーダーには「折り返し」という表示のメニューがあるんです。PDF内にテキストがあれば、「折り返し」を選ぶと画面の大きさに合わせて文字が折り返して表示されるんです。けっこう文字のレイアウトは崩れちゃうんですが。でも、基本的にはそれができる。それは何のためかというと、アクセシビリティ対応なんです。

沢辺 字をでっかくして読みたい人とか。

深沢 そうです。そういうのも含めてアクセシビリティ対応だとか、構造化対応だとかっていうことはPDFの機能にあるんですね。そういうものをうまく使って、小さい画面用/大きい画面用とか、当然レイアウトの場合はデバイスのサイズの問題ってあるんですけど。そういう対応をしていったPDFがつくれれば、紙でつくっている雑誌をこれから電子化していきたいっていうときに、ひとつの突破口になる可能性はあるんじゃないかなっていう気はしてるんです。

沢辺 ちょっと話が進みすぎましたね。一つ手前に戻りましょう。深沢さんは、webマガジンと電子雑誌、まあこの場合は電子書籍も含めてもいいけど、どう違うんだよ、同じじゃないかって思っているっていうことでいいんですか?

深沢 まったく同じだとは思ってないです。でも、みんな区別しすぎてしまっていると思うんですよ。ところが技術的にはそんなに変わりがない。じゃあ、電子書籍・電子雑誌と、webサイトやメールマガジンとの本質的な違いはどこなのかっていうことを考えていく必要があると思うんです。いろんな要素があって、まずコンテンツが完結しているかどうかとか、さっき言ったページネーションの問題、それからボリュームの問題もあると思うんですね。一定度のまとまったボリュームがないとやっぱり書籍、雑誌として認識しにくいものがあると思うんですね。今は、そういうことをいろいろ洗い出している。

沢辺 俺の感覚でいくと、パソコンでブラウザを開いていてwebサイトで長い読み物であったとしてもPDFがリンクされていると腹が立つ。

深沢 それは腹が立ちますよ。当然のことです。ただ、僕はPDFにリンクされていると、なぜ腹が立つのかっていうことを考える必要があるんだと思うんですよ。

沢辺 別のアプリを利用しなくちゃならなくなる。

深沢 要するにインライン表示できないんですね。

沢辺 俺は今、ブラウザを触っているんだよ、と思う。

深沢 そうです。通常のPDFは表示を待たされますから。

沢辺 ちょっと2〜3行読んでみて面白ければ先にいくけど、そのために、また別のAcrobatを起動したり。

深沢 そこもPDFの本当に駄目なところ。それまでのコントロールを放棄させられちゃうんですよ。

沢辺 特に役所のサイトだと、全部。

深沢 多いですね。それは僕からしてみると、PDFの古い使い方なんですよ。あんなのはPDFのまともな使い方じゃない、というふうに僕は思っているんですよ。
(会場に)たとえば、「FlashPaper」っていうのをご存じの人はこの中でいます? 知らない。FlashPaperってPDFの対抗馬で、マクロメディアが昔作っていたんです。

沢辺 「Dreamweaver」とかホームページをつくるためのプロ用ツールをリリースしていた会社ですね。

深沢 そうです。「FlashPaper」っていうのは、Flashの中でPDFと同じようなことを可能にしようというものなんです。要するに、ページネーションができて印刷ができて検索ができて拡大表示ができてっていうのをブラウザの中でやっちゃうわけです。

沢辺 うん、うん。

深沢 それがあったんですよ。5年ぐらい前まで。

沢辺 でも、何かあったね……ボタンを押すと……。

深沢 いや、ボタンも押さないで、もうブラウザの中でそれが直接見えている。僕はいまだにそれ、けっこうつくっています。
今、メインの仕事で「the能.com」っていう能のサイトをやっているんですね。そこで能の謡(うたい)のストーリーペーパーを、日本語と英語の対訳で、縦組みで、ルビ付けて、FlashPaperでwebのブラウザの中で表示できるようにしているんです。それはもともと、海外の人に向けて縦組みの日本語表記をどうやって見せるのかっていうところから始めたんですよ。FlashPaperはすごく画期的な技術だったのですが、Adobeにマクロメディアが買われちゃった時に捨てられてしまった。本当はAdobeがPDFをブラウザの中でインライン表示できるようにするだけで、随分違うんです。要するにブラウザの中でページめくりができて、印刷ができて、検索ができて、拡大ができてっていうことができれば、それで解決しちゃうものも多いと思うんですね。

沢辺 それ可能なんですか?

深沢 できます。とっくの昔にできてたんです。

沢辺 技術的にはできるが、Adobeがツールを提供をしてないっていうこと?

深沢 もうやめちゃったんです。

沢辺 それは「FlashPaper」?

深沢 Adobeがマクロメディアを買った時に、「このFlashPaperはPDFの対抗技術になっちゃうんでやめましょう」ということで捨てちゃったんですね。今AdobeのほうとしてはPDFではなく、Flashテキストの組版、日本語組版を含めて何とかしようということでTFL(Text Layout Framework)という新しい技術をFlashの中に組み込もうとしているんですね。しかし、Flashを使うのがいいかどうかっていうのが、たとえば、iPad、Appleの方針もあってちょっとあやふやになっちゃっているところもある。

沢辺 じゃあ、FlashじゃなくてPDF単体でも、もうちょっと頑張れば「FlashPaper」のようなことはPDFの中でもできる。

深沢 できるはずです。だって、5年ぐらい前、同じようなことをFlashPaperは実際にやっていたんだから。

沢辺 その当時は、Flashでやっていたの?

深沢 Flashでやってたんです。今、AdobeはFlashもPDFも両方持っているわけですよ。要するにFlashのプラグインの中でPDFをインライン表示するっていう機能を持たせればいいだけの話じゃないかな。そんな難しいことじゃないだろうと僕は思っているんだけども。それができたら解決しちゃうことってたくさんあると思う。
それと同じことを考えていたのがアメリカのScribd(スクリブド)っていう会社です。僕は随分前からずっと注目していたんですけども、Scribdは「YouTubeの文章版サービス」なんですね。自分で何かPDFをつくった、Wordで論文を書いたよとか、テキストファイルで何か小説を書いたとか、それをほかの人に見てもらいたいとき、AcrobatやWordを持ってない人へも、web上でページネーションして見せたいというときに、Scribdに自分のアカウントをつくってアップロードしちゃうんですね。そうすると、自動でページネーションされて公開される。

沢辺 アップロードしちゃうの。それは対応するフォーマットっていうのは?

深沢 PDF、テキスト、Word、パワーポイント、そういうたぐいですね。

沢辺 それがあれば。

深沢 何でもアップできる。YouTubeがなぜこれだけ広まったかというと、以前はいろんな動画フォーマットがあったんです。たとえば、RealAudioとかQuickTimeとかいろんな種類があったんだけども、webで動画を公開するには、使っているネットの速度によってだとか、画面の大きさによってだとか、Mac用、Windows用とか、いろいろな種類を用意しなければいけなかった。見る側も自分の環境にあったプラグインが必要だった。動画サイトをやっている人はわかると思うんですけど、エロ動画サイトに行くと、いろんな種類があったじゃないですか。

沢辺 それはわからないな(笑)。

深沢 わからないんですか。残念だな(笑)。みんなそれで苦労したんですよ。「あっ、Macだと見えないや」とか。そういう面倒なことを解決したのがYouTubeなんです。YouTubeのすごかったのはFlashムービーを使ったんです。要するに、動画なら何でもいいからとにかくアップしちゃえば、自動でFlashムービーに変換してみんな誰でも見られるようにしますよって。
同じことをScribdはやってるんです。テキストとか、Wordとか、文章であれば、何でもブラウザ上でページネーションしますよと。でも、Scribdは「FlashPaper」でやっていたのですが、去年からそれを全部HTML5(HTMLの最新仕様バージョン)でつくり直しますってシステムにして、今、それをやっている最中なんですね。
たとえば、それをただで見せたくなくて売りたいっていう場合、アップするときに「有料」を選んでおけば、それを見た人からお金を取ってあなたの口座に振り込んであげますよというところまでやっているんです。それに乗っかっている出版社ってアメリカではけっこうたくさんあるんですよ。こういうのを見ていると、まだまだ新しい技術うんぬんっていうよりも、もう少し、たとえば今あるPDFとか、そういうものでも。

沢辺 可能性はまだあると。

深沢 普段持ち歩くようなコンピュータってノートパソコンくらいしかなかったのが、今、iPadなどのデバイスが出てきて、電車の中でも見られるぐらいにはなったわけですよ。そういうところに向けたPDFの在り方ってどうなんだろうとか。またiPhoneやAndroidなどの、小さなディスプレイで見るのに適したPDFとかっていうのは、もっと「こういうのがあってもいいんじゃないか」ということを提案したほうがいいと思うんです。

沢辺 じゃあ、PDFの可能性ということをもうちょっと掘ってほしいんですけど、そこに行く前に、Adobeがちゃんとやれば、ブラウザの中でPDFをもっと見せることができるよ、と。

深沢 別に、僕はPDFにこだわっているわけではないんだよね。

沢辺 わかる、わかる。ひとつの例として。

●「今ある」ものを徹底的に追求すること

深沢 すでにある技術でも、もっと徹底して使い込んじゃえば、いろんなことができるんじゃないのって思っているっていうことなんですよ。
一番最初の話に戻りますけど、僕がDTPをやりだしたとき、日本語のフォントはモリサワの「細明朝体」と「中ゴシック」の2書体しかなかったんですよ。その時、僕は翔泳社っていうところの仕事で、翔泳社の篠崎さん(現SEデザイン取締役・篠崎晃一氏)と小林弘人氏と一緒にIBM PCのマニュアルをつくったんです。その2書体だけでつくったマニュアルは評判が良くて、マニュアル大賞のデザイン賞か何か賞をもらったらしいんですけど、2書体のDTPでもいろいろ工夫すると、きれいで読みやすくてすてきなものができるんだ、ということを再確認したんですね。僕は書体が少ないからデザインができないっていっているのは、ただの甘えだと思っている。もちろん書体はたくさん使えるにこしたことはないし、いい書体を自由に使えるべきなんですよ。だけども、それが今手元にないんだったら、手書きにしたり写植をスキャンして貼込んだって構わないじゃないか、と思うんです。

沢辺 活版時代のやり方ですよね。

深沢 そうです。でも、それでも、ユーザーにきちんとしたものが届けられれば構わないんじゃないかと僕は思っている。それと同じことなんです。
今、電子書籍でこれは技術的にできないとか、これはまだこうだから、という話を多く聞くけども、じゃあPDFを突き詰めたことがあるのかよと。今のHTMLを突き詰めて何かつくったことがあるのかよという、そっちのほうが僕にとっては重要な課題なんですね。

沢辺 なるほど。1回整理すると、取りあえず、今まで電子書籍といわれていたものはリフローすることが前提だ、みたいなふうになっていったが、電子雑誌はリフローできればいいかもしれないけど、できなくてはいけないものじゃないかもしれないよね、デザインに関しては。でも、多分、この「デザイン」っていうことは決定的な気がするんだよね。

深沢 そう思いますね。

沢辺 今までの電子書籍にとどまらないで、もっと違うもの。たとえば、写真だとか、絵だとか、最低限、今、入っているものを活かすためには、そこにデザインがなければつまらないし、きれいじゃないし。
「デザインを固定化する」ものを電子雑誌っていうふうにくくれるのかどうかわからないけど、そういうものが電子書籍/リフローするものと区別されるとしたら、その理由のひとつにはデザインの重要性があるっていうことは立つ、と。
その際に、とはいえ、僕はやっぱり、たとえば、カットアンドペーストできるとか、検索できるとか、そんなのもない。ただの画像というのもひとつの試みとしては別に否定するべきではない?

深沢 いや、それはもう否定していいと思いますよ。

沢辺 電子書籍の中で深沢がこんなことを言っていた、みたいなこと、それをコピーペーストしてTwitterに貼り付けて。

深沢 それはできなきゃ駄目だと思いますよ。

沢辺 何のために電子でやっているの? みたいな。

深沢 それは、もう本当にそう思いますよ。

沢辺 だったら、自炊でいいじゃんっていうのは?

深沢 いや、僕が言っているのは自炊とか、スキャンしたものでさえもそこそこの検索性があれば、納得している人がいるんだよという話なんですよ。そういう人がいるっていうところに「絶対にリキッドじゃないと」っていうことを、大前提として出しちゃっても、あまり現実味を感じないんですね。
今、テキストを埋め込んだPDFだったら、文章を検索することもコピペすることもできますよね。どういうつくり方が一番ベストなのかっていうのは、はっきりいって、まだ今の時点ではHTML5なのか、それともPDFなのか、それともEPUBのバージョン3なのかわからないわけですよ。出てきてもいないんだから。実際にはHTML5にしたって、EPUBの3にしたって。まだ今後どういうふうになるのかわからない。どういうふうになるのかわからないものに対して、今から困った、困ったという必要はなくて、今、できることをやればいいというふうに基本的に思っている。
今、できることのひとつは、webとの親和性みたいなもの、それから構造化みたいな問題とか、PDFもひとつの方法だよねっていう話をしているんです。そういうことですね。

沢辺 最初、俺は「WIRED」みたいな画像をぺらぺら紙芝居みたいにして見せるぐらいの方法しか、今のところ提示されていません、なんて言ったけど、いやいや、実は、今、電子雑誌、電子書籍と提示される以前からあったPDFとかで、徹底的にやれることを突き詰めてないと。

深沢 そうそう。それが言いたい。

沢辺 「沢辺、おまえ、今後の新技術ばかり追い掛けているんじゃなくて、今ある細明朝と中ゴシックでどこまでできるかっていう方向もあるじゃないか」と。

深沢 そうそう(笑)。

沢辺 「フォントが出てくれば、僕のデザインがよくなるなんて、そんなん、おまえの腕が悪いからだよ」と。

深沢 いやいや(笑)、そりゃ出てくるにこしたことはないんですよね。ただ技術だとか、そういうものって、その範囲内で物事を考えていると、やっぱり何かものをつくる人間としてはすごく情けないんじゃないかなっていう気がするんですよ。だから、電子だろうが紙だろうがもちろん見てもらい方とか、流通の仕方とかがいろいろ違うわけなんですよね。

沢辺 じゃあ、PDFで、このへんまでできるんだぜっていうことを、いくつか具体例を挙げてください。さっき聞いたところも確かにあるけどね。

●文書の構造化/FrameMakerというDTPソフト

深沢 たとえば、PDFに限らないんですけども、InDesignには「構造化」っていうメニューのボックスがあるんですよね。InDesignで雑誌のデザインをしている人間で構造化のウインドウを開いたことがある人って、ほとんどいないと思うんですよ。僕はけっこういろんなデザイン事務所に行くんだけども、まあほとんどいないですね。

沢辺 構造化って何?

深沢 その話になっちゃうんですよ。たとえば、AdobeがInDesignのほかにFrameMakerっていうDTPソフトを出しているんですけども、そのFrameMakerっていうのを実際に触ったことがある、見たことがあるデザイナーもやっぱり非常に少ないと思うんですね。一般的なところでは。ところが、FrameMakerってある業界では、もう圧倒的なシェアというか、絶大な信頼を持っている。FrameMakerじゃないと、とにかく自分たちのドキュメントの作成ができない。印刷もできない。InDesignじゃ駄目なんだって言っている人たちがたくさんいるんです。

沢辺 まだあるんですか?

深沢 だから、Adobeが手を離さないんです。FrameMakerはInDesignと同じくDTPソフトですが、縦組みはできなくて、横組みしかできないんです。しかし、一番の特徴はXMLと親和性が高いんです。
FrameMakerがどこで使われているかというと、マニュアル関係なんですよ。
普通の人たちはあまり知らないかもしれないけど、たとえば、乗り物や工場の大型機械などの操作手順が載っているようなマニュアル、それから電子機器、コンピュータソフトとか、家電、そういうものの分厚い何千ページもあるようなマニュアルは、もうほとんどがFrameMakerでつくられているんです。

沢辺 何千ページもあるっていうことは、俺たちが目にしない、それをつくるメーカーの人同士とか、修理をするような人たちに配るような?

深沢 たとえば、飛行機のマニュアルとかね。あと自動車の修理用のマニュアルとか。

沢辺 ということは印象で語っちゃうけど、すごく章、節、項とか、1章の1とか、1-1-1とか。

深沢 そうです。ものすごくきちんと、つまり構造化されているわけです。

沢辺 InDesignでいうと、小見出しの文字をぱっと選んで「ゴシックMB101/20級」とかできちゃうわけだよね。FrameMakerはそれをやらせないぐらいの勢いのソフトなんですね。

深沢 まあ、できはしますけど、基本的にはそういう使い方をするためのソフトというよりも、今、言ったように「章があって」→「節があって」っていうふうに、もうどんどん構造化してある。

沢辺 章の大見出しを選んで44級とか、でやらずに「これは章である」、という視点で。

深沢 意味合いで全部の文章を作成するんです。そういうかたちでまずマニュアルをつくる段階から、テクニカルライターにこういうマニュアルを書けというルールで文章を書かせるんです。そういう方法論で書かれた文章だから、ざっと流し込むと図版との組み合わせでマニュアルが全部レイアウトされちゃうんですね。で、そこに対してデザイナーがいろいろいじることもできるんだけれども、そこから今度はHTMLマニュアルとか、ディスプレイ用のマニュアルに書き出すことができるんです。もう電子書籍ですね。

沢辺 PDFとか?

深沢 PDFにもできますが、たとえば、ソフトを使っていて「ヘルプ」のところを選ぶとweb画面みたいなかたちでWindowsヘルプとか別ウインドウが出てくるじゃないですか。ああいうのはFrameMakerから書き出すことが多いんです。そうやって文章を構造化しておくと、今度は多言語対応ができるんです。要するに、構造化されているから自動翻訳ソフトにかけやすい。英語に変える。英語に変えてからスペイン語に変える、ポルトガル語に変える、ロシア語に変える、それから、ハングルに変える、中国語に変えるっていうことをやる時に、大体翻訳ソフトでTRADOS(トラドス)っていうのを使うんですね。そのTRADOSっていうのは、僕らが普通目にする自動翻訳のソフトとはちょっと違って、文章を構造化することで翻訳精度がどんどん上がっていく。

沢辺 でも、構造化されていようが、されていまいが翻訳という意味では変わらなくないですか?

深沢 いや、それが全然違うんですよ。構造化されてないと翻訳の質が上がらないんですよ。要するにこれは何について語っているものなんだっていう、今までの実例を持ってくることができないんですよ。

沢辺 なるほど、ある種のシソーラスということ。

深沢 そうそう。シソーラスなんです。それはアルゴリズムなんですけども、僕らが考えている翻訳ソフトっていうのは、ただ単に辞書の項目みたいなかたちで持ってくるじゃないですか。ところが、TRADOSの翻訳というのは、今までこういう流れの中で使われた言葉の対訳は、これが多いというようなことが行なわれる。
もちろん最終的には人間の目で直さなければ、自動翻訳なんて信用できないんですけども、ただ、もう圧倒的にTRADOSを通すことによってスピード、コストに対するメリットが出てくるんですね。だって、何千ページもあるマニュアルを人間がいちいち翻訳していたら、コストのことを考えたらもうほとんどやっていけないですからね。だから、彼らは文書の作成の構造化を徹底的にやってるんですよ。そういうことをやっている人たちっていうのは世の中にいて、実はけっこうそういうのは進んでいる。
つまり、FrameMaker的っていうのは、XML的っていうことなんですね。FrameMakerがなぜそういうことに使われたのかっていうのは、XMLで構造化して、全部データベース化できるから。
テキストを、人間が頭から終わりまで読んでいくようなもの、とだけして考えていくんじゃなくて、ものすごく分割して意味合いで分けて、データベースの中に格納しておく。それが全部そのまま今の雑誌だとか、書籍だとかに通用するとは僕も思わないんだけども、あまりにも今の雑誌だとか、書籍だとか、そういうことをしなさすぎているところがあると思うんです。
だって、おそらく雑誌をつくっていたり、小説を出版している出版社で、たとえば、使った写真だとか、図版だとか、著者からもらった原稿のテキスト、Wordっていうのを全部ファイル名とか、一覧ですぐ取り出せるようになっているかっていったら、ほとんどなってないでしょう。個人に任せたらめちゃくちゃになるのは当然です。どのフォルダに入っているのかわからないとか、どこかフロッピーに入ってどこかの机の奥にあるはずだとか。

沢辺 大体データはわからないね。

深沢 そんな感じなんです。印刷所の今の書籍の対応っていうのもやっぱり似たり寄ったりなんです。たとえば、印刷所に書籍でつくったものを今度はwebにそれを転載したいんでテキストでくださいってもらったテキストを見てみるとわかりますけども、もうはっきりいって頭を抱えちゃう。これだったら、もう一から入力し直すか、それこそ全部スキャンしてOCRで読み直したほうが早いっていうものが多いんです。でも、そんなことを実際やってられないですよね。

沢辺 やりたくない。

深沢 だから、やはり最低限のところで、共通フォーマットでも何でもいいんだけども、何とか構造化してこれは本文だよ、これは誰々が書いた何とかっていう原稿だよっていうぐらいでもいいから、業界全体で何かルールを決めて持っているという、そっちのほうを優先したほうがいいんじゃないかなっていう気がしているんですけどね。

●リフローできる/できないは重要か?

沢辺 僕の質問とちょっとずれていますよ(笑)。PDFで今、どこまでできるのか。この質問から出発したから。

深沢 “PDFだけ”でどこまでできるのかっていうのは答えにくいんですよ(笑)。さっき言ったようにPDFの中には構造化の機能だとか、読み上げの機能だとか、それこそテキストの折り返しの機能だとかっていうのは不十分ながら、やっぱりあるんだよっていうことぐらいしか、僕のほうではいえない。

沢辺 当然想像できるけど、PDFは、裏側に、という言い方をすればいいのかな。テキストを持っていれば、OCRをわざわざかけなくても。

深沢 いや、PDFってちゃんと作ればテキスト埋めこみじゃないですか。だから、テキストを選択できるじゃないですか。

沢辺 うん。できる。選択できるし、それをコピーしてどこかに貼ることもできる。そういうことができるし、当然検索もできるよね。

深沢 できます。

沢辺 文字が入っていて。でも、順番、流れか。

深沢 そうです、順番。さっき言ったように文章のものはテキストの途中にノンブルだとか、キャプションが入り込まないように分けたい。その順番をちゃんと決めたい。それはInDesignやAcrobat上でも可能なんですよね。
ただ、さっきPDFでここまでできるということで、リキッドと固定レイアウトの話が出たんですけども。現状のPDFはサイズにすごく左右されるっていうのがありますね。今、リキッドが出てきてるというのはサイズに左右されないっていうのが一番の利点としていわれていると思うんです。

沢辺 ごめん、この場合のサイズって何のサイズ?

深沢 ブラウザのウインドウのサイズですね。

沢辺 要はiPadで見せるのか、iPhoneで読ませるのか、それともパソコンのモニターで見せるのか。そのことを言っているんですね。

深沢 そうです。今、リキッドじゃなければって言っている人の話は大体そのへんからきていることが多いですね。

沢辺 そういうサイズの問題と、もうひとつ、老眼がよく語られますよ。アメリカでKindleがはやったのはじいちゃん、ばあちゃんが「読みやすい」って喜んだから。大体、そういうふうにいわれてますね。

深沢 はい。僕も老眼なんでそこらへんはすごくわかるんだけども。実はそのへんのユニバーサルデザイン(年齢や障害の有無などに関わらず、すべての人が利用することのできるものや場所、情報のデザインのこと)とか、それからアクセシビリティみたいなものっていうのは、実は本当に必要な人のためのものというよりも、団体とか、企業のエクスキューズとして使われることのほうが多いんじゃないかなって僕は考えています。

沢辺 俺が振っちゃったんだけど、まず、ユニバーサルデザイン系の話はちょっと横に置いておきましょう。リキッドが必要、というのは、デバイス、見る道具のサイズ問題じゃないかと。

深沢 そうですサイズの問題じゃないかと思っているんです。
僕は、サイズってそんなに可変である必要があるんだろうか、ていうことをもう少し根本的に考えたほうがいいんじゃないかなと思っているんですよ。たとえば、雑誌というのは可変サイズじゃないけども、それによってものすごく不満があるという話はあまり聞かない。たとえば、見えにくかったら老眼鏡を掛けるというのもひとつのソリューションなんですね。それと同じようにiPhoneが今度同じデバイスのサイズで、解像度だけ高めてすごく密度が細かくなった。それによって見やすくなったということ。だから、大きさっていうのが、絶対的な条件として言われているのかどうなのか、という根本的なところに立ち返って考えたほうがいいんじゃないかなと僕は思っているんです。

沢辺 昔、鈴木一誌っていうデザイナーが「ぴあ」の欄外情報、あんな小さい、6級か7級ぐらいですかね。あんな小さいものを熱心に読んでいる人がいるぐらいだから、新聞は字をでっかくしようとか、そんなことばかりいってるけど、読みやすさというのは相対的なものだ、みたいなことを言っていましたね。

深沢 ははは(笑)。でもそういう側面ってものすごくあると思うんですね。読みやすい、読みにくいっていうのはやはり絶対軸を持っているものではないので、慣れっていうのがすごく大きいと思うんです。特に組版に関しては何がルールなのか。組版のルールっていろいろいわれていて、調べれば調べるほど、組版って結局慣れなんじゃないのっていう結論が僕の中にあるんですね。要するに、たとえば、50年ぐらい、これでいけっていうふうに押し付けられたら、もう50年後はそれが一番読みやすい組版になっちゃう可能性ってあると思うんですよ。

沢辺 ちょっと言い過ぎだと思うけど(笑)。

深沢 でも、そういうふうに思える歴史って、調べてみるとたくさんある。
僕が今回いいたいのは、「デバイスの大きさってそんなに可変である必要があるのか。そこまで自由にさせたほうが果たして親切なのか。逆に不親切なんじゃないか」ということです。

沢辺 たとえば、『AERA』を電子雑誌にしますと。iPhone版だと本文が9級、1ライン12文字とかで、iPadだったら二段組いけるよ、みたいになって、24インチのモニターで見たときは自動的に13級になったりして、16文字でリフローするとか、ちょっとしたサイズの違いに移動している時に、そこまで対応してやる必要があるのかよっていう話?

深沢 というか、要するにそれをつくる側のことを考えてみろよっていうことを本当は言いたいのね。

沢辺 労働者の切実な叫び(笑)。

深沢 だから、実際にDTPとか、webをやってみるとわかるんですけども、たとえば、リキッドでデザインをするというのは、ありとあらゆるパターンを想定してデザインしなければいけない。それはものすごく大変なことなんですね。ただ単にテキストだけ流し込む、1行が20字でも80字でも構わないというようなものであれば構わないんだけど、僕ら、たとえば、装幀とか、ブックデザインとか、組版をやったことがある人間というのは1行が20文字なのか、40文字なのかっていうのは全然違う。
たとえば、1行で、その文字と文字の間が一歯詰めなのか、それとも文字が仮想ボックスいっぱいのフォントなのか。それによっても文章を読んでいくときのスピード感も圧倒的に違う。それに最適化したものをつくろうとしているのがブックデザインだったり、装幀だったり、組版だったりというもの。
で、リフローの電子書籍というのは取りあえずそれをチャラにして、全部リーダー側の、デバイス側のほうの能力で自分が何とかしたい人は何とか調整すればいいじゃんっていうような考え方なんですね。それはそれで腑に落ちるというか、納得できる人はお好きにどうぞっていう感じはするんですけども、でも、それが最適解なのかっていわれたら、それは違うだろうって僕は思ってるんです。僕の基本的な考え方としては、サイズなんて2種類くらいあればいいんじゃないかなって思っているんですよ。

●サイズはA5とA8、そのふたつでいいんじゃないか

沢辺 電子デバイスに?

深沢 そうです。要するにポケットに入れられるサイズと鞄に入れられるサイズですよ。そのふたつがあれば、基本的には済んじゃうんじゃないかなと思ってるんです。だから、iPhoneとiPadでもいいし、Appleが嫌な人はAndroidとキンドルでもいいけど、ポケットに入るサイズと鞄に入るサイズ。鞄といってもピンキリあると思うんですけども、iPadが入るぐらい、B5ぐらいのサイズですよ。

沢辺 あっという間に廃れましたけど、ネットブック。あれも同じような画面サイズですよね。

深沢 画面サイズで言えば、A8(74mm×52mm)とA5(210mm×148mm)ぐらいかな。

5023878856_ff94aacff9_o.jpg
●iPhone(画面サイズ約A8と)iPad(画面サイズ約A5)

沢辺 iPhoneとiPadの中間が出るっていううわさがあるじゃないですか。

深沢 中間が出たっていい。そうしたら、それに近いやつで読めばいいんですよ。そうやってリキッドで自由にする、要するに読む側に委ねちゃうっていうやり方が果たして最適解なのかどうなのかっていうのは、もうちょっとみんな考えたほうがいいんじゃないかな。もちろん、それが最適解である可能性もあるんですよ。だけども、僕はちょっとどうも今の時点ではあまり思えない。

沢辺 俺もそれはそう思えないですね。

深沢 たとえば、A5のサイズでiPadのサイズだったら、見開き表示にすれば、17〜19インチのディスプレイで見るのにちょうどいい感じになるんですね。それだったら、それでいいっていう感じがする。この紙(紙を持つ)のサイズがA4(297mm×210mm)ですよね。半分にすると、これがA5のサイズで大体iPadのサイズ。これをA6、A7、A8と折り曲げていけば、ちょうどiPhoneの画面サイズ。規格サイズっていうのは今までずっと何十年もの間、世界中で使われてきた利点もある。まあ、別に規格サイズにこだわる必要は全然なくて、四六(四六判を指す。一般的な単行本のサイズ。188mm×128mm。B6サイズに近い)だろうが何だろうが全然構わないんですけども、そのぐらいの考え方でいいんじゃないかなっていうふうに僕は思っている。労働者が徹夜をしなくて済むし、つまらないことで頭を悩ませなくても済む。

沢辺 でも、お金をもらえればいいじゃない。

深沢 もらえるんだったらいいんですよ。何でも、何種類でもつくれるし。

沢辺 出版社が出すならね。

深沢 そうです。たとえば、ユニバーサルデザイン、webなんかでもそうなんですけど、ユニバーサルデザインにしてくださいとか、アクセシビリティをもっと考えてくださいという要求がくるとき、追加料金ってもらえないことのほうが圧倒的に多いんですよ。製作側の人は、もうみんなうなずいていると思うんですけども。

沢辺 うなずいていますねぇ。波のようなうなずきが。

深沢 団体や企業のエクスキューズなんですよ。そのエクスキューズは下のほう、作業をしている人間に押し付けられることのほうが圧倒的に多いんです。
たとえば、今のiPadの「WIRED」の電子マガジンみたいに縦横で見られるっていうのは、今はまだ魅力的かもしれないけども、今後それが魅力的な商品として当たり前になっていくのかどうなのかっていうことも真剣に考えたほうがいいと思います。みんながiPadみたいな電子デバイスで雑誌を読むのが当たり前になった時代に、わざわざ縦位置の版面と横位置の版面のふたつをつくってくれって。

沢辺 (iPadで「WIRED」を見る)

深沢 これを横にしてみると、変わりますよね。これは縦と横を別にデザインして2パターン、InDesignでデザインして、それをAdobeのDigital Publishing Platformで書き出しているんです。書き出して全部画像にしたやつをXMLファイルでまとめているんですけども、デザイナーは単純労働で2倍の仕事をしているんですよね。

沢辺 まあ2倍とはいえないでしょう、1.5倍ぐらいでしょう。

深沢 まあ1.5倍ですかね。とにかく仕事が増えている。今の時点では1.5倍だったら1.5倍は物珍しさがあってマネタイズできているのかもしれないけども、今後こういうふうな電子デバイスで雑誌を読むのが当たり前になってきたとき、そうやってふたつのパターンをつくっていかなければいけないものなのか、どうなのか。デザイナー側にそれだけお金を払うべきなのかどうなのか。

沢辺 利用者が結局はお金を払う。

深沢 そうです。結局、そうなるんです。

沢辺 これのためにみんな500円のものを800円で買ってくれるか。

深沢 そうです。じゃあ、誰がお金を出すのか。誰がそのコストを負担するのかみたいなことまで考えてやっていかないと、電子出版というものが成り立たないような気がするんですよ。そうなった時に、たとえば、広告的なものだったら、どんな見せ方をしたって自由なんで、お金が出るんであれば、いろんなことをやればいいと思うんですよ。でも、雑誌っていうのはそういう考えでつくれるものじゃない。出版というものは、「ものすごくお金を掛けてつくったから、高い金額で買ってください」と成立させることはやっぱりなかなか難しいんですね。

●データベースからの自動組版

沢辺 (会場に)ご質問のある方はいらっしゃいますか。

会場 InDesignで「構造化」のメニューを選ぶと、何をやることができるんですか。

沢辺 そもそもどこにあるの? 俺も知らない。

深沢 構造化、メニューの中にありますけど。定型物の自動組版に使う以外では、今の時点ではまだそんなにできることはありません。どの部分が本文でどの部分が章で、といった、さっき言ったタグ付けですね。
それをPDFに書き出したあと、アクセシビリティ対応とか、そういうところに持っていきやすいぐらいの感じです。

沢辺 (他の会場の人に)ご存じでした?

会場 確認はしています。

深沢 ありますよね。ただ、実際に使っているデザイナーはあまりいないと思う。まだその使い方も結局、InDesignとXMLの書き出しの使い方というのも結局、自分で決めなければいけないんですよ。データベースを用意して、InDesignから書き出したものをどういうふうに扱っていくのか、みたいなことをシステム的に考えていかなければいけないので。構造化ウインドウはあるけども、じゃあ、それですぐ何かやればどうにかなるっていう話にはなかなかならないんですよね。
たとえば、InDesign Serverって知ってます? 僕も実際には見たことがないんですけど、見たことありますか?

会場 仕様書は見た。あとカタログはいろんな方からいただいていますし、調べましたけども、いちデザイン事務所が入れるようなものではないですよね。

深沢 そうですよね。でも、InDesign Serverみたいなものを見ていくと、結局、普通にページネーション、テキストを置いて、写真を置いて、図版を置いて。こうしてああしてというふうに考えていくような感じのデザインのやり方ではなくて、ばーっと流し込んでいくやり方。たとえば、通販のカタログ雑誌とか、ああいうのはやっぱりXMLと絡ませて自動組版に近いようなかたちでやっていくことが多いと思うんですよ。そういうわーっと流し込んで出来上がっちゃうというような雑誌のつくり方と、一枚一枚のページの中のいろんなものを手でこっちに変えてみたり、あっちに変えてみたり、それからテキストを大きくしてみたり、小さくしてみたり、そういうことが必要な雑誌とでは構造化というものの考え方そのものがやっぱり違うと思うんです。何でもかんでも構造化といっても、マインドマップ的な構造化ができるとは限らない。どちらかというと、できないことのほうが多い。

沢辺 俺の認識が間違っているかもしれないんですけど、InDesignって写真を置くじゃないですか。その下にキャプションを付けるじゃないですか。これって何らかの設定をすると、この関係性がつながるということは?

深沢 できますよ。

沢辺 できるんだ。全然意識してないよね。

深沢 できるけども、それはけっこう面倒なんですよ。機能としてはありますよ。でも、僕も実際使ったことはない。大体僕は自分の範囲でできる作業しかしてないから、さっき言ったInDesign Serverみたいな、何というのかな。それこそ何百ページもある、たとえば、アスクルのカタログみたいなね。ああいうのをざっととにかくデータベースから持ってきて全部流し込んでつくるというような感じのことは実際にはやってないです。

沢辺 アスクルのカタログ見てると、(自動組版は)できそうもないんだけどな。

深沢 でも、ああいうのはかなりのところが、実際やってますよね。

沢辺 アスクルやってるのかな。

深沢 そうじゃなければ、半年に一度、あのボリュームを、全部のデータを更新して、つくるっていうことは不可能ですよ。あれを1ページ、1ページ、デザイナーがやっていたら、多分、デザイナーが10人ぐらいのチームを組んでもみんな死にますから。

沢辺 でも、何かイレギュラーがいっぱいあるように感じる。

深沢 イレギュラーに見えるような設計にしてるんですよ。

沢辺 あれ、設計か……? どうもできそうもないような気がする。

深沢 イレギュラーに見えるような設計はけっこうやっぱりできるんですね。要するに、パターンを何パターンか持っていて、そこから外れるようなページの場合はどういうふうにしようかという感じで。まあ、アスクルが実際にやっているかどうかわからないですけどね。

沢辺 パターンを抽出するってものすごく大変だなって。単位が変わるじゃないですか。だから、ガムテープだと白、黒、茶、黄とかって横軸にあって商品番号があって、縦軸には1巻/5巻セット/段ボール1箱セットとか。このぐらいだったらいいんだけど、それが今度は鉛筆の場合とか、替え芯が出てくるとか、俺の頭はこのあたりで既にパンクしてしまう(笑)。

深沢 やっぱりデータベースの設計なんですよね。結局、もう完全にデータベースのほうの設計をどうするのかというところから始まって、そっちをきちんとつくっておかないと、カタログにしたりとか、webカタログにしたりっていうものは対応できないんじゃないですかね。

P1040238.JPG

●データを構造化する意義

沢辺 会場からいかがですか。

会場 先ほど深沢さんはリキッドであるべきか否かっていうのをもう1回考え直したほうがいい、それはなくてもけっこう満足できるんじゃないかみたいなことはおっしゃったと思うんです。その話とやっぱり電子雑誌をつくるにあたってデータそのものを構造化させておいたほうがいいっていうのは違う話、という認識でいいんですか。

深沢 違う話だと思います。要するにリキッドっていうのは表示の方法のひとつでしかなくて。でも、たとえば、構造化をしておくっていうのはさっき言ったように全く違うものをつくっていく、たとえば、さっき例に挙げたのはサイズのパターンでしかなかったんですけども、全く違うデバイスが出てくる可能性も今後あると思うんですよ。だから、webが出て、それから今度はこういうスレート型のデバイスが出て。もしかしたら、もっと全然違うものが出てくるかもしれない。壁に映すようなものになるのかもしれないし、それこそ音声リーダーで聞くことを前提にした電子書籍になるかもしれない。そういういろいろな展開が出てくることっていうのが今後あり得るわけですね。その時に、じゃあ、リキッドうんぬんというよりも、とにかくもう「文章のここからここまではこの記事で、誰が書いているんだよ、何が図版としてくっついてくるのか、キャプションはこうだよ」、みたいなことを何らかのかたちで構造化しておかないと、使い回しはできない。
だから、リキッドうんぬんかんぬんというのは、見せ方の方法論のひとつでしかなくて、構造化というのはもっと根本の部分だと思うんですよ。構造化というのはやはりDTPの段階でも構造化しなきゃいけないけども、原稿を書く段階でも構造化しなきゃいけないし、編集者も原稿をもらった後、どうタイトルを付けて見出しを付けていくのか。それから、どういうフォーマットで、どういう文字コードで、どういうファイル形式で保存するのかということも構造化の一部なんですね。
さっき、Twitterで武蔵美の今泉先生が、

————————————————————————–
雑誌って「雑」っていうぐらいだからマニュアルとはかなり距離がある。さらに基本的に「気分モノ」だから構造化は難しいだろうな
@imaitsme
Hiroshi Imaizumi
●http://twitter.com/imaitsme/status/22168572985
————————————————————————–

深沢 と載ってたんですけども、多分、本来の意味でのデータベース的な、XML的な文章の構造化っていうようなことでいったら、当然のことながらすごくやりにくいと思います。入り組んでますからね。でも、入り組んでいても、じゃあ、その中からたとえば、テキストと写真をある程度抜き出して考えたり、ブロックで考えたり、それこそページごとに考えたりぐらいの構造化でも、やっぱりやっておくのとやっておかないのとではものすごく違いが出てきますね。それは製作の段階で常に付きまとってくる。
構造化というのはすごく、……何というのかな、何か言葉が堅いじゃないですか(笑)。コンピュータの世界ではオブジェクト指向という物事の考え方をするんですね。とにかく何でも部品にして置いておこうよという考え方なんですよ。プログラムを書くときに一から、頭からずっと終わりまでプログラムを書いて、ひとつのプログラムを命令としてコンピュータに実行させようというようなことでは、長いプログラムを書くときにはすごく大変になってきちゃって、バグを探して直すのも大変だし、それから何人かで手分けして、ちょっと新しい機能を追加するっていうこともできなくなる。だから、オブジェクト指向ということが何年ぐらい前なんでしょうね。30年とか、40年とか、もっと前なのかな。あまり僕も詳しくは知らないけど、とにかくかなり昔からオブジェクト指向のプログラミングっていうのがいわれたんですね。
それは要するにプログラムの命令を部品化して持っていこう。部品化してヒエラルキーみたいなものをつくって。で、管理していこうと考えた。僕はプログラマーじゃないんで、もしかしたら誤解があるかもしれないんだけども。雑誌をつくるときとか、自分の仕事のやっていることっていうのをきちんと整理してまとめて保存しておくと、それは後々どんなほかのことがきてもやっぱり役に立つじゃないですか。それと同じだと思うんですよ。ただ、忙しくなったり、コストがものすごく安くなったりして、「とにかく今日中にこれだけは何とかしなきゃ」って状態になってしまうと、後で使うために整理しておくということをしなくなっちゃうんです。それは、もう当然のことながら、そういう整理をしなければいけないっていうのは、やっぱり下流のほうの人間に押し付けられることがやっぱり多いですし。
整理をするということに対する報酬がもらえないということもあって、デスクトップにありとあらゆるアイコンがバーッと並んでいて「うひゃー、これ、どうやって調べればいいんだよ、とにかく、もう検索するしかないのかよ」みたいな(笑)雑誌のデザイナーや編集者もいますよね。最近はファイルをちゃんとフォルダで階層的に保存しておくということを、だんだんしなくなってきていて、とにかく全部ひとまとめにして置いておいて後から検索で調べればいいんだよ、みたいな感じの考え方になりつつある。
でも、それだったらそれでいいんだけども、そのためには今度はメタ情報をファイルに付けていかなければいけない。今はコンピュータが自動的にメタ情報を付けるようなやり方になってきているんですよ。たとえば、iTunesで音楽を管理している人はたくさんいると思うんですけども、iTunesの中に入っているのはmp3とか、AACとかっていう音楽ファイルで、そのファイル一つ一つをフォルダを開けてこれがこうだって見たことがある人は少ないと思うんですね。iTunesでしか管理してないんですよ。iTunesで見ると、このミュージシャンのこのアルバムの何曲目とかっていうのが出てくるんで、もう済んじゃうわけです。だから、いちいちフォルダの中を開いてここにあるんだっていうことを見たり、ファイルの名前を変えたり、拡張子を確認しないで済むんです。
webもそうで、昔はwebを見たらみんなブックマークとかお気に入りとかでそれを保存してた。で、どんどん長くなっちゃうじゃないですか。そうすると、今度はまめな人はそれを階層化して、たとえば、仕事用のフォルダとか、友達のホームページとか、そういうふうにやったんですけども。もうあまりにも多くなったら、僕なんかは最近ブックマークしなくなってきちゃうんですね。とにかく必要だったらGoogleで検索すればいいやって考え方にだんだんなってきている。全体にそういう方向になってきていると、じゃあ、検索しやすいサイトをつくっておくことがどれだけ大事なのかということがわかってくるんですね。
これはさっきの雑誌の構造化というのと同じで、雑誌をつくるときにどれだけ検索しやすい雑誌にしておくかということを考えてつくっておく。webと考え方は全く同じなんですよ。それがリキッドであろうが固定であろうが、やはり検索しやすいっていうのは今後、電子書籍というのがどんなかたちに発展するとしても、5年後、10年後のことまで考えたら、検索できるようにしておいたほうが、絶対得なはずなんです。

沢辺 得だよね。さっき整理って下流の人間にやらされるって言ったけど、下流の人間としても最初にやっておけば、2回目、3回目はどんどん楽になるっていうこともあるよね。

深沢 そうですね。

沢辺 今、出版社と国会図書館が一緒に、Googleブック検索みたいな、全文検索をして一部がネットワークで表示される。で、それを見て買いたくなれば、購入できるようにする、っていうインフラをつくろうとしているんだけど。その時、いざ実際にOCRはどうするのとか、いろいろ問題はあるんだけど、仮にOCRがちゃんとできたとしても、ある単語に対してどういう順番で本を表示するか、これは競争になるでしょう。

深沢 各社の思惑がね。

沢辺 入るわけじゃないですか。だけど、その思惑部分は除いておいたとしても単純に全文が本当にOCRになっているだけのプレーンなテキストの状態よりも、章─節─項の区別がついて、じゃあ、章の中に入っている言葉、たとえば「内閣総理大臣」でも何でもいいんだけど、本文に入っているより、章のところに入っているのは少なくとも意味が高いと理解できるわけですよね。Googleの検索ロジックと同じように、webの一番上のタイトルのところにその言葉が入っていれば、一番価値が高いはずみたいなことに似ていると思うんだけども、そういうことをしないと、利用する人にとっていい順番を出してあげられなくなるわけ。そうすると、それは当然構造化されてなければいけない。
とはいえ、Googleに聞くと、OCRでバーっとやっているらしいんだけど、文字の大小、太さとかで一応階層化はできているといっているけど、それはあくまでも非常に大ざっぱなものだから、できれば、章─節─項とか、もうちょっと意味のある構造化されたデータが元にあればあるほど後は作業が楽ということに直面してるんですよね。

深沢 そうですね。テキストで持つべきなのか、それともメタデータみたいなもので持つべきなのかというのはいろいろ考えがあると思うんですよ。たとえば、画像だとか、写真だとかっていうのも、写真なんてちょっと前までは結局、Exifみたいなメタデータでいろんな情報を持つ、としか考えられなかったのが、今は写真そのものの画像認識で、誰の顔だとか、何を撮った写真なのかっていう判断がだんだん可能になってきました。だから、取りあえず汎用性のある情報を付ける、持たせるっていうことをやっていくべきじゃないかなと思っているんですね。
汎用性があるっていうのはどういうことなのかをもっと根本的に考えると、やはり何かどこかのメーカーに全部命を預けてしまうみたいなものじゃなくて、少なくともソースはオープンで、ひとつの会社に頼ったものじゃなくて、会社の都合や思惑で何かすぐにやめられちゃったりっていうようなことがあると当然困るわけで。電子書籍のフォーマットもそうだし、たとえば、僕がPDFに注目しているのはPDFって2年ぐらい前にオープンフォーマットになったんです。

沢辺 そうですね。

深沢 だから、今まではAdobeの中だけで考えられていたリーダーであるとか、そういうのもオープンフォーマットになったということで、もっといろいろな使われ方がこれからしていくんじゃないかなって期待するところもあるんですよ。
同じように、今、電子書籍……EPUBみたいなもの、いろいろいわれてますけども、もちろんそういう共通で何かフォーマットをつくって考えていくっていうことはすごく大事なことだと思うんですね。ただ、今のEPUBに過大な期待をしたり、EPUBがすべて何かを解決してくれるっていうようなものではないという気がする。

●Twitterからの質問

沢辺 今、USTREAM、全国で36人ぐらいの方に見ていただいているようで(笑)。なおかつ、Twitterでいろいろ書いていただいていますね。

————————————————————————–
FrameMakerで1600頁くらいの表組み作った時、一度も紙に出さないで校正終わったことある。刷本見てない^^
@seuzo
市川せうぞー
●http://twitter.com/seuzo/status/22168331029
————————————————————————–
Adobe Digital Publishing Platformって検索もできないんでしょ? クライアントから「検索窓つけてよ」って言われたらどうするんだろうね?
@seuzo
市川せうぞー
●http://twitter.com/seuzo/status/22169475327
————————————————————————–

深沢 せうぞーさんですね。

沢辺 「Adobe Digital Publishing Platformって検索もできない」。これ、意味がわからないんだけど。

深沢 「WIRED」をつくったやつです。電子版の「WIRED」とiPad用の「WIRED」はInDesignでつくって、それをAdobe Digital Publishingで書き出してるんです。Adobe Digital Publishing自体は、まだ世に出てないんで、要するにベータ版でつくっているっていうことですよね。だから、今の時点では検索できないんだけども、実際に世に出る時にそういう機能が果たしてないままなのか。当然、付けてくるような気はしますけどね。

————————————————————————–
構造化やCMSを難しく語ると技術的文脈に過ぎると思う。HTMLも構造化。MS Wordの文字スタイルがすでに構造化。だけど、そんな原稿見た事ない^^
@seuzo
市川せうぞー
●http://twitter.com/seuzo/status/22170730808
————————————————————————–

沢辺 市川せうぞーさんが、「構造化、CMSを難しく語ると技術的文脈に尽きると思う」と。これはどういうことなんだろうな。おまえら、ちょっと難しく語りすぎてないかっていうことを言いたいんですかね。

深沢 HTMLも構造化のひとつですよということでしょうね。せうぞーさんみたいにDTPをやりながら、プログラムもわかるような人は、構造化、構造化っていうと、やっぱりみんながちょっと構えちゃってっていうようなことを気にしているのかもしれないですね。僕がさっき言ったように構造化というのは、要するに自分の仕事をしているデータを適切に整理しておくっていう話なんですよ。それをただ単に僕の場合は構造化といっている。だから、構造化イコールXMLっていうふうになっているわけでもない。ただ、整理しておくと、それが後でもっときちんとしたコンピュータ的な整理をするときに、しやすい、つながりやすいんです。ただ実際に、普通の人間がXML的な構造化を常に考えてなければいけないのかっていったら、そんなこと無理に決まっていて。大体僕だってこういうふうに構造化ということを言っているけども、普段の仕事でどれだけ構造化を気にしてるか。

沢辺 難しいよね。

深沢 そんなことやってられないよっていうことのほうが実際には多いんですよ。webをやっていくと、常に突き付けられてきたんで。「取りあえずこのページが見えればいいや」っていう感じでつくっちゃうっていうことが多いんですけど。

沢辺 webやっていたって構造化を自覚してない人はけっこう多いと思うけどな。

深沢 だけども、最低限の自分がつくっているものが、じゃあ、少なくともXHMLのファイルでUTF(Unicode Transformation Format/英語や日本語だけでなく、世界中の言語をひとつのコードで表すためにつくられた文字コード)でつくっているんだったら、じゃあ、どうしておけば、ユニバーサルなデザインにできるのか。どうすれば、後から修正しやすくなるのか。どうすれば、自分でそのページを管理しやすくなるのか、みたいなことはやっぱり考えていったほうがいいと思うんですよね。それが構造化だと思う。

●構造化を自動化するシステムは可能か

沢辺 でも、それって、たとえば、編集者にしてもデザイナーにしてもそこまでやれっていうのはちょっと酷かもしれないですね。

深沢 そこまでがどこまでなのかっていうのはやっぱりこれから考えていかないとならないでしょう。

沢辺 いや、そうじゃなくて。ちょっと俺、深沢さんにヨイショしたつもりなんだけど、「WIRED」のようにデザイナーがいて編集長がいて、もうひとつ、構造化とか、進行っていうことを考える役割を1個置いておかないと、と。デザイナーが普段からそういうことを全部わかって、そこまでできるかというと、

深沢 いや、無理ですよ。

沢辺 だから、やっぱり第2、第3の深沢さんが必要なんじゃないかっていうことを言っておきたい。

深沢 役割の問題としては、それをたとえば、どういうかたちでやるのか。たとえば、そういうのを全部吸収して、もう自動的に処理してくれるようなオーサリングのシステムなり、アプリケーションがあれば、そんなこと気にしないで済む、っていうことももしかしたらあるかもしれないんですよ。

沢辺 そうですね。僕、正確に知らないんですけど、新聞社だと、最近は社内のデータベースに記事を上げるんだって。で、誰が書いたとか、著作権処理がどうだということも含めてデータベースに記者が記事を上げて、アプリケーション、いわゆるエディタみたいなものも専用のものをつくって。それでどこまで解決しているのか。それはちょっとよくわからないけど、たとえば、そういう思考はあると聞いたことがあるんだよね。

深沢 そういう思考を、今はInDesignの中にだんだん、持とう、つくろうとしている最中なんですね。

沢辺 まだいってないよね。

深沢 いってないです。それをもう既に進めちゃっているのがさっき言ったFrameMakerとかそういう話なんですよ。

沢辺 1,600ページ。

深沢 だから、要するにFrameMakerって単独で何とかなるようなソフトじゃなくて、常にXMLのデータベースっていうのが別にあるんですよ。データベースから記事を引っ張ってきて処理をするという、そのフロントエンドの部分なんですね。
これから何かパブリッシングをしていく時っていうのは、たとえば、作家が書いた原稿をどこか1カ所にデータベースに置いておく。それから、カメラマンが撮ってくれた写真をどこか1カ所に保存しておく。じゃあ、それをどういう使い方をするのかというのを、編集をしながら考える。そういうシステムってやっぱり必要になってくると思うんですよね。

沢辺 でも、豊富な実例ができないと、それはアプリ化できないよね。

深沢 そうでしょうね。こういうふうにやったら、こんなにいいことができましたということをもう少し積み重ねていかないと。
あとはやっぱり大きな仕組みじゃなくて、もう個人で使えるような仕組みじゃないとやっぱり駄目じゃないかと思うんですよ。さっき言ったInDesign Serverにしても、QuarkXPressも「Quark Publishing System」っていうのがあって、やはりデータベースとくっつけて自動組版できますよ、みたいなのがあるんですけども、新聞社などが導入して何千万円という話になっちゃうんですね。でも、そうじゃなくて、もうこれからはインターネットを使ってサーバーもネット上に置いて、クラウドで構わないんですよ。で、個人のレベルでも、

沢辺 じゃあ、深沢さんがつくればいいじゃないですか。

深沢 (笑)それは僕の仕事じゃないですよ。

沢辺 利用料を取って、「何とか社」って事前登録していると、何とか社の全部の原稿が整理されて見られるとか。

深沢 それは、だから、基本的にはAdobeなり、どこなりが本当はやるべきなんですよ。実際に、多分、やろうとしているんだと思うんですよね。でも、やっぱりなかなかそれが進まないのは、たとえば、ひとつはAdobeがCSっていうパッケージで、Version Cueっていうデータベースサーバーの仕組みをつくったんですね。だけど、ほとんどの人がやっぱり使わない。実際、僕はいろんなデザイン事務所、出版社、AdobeのCSを使っているところを回ったんだけども、Version Cueを活用、活用とは言わないまでも、少なくとも使っているよというのもほとんどいないんですよね。

沢辺 俺も使ってないですよ。

深沢 (会場に)使ってました?

会場 一応全部にインストールしてあるんですけど、スタッフによって違います。Version Cueを使いこなしているアートディレクターやデザイナーもいますし、一度も触ったことがないスタッフもいます。

深沢 結局、Version Cueみたいなグループウェアって、管理をする人のスキルと、それから最低限のスキルのラインがそろってないといけないっていうのがあるんですよ。そこらへんが難しいところなんですね。

●グループウェアの利点と困難

沢辺 それはそろってなければいけないの? それとも最低ここまでのスキルを全員が持っていて、それ以上持っている人がいれば、より良しっていう感じなの?

深沢 結局、仕事によるんですね。自分のページだけやればいいやっていうようなものだったら、単にバージョン管理をするだけなので、そんなに問題ないですけども、コラボレーションをする時は結局自分はここまでやったんだけども、「あと、これの修正をやってね」、みたいな時に一緒に修正をする人間がバージョン管理のスキルを持ってないと、もう使えないんですよ。だから、もう考え方そのものが破たんしちゃうんですよ。
グループウェアってみんなそういうものを抱えていて、グループウェアの最大の欠点っていうのはやっぱりスキルのラインの統率。じゃあ、誰かすごく詳しい人間が1人、まず管理するっていうのが大前提なんだけども、それをやはり最低限みんなに教育していく。でも、教育のコストや時間ががなかなか確保できない。バージョン管理もこれから構造化してワンソースのものをいろいろな使い方をしていって。その中のひとつにやっぱり電子書籍がある。また別のものとして紙の印刷物だったり、webがあったり、いろいろな使われ方をしていくとき、やはり、とにかくサーバーに元になるファイルがあって、グループウェアがあって、じゃあwebデザイナーはwebをつくる。それから、紙のデザイナーは紙をつくるという方向に進んでいきますよね。でも、コラボレーションだから、最低限共通の言語というか、言葉とか、決まりとか、ルールっていうものをやっぱり守らなきゃ破たんしちゃうんです。

沢辺 守るのが難しい。

深沢 それが難しいんですよ。

沢辺 ヒューマンなところが難しいね。

深沢 でも、それを本当は何とかしていかなきゃいけない。だから、Adobeはバージョン機能を本当はもっと徹底的に使いやすくするべきだと僕は思っていたんだけども、CS5で結局やめちゃいましたね。手放しちゃった。

沢辺 やめちゃったの?

深沢 もうやめちゃったんですよ。CS5にはVersion Cueが入ってないですからね。すごくびっくりしたし、がっかりしたし。Adobeは何を考えているんだと思いましたね。もうこれ以上自分たちではできませんということでお手上げですよ。僕はAdobeに対してものすごく腹を立てている。

沢辺 いつかは届きたいと思ってたんですけど。発想は面白いもんね。

深沢 そうです。あれが本当にきちんとつくられたらものすごく便利なんですよね。たとえば、webプログラムの世界ではSubversionというファイル管理のやり方があります。webプログラマーってどんどんプログラムを書き直していくんで、そのバージョン管理がどうしても重要なんですね。しかしデザインのバージョン管理ってやっぱりちょっと考え方が違うんです。
デザインの場合、たとえば、単純に昨日よりも今日のほうがバージョンは新しいという考え方じゃなくて、A案、B案をつくってどっちになるのかわからないとか、そういうことがすごく沢山ある。だから、たとえば、3パターンつくる、4パターンつくる、そのうちのどれがいいのかっていうのは、最終的にクライアントの判断で。B案でずっと進んでいたのに最後の最後でひっくり返ってA案になっちゃうっていうこともある。それはプログラムのバージョン管理の考え方ではやっぱり処理できないんですよ。だから、その分、また新しいやり方、コラボレーションのやり方っていうのを考えていかなきゃならないんだけども、Adobeがそれをあきらめちゃったのはすごく残念ですね。
Version Cueもそうだけども、最近、Googleドキュメントをみんな使ってるじゃないですか。Googleの中にWordやExcelみたいな機能があって。あれは、何人かでコラボレーションする時に、それこそスケジュール表をつくっておいて、たとえば小説家がGoogleドキュメント上で書いた文章を、編集者が直接InDesignに流し込むとか。そういったことは多分、すごく可能性はあると思いますね。
Googleドキュメントを見たり使ったりしていると、やっぱりグループウェアってこのぐらいまで易しくないと駄目なんじゃないかなっていう感じがするんですよね。
僕なんかがコンピュータを使うっていうのは、やっぱり楽をしたいというのと、それから、もうひとつはいいものをつくりたいということなんですね。もともと僕らはコンピュータをどうしても使わなければいけなかった時にコンピュータを使いだしたわけじゃないんで。だから、やっぱり楽をしたいとか、いいものをつくりたいとか、何か自分たちを表現したいとか、そういうことを考えてコンピュータを使っていたから。

沢辺 そうだよね。

深沢 だから、何とかコンピュータをうまく使いたいという気持ちが常にある。

P1040266.JPG

●製作者に今後求められるスキルは

沢辺 (会場に)事前に質問をもらっていた中でコストのことをお書きになっていた方がいらっしゃいましたよね。

会場 僕はもともとグラフィックデザインから始まって、webの仕事もやるようになり、DVDなんかもつくるようになって。で、昨今、こういうiPadみたいなものが出てきて、webに映像も乗ってくるわ、何だと。アメリカのプロスポーツのサイトなんかは、もうかなり派手にやっていますけども、ああいうことができるようになった。
今度はiPadなんかでも、これに特化されたニュースサイトなんかを見ていると、いわゆる記事は記事でちゃんと読める。映像もニュースのちょっとした2〜3分の動画が見られるようなものが、一体になってきている。
その中で、今までのグラフィックやwebや動画の経験を生かして、それらが一緒くたになっちゃうようなものをつくろうという時、まずコスト、今、こういうはやりものだから、ある程度こういうことはできる。プログラマーを見つけてきて、このぐらいの予算があればできますよとかって。やったらできなくはないのかなとは思うんですが、映像とか、広告とか、そういうものが一緒になってきたときに、われわれはつくる側なんで、それを変えていこうとしたときに、これからどういうスキルを身に付けてやっていったらいいのか。今、はやりものだからと、今のことだけを考えてやってしまったら、後はどうなってしまうのかなとか。これからの、ソフトをつくる側の心構えとか、今後はどうなっていくのかなと、また予測されることがあったら教えていただきたいと思います。

深沢 予測は難しいですけども、技術って基本的にどんどん変わるじゃないですか。だから、何かひとつのスキルでずっとつぶしがきくとはやっぱり思えないわけですよ。となると、やっぱりもっと根本的なところで、自分がたとえば、デザインだったら、何をデザインしたいのか。何を伝えたいのか。どういう表現をしていくのかとか、どういう編集をするのか、みたいな、もう本当にそういう根源的なところを、今の技術でどうしていくのかっていうふうにやっていくしかないわけですよね。
たとえば、今、デザイナーがInDesignを覚えたから、じゃあ、それでデザインができるかといったら、やっぱりそんなものじゃなくて、デザインができなければ駄目なんです。デザインができるというのは、紙と鉛筆でもデザインができないと駄目なんですね。紙と鉛筆でデザインができる人間がInDesignを覚えれば、それは飯を食えるかもしれない。でも、紙と鉛筆でデザインができない人間がInDesignだけを覚えても、やっぱりそれはしょうがないわけですね。もっと根本的なところに立ち返って、じゃあ、自分がどういうスキルを持つのかみたいな普遍的なものを、まずベースに考えていったほうがいいような気がします。
電子書籍も、今、いろんな見せ方があるじゃないですか。たとえば、今だとHTMLも4とか、4.5のXHTMLに比べても、HTML5は、プログラムがわからないと無理だよというレベルのものにだんだんなりつつある。
まあ、もしかしたら、それをプログラマーじゃなくても、簡単に画面上でつくれますよというオーサリングソフトが出てくれば、解決しちゃうかもしれないけども、今の時点ではそういうのはちょっとまだ見えないですし。
そうなってくると、オーサリングの環境みたいなものに左右されない。どういうものをどういう見せ方するのか、検索されるとどういうふうにヒット率が上がるのかみたいなところも大事だったりするんですよ。本をつくるんだったら、どういう本をつくれば売れるのかっていうのが一番大事じゃないですか。紙でそれが考えられない人間が電子で何か考えられるかっていったら、もう絶対無理なわけですね。

沢辺 なかなかコンサバですね。原点に戻れということがいいたいわけですね。

深沢 原点に戻れというよりも、戻れなければ、まず何も始められないんじゃないかと。出版やデザインに関しては、技術が何かを解決してくれるということは、まずあり得ない。

沢辺 おっしゃるとおり。それはそうです。だから、僕がもう1個いいたいのは、さっきの三角形なんですよ。これだけ技術の幅も広まったし、この時代において編集もできます、デザインもできます、テクノロジーもわかります。これを1人でクリアするのは絶対に無理だから。

深沢 そうですね。

沢辺 で、デザイナーも、やっぱり名を成したデザイナーって本の1冊、2冊書いたり、それからちょっとした編集なんか知っているわけですよね。と、俺はそう思ってるの。だから、デザイナーは編集のことをわからなくていいなんていうことは全くなくて、編集者もデザインのことをわからないといけないと、ちょっとずつ微妙に侵略していかないといけないということ。

深沢 共通言語がないといけないですね。

沢辺 さらにこのテクノロジーは、またもう1個すごく難しい問題だと思う。昔だったら、活版の印刷所に見学にでも行って「このようにつくられているのね」って。まあそんなことをいったら活版屋さんに怒られるけど。

深沢 いや、それは今でも同じだと思うんですよ。

●編集者×デザイナー×プログラマーのチーム

沢辺 なんだけど、それにさらに、しち面倒くさいデータベースがどうだ、オープンソースがどうだ、オブジェクトがどうだとか、いろいろな要素があるから、やっぱりいいチームをつくるっていうことが、もうひとつの課題なんじゃないかなと思うね。

深沢 そうですね。だから、コンピュータの世界ではクラスタ(房・集団)という言い方をするんですけども、要するにプログラマーのクラスタとか、編集者のクラスタとか、デザイナーのクラスタに分かれている。それぞれのクラスタ、今は特にプログラマーのところだけ孤立しちゃっているところが多いんですよ。前も、たとえば、「マガジン航」の仲俣君も言ってたんだけども、「編集者はこれからデザイナーとプログラマーと3人でチームを組むことが大事なんじゃないの」と。それはそのとおりだと思うんです。その3人でとにかく相談をする。技術的なことはプログラマー、それからデザインはデザイナー、編集はどうやって売っていくのか、マネタイズするのかみたいなものを含めてコンテンツを考えていく。そういうトライアングルみたいなものがうまくできているチームはものすごくこれから可能性が出てくると思いますね。

沢辺 そうでしょうね。

深沢 それはフリーであっても、組織であっても、やっぱりすごく重要だと思う。

沢辺 事前にいただいた質問から。「未来の雑誌はどれも既存の雑誌に比べて製作コスト、手間も暇も費用も大幅に掛かるように感じます。効率的な、かつデジタルメディアの特性を生かしたデジタル雑誌コンテンツづくりをどのようにしていったらいいのか。あるいはそのあたりは技術的に、技術がどの程度解決していくのか」というのがあったんですけど、それを書かれた方は?

会場 僕です。

沢辺 そのへんの問題意識を、今までの話を聞いていかがでした?

会場 日々悩んでいることなんで、本当にありがとうございます。これ、電子雑誌の話になると、どうしてもやはり広告のことも含め、いろんなことがあっても動画と音声ということを要求されることが多いような気がします。そうなった時にやっぱりその分の編集コストが乗っかりますし、先ほどおっしゃったようなデザインのコストも掛かってくると。できれば、1個のデザインでいろんなデバイスに対応できたほうがいいですし、そういうふうに技術的になったらいいんじゃないかなということを思ったりしてるんですけども。取りあえず、雑誌もけっこうぎりぎりのコストでつくっているケースが多い中で、さらにデジタルのためのエクストラのコストとなると、なかなか難しいですよね。じゃあ、定価を上げられるかといったら上げられないですし、読者をもっと増やすためには、じゃあ、売り場をどうするかって、また別の考え方もありますけど。つくる側で何かなるべく工夫することで効率化とか、コストダウンを図れるんじゃないのかという夢を抱いているんですけども、そのへんに関してもう少しお話をいただければありがたいと思っています。

深沢 デザインにしてもそうなんですけども、たとえば、ワンソース・マルチユースっていうのが果たしてコストダウンに直接結び付くのかどうなのかっていうのは、根本的に考え直す必要があるような気がするんですよ。要するに、2パターンつくるのと、ワンソース・マルチユースで考えていくのと。逆に最初から2パターンつくっちゃったほうが、デザインにしても何にしてもコストが安い場合がけっこうあるんですね。特にデザイナーとか、製作側のほうでは「何にでも使えるようなものをつくる」というのはすごく大変だったり、難しかったりするんです。何かに限定されたものをつくるほうが意外と簡単に済むことがある。
だから、もしワンソースでやりたいのであれば、大元のところから仕組みを考えなくてはならない。
それとは別に、どのぐらいのものをつくって、どこにリーチしていくか、という考え方も大事だと思います。世の中の流れ、じゃあ、iPadはどのぐらい売れているんだとか、Windowsよりにつくったほうがいいのか、Macよりにつくったほうがペイするのかとか、そういうふうなものも含めて考えていくしかないわけですね。
あとはオーサリングの仕組みのほうの問題があって、今、たとえば、雑誌はInDesignで、webはたとえば、DreamWeaverでつくるとか、そういうふうになってるんですけど。ブログってありますよね。たとえば、WordPressだとかでブログをつくるんですけども、ああいうCMSの仕組み、要するにデータベースが裏で動いていて、データベースにテキストと写真を放り込むとレイアウトして見せてくれるという。そんな仕組みをCMSっていうわけです。

●ページネーションとマネタイズの可能性

深沢 Twitterなんかもそうなんですけども、そういうCMSが直接電子書籍のフロントエンドになっちゃうってことは十分あり得ると思うんですよね。パブーっていう電子出版サービスがあります。さっき言った「Scribd」の二番煎じというか、ちょっと遅れた日本語版に近いような感じのものです。基本的にあれはブログみたいなシステムで、テキストがスクロールしていっちゃってるんで、ページネーションをちゃんと考えていないところがすごく不満なのですが。
でもこういうシステムを使って、アップしたテキストがEPUBでもダウンロードできる、ってなっていけば、「CMSで電子書籍をつくる」っていうのが一般化していく。そうなってくると、文章中心の書籍だけじゃなくて、レイアウトもちょっと凝ったものにしていきたいっていうのが、あの中でだんだん機能として出てくれば、電子雑誌を、たとえば、Movable Typeでも新聞風に見せるスタイルシートっていうのがあるんですね。どんどんそうやって記事をアップしていく。それから写真をアップしていく。そうすると、それを見たときに、もう個人の新聞のように見える。
そういうふうな仕組みはだんだんできつつあって。そういうのがもしかしたらどこかで突破口になる可能性があるなと思って、ずっとそういうのは注目して見てはいるんですけど。ただ、今の時点で「これが解決策」っていうのはまだないですよね。

沢辺 ないね。

深沢 それでも、面白いなと思うのはiPadでちょっと話題になったFlipboard(フリップボード)っていうアプリがあるんですけども、これはTwitterのブラウザです。Twitterで流れてくるテキストであるとか、画像であるとかを勝手にレイアウトして、ページネーションして見せてくれる。

自分のTwitterを登録しておくと、日本語で自分の普段見ている知り合いの書いた文章とか、撮った写真とかがこれでページでレイアウトされて表示されるんですね。それ以外にも、たとえば、新商品ニュースの「GIZMODO」とか、「IT media News」みたいなもののTwitterも登録しておけば、ページめくりして見られる。で、こういうのを見ると、やはり、もうこれは構造化された電子書籍以外の何物でもないと思うんですよ。それを見たときに「これ、雑誌ぽいじゃん。格好いいじゃん」とか、「これで読みたい」とかっていう気分にさせられれば、それってマネタイズの可能性がすごくあると思うんです。そのへんに突破口はもしかしたらあるんじゃないかなって感じです。そうなってくると、CMSであるとか、誰かがひとつ仕組みをつくってくれれば、それに乗ることで自分たちのコンテンツをつくっていく。
今の印刷の仕組みとかっていうのはやっぱりそれに近いものがあると思うんです。いちから自分たちが印刷の方法だとか、そういうことを考え出したわけじゃなくて、既に印刷だとか、写植、デザインという仕組みに乗っかって自分たちでコンテンツをつくっていった。そういう感じの考え方としては、何かそういうものに乗っかって小さな出版社なんかでもどんどん面白いものをつくって世に出していって。それを見た人がお金を出してっていうような方法が何かいろいろ考えられると。
あとは課金の方法、どうやってお金を集めるかっていうのはなかなかまだね。特にwebとか、ネットワーク系のところでは決定的なものはないです。Appleが集金代行してくれるiTunes Storeみたいなものがあるので、そこでっていうような感じのことが、今はけっこうあるんですけども。でも、それだとAppleはやっぱり自分たちが集金をするんだったら、最低限このラインのものじゃないといけないとか、こういうものは売りたくないって、当然、言い出すんですよね。それに対して、たとえば、Appleはポルノを扱わないっていう批判があったりするんですけども、僕は売りたいものを自分たちで決めるのって、当然だと思ってるんですね。だから僕はAppleがリジェクトすることに対して、当然だろうと思っている。世の中の人はけっこうそうじゃないと思っている人が僕の周りにも多いんだけども。
僕はそうじゃなくて、Appleはやはり教育市場のほうがアダルト市場よりも自分たちにとってはでっかいビジネスチャンスがあると思って、そういう判断をしたんだったら、自分たちはポルノをリジェクトして教育市場のものを売りますよって。そこには何も問題があると思ってないです。そうじゃない人間が、自分たちはアダルトで勝負したいんだ、っていうんだったら、そういう仕組みを自分たちでつくればいいんであって。

沢辺 そうそう、そうそう。

深沢 それが禁止されているわけじゃないんですよ。iPhoneでも、iPadでも別にポルノだって見られるんですよね。それを表示しようとした瞬間にフリーズしちゃうとか、真っ黒になっちゃうっていう仕組みにはなってないんです。それは完全にオープンになっていて、全然何も問題はないんだけども、ただ、代わりにAppleが集金をしてくれるかどうか。そっちだけが問題。

沢辺 そうですね。

深沢 もっと自分たちで、自分たちの頭で考えて、集金の方法まで考えて。特にアダルトなんかはリスキーな仕事なんだから、リスキーなことをやろうと覚悟するんだったら、そういうところまで考えて、やればいいじゃんって思うんですよ。

沢辺 話を戻してごめんね。(iPadを見ながら)Flipboard、自分で登録してみたんだけど、これってただ俺がフォローしている人のつぶやきを、勝手にレイアウトして、でかくしたり、小さくしたりしているの?

深沢 勝手にやってるんです。

沢辺 なるほどね。だけど、考え方としては裏にXMLがある、みたいな。

深沢 要するに、Twitterのデータっていうのはひとつのツイートが、構造化されたXML文章として送られてくるわけです。

沢辺 これでいえば、俺がフォローしているやつがこんなサイズになったり、2分の1のサイズで表示されたり。

深沢 そうです。どういうアルゴリズムで表示をでかくしたりっていうのはちょっとわからないんですけど、たとえば、リツイートの多いものを前面にするとか、フェバリットの多いものを大きくするとかっていうことが、もしされているんだとしたら、それって、もう完全に雑誌ですよ。
毎日新聞が自分たちの記事データベースの中でネットアクセスの多い記事をツイッター連動で集めて、もう一度レイアウトし直して紙で印刷し直して売ってるんですよ。「毎日RT」っていうタブロイドペーパーですね。あれも佐藤直樹さんのところでデザインをやっているんですけども、そういう考え方のものってやっぱりあっていいと思うんですよ。結局、インターネットの世界というか、時代というのはやっぱり再利用を、どんどんどうやっていくか。雑誌もそれをどんどんやっていっていいと思うんですけど、そのためにはやはり自分たちが普段つくっている雑誌を何とか、後々、また別に使えるようなものとしてつくっておく。それが逆に下流のほうでも負担の軽減になっていったりすれば、一番いいんじゃないかなと思うんですけど。
そのへんに、今の時点ではまだやっぱり立ち上げのところなんで、やっぱりいろんな負荷が掛かっていると思うんですけども、マネタイズの可能性があるとしたら、そういうところにあるんじゃないかなとは思います。

沢辺 はい、それではほかに皆さん、ご質問はありますか。なければ、9時半も回りましたので終わりにしましょう。じゃあ、何かいきなりぶちっと切るようで申し訳ないですけど。

深沢 僕に何か聞きたいこととか、質問とかがあったら、Twitterとかで連絡して下さい。ブログもやってますし、送ってもらえれば、僕のわかる範囲のことだったら答えますよ。

沢辺 僕的にも本質に近いお話しが聞けたというか、自分で抱えていたポット出版であの本の電子化をどうしようかなっていうようなことの具体的な回答というか、ひとつのたたき台に何となく手が届いたかなって感じがします。どうもありがとうございました。

深沢 ありがとうございました。(了)

関連書籍

『電子書籍と出版─デジタル/ネットワーク化するメディア』


高島利行、 仲俣暁生、 橋本大也、 山路達也、 植村八潮、 星野渉、 深沢英次、 沢辺均
定価:1,600円 + 税
ISBN978-4-7808-0149-1
B6判 /208ページ/並製
[2010年07月刊行]

内容紹介や目次など、詳細はこちらをご覧ください。