かなり前から、「全ての存在を認めて、よく考える」を心がけてきた。そして双方の立場を考えることをした結果、敵対していた企業を研究しすぎて逆に好意的になってしまうというミイラ状態になった。任天堂はバカにしていたし、アップルもバカにしてきたが、彼らを紹介する本を読み、行動原理を理解していくと、敵対心は消えていつのまにか肩入れしてしまう。

労働組合も、経営を邪魔する存在、ストライキを行って社会に害を与える存在として嫌っていたが、団結権の行使、弱者は団結しなければ強者に対して交渉できない、ということを感じるに従って、その認識を改めていった。

例えば、JASRACも悪の権化と嫌っていた。しかし、音楽家個人と放送局や音楽利用者が直接交渉することを想像すると、個人は負ける。そのために団結して組織を作ることで音楽家の利益を守ろうとしている。そして音楽家がJASRACの考えに同意できないのであれば『JASRACを使わない』という選択肢も残されている。皆がJASRACに反発し、JASRACを使わなければ、その役目は終わる。JASRACが存在していることで、音楽はJASRACを通じて利用料さえ払えば、音楽家や利用者が直接交渉することナシに、誰でも使える状況になっている。

よく出る漫画の二次利用の問題の話がある。漫画の二次利用をした著作物が出回っているが、一次著作の作者に金が回っていない、と。仮に、漫画の世界においてJASRACとなるような組織が存在していれば、管理団体を通して利用許可が出され、売り上げのうち数％を一次著作者が取ることが出来る。このような二次利用の世界では実費以上の収益を上げてはならない、との約束事があるようだが、管理団体が存在してルールが定められていれば、より多くの利益を上げても許される世界は存在したのではないか、と。

これは漫画の世界だけではなく、出版全般や映像、ゲーム(映画)についても、割とそう思っている。なぜ、そのような団体が出てこないのかは不勉強なので知らない。音楽と放送の関係が独特だからかもしれない。

それぞれのWebブラウザ上で動画コーデックに対応していかなければならないが、iOS側はH.264を推している。以前、ChromeがH.264への対応を打ち切りにする、と報道されていたが、ChromeはFlashを同梱している。FlashではH.264を再生することが出来るため、逆に、HTML5のフォールバックとしてFlashが利用されることになるのではないか、という憶測が存在していた。

以前、Webブラウザ上でリアルタイムなやりとりを実現するためにCometという手法が存在していた。この技術をより改善したものがWebSocketという技術であり、TCP上で動作する。昨今の最新ブラウザはほとんどが対応の兆しを見せている。旧来のIE8,9のようなブラウザでは対応をしていない。しかしTCPなのでJavaやFlash上ではSocketを用いて実装が可能であり、ネイティブに対応していないブラウザではFlashへのフォールバックが手段として用いられる。

ファイルアップロードにおいても似たような事例がある。HTML5ではDataTransferオブジェクトを用いることでドラッグ&ドロップにてファイルのアップロードを実現している。Flashではドラッグ&ドロップを行うことはできない。HTML5ではmultiple属性によって複数ファイルのアップロードに対応しているが、レガシーブラウザでは対応できないため、Flashにフォールバックして複数ファイル対応するようなライブラリが存在する。

最新の事例では、ニコニコ動画が動画再生とコメント表示部分のUIを残して、コメント一覧のUIをHTML+jsに分離した、という流れもあった。

動画再生においてiOSではFlashの代替にHTML5が用いられ、H.264ではHTML5の代替としてFlashが憶測され、WebSocketではHTMLの代替にFlashが用いられている。

Flashの代替がHTML5であったのに、最近はHTML5の代替がFlashであるような事例が増えているなあと思った。

Twitterの投稿は140文字に制限されている。普通、この手のサービスは、いくらでも長い文章を投稿できることが優位とされる。しかし、Twitterは140文字に制限し、そして成功した。

そもそも、140文字に制限したのは、SMSの制限は160文字で20文字はユーザー名に割り当てる予定だったから、らしい。

この制限は、結果として情報を扱いやすい仕組みを生み出したのではないか、と考えている。

例えば、どんなユーザーでも1000回発言すれば1回はいいことを書く、と仮定する。これがブログ記事の場合、前後の文脈に「いいこと」が挟まれる。この前後の文脈に誤りや検討不足、賛同できない点があると、「いいこと」を他の人に宣伝しようとは思えない。そこをQuoteするための仕組みとしてtumblrなどがある。

twitterの場合、140文字に制限されることによって、前後の文脈を入れ込むことも制限される。結果的に「いいこと」が汚染されずに残る。それがRTされやすい仕組みになっているのではないか。

同様にミスリーディングをさせるような行為も可能である。前後の文脈抜きに刺激的で誤解するような文面をRTすることでtweetしたユーザーの意図とは違う意図で拡散されていく。

しかし、twitterのように情報に今までよりも制限を加えて上手くいっているサービスに気づいた事がないので、そのような共通した特徴を他のサービスで見る事ができない。残念だ。

第一印象

• 黒い
• でかい

でかい
大画面:908×486,中画面:672×486,小画面:908×150
大画面の場合、コメント欄が横幅1440～1600ないと欠けるようになった。マウスをコメント欄の上に載せれば動画の上にかぶさる形で出てくる。

あと再生ボタンもでかい。マイリストボタンが上部の大きいボタンになった。

このプレイヤーはとにかく、色々でかい。

情報整理
動画の概要（動画説明）が基本、収納されるようになった。再生数・コメント数が動画の下に落ちる。動画説明も下に存在している。動画説明を見ようと思えば、動画上部をクリックして展開するか、スクロールすれば良い。

ファーストビューで数字を見せないようにする工夫か。数字で動画を判断するまえに動画を見てもらいたい、という流れ？それとも動画を上部に持っていきたいから、か。

ソーシャル連携強化
動画レビューが出来るようになる。twitter・facebookと連携して紹介することもできる。目立つ。

twitterによる動画紹介と、その拡散を狙ったものか。今までの動画ページに比べて下方に伸びるようになる。紹介した文章がレビューとして載るので、それが投稿するインセンティブに。

Dock
「動画をもっと見る」あたりの動画がMacのDock風味で拡大されるようになる。html+js実装。

プレイヤー周り挙動
再生ボタンなど制御パネルが再生中は表示されなくなった。コメントも一度、クリックしなければ行えない。コメントしやすさ前提よりも動画閲覧しやすさ前提にシフトした。

再生終了後のおすすめがFlash上の実装ではなく、html側の実装でFlashにかぶせる形で実現されるようになった。というかFlash上の実装でおすすめ表示するのはFlash側の開発者のストレス半端無いので正解だと思う。

動画再生中は左右のコメント欄、ニコニコ市場が透明になる。透明になるのでグレーの背景に溶け込んで、目立たなくなる。

あと、「動画をもっと見る」にて動画を遷移すると、url移動したように見せて、実はjson読み込みによる遷移。つまり、戻るボタンを押した際にhtmlの再読み込みを行わずにFlashプレイヤー側で前回の動画を読み込む処理を行い、それに伴い、動画情報の切り替えも行う。

これの利点は、ページの再読み込みが必要ない、すなわち「jsとflashの再読み込みが必要ない」という利点があり、その中でも「flashの再読み込み」を回避したのは動画ページ遷移のスピードと快適性を高めている。

しかしながら、現時点ではプレイヤーが存在しないページに戻ろうとすると、Flashプレイヤーを放棄してしまうため、そのようなページをはさむ遷移では利点が得られない。「動画をもっと見る」場合にのみ利点が得られる。

将来的には、flashプレイヤーをロードしたまま、検索を含む全てのページをpjaxで遷移することで、動画ページの動画読み込みまでの待ち時間を格段に短時間にすることが出来ると期待できる。それを実現するとなると、動画ページのあり方、検索ページのあり方を含めてドラスティックな変化になる。やり方はあると思う。

flashプログラム側が複数の動画を遷移してもメモリーリークしないように色々と見張る必要があって大変だろうなぁという印象。今まではページ遷移すれば、ゼロからの読み込み、なので特にメモリーリーク周りについては考える必要はなかった。これからは同じFlashプログラムでいくつも動画＋コメントを読み込んで再生する形になるので、どこかで迷子になるObjectが出やすそう。

通常、

というURLだが、「動画をもっと見る」のサムネイルをクリックしたときに、json情報を読み込むために

という形にてjsonリクエストを行う。そのjsonを公開しようかと思ったら、userAge、userPrefecture、userSexなどの情報が入っていて、ビビる。何に使ってんだ、その情報。アカウント情報を見たところ前述の情報は非公開設定になっている。

プレイヤー設計方針
コメント周りのギミックもhtmlに逃がしている。ということで、Flashによるニコニコプレイヤー、nicoplayer.swfの機能を動画再生とコメント表示とコメント投稿に切り出して、それ以外のUI部分（コメント一覧[設定]、再生終了画面）をhtmlに逃がした。逃がした部分はhtmlなので設定画面やコメント一覧は気分で変えられる。externalなんたらでjsとflash部分が繋がれて反映される。

たぶん、ブラウザ側のjsがもたつくとかあると、影響は大きい。

この設計方針はむしろhtml5とflashの双方で利用できる画面構成を考慮した結果であり、PC向けにはflashの方が適しており、flashが使えない場合にはhtml5にフォールバックすることを目的としたものであると推測する。

flashを使った場合の利点は動画再生の際のバッファ管理と滑らかなコメント表示部分であり、それをflashに残したという印象。仮にhtml5にフォールバックしても不満足ながら再生できる状態に持っていった、と。んでコメント一覧などのUIはflashだろうとhtml5だろうと共通部分なので使いまわせる、と。将来的にhtml5がflashと同等の能力を持った時点でflash捨てるつもりだな、と。

そのような推測を仮定すると、ボタンが大きいのは、おそらくタッチ端末で利用することを想定してのもの。

今のところ分からないのは、コメント投稿部分をflash側に残している点。なぜ、そこは共通化しなかった。

総評

でかい
くろい

UIも変わったけれど、プレイヤーの中身がかなり変わった。flashでもhtml5でも再生できる形に持って行っている。その変更はよく思い切ったと思う。これに皆が慣れてくれれば、html5移行は楽。

html側にデザインがひっぱられているので、既存のflashに慣れたユーザーには違和感あると思う。

flash側とhtml側の担当者が別々だったら、色々と大変だろうなー。apiの策定とか。一人でやっていたら、それはそれで大変だけど。

このプレイヤー作った人は大変だったと思うのでお疲れ様です。

色々な声を無視してがんばって下さい。

node.jsとその他プラグインを堪能。

• socket.io
• express
• connect-assets
• coffee-script
• haml-coffee
• js2coffee

最初は素直なJavascriptで試していたが、coffee scriptでないと書きたくない気持ちに襲われてcoffee-script入れる。

app.jsにアプリケーションの記述を行う。起動するときは

node app.js

のような形。coffeeでapp.jsを記述するためには最初は

coffee -wc app.coffee

というコマンドを別のターミナルで起動して自動変換していたが、他のテンプレートを調べると、server.jsというファイルを用意して

require("coffee-script");
require("./app");

というコードを書いておくと、app.coffeeのままでも実行できるということが分かって楽になった。
jsからcoffeeに変換するにはjs2coffeeを使う。

connect-assetsを使うと、assets/js/app.coffeeやassets/css/app.stylなど、assetsディレクトリに分けて呼び出すことが出来る。htmlの中にインラインでjsやcssを書きたくない人向け。

socket.ioは面白い。node.jsのEventEmitterの仕組みでemitで発火してonで受信する。その流れがサーバ側とクライアント側で同じように書くことができる。サーバでもemit,onだし、クライアントでもemit,on。このあたりが面白い。あとIE8でも動くし、公式にはIE5.5でも対応すると書かれている。すごい。

vim上で書く場合は、jadeやcoffeeのための環境づくりをしておかないと、タブキーを押したときの挙動でスペース2個のはずがTABが出てきて、毎回修正しながらの作業で萎えてくる。

全体の感想

node.jsというか、socket.ioそのものが目当てで試してみた。だからかもしれないが、html生成部分やjs,css生成部分、routing周り、そこまで使う必要はなく、socket.ioが使いたければ、その部分だけ使うのが正解で、それ以外の部分は他のフレームワークに仕事をさせた方がいいよね、と。node.jsだけで済むようなライトウェイトなサイト、もしくは自分だけ身内だけで使う用途なら割と便利に使えるのではないか。

なので必要な部分をガッとapp.jsに書いておいて、他のフレームワークからsocket.io通じて呼び出す形になるのかな、と。例えばメッセージの部分だけ切り出してapi化して使えるようにしたpusherというサービスが存在しているが、そのような形を自分で作る、と。

この呼び出し方は、クライアント側jsをnode.js側に置くのか別フレームワーク上に置くのが正解か、分からない。別フレームワーク上に置いてしまうと呼び出し部分と処理部分が1つのパッケージにならないので、それはそれで不安かな、と。

既存のセッションとどうやって絡ませるのがいいのか、は分からない。

もしかしたら、ブラウザの送信をnode.jsで受けずに別フレームワークで受ける、

ブラウザ→送信→（別フレームワーク→node.js）→受信→ブラウザ

という形が良いのかもしれない。

「Google Driveは規約が問題だからDropBoxを使い続ける」という意見が多い。その意見にどうかな、と思う所がある。そういった思考ルートについて最近考えている。

NAVERまとめの「Google Driveの利用規約がヤバ過ぎる」という記事などが例に挙げられる。「NAVERまとめ」のこのようなまとめにリンクを張って編集者に金が入り、そのような情報の拡散に寄与するのは悲しいので、リンクは張らない。

—-

規約がどうであれWebサービス・ストレージサービスに「平文のデータを渡す行為」は、「その平文のデータが漏れる危険性が著しく高くなる」ことであると考えている。一度相手に渡したデータは、利用しているサービスの社員に意図せずアクセスされる可能性がある。加えてサービスが瑕疵や不正アクセスによってお漏らししてしまう可能性もある。

だから機密のある文章、社内秘、秘密にしておきたいプライベートの情報などは、そういったストレージサービスに預けることは危険である。にもかかわらず、そのようなデータを預けている人が少なからず居るのだろうと予想する。

Google Apps for Businessというサービスが存在しているし、sales forceというサービスが存在している。正直なところ、このようなサービスが普及することが信じられない。社内機密を扱う便利サービスは、全て各々の社内で運用されるものなのだろう、と。

思えば、この概念は初めから成立していなかった。プロバイダメールがあったからだ。プロバイダのメールは、メールサーバをプロバイダが立ち上げており、（何が起こるのかを想像しなければ）見ようと思えばプロバイダは利用者のメールの内容を見る事ができる。にもかかわらず、その意識なしに私自身もメールが安全なものだと考えている。麻痺しているからだ。

Gmailなどのメール本文を参照して広告を出すサービスを利用することは、そうした麻痺が成せることでもある。Gmailは広告モデルで運営されているので、GmailはPGPなどの仕組みは導入できない。しかしメール上でPGPでやり取りをする、という選択肢は許されている。しかし、PGPを使ったメールが少ないからこそ、広告モデルで成り立つ。

過去に暗号化した添付ファイルを送付して後からパスワード送る行為について考えたときにも、その麻痺した感覚に疑問を持った。PGP上でやり取りをすればどのプロバイダのメールサーバを使おうとも、より安全な環境が手に入る。かなり前のメールソフトでもPGPは出来るが、広まっていない。

メールサーバと同じように、インターネットを走るデータ、IPパケットすらネットワーク管理者は取得可能である。その問題を解決し、終端でしかデータの中身が分からないように暗号化できるSSLは広く利用されている。SSLはSSLを利用者が使っていると（あまり）意識させていない（本当は意識させなければならない）。その成功要因からすれば、意識せずにセキュアなメールが行えるシステムを考える必要があるのだろう。

ストレージサービスに類するサービスにおいても既にそのような試みは生まれている。かつて2008年ごろにFirefox 3 Beta 4とWeaveの感想という記事においてMozillaのWeaveに触れた。このサービスは今はFirefox Syncと呼ばれている。この記事内では触れていないが、このサービスはローカルのマシンで鍵を生成し、その鍵で暗号化された内容をサーバに送信する。そのためサーバの管理者はデータを参照することができない。

詳しくはSync のデータを保護する方法に書いてある。

あなたの リカバリキー は、このデジタル金庫を開けることが可能な世界でただ 1 つの鍵であり、他にこの金庫をこじ開ける方法はありません。誰かが Sync サーバにあるあなたの Sync データにアクセスしたとしても、あなたのデジタル金庫自体を見られるだけでその中身が見られることはありません。リカバリキー は、同じキーを作成して金庫を開けるには数千台のコンピュータを同時に何年も動かさなければならないような方法で作成されます。

Mozillaは既にストレージサービスに関する不安を払拭している。素晴らしい取り組みだと思う。鍵を無くしたら永久にアクセスできなくなるデータであることが正しい。だからこそ、データはリモートとローカルで冗長化されなければならないし、鍵はバックアップしておかなければならない。

だが「鍵を無くしたら永久にアクセスできなくなる」サービスは昨今は相手にされない。そうなると利用の可否の判断はどうなるのか。相手の会社を信頼するか否かになる。その信頼のよりどころは規約が正しいか、今まではどうだったか、などの要素なのだと思う。
仮にインターネットからアクセスできるファイルサーバが欲しい場合、自分でファイルサーバやるのとGoogleのストレージサービスとどちらが安全だろうか、考えるのかもしれない。

DropBoxが切り開いたストレージサービスの道にGoogleという大企業が入り込んできたからオリジナルを守らなきゃいけないという意思なのかもしれない。

これが、
それ以前に「漏れて困る機密情報は暗号化もしないでオンラインストレージに入れるなよ」、と、思う訳である。

漏れて困るから別のストレージサービスを使うという話ではない。漏れて困るなら安全ではない方法で使うべきではない。コストが上がっても、OCRかからなくても、検索できなくても、良いというのであれば、Firefox Sync式のデータアップロード方法を取るようにGoogleに要望すべきである。（しかし、便利なサービスを実現するにはローカルに全ファイルを展開してインデックスする仕組みになるので、計算量が大きく、例えばGoogle Desktopのようなものになるだろう）

漏れて困る情報をスマートフォンアプリが勝手にアップロードする件とは違い、自分からデータをアップロードして、自分から危険に晒している。さらにはメールも同じ状況下にある。その点を考慮して、漏れて困る情報は日頃からPGPと暗号化を行うか・そのような技術を利用しないのであればアップロードしない。

機密情報をそのようなサービスに預けて、万が一、漏らしたサービスが存在したとして、社会的制裁と（微妙だろう）損害金で帳尻が合うのであれば、そのようなサービスを活用すべきである。その帳尻が合わないのであれば、やはり、機密情報はアップロードするな、と言わざる得ない。

「今までも漏らしていないし、これからも絶対に漏らさないだろう」、という考えは、ここでは引用したくないけれども原発神話であり、お漏らししたときの影響範囲と対処が分かった状態でなければならない。

Google Apps for Businessも同様で、そのような不安を抱えたものだと思っている。

これは自分でVPSや自宅サーバでファイルサーバを立てても同じ話で。ネットワークに常時接続されている限り、自分でお漏らしした場合も考えなければならない。となると、ネットワークから分離されたUSB-HDDが良いという話になるのだけれども。…紛失とか、盗難とか。その場合に備えて暗号化ドライブにしておくとか。

結論

お漏らしが怖いなら機密情報を置くな、あと社内秘置くな
機密情報置きたいなら暗号化しろ、どの暗号化すればいいのか分からない場合はやめておいた方がいい

その結果、分かったことがある。参考になるかどうか分からないが書く。

体験版商法は割と当たる

体験版商法は割と当たる。1巻は無料でその後の続巻は有料、などのサービスがあるが、そのようなケースでは、続きを今すぐ読みたいという欲望と戦うことになる。…これに勝てない。本屋なら立ち読みすれば買わずに済むのだが、電子書籍の場合、楽して家で読んでいるので、外に出るのがダルイ。本屋が営業していない時間でもある。

電子書籍の利点として24時間営業であることを忘れてはならない。実店舗の場合、買って積んで読みたいときに読む or 電車に乗っている間に時間があるからその前に買う というスタイルで本を読んでいた。それに加えて寝る前に本を読むか、となった場合に、タブレット端末で読んで気に入ったら買う、というスタイルが出来た。

ちなみに体験版の無い電子書籍は買ったことがない。Amazonで書籍をレビュー参考にして買うことはあるけれど。電子書籍についてはない。

買いにくい本が買える

携帯向けの電子書籍でよく売れているのが、実店舗で買いにくい本だ、という話は聞くが、確かにそのとおりだ。それが買える利点はある。

それは実店舗の人間に対して顔などの情報を閲覧されることが嫌だからだ。同じように電子書籍の場合、電子書籍やっている業者にクレジットや氏名などの情報を渡したくない、という個人的思想がある。いや、漏れたら嫌だし。電子情報は漏れるし。

その場合、iOS系の場合は、アプリやアドオンで処理される場合、Appleが決済を中継してくれる。Appleになら情報閲覧されてもいいけれど、得体の知れない電子書籍業者には情報渡したくない、という思想を満たしてくれる。

いや、一度、電子書籍のサイトに登録して買ってみようかな、と思ったのだが、個人情報とクレジット入力の時点で躊躇してしまう。いいのか、と。他の決済代行業者が仲介してくれるのであれば、例えリスクが同じであろうと、さらっとポチってしまうのだが。心理的な抑制だろうか。

捨てる手間がないのがいい

いや、捨てないけれど。例えば紙の書籍の場合、場所を取る。本を入れてそのままのダンボールが２，３積まれている。本棚に入りきらなくて。このまま本を買い続けると、読み終わった本が増えていくんだろうな、と思うと、対処しなければ、と思う。思うが、積極的に何かしようとは思わない。

電子書籍によって流通が最適化されてコストが安くなるので安い価格で売れよ、という気持ちになることはあるが、電子書籍だと場所とらないからそれはそれで新しい価値はあるよね、という気持ちにだんだんなっている。前述の買いにくい本を仮に買った場合、それが部屋にあるのは嫌だ。いや、別にあってもいいんだけどね。何か嫌だ。

んで、いつでも読めるといえば読めるので、それはそれで価値があるかな、と。

関係ないけれど

デジタルデータなので、本の権利者は電子書籍の販売業者に売り上げ誤魔化されることあるんじゃないの、という心配がある。電子本が売れたら売れたで、本の権利者に1度でもping（特典ダウンロードなどの形で）が飛ぶようにしないと、マズいんじゃない。

タブレット端末で外で電子書籍を読んだことはない

生活スタイル的に、外で読まないな、と。読もうと思うのは、ほぼ寝る前。メールチェックと共に。

BC-309
約10,000円
50g
SDカード記録
アプリケーションにて分析
自動認識機能
CSV出力（らしい）

HBF-208IT
約8,000円
100g
USB/FeliCa携帯連携
ウェルネスリンク（Webサイト）に情報送信
ユーザーごとに1から4のボタンを押す必要がある
説明書が読みやすい

両方
どちらも色々計れる。
一定の情報を溜められる。
繋げないとグラフ化できない。

検討
BC-309はFlucardと連携できる可能性がある。可能性があるだけで無理かもしれない。SDカードを差し替えて計るのは正直つらい。CSVなので加工が楽しそう。flucardとの連携が上手くいけば、データ送信部分をサーバで処理できるので可能性は広がる。

HBF-208ITはウェルネスリンクとの連携が前提で手元にデータが残ることがない。ウェルネスリンク自体は良くできている。AndroidとFeliCaを使った連携が特に良い。良いがAndroidを持っていない。ファイルが残らないかと思ったらCSVでダウンロードできるようだ（ファイル出力）。USBデバイスサーバーでLAN対応できる可能性がある。ウェルネスリンクを用いる場合は自立してデータ送信できない。その気になればUSBプロトコルの解析。ウェルネスリンクは手動によるデータ入力にも対応する。

その気になればBC-309+ウェルネスリンクも可能。

BC-309+flucardはギャンブル。HBF-208ITは安定。

ぐぬぬ。

かたや、外国では著作権をないがしろにしたような挙動をしていたりする。彼らは著作権が侵害されることを前提として、オンラインを重視したゲームなどに注力していたりする。

いっそのこと、著作権のない世界を想像してみよう。

著作権のない世界では、すべての著作物は複製可能である。ひとつの作品をネット上で公開した場合、複製を禁ずることはできない。ひとつの作品を販売した場合も、購入した者が複製して配布することを防ぐことはできない。

このような世界の場合、著作者はどのように利益を得るのか。つまり、どうやって著作による専業で生きていくのか。

3つの手段がある。

1つは当初は無償で作品を作成して、後から寄付を受けること。

2つは単独で著作者を養うことができる金持ちに囲われること。

3つは単独で著作者を著作者を養うことができない人々が集まり、委員会を作成して予算を集め、契約の形で作品を作らせること。

2と3の方法は製作した著作物は「門外不出とされ特定の者だけが楽しむ」という形と、「公開して公共の財産とする」という形の2つが出口として存在できる。

そんなことを「Tokaido」を巡り、募金型OSSプロジェクトで議論が噴出の記事を読みながら、思った。

当時のmp3プレイヤーは単純にmp3ファイルをストレージにコピーすれば使えるようになるものだった。それは一見使いやすいように見える。当時、友人が使っていたウォークマンに音楽を入れるためのツール、sonicstageなるものを見せてもらったが、どのように使えばよいのか分からなかった。

iTunesはCDを入れたら勝手に起動して、インポートする、というボタンをクリックするだけで曲が名前つきでリッピングされていく。楽だ。これは、既存の音楽CDを持っていて、それを持ち歩きたい、という要求から来るものだ。

PC上でプレイリストを作って、同期することが出来る。逆に言えば、PCがなければ上手く設定することが出来ない。PCと同期しない選択肢は、MDデッキなどでCDからMDに吸い取る、というものなので、現実的ではなかった。

仮に、CDから簡単にリッピングして簡単にiPodに同期できるソフトウェアが存在することが、音楽プレイヤーとしての勝利であるのなら、タブレットに関してはどうだろうか。

一旦、picasaのそれが近い、と思った。picasaはデジタルカメラの写真を管理することに優れており、顔認識して分類することもできる。一覧して写真を見たりなどの操作がしやすく使いやすい。

しかしタブレットの皆のゴールは写真だろうか。否、書籍だ。

iPodはCDからのメディアの載せ替えだったように、書籍からタブレットへの乗せ替えはどうだろうか。書籍からスキャンした結果（自炊したもの）を上手くPC側で管理できるソフトウェアが思いつかない。

であるのなら、電子書籍を対象としたタブレットを設計するメーカーは、積極的に自炊を支援することが必要ではないか。自炊した結果を美しく管理できるソフトウェアをバンドルすべきではないか。

すなわち、現状のタブレットのビジネスにおいて、新しいメディア・電子書籍を売る、という一点に着目しすぎており、既存の書籍を電子化したいニーズを無視していると感じる。

iPodの場合は、既存のCDユーザーを取り込みライブラリを作成させ、その上でiTunes Storeの提案を行い、使い込んだライブラリの中に溶け込むように音楽を売っていった、ように見える。ライブラリを使い込んで、今後ずっとそのライブラリ（とソフトウェア）と付き合っていく覚悟が出来なければ「ひも付き」の音楽なんて買えない。

このiPodのやり方を踏襲するのであれば、まず、既存書籍のライブラリ化が必須であり、その使い込んだライブラリに次は電子書籍を入れるか、という順番でなければ乗り換える気がユーザーには起きないのではないか。一口にライブラリ化といっても、画像をきれいにしたり、文字をOCRしたり、など、様々な後処理が考えられる。工夫のしどころはある。

よって、「電子書籍ユーザー対象のタブレットの勝利を決める要因は、既存の書籍のライブラリ化を簡単に、そして美しく行える同期ソフトウェアのバンドルによって左右される」と、考えている。

という、お話でした。

ブラウザの概念が分からない。ブラウザを開かせようとすると、safariという名前のアプリになっている。「メール」「ミュージック」などは一般的な言葉だが。しかし、safariを「ブラウザ」と置き換えてしまうのも、何か、変な気がする。

Yahooなどで検索させようとすると、タッチするポイントが分からない。検索エンジンはリンク、説明文、などで構成されるが、説明文の方をタッチしてしまう。

iPadのホームに周辺店舗のチラシのブックマーク（アイコン）を置いて、それを開いて見る、という一連の作業を提案した。インターネット経由で店舗チラシを見る、という事柄に興味を持っていたからだ。

実際にやってみると、ホーム画面からアイコンをタップしようとするが、上手くタップできない。

タップは指を置いてすばやく離す必要があるが、上手く離すことが出来ず、タップとして動作しない。iPadのホーム画面は横スライドすることによって多くのアイコンを表示することができるが、手がぶれている場合、横スライドとして認識されてしまい、タップとして動作しない。この作業で4,5回アイコンをタップすることでようやく認識された。

チラシに関しては直接PDFを開くように設定した。PDFを開くと、それは画像と同じく操作することができる。指をスライドしていくと見えていない別の部分が見えるし、2本指でのつまむ操作で拡大・縮小が出来る。説明すれば、それは簡単に出来た。またホームボタンを押すことでホームに戻れる、ということを説明しても、それは理解できた。意外と出来るものだな、と。

この一連の限られたPDFを見るという動作の中で最も困難だったのは、ホームのアイコンのタップだった。ホーム画面のアイコンは指の命中率が低い人にとっては、小さすぎて押し辛いものだった。ホームボタンを押せばホーム画面が出るので、その点は非常に良いのだが、ホーム画面のカスタマイズ（例えばクリック領域を広く取るなど）が出来ないので、そこから色々な使い方を提案したりと展開することができない。

この点、Androidの方はカスタマイズ出来るので良いな、と。例えば、三重県玉城町の『オンデマンド交通システム』の実証実験に使われているAndroidのメニューは「緊急通報」と「バス」の2つしかない。字が大きくて良いし、タップで反応する場所も広くなるようにアイコンが大きい。このようなカスタマイズが必要に応じて出来るようになると、リテラシーがない人やお年寄りに使いやすいはず。

2番目に困難だったのは、ブラウザ上の画像をタップすることだった。某店舗はPDFに直接リンクができなかったので仕方が無くWebページにリンクした。そこは簡単な画像の2択があったのだが、「画像をタップすると次のページに移動する」という事柄をページを見ただけでは理解できなかったため、躊躇してしまった。チラシの縮小した画像があったため、ピンチ操作（2本指で拡大する操作）を誤って選択してしまうことが多かった。確かにその通りだ。

この点について、どのようなメニューがあれば良かったのか、考えても思いつかない。教えれば済む話なのだが、Web上のリンクがどのような場所なのか、iPad上で説明できるかどうか難しい。マウスなら、指のマークに変わるので、そこはクリックできる場所だと分かるのだが。

そんな感じで1日目が終わった。続ける気力があるのかどうか分からないが、とりあえず使える形で置いておこうと思う。

既に信頼できるドメインありサーバ（固定IPアドレス）を使っているのであれば、そこに動的IPアドレスのサーバからIPを渡せばいいのかな、と。

やっていることは外のDDNSサービスを使ったときと同じで、IPアドレスを渡す先が自分のサーバかDDNSかの違いだけ。

外部のサイトのjavascriptを読み込んで表示している。今までは、それら提供者への性善説的な信頼においてjavascriptのコードにまずい所はないだろう、と。が、最近、とらっきんぐの問題等、色々出てきているので。

外すのが流行りになってる！！

chromeの場合は開発者ツールで何処と通信しているのかが分かるので、その機能を使って意図している場所かどうか調べる。

確かにmicroadへのリクエストを出している。

こわー。

ちなみにボタンを外すと、こんな。

外部から呼び出しているjsは、知らない間に中身のコードが書き換えられてしまうこともある。ボタンをつける方も一定の管理が必要ということかね。

もしくは、よく使われるjsは皆でソース読んでおこう、という話なのかね。誰々がソースを読んで問題ない、と判断していたから信頼する、みたいな。

その1つは地産地消できる規模感があること。

数式っぽく表す。リアルタイム性が高ければ高いほど、中毒になる。

リアルタイム性 ＝ 購読品質　×　情報発信の容易さ（140文字、1枚絵）

購読品質 ＝ 友人・知人の購読数 × α + 有名人の購読数 × β + 好みの趣向の購読数 × γ

購読数 ＝ 参加者数 × 検索性

これを当てはめる。Google ReaderとRSSでもいいし、twitterでもいいし、pixivでもいい。コンテンツ作者のコンテンツ追加頻度は、大きくは、情報発信の容易さに依存すると考えていて、ブログ記事や1枚絵の場合は重くて容易ではないが、twitterの場合は140文字でかつ10文字くらいでもどうでもいいので、容易だ。

式展開していくと、見る側としては「参加者数」「検索性」「情報発信の容易さ」にリアルタイム性（中毒）が左右される。

「検索性」というのはなかなか厄介で、自分好みの購読をするのは難しい。twitterやpixiv、RSSそれぞれで難しさを感じている。これを上手くやる方法はないものか。

次に作る側について考えてみる。

（コンテンツ作者の場合は）見てもらった・評価された場合の快楽　＝　閲覧数　＋　コメント数　＋　ＲＴもしくはお気に入り
閲覧数　＝　品質　×　フォロワー
コメント数　＝　閲覧数　×　α　
ＲＴもしくはお気に入り　＝　閲覧数　×　β
品質は0から100まで、と定義

快楽　＝　閲覧数（1 + α + β）＝ 品質　×　フォロワー数 × （1 + α + β）

つまり、自分の作成の「品質」と「フォロワー数」に快楽が左右される。自分の品質がせずともフォロワー数がある程度居れば、モチベーションは続く。

で、

フォロワー数　＝　購読数　×　(100 – 品質)　×　α ＝ 参加者数 × 検索性 ×　(100 – 品質)　×　α

という形になるから、「品質」に自信がないとなると、「参加者数」「検索性」に左右される。参加者数が必要ということは「地産地消できる規模感があること」ということだ。
作りながら見る、という活動を経て、この手のサイトは大きくなっていくはずだ。

その後の現象として、見るだけ、が生まれる。

よって始めるのであれば参加者数０からだろうから、「フォロー・フォロワーシステム」「地産地消」「情報発信の容易さ」「検索性」（出来うるのなら「有名人の取り込み」「特殊な趣向に偏る」）という点にこだわって、物事を進めていくと、リアルタイムWebとして上手くいくのかな、という予想が立てられるのである。

続かない。

自分の情報発信が即時に伝わる＝リアルタイム発信性

コンテンツの持ってくる場所が違った。自分自身パッシブWebでは自動コンテンツ検索エンジンの活用によってコンテンツを差し込むことが主で、そのうち、「番組」を誰かが作っていくだろうという考えだった。

twitterは140文字で出来る可能性で色々なことを生み出していった。画像投稿サービスが生まれた。Youtubeのリンクを張れば見る事ができる。ニュース記事やブログ記事のURLを張れば短縮リンクが表示される。短縮リンクと共にコメントが書き込まれる。

多くの人が情報発信者になっていた。彼らをトリコにするのは何か。

それは隣人のリアルタイム性に加担できる、という点ではなかろうか。twitter上で情報発信を行うことができるのは、既にフィルタリングを超えているからであって、その時点で何らかの評価がされ、それを通過している。

自分が興味のある事項を発信すると、即時に相手に反映される。相手はリアルタイム性のトリコになっているので、すばやく自身の情報発信を受け取るだろう期待がある。場合によっては反応がある。これはネットワークで言うところのRTT（ラウンドトリップディレイタイム、往復遅延時間）なんだな、と。往復遅延時間が短いほど、活発になっていく。

これらの特徴によって、twitterはニコニコ生放送よりも、Ustreamよりも、手軽で活発なサービスになりえた、と。

pixivもリアルタイムWebである

pixivに関してもtwitterとのアナロジーで説明できる。pixivはmixiベースの友達システムだが、twitterゆずりのお気に入りユーザーシステムも持っている。どのように作用するのかというと、自分が絵を書いてアップロードすると、友達・お気に入りユーザーに入れている人、のタイムライン（便宜上の呼び名）に差し込むことができる。

このため、自分が絵を描いたら購読者が見てくれる率が高いので描きたくなるし、他の人の絵をフィルタリングされたものがリアルタイムに流れてくるので見る側としても飽きないシステムになっている。

「膨大なコンテンツを引き出すためには、見てくれる人が必要で、見てくれる人を作るためにはリアルタイム性が必要なのだ。」

この2つのシステム、twitterとpixivは本当に良くできている。着目すべきは社会的関係を持ち込まずにネット上の人格のみでも活動可能な点だ。社会的関係を重視するネットワークの場合、友達システム（すなわち相互に許可するシステム）が必要になる。社会的関係から離れたとき、それは購読（subscription、follow、favorite）だけでもいいのだ。

今までのSNSはmixiなどの社会的関係をつなぐものからスタートした歴史的経緯上、好きなもので繋がるSNS、ニッチな分野のSNSにおいても友達システムを導入したものが多く見受けられる。そのシステムは正しいのか再考してほしい。

続く。

リアルタイムWebについて調べてみた。そして、パッシブWebの特徴である「リアルタイム」と「誰もが能動的な活動＝皆が情報発信」が融合したものがリアルタイムWebなのではないか、との考えに至った。

パッシブWebでは「一部が情報発信する」に留める考えだった。「皆が情報発信」を行えるようにすることで、皆が7つの大罪の業火に焼かれるのではないか、と思ったからだ。そうでもなかった。健全にやろうと思えば健全なのだ。

リアルタイムWebについて自分なりに再度、特徴を整理することにした。他所には通じない考えなので、ここだけの話と理解してほしい。

リアルタイムWebの特徴

• 見るたびに異なる情報を欲する＝リアルタイム性
• 自分の情報発信が即時に伝わる＝リアルタイム発信性

見るたびに異なる情報を欲する

パッシブWebにてリアルタイム性とフィルタリングについて説明した通り。

例えばTwitterを例にとって考えてみる。

フィルタリングはフォローという仕組みで行っている。人と趣向を結びつけている。だから皆、プロフィールに属性を記述しようとする。

リアルタイム性については、フォローを増やしていくことで満たされる。例えば最低限フォローは5人以上とか20人以上とか100人以上とか、そういう指南が存在していることが、リアルタイム性のあるタイムラインに価値があるということを示している。加えて140文字に制限したことが大きい。これによって気軽さ、敷居を下げることで、誰もが短い文を吐き、リアルタイム性に拍車をかけるのだ。長い文章も、短くてもいいから少しずつ公開される方が良い。文章のばら売りだ。

twitterは自分自身、Eメールシステムの焼き直しにしか見えなかった。twitterはメールが公開されるEメールシステムである、twitterは1社のみにて提供されるメールシステムである、と。APIが公開されているのは確かに良い、良いが、それはメールクライアントと何が違うのか？

その答えが、今まで考え続けてきたリアルタイム性だった、と理解したときに、感動した。

続く。

操作なしで自分に対して価値ある情報を得るためには、フィルタリング設定を行わなければならない。フィルタリングをしなければ有象無象からリアルタイムに必要な情報を自動取得してこれない。これをどうするのか。

それはやはり、周辺情報を活用するアイディアしかない。時間、場所、行き先、経路、音声、URL、興味、などのパラメータを利用することだ。今見ているテレビやラジオ、ビデオ、音楽、本、サイトに関係する情報、今いる場所、近辺の店舗情報、電車・バスの時刻表、天気、気温、湿度、花粉（情報・対策）、カレンダー、イベントなどの情報をリアルタイムに提供することが理論的には可能そうだ。

これらの情報をWeb上のコンテンツ、動画や音声、解説などから引っ張ってきて表示する。興味のあるものだけに絞れるようにする。

大事なのは、「リアルタイムに」「同じものを見ている」「人々がつながる」ことで、見ているものに対してコメントできると、より、コンテンツに広がりが出てくるな、と。

と同時に、誰かがコンテンツを管理して、番組表のように流し込めるようにする。例えば花粉対策の動画・文章・製品などの情報を花粉に興味のある人々にリアルタイムに流し込んで、コメントし合う。番組は動画でしか作れない、という概念を破り、WebのURLと作者と視聴者のコメントだけでも番組足りえる。

それらの一部の番組作者によって運営されるパッシブWebこそがテレビに代わる次代を作る。と、妄想したり。

iPadを買って使い道ないなー＾＾探さないとなーと思い、発売から9ヵ月後に思いついたのが、ここまでのパッシブWebという概念だった。

その後、リアルタイムWebという概念が出てくることになる。

続く。

なぜ、リアルタイムに価値があるのか。それはオンラインゲームの観察からヒントを得た。

リアルタイムは中毒性を生む

オンラインゲームは何故面白いのか、ハマるのか、という議論をよくしていた。よく出来ているなと感じたのは、オンラインゲームに熱中する（納金してしまう）要素として7つの大罪が挙げられる、という説だった。

「大食」「肉欲」「強欲」「憂鬱」「憤怒」「怠惰」「虚飾」「高慢」

これ以外にもう1つの要素を見つけた。オンラインゲームに自分が参加していなくても、ゲームそのものの時間は進んでおり、次にログインしたときには情報がまったく変わっている、という点だ。これはオフラインゲームには無い特徴で、オンラインゲーム特有だった。

もう1つの事例はRSSだ。ブログの記事の更新を手早く手にするためにRSSという仕組みが普及した。これを100くらいGoogle Readerに登録しておくと、ログインするたびに新たな記事があり、中毒気味になる。今でも、記事の更新がないか、すぐ確認してしまうくらいだ。

このことから、「見るたびに新しい発見、コンテンツがある」ことに意味がある。リアルタイムは中毒性がある。と悟った。利用者が無駄と思える情報は無視されるが、すぐにコンテンツが切り替わるのであれば、付けっぱなしにしてもいい、と思ってくれるはずだ、と。

7つの大罪は嫌いだ。人を不幸にする。だから見るだけでいい。

だから―――結果的に「リアルタイム」の特徴は、すなわちテレビ的にする、ということだった。

続く。

自分自身、この言葉に至る前に、2009年頃から2011年まで、パッシブWeb(passive,受動的な)という造語を作り出して、色々なことを考えてきた。パッシブWebについて考えてきたこと、リアルタイムWebに関してどう考えているのかについて、書き残しておきたい。

Passive Web

パッシブWebとは消極的な、というよりは受動的なWebである。当時、インターネットWebがアクティブ（能動的）メディアで、テレビ放送がパッシブ（受動的な）メディアである、という言説から来ている。

かつては、自室に入ると習慣的にテレビの電源を入れ、見る見ないに関わらず、電源を付けっぱなしにする、という行動を行ってきた。興味のある話題が流れてきたら聞き耳を立てる。そうではなければ無視をする。入ってくる情報を操作できないので、受動的なメディアである。

インターネットWebの場合、自分の好きな情報に検索エンジンを用いてアクセスできる。場合によっては、自分から情報発信できる。文章を書いたり、絵を描いたり、音楽を演奏したり。自分から情報を選別したり、提供したりするので能動的なメディアである。

以前、よく放送と通信の融合について考えていて、テレビをインターネット側に寄せる方向に行けば幸せだと思っていた。テレビへのコメント、参加型コンテンツ、物販・プロダクトリプレースメント。

しかし上手くいかない。テレビを変えるにはメーカーを動かす必要があるし、テレビ上のアプリで劇的に変化をもたらすのは困難だった。もうどうしようもないな、と。そこで逆に考えてみることにした。インターネットをテレビ側に寄せていったらどうなるのか。

正直なところ、インターネット上で好きなコンテンツを探す、という作業が面倒だった。検索キーワードを考えて入れて検索して見つからなかったら再度考えて入れて検索して見つかったら見る。だらだら身ながらでも楽しめるような仕組みができないものかな、と。

その仕組みの概念をまとめていくとテレビ的な要素＝パッシブとWebが融合したらどうだろうか、との発想に至った。

利用者が一度も操作する必要がないWeb

パッシブWebにはセンセーショナルなコンセプトが必要だった。「1秒に、1回更新、見ているだけ、楽しい」そして「利用者が一度も操作する必要がないWeb」。

人々はWebを操作することに疲れている。今こそ操作の呪縛から解き放たれよ。

キーワードは、「操作しない」「リアルタイム」だった。特にリアルタイムであることが重要であると考えた。

続く。