みすず学苑のCMがヤバイことになっている話

Posted on 2月, 24 at 3:35 pm

私の出身地である名古屋には、美宝堂やアサヒドーカメラといったインパクト強めのCMがあるのですが、東京にも、みすず学苑という衝撃的なCMがあります。関西は・・・なんだろう、ながーーーーーーーーーーーーーーいおつきあいの京都銀行とかですかね。もっとありそうだな。しかもレベル高そう。

で、このみすず学苑ですが、テレビCM以外でも結構露出していて、交通広告（電車）でよく見かけていて、テレビでもちょくちょく見るわけですが、最近のCMがとんでもないクリエイティブに仕上ってます。タイトルは、プリンセス編。

「シンデレラれな～い！」「知らん雪姫！」「不合かぐや姫～」などでツカまれ、お決まりの「怒涛の英語と個人指導」と続きます。

しかしここからがインパクト強烈。

「成績アップ、プリン、プリン、プリン！」

と言いながら、最後はみんなでポーズを決めるんですが、背景にはプリンの雨が降っています。もうね、まったく意味がわからないんです。ついでに白雪姫の女性はめちゃめちゃ顔を黒く塗ってるし（いちおうツッコミポイントだと思ったので指摘しておきます）。

テレビCMにおいて、視聴者へのインパクトはかなり重要で、このクリエイティブによってかなりみすず学苑は完全に頭にインプットされましたが、問題は学習塾の信頼性が伝わったかどうか。

学習塾を選ぶときって、それなりにお金を払うわけだから、選ぶときも料金や通いやすさも然ることながら、実績や講師の質はもっと重要な要素になってくると思いますが、私も親として、親の立場で考えると、「みすず学苑」と聞けばあのCMが思い出され、なんかクソみたいなダジャレを並べまくってた品のない塾だよな・・・というのが印象で、今の時点では、子供をみすず学苑に通わせようとは、残念ながら思いません。そう、みすず学苑の広告には、「品」がないんです。

病院のWebサイトでは、ほとんどが「白」を基調としたものが多く、全体的に落ち着いたデザインであることが多いです。「病院」に最も必要なのは「信頼性」「清潔さ」であって、それを一番得やすいのが、そういうテイストなんだといわれてます。きっと病院という建物は昔から建物全体、設備全体が白いことが多く、「落ち着いた白＝きれいな病院＝信頼できる病院」という連想を持つ傾向があるのだと思います。

回転寿司チェーンのWebサイトでは、赤と黒、たまに木目をパーツに使用しているところが多く見受けられます。日本人が大好きなマグロと、海苔、そしてゲタを連想させる組み合わせです。新鮮さや雰囲気を伝えるためだと思われます。

学習塾の場合もやっぱり「信頼性」が必要のはず。加えて、「塾生を全力で志望校に合格させるという熱い思い」。ただ、「熱い思い」ばかりを前面に出しても胡散臭いだけ。だからそこは冷静にというか、クールに装い、実績面でアピールするのが正解といえます。

そう考えると大手予備校のサイトなんかは、代々木ゼミナールも駿台も河合塾も四谷学院も日能研も、すべて背景は白で統一されており、病院のような、でもちょっとアカデミックに大学のような雰囲気がうまく表現されています。ちなみに、みすず学苑も、Webサイトはわりと信頼できそうなトーンです（MovableTypeで作られてますね）。

・・・トーンはいいのですが、ビックリしたのはこのサイト、google chromeで閲覧しようとすると初回はアクセスが制限されてしまいます。

「警告：このサイトにアクセスするとコンピュータに損害を与える可能性があります。」

やっぱり・・・やばいでしょ、みすず学苑。塾のサイトなのに、Googleからはまったく信頼されていない。だれか教えてあげてください。不合かぐや姫。

Posted in Google, Google Chrome, Web, Youtube, デザイン, マーケティング | 1 Comment »

Twitterの投稿数は1日5000万だという話

Posted on 2月, 23 at 3:37 pm

As a member of the Twitter analytics team, part of my job is to measure and understand growth. The graph above tells a story of how we’ve grown over the past three years in terms of number of tweets created per day. Please note that tweets from accounts identified as spam have been removed so the counts in this chart do not include spam.

（Twitter分析チームではTweetの推移を分析しているのですが、上野グラフでは毎日のTweet量を、過去三年間でどのように推移したかを表しているものです。なお、スパムはこの数値には含まれていません。）

引用元: Twitter Blog: Measuring Tweets.

1日に5000万のツイートですってよ。レコード長が140バイト。ただし日本語は140文字なので、280バイト（かそれ以上）。同じDB設計なら280バイトで、さらにプロファイル情報なども考えるとレコードあたり400バイトぐらいのデータ長で考える必要がありますが、だとすると一日に増加するデータ容量は、

400Byte　×　5000万　＝　200億バイト≒約１8.6GB／日

もうすこし読むと、下のほうに、

Today, we are seeing 50 million tweets per day—that’s an average of 600 tweets per second. (Yes, we have TPS reports.)

（現在、一日に5000万のTweetsがあり、それは平均６００Tweets／秒になります）

となっています。勢いがすごいな。

データ量にして、一ヶ月に558GB、一年で6.5TB。まあこれはテキストだけなので、写真などのマルチメディアデータは含みません。たいした容量です。

たいした量ですが・・・思ったほどではなかったな。なぜかというと、だいぶ前にGoogleEarthの記事を読んだからかも。

http://www.itmedia.co.jp/news/articles/0609/27/news104.html

Google Earthのデータは「70Tバイト以上」
Google Earth開発責任者が来日し、「Google Earthのデータ量は70Tバイト以上」と明かした。データ量は毎月増えているといい、ユーザーによるコンテンツの追加にも期待をかける。

あと、このへんとかも。

http://gigazine.net/index.php?/news/comments/20080110_google_20petabytes/

Googleフェローの発表資料によると、2007年9月時点でGoogleは1日に20ペタバイト（20,000テラバイト＝20,000,000ギガバイト）以上のデータを大規模なコンピュータ群で処理しているようです。それにしても想像するのが難しいほどのデータ量ですね。

ペタとか、意味がわからんですよ。そのうちカンタンに扱えるサイズになるんだろうか。「この映画、2時間ほどですがデータは１ペタぐらいですね」「こちらの機器の転送量は２Pbpsですね」的な。

頑張れムーアの法則。

・・・と、ひさしぶりにせっかくちゃんと書いたと思ったら、GIGAZINEにすでにまとめられていた・・・かなしいとき。とりあえずトラックバックしておこう。

http://gigazine.net/index.php?/news/comments/20100223_twitter_50million_tweets_per_day/

Posted in Google, Twitter, Web, コミュニケーション | No Comments »

誰かマックでダブルマックツイストセットを頼んでみて。

Posted on 2月, 19 at 7:52 pm

「ダブルマックツイストセットをホットコーヒーで」

とマックで注文したら、クルクル回りながら何かがでてきそうな気がしますが、マックツイストを2回やる、という技のようで、マックツイストってどんななのよ、という素人ですみません。

あ、ちなみに今日ハワイアンバーガー食べました。久しぶりに「これはイケる」と思いました。よろしければぜひどうぞ。

ショーン・ホワイトの全て [DVD]

ビデオメーカー 2010-02-19
売り上げランキング : 81

Amazonで詳しく見る by G-Tools

Posted in 日記 | No Comments »

バンクーバーに行ってきた（嘘）

Posted on 2月, 17 at 12:37 pm

バンクーバーに行ってきました。

大きな地図で見る

というのは冗談で、久しぶりにストリートビューを見ていたら、そういえばバンクーバー歩けるじゃん、と思ってGooglemap旅行。スタジアムできてる～。

スタジアムが大きいこともすごいし、バーチャルに動き回れるのもすごいし、一瞬で移動できるのもすごい。あと、バンクーバーの位置も今回初めて知った（左のほうだったのね・・・）。

というわけで、バンクーバーからお届けしました。ガンバレニッポン。

Posted in 日記 | No Comments »

Google Docsのテンプレートがエラい数になっとる

Posted on 2月, 16 at 6:47 pm

GoogleDocsのテンプレートがいつの間にかずいぶん増えたなぁ・・・と思っていろいろ見ていたら、

gdoc

「数千」は、ちょっと見る気が失せました・・・。

まあ実際、iPhoneのAppStoreも、表記するなら同じようなことになるんでしょうが、Googleだったらもう少し書き方あるだろー、とツッコんでおきます一応。

見方を変えれば、アクティブなユーザーがそれだけすごい数になったということなんですね。クラウドってすごいや。

Posted in Google, Google Document, SaaS, Web | No Comments »

「日本でFacebookの地位を獲得するのは、やっぱりmixiか、それともGREEか」という記事が興味深い・・

Posted on 2月, 16 at 10:58 am

これは興味深い記事。GREEって使ったことないけど。

先日、mixiがFacebookのようなタイムラインを導入するべきではないかという記事を書いたが、この視点で日本のSNS市場を見た上で、当然もう一つ忘れてはいけないプレイヤーがいる。それがGREEだ。

引用元: [jp] 日本でFacebookの地位を獲得するのは、やっぱりmixiか、それともGREEか。 .

これが・・・

こうなるかもしれないよ、という図。わかりやすい。

確かにGREEって5年前ぐらいはmixiと争ってて、ユーザー数で全然勝ち目ないなーと思ってましたが、モバゲーぽくなってきたなーという印象を持つようになってから、たしかにmixiと立ち位置が明確に分かれてきたなぁと思ってました。一時期、モバゲーと区別がつかなかった頃もありましたが。

個人的には、Facebookが日本ユーザ向けに強力にローカライズしてくる可能性もあるんじゃないかと思ってますが、どうなんですかね。そのへんの議論はすでに語りつくされているのかもしれません。

たしかに、SNSゲームは、シンプルなものが多く、ゲームそのものはたいしたことないのだが、シンプルだけにハマりやすいのは否定できない。実際自分もやってるし。

Posted in Web, Webビジネス, マーケティング | No Comments »

今さら挑戦、味覚マジック（アボガド＋しょうゆ）

Posted on 2月, 15 at 11:10 am

アボガドにしょうゆをかけるとトロの味になる

というのは有名な話ですが、ホントなんだろうかと思ってスーパーでアボガドを買ってきて試してみました。

こういう組み合わせ。

キッカケは「世界一受けたい授業」の番宣でやっていたことで、なんだか科学的にも甘みを示すレーダーチャートがトロと「アボガド＋しょうゆ」がほとんど同じ形になるというので、ほんとなのかと思い。

またこういう味覚マジックはほかにもいろいろあるようで、このへんとかにかいてありましたのでご参考に。

http://chururun.jp/archives/2004/10/26_1213.php

http://contest2005.thinkquest.jp/tqj2005/80405/main8.html

で、この「アボガド＋しょうゆ」ですが、こんなかんじにして食べます。

すると本当にトロの味っぽい。これはやばい。お手軽すぎる。アボガド１個で120円～130円なので、トロと比べて圧倒的なコストパフォーマンス。多少違和感を覚えても、このコストパフォーマンスには文句は言えない。ということで、今さらながら感動し、思わずブログにエントリーしてしまったわけです。

なお、しょうゆはワサビ醤油のほうが再現度は高いと思われ、また今回はやわらかめのアボガドを使用したため、どちらかというとネギトロ的な食感。やわらかめのアボガドを使用する際にはノリを用意して、軍艦をつくって乗せて食べるといいと思います。

それにしても、人間の味覚は曖昧なもんで。毎年、正月に放送されている「芸能人格付けチェック」を観てもよくわかります。

そういえば、その番宣でもうひとつやっていたのは、

ホットミルク＋たくあん＝コーンスープ

でした。堺正章はそれなりに評価していたので、よろしければこちらもお試しください。

新鮮じゃないと美味しくないアボガド 24個箱入り

Posted in グルメ, 日記 | No Comments »

FlickrPro申し込み

Posted on 2月, 15 at 9:55 am

FlickrのProアカウントに申し込みました。

という備忘録的な内容は、Google Analyticsのアノテーションに記録しておきましょう。

以後気をつけます。

http://www.google.com/intl/ja_ALL/analytics/

Posted in Analytics, Google | No Comments »

Twitterのテーブルは3つで構成されているかも（DB入門編）

Posted on 2月, 14 at 12:23 am

何気なく、風呂に入りながら「Twitterっていくつのテーブルで構成されているんだろう」と思ってしまって、DBの構造を推測してみた。仕事ではSalesforceのテーブル管理をしたことがあるが、ヤツはとんでもないテーブル数を持っていて、どこに何が格納されているのかさっぱり予測できない。当然カンペキに正規化されているんだろうけれども、あれだけ複雑なアプリケーションであるのと、やっぱりクライアントごとにしっかりデータを分けなければならないというポリシーがあるはずだから（営業データだからね・・）、基本的にはテーブル単位、あるいはDB単位で分けているんだと思う。

で、Twitter。「無料のつぶやきサービス」というサービスで、先のSalesforceとは求められるSLAがまったく異なる。個人単位でデータをエクスポート／インポートすることもない。爆発的に増加するユーザや爆発的に発生するつぶやきに、いかにスケーラブルに対応するかが、このサービスのポイント。それらのポイントをクリアするためには、どのようなテーブル構成が求められるのだろうか。元DBエンジニアの端くれとして、風呂の中で考えてみたのでメモしておきます。現役のエンジニアさんにとってはレベルの低い話なのでスルーしていただければ。

まず基本要件が、大きく３つ。

自分のつぶやきと自分のフォローしているアカウントのつぶやきをタイムラインで抽出できる

自分がフォローしているアカウントの一覧を抽出できる

自分をフォローしているアカウントの一覧を抽出できる

これがTwitterの基本機能（のはず）。そうすると、Salesforce的な設計であれば、

①アカウント一覧テーブル（全ユーザのアカウントを管理。アカウントID、パスワード、アイコン、各種プロファイル）

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID）

③フォロー一覧テーブル（登録日付、アカウントID）

④被フォロー一覧テーブル（登録日付、アカウントID）

となるが、この設計だと①を除いた②③④は、アカウントごとにテーブルを用意する必要がある。ユーザーには利用頻度に違いがあるので、一度アカウントを作ったけれどもまったく利用していないユーザーに対してもこれらのテーブルを用意しておかなければならない。論理的に確保しておくだけなのでユーザーが少ないうちは気にする必要はないかもしれないが、その数が数千、数万を超えるようだと無視できないサイズになる。DBの中ではテーブルを作成すると、レコードが入っていようがいまいが、一定の領域を確保してしまうからだ（表領域と言います）。

ちなみに、下はTwitterのアカウント登録数推移。毎日20万～30万人のユーザーが新規登録している。恐ろしい規模だ。この規模で上のような設計をしていたら、ストレージがいくらあっても足りない。

ではそれぞれの共有できるテーブルにしていくには。①は共通のテーブルだからいいとして、②は全ユーザーで共有できそうだ。カラムの構成を

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID）

から

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID、アカウントID）

とする。こうすれば②も共有できる。自分だけのつぶやき一覧は、SQLで条件指定（where ユーザーID＝xxx order by 日付）

で抽出することができる。何億ユーザになっても、テーブルは１つで済む。

しかし、③と④がまだユーザー単位に必要だ。というわけで次に③と④をやっつけていく。

結論から言うと、③と④は合体して、１つのテーブルで管理できる。難しく考える必要はなくて、

③フォロー一覧テーブル（登録日付、アカウントID、）

④被フォロー一覧テーブル（登録日付、アカウントID）

から、

③＋④フォロー関係一覧テーブル（登録日付、フォロー元ID、フォロー先ID）

するだけ。錆付いた頭では、頭の中だけで考えるとちょっと時間がかかりました・・・。紙に書けば一瞬だった。こうすると、各レコードは

AさんがBさんをフォローした場合、（”201002132342″,”A”,”B”）というレコードが、

BさんがCさんをフォローした場合、（”201002132348″,”B”,”C”）というレコードが作成される。

こうすることで、すべてのフォロー関係を１テーブルで管理することができるようになる。自分が誰をフォローしているのかを知りたければこのテーブルから（where フォロー元ID＝A）で3列目を抽出すればよいし、自分をフォローしてくれているアカウントを抽出するには（where フォロー先ID＝B）で2列目を抽出すればよい。

これらの３テーブル

①アカウント一覧テーブル（全ユーザのアカウントを管理。アカウントID、パスワード、アイコン、各種プロファイル）

②つぶやき一覧テーブル（日付、つぶやき内容、つぶやきID、アカウントID）

③＋④フォロー関係一覧テーブル（登録日付、フォロー元ID、フォロー先ID）

で、ユーザーごとにテーブルを作成することなく、スケーラブルな対応ができるようになるわけだ（たぶん）。

厳密には、運用上無限に肥大化し続けるテーブルは扱いづらいため、つぶやき一覧テーブルなんかはレコード数単位で分割されていると思う。アカウントを発行するときにでも、①のアカウント一覧テーブルのカラムに、書き込み先のつぶやき一覧テーブルの識別番号を与えているかもしれない。またはテーブル自体は仮想的に一意の名前にして、実際にはIDのレンジでテーブルをパーティショニングしているかもしれない。あと、リストの管理とかもあるし、当然これだけでは済まないのは理解しています。

というわけで、勝手にTwitterのテーブル構造を予想してみましたが、これはTwitterがOracleやMySQLのようなリレーショナルデータベースを使っていたら、の話。GoogleのBigTableのような別のアーキテクチャを使っていたら、これらは全然違うだろうし、BigTableを理解していないので推測もできません。ただAPIを使ってTwitterアプリを作ってみたら、いちいち予想しなくてもわかりそうな気もする。作ったことないし、作る予定もないので永遠に推測の域を出ませんが。誰か正解知ってるのかな。

たまにはDBマガジンでも読んでみるかな。トレンドはキャッチアップしておかないとね、モチベーションがあるうちに。