2013-05-12

マウス操作だけでスケジュール調整ができるWebサービス「Cu-hacker」

f:id:uchiuchiyama:20130511234237p:plain

スケジュール調整の煩雑さ

打合せやランチ、旅行などで自分と相手のスケジュールを合わせる必要があるとき、皆さんはどうやって調整していますか？

メールで候補を送ってる？
Facebookメッセンジャー？
調整さんなどのサービス？

どれにしても、自分のスケジュールとにらめっこしながら、以下のようなテキストで空き時間の候補を挙げていくことになりますよね。

・5/11(土) 17:00～19:00
・5/14(火) 08:00～10:30、13:00～16:30

何気ないタイピングですが、スケジュールを見たりテキスト入力をしたりと思ったよりも大変です。また、日付と曜日が合っていなかったり、間違った時間帯を書いてしまったりすると、メール等の往復も多くなって相手も大変です。

Cu-hackerというWebサービスがあります

そこで、Googleカレンダーのような使いやすいインタフェースで、空き時間を選んで相手に送るという部分に特化したWebサービスが出てきました。

Cu-hacker | スケジュール調整を10倍早く

マウスドラッグなどの簡単な操作で自分の空き時間がテキスト化でき、それをコピーしてメールに貼り付けたり、そのままFacebookメッセージで相手に送ることができるサービスです。

使い方は非常にシンプルで簡単

まずはCu-hackerからGoogleアカウントでログインしてみましょう。

自分のスケジュールを見ながら操作

ログインすると、自分のGoogleカレンダーの予定が表示されます。

f:id:uchiuchiyama:20130512000104p:plain

一日のうち空いてる時間帯を一括選択

カレンダー上部の「一括選択」ボタンを押すと、その日一日の空いている時間帯を全て選択状態にできます。

f:id:uchiuchiyama:20130512000302p:plain

空き時間として知らせたい部分をマウスドラッグ

空いている部分をマウスでドラッグするだけで、その時間帯が左側のテキストエリアにコピーされます。

f:id:uchiuchiyama:20130512000533p:plain

コピペしたりFBメッセージで送ったり

テキストエリアの下部にある「コピー」ボタンを押すと、テキスト化された自分の空き時間がコピーできるので、そのままメールに貼り付ければ簡単に予定が調整できますね。

もちろん、空き時間情報はただのテキストなので、ミーティングルームの場所を書いたり、優先度を書き足したり、相手先に行くのか自分のところに来てほしいのか書いたり、自由に変えられます。

また、テキストエリアの上にある「Facebookの連絡先をインポート」ボタンを押すと、Facebookの友達にテキストエリアの内容をそのままメッセージとして送ることもできます。

簡単操作で毎日の小さなストレスを無くしましょう

たくさん予定調整をしないといけない人も、たまにしかそんなことないよという人も、日々のちょっとした「面倒なこと」を解決してくれるツールを使ってみてはいかがでしょうか。

Cu-hacker | スケジュール調整を10倍早く

ちなみに、サービス名の「Cu-hacker」の成り立ちは「空白ッカー」なのではないかと思っていますが、本当のところは・・謎です。

スポンサード

2013-05-06

Gunosyは多くのユーザに同じ記事を配信しているのか検証してみた

データマイニング考え方

f:id:uchiuchiyama:20130506111715p:plain

Gunosyに対する批判の一部を検証してみた

Gunosyについて、色んな意見が飛び出しているようなので、簡単ですがデータを見てみました。こういうときは冷静にデータを見てみるのが良いでしょう。あくまでもデータの羅列なので個人的にどう思っているかは表明していないです。

検証した部分

検証したのは、批判における以下の部分。

つまり、Gunosyの50〜60%のユーザーは、自分と全く同じ記事を読んでいるわけだ。
これで「一人ひとりの好みに応じて配信してます」というのはさすがにキビシイｗ
Gunosyのレコメンドエンジンの仕組み解説 - ベンチャー・アンダーグラウンド

また、これに対するGunosy側の所感から以下の部分。

実際にGunosyを使っている友人の方がいれば見比べてみてほしいのですが、配信されている記事が25記事とも同じであるというGunosyユーザー様はほとんど存在しません。
Gunosy blog - ここ最近のGunosy関連の批判についての所感

つまり、配信されている記事がユーザ毎に同じなのか、重複している記事はどのくらいあるのか、という部分について、少数ながらデータを集めて見てみました。

検証方法

全てのデータが手に入る訳ではないのでサンプリングして分析しています。

検証の方針としては、ランダムにピックアップしたGunosyユーザの特定の日の配信記事リストから、記事URLを使って重複をカウントします（※配信記事リストの掲載位置は加味せず、リストに含まれるか否かだけを見ています）。このとき、重複記事数が著しく多かったり、ユーザ間の重複率が批判の通りなのかを検証します。

Gunosyユーザのサンプリング

Gunosyユーザをサンプリングする方法は、簡易的ですがGoogle検索で「site:gunosy.com」を検索した上位100件の検索結果から、ユーザを抽出しました。ランダム性はGoogleの検索に依存するので少し微妙ですが他に利用出来るGunosyユーザ一覧も無いため、今回はこれを利用します。

結果として65人のユーザが抽出できました。

なお、今回はGoogle Custom Search APIを利用しましたが、再現可能なコードは技術系のメインブログに後ほど載せようと思います。

追記：再現可能なコードを「コード解説：Gunosyは多くのユーザに同じ記事を配信しているのか検証してみた | noriaki blog」に公開しました。

配信された記事一覧

昨日 (2013/05/05) に配信された記事の一覧を、Gunosyにアクセスして抽出しました。

結果として249記事が抽出できました。

これは、Gonosyサイトをスクレイピングしました。ユーザサンプリングと同様に後ほどコードを公開します。

追記：再現可能なコードを「コード解説：Gunosyは多くのユーザに同じ記事を配信しているのか検証してみた | noriaki blog」に公開しました。

結果

f:id:uchiuchiyama:20130506111715p:plain

これが横軸を記事、縦軸を重複配信数としてプロットした図です。

多くのユーザに同じ記事が配信されているのか

正確な計算はしていませんが、一般的なジップ分布（あるいは冪乗則）に従うように見えますので、全ユーザ（ほとんどのユーザ）に同じ記事が配信されているということは無さそうです。

最も重複している記事は46人に配信されており、全65人のうち約71％です。具体的には個人メディア雑感 - Market Hackでした。これもジップの法則から考えると、70％以上の人に配信される記事もあり得ると考えられます。

重複して配信されている記事はどのくらいあるのか

重複配信数が2以上（つまり複数ユーザに重複配信されている）記事は163記事（65％）で、一人のユーザにしか配信されていない記事は86記事（35％）でした。

その他の批判点

GunosyがGunosyを批判する記事を配信しなかった
はてブのホットエントリー記事が配信記事の大半を占める

他にも上記のような批判があるようです。(1)はGunosy blogで回答されていますね。

(2)のはてブのホットエントリーとの重複具合は、ホットエントリー記事一覧データがあれば検証可能ですね。5/5用なので5/4のホットエントリー記事一覧データがあれば検証できますが、だれか提供してもらえませんかね。また、Gunosyユーザのサンプリング方法も微妙なので、Gunosyさんからユーザ一覧（公開になっているユーザ名）などもらえるともう少し検証できるかもしれません。

参考URL

スポンサード

2013-05-04

気象庁のデータが公開されたから1988年と2012年の最高気温推移を比べてみた

書籍紹介データマイニング

f:id:uchiuchiyama:20130504100432p:plain

気象庁が過去の気象データを公開しました

f:id:uchiuchiyama:20130504103708p:plain

気象庁|過去の気象データ・ダウンロード

2013/05/01に公開されましたが、これはすごいデータですよね。1872年から昨日までのデータが毎日更新されています。140年分もの膨大なデータが表示・ダウンロードできます。

1988年と2012年の年間の最高気温推移を比較してみた

というわけでさっそく試してみました。表示・ダウンロードできる量が「地点数」×「項目数」×「期間」によって制限されているので、1回でダウンロードできる例として1988年から2012年の日別最高気温データをダウンロードしてみました。

日毎の最高気温をプロットしたグラフに7日間の移動平均線を追加して、それぞれの年を比較してみました。2012年の方が最高気温が高く推移しているように見えるかも。特に7〜9月は暑かった。逆に1，2月は気温が上がりきらなかったみたい。

気象庁のデータダウンロードサイトのUIが良い

ダウンロードできる量制限のための「地点数」×「項目数」×「期間」が、上限に対してどのくらいのパーセンテージまで来てるのか、項目を選択するたびにちゃんと反映される。しかも、上限に到達していないときには主張せず何％なのか分からないようにしてあって、上限を超えたときには何％超えているのかをちゃんと主張してるからどれくらい項目を削れば良いか分かる。

さりげないけど、ユーザ体験をよく考えられたUIで嬉しくなりますね。

最後に

最近さまざまなデータが公開されているので、組み合わせるとデータマイニングの元データとして活用できるかもしれません。使ってみて色々試してみてはいかがでしょうか。

気象庁|過去の気象データ・ダウンロード

スポンサード

統計的にデータを取り扱うための基礎を学ぶならこの本

統計学が最強の学問である

作者: 西内啓
出版社/メーカー: ダイヤモンド社
発売日: 2013/01/25
メディア: 単行本（ソフトカバー）
購入: 11人クリック: 209回
この商品を含むブログ (44件) を見る

kindle版もあるよ

統計学が最強の学問である

作者: 西内啓
出版社/メーカー: ダイヤモンド社
発売日: 2013/01/28
メディア: Kindle版
購入: 9人クリック: 25回
この商品を含むブログ (10件) を見る

2013-05-03

新人にもオススメしたい、技術も分かる企画屋さんになるためのデータ構造脳のつくり方

書籍紹介システム企画

データ構造脳の大切さ

スマホアプリやWebサービスの企画をお仕事や趣味でやっている人も多いのではないかと思いますが、個人でやるにもチームでやるにも企画の後（または同時）に考えないといけないこととは、そのアプリやサービスが取り扱うデータの内容とデータ構造です。

アプリやサービスの中でどんなデータが使われるのかというデータ内容、そのデータはどのようなかたちで保存されるのかといったデータ構造は、適切に考えられると企画を実装するにあたって色んなメリットがあります。

アプリ・サービス実装にかかる工数が軽減される
コード上でデータの取り扱いが簡単になるためバグ発生確率が低下する
UX・UIを企画するときにバックエンドシステムとの整合性を意識できる

主に最後のメリットによって、そのほかのメリットが生じると言えるでしょう。

では、こういったデータ構造はエンジニアはじめ技術の人たちしか検討・整理できないのでしょうか？

私は訓練次第でどんな人でもある程度考えられるようになると思っています。

そこで、今日は実際に私が行っていた訓練方法を実例をもとにご紹介します。この訓練方法は、この記事の最後に紹介している書籍に書かれている考え方を実際に手近にあるものを使って実践してみるものです。

コンビニのレシートからデータ構造を推測してみる訓練

まずは、この画像をご覧ください。

f:id:uchiuchiyama:20130416131818j:plain

なんの変哲も無い、私が昼食を買ったときのレシートです。アプリやサービスなどの画面とは違いますが立派なUIです。このレシートを受け取った私は、いつ、どこで、なにをどのくらい、どうやって購入したのか分かるようになっています。

このレシートをもとに、「買い物（購入）」処理に関するデータ構造を想像してみるのが今回の訓練です。

なお、この訓練に正解はありません。実際のDB構造を見ることができるものでもない限り、答え合わせはできないのですが、想像してアウトプットする習慣を付けることが重要です。

レシートにどんな情報が書いてあるのか

こういった買い物（購入）といった取引（トランザクション）には、ほぼ必ず以下のようなデータが紐付いています。将棋や囲碁での定石にあたるものでしょうか。

いつ取引が行われたのか（それが記録されたのはいつか） (When)
どこで取引が行われたのか　(Where)
何が取引されたのか (What)
その取引を担当したのは誰なのか (Who)
どのように取引されたのか（どのような手段で取引されたのか） (How)

まず、これらの情報をありったけ見つけて書き出します。その次にその情報を似たまとまり毎に分類して整理していきましょう。

いつ？

f:id:uchiuchiyama:20130503165346j:plain

この部分に書いてありますね。2013年4月16日 09:21です。つまり、この取引データが作成された日時です。表にすると以下ですね。

レシート

データ項目	データ内容
作成日時	2013/04/16 09:21

どこで？

f:id:uchiuchiyama:20130503165400j:plain

取引された場所を探してみましょう。この部分にお店の名前と住所、電話番号が書いてあります。先ほどの表に追加してみましょう。

レシート

データ項目	データ内容
作成日時	2013/04/16 09:21
お店の名前	東新橋一丁目店
お店の住所	東京都港区東新橋1-3-1
お店の電話番号	03-3573-7228

なにが？

f:id:uchiuchiyama:20130503165420p:plain

何が取引（購入）されたかは簡単に見つかりますね。2つあるので2つとも見つけてみます。商品名と購入価格があるのでそれぞれを表に追加してみましょう。

レシート

データ項目	データ内容
作成日時	2013/04/16 09:21
お店の名前	東新橋一丁目店
お店の住所	東京都港区東新橋1-3-1
お店の電話番号	03-3573-7228
買った商品1の名前	ｱｻﾋﾏﾂﾅﾏﾐｿｽﾞｲﾅﾒｺｼﾞﾙ
買った商品1の値段	137円
買った商品2の名前	手巻寿司納豆
買った商品2の値段	135円

だれが？

f:id:uchiuchiyama:20130503165424j:plain

取引を担当した人はレシートの下の方に書いてありますね。これも追加してみましょう。

レシート

データ項目	データ内容
作成日時	2013/04/16 09:21
お店の名前	東新橋一丁目店
お店の住所	東京都港区東新橋1-3-1
お店の電話番号	03-3573-7228
買った商品1の名前	ｱｻﾋﾏﾂﾅﾏﾐｿｽﾞｲﾅﾒｺｼﾞﾙ
買った商品1の値段	137円
買った商品2の名前	手巻寿司納豆
買った商品2の値段	135円
レジ担当者の名前	森川

どのように？

f:id:uchiuchiyama:20130503184426j:plain

支払い方法はこの部分に書いてありますね。今回は電子マネーのiDを利用しました。iDに関する情報が書いてありますね。ここでは支払い方法としてのiDと、支払い回数を抜き出してみます。

そのほかにも様々書かれていますが、これは皆さんで考えてみてください、宿題ですね。

まとめてみると

レシート

データ項目	データ内容
作成日時	2013/04/16 09:21
お店の名前	東新橋一丁目店
お店の住所	東京都港区東新橋1-3-1
お店の電話番号	03-3573-7228
買った商品1の名前	ｱｻﾋﾏﾂﾅﾏﾐｿｽﾞｲﾅﾒｺｼﾞﾙ
買った商品1の値段	137円
買った商品2の名前	手巻寿司納豆
買った商品2の値段	135円
レジ担当者の名前	森川
支払い方法	iD
支払い回数	一回

データの入れ物（テーブル）がレシートで、データ項目（カラム）とデータ内容（値）をまとめています。

分類して整理する

どこで？の部分で出てきたお店の名前とお店の住所のように、別のものを表している各項目にお店のという共通部分があることに気づいたでしょうか。また、買った商品1や買った商品2というように同じものが複数登場することにも気づいたと思います。

こういった共通部分を抜き出して別のデータ構造としたり、重複するデータを複数のつながりにまとめたりすることを、データ（ベース）を正規化すると呼びます。

今回のレシートでは、例えば以下のように正規化できます。

レシート

データ項目	データ内容
id	1
作成日時	2013/04/16 09:21
レジ担当者の名前	森川
お店id	1
支払い方法	iD
支払い回数	一回

お店

データ項目	データ内容
id	1
お店の名前	東新橋一丁目店
お店の住所	東京都港区東新橋1-3-1
お店の電話番号	03-3573-7228

商品

データ項目	データ内容
レシートid	1	1
名前	ｱｻﾋﾏﾂﾅﾏﾐｿｽﾞｲﾅﾒｺｼﾞﾙ	手巻寿司納豆
値段	137円	135円

お店id 1 の東新橋一丁目店で、4/16に森川さんのレジでiD1回払いの取引（購入）をしたことをレシートテーブルとお店テーブルで記録しています。

また、このとき購入された商品は、ｱｻﾋﾏﾂﾅﾏﾐｿｽﾞｲﾅﾒｺｼﾞﾙと手巻寿司納豆をそれぞれのデータとして、商品テーブルにレシートidと一緒に記録しています。

正規化のことを書くとそれだけでもう2記事くらい書く必要があるので書籍等に譲りますが、データベースを利用するシステムやUIを考慮して適切に正規化を行うことは様々な利点があります。

たとえば今回の例では、データベースを持っているお店や企業（今回の場合はLAWSON）では、1日に何回も取引が行われ（レシートも発行され）ます。そのため、取引のたびにお店の情報をデータベースに記録していくとデータ量がとんでもないことになりそうです。また、もしお店の電話番号が変わったら今までの取引の全てのデータを修正していかなければなりません。

この訓練のときには、データを見つけることに加えて正規化も意識しながらスッキリとしたデータ構造が作れるように考えてみるようにしましょう。

最後に

企画からローンチまでの期間がどんどん短くなっている現在では、実装するのも自分だという人はもちろん、技術の人たちと一緒に考えていくスタイルの人でも、企画する人が技術のことを知っていることによってコミュニケーションコストが下がります。結果、より早くアプリやサービスを完成させることができるため、技術は技術屋さんにお任せではなく、少しでも知っていくことが大切です。（もちろん、技術の人が企画やマーケティングを知ることも同じくらい大切です）

今日ご紹介したような訓練を日常的に行えば、今は苦手に思っている人でもきっと適切なデータ構造を簡単にすばやく考えられるようになるでしょう。まずは身近なものから、見かけたら頭の中で変換する癖が付くくらい実践してみましょう。

今回、訓練を説明するのに参考にした書籍は楽々ERDレッスンです。この本には今日の内容はもちろん、データ構造を考える上で必須となる基本的な考え方が分かりやすく書かれています。2006年4月に発売された本ですが、データ構造理解は考え方のベースとなる部分なので流行り廃りがなく現在でも十分な内容です。訓練を続けると共にぜひ読んでみて下さい。

楽々ERDレッスン (CodeZine BOOKS)

作者: (株)スターロジック羽生章洋
出版社/メーカー: 翔泳社
発売日: 2006/04/18
メディア: 単行本
購入: 72人クリック: 940回
この商品を含むブログ (118件) を見る

2013-05-01

Google&Facebookに学ぶ、新機能の実装プロセス、を実践するためにGoogle Analyticsウェブテスト機能を使う

考え方

f:id:uchiuchiyama:20130501061107j:plain

kensuuさんが以下のようにブログに書いていて、まったくその通りだと思うのですが、じゃあどうやって枠組みを作るのかというとPDCAを含む意思決定プロセスに落とし込む必要があると思います。

どのみち言えることは、「メンバーを信じてやってもらう」ということがまず最初にあるのかなあ、と思っています。
そして、クリエイティブを発揮してもらいつつ、それが単なるアイディアの出し合いじゃなく、価値ある実装まで持っていき、ユーザーに支持してもらえるようにするか、という枠組みを、経営者層が決めるというのが重要なのだと思います。ここが本当に難しいのですが、それを作れるような会社を目指さないとですね。
Google&Facebookに学ぶ、新機能の実装プロセス - nanapi社長日記 @kensuu

PDCAを含む意思決定プロセス

PDCAを含む意思決定プロセスと言ってもよく分からないので具体的なプロセスにしてみると、

良いも悪いも分からないけど数多くのアイデアを出す (Plan)
その中でどんな順番でアイデアを試すか決める（やるやらないではなく順番） (Plan)
現在のサービスにアイデアを実装する。このとき、全部を一度に実装するのではなくて、一つずつ組み込んだ現在と少しだけ違うページをアイデアの種類数だけ用意する (Do)
現在のものと同時平行で少数（または多く）のユーザに使ってもらう (Do)
（事前に決めた指標・目標をもとに）良かったパターンをデータから見つけ出す (Check)
その知見を取り入れてまた(1)から繰り返す (Action)

こんな感じでしょうか。

みんな大好きGoogle Analytics

上記の(4)(5)を無料で非常に手軽に実施できる機能が、Google Analyticsの「ウェブテスト」機能です。簡単に言うと「A/Bテスト」ツールですね。

これは、複数登録したページ (URL) のうちオリジナルページにアクセスしたユーザを一定割合別のページ（パターンページ）へリダイレクトさせ、それらのデータを計測して可視化できる機能です。下記のスクリーンショットを見てもらうとよく分かるかもしれません。

f:id:uchiuchiyama:20130501063158j:plain

使い方はGoogle Analyticsにログインして、左サイドメニューの「コンテンツ」→「ウェブテスト」を選択するだけです。

オリジナルページのURLを入力すると始まるウィザードに従って設定を進め、いくつかコードをコピー＆ペーストでページに組み込むだけで簡単にA/Bテストが開始できますので、あなたのサービスでも試してみてはいかがでしょうか。

ちなみに、今回作成したウェブテストには実際にアクセスできます。アクセスすると、ユーザ毎に0001.htmlか0002.htmlのどちらかに振り分けられます。Cookieが有効な間は必ず同じページに振り分けられるので別パターンのページにアクセスしたい場合はCookieを削除してみてください。

ウェブテストやA/Bテストをプロセスに組み込むときに参考にした本

データ・サイエンティストに学ぶ「分析力」ビッグデータからビジネス・チャンスをつかむ

作者: ディミトリ・マークス,ポール・ブラウン,馬渕邦美,小林啓倫
出版社/メーカー: 日経BP社
発売日: 2013/02/28
メディア: 単行本
購入: 3人クリック: 12回
この商品を含むブログ (6件) を見る

2013-04-27

リクルート・ホールディングスを退職しYahoo! JAPANへ入社します

仕事

f:id:uchiuchiyama:20130427122204p:plain

ご挨拶

4/30(火)を最終出社日として、リクルート・ホールディングスならびに出向中のメディア・シェイカーズを退職いたします。Facebook上はもちろん随所でお世話になった皆さまにあらためてお礼を申し上げます。 5/1(水)からヤフー株式会社に入社しマーケティング・イノベーション室にJoinします。

リクルートでの5年1ヶ月

リクルートではMTL〜事業開発室〜アドオプティマイゼーション推進室と一貫してネット広告事業の開発・推進を担当させていただきながら、ビジネス人としてのイロハをたたき込んでいただきました。その後、メディア・シェイカーズ出向後はR25のデジタル領域を担当させていただきつつ、様々なチャレンジにも携わる機会をいただきました。

リクルートには5年1ヶ月在籍しましたが、社会人になって初めての会社がリクルートで本当に良かったと思っています。退職して転職・独立する人が多く「人材輩出企業」と呼ばれたりもしますが、自分が退職することになった今、あらためてその理由が分かった気がします。それはリクルートでは全従業員が、お給料をもらいながらMBA（経営学修士）を受けているようなものだということです。リクルートで仕事をすることそのものが、毎日毎日、自分が直面する経営課題を解決する方法を模索したくさんの優秀な仲間たちとトライアル＆エラーを繰り返していることなのだと。

こんなリクルートで出会ったすばらしい仲間とのエキサイティングな経験を糧に内山は転職します。人生で初めての転職ですが、不思議と気持ちは落ち着いていてワクワクしています。

新しい場所 Yahoo! JAPAN

5/1(水)から携わるマーケティング・イノベーション室ではDaisuke Tomozawaのもとで、たくさんの人を巻き込んでいきながら仕事をしていきたいと思っています。

2012年8月：仏CRITEOの日本法人へ出資
2012年10月：MediaMindと業務提携
2013年2月：SSP事業を手がけるジーニーへ出資
2013年3月：DSP事業を手がけるFreakOutへ出資

社外から見ているだけですが、Y!Jキャピタルを含む広告に関するヤフーのここ半年の動きは「爆速」化を体現するものだと思っています。そんな爆速なヤフーに入社し、デジタル広告における「ブランディング」「ダイレクトレスポンス」の両方とも、ヤフーの超巨大なメディア・データをフル活用しつつ、内山が得意としているテクノロジーはもちろんクリエイティブに関しても多くのチャレンジをできればと思っています。日本を代表するメディアを巻き込んだ日本の「広告」「マーケティング」の価値を再定義し創り出すくらいの気持ちで、日々勉強しつつ頑張っていきますので皆さま変わらぬお力添え、ご指導をよろしくお願いいたします。