2013年3月17日日曜日

モバイルサイトは、スクラッチで構築したほうが儲かるという「妖怪の正体」!

モバイルサイトは、

スクラッチで構築したほうが儲かるという「妖怪の正体」!

この1年間は、ずっとモバイルサイトをより効率的に作る方法というものを調査・研究してきました。ようやく、はっきりしてきたので、これらを整理してまとめようとおもっています。
 ところがやっかいなのが、目に見えぬ壁、理想を追わないほうが儲かるという壁です。



1.スクラッチで構築する

まず、スマートフォンサイトの多くが「スクラッチ構築」で作られています。つまり、手作業で、別途でスマートフォンサイトを作る手法のことで、大手サイトの約6割はこの構築方法で作られています。

○と×

○自由に、制限なくモバイルサイトが構築できる。

×運用コストが延々にかかる。×別サイトでマーケティング的に不都合。

 だから、そろそろ企業のWEB担当者はもう気づいています。スクラッチで構築すると「最初はやすく済ませられるけど、あとあとのコストが大変に無駄」と。


2.サーバーサイドでテンプレート調整

CMSをベースにする手法のひとつですが、サーバーサイトでのテンプレート調整で対応します。これはエンジニアがテンプレートを設計する方法です。仕組みとして持っているというよりも、個別でスクラッチで構築される場合もあります。一元管理できるという点では、ある意味で理想のアプローチですが、エンジニアのコストや微調整におけるスピード感、またデザインのフレキシビリティで考えると、問題は少なくありません

○一元管理できる 
×コストがかかりすぎる。 
×小回りがきかない。融通性がない。 
×実際の対応はスクラッチで構築が多い 


 このほかにも、プロキシーソリューションやアプリ対応などがありますが、北米では、ほぼレスポンシブウエブデザインと、このサーバーサイドテンプレート調整の2つに絞られてきた感じがあります。(後述しますね。今度)

古いやり方のほうが業者は儲かるという現実

 ともかく、スクラッチは、マルチスクリーン時代においては、領域が変わるため、今後のモバイル対応には向かない手法です。
 またサーバーサイドのテンプレート調整を含め、より効率的にものごとを解決するよりも、従来のやり方をしたほうが、都合がよく「儲かる」という本音もあります。

(なんとなく暴露系ジャーナリズムのようになってきましたが、、、、)

 スクラッチでの構築は、制作費がかかり、その後の運用更新でも作業料がかかります。また、サーバー代やチェックにもが二重にコストがかかるために、理屈として請求がしやすくなるようです。
 業者の口説き文句は、「モバイルとPCは違うから、専用サイトでいいですよ。」「スマホはモバイルファーストで作る必要があります」「デザインも自由にできます」と、ものすごい根拠のセールストークをするようです。


 また、サーバーサイドのテンプレート調整でも、ある大手ベンダーの技術担当者がいいまいした。「安く効率的に作るよりも、5000万円ぐらいのCMSを売りつけたほうが儲かるですよ」「毎月のメンテナンス費用も結構稼げます」「コンテンツ移行させるのだけでも結構手間だから200万円~300万円くらいかかります」

(もうすっかりナニワ金融道の世界です。)

 大手広告代理店においては「もっと儲かる仕組みならうれしいんですけど、なんとかなりませんか?」と尋ね返して来る始末です。

某・元大手ITベンダーの関係者が、私にアドバイスしてくれました。

「昔からそうなんですよ。ITやインターネットといっても、元は建築関係の見積もり構造なんです。なのでオーソドックスで儲かる仕組みをキープしようとします。大手になればなるほどそういうもんですよ」


企業担当者もわかってはいるが、なかなか整理は難しい。

 企業担当者の方もいいます。「まあ相手も儲けないといけないだろうから、今は高くならなければ許せる部分があるけど、今後はねえ~。そりゃもちろん、ダメでしょ。」

 もっとも、企業担当者の大変です。スマートフォンだけではなく、タブレット対応も考える必要があるし、One WEB化対応の必要性、PCではなくモバイル中心のWEBリニューアルなど、まさに激動期で、「なにがベターか」は、混乱は高まるばかりでしょう。

 私としては、今後の変化に対応できる、リーズナブルで、フレキシブルなモバイルステップアップ方法をレポートしていきいたいと考えています。なのでよろしくお願いします。




2013年3月12日火曜日

Googleのエンハンスド・キャンペーンは、モバイルサイトをどう変える?


「グーグルが、モバイルとデスクトップ、それぞれの広告の壁を吹き飛ばす!」

 2月6日に、Googleが自らのブログニュースで、奇妙なニュースを流しました。
2013年の半ば、7月頃に、いままでのモバイル広告とPC向けの広告の区別を止めて、ひとつに広告手法に統合するというものです。これを「エンハンスド・キャンペーン」といいます。

http://www.businessinsider.com/google-blends-desktop-and-mobile-ads-2013-2?utm_source=Responsive+Design+Weekly&utm_campaign=82238c0a14-Responsive_Design_Weekly_044&utm_medium=email


 この発表が意味するものはなんでしょうか?

  今後のGoogleの広告キャンペーンにおいては、スマートフォン、タブレット、パソコンなどの複数のスクリーンにおいて常に橋渡しができるように設計されます。また、全媒体を合わせたレポートの作成も可能になるといいます。


 これによるメリットはなんでしょうか? CNETで報じられいるメリットでいえば、

  • デバイス、場所、時間帯といった状況に合わせたデータ管理。ひとつの広告キャンペーンで、すべての表示媒体に対しての入札単価の調整が可能。
  • ユーザーの状況に合わせた広告の最適化が可能
  • 異なるデバイスにまたがってコンバージョンを測定できるレポートの作成が可能

つまりチャネル単位ではなく、より人にフォーカスしたプロモーションが可能になるといいます。


 また、逆にデメリットはなんでしょうか?

クライアントにとっては2つありそうです。ひとつは、いままでより多くの広告費を支払う必要があるということ。これはGoogleのAdwords広告のクリック単価(CPC)が、5四半期連続で下がり続けていることにも要因があります。Googleには下がりきったモバイル広告の単価をあげたいという目論見があるからです。


 ランディングページのOneWeb化も大きな課題

これも重要な問題です。というのも、現在はモバイル用とPC用では、ほとんどの場合、ランディングページが別々に作られています。つまり「領域」がことなるわけです。スクラッチの方法もそうですが、CMSでサーバーサイドテンプレート構築、プロキシーソリューションの変換サービスで作られたモバイルサイトは、どれもそうです。


 もし、今後のリスティング広告を結果を正確に分析しようとすると、ランディングページは同一URL、OneWeb化が必至となります。そうしないと、レポートの整理が乱雑になってしまい、その整理はやっかいになるからです。

 あるメディアの友人が応えてくれました。

「メディア側というよりも、企業側のほうが大変じゃないでしょうか。Eコマースやリスティング広告を使用する企業なら、One Web化のためにサイト設計をやり直す可能性もでてくるでしょう。解決策は、Onewebによる最適化サービスやそれに対応したCMS構築、レスポンシブデザインの3つしかありません。それ以外の方法で構築すると、再び手直しが必要になって来る可能性があります」

 つまり、現状では、ランディングページは別々の場合がほとんどである。いままでは、デバイスというチャンネルに対して広告課金されていたから、それ専用のランディングページでもよかった。それが今後は、人に対して広告料をとるという仕組みになってくる。もうチャンネルはどこでもよくて、その経由など補足するには、「One Web」=ひとつのURLでないと都合が悪くなるというわけです。
  企業側はマルチ・チャンネル化によりコスト増なのに、別ページとなるモバイルページやプロキシーソリューションでは、再びやり直す必要もでてきている。

タブレット対策、OneWeb化など、いまから無駄のないモバイルサイトの構築を考えておく必要がますます大切になってきました。



2013年2月25日月曜日

モバイルファーストは、ファーストフードなり~?


モバイルファーストは、ファーストフードなり~?


 前回のレポートでは、「PCサイトは幕の内弁当なり~!」というテーマをまとめて見ました。これはPCサイトには、できるだけ多くの要素を詰め込むことが常に考えられてきたからです。過去15年間以上、私たちに染みついてしまったパッケージ手法です。それは、受け手というよりもむしろ、「送り手の思いを詰め込むためのテクニック」だったようにも考えられます。

 さて、今後重要視されるモバイルファーストのデザインとはなんでしょうか?
 これは(1)圧倒的に画面スペースが小さいということです。次に、使われ方が(2)屋外で利用されることが多いということです。これらは、フューチャーフォンの時代にも、よく語られたことでしたが、以前は、PCとフューチャーフォンは別ものと捉えられていました。しかし、今ではスマートフォンがPCと同じものであり、PCやタブレットと連携しながら使うことが可能になったことから、よりモバイルに適した設計やPCとの連動できる設計が求められています。

 米国のスターバックスのWebサイトは、現在レスポンシブデザインで展開されていますhttp://www.starbucks.com/。

 レスポンシブデザインというのは、さまざまなデバイスに対して、適合できる手法の一つで、今後のマルチスクリーン、マルチデバイスへの最適表示方法として注目されている手法の一つです。
しかし、私の友人のMobify社イゴール・ファレスキーが、昨年末にシアトルでスターバックスのWeb担当者からコメントをもらったようです。「今回のリニューアルは、一部では失敗だった」ことを認めたようです。

みなさんは、なにが失敗だったのか、実際にスマートフォンで試してみてもらえますか?





  結論としては、モバイルでムービーは不要だったということです。つまり、PCと同じコンテンツの扱いは、かならずしも正ではないということです。モバイルで必要だったのは、ストアロケ-ター(店舗位置情報)だったり、キャンペーン限定商品だったりと、優先準備が変わってきます。
モバイルファーストの発想に立てば、よりターゲットの状況に即したコンテンツを提供することが重要です。


 この場合、レスポンシブデザインは、マルチスクリーン対応を考慮したものの、モバイルファーストは十分に考慮されていなかったと言えます。

  モバイルファーストを考える上で、例えのひとつとしてファーストフードがふさわしいでしょう。マクドナルド、吉野屋、ケンタッキーなどなど、前回の「PCサイトは幕の内弁当なり~」とは大きく変わってきます。

  ポイントは、素早いこと、目的が明確であること、価格がリーズナブル、この3つに集約できるのではないでしょうか?

(1)すばやいこと
目的の商品がすばやく探せますか?つまりローディング時間が高速でないといけません。また、素早く探せるUIも必要です。

(2)目的が明確であること
目的が買い物なのか、地図なのか、料金表なのか、より明確な選定が必要です。スターバックスの場合は、ショートムービーよりは店舗情報検索でした。ターゲットをもう一度見直して、彼らが求める内容を精査する必要があります。

(3)価格がリーズナブル=モバイルならでの手頃感
お手軽であることが重要です。とくにEコマースの場合は手軽に購入できる商品を中心にまとめることを考慮する必要があり、そういう意味では、PCサイトとは違う商品を用意することも必要のようです。

 そして、ここでは、より多くの要素ではなく、限られた要素に絞ることも重要です。PCサイトは真逆なミニマムな発想をもって検討してみることが必要です。
これらを検討しながら、「モバイルファーストのためのサイト作り」を考えてみてはいかがでしょうか?



2013年2月21日木曜日

PCサイトは、幕の内弁当なり〜!

 最近、「モバイルファースト」を考える機会が多いのですが、そもそもデスクトップサイトというのは「いかに情報を詰め込むか」という、なりゆきで始まったと感じています。
 つまり限られたサイズの中で、いかに情報を効率よく詰め込み、ポイントを押さえるか。これは雑誌のレイアウトの原則だったのではないかと思っています。かつて、雑誌の編集者をしていた頃に、デザイナーのN親分が、教えてくれたことがあります。
「ただ詰め込んじゃダメ。なにがポイントかを考えてラフを描くんだ」と。

ビギナー編集者というのはどうしても要素を詰め込んでしまいがちです。「白スペース恐怖症」というのもありました。でも、こういうページは、「どこがポイントであるかどうか、わからない」からダメページにあるというのです。
答えとしては、「つまりポイントを作れ」でした。

今考えると、雑誌デザインは、雑多な要素に調和をといれた「幕の内弁当」だったともえいえます。この写真の場合、ポイントとなるのは、エビフライです。



さて、幕の内弁当デザインといえばヤフーです。

かつてのヤフーのデザインはこれでした。それが10年後にはこうです。

1997年                       2010年


 

どうでしょうか?
複雑化をつづけながらも、「そうじゃいけない、よりわかりすく、より多く」という「整理とポイントの歴史」を続けてきたといえるでしょう。
ヤフーの場合はレクタングル・バナー枠が「エビフライ」に相当するのでしょう。


モバイルファーストの時代は、ファーストフードの発想で。

モバイルファーストの時代になってくると、今度は、情報を最小化していく必要があります。幕の内弁当ではなく、「ファーストフード」に切り替える発想だとおもっています。

マクドナルト、吉野屋、Coco壱番屋、KFC・・・・・


『モバイルファースト』著者 ルーク・ウロブロスキーがいいます。
ユーザーに場所や、そのときのニーズ、つかい用途を考えてデザインしていく必要があると。

しかし、問題は、それをどう実践していくかが重要です。なにしろ我々は15年以上も「幕の内弁当」の発想でWebサイトを作り続けてきたきたわけですから、そう簡単には切り替えられないのです。シンプルで要素の少ないデザインをできるでしょうか。

雑誌デザインでいう「白スペース恐怖症」に似た、シンプルすぎる要素を
どう判断していくことになるでしょうか?
ぜひこれについて、ご意見お願いします。

2013年2月12日火曜日

モバイルファーストという言葉の意味?

モバイルファーストという言葉が使われ始めています。

この言葉は、元ヤフーUSAのチーフアキテクトであり、eBayでも活躍したUI/UXデザイナーのルーク・ウロブスキーが2009年に提唱した言葉です。

2011年9月には、彼の著書「モバイルファースト」が、米国で発売され、ようやく日本でもこの言葉が少しずつ使われ始めているようです。



モバイルファーストを簡単におさらいすると3つのポイントがあります。それは3つの社会変化といえます。

1)急拡大するスマートフォン端末の拡大
2)限られた画面における制約ーコンテンツフォーカスが必要
3)新しいテクノロジー 位置情報や音声認識などの登場


以上の変化が生活スタイルに関わってくるために、今後はPCによるデスクトップファーストではなく、モバイルを中心とした「モバイルファーストでの行動スタイル、コンテンツ様式が求められてくる」といいます。

このことを突き詰めていくと、
もはや重要視すべきなのは、モバイルサイトであって、
デスクトップサイトは、二番目に考えればいいという考えです。


すでに主婦層や若年層では、スマートフォンを中心とした行動様式のシフトが始まっており、PCサイトのモバイルからの流入率は 40%を超えようとしています。これらは欧米なみに、1年後には間違いなく50%を超えてくる可能性があります。


バズワード化するモバイルファースト?

このモバイルファーストについての考えは、後述するとして、この言葉は、少々暴走気味に一人歩きをはじめている気配もあります。

 ある携帯端末会社のスタッフはいいます。自分たちのサイトはモバイルファーストで作ってあるから大丈夫です。話をしていくうちにちょっと定義がずれているのに気がつきまいた。彼らは、モバイル専用のサイトをスクラッチで作る。または、スマートフォン専用のアプリを開発するという意味で使われていました。

専用アプリがモバイルファースト?これには少々驚いてしましました。それは言葉として間違いないかもしれませんが、デバイス間の連携やコンテンツの流用=ワンソースマルチデバイスなどはまったく考えられていなかったからです。


ルークの考えるモバイルファーストをあえてわかりやすくいえば、

モバイルを中心にWEBサイトを設計し、それをマルチスクリーン対応にして効率化をはかること」

と理解します。そしていま注目されているのは、ユーザーはデバイス間で遷移をするということです。
 今後、明らかにされる、モバイルへの流入率、利用時間、滞在時間、Eコマースの伸びのデータの公表は、間違いなく、モバイルファーストに対する感覚を大きく変えていくことでしょう。

2012年12月30日日曜日

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

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

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


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

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

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

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


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

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

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


このURLの問題が何を表しているかがポイントです。
非OneWeb、つまりURLが別々になったときの問題としては、大きく下記の3つがでてきます。
  1. SEO効果をだめにする。リスティング効果が半減
  2. ソーシャル効果がダメになる。拡散、集客
  3. マーケティング集計 ログ解析がダメになる。


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

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


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

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

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




2012年12月6日木曜日

エンジニアから見た、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や新機種のバージョンアップのたびに右往左往する可能性がでてきます。それもサーバー単位で細かく修正するというような。1つや2つならまだいいですが、複数単位やぺージが増えると大変です。これがMobifyの場合、システム上で調整が効きます。この点も大きいでしょうね。 


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

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


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