Category: Diary

Samsung Apps StoreとGoogleばなれ

Androidのバリューチェーンの中でSamsungがどんどんと力を付け、Googleよりも力を付けつつある点について何回かブログをしました (1, 2)。またAndroidで儲かっているのはSamsung１社という状態になっているため、他のメーカーもGoogleに頼らない、Androidに頼らないマーケティング戦略を打ち出さざるを得ない状況も生まれています(3)。

Samsung Appsのキャンペーン

どうやらこの動きは加速しているようです。

Samsungはモバイル用ゲームを作っているElectronic ArtsのChillingo部と提携し、“100% Indie”というキャンペーンを開始するそうです。

以下抜粋

“100% Indie” allows developers to tap into the phenomenal growth that Samsung is experiencing. – See more at: http://news.ea.com/press-release/mobile-and-social/chillingo-and-samsungs-100-indie-developer-program-offers-best-reven#sthash.S9vu3ir6.dpuf

Developers will receive 100% revenue from March 4, 2013 – September 3, 2013, 90% revenue share from September 4, 2013 – March 3, 2014, 80% revenue share from March 4, 2014 – March 3, 2015, and after March 4, 2015 on Samsung Apps, developers will receive 70% revenue share.

Kevin Tofel氏が解説していますが、Google PlayやAmazonのAppstoreでは開発者は売り上げの70%を手にします。しかし100% Indieのキャンペーンでは、まず最初の6ヶ月間は売り上げの100%が開発者に行きます。そして6ヶ月ごとにこの比率は10%ずつ下がり、2015年の3月からはGoogleやAmazonと同様の売り上げの70%になります。ゲームに限定されているようですが、新しいゲームに限定されているという記載はなく、既にGoogle Playなどで販売されているゲームでも大丈夫そうです。

目的は明白で、Samsung Appsの開発者向けプロモーションです。つまりGoogle PlayやAmazonのAppstoreでソフトを販売するよりも、Samsung Appsで売った方が儲かりますよと開発者に持ちかけ、開発者がSamsung Appsでの販売を選択するようにさせたいのです。

Kevin Tofel氏が指摘するように、Gartner Researchの調査結果によるとAndroidスマートフォンの実に42.5%がSamsung製です。Androidタブレットの世界でも、45%がSamsung製だとするデータもあります。つまりSamsung Appsの潜在的なリーチはGoogle Playには及ばないものの、脅威を与えるのに十分です。

Samsungが仕掛けられる展開

Samsungの戦略はわかりませんが、Androidの世界での圧倒的なシェアを活かせばいろいろなことができます。

  1. Google Playよりも安い値段でアプリを販売。これはAmazonと同じ戦略ですが、Amazonはタブレットしか販売していないので、マーケットがまだ小さいです。同じことをSamsungスマートフォンでやればGoogle Playばなれは加速します。
  2. 開発者の優遇。Google Playは売値の70%を開発者に還元しています。Samsung Appsは100% Indieキャンペーンでは期間限定で還元率を高くしていますが、同じような戦略を拡大することができます。

Samsungはスマートフォンで莫大な利益を得ており、Samsungのモバイル事業だけでもGoogleの全事業より儲かっています。またSamsungの携帯電話の売り上げはAmazon全体の売り上げをしのいでいます（Amazonは超薄利多売のため、ほとんど利益がありません）。Samsung Appsで仮に赤字になったとしても、その分スマートフォンが売れるのであれば、赤字分は容易に回収できます。

もしSamsungがSamsung Appsを積極的に展開し、開発者優遇策を通して独占的なタイトルを集め、かつ売値をGoogle Playよりも低くすれば、Google PlayもAmazon Appstoreも窮地に立たされます。GoogleもAmazonも自らのマージンを減らすことで対抗しようとするでしょうが、Samsungのような強力な赤字回収メカニズムがないので、まともに戦えません。

Googleが怖がっているのはもっともなことです。

戦略的な話をすると

より高いレベルの戦略論で言えば、

  1. GoogleもAmazonもハードおよびOSに対する戦略は同じです。つまりハードウェアおよびOSをコモディティー化し、誰でも入手できるようにします。そしてネット広告もしくはネットでのコンテンツ販売で儲けるという戦略です。
  2. しかしGoogleやAmazonの戦略とは裏腹に、ハードウェア、OS、販売チャンネル、マーケティングの力がバリューチェーンで最大の位置を占める展開となり、それに強いAppleとSamsungだけが勝っています。
  3. 一方でコンテンツ販売に関しては、AmazonにしてもGoogleにしても優位性が出せていません。物流が重要な世界と異なり、デジタルコンテンツの販売ではAmazonですら優位性がなく、参入障壁が低くなっています。むしろハードで勝っているところがデジタルコンテンツ販売でも勝つという展開になる可能性があります。
  4. なぜそうなるかというと、スマートフォンもタブレットもまだ”Good Enough”に達していないからです。Appleが新製品のiPhoneを出したり、Samsungが新しいGalaxyを出せば飛ぶように売れます。まだまだ顧客は新しくて高機能なハードを求めているのです。これが逆に「もう古いやつでいいや」となればハードがコモディティー化していきます。
  5. ハードやOSでの差別化がバリューチェーンで大きな位置を占める限り、GoogleやAmazonが優位に立つのは難しくなります。

GoogleもAmazonも戦術レベルではなく、戦略のレベルで苦戦しており、なかなか出口が見えません。大きな転換がない限り、Apple, Samsungの優位は続くと予想され、かりにHTCが復活しても2強が3強になるだけで、Googleにとってはますます頭痛の種が増えるでしょう。

Google社内でSamsungの強さを危惧している？

タブレットにおけるAndroidの追い詰められた現状という書き込みをしたばかりですが、The Wall Street Journalに“Samsung Sparks Anxiety at Google”という記事が掲載されましたので紹介します。

Google executives worry that Samsung has become so big—the South Korean company sells about 40% of the gadgets that use Google’s Android software—that it could flex its muscle to renegotiate their arrangement and eat into Google’s lucrative mobile-ad business, people familiar with the matter said.

But Mr. Rubin also said Samsung could become a threat if it gains more ground among mobile-device makers that use Android, the person said. Mr. Rubin said Google’s recent acquisition of Motorola Mobility, which makes Android-based smartphones and tablets, served as a kind of insurance policy against a manufacturer such as Samsung gaining too much power over Android, the person said.

Several people familiar with the relationship between the companies said Google fears that Samsung will demand a greater share of the online-advertising revenue that Google generates from its Web-search engine.

Samsung in the past has received more than 10% of such revenue, one of the people said. Samsung has signaled to Google that it might want more, especially as Google begins to produce more revenue from apps such as Google Maps and YouTube, another person familiar with the matter said.

Samsungが具体的にどのような要求をAndroidに押しつけてくるかはまだ見えてきていません。しかし特にGalaxy Noteシリーズではマルチウィンドウやスタイラスなどの独自機能をかなり前面に出しており、Google
が提供するAndroidだけではタブレット市場で勝つには不十分だと考えていることが強く示唆されています。

FireFox OSも予想以上にメーカーやキャリアからの協力を取り付けている印象で、思いの外にAndroidに対するメーカー、キャリアの不満があるのではないかという気もします。2013年はその姿が少しずつ見えてきそうな気配があります。

大切なことは、マーケットシェア的にはAndroidとiOSが市場を二分しているとはいえ、新規参入の余地がまだあるということです。新規参入の余地は、既存の製品に顧客がどれぐらいの不満を持っているかによって決まるのであって、マーケットシェアによるのではありません。スマートフォンの場合、キャリアは通信料の増大に不満を持っているし、ユーザは電池の持ちに大きな不満があります。両者ともに、今までよりも良いものを求めています。SamsungがGalaxy Sを売り出してスマートフォンのシェア拡大を開始したのはまだ2年ちょっと前です。まだまだいろいろなことが変化し得ます。

タブレットにおけるAndroidの追い詰められた現状

iPadが圧倒的に強いタブレット市場において、それでも徐々にAndroid陣営は勢力を伸ばしつつあります。とはいえ、状況はGoogleにとってかなりまずいように思えます。なぜならAndroidを前面に出して売れている気配が全くありません。

iOS vs. Android

という構図ではなく、

Apple vs. Amazon

もしくは

Apple vs. Samsung

という状況になっています。テクノロジーブロガーはGoogleに注目しています。しかし実際の販売状況および利用状況を見る限り、Googleは「蚊帳の外」感すら漂っています。

以下データを見ていきます。

Millennial Mediaというモバイルの広告事業を展開している会社が発表したデータをまず紹介します(Apple Insider経由)。ここで見ている数字は広告がどれぐらい多く閲覧されたかを示すもので、広告はアプリなどに埋め込まれて表示されます。

まずはスマートフォンを含むデータ。Appleが2012年にシェアを25.36%から31.20%に伸ばしている結果となっています。Samsungも同様に16.80%から22.32%に伸ばしています。

NewImage

タブレットに限ったのが以下のデータです。Androidがシェアの41%を握るまでに成長しているものの、その原動力は圧倒的にSamsungによるものであり、次いでAmazonとなっています。GoogleがブランディングしているNexus 7はAsusのシェアに含まれていますが、Androidのうちのわずか5%です。

NewImage

AmazonのKindle Fireは、OSとしてはGoogleのAndroidを使っていますが、激しくカスタマイズされていてAndroidの存在感を消しています。それどころか、メーカー保証を損なうような改造を行わない限りGoogle PlayストアなどのGoogleのサービスを利用することができなくなっています。

SamsungはAndroidをそこまで改造しておらず、普通のGoogle Playを使うことができます。しかしスマートフォンでもタブレットでも圧倒的に強いSamsungはAndroidを脅かす動きが顕著に出てきています。独自のモバイル用OS Tizenを2013年中に発表予定していることもそうですが、スタイラスによるペン入力やマルチウィンドウの独自ソフトを組み込んで、Samsungだけの機能を強化しようとしている点も見逃せません。

Nexus 7はアメリカでの発売が7月で販売期間が短いという問題がありますが、機能の割には圧倒的に安い価格で提供していて、なおかつ評論家の間では非常に好評だったにもかかわらず、Samsungの遙か後方に位置しています。販売チャンネルをしっかり管理しているSamsung、独自の強力な販売チャンネルを持っているAmazonとの差がくっきり出ているように感じます。

なお同じような結果は同業者のChitikaからも発表されています。Chitikaのデータの違いは2ヶ月ごとに更新されている点で、そのため年末商戦に強いAmazonのシェアが高くなっています。

Chitika January Tablet Graphs 1 2

推察

GoogleはAndroid OS自身からは利益を取らず、Android OSを使っている利用者からの広告収入やオンラインストアで利益を得ようとしています。そのためにはAndroidがどう使われているかをある程度コントロールする必要があります。

しかしAmazonのKindle FireユーザはAmazonのオンラインストアに囲い込まれているため、Googleのストアが入り込むことができません。Kindle FireのブラウザもAmazon製ですので、Googleがコントロールできません。

SamsungはGoogleを排除していません。しかしGoogleのタブレット戦略はNexus 7後もほぼSamsung１社に依存しています。力関係は圧倒的にSamsungに傾いています。特筆するべきは、ちゃんと粗利を稼げるAndroidタブレットはSamsungしか作れていない点です。

Androidはタブレットのシェアを伸ばしました。しかしその犠牲として、Googleは市場をコントロールする力を失いました。価格崩壊も起きていて、混沌としています。2013年がどうなるか、予測不能です。

Androidばなれ

以前にSamsungがDoCoMoとTizen搭載スマートフォンを販売するという話に関連して、Android搭載スマートフォンが売れているのはGoogleの製品開発のおかげではなく、むしろSamsungのマーケティングに起因する可能性が高いこと、そして既にSamsungの方がGoogleよりも強い立場になってきているかもしれないという話をしました。

実はHTCも同じ考え方をしているかも知れないという情報が出てきました。

これは何かというと、HTC Oneの製品発表会でAndroidのことが一切語られなかったという話です。もちろんAndroidは搭載しているのですが、Androidに言及することはマーケティング上なんの利益にもならず、むしろ害があると判断したようです。

2013年はSamsung以外のAndroidメーカーが利益を確保しようと、あの手この手を使ってくるはずです。その中でAndroidのことを敢えて語らないというやり方は他のメーカーも採用するでしょう。

低価格のタブレットは破壊的イノベーションになるか

ドコモからも9,975円のタブレットが発表されたように、相変わらず赤字でタブレットを売るのが流行っています。タブレットを赤字で売る代わりに電子書籍やビデオ、アプリなどのコンテンツで儲けを出そうというのが戦略です。問題は終着点として最終的にiPadに勝てるようになるのか、それともAppleの絶対的な立場は揺るがず、別の市場でコンテンツ消費に特化したタブレットが生き残るのかどうかです(今の電子辞書のように)。

破壊的イノベーションによってマーケットの覇者が入れ替わる仕組みはClayton Christensen氏が”Innovator’s Dilemma”で理論的に解説していて、イノベーションにおけるスタンダードな理論になってきています。こに理論に即して話しますが、この理論をどう適用するかは人によってまちまちなので、あくまでも一つの解釈ということになります。

前提は技術水準がニーズを飛び越していること

Innovator’s Dilemma が起こるには前提があるとChristensen氏は述べています。それは技術水準が進化した結果、かなりの部分の消費者のニーズを飛び越してしまっているということです。つまりもっと性能が限定的なものでも十分に顧客が満足できるという状態に達していることが必要です。

どうしてこれが必要かというと、破壊的イノベーションはまず既存の主力企業が最初は脅威を感じないことから始まるからです。主力企業が「ローエンドは他企業に任せてよい」と思うことから破壊的イノベーションは始まります。そういうローエンド市場がそもそも存在することが必要です。

iPadが発表される前にネットブックがPC市場で爆発的に売れましたが、ネットブックはローエンドPCでした。これが爆発的に売れたということはPC市場全体が顧客のニーズを飛び越していたことを強く示唆していました。CPUパワーが大幅に落ちるタブレットにPC市場が飲み込まれつつあるのは、その延長線上のことです。

AmazonのKindle FireやGoogle Nexus 7の場合は性能的にiPadを目標にしています。iPadと同等以上の性能をプロモーションしています(スペック上では確かに超える部分もあります)。そうしないと顧客は買ってくれないのです。つまりまだまだタブレット市場では顧客ニーズを飛び越す技術水準には到達していません。少なくとも先進国市場ではローエンド市場は存在しません。Kindle FireもNexus 7もローエンド製品ではなく、ハイエンド製品を赤字でもいいから安く売ろうという試みです。

ローエンド市場が存在しないということは、Appleは決してハイエンド市場に逃げないし、市場で何ら譲歩しないことを意味しています。

マーケットリーダーが対抗できないような戦略が必要

マーケットリーダーに勝つためには、マーケットリーダーが対抗できないような戦略を採用する必要があります。マーケットリーダーは力が強く資源も豊富なので、そに気になれば新規参入企業を一蹴できます。それをさせないというのが破壊的イノベーションの妙です。

マーケットリーダーが新規参入企業を許してしまう理由は利益構造だったり、要求水準が非常に高い代わりに利益も良い顧客を重視しすぎたりすることだったりします。いろいろありますが、とにかく対抗できない必然的な理由があります。

問題はAppleがGoogleやAmazonに対抗する気になれるか、そして効果的に対抗できるかです。つまり電子書籍配信やビデオ配信、音楽配信など、GoogleやAmazonが利益に源泉にしようとしているサービスをAppleも立ち上げ、そして対抗できるかです。答えは簡単。Appleはもうこれらをずっと前からやっていて、音楽配信に関しては大成功しています。Amazonは電子書籍では成功していますが、それ以外ではまだまだです。GoogleはYouTubeなどの無料サービス以外ではこれといった成功はなく、基本的にはまだお金を払ってもらうのを苦手としています。

つまりGoogleやAmazonのような戦略はAppleも十分に採れて、その気になればAppleの方がうまくできる可能性だってあります。Appleが対抗的にiTunes storeのコンテンツの価格を下げれば、GoogleもAmazonも対抗値下げを余儀無くされ、コンテンツで回収するというビジネスモデルが立ち行かなくなります。

Kindle Fireはどうなって行くのか

この日経BPの記事がすべてをまとめているような気がします。待ちわびたKindle Fire HDはちょっと残念な端末だった

  1. サイズも重さもイマイチで、開発投資が不十分。
  2. アプリはAndroidと同じものであっても再度Amazonから買わないといけない。

Kindle FireでAmazonが狙っているのはiPadの代替ではないし、Nexus 7の代替でもなさそうです。破壊的イノベーションはおろか、タブレットとして成功することすら狙っていない感じがします。でもそうなるとまだまだ値段が高すぎます。おそらくはiPadが進化する傍で、ひたすら価格を下げて行くのではないでしょうか。機能の差がどんどん広がって行っても。そうやって電子書籍やポータブルDVDプレイヤーのような製品になって行くのだろうと思います。

Google Nexus 7はどうなって行くのでしょうか

Google Nexus 7の場合は違う使命があります。Googleとしては本当はハードウェアがやりたいのではなく、自分たちが損をかぶらないとiPadにいつまで経っても追いつかないからハードを作ったという経緯があります。本当はハードはメーカーに任せるつもりだったはずです。

したがって、Google Nexus 7は性能的に優れている使命があります。そして現時点では赤字で売らないとiPadに対抗できないので、赤字をかぶり続けるはずです。Amazonの場合はタブレットの性能を犠牲にして価格を下げるという戦略が採れますがGoogleはそれができません。Nexus 7は常にiPadを目指さなければならず、ローエンドからの破壊的イノベーションは仕掛けられない使命を持っているのです。

Nexus 7のような赤字で売る製品は、Googleとしてはなるべく早くやめたいはずです。Androidタブレットを各メーカーが自力で売れるようになれば、やめようと思っているはずです。でもその芽はまだありません。ズルズルと可能な限りの最高の製品を赤字で販売し続けるのだろうと思います。

iPhone, Mac, Androidの週末・平日での使用量

StatCounterのデータを見ると、いろんなデバイスやOS、ブラウザが週末と平日とでどのように使われているかを知ることができます。

iPhoneは平日使用され、Androidは週末に使われる

スクリーンショット 2013 01 08 1 13

解釈に困るデータですが、iPhoneが平日に多く使用されるのに対して、Androidはその逆の傾向が出ています。すごくキレイな逆相関です。

対照として米国のデータも出しますが、特にそのような傾向はありません。

Us iphone android weekend vs weekday

日本とアメリカの市場の大きな違いは最大のキャリア（日本ではドコモ）がiPhoneを扱っているかいないかですが、それを考えてもますます謎が深まるばかりです。ドコモのユーザが平日よりも週末にスマートフォンを使う理由があるとも思いません。

唯一考えられるのは、会社でiPhoneを支給している会社が多いのに対して、会社でAndroidを支給しているのが明確に少ないのかも知れません。ドコモの企業ユーザはAndroidに乗り換えるよりは、現行のiModeで十分と考えているのかも知れません。

もしそうだとするならば、今後この企業ユーザがいずれドコモのAndroidを使うようになるのか、それともKDDI/SoftbankのiPhoneに乗り換えるのか、ドコモにとってはかなり重要なポイントになりそうです。

なお、日本企業が支給する携帯はまだ圧倒的に非スマートフォンであるデータが2012年の7月に発表されています。

いくつかの国でも見ましたが、日本と同じようにiPhoneとAndroidで休日・平日の使用がキレイに分かれている国はなかなかありません。Singaporeなどは多少似ています。Spainではむしろ逆の傾向が見られます。

PCのOSの休日・平日の違い

同じような解析をPCのOSで行ったのが以下のグラフ。まずは日本のデータ。

PC OS weekday vs weekend 4

Windowsの中でもWin7とVistaは週末に使われる傾向にあり、Win XPが平日に使われる傾向があります。日本の企業は未だにWin XPを多く使っているようです。Macは平日に使われることが多く、職場での利用がメインのようです（個人的にはこの結果は意外でした）。日本のiOS (iPad)の利用はまだ少ないようですが、特に平日と休日の差は見られませんでした。

次に米国のデータ。

US desktop OS weekend vs weekday 2

米国では職場でもWin7が浸透してきているようで、平日と休日の差が無くなっています。Win XPを使っているのは主に職場のようです。Vistaは休日に良く使われています。Macは日本と違い休日と平日の差が無く、米国の方が家庭にも浸透しているようです。さらにiOS (iPad)は週末に使用が多くなるようです。

オフライン（ローカル）で使えるWebサイトって何を指すのか？

HTML5にはアプリケーションキャッシュやストレージなど、オフラインアプリケーションを実現するための機能が用意されていますが、そもそもオフラインアプリケーションって何なんだろうって考えてみたいと思います。なぜかというと、オフラインアプリケーションと一言で言っても、どこまで「オフライン」である必要があるのかに差があるからです。

まずWebサイトを分類したいと思います。

  1. 閲覧をメインとしたサイト： WikipediaやAsahi.comなどの新聞サイトがこれに該当します。
  2. 個人用にカスタマイズしたコンテンツをメインにしたサイト： Facebook, Twitter, LinkedInなどがこれに該当します。
  3. データ入力や加工をメインにしたサイト： GmailやGoogle Docsがこれに相当します。

以下、それぞれについて考えていきます。

閲覧をメインにしたサイト

1の閲覧をメインにしたサイトについてはオフラインへのアプローチは２通り考えられます。一つはサーバから帰ってくるHTMLをそのままキャッシュすることです。もう一つはAPIでデータをJSONなどの形式でダウンロードし、これをキャッシュすることです。そして画面に表示するときはJSONデータからDOMを作ります。

どっちを選択するかに関わらず、このようなサイトに共通しているのは、ブラウザ側ではModelを持つ必要が無いということです。保存する内容はページの内容だけですので、ModelはせいぜいPage一つです。わざわざクライアントサイドのMVCフレームワークを用意する必要がありません。

このようなサイトで一番大きな問題はデータ量ではないでしょうか。Wikipediaであればすべてをローカルに保存するわけにはいかず、一部だけをダウンロードすることになります。それでも数千ページを保存すれば相当な容量になります。このデータを効率的にサーバから出力し、ブラウザ側で処理し、ローカルに保存していくかは簡単ではありません。

個人用にカスタマイズしたコンテンツをメインにしたサイト

実際問題、こういうサイトではオフラインの閲覧はほとんど実現できていません。例えばHTML5をやめてnative Appを開発していくということで話題になったFacebookのiPhone用アプリですが、オフラインで見られるのは以前に閲覧した内容のキャッシュです。先読みしてローカルにページを保存することはしません。したがってオフラインでやれるのは見直しだけです。

Twitter, LinkedInのiPhone用Nativeアプリも同じです。

ただ「いいね！」などはオフラインでも押すことができて、オンラインになるとその変更がサーバに送られることを期待しましたが、テストしてみたところ反映されていませんでした。

もともとこのようなソーシャルネットワークアプリはタイムラインを中心としたUIなので、タイムラインさえキャッシュすればほとんど用が足りると発想をしているのだと思われます。いずれにしてもオフラインではたいして使えないのが現状です。

このようなサイトを実現する方法は「閲覧をメインにしたサイト」とよく似ています。サーバから帰ってきた内容をキャッシュすれば良いのです。ただし内容が変更されることが頻繁にあるので、ネットワーク接続があれば積極的にデータを更新することになります。

データ入力や加工をメインにしたサイト

GmailやGoogle DocsはもともとデスクトップのemailクライアントやMS Officeをウェブ用に作り替えた製品であり、完全にオフラインで動作するようにGoogleがかなり開発をしてきた製品です。

これらの特徴は、様々に加工した後に作られるドキュメントが非常に独立していることです。デスクトップのアプリであればドキュメントはファイルシステム上のファイルであり、属性としてはタイムスタンプやフォルダー名、ファイル名、そして権限ぐらいです。Facebookの書き込み、コメント、いいねと違い、複雑なリレーションがありません。

このようなWebサイトはデータを加工するのには複雑なJavascriptを使う必要がありますが、一方でサーバとやりとりするデータはかなり境界がはっきりしていて単純です。この際に便利なのがクライアントサイドのJavascript MVCフレームワークです。ブラウザの中で複雑な処理が行われデータが加工されていきます。上述の「閲覧をメインにしたサイト」「個人用にカスタマイズしたコンテンツをメインにしたサイト」と異なり、ブラウザはデータに対して受け身ではなく、積極的にデータを作り、改変します。ブラウザ内での処理が複雑になりますので、MVCフレームワークの必要が出てきます。

このように、どのようなWebサイトでオフライン閲覧を実現しようとしているかによって、どこまでやるべきか、どこまでやれるかがかなり分かれます。

さて私が考えているのはソーシャル機能を持ったオンライン抄録集ですので、1, 2の機能を併せ持ったものになります。それを実現するために何が必要かを考えていきます。

ソーシャル機能を持ったオンライン抄録集ではブラウザ側のMVCは必要ない

オンライン抄録集は根本的には「閲覧をメインにしたサイト」ですので、各ページのデータをローカルに保管すれば十分です。ソーシャル機能については「個人用にカスタマイズしたコンテンツをメインにしたサイト」と同じように考えますので、普通に考えればオフラインでソーシャル機能を提供する必要はありません。したがってサーバのレスポンスをキャッシュするアプローチで十分です。

もし一歩先を行って、「いいね！」などをオフラインでも可能にしようと思うと、ブラウザの中にModelを作っていく必要が出てきます。しかしModelの数は少なくて済むと思われますので、全面的にクライアントサイドMVCを導入するのは無駄だと考えられます。

残念ながら適当なフレームワークがない

残念ながらこういう目的のJavaScriptフレームワークは存在しないのが現状です。Sencha Touchはローカルにデータを保存することができますが、完全なクライアントサイドMVCフレームワークなので今回の目的に合いません。

jQuery Mobile, jqMobiなどはサーバ側にHTMLの生成を任せているフレームワークで、クライアントサイドにModelを持つ必要の無いものです。しかし主眼はNativeアプリと似たようなUIをブラウザ内で実現することであり、ページをローカルにキャッシュする機能はありません。

オフラインでも使えるwebサイトを作るために

現在取りかかっているプロジェクトと関連しますので、ローカル（オフライン）でも使えるWebサイトを作るためのポイントをまとめてみました。

データをため込むにはHTML5のアプリケーションキャッシュとストレージを使う

ローカルで使えるWebサイトを作るには、データをローカルに保管することが必須です。HTML5では保管方法がいくつか用意されていて、大別するとアプリケーションキャッシュとストレージになります。

静的なファイルはアプリケーションキャッシュで

完全にローカルで使えるWebサイトを作るためには、HTML5のアプリケーションキャッシュを使う必要があります。最初に問い合わせるURLはこのアプリケーションキャッシュに入れます。これをやらないと、URLを入力した時点でブラウザはサーバに問い合わせをし、ネットワークが繋がらなければエラーになります。

アプリケーションキャッシュは便利ですが、例えば1ページでも更新されるとキャッシュ全体をクリアしなければならないなど、頻繁に更新される内容には不向きです。あくまでも静的なファイルに使用します。

ただし、Webサイトのトップページはしばしば動的なページです。更新情報やお知らせなどを掲載することが一般的です。そうなると最初に問い合わせるURLは静的ではなくなります。

この問題を解決するためには、最初に問い合わせるURLではウェブページのフレームワークだけを返し、更新情報などはストレージから読み込むんで、Javascriptで埋め込むことになります。

HTML5 History APIは使わない

Javascriptを使ってページ内容を更新する場合、backボタンやブックマークを正常に動作させるためにURLを書き換える必要があります。その方法はURLのハッシュフラグメントを書き換える方法と、HTML5のHistory API (pushStateなど)を使う方法があります。

pushStateを使うとハッシュフラグメントではなく、URLの本体を変更します。この方が従来のWebと親和性が高いという理由などから、現在ではHistory APIを使った方法が推奨されています。

しかしこれはローカルWebアプリには使えません。最大の理由はアプリケーションキャッシュがうまく使えないからです。

例えばhttp://my_server.com/をアプリケーションキャッシュに保管しいても、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2というURLにアクセスしようとするとアプリケーションキャッシュのページは使われません。通常通り、http://my_server.com/path_to_page_1, http://my_server.com/path_to_page_2をサーバに要求します。

それに対してhttp://my_server.com/#!path_to_page_1, http://my_server.com/#!path_to_page_2のようなURLになっていれば、まず最初にアプリケーションキャッシュのhttp://my_server.com/が呼び出されます。そのあとpath_to_page_1やpath_to_page_2のコンテンツはストレージから読み込むか、あるいはAJAXでサーバに問い合わせることができます。

その他、Androida 4.0のデフォルトブラウザがHistory APIをしっかりサポートしていないという問題もあります。

ストレージの選択

ストレージはいくつもAPIが用意されていますが、ブラウザのサポートを考慮すると実際に使えるものは限られています。

一番広くサポートされているのはwebStorageです。これは非常に単純なkey/value型のストレージです。IE8でさえサポートされています。しかしwebStorageの大きな問題は容量の少なさです。Safariだと5Mbyteが上限です。これでは日本分子生物学会の抄録などは収まりません。経験的に数百演題の学会であればwebStorageでも十分ですが、1000を超えたらwebStorageでは不十分です。

次にサポートされているのはWeb SQL Databaseです。50M byte以上のデータをため込むこともできます。またSQLでクエリが書けるので、いろいろな使い方ができます。ただしWeb SQLは今後は規格を更新しないことが決まっています。Web SQLの大きなポイントは、FirefoxやIEなどのデスクトップ用ブラウザではサポートされていないものの、スマートフォンのブラウザで広くサポートされている点です。

最も期待されるのはWeb SQLに変わるIndexed DBですが、こっちはまだサポートするブラウザが少なく、特にスマートフォン用ブラウザではサポートされていません。

上記を考えると、ストレージとしては第1にWeb SQL Databaseを優先させ、サポートしたいブラウザや保管したいデータ量を考慮してIndexedDBもしくはwebStorageをサポートするのが妥当な選択だと言えます。

まとめ

完全にローカルなWebサイトを作るために必要なコンポーネント、どのHTML5テクノロジーを使うかの話をしました。特に重要なのは、一般的に推奨されている History APIは使えないということだと思います。

もちろんコンポーネントを選定しただけではまだまだ話は始まったばかりです。解決しなければならない問題はたくさんあります。これについてはこれから少しずつ紹介していきます。

解決しなければならない問題のリスト

  1. ハッシュフラグメントのフォーマット
  2. out-of-dateになったページをどうやって更新するか
  3. データの同期をどうやって行うか

statCounterの統計 201301

statCounterという、ウェブ使用統計が簡単にわかるサイトがあります。この統計をちょっと見てきます。

米国PC用ブラウザ（含むタブレット）の統計

StatCounter US browser 2013 01 06 17 24

  1. クリスマスになるとIEの使用率が減ってChromeの使用率が上がります。
  2. それに対してFirefoxの使用率は目立った変化はありません。
  3. iPadの使用率はクリスマスで大幅に上昇。1月になっても継続しています。
  4. Androidの使用率は大幅に上昇。しかしベースが非常に低い。

米国モバイル用ブラウザ（スマートフォンやフィーチャーフォン）の統計

StatCounter mobile browser 20130106

  1. 米国ではAndroidが2012年を通して使用率が減少する傾向。対してiPhoneの使用率が上昇する傾向。
  2. 2012年のクリスマス期はその傾向が特に強く出ました。