HTML5 Experts.jpが誇るエキスパートたちに、「UX」というテーマでインタビューするシリーズ第三弾です。

株式会社Spelldata CEO、そしてエキスパートNo.54の竹洞陽一郎さんに、「UXとWebパフォーマンス」について聞いてきました。UXとWebパフォーマンス、なんとなーく関連ありそうだなーくらいの気持ちでインタビューをお願いしたのですが、それらに密接な関連があるというだけではなく、マーケティング活動にも大きな影響があることなど、経営者ならではの視点からのお話も聞かせていただきました！

パフォーマンスに関する認識が甘いそこのアナタ、意識が変わること請け合いのインタビューです！ どうぞお楽しみください。

　▲左から、インタビュアー白石俊平編集長、HTML5 Experts.jpエキスパート竹洞陽一郎さん

パフォーマンス上の問題を抱えるサイトは99%！？

白石: 今日はよろしくお願いします。竹洞さんは先日、Webサイトの品質改善を行う株式会社Spelldataを立ち上げられ、10月にWebサイトも公開されたわけですが、Webサイトさすがに速いですね。

竹洞: ありがとうございます。装飾は一切抜いて、画像の数やアクセスするドメイン数を必要最低限に留めることで、高速化を心がけてます。

白石: ちなみに今ぼくが言ったみたいに、「御社のWebサイト、さすがに速いですね」とお客様からお褒めの言葉をいただくようなことって、ありますか？

竹洞:いやあ、ないですねえ。全然（笑）。

白石:ないですか？注目に値する速さな気がしますけども。

竹洞:Webサイトがポンポン表示されるなんて、世の中のほとんどの人にとっては当たり前のことなんですよ。

白石:えっ？？そうなんですか？でも…ポンポン表示されないWebサイトなんて、ザラにありますよね？

竹洞:はい。つまり、大多数の人はポンポン出ないWebサイトからは、すぐに離脱しちゃうんです。ってことは、そんなサイトは存在しないも同じ。

白石: な、なるほど。「ポンポン出るのが当たり前」っていうのは、裏を返すと、「ポンポン出ないWebサイトは存在しないも同じ」ってことですか。

竹洞:そうそう。「速くて当たり前でしょ」って感覚。IT業界以外の人に聞いて調査してみると、もっとショックですよ。ちょっとでも表示に時間かかると、容赦なく離脱します。年齢が上がる程に気が短いですね。あと、男性より女性（笑）。

一方、Webサイトをつくる企業やWeb制作会社は、自分のサイトに対して愛があるから、バイアスがかかって無視しちゃうんです。逆に速かったときの印象は記憶に残りやすく、遅いのはたまたまだ、って思っちゃうんですね。実際に自社のサイトが遅いという経験をしても、「PCの調子が悪いんだ」とか「電車の車内だしな」とか、他に原因を求めちゃう。この辺りのお話は、「錯覚の科学」という本が詳しいです。「人は見たいものだけ見えて、聞きたいことだけ聞こえる」そうです。

白石:なるほど。では、パフォーマンスに問題のあるWebサイトって、どれくらいの割合あるんでしょう。

竹洞:基本的に日本のWebサイトの99%はパフォーマンスに問題ある、と言ってもいいんじゃないですか。

白石:え、えええ！そんなにですか！99%！？

竹洞:日本のサイトはデスクトップサイトの場合は、トップページが表示し終えるのに平均で4、5秒かかるのはザラなんです。一方、アメリカはトップページを平均1秒以内を目標にしているというレベル。スマートフォンサイトについては、日本はトップページが表示し終えるまで30秒ぐらいかかるのに対して、アメリカの場合は平均5秒前後です。

白石:意識の差が大きいんですかねえ…。

竹洞:もちろん、日本にも意識高い企業はありますよ。例えば三菱電機さんなんかは、すごくパフォーマンスに気を使っています。正直、コーポレートサイトって、普段からエンドユーザーが見に来るようなものでもないじゃないですか。でも重要な「何か」があった時にはアクセスが殺到する。その時にサイトが見れなかったりすると、最もユーザーが情報を欲しがっている時に、情報を提供できないということになる。そういう時こそ、企業の姿勢や文化が見える。だから、普段からパフォーマンスを意識したサイト作りを行っていると言うんです。でも、なかなかこういう企業は、日本にはないですね。

白石:じゃあ、パフォーマンスに問題を抱えたサイトが実際にはたくさんある中で、企業はいつ、どういうきっかけでその問題に気づくのでしょうか？

竹洞:お客様からクレームがあった、っていうのが一番よくあるパターンですね。でも、日本の場合、お客様からクレームがあった場合は、相当数のお客様が既に見限っていることが多いです。パフォーマンスの遅いサイトは、ユーザ体験を損ねた結果、クレームとして跳ね返ってくるわけです。

UXとWebパフォーマンスの密接な関係

白石:なるほど。「遅い」とか「つながらない」とかって、よく考えるとだいぶネガティブな印象を受けますよね。

竹洞:そうなんです。で、今白石さんがおっしゃった「印象」って、UXを語る上ですごく大事です。 UXは「ISO9241-210:2010」で定義されていて、「製品、システムもしくはサービスの利用もしくは利用によって予測される人の認知と反応」だそうです。ですから「人の心(認知)に変化(反応)を引き起こす」、つまり「人の心がどう動いたか」だと私は考えています。ですから、UXはマーケティングという企業活動と非常に密接な関係があります。

白石:ぼく、恥ずかしながら最近まで知らなかったのですが、UXってマーケティングの文脈で語られることも一般的なんですよね。

竹洞:そうなんです。だから、サイトのUXに問題があるという企業は、マーケティング上の問題を抱えていると言ってもいい。パフォーマンスはその最たるものです。UXに大きな影響を及ぼす項目でありながら、一番問題が看過されやすい。

白石:竹洞さんの会社も、企業のマーケティング活動をトータルでサポートしてらっしゃるんですよね。

竹洞:そうです。Webサイトのパフォーマンス改善は、その活動の一部でしかない。結局のところ企業の提供するWebサイトって、マーケティング用、販売促進用のツールって言ってもいいと思うんです。 なのにWebサイトが遅いと、ユーザがサイトを見ないで帰ってしまう。これでは、興味を持ってくれたお客さんがそこにいるのに、チラシを渡そうとモタモタしているうちにお客さんが去って行ってしまうようなものです。

白石:なるほど…だから、パフォーマンスを含めたUXの改善が、売上にとっても無視できない影響をおよぼすというわけですね。

竹洞:ただ、UXを考える場合には、一旦Webから離れた方がいいんです。

白石: と、いうと？

竹洞:例えばとある名古屋市で複数店舗を展開している美容室ですが、顧客のペルソナを「37歳女性、2児の母」と明確に定めているそうなんです。そのペルソナに姓名まで付けてある。このペルソナに該当しない女性は、来店していただいかなくてよいとまで言い切っているんです。そして、この顧客のことを具体的に考えて、最高のサービスを提供しようとする。

すると、子供連れで来店できるように託児室を用意するということに繋がる。 それだけじゃありません。その美容室は、その「37歳、2児の母」のための美容サービスがワンストップで提供できるように差別化しています。だから、その美容室でネイルケアもできれば、エステも受けられる、大学と一緒になって研究開発した、37歳を中心とした年齢層向けの化粧品も買える…という具合にサービスを充実しています。

待合室も広いサロンになっていて、気軽に2〜3時間一人で過ごしたり、他の来店客と談笑を楽しんだり、店内で販売している子供服をショッピングできるスペースになっている。こうなると、美容室の概念と、そこでの顧客体験そのものが変わっちゃうんですよね。

白石:面白い！

竹洞:結局UXを改善するといっても、事業上のUSP(Unique Selling Proposition)が無いままに闇雲にやってはダメなんです。先の例のように、自社の差別化要因をしっかり考えないと。 「なぜ顧客は、他の企業ではなく、私の会社のサービスを使うべきなのか? 自社の商品を買うべきなのか？」という問いに答えられるようになることが大事。

ここをしっかり考えてあると、自然と販促ツールもしくは販売ツールであるWebサイトで伝えるべき価値が明確になり、その結果、Webの分野におけるUX改善において達成すべき目標も明確になります。

白石:なるほど。伝えるべきものがあってこその、Webサイトですもんね。

竹洞:ただ、Webサイトのパフォーマンスを上げないと、そもそもサイトを見てももらえません。見てもらえないなら、（Webサイトの）UXもへったくれもありません。

先程も申し上げたとおり、エンドユーザの意識としては、Webサイトはポンポン表示されて当たり前。だから遅いという理由で減点されこそすれ、速いからといって加点されるわけじゃないのです。こういう意味ではパフォーマンスの高速化というのは、「売れない理由をつぶす」ということだと言えます。パフォーマンスを上げることが売上アップに直接繋がるとは限りませんが、パフォーマンスが悪いと確実に売上に影響する。

パフォーマンスが上がると売上が上がる？

白石:先ほどから何度かご指摘されている、「パフォーマンスが悪いと、サイトそのものを見てもらえない」というのは、具体的にどれくらい見てもらえないものなんでしょう？「遅い！」といって去ってしまう人の割合は？

竹洞:一つの指標になるのは、Google Analytics（GA）が示す「直帰率」です。

ただGAの直帰率って、そもそもGAのスクリプト読み込みが成功したときしか計測できないんですよね。ユーザがサーバにアクセスして、HTMLが読み込まれて、ブラウザがGAのJavaScriptファイルを読み込んで実行する、この一連の動作が完了する前にユーザが離脱してしまった場合は、計測の数値としては「欠損」になってしまいます。

そこで必要になってくるのが、サーバのアクセスログとの突き合わせです。実際にやってみるとわかりますが、GAのデータと結構食い違いが出てきますよ。サーバログのアクセス数に比べて、GAのアクセス数が3〜4割少ないことが頻繁にあります。

白石:そんなに！それだけの人々が、サイトの遅さにあきれて離脱してしまっている可能性もあるということですか。

竹洞:全部がパフォーマンスのせいではないでしょうが、無視できない割合なのは間違いありません。だから、「サイトを高速化するとアクセス数が伸びる」というのは実は単純な理屈なんです。サイトを速くすれば、直帰率が下がる。

白石:なるほど…遅いサイトを我慢できなくなったのは、モバイルの普及も関係ありそうですね。PCだったら、遅いサイトを読み込んでいる間にほかのことをして時間を潰せますが、スマホだとそうはいきませんものね。

パフォーマンスを改善せよ！そして、UXを改善せよ！

白石:では、Webエンジニアが実際にパフォーマンス改善を行うために、どのようなことを心がければいいでしょうか？

竹洞:品質管理の概念を製造業から学んで、実験計画法に基づいて、自分が関与しているWebサイトのパフォーマンスの計測データ取得して、毎日見ることですね。

私は、成蹊大学名誉教授の中西寛子先生にお願いして、月1回「中西塾」という統計学の勉強会を開催していて、そこの管理人をやっています。中西先生が今月の回で仰っていたのですが、日本はデータの取り方について、世界に比べて教育が非常に遅れているそうです。

データの取り方には、1. 調査 2. 実験 3.観測の3つがあるそうで、欧米では明確に違いを分けているそうです。この中で、因果関係を説明できるのは、「実験」だけなんです。それは、実験者が実験計画に「介入」することが可能だからなんです。

しかし、日本でパフォーマンス計測で有名なのは、FirebugやChrome Developer Toolですよね。あれは、「観測」なんです。因果関係は証明できない。「何か関係がありそうだな」と当たりをつける程度なんです。 では、「実験」と「観測」の根本的な違いは何かというと、実験計画法の「局所管理化、ランダム化、反復」を満たしているかどうかです。

品質管理で、商品を1個だけ抜き出して、それが品質基準を満たしていたら、他の全商品が満たしていると言っていいかと問われれば、ダメに決まっています。でも、今のWebの業界って、それをやってるんですよ。時々、FirebugやChrome Developer Toolを使って計測してみて終わりという具合に。そもそも、インターネットの中は、毎日状況が変わっているという意識がないから、一度、高速化してしまえば、それでOKだと思っている人がほとんどだし。

Webサーバからインターネット回線やモバイル回線、そして端末のWebブラウザという一連の「生産ライン」を、HTML、CSS、JavaScript、画像といった「部品」が流れていって、Webブラウザ上で組み立てられた「完成品」がWebページで、その部品を配送する「インターネット」というベルトコンベアの状況が毎日変わっているんだから、毎日計測しないと、今のパフォーマンスはどうなっているってことを言えないんです。昨日速かったから、今日も速いわけじゃない。

例えば、デバイスからネットワークパフォーマンスを計測する「スピードテスト」みたいなアプリっていろいろあるじゃないですか。あれ、実はあんまり意味ないんですよね。

白石:え、そうなんですか。あれで計測してキャリアや端末を比較している記事とか、よく見かけますけども…。

竹洞:最近はネットワークも複雑系の極みで、パケットの経路も一意には定まりません。全部の通信が、一度、日本のIXを通って…というのは、昔のお話です。どこのサーバにアクセスするかによって、経路は様々です。あのテストで得られる結果って、「たまたまその時、そのアプリのテストサーバにアクセスする経路で、一度だけ」得られたパフォーマンスデータでしかないんです。

統計的に意味のあるデータにするためには、一定数以上のサンプルが必要。例えば、弊社製品の宣伝みたいで恐縮なんですが、うちだと「SpeedData」というサービスがあります。これは、Webサイトのパフォーマンスデータを24時間365日計測して得られたデータに、高度な統計的処理を施した上で、様々な形の可視化を行うことができます。

▲図:実際に計測していたデータをグラフで表示
白石:なるほどー。で、データを見て問題の切り分けを行うわけですね。

竹洞:はい。おおまかに言えば、パフォーマンスの問題は「フロントエンド」「バックエンド」そして中間をつなぐ「ネットワーク」のそれぞれに切り分けられます。それぞれについて、ちょっとしたTIPSをご紹介しますね。

ネットワークでは、実はDNSがボトルネックになることがよくあります。特にモバイルネットワークだと、日本ではNTTドコモ、KDDI、ソフトバンクの三社が抱えるDNSサーバに負荷が集中するという構造がある。しかし、その点を深く考えないWeb制作会社や運営会社は、何かあったときにサーバを切り替えやすいようにとか言って、DNSのTTLを5〜10分に設定します。

そうなると、スマートフォンでの名前解決のキャッシュが5〜10分で切れるわけですから、数百万台のスマートフォンからDNS LookupのDos攻撃を常に受けているようなものです。これに耐えているのは素晴らしいとしか言いようがありませんが、さすがにパフォーマンスが安定しません。

フロントエンドでいうと、ソーシャルボタンや広告などが足を引っ張ることがよくありますね。こうしたパーツはiframeで読み込まれることが多いですが、iframeのレンダリングそのものが遅い上に、iframeで読み込んだHTMLが別ドメインのリソースを参照していることもよくあります。

例えば、Facebookのいいね！ボタンだけでも4ドメイン以上参照していたりもする。TwitterやGoogle+、はてなブックマークボタンなどを入れると、参照するドメイン数が15を超えるのは普通です。しかも、サービス事業者側としてはできるだけ新しいリソースにアクセスして欲しいので、キャッシュの有効期限も短く設定されているのが普通。

こうなってくると、HTTPのリクエスト数も多いし、DNSも足を引っ張りますし、少ないドメイン数で構成されているWebページを前提としているSPDYとかもあんまり効果がありません。

バックエンドに問題があった場合は、一筋縄では行きませんよね。以前私が担当した仕事で、CDNのエッジサーバ上で動的にページを生成する仕組みを導入してフロント部分の高速化を行った所、今までTopページの速度が平均15秒ぐらいだったのが2〜3秒になって、その結果、アクセス数が殺到しちゃって、バックエンドのシステムが持たなくなっちゃった、なんてこともありました。その時は、バックエンドの修正コストが馬鹿にならなかったので、泣く泣く元に戻しましたけども（笑）。

白石:それは残念な事例ですね（笑）

竹洞:また、どうしてもパフォーマンス改善が難しいケースもあります。特に、サービスのコンセプトそのものが、パフォーマンスとのトレードオフになる場合などは悩ましいですね。例えば以前携わったお仕事で、「世界中のほぼ全てのホテルを検索できる」というのがウリのサービスがありました。バックエンドのパフォーマンスを上げたいけれども、元となるホテルの検索結果のデータを提供するアメリカやロンドンのAPIサーバの反応がよくなくて、どうしても限界がありました。

白石:それには、どう対処したんですか？

竹洞:結局パフォーマンスの問題は、UXの問題の一部でしかないというところがポイントです。実際の速度を変えられなくとも、UXは改善できる。その時は、検索の進捗状況をプログレスバーで見える化してユーザのストレスを軽減すると共に、そのサービスのウリである「世界中のほぼ全てのホテルを検索できる、聞いたことのない国でもホテルが予約できる」というメッセージが、ユーザの目に留まりやすいようにしたのです。

そのサービスのウリは、ユーザにとても価値のあるものでした。だからその価値を前面に打ち出した上で、その代わり検索には時間がかかるよ、とわかりやすく表現することで、速度面でのウィークポイントを補えると判断したのです。

白石:なるほど。サービスの価値をユーザに明確に認識してもらうことが、UXの改善につながったというわけですね。

竹洞:はい。それは結局のところ、インタビュー冒頭に申し上げた「UXとは結局、人の心がどう動いたか」であるという考えにも繋がるわけですね。サービスの価値を理解してもらうことが、ユーザの心を動かすのです。

白石:UX、パフォーマンス、マーケティングなど、いろいろなお話が聞けてとても価値のある、楽しい時間でした。どうも、ありがとうございました！