「宅配ピザをネットで注文」の違和感

宅配ピザのドミノピザが、ネット注文に力をいれているんだそうだ。

アフィリエイト導入でWebオーダーの受注促進と売り上げ強化を狙う (日経BP ネットビジネスTODAY 2005/9)
自社Webサイト上の注文フォーム経由での売り上げの増加を狙って、アフィリエイトやキーワード広告を積極展開しているらしい。現在のところ売り上げの6%がWeb経由、残りが従来の電話注文。 これを売り上げの10%まで持っていくことが当面の目標らしい。

正直言って、クエスチョンマークだ。

上で紹介した記事によると、「(自社サイトのWeb注文は)チェーン全体で月間平均約3万件の利用がある」ということは、一日約1000件。ドミノピザの店舗数は169店舗(2005年9月現在)だから、一店舗あたりのネット経由での注文数は一日約6件。これを1日10件まで増やしたところで、残りは全て従来どおり電話注文。だからなんなのだ? こうしてマスコミに取り上げてもらう宣伝効果以外のメリットがよくわからない。

「Webはメディアだ」というのは正しいが、少なくともいまの技術インフラでは 「しかし告知にはまるで向かない」という性質を見落としがちだ。 ビジネスというジャンルにおいて、現在のWebは問題解決ツール以外の何者でもなく、これは向こう4,5年は変わらないだろう。

ピザのネット注文はそれを使うユーザーのどんな問題を解決しているのだろう?

ひとつは、最新のメニューを書いたきれいなチラシが手元に無いという状況の解決。 しかし、ひとたび配達に来ればそのときついでに最新のチラシを置いていってくれるので、以降しばらくの間はその問題は解決済みとなり、Webで注文する理由を失う。

ひとつは、仕事仲間同士で注文して職場に宅配してもらうとき、電話で注文する声を周りの人間に聞かれないで済むというメリット。 しかしちょっと一服するついでに職場の外から携帯で電話すれば済む話でもある。

ひとつは、オトクなクーポンをGET!というやつ。 ただしこれはよく考えると目的やそのメリットは「お得」であって「注文すること」ではない。ここを見落とすと単なる値引き販売による体力消耗にしかならない。

ひとつは、Webだと一度ユーザー登録すれば住所を覚えててくれるので・・・ というWebでよく聞くメリット。しかしそれは電話注文も同じだ。 ピザ店のお姉さんに電話番号を伝えるだけで「はい、○○町○番の○○さんですね」 と言われたことは誰にでもあるだろう。過去に一度でも注文したことがあれば それが店舗のデータベースに残っているわけだ。

リンクシェアのシステムを使ったアフィリエイト広告も打っているようだが、 その料率、なんと5%。数%の割引クーポンをWeb注文でも使えるようなので、 アフィリエイト経由での売り上げは実質10%近くを失うことになる。 どう考えても企業として必要とする利益は出ないはずだ。 もし筆者だったら、自分のブログサイトにでもアフィリエイトリンクを貼って、 自分(or同居人の名前or職場の隣人の名前)で注文するだろう(笑) もちろんそれは広告効果とは言えない。

このように、ピザの宅配のネット注文にはコレといったものを感じない(マスコミに取り上げてもらう宣伝効果を除く)。 ネット注文を全体の10%に引き上げたところで、メニューを書いたチラシをポストに入れまくるためのコストがそれだけ減るかというとそうでもない気がする。

とりあえず最後にビジネス向けWebサイトを作る&見る上で当たり前のこととして考えるべき観点をあげておく。

  • そのWebサイトは、ユーザーのどんな問題を解決しているだろう?
  • それは本当にユーザーの望んでいる問題解決だろうか?
  • そもそもそのユーザーとはお店に来る客?それとも従業員や取引先?

Google Maps APIと文字コード

この7月あたりから巷で話題のGoogle Maps APIだが、 文字コード関係でちょっとしたコツがある。

文字コードまわりをEUCで固めた環境で作業していて気づいたのだが、 EUCで書かれたhtmlに埋め込んだJavaScriptからGoogle Maps APIを呼び出すと、 Internet Explorerが「エラー:'GMap'は宣言されていません」のようなエラーを吐く。 ちなみにFireFox等ではこのエラーは出ない。

原因は、Google Maps APIとしてGoogleが提供するJavaScriptやデータ等が 文字コードとしてUTF-8を基本としているため、 それ以外の文字コードで書かれたHTML等とと混ぜようとするとIEが解釈しきれないらしい。

しょーがないってんでわざわざ呼び出し元のHTMLのほうを UTF-8で書き直したりしている人も多いのではないかと推察されるが、 すでにEUCやShift_JISで書かれたリソースを沢山保持している人にとっては 文字コードの乗り換えも混在もできればやりたくないのが当然だろう。

実は簡単な解決方法がある。 Google Maps APIではその基本的なライブラリを次のように呼び出すことになっているのだが、

<script src="http://maps.google.com/maps?file=api&v=1&key=....." type="text/javascript"></script>
これを、次のようにするだけ。
<script src="http://maps.google.com/maps?file=api&v=1&key=....." type="text/javascript" charset="utf-8"></script>
これで、ブラウザがよきにはからってくれるようになる(らしい)。

というテクは実は数年前にbulknews.netのmiyagawa氏が書いてたりする。

script タグに charset アトリビュート (bulknews.net 2003/10)

しかしながら、時代はもう着実にUTF-8への統一へ向かって流れている。 データ層からアプリケーション層、プレゼンテーション層にいたるまで すべてUTF-8で固めることで余計なトラブルを防ぐということも、 そろそろ真剣に考えるべきだろう。