デジタルメディアは「計測できる」からこそ価値がある！

　今回は、コムスコア日本代表の前川洋輔氏にインタビューをさせてもらいました。

　コムスコアは、ニールセンなどと並ぶ米国のデータ調査会社です。私自身でいうと、2007年に、米国のGlamメディアの調査をしているときに、彼らがコムスコアのデータを利用して広告効果のレポートを出していることから、気になっていた会社です。


その前川洋輔さんは、こういいます。

「デジタルメディアは、計測できるから価値があるんです」

「マルチデバイス、マルチスクリーンの時代では、OneWeb＝１つのURLの発想で考えていかないと、その計測できるバリューにひずみができてしまうんです」

　みなさんは、この意味がわかりますか？ちょっと背景を説明すると、スマートフォンサイト対応には、いくつかの方法があるのですが、多くのソリューションが分離された別々のモバイルサイトを作ってしまう傾向があります。
　日本でも6割とされる「スクラッチ」でのサイト構築もそうで、URLはPCと異なってしまいます。また最適化コンバートを行うプロキシーソリューションでも同様で、ドメインに前に、ｍドットがついてしまいます。これらはOneWeb＝１つのURLではありません。

スクラッチで構築した場合：PC www.yourdomain.co.jp/　　　　　スマホ　　www.yourdomain.co.jp/sp/

プロキシーソリューションの場合：PC www.yourdomain.co.jp/　　　　　スマホ　　m.yourdomain.co.jp/

※スクラッチは個別でスマホサイトを構築するやり方。プロキシーソリューションは、プロキシーサーバーを使って、キャシュされた別のサイトをリダイレクションによって読みにいくやり方で、フューチャーフォンの時代から利用されていた方法です。


このURLの問題が何を表しているかがポイントです。
非OneWeb、つまりURLが別々になったときの問題としては、大きく下記の３つがでてきます。

1. SEO効果をだめにする。リスティング効果が半減
2. ソーシャル効果がダメになる。拡散、集客
3. マーケティング集計　ログ解析がダメになる。

１）２）も結構大きな問題だったのです。カンタンにいえば、領域が別になるわけです。Googleのクローラーは1つではなく、複数それぞれのサイトを走る必要があります。無理矢理サーバーサイドでURLを調整する方法もありますが、この方法でもサーバー内部でリダイレクションをかけているので、クローラーは１つではありません。

３）のアクセス解析の問題はどうでしょうか？　解析のテクニックでなんとか調整するという方法があるとは聞いていましたが、結構調整が大変、人為的なミスがおこりやすい、でてきたログが判読しがたい状態になるなどの面倒さがあります。つまり計測しにくいという問題がでてきます。


つまり、マルチスクリーン時代はOneWEBであることが必要です。Googleもそうだし、コムスコアでもデジタル分析の上で、推奨しています。

計測できない、または計測しにくいWebページであることは、WEBマーケティングの本来の役割を果たしていないともいえるのです。

「タブレットサイトへの対応を含めても、WebはOneWebでなければならない。
このコラムのタイトル「OneWebワールド」の価値を、改めて認識したインタビューとなりました。ありがとうございます。

エンジニアから見た、Mobifyの優れたポテンシャルと今後の発展性について

Inside Mobify

エンジニアから見た、Mobifyの優れたポテンシャルと今後の発展性について
　　　　　　　 ～技術アドバイザー・黒田正信氏に聞く

　今回は、サーバー系エンジニアである黒田正信氏に、Mobifyがもたらす技術のすばらしさについて語ってもらいました。
 というのも、見過ごしていた技術のポイントを黒田氏が、自らの饒舌に語りはじめたからです。彼のコーフンぶり、CEOイゴールとの熱い会話、エンジニア同士のやりとりの中で、Mobifyの真のポテンシャルが分かり始めたからです。

　今回のインタビューは、エンジニア黒田氏にとってのMobifyの技術的な感動を再度、ここで収録してみました。

プロキシー・ソリューションでは、まったく興味がなかった。

　最初、Mobifyを知ったときには、従来からあるプロキシー・ソリューションだと思っていました。プロキシー・ソリューションは、サーバー側でコンテンツをスクレイプしてキャシュして配信するという当たり前のやり方です。

　ところが、新しいMobifyクラウドは、クライアントサイドのデバイス本体にいろんなことさせるソリューションでした。
　つまり「スマホ本体の中で最適化を行う状態を作る」という。こんなやり方は、今までは考えられなかった。少し前のデバイスならばパワー不足で実現が難しかったやり方だったんです。
　これは画期的なことだと思います。



デバイスの本体で最適化というアイデアはすばらしい

　ボクが古いのか、Mobifyチームの彼らが天才なのか、アイデアそのものとしてもデバイス本体でも表示の最適化を行うという常識を変えたところが凄いと思いますよ。

　逆に、従来のプロキシーソリューションでは、まったく予想の範囲内だし、ガラケーの時代からあったやり方なんです。プロキシーソリューションだと、結構サーバーに負荷がかかります。しかし、Mobifyクラウドの解決方法は、逆にサーバー側に負荷がかからない仕組みなっています。これもエンジニアからみたら画期的ですね。つまり技術的にコストを下げていくことにつながる技といえるからです。


Mobify.jsの優れた素質と今後の活用法

　Mobify.jsは、Javascriptの新しい使い方を追求しています。デバイス側で非同期通信を行わせているわけですが、サーバーとの通信負荷を減らすことにもつながっています。
　
　Javascriptは、ここ数年でいろんな活用が萌芽した新しい技術であり、こうしたアイデア事態がコーフンしますね。
　またMobify.jsは、Googleの開発したNode.jsをベースにしていることも安心感を生みます。なにしろGoogle自体が、Javascriptをこれでもかと、徹底的に駆使してきたサービスをたくさん生み出していますからね。
　このMobify.jsは、CTOのジョン・ボクサールが開発しています。彼らが自分たちのMobify.jsをGoogleのラリーページに見せたそうですが、ラリー・ページ自身が「こういう使い方っていいね！」といってくれたようです。


オープンソースになったMobify.js

　Mobify.jsは、2012年の6月に、オープンソースとなりました。オープンソースを不安視する声もありますが、逆にその利点はいろいろあります。
　まず、多くの人の目に止まるようになることで、あらゆる問題点が浮き彫りになります。そのためバグ対応のスピードが加速化します。また解決方法が見つからなければ、「自ら開発してやろう」という人もでてきたりします。逆にいうと、クローズで開発しようとすると、社内リソースがいくらあっても足りないような作業を、フリーミアムで行える環境ともいえるのです。
　いまでオープンソースであることのほうが、たくさんの人が見て、開発やバグ問題を解消するという安心感や信頼感を生んでいます。こうした面でいうと、オープンソースであるということは、サービス面の改善でもリードしているといえます。



OneWeb＝同一URLを行うというのは、絶対必要だ。

　同一URLというのは、理屈でいえばURLがそろっていたほうがいいわけです。OneWebであらゆるデバイスを対応させるという。つまりなんだかんだと言って、URLが分かれていていいことなどありません。スクラッチの開発会社は理屈を加えるかもしれませんが、SEO対策、ソーシャル対策、マーケティング活用、分析の面で必要条件といえるでしょう。
　とくに、最近はFacebookやpinterestなどのソーシャルメディアによって、確実に売上げが上がるということが証明されてきています。これが別URLやサブドメインだと問題が起こるわけです。スマホでみたものがPCでみるとか、PCのサイトをスマホで見ることになるとか、不都合がたくさん生じてきてしまうわけです。しかし、この点も他のOneWebソリューションは、デザインをなくす方向で対応していますが、Mobifyの場合デザインをスポイルしない開発が可能な点もいいですね。



モバイルCDNのスピードを手軽に利用できる

　Mobifyはその変換方法やロジックに注目されていますが、モバイルCDNの存在も忘れてはいけません。
　Mobifyでは、EdgeCast(エッジキャスト)というCDNを利用していますが。これがとにかく速い。計測してみると、CDNを利用していない場合のWebサイトサーバー本体よりも、Mobifyほうの応答速度ははるかに上回っているのです。
　
　つまり、PCサイトよりもレスポンスが速いわけです。モビファイサービスの場合、こうしたCDNの費用が月額利用料に含まれるわけですから、どう考えてもオトクでしょう。
　単体でCDNを利用しようとすれば、設定も大変だしコストもかかることになってしまいます。パッケージとしてインクルードされていることは大きいと思いますよ。


スクラッチ工法やCMSで対応することはどうなんだろう？

　スクラッチで開発したり、サーバーサイドのテンプレートで対応することって、まだまだ一般的ですよね。ただ、こうしたやり方でやり続ける限りいろんな不具合ができてしまいます。まずスクラッチだと作業が別途別にかかり続ける。これはあり得ないわけです。コストが無尽蔵に増えることは企業としてだめですから。またサーバーサイドのテンプレートでいえば、設定を細かくすることはできてもキリが無いわけです。
　
　それにOSや新機種のバージョンアップのたびに右往左往する可能性がでてきます。それもサーバー単位で細かく修正するというような。１つや２つならまだいいですが、複数単位やぺージが増えると大変です。これがMobifyの場合、システム上で調整が効きます。この点も大きいでしょうね。　


セキュアまで標準で対応している。

　Mobifyのクラウドは、セキュア対応が標準で対応しています。というか、PCサイトのセキュア対応に準じます。多くのプロキシーソリューションが、SSLサーバーを介してセキュア対応をしているわけですが、プロキシー自体がセキュアに向いていないリスクを抱えています。
　その点Mobifyは通信そのものをPCとスマホを直結したカタチで、画像関係だけをセキュアに関係なくコントロールしています。つまりデータ漏洩が発生しない。ほかの方法ならばいろいろ設定が必要な場合が多い。それがないだけでもすばらしいですね。そもそも2年前にPCDに問題からプロキシーソリューションに限界を感じたことから生み出されたクラウドと聞きます。この点にも注目ですね。

黒田正信氏　第四企画代表　サーバー系エンジニア

制作側は、スクラッチでのモバイルサイト構築に「罪の意識」を持つという。

スクラッチでのモバイルサイト構築に「罪の意識」を持つ？


あのですね。スマートフォンサイトをスクラッチで作っていると、
やっぱり「罪の意識」を感じてしまうですよ。
あるWeb製作会社の友人ですが、突然彼は、私にそう告白してきた。

　　　「！　」　　................................　　　どうして？

 それは、やっぱりムダじゃないですか？　PCサイトがあるに、まったく別のサイトに同じものを載せるという行為そのものことですよ。

スクラッチでモバイルサイト作るということは？

現在、スマートフォンサイトを作る上で主流となっているのが、このスクラッチ（マニュアル構築）で、専用のモバイルサイトを作る方法である。つまり、PCのコンテンツがあるのに、同じコンテンツを複製するような作り方をしたり、または、モバイル専用の別のサイトを作るというやり方だ。（北米ではセパレートサイトという言い方をするようですが。）

　この方法だと、コストもかかるし、更新作業も面倒だし、チェック作業や時間そのものに結構タフさを要する。なにしろ、ページが置かれている領域そのものがことなるため、
１．SEO対策は再度直す必要があるし、２．Facebookなどのソーシャル共有などで、正しい表示が難しくなります。この問題はもっと奥の深い問題があるのですが、スクラッチ構築の表面的な作業問題だけでも悩みや尽きません。

「ダメダメダメの連続なんですが、 商売と考えると手っ取り早し、しっかり製作費をもらえるからなんだかんだで、結局、スクラッチで作ってしまうんですが、やっぱり心の奥で「罪悪感」を感じてしまうんです」

　彼は、古くからの友人だが、実直な男で曲がったことが嫌い。非常に真摯な人間だから、なおさら彼の言葉が気になる。

「それにですよ。iPhone5とか、iOSとか新製品がでたり、OSが切り替わってしまうと、
以前のブラウザの問題と同じように、表示崩れがおこったりするんですが、それがスクラッチでやると、細かい微調整をそれぞれに応じて個別やらなければならないんですよ」

　実は、こうして発生してしまう不具合に対して、その対応費をいただく。これが、スクラッチを行う製作会社の稼ぎの部分となっているようだ。そしてそこにいる自分のやり方に許せないというのだ。つまり「確信犯」という罪の意識である。

 わかっていながら、古い手法で対応する

　なるほど。制作とは、不条理を抱えながら稼ぐ世界もあるという。この現状を広告主（クライアント側）もある程度、わかっている部分もあり、そうしないと
製作会社もうまみがないだろうからと、いまは、目をつぶっているような節もある。

ある大手の広告代理店の製作部門の担当者は、我々のコンバートサービスをみて、非常に興味を示してもらったものの、次のような質問がでた？

「それでどうやって儲ければいいのでしょうか？」

また別の大手SIベンダーの担当者は「コンバートサービスもいいのですが、5000万円のCMSを納品したほうが利益が大きいですよね」とも答えてくれた。

  この世には、もっといいやり方や手法があるのに、それを見ないで（見ようとしないで）、古いやり方で押し通そうとする世界がまだまだ存在するようだ。
公共事業の道路工事が何度も掘り返し、埋めているやり方に非難がでたこともあったが、ちょっと近いだろうか。

ともかく、我々は業界の異端児だから、正義を信じよう。もっとより効率的にする、コストを下げる、スピードをあげる。そして最良の結果が得られるように、サービスを提供して行こう。

【ウラジオストク対談】 マルチデバイス対応には、OneWebとアダプティブで対応していく！

はじめに。
ここ極東の果てのウラジオストクで、私とMobifyのイゴール・ファレッツキー社長と一緒に、連日のように、新しいモバイルサイトの対策について話し合っています。

というのは、従来の「最適表示」という問題に大きな変化が起こっているからです。もはやスマートフォンサイト対策だけでは、不十分であり、7インチを含めたタブレット対策という問題が目前にせまっているからです。ネクサス７に始まり、iPad Mini, Kindle Fire,さらにサムソンの新機種など、さまざまなサイズのタブレットが登場してきています。

サーバーサイドテンプレート調整の問題は、コストと、小回りが効かせにくい調整作業

占部雅一（以下 マサ）：
　マルチデバイス対応なんだけど、結局、我々が取り組もうとしているOne Web以外の方法で、ほかにいい解決策があるのだろうか？　CMSのサーバーサイドでのテンプレート調整では同等の対策をすることもできるが、この方法についてはどう思う？


イゴール・ファレッスキー（以下、イゴール）：
　CMS＋サーバーサイドテンプレート調整のコントロールをやれば、インフラのコストも含めて3倍～5倍のコストがかかってきてしまう。それはクライアントにとってたまったものではない。我々は、オープンソース化したMobify.jsを使い、かつ我々が用意したクラウド・サービスを使う。そのほうが、コスト的にはるかに安上がりになるのは間違いない。モバイルCDNなどを個別で用意したら、いったいどれほどのコストになるかを試算してみるといい。

マサ：結局、OneWebにするにしても、サーバーサイドのテンプレート調整では、結構手間になるようだし、いまはタブレット対応は、まったく考えられていないようだね。

イゴール：　タブレット対応は、サーバーサイドのテンプレート調整でやる限り、コストがかかり過ぎる。またテンプレート調整では小回りはきかない。なのに内部のエンジニアは、トータルでコントロールしたいから、どうしてもこの方法に目がいくようだ。

レスポンシブウェブデザインは理想的だがコストに加え、エラーが発生しやすい

マサ：　では、レスポンシブウェブデザインという方法はどうだろうか？OneWebを実現する上では、すでに古典的な手法で、もう何年も研究がされている。しかし、これらの「トラディショナルなレスポンシブウェブデザイン※注１」では、本当の意味での解決策にはつながらないのではないか？

イゴール；　そのとおり。コストが合わない。

マサ：　つまり、手間がかかりすぎる。構築の時間、コスト、メンテナンス、更新性など、どれもやっかいだよね。レスポンシブウエブに取り組むチャレンジャーのデザイナーでさえ、半分は諦めている感じがする。なのにムーブメントだけは熱い。クライアント側に対しても、トライアル後には「こんなに大変ならやめたほうがいい」という声も聞く。


イゴール：アメリカにもレスポンシブウェブデザインに対しては、熱烈なフリークがいる。彼らの取り組みといえば、CSSの芸術的なアプローチを追求し、そのジーニアス（天才的）な手法にこそ未来を見ようとしているうようだ。

しかし、我々自身がスターバックスやideeli（アイデリー）で取り組んだように、Adaptive（アダプティブ）ウェブという手法を提案している。

これは、PCサイトはそのままに、モバイル側だけでレスポンシブウェブデザインの対応を図るというコンセプトだ。

マサ：　レスポンシブ・デザインの最大のネガは、リニューアルをしないといけないという点につきる。ここが大きなハードルです。また構築コストも約２～3倍かかってしまう。100万円でできるサイトに、だれが300万円もの大金を支払うだろうか。


イゴール：しかし、北米ではEコマースを中心にレスポンシブウェブデザインが主流になるとも言われている。Googleがこの方法を推奨しているからであり、SEO対策、ソーシャルシェアやアクセス解析の点でも問題がないからだ。また、実際にクローラーがひとつで済むというもの大きな点だ

「アダプティブ」とは、レスポンシブ・デザイン＋Mobify　というハイブリッドの対応策

マサ：　実際のところ、「アダプティブ」こそが最良策だろう。レスポンシブ・デザイン＋Mobifyを組み合わせたハイブリッドな手法が、実はもっとも現実的だとおもう。それは先のリニューアルが不要なため、それに早く対応できることだ。
しかし、それなのに日本では、ハイブリッド策は、邪道と思われている節もあって、ピュアな開発者たちは、関心を寄せてくれない。

イゴール：アメリカでもそう。インハウスの技術者たちは、すべて自分たちでの解決を求める傾向があるんだ。スクラッチしかり、レスポンシブウェブデザインしかりだ。しかし、こうした方法でやればやるほど、構築コストとメンテナンスコストは跳ね上がってしまう。それは結果的に、クライアントに大きな負荷をかけるはずだ。

マサ：では、いま我々が取り組んでいる解決策、アダプティブウェブしかないんじゃないだろうか？つまり「Mobify.jsとクラウド」を使うことで、本当の意味の解決策はなるという。　イゴール、ほかの方法は、まだあるんだろうか？


イゴール：ないと思う。おまけにFacebookの急進がOne Webでなければならないことを押し上げている。口コミにしろ、モバイルコマースのコンバージョンがそれを証明しているしね。

マサ：　とすると、僕らのPRが足らないということじゃないかな。でも、こうした結論にたどりつくまで結構時間がかかってしまった。なにしろ、どれも手探りだからね。

イゴール：　これからは、アダプティブがいいでしょ。





マサ：　そうだね。PCサイトはそのままにして、モバイルサイトのみをレスポンシブウェブデザインで対応させる。しかもスマホだけでなく、タブレットもやってしまう。

PCサイトの全面リニューアルは大変だから、そのままにしておく。過度的な解決策かもしれないが、ここ2年くらいは現状サイトが残るだろうから、企業サイトがモバイルファースト化するまでの執行ゆうｙと思う。


イゴール：ともかく、ここロシアでもユーザー率は２５％と、日本と同様だけど、街中には日本以上にWifiが多いね。日本は街中のインフラが少なすぎると感じたよ。どこにもアンテナが立たないのが問題だ。　北米のユーザー率は、来年には６０％を越えるだろう。まもなくタブレット市場が活性化するとおもっているんだ。

マサ：、もっとOneWebを理解してもらうように、がんばりましょう。



※注１　トラディショナル・レスポンシブデザイン　→　CSSの技術を駆使して構築するオーソドックスな構築方法。反対に、レスポンシブ・デザインにMobifyのクラウド技術を加えて対応する方法を「アダプティブ」と呼んでいます。この方法だと、PCサイトはそのままに、モバイル側を対応することができるため、大がかりなリニューアルをする必要がありません。

※注２　One　Web　（ワン・ウェッブ）　→　PCサイトやスマートフォンサイト、そしてタブレットサイトをひとつのページ、すなわちOneWebの絶対パスのページで対応する方法。この方法だとあえて、複数のページを作成する必要がなく、集客や拡散の上でも大きなメリットがある。とくにFacebookが伸張している時代において、口コミによるリコメンドの存在は大きく、モバイルEコマースにおいては欠かせない条件と言われている。また同様にSEO効果にも都合がよく、、マーケティング分析の上でも無理のない仕組み。これらは、スクラッチやプロキシータイプのソリューションでは解決しにくい課題となっている。


2012年11月6日　（ウラジオストックでのモバイルサミットにて）

【北米モバイル通信】iPad Mini 向けWeb デザイン対策の５つのポイントとは？

iPad Mini 向けのWeb デザイン対策の５つのポイントとは？

これは、iPad　Mini対応のWebサイト製作のためのヒントです。ほとんどの人が意識してこなかった最適化対策です。キンドルではどうする？ネクサス７ではどうする？　日本では、スマホ対策が急務ですが、これだけでは終わらないのです。7インチタブレット対策をどうするのかが、今後の重要な課題および研究ポイントになってきます。

1.      タブレットで見るPCウェブは時代遅れ

iPad Miniへの対応が注目されています。現在のサイトが、スマートフォンフォンサイトならば、拡大し、PCサイトなら縮小して対応することはできます。どちらを選ぶとなると、モバイルサイトを拡大する方が最適化の出発点としては無理がありません。

しかし、これも一時しのぎです。世界はすでにマルチスクリーンの時代です。Googleの発表では、「９０％の人はスマートフォン、PC、タブレット、テレビと、それぞれのデバイスを使いわけている。」と言います。

ウェブサイトをさまざまな人々に見てもらいたいと考えるなら、すべてのデバイスに適応させる必要が迫られているのです。

2. タブレットデザインのガイドライン

では、 iPad Miniのような小型タブレットのためには、どうデザインしたらよいのでしょうか？下記は、タブレットデバイスのためのガイドラインです。

iPad Miniは、7.8インチの新しい画面サイズです。まず、1024 x 768 ピクセルサイズの画面 (iPad 1や 2 と同じ) であることを確認し、デザインを開始します。

• 大きなテキスト-読みやすさのために、14 ピクセルにフォントサイズを大きく。
• パッドするために-PCより幅や高さを増やし、リンクのタッチ精度をあげます。

特にこれは、フォームやカレンダー 、ドロップダウンメニューに意識しましょう。

• マウス動作　-可能な限り、マウスによる動きを削除します。
• コンテンツ-タブレット画面サイズの600 x 1000 （ピクセル）の、　固定でのページ幅の修正ではなく、全範囲をカバーするように柔軟な設計を検討します。
• フラッシュの削除– iPad やタブレットでは、フラッシュを削除する必要があります。
• ポジショニング-［positon:fixed］の設定はコンテンツのロードを遅くするので、外してください。

大事なことは、これらのガイドラインとともに、実際にユーザーとしっかり話をして分析をしましょう。最近の事例では、タブレット対応でテキストサイズを変更したことで、ユーザーは老眼鏡の必要がなくなり、コンバージョン率向上にもつながったケースもありました。

3.   サプライズ！： ユーザーは常に変化しています。

iPad Miniの画面比率は、1 億台以上販売されてたiPad と同じ4：3 ですが、まったく別物です。iPad MiniはiPhone と iPadの中間に位置します。7 インチ デバイスは、iPad より携帯しやすく、iPhone や iPod Touchよりもパーソナルなデバイスになりうると予想します。

大きさの違いは、iPad Miniの特質を意味するのかもしれません。iPad Miniは、ハンドバッグ、ラップトップ バッグ、財布やキャリー ケースに簡単に収まり、通勤や旅行に手軽に持ち運べます。ユーザーは 電子書籍、映画およびビデオ、ゲームやそのほかのエンターテイメント、FacebookやTwitterのようなソーシャルメディア やショッピングや商品検索など多岐の用途に使うことでしょう。

もちろん、彼らの行動を詳しく研究する必要があります。そのために、モバイルフォン利用の3 つの基本を再確認しましょう：

• 繰り返し：ユーザーは株価、スポーツのスコア、オークション出品などの定期的なリアルタイムの情報を求めて接続します。
• 退屈な時：ユーザーは時間つぶしや気晴らしを求めてFacebookやTwitter、またはメールやその他のエンターテイメントを利用します。
• 緊急な時：ユーザーは緊急時に、検索エンジンやニュースでどこで何が起きているかの情報を求めます。

4.   パフォーマンス: オプションにあらず！

iPad MiniはWifiiと３G回線、LTEなどに接続しますが、性能はデスクトップ ＰＣよりもスマート フォンに近いのです。開発においては、コンテンツ配信やコンテンツ運用で、パフォーマンスの制約に注意をする必要があります。ここでは、いくつかのケースを紹介します。

• HTTP 要求の削減。タブレットはノートパソコンに近い画面領域がありますが、その処理能力はモバイルに近いのです。「Facebook Connect と Google +1」 のような要素を削除すればパフォーマンスがよくなります。
• 画像の最適化。 iPad Miniは非常に美しい高解像度表示を誇ります。デバイスへのイメージ最大化や縮小化にも配慮されています。しかし、注意が必要です。余計なデザイン化は、ユーザーエクスピアリアンスを損ないます。
• スクリプトとスタイルの管理。JavascriptやCSSは、ページ内に書かれているものはすべて読み込まれます。不要なスクリプトはリソースを消費するだけなので、Jazzcatのようなサービスで、JavaScript と CSS を統合してみてください。http://www.mobify.com/mobifyjs/docs/jazzcat/
• CSS の選択。アニメーションの荷は高く、JavascriptではなくCSSを選択してください。

つまり、iPad Mini対策では、簡単にＰＣサイトを綺麗に表示させることはできません。では、どうやってiPad Miniに最適化させればいいのでしょう？

5. レスポンシブを超えるアダプティブ

レシポンシブデザインは、マルチデバイス　スクリーン用に構築する1つの方法です。しかし、レスポンシブデザインは、CSSを取り入れる適応可能なアプローチの1つに過ぎません。

ブラッド・フロスト氏は、プレゼンテーション：（Beyond media queries: anatomy of an adaptive web design）:の中で、次のように述べています。

レスポンシブウェブデザインとは、可変グリッドデザインです。メディアの柔軟性があり、非常に幅広い適応可能な哲学/戦略の一部です。言葉が先行してしまった気配がありますが、マルチデバイスのウェブ構築のために定義されるべきです。

レスポンシブデザインだろうと、最適化を施されたサイトだろうと、重要なことは One Web アプローチです（http://www.w3.org/TR/mobile-bp/#OneWeb）。つまり、Web標準の HTML、CSS、JavaScriptを利用し、ひとつのＵＲＬを通してユーザーに提供するということです。

もし、ウェブサイトが複雑でなければ、レスポンシブデザインを使用し、よりシンプルに可変性グリッド対応ができます。しかし、ウェブサイトが複雑に変化した途端、大きな問題を発生させることになります。

• イメージ管理と最適化－さまざまなデバイスへの画像表示を可能にしますが、レシポンシブデザインのイメージの管理は困難です。http://dev.opera.com/articles/view/responsive-images-problem/
• リソース管理と最適化－画像管理を越え、全体的なリソース管理 – 画像、スクリプト、CSS はレスポンシブデザインなど、に大きな影響を与えます。
• コンテンツのリフロー －レスポンシブ　デザインは、コンテンツを非表示にするなど、限られたコンテンツでコントロールが必要です。。
• ユーザー インターフェイス (UI) 　– 多くのデバイスは、独自のUIが求められ、フォーム入力、メニューは、デバイスに応じたUIが必要です。
• データのテーブル　－画像とコンテンツをデバイスに適応させた後もテーブル要素の扱いはやっかいです。下記URLにいくつかのソリューションがあります。

http://filamentgroup.com/lab/responsive_design_approach_for_complex_multicolumn_data_tables/

レスポンシブ・デザインはフロント エンドのレイアウトにはすばらしい技術です。しかし、多くの課題も抱えています。今後は、理想と現実に対応できる高度な機能が必要です。

レスポンシブ　ウェブサイトの86％は、単純に同じＨＴＭＬページ（すべて同じ関連画像、スクリプト、コード、リソース）の配信です。そのため、それ以外を行うことは難しくなります。複雑な動作をさせることで、それぞれのバイスに最適配信ができますが、それがブラウザー上でしっかり動くかどうかはわからないという現状があります。。

iPad Miniの登場は、マルチデバイスの時代が訪れたことをさらに意識させます。今後のコミュニケーション・プロジェクト成功は、最適化のアプローチをいかにうまく行っていかがポイントになってくるでしょう。

補足：Domobiは、レスポンシブデザインをさらに拡張するできる機能を持たせることが可能です。よりパフォーマンスをあげ、構築期間とコストを抑え、さらにメンテナンスをしやすくすることができます。

（James Sherrett, October 24 2012）

マルチデバイス対応とは、オーディエンスを選ぶ時代になる！

アドテック東京2012　ライブセッション・レポート

　今日10月31日（火）は、広告とITの国際イベント、アドテック東京の初日でした。
　ワークショップのひとつ、ライブセッションにモデレーターとして登壇させていただきました。今日のゲストは、カナダのMobify社のイゴール・ファレスキー氏と、渡辺春樹氏（ビービッド）、戸井精一郎（日本経済新聞）、田中剛（花王）の４人で展開させていただきました。

どんどんデバイスが増えてきています。
スマートフォンだけの時代では、なくなってきている。

　すでに、７インチ・タブレットが登場してきました。　iPad miniをはじめ、Kindle Fireなどがそれです。またタブレットでも１０インチのNexus１０が登場しました。
　　http://www.itmedia.co.jp/news/articles/1210/30/news026.html


つまり、どんどん違うサイズのデバイスが登場してきています。３．５インチだった旧iPhone、４～５インチのスマホ群、６～７インチのタブレット群、８～１０インチの
タブレット２群と、まさにモバイルデバイスが百花繚乱となり、スクリーンサイズはどんどん増えていく時代になりそうです。



 マルチスクリーン時代のポイントは、

• PCはどんどんタブレットPCへ置き換わっていく。
• デバイス対応には、OneWebが理想である。そうしないと製作側は手間やコストが大変だ。
• なにが何でもOnewebというわけではないが、いまはそれが一番近い解決策だ。

■本当の意味のモバイルファーストを求めて

　そして、今回のライブセッションで方向が見いだされたのが、「選ぶのは、オーディエンスである」ということ。これは、過去ブラウザ対応のように、異なるブラウザで表示チェックをしたように、今度はデバイスをどう併せていくかが問われていきます。

　そこでの課題は、どうデバイスやOSに対して、表示を最適化するだけでなく、「コンテンツをどう出し分けるかが課題だ」というところがポイントです。

　PCをベースにした時代から、PCを元に変換するとしても、今後は、コンテンツをどう整理するか？そして、大事になってくるのがオーディエンスのターゲットがどういう人たちかを見極める必要があるということです。

ワンソース・マルチデバイスで
コンテンツを出し分けるということ。

　そこで初めて「モバイル・ファースト」というキーワードがでてきました。モバイルファーストでコンテンツを組み立て直し、そこから各サイズのデバイスに出し分けることが重要だということです。

　オーディエンスを選ぶ。まずあるべきなのは、やみくもなデバイス対応ではなくて、まずターゲットあり。そしてコンテンツが決まってきます。そこでは、どういうコンテンツ形態にするか、 どこのデバイスを起点のソースにするか？が決まってきます。

　オーディエンス選定から、コンテンツ選定、次にデバイス選定、その上でワンソース・マルチデバイスが考えられると予想されています。

　こうなると、開発の余地はまだまだたくさんあります。
　さて、どう料理していくか、考えただけでもエキサイティングです。







、

新OS、新デバイスになったら、Ｗｅｂ表示が正しくできますか？

10月も後半、ようやくiPhone５を手に入れることができました。
使い始めて、まだ一週間ばかりですが、最初のレポートとします。

　私が購入したのは、KDDIのauバージョン　16GBモデルです。auショップ人形町店です。ちなみに、ここの人形町店だと、64GBなら、案外すぐに購入できるようですよ。

　さて、持った感じは少し違います。掌サイズだった「4」のラインに比べて、少し長くなりました。掌スッポリではなく、ちょっとはみ出してしまう感じです。巨大化するアンドロイドと比べて、iPhone4は頑なに、従来のサイズを守ってきたともいえるのですが、今回は、少し縦方向に伸びました。この拡大はどう受け入れられるのでしょうか。

　で、一番の問題がそれほどサプライズがないこと（５Sや５Cもそうなりましたが）。４の延長なので、仕方ないですが、もう少しなにか期待感が欲しいところですね。一番の問題が、バッテリーの持ちが悪い点です。省エネ設定などを試してみましたが、それほど変わりません。もう少し様子をみて、ダメならショップに相談してみることにします。

まとめ。

○　
・さらに精緻化されたデザイン、ディテールの処理に感動。
・薄く軽くなり、軽快な感じが多少します。
・アンドロイド製品群がふた昔前に見えてしまいます。素材といい。

△
・意外と発熱する。結構使い続けると熱い。

×
・思ったほど感動が少ない。アップルに科せられたサプライズが足らない。
・電池が持たない。iPhone４よりも３０％ほど悪い。



新OS、新デバイスで、Ｗｅｂ表示は対応できていますか？

　さて、新機種、新OS登場によるモバイルWEBサイトの対応状況が実は本題です。 新しいデバイスやＯＳが表れてきたときに、意外な盲点としてWEBが崩れてしまうことが多々あります。
　それが、スクラッチの工法だったり、CMSサーバー側のテンプレートの設定だったりすると、どうしても新デバイスへの対応やＯＳへの対応がすみやかにできなくて、ＷＥＢを修正、やり直しなどの作業が生まれてきます。
　多くの原因は正しいＷＥＢの記述がされていないのが原因です。正規化されないデザイナー独自の技やローカルルールが、当たり前のように存在しているからです。

こういう場合でもクラウドの対応のサービスならば、意外とスムースに対応でき、もし不具合があったとしても極めて短時間で対策が図れていきます。
つまりサービス提供側でその対応の多くが賄われ、クライアント側による改修の負担が最小限で抑えられるわけです。特にデバイスのデータベースの管理は、個別でやると結構大変になります。


　今回のようなiPhone５もiOS６のような社会的なインパクトがある場合でも、細かいバグは心配になります。しかし、１）スクラッチの場合は前ページ槍換えなどの致命的な対応になる可能性もある。　２）CMSなどのテンプレート調整もテンプレート作成の数が多かったりします。また改修のためのスピード対応を考えると、さらに厳しい対応がせまれることも覚悟しないといけません。

　10月23日には、ipadミニがどうやら発表される見込みですが、GoogleのNexus７　アマゾンのKindle などでも、WEB対応は、新たな問題が発生する可能性があります。何しろ、7インチは誰もがノーマークだったジャンルです。いろんなコンバート方式、構築方法がある中で、やっぱりおすすめなのは、メンテのリスクが極めてすくないクラウドタイプの最適化サービスです。

　



企業としては、過去のWEB資産や、予算確保しなければならない都合から、一気にサイトリニューアルは難しいのが現状です。
　まずはサイト最適化サービスくらいから、無理のないところで、最適なモバイル対応を行う。

そのために、対応力のあるツールを選んでおくことが重要になります。ぜひこの機会に
新しいデバイスへの対応、OSへの対応についてチェックをしてみてください。



　　

【北米モバイル通信】 オープンソース化には、リスクを冒すバリューがある。

　私たちの扱っているMobify.jsがこの夏オープンソース化されました。
オープンソース化に伴い、どういう発展があるのか、リスクがあるのか、Mobify社の中でも
相当な葛藤があったようです。同社のCEOが可能性とリスクについてハーバード・ビジネスレビューの中で,次のように語っています。（占部）

オープンソース化には、リスクを冒すバリューがある。

　だれもがタダで手に入れたいと思っています。
しかし、自らのビジネスそのものに、他人からのアクセスを認めることに抵抗はないでしょうか？それは価値の判断なのでしょうか？

　2012年初頭、モビファイは、プラットフォーム技術の重要な部分をオープンソース化する判断をしました。オープンソース化は、mobify.jsという弊社の主力のフレームワークのことです。Mobify.jsは、Web制作者やデザイナーにとって、モバイル向けのWebサイトを簡単に作れるようにすることを可能にします。

 　オープンソース化とは、ソフトウェアのソースコードを公開し、誰もが入手可能とし、そうすることで、ほかの人がソフトウェアを独自のバージョンに作り替えたり、修正を加えたりすることができます。人気のブラウザであるMozilla Firefox、イメージフォーマットのPNG。またApacheは、ウェブサーバの技術として特に有名ですが、オープンソース技術の代表例といえるでしょう。

　起業家は「オープンソース化は成功へのカギだ」ということに気付きました。Andre Charlandの会社「Nitobi ソフトウェア」は、主力製品のPhoneGapを2010年にオープンソース化した後にAdobeに買収を受け入れました。Charlandは言います。「こんなに早くはできなかった」「自分のコードがどれだけ良くなるか、どれだけ早く多くのユーザーに届くか、に驚かされることでしょう。」

　オープンソース化の決断は、私たちにとって簡単なものではありませんでした。Mobify.jsのオープンソース化の前に、内部でのディスカッションをたくさん行いました。タダでフレームワークを提供したら、それを動かすための、私たちのプラットフォームは必要とされるだろうか？競合相手がこれを使ったらどうしようか？もし悪用されたら？利益にどう影響するだろう？もし、だれも使おうとしなかったら？

　オープンソース化には謙遜と勇気が必要です。時には屈辱的なことだってこともあるでしょうが、フードを取り払い、コミュニティに引っ掻き回されることで、気付かなかったバグを見つけられるます。

　あなたは自分のチームに対して、起こりうる事態に備えなければいけませんし、柔らかな物腰でフィードバックを受けることの大切さを教えなければいけません。同時に、なぜこの方向に進んでいるのか、確固たる理由や何を得たいのかについて、考えておく必要があるでしょう。

　私たちの目的は、製品の性能を高めることです。素晴らしい成功をおさめるオープンソース・プロジェクトは、数千人ものコミュニティ・メンバーによって、厳しく見直され改善されていきます。Mobifyには25人のソフトウェア開発者と品質保証のプロフェッショナルがいますが、世界のすべてのソフトウェア開発者と出会えるわけではありません。彼らは可能性を試しプロジェクトに貢献してくれています。

　貢献者たちはシリコンバレーにだけとは限りません。オープンソース化は、インド、ブラジル、中国といった巨大な市場に参入する効果的な方法になりえます。実際に各国のプログラマーとともに仕事をしたことがありました。彼らはローカルな問題を解決する手助けをしてくれました。ある地域ではソフトウェアへの支払いをする文化がなかったり、支払いをする余裕がない場合もあります。また、コードや関連資料の翻訳のために、現地の開発者をリクルートすることもあるでしょう。

　

　私たちは、オープンソース化は会社のどの部分がどのように関わるのかについて考えました。長年、私たちは数多くのオープンソース・ソリューションを利用してきました。私たちの仕事は、先行するオープンソースがあるからこそできることなのです。自社のソフトウェアをオープンソース化は、オープンソースコミュニティに負う借りを返す方法なのです。

　最後に、こららは従業員にどのような意義をもたらすでしょうか。私たちは、正しい企業風土を育てることに関心を持っています。開放的であることや透明性に価値を見出しています。これらが成功を導きます。コードをWebに入力するたびに、健全な会社となっていくのです。プログラマーには能力主義的な人が多いのですが「オープンソース化すれば、いいソフトウェアが勝つ」と、彼らの心に響くでしょう。

 

　オープンソース化はリスクを伴いますが、利益をもたらします。製品やサービスのバグを発見できるだけでなく、新しい市場、新しい製品のアイデア、新しい才能の源など、あらゆることへのチャンスが得られることでできるでしょう。

by Igor Faletski  |   7:00 AM October 12, 2012

　

【北米モバイル通信】55%のモバイル保持者がインターネットを利用

スマホユーザー数がすでに過半数を超えてしまったアメリカ市場。日本とは違って、すでにスマートフォンサイト対応がからタブレットサイト対応に関心がシフトしているという状況です。それではアメリカ人の利用状況はどうでしょうか？「ピューリサーチ」の結果をみてみましょう。（占部）

　ピュー・リサーチの調査結果によると、米国に暮らす成人のモバイル利用者の半数以上は、すでにモバイルを介してインターネットやEメールを利用しています。

　この調査の数字は、現在、アメリカ人のほぼ９０％が携帯電話を所有していますが、そのうち成年アメリカ人の４９％が携帯電話を利用してインターネットにアクセスし、74%の人々が最低でも一日に一回は、インターネットを利用していることがわかりました。

　

　２００９年には、わずか３１％の携帯保持者しかインターネットを利用していなかったことを考えると、これは驚異的な成長です。

ピュー・シニア・リサーチ専門家のアーロン・スミスは言います。

「私たちは、３年間でインターネット利用者が倍増するのを見てきました。この国はモバイル利用者を、５年間で０％から半数にしたのです」

これらの背景には、２００７年のiPhoneの誕生があります。iPhoneは、スマートフォンブームを引き起こし、携帯電話による高品質のWeb閲覧を実現したのです。

ネットユーザーの年齢層

各年齢の人々がスマートフォンを通してインターネットを利用しています。調査では、収入が7500ドル以上の世帯だけに絞ると、インターネット利用率が69％になることが明らかになりました。2016年には米国だけでも、スマートフォンは6890億ドル売り上げをもたらすと推測されている中、これは重要なことです。

アプリやスマホによるプロモーションが必要

　お店で携帯電話を開き、商品の値段がインターットの方が安いかどうかを調べたことはありますか？　米国の小売りの売り上げ全体の5.1％（1590億ドル）はスマートフォンに影響を受けています。

コンサルティング会社デロイトによると、スマートフォン利用者はスマートフォン以外の携帯電話利用者と比べて、店内で買い物をする確立が１４％高く、スマートフォンは店内の売り上げを動かす大きな要因となっています。

デロイトのカシー・コボー氏は言います。

「もはや小売り業者は、アプリやスマホによるプロモーションで購買者を引き付けることのできないと、ライバルに客を奪われてしまう。
　買い手とつながるためには、小売り業者は店の形態、形式、商品に対する購入後の反応に注意を払い、買い手の要望や経験に基づいて戦略を練り直す必要があります」

つまり、

小売り業の成功には、モバイル戦略が必要不可欠である

すばらしいモバイルサイトは、新しいダイレクト販売・店内販売をもたらします。

すばらしいモバイルサイトは、客に購買を促進します。

それは競争相手ではなく、これらを実行した企業だけに利益をもたらします。

※モビファイのPhil Webb, July 9 2012