開発中のBook+の特徴をご説明するシリーズの第3回目。今回はスマートフォルダ機能についてご紹介したいと思います。

自炊をやっていて困ること、あるいはPDFビュワーを仕事での資料閲覧に使っていて困ること

その一つに大量のファイルが入ってる場合に目的のファイルが探しにくいことがあるという点があります。ファイラ系アプリでもビュワー系アプリでも共通していると感じるのですが、ファイルが増えてくると探す行為の頻度が増えてくるような気がします。

Filing © 2011 Anna, Flickr

そもそも探す手間を省けるよう全体を俯瞰できるファイルブラウザ(第1回目でご紹介)を搭載しているのですが、いざ検索したいっ！となった場合にはなるべく探し易いように…という事で、多様な検索機能とスマートフォルダ機能を搭載しました。

スマートフォルダの解説に入る前に、Book+のファイル検索機能をまず見て頂きたいと思います。どどーんと。

結構色んな切り口で検索が可能です。文字列を使って部分検索をするのは普通に在る機能ですね。Book+では更に以下のような検索が出来ます

• 更新日(「あのファイル確か2,3日前に入れていた筈なんだけどなぁ？」といった時に使います)
• 最後に開いた日(「一昨日読みかけで放置していたPDFの続きを読むぞ」といった時に使います)
• フォルダ検索(フォルダだけで検索したい時に使います)

組み合わせも自由自在です。上記の画面キャプチャの例では

「日経という言葉がファイル名に含まれて、且つ1週間以内に登録したファイルで、しかもここ3日間の間に開いたファイル」

を最大20個探そうとしている様子です。検索ボタンを押すと、マッチしたファイルが表示されますので、そのまま閲覧する事も、移動や削除も可能です。

Folder © 2010 Jonas Merian, Flickr

さて、ここからがようやくスマートフォルダ機能の話。

端的に言うと、検索条件を記憶させたフォルダを作れる機能です。検索結果を「保存」をすると、検索条件を覚えたフォルダ(これをスマートフォルダと呼びます)が作成されます。以下は検索結果表示中の様子。

検索結果を覚えるのではなく、検索条件を覚える

というのがポイント。記憶した検索条件に応じて中身が動的に変化するフォルダと言っても良いでしょう。スマートフォルダを開くと、毎回検索条件にマッチしたファイルを一覧してくれる訳ですので、これで同じ条件の検索を繰り返す必要は無くなります。スマートフォルダは何個でも作る事がことが可能。以下は2つ作成している例です。

INBOXのすぐ下は「日経」の文字が含まれるという条件にマッチするもの、一番下は「最後に開いた日が2日以内」という条件にマッチするもので、自分で「最近開いたファイル」という名称を付けています(スマートフォルダには好きな名前を付けられます)。

スマートフォルダは並び替えることも可能ですし、不要になれば削除も出来ます。ちなみにスマートフォルダを削除した場合は中のファイルそのものは消えませんので心配ご無用です。あくまで検索条件へのショートカットが無くなるイメージですね。

Book+ではこのように、横断的な検索とその再利用が出来る仕掛けを用意しています。自炊派の方で多数のPDFファイルをお持ちである方や、自炊派でなくともお仕事で大量のPDFを閲覧されるような方にこそ活用頂ける機能ではないかなと思います。

開発中のBook+についてご紹介するシリーズ2回目です。1回目ではBook+のファイルブラウザと題して、ファイルシステムのようにPDFを管理するような思想を持っている事をご紹介させて頂きました。

まさにディスクドライブのようなモノで、そこを基点にしてフォルダを自由に作成してPDFを配置/管理する…と。これを Book+ホーム と呼んでいます。では、その中にどうやってPDFを入れていくのでしょうか。

方法は他のアプリと余り変わりません。アプリ連携(Open-In)で他のアプリから持ってくるか、iTunesを経由したUSB転送ですね。Book+に取り込まれたPDFは、受け取り専用として用意された INBOX と呼ばれるフォルダに入ります。

Book+ホームに受信箱が予め備わっている感じでしょうか。

以前のエントリでメールの受信箱を基点にした僕のタスク管理方法をご紹介させて頂きましたが、まさにそれと同じ。Book+に直接取り込まれたファイルは、とにもかくにも INBOX に入ります。未読…というか、未整理状態ですね。買ってきた本をとりあえず机の上に重ねて放置している状態に似ているかも知れません。

l i g h t . r e a d i n g © 2011 Angie Torres, Flickr

整理する機構をファイルシステムのようにこだわって作ったからこその機能と言いましょうか。やっぱり、整理する場所と入れ物とは分けた方が良いんじゃないかと。

このINBOX機能によりBook+に新たなPDFを入れたとしても、既に整理された構造の中にフラットに並んでしまって、グチャグチャになるという事はありません。(個人的にGoodReaderを使ってて辛いのはココなんですよね。整理しててもすぐ散らかった感じになっちゃう)

もちろん、INBOXに入ったままPDF閲覧をするというスタイルでも構いません。整理しないという割り切りですね。何個でも入れたままに出来ますので、そこは整理のスタイルという事で。

INBOXに今、3つのファイルが入っています。(先ほどの写真では2つでしたが、撮影したシーンが異なります)

移動したいものを選んで、移動ボタン。そして移動先指定を促されますので移動させたい箇所を指定します。

こんな感じのインターフェース。階層構造をインデント付きで表現しているので分かり易いですね。タップ後、ファイルは移動してそのフォルダを自動的ファイルブラウザで表示します。…ので、整理した後にすぐ読み進める事も出来ます。(もちろん移動元であるINBOXからは無くなります)

ちなみに僕的感覚ではINBOXは常にゼロになってるのが理想。何のために入れたファイルなのかを整理する事で明示する….という仕組みとしてINBOX機能が働いてくれている感じです。

一時的にBook+で見たいだけなんだというファイルはINBOX内で直接閲覧。不要になれば Book+ホーム配下に移動させる事なく削除するというテンポラリな使い方も出来ます。そんな使い分けが出来るのも INBOX 機能の特徴です。

整理する機能はやめてGoogleDocsのようにタグ付けする仕組みも考えたのですが、やっぱりフォルダ階層がある方が直感的という事でこの実装にしました。一方で、タグとは異なる、フォルダ階層には関係の無い横断検索的な機能も搭載しています。案外、iPad/iPhone 系でファイルを扱うアプリには備わっていなくて不思議に思っていたのですが、その機能についてはまた次のエントリでご紹介させて頂きます。

普段から何個も開発案件が並行している事が多くタスク管理には常に悩まされていました。開発以外の事(例えば労務/財務/法務/税務など)も含めたりするとプロジェクトの数は凄い事になります。

そんな中、自分なりに色々と試してきて行き着いた終着点についてご紹介します。万人受けするものではないかも知れませんが、TODOアプリやGTD(ワークフローの管理手法。詳しくはこちら)に興味があって、複数案件を同時にこなしているような方に何かのヒントになればイイなぁと。

inbox © 2011 kevin rawlings, Flickr

肝心かなめはメールの捉え方にあると気がついたのは、初めて増員した時だったでしょうか。

良くも悪くも今のご時世はメールが全て…は言い過ぎかも知れませんが、skype/Twitter/Facebook など色々仕事に使えると言われながらもやはり大半はメールに落ち着きます。逆にメールを使わずに完結する仕事は皆無に近い。

…なので、そのメールの使い方を最適化せずに幾らTODOツールやGTD系アプリに頼っても続けられる事が出来ない筈と思い至りました。

色々と試行錯誤して仕事の流れを分析する中で気づきを得、メールに対する接し方を変えてみてからでしょうか。ようやくGTDツールを使いながら気持よく自分のタスク管理が回せている感じがします。といっても、タグ付けの工夫とか、メール検索テクニックとか、そういう話ではなくもっと簡単。

受信箱は常にゼロにする

ただこれを徹底するように考え方を変えただけ。

Inbox Art © 2009 Beck Tench, Flickr

メールは何らかのタスク発生を伴っている事が多いです。スケジュールの調整だったり、書類の確認だったり、誰かに電話する事だったり。多くのタスク発生ポイントがメールの受信箱にある。何を今更…ですけどね。

プロジェクトの大半でメールのやりとりが必ずあって、そのメールが何らかのタスクを伴っている事が多いのなら…という事で、受信箱をとにかく残タスクの塊&新たなアクションの源泉だと考えるようにしました。GTDツール使ってINBOXだ何だと言うよりも前に、まずメールの受信箱。

とにかくゼロにしよう、受信箱に残メールがあるのは誰かを待たせている事の証だと考えよう、何か反応を起こして受信箱を空にしようと、その上で使えるツールは支援ツールとして使うようにしようと。

あくまで基点はメールです。これは世の中がそうなので仕方ない(少なくとも僕の今の仕事では)。多分、10年や20年の単位で変わらないでしょう。そんなメールの入ってくる口である受信箱をゼロにしようと意識し始めた途端、GTDツールと自然と付き合えるようになってきたという感じですかね。

GTD and The Now Habit © 2006 Dennis Blöte, Flickr

まずはメール。その次、GTD。

…というか、GTDを回す為にメール受信箱を巧く使うって感じのような気もしているのですが、ちょっと長くなってきたので、分けて書きたいと思います。次回はメール受信箱をどんなふうに捉えるようにしたかについて書いてみます。

Mac好きな方なら知らない方はいらっしゃらないと思います。Apple製品が好きな方や興味のある方の為のユーザグループミーティングの本家、AUGM東京が2011年も開催されます。開催日は9月3日。

プログラム内容を見てもかなり凄いイベントなのが伝わってきますね。さすが本家。噂によると300名の定員も一瞬で満席らしいです。

参加企業名一覧にある通りScanSnapのPFUさんも参加されるのですが、なんとそのPFUさんのセッションで弊社が少しばかりお時間頂いてお話をさせて頂く事になりました。

7月でしたか、この話を頂いた時は、えぇそれはもうビックリしましたとも。AUGM東京ですよ！しかもPFUさんとご一緒に！これはもう驚く他ありません。関係者の皆様、改めて御礼申し上げます m(__)m 精一杯プレゼンテーションさせて頂きたいと思います。

当日は10分程のお時間を頂戴して、

• 擬似的にScanSnapをiPadのスキャナにしてしまうFastBoardというiPadアプリのご紹介
• ScanSnapで取り込んだPDFを閲覧する為のビュワーとしてBook+をご紹介

の2つを5分/5分ぐらいで出来ればと考えております。交流の場も設けられているそうですので、色んな方とまたお知り合いにならせて頂けたら嬉しいなと思っています。早くも2週間前と期日が迫っておりますがプレゼン準備頑張ります。

という訳でちょっとしたご案内でした。もしAUGM東京2011にお越しになられる方がいらっしゃいましたら、会場でお会い致しましょう

もはや肩書きは経営者であり開発者ではなくなってしまった昨今ですが、その理由は2つ。

1つ目は以前にもまして開発より優先度の高いタスクに時間が割り当てられる事が圧倒的に多い為、2つ目は自分で開発するよりも社内でエンジニアに任せた方が圧倒的に早いから。

Creating © 2009 misterbenben, Flickr

とは言え、何でも良いので何か作りたい衝動に駆られる時があります。元エンジニアのサガなんですかね。そんな時は、あったら便利やなと日常で感じたプチツールを作ってみたりします。ただ作った後に「実はもう他にあった」と発覚する事もあったりしますけどね。…今回もひょっとしたらそうかも(笑)

で。今日はちょっと気分転換に Flickr API を使った自分用ツールを作ってみた次第。

最近ブログのエントリ数を増やしてて、改めて段落間に写真があると文字だけに比べると読み易いかもなーと感じてました。これまで wylio というサイトを使って、Creative Commons なライセンスの画像を引っ張ってきていたのですが、どうやら使い続けるには有料になるらしく、ならば作ってしまおうと。

検索キーワードを指定してやるとこんな風に

結果がダダダダと表示されるので(上の例では sunset で検索)、好みの写真のIDを選んでゴニョゴニョすると

<div style="clear: both; text-align: center;">
    <a href="http://farm7.static.flickr.com/6207/6060557720_67725081a5.jpg" title="TWY">
        <img style="float:none; margin:0px auto" src="http://farm7.static.flickr.com/6207/6060557720_67725081a5.jpg" width="360" />
    </a>
    <div style="font-size:70%;">
        <a href="http://farm7.static.flickr.com/6207/6060557720_67725081a5.jpg" title="TWY">TWY</a> © 2011 <a href="http://www.flickr.com/photos/60132504@N08">tsuna72</a>, Flickr
    </div>
</div>

こんな感じの html コードを Mac のクリップボードに保存してくれるというもの。そのまま [cmd] + v でブログのエントリに貼り付たら

radiance © 2011 spiritflare, Flickr

こうなると。Creative Commons のライセンス指定に従って作者とURLへのリンクを記載して、併せてFlickrから拝借していることも明示。

という訳で、今後のブログエントリでも引き続き Creative Commons ライセンスの写真を使わせて頂きたいと思います。撮影者の皆様、いつも有難う御座います。

ちなみに今回作るのに要した時間は Flickr API を調べたり微調整も含めて2時間ぐらいですかね。明らかに遅過ぎるのですが、久しぶりに開発出来たのでもう満足です。

さ、仕事の続きしますかね

昨日のエントリで Book+ というPDFビュワーを開発中である事を書かせて頂きましたが、公開までの間に開発中の画面や機能について幾つかご紹介出来ればと思っています。まずは管理系から行ってみましょう。画面を見て頂いた方が早いと思いますので、どどーんと。

色んなファイル管理インターフェースを「探しやすさ」という点で検討してみた結果の落ち着きどころなのですが、決して是非を言ってるのではなく、僕らが良かれと感じたインターフェースの試みと思って頂けたら嬉しいです。

本棚的なインターフェースではなく敢えてファイラ的にしてみました。

フォルダの中へ階層構造を次々と潜っていける仕掛けで、階層は幾つでも作る事が出来ます。深い階層では場所に迷わないようにパンくずリスト的な表示もするようになっていて、任意階層にいつでも戻れるようになっています。

探す行為でフリック操作をするのは上下方向に限定した方が分かり易いんじゃないかという議論の末、この形に落ち着きました。

また、フォルダが賑やかな事から推察頂けると思いますが、6色から色を選択出来るようにしてみました。

こんな風にフォルダの設定から指定出来ます。

階層構造を自由に作る事が出来て、尚且つ、PDFをまとめる器として機能するフォルダを色分け出来るようにする事で、柔軟な整理と全体を俯瞰する事が可能になり、どこに何があるか分り易くなるんじゃないかと思います。

あと、整理と言えば忘れてならないのはロック。机の引き出しに鍵がかかっているように、特定のコンテンツは自分しか見れない箱に入れておきたくなるものですよね。これもまた整理のいっかん。なので、任意のフォルダで自由にパスワードロックが出来るようにしてみました。

中を見ようとするとパスワードを聞かれます。見られちゃマズイ系のコンテンツもきっとこれで大丈夫 ロックが掛かったフォルダの中にまた別のロック付きフォルダを作ったりする事も可能です。やり過ぎると確実に使いにくくなりますが(苦笑)

とまぁここまで見て頂くとお分かり頂ける通りパッと見はMacOSXのファイルシステム的なのですが、自分らで使ってみている感想としては結構分かり良くて整理し易いインターフェースになってるんじゃないかなぁと思っています。

ところで、このBook+の素敵なデザインは、お馴染みメタ・グラマーさんに全面的にお願いしました。おかげさまで、シンプルで常用に耐えうるテイストながらアクセントが所々あるという絶妙な雰囲気に仕上がっております。いつも有難う御座います m(__)m

という訳で、まずはファイル管理系のご紹介でした。他にも管理し易さを追求してみた機能があったりしますので、また改めてご紹介させて頂きたいと思います。

僕は根っからの読書好きで書籍も雑誌も大量に持っています。実家の押入れには漫画も結構あります。

iPadが出ると分かってから、裁断してスキャンしてPDF化して持ち歩きたいと思いました。実際 PFUさんのScanSnap と PLUSさんの裁断機を購入してそうしました。iPadはiPad2へと進化して、iPhone は Retina ディスプレイで解像度を上げ、iBooksを始めPDFビュワーアプリも物凄い勢いで沢山登場し、僕は益々読書用端末としてiPad/iPhoneを使うようになったのです。

ただ、読書体験を決めるアプリについては色々と試せば試すほどユーザとして感ずる事が増えていきました。それは弊社メンバーも同様なのですが、あれも欲しい、こんな事も出来たら良いな…と。

例えば、

■ PDFの管理方法

• 実はGoodReader的な感じでファイラの体を成してる方が整理し易いんじゃないか
• MacOSXにあるようなスマートフォルダ(検索条件を記憶して常にマッチするファイルだけを集めて表示してくれる仮想フォルダ)のようなものがあった方が、雑誌やシリーズ物のPDFが管理し易かったりしないか
• もっと言えば、毎日読書するのなら1日以内に開いたPDFがすぐに参照出来るとか、登録日が直近3日以内のものを常に一覧出来ると便利じゃないか

■ PDFの閲覧方法

• ページを送っていく感覚だけじゃなく、もっと一気に全体を俯瞰出来たりすると、特に雑誌等の場合は読みたい場所に辿り着き易いんじゃないか
• 段組コンテンツのPDFはiPhoneでは特に見にくいが、実は工夫次第で読み易さが提供出来るんじゃないだろうか

等々です。読書が好きだからこそかも知れませんが色々思うところが増えてきた訳ですね。

普段は既に存在しているモノをちょっとやそっとの違いで自ら作ろうとはしません。先のエントリで書いた車輪の再発明になるだけで、そこには経済的合理性がほとんど無いからです。作者の方に要望を伝えて実装されるのを待つほうが良い。何より「世に無いモノを作り出し、世界を変える」という弊社の理念に合いません。

でも、どうもですね、電子書籍化したPDF(または連番jpgを圧縮したZIP BOOK)の管理と閲覧についての考えを自分らなりに突き詰めていくと、既存のモノとの差異がちょっとやそっとでは収まりそうになく、結構違うモノのように思えてきたのです。管理の考え方だったり、閲覧面での機能であったり、それこそ新しいコンセプトが形成されつつあるんじゃないかと。であれば、

自分達で新しいビュワーを作ってみたらどうだろう？

と思い至りました。

実は、余り表には出ていませんでしたが、幸いにして社内にはiOSにおけるPDFを扱うノウハウが結構蓄積されています。というのも、弊社プロダクトの一つであるSYNCNELが自前実装のPDFビュワーを内蔵していた為。

コアとなる技術もあるし、やってみたい事も増えてきて、電子書籍リーダを作る材料は揃った訳です。

PDFについては、先日のエントリ(EPUBは本当に必要か。全部PDFで良いじゃないか)で、ページの概念を必要とする旧来型の書籍/雑誌の電子化はPDFが最強というFinalAnswerは出ているという主張や、PDFかEPUBかという論説を書きました。専門家から「偏っていると思うし危険な発想」と言われたり、中には「こいつはヴァカでok」という低俗な中傷をするだけの残念な反論コメント(ですらない)もありましたが、僕の考え方は変わりません。

従来の雑誌や書籍というメタファーで閲覧する限りにおいては、是非を論ずる余地はもはや無くPDFが他を圧倒的に凌駕する是であると思っているので、フォーマットを論ずるよりも、最強たるPDFによって電子化された書籍をどう管理し、どう閲覧し、電子ならではのリッチな体験をどう実現するか…にしか興味がありません。だから、先のエントリに書いた通り

1. PDFを如何にリッチにするか
2. PDFを如何に読みやすくするか
3. PDFを如何に管理し易くするか
4. PDFを使って如何に新たな読書体験へと読者を誘(いざな)うか

が追求すべき事項であろうと。

結局、「自炊」という風習が、書籍や雑誌という形式を電子化するには(読者にとって)PDF化が一番適した解なのだという事を示していると思うんですよね。この現実を真摯に見ないといけないと思います。

年間7万とも8万とも9万(2010年出版年鑑によると8万弱)とも言われている新刊の出版物を全部PDFでも販売して、同時に過去の書籍全てをPDF化して流通させれば、さんざん電子書籍化に失敗してきた理由にあがるコンテンツ不足なんて解消する筈なんです。雑誌も含めれば100万冊なんて一瞬じゃないですか。

PDF最強と既に解が出ている所で同じ議論を繰り返すより、権利や法律の整備に労力を費やした方がよっぽど合理的。例え現実的だと思えないとしても…です。そこが事の本質だし、結局同じ問題にはぶちあたるのですから。

とまぁ論旨がずれてきそうなのでチョット戻しますと、PDF(そしてZIP BOOK)という電子書籍の形式を大前提にした追求を iPad/iPhone のアプリでやってみたいと思っています。最初は「2. PDFを如何に読み易くするか」と「3. PDFを如何に管理し易くするか」という2点から。地道な所ではありますが、まずは足場を固める事に重点を置きながら、その上で 1 や 4 の追求をしてみたいと思います。

新たな読書体験を目指す前のめり感を出したくて、僕らはこれをBook+(ブックプラス)と名付けました。

今更感があると評されるかも知れないのですが、それでも電子書籍時代の新しい読書体験の一例として世に一石を投じれたら良いなと思っています。そして、既存のリーダーアプリの作者の皆さんやユーザさんと一緒に盛り上げていって「もう全部PDFで良いじゃないですか」という現場の声を大きくする一助になれれば良いなと。読み手の声がゆくゆくは(まずは日本の電子書籍業界という狭い(?)世界かも知れませんが)本当に世界を変えていく力なのかも知れないなと思うのです。

弊社では通常の有給休暇とは別に家族の誕生日と結婚記念日を設けています。仕事は確かに大事だけど大切な人との時間も大事にしましょうという発想から創業以来そういう事にしています。

24時間を8/8/8と3つに分けて、1つは仕事、1つは家族、1つは睡眠が理想だと思ってますが「通勤」という物理的な移動時間を要するが故に、また、ぶっ通しで8時間労働するのは厳しいので1時間の休憩が間に挟まるなど、どうしても仕事のweightが必然的に高くなりますよね。そのひずみ(?)をちょっとでも和らげる事が出来ればという思いもあります。

制度の徹底は社長が行使してこそ実現するもの。

そして何より僕の無茶に付き合う為に全てを犠牲にしてくれている奥さんの誕生日に感謝を形にするという事で朝から晩までのオフを取らせて頂きます。時期的にはお盆休みっぽいのですが、誕生日休暇です。ウチは社長にお盆はありませんので 年に一日fullにオフな日は片手の指数にも満たないっすね(笑)

ちなみに、毎回お互いの誕生日の時は基本的に「旅」をテーマにしています。今回は名古屋。普段早起きしている強みを活かして(?)相も変わらず日帰りです。ぽつぽつTwitterなりFacebookなりに呟きながらオフを楽しんできたいと思います。とは言え、やっぱり気になるのは気になるので iPhone/iPad/MacBookAir/UQ WiMAX/Pocket WiFi は持って行くんですけどね(笑)

という訳で、明日の8/19(金)は僕個人への連絡が取りにくくなるかもですが予めご了承下さいませ。

iPhone/iPad好きの方であれば AppBank をご存じない方はいらっしゃらないでしょう。そして、AppBank をご存知であれば、AppBank Store というiPhone/iPad関連のケースやアクセサリを販売しているサイトもきっとご存知の筈です。

その AppBank Store のサイト専用の iPhone アプリが先日公開されました！種々様々な関連商品をランキングやカテゴリ毎に閲覧でき、大きな写真や動画やレビューも見れて買い物も出来てしまうアプリです。

大変有難いことに、このアプリに弊社はiPhoneアプリ開発部隊として関わらせて頂く事が出来ました。弊社含め3者が関係者としておりまして、もちろんまず最初にAppBankさん、そしてサーバ側はモバイル関連開発で実績を多数お持ちのエム・フロンティア様。あれだけの大量商品、大量アクセスがある AppBank Store のサイト構築と運営をされている会社様です。そして弊社。巧くチームプレイが出来たのではないかなぁと思っております。関係者の皆様、お疲れ様でした m(__)m

プロジェクトの途中でずっと「これは物販サイト専用アプリのお手本になる」「これはiPhoneユーザとしては見てるだけで面白いし買ってしまいそうになる」と思って開発させて頂いてました。

AppStoreのレビューを見る限りやっぱり同じように感じておられる方が多く、しかもアプリはアッという間に無料総合1位になっていたりもしてまして、開発メンバーとして関わらせて頂いた者としてはホントに感無量であります。ちなみに開発担当はおなじみ弊社 @itok_twit。僕はいつもながらの調整役ですね。

iPhone/iPadをお使いのお持ちの方は絶対に楽しめる且つ有用なアプリですので、是非使って見られる事をオススメ致します。ダウンロードはこちらから！！ウィンドウショッピング的に見ているだけでも結構楽しかったりしますよ！

2010年、電子書籍元年と言われました。1年経て注目のフォーマットEPUBの議論もだいぶと目にするようになってきました。しかし、依然としてまとまらないような気がしてなりません。

見えてくるのはフォーマットやリーダの乱立した混戦模様。国内の群雄割拠ぶりはこちらの電子書籍情報まとめノートさんのエントリに詳しいですが、多分このまままとまらないであろうこと、そしてまた5年後か10年後かに「今年こそは電子書籍元年だ」って同じように言ってるんだろうなぁという将来が容易に想像できます。シグマブックやWordsGear、リブリエのように歴史はやっぱり繰り返すのです。

最近は特にEPUBの議論を目にしたりするのですが、どうしても違和感を感じてなりません。EPUBでなきゃいけない理由が無いんじゃないかというのが僕の主張。

例えば、EPUBを始めとする電子書籍のメリットとしてリフローである(文字の大きさや画面の大きさに合わせて表示が柔軟に変え得ることの意味)ことが必ず出てきますが、その一方で、ページの考え方をどうするか懸念していたり、CSSはリーダによって解釈に違いがあり過ぎるから意図した見た目にするのが大変だねどうしよう、って議論があったりします。

他にも EPUB3 の前に散々議論されてましたが、ルビとか縦書きって話も同様ですね。禁則とか圏点とかもそうですかね。やっぱり見た目は大事なんですよ。「如何に紙への印刷と同じものが再現できるかが重要」なんてコメントも耳にしたりしますしね。そりゃそうです、見せる(魅せる)為の編集だし出版なのですから。だからどこまでいっても意図した通りに見せたい思いは必ずあって、結局WYSIWYGなのだと思うのです。

他にも例えばこういう記事もあります。

見開き表示に対応したEPUB形式の電子書籍を日本で初めて制作し提供を開始 － Apple独自の拡張仕様を活用し『JAZZ JAPAN』で紙の雑誌レイアウトを再現 －

固定レイアウトなEPUBなんて言葉が出てくると、もう何の為のEPUBか分からなくなってしまいます。リフローが良くて始めたEPUBなのに、レイアウトが重要だから固定してみました的な。じゃぁ、

何でPDFじゃダメなんでしょうか。

EPUBを論ずるときにレイアウトが検討事項として存在し、そのどこかに WYSIWYG 的考えが少しでもあるなら、誰がどう考えてもPDFに軍配があがります。Adobeに言わせれば ISO にまでなってるPDFを舐めるなっ！てモンじゃないでしょうかね、ホント。(まぁそんなAdobeもInDesignで早くからEPUB出力できる事をPRしていたりするのでよく分からないですが)

PDFには「全ての環境においてほぼ同様の状態で文章や画像を閲覧できるようにする」というミッションのもと1993年から地道に積み上げられてきた歴史があります。なので、書籍や雑誌というメタファーが大事で且つ見た目という要素が検討項目に入っている時点で、PDFからの脱却は考えない方が良いと思うんですよね。あるいは、コミック系の自炊でよく使われている jpeg 画像をzipで固めただけの ZIP BOOK 形式ぐらいに割り切ってしまうぐらいの勢いとか。だって、見た目が重要なんですから。

一方PDFではダメという根拠に、段組のコンテンツがiPhone等のスマートフォンでは読み難いという主張もあったりしますが、果たしてそうでしょうか。

こういう技術(工夫)も含めて読み易くする為の仕掛けはある訳です。段組→小さい→読みにくいはちょっと短絡的な発想じゃないかなと思います。アプリケーション層での見せ方の工夫をせずに、コンテンツの作り方まで手を入れようとするのは果たして合理的な選択なのか。

もしiPhoneで読み難い事を解消する為にフォントサイズ変更が自由なリフローという選択肢を取るのなら、レイアウトは犠牲にすべきなのは皆さん薄々気付いている筈なんですよね。だって、EPUBのコア技術はhtml+cssであり、webの世界でレイアウトが紙のような再現度を持ってない事は自明な訳ですから。

webにはwebで意図通りの見た目を実現するテクニックが様々醸成されて来た歴史もありますから、それを使う手もあるとは思います。html+cssなwebをマルっとzip化したweb魚拓+アルファな考え方ですね。スマートフォンやタブレット型端末に特化するならWebKitに最適化する事で概ねカバー出来るのでやり易い筈です。ちなみにAppleは MacOSX Safariの .webarchive という保存形式でそれを実現していて、iOS上ではUIWebViewに webarchive を食わせるとそのままWebスナップショット的に表示してくれたりもします。

まぁ色々書いていますが何が言いたいかというと、PDF なり jpeg なり webarchive なり、レイアウトや見た目を保持する技術は既に確立されているのに、何でわざわざ新しいフォーマットに飛び込んでレイアウトの議論に苦心されてるのだろう？ってこと。ここが凄く違和感なんですよね。

もちろん、リフロー以外にEPUBのメリット(とされるモノ)は沢山あります。でも、EPUBでなきゃほんとにダメかって感じで、決定打が無くやっぱり違和感があるのは否めません。

こんな風に。ほとんどはPDFで実現されているんです。何でそれをイチから作りなおそうとするのか？それが幾ら考えても分かりません。加えてPDFには、改竄されていない事を証明したり有効性証明をする為の ISO30000-2 ISO32000-2 として採用手続き中のタイムスタンプという機能もあります。EPUBではそこまでの考慮は無い。

確かにEPUBでしか規定できない情報もあるでしょう。でも、それの為にコンテンツの作り方まで根こそぎ変えようっていうのはどうかと思うのです。僕はPDF最強だと考えてまして、そんなにややこしい議論するならもう媒体はPDFで良いじゃんっていつも感じてしまいます。ページという存在、書籍や雑誌というパッケージングの存在がそれほど重要なら多分、PDF+アルファで良い。その上でもし電子書籍を論ずるのであれば、その論点は、電子化の新しい手法や仕様ではなく、

1. PDFを如何にリッチにするか
2. PDFを如何に読みやすくするか
3. PDFを如何に管理し易くするか
4. PDFを使って如何に新たな読書体験へと読者を誘(いざな)うか

という事にしたらどうかと思うのですよね。(既に1.はPDFの仕様が結構内包してますが)

開発者が一番嫌う事に車輪の再発明というモノがあります。既にプログラムがあるのに同じモノを作るだけの自己満足を揶揄する表現です。無論、自己学習の為に敢えて同じものを作る事はあったりしますが、あくまで勉強用途に限られています。何だか…EPUBの議論って開発の世界で言うところの車輪の再発明をしようとしている風に見えて仕方が無いのです。

電子書籍フォーマット「EPUB 3」ってぶっちゃけどうよ？

この記事を「で、PDFではダメなの？」という視点で読んで頂くと興味深いのですが、やっぱりEPUBでなければならない理由って出てこないんですよね。

それでも、この記事が言うようにフォーマットの是非は関係なくEPUBという新しいフォーマットの誕生が電子書籍業界に活気を与えるという理由等でやっぱりEPUBだという事であれば、やはり紙とページの概念は捨てるべきだと僕は思ってます。OPS(EPUB3では EPUB Content Documents 3.0となる)で文書構造が明示的に書かれる事になるのに、何で読み手の読書体験を分断する「ページ」という余計な区切りを取り込む必要があるんでしょう。元は html+css なのだから、web 的な読ませ方を想定するべきじゃないでしょうか。やはり「ページ」が必要なら繰り返しになりますがPDFで良いんです。ウィンドウの縦解像度に依存して無理やりpagingされるウェブサイト(html+css)って読み易いでしょうか？

読書が好きなので電子書籍は凄く興味あるテーマですが、どこか「書籍の電子化」ばかりを議論しているようで、電子化する事によるメリット(上述の件)の議論が置き去りになっている気がして残念でなりません。誤解を恐れずに書かせて頂くと、昨今の議論は電子書籍化ではなく単なる書籍電子化の再論に過ぎないのではないかと思います。フォーマットって別に読み手には関係無いんですよね。

上述の電子書籍の論点については自分なりのアイディアも一応持っていたりするのですが、今回のエントリがちょっと長過ぎたのでそれはまた別の機会に書いてみたいと思います。