楽天テクノロジーカンファレンス2014に参加してきた

久しぶりに参加しました。全体的に人も増えて盛り上がっていました。

中嶋 聡さんの話

今回自分が聞いたセッションの中で、一番熱量が高いプレゼンでした。

 

以下よかったところのピックアップ。

22分のところ:日本の閉塞感についての話。イノベーションが起きない理由。

エグゼクティブたちは、若い奴らはパッションがないという。
若いエンジニアは、ボスから言われた今のプロジェクトでいそがいしいという。アイディアを思いついてボスに持っていっても、承認されない。
双方がブロックされていると感じている。
誰もイノベーションに対して責任を持っていない状態。
中島さんのこの問題に対する答え:イノベーションはコーポレート戦略ではなく個々人のパッションから生まれる。 

46分のところ:Windows95の誕生話。

Windows95は、Microsoftの公式プロジェクト(Cairoと呼ばれていた。MBAホルダー, コンピューターサイエンティストで構成されたチーム)からではなく、Cairoが失敗したときのためのバックアッププロジェクト(Chicagoと呼ばれていた。Windows3.1のハッカーチーム)から生まれた。中島さんは最初Cairoチームにいたが、ここでは何も起きないと思いWindows3.1チームに移り実装を始めた。
ビルゲイツへのプレゼンのタイミングで、Cairoが200枚のドキュメントを提出したのに対し、Chicagoはβ版のプロダクトCDを渡した。
直後にビルゲイツはCairoのプロジェクトをキャンセルした。
イノベーションがおこっていないのなら、自分の失敗である。あなたはイノベーションを起こす責任がある。

この話を聞いて中島さんのファンになってしまい、メルマガも申し込んでみました。こちらは、シアトルで仕事をされている中島さんの普段の気づきなどがシェアされており、国際感が得られるのでしばらく続けようと思ってます。オススメできる内容です。

 三木谷さんの話

楽天マーケティングジャパン事業というのを始めたと最近ニュースでも話題になりましたが、ビッグデータの取り組みの一部が紹介されました。

 

31分のところ:楽天市場のデータを用いて、政府が公表する2ヶ月前に景気総合指数を予測した

今後、例えばウエアラブルなどあらゆる生活からクラウドにデータが送られるようになるので、益々データサイエンスが重要になるということです。エンジニアとしては、これから勉強をしておいて損のない分野だと思います。自分も概要がぱっと分かるくらいにはなりたい。 

塩野 隆生さんの話

楽天市場の開発についての話です。市場について色々な数字がみれます。

今後は、今あるレガシーなシステムをAPIで統一するといったことをこれからやっていくということです。世界のシステムを統一するとなると、色々大変そうです。楽天はその辺の先端を走る企業なので、その後ナレッジが国内に展開されていくといいなーと勝手に思ったりしています。

また個人的にはプレゼン後に質問をして、V-commerceのことを少し聞けたのがよかったです。かなりバックリと良いか悪いか?と質問したところ、良いそうです。(今の英語力的にそれが限界だった。。)

 

喜連川 優さんの話

スライドは非公開。

既存のRDBに比べて数100〜1000倍にパフォーマンスを高めたアウトオブオーダ型データベースエンジン(OoODE)についての話。
ポイントとしては、既存の同期処理をしていたRDBに対して、非同期処理の概念をRDBに持ち込んだところだそうです。詳しくはよくわからなかったですが、webサーバーでいうとApacheからNode.jsのようなパラダイムシフトに近いイメージだと思われます。

プレゼンで笑いをとっていたところも良かったです。最後の方、プレゼンの時間がなくなってきた時点で、スライドショーからスライド一覧の画面に戻して下にだーっと流し始め、"Please feel."と言ったところが個人的によかった。

カンファレンスとは関係ないですが、 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント  に、ユーモアについて書かれたすばらしい一説があったので引用します。

優れたベンチャー企業、優れたプロジェクト、ついでに言えば優れた仕事は、楽しくなければいけない。 あなたが死ぬほど働いているのに、ちっとも楽しくないという場合、おそらく何か間違っている。楽しい理由の一つは、将来の成功の予感かもしれない。だが、一番大きいのは、同僚と一緒に笑ったり、ジョークを言い合ったり、ともに仕事をすることの楽しさであるはずだ。 

 

ビアバッシュでの森 正弥さんとの話

今回セッションを含めても一番学びがあったトークだったかも知れません。

森さんのマネジメント方法について教えていただきました。

キモとしては、親心を持つ、ということらいしいです。それを端的にいってしまうと、質問には答えない。その人のフィールドで会話をすることになるので、その人の視野が広がらない、とのことです。それよりも、その人の20年後、30年後の人生を考えて話をしましょうということです。

親心とは。

Google Analytics Embed APIのチュートリアルをRailsで試してみた

Google Analytics は、Web サービス構築に携わる皆様ならご利用の方も多いと思います。そんな中、管理ツールなどで一元管理してみたいっ!という要望をもらうエンジニアも多いのではないでしょうか。

 

今回は、Google Analytics APIの中でも手に付けやすいEmbed APIのチュートリアルをやってみました。意外と日本語の情報が少なかったので共有します。今回の手順は、HTMLが動くWebサーバーであればどのプログラミング言語でも適用できます。


Google Analytics API 概要

Google Analyticsは、以下のパーツからなります。

https://developers.google.com/analytics/images/platform/platformOverview.png

  • Collection – データを収集する。おなじみのga.jsなどです。
  • Configuration – データをどう扱うかの設定をする。
  • Processing – Configrationの設定をつかってデータを処理する。
  • Reporting – Processingで生成されたデータを可視化する。

 

APIは、ConfigurationとReportingの部分で用意されているようです。今回ご紹介するのは、Reporting APIの一つであるEmbed APIのチュートリアルです。


Embed API

Embed APIの用途は、デモサイトを見るのが一番早いです。
例えば 1. Basic Dashboard にアクセスをして、Google Analyticsを利用しているアカウントでログインすると、以下のようにセッション推移のグラフを表示できます。(このブログのSession数が少ないのはさておき。。)

 

f:id:a2kichi:20140915143317p:plain

 

Google Analytics Embed API チュートリアル

このチュートリアルでは、以下のような画面を出力するアプリを作成するのがゴールです。

f:id:a2kichi:20140915143833p:plain


1. Client ID(APIへのアクセスキー)の作成

APIを利用する前に、まずClient IDを作成する必要があります。

前提として、Google APIのアクセスポリシーとしては、以下のようになっています。

  • 公開データへのアクセス : API key (Client ID)でアクセス可能
  • 非公開データへのアクセス : OAuth 2.0 認証が必要

今回利用するデータは、サイトへのSession数といったプライベートな情報になります。なので閲覧者はグラフを表示する前に、画面上のログインボタンからOAuth 2.0 認証(Googleへのログイン)をする必要があります。(アクセストークンを取得してアプリに保持すれば、その認証プロセスも省けそうですが、今回はそれはやりません。)

 

手順は下記です。 

こちらにアクセスをして、プロジェクトを作成する

f:id:a2kichi:20140915144930p:plain

プロジェクト作成後、Analytics API をONにする

f:id:a2kichi:20140915145116p:plain

クライアントIDを作成する

f:id:a2kichi:20140915145317p:plain

 

今回は、localhost:3000でEmbed APIを動かすアプリを作ったので、AUTHORIZED JAVASCRIPT ORIGINSをlocalhost:3000にします。

f:id:a2kichi:20140915145449p:plain

 

2. 認証画面の設定に、EMAIL ADDRESSとPRODUCT NAMEを設定する

ログインボタンを押した際にでるポップアップのOAuth 認証画面の設定です。

f:id:a2kichi:20140915145721p:plain

 

こちらを設定しないと、閲覧者が認証をしても、下記のようなエラーになってしまいます。

invalid_client
no application name 

  

3. アプリのViewにチュートリアル用HTMLをはりつける

作成したアプリのViewにチュートリアル用HTML(+ Javascript)をはりつけ、CLIENT_IDを先ほど作成したClient IDに置き換えれば完了です。

 // Step 3: Authorize the user.

 

var CLIENT_ID = 'Insert your client ID here';

 

Railsのソースは、GitHubにUPしてみました。(今後拡充していく予定です)

 

チュートリアル完成後の画面

WEBrickでRailsを起動させ、ブラウザでlocalhost:3000 にアクセスして、上記の流れで作成したアプリを確認してみます。

 

初期画面はAccess Google Analyticsのボタンだけです。

f:id:a2kichi:20140915150054p:plain

 

ボタンを押すとOAuth認証のポップアップがでます。

f:id:a2kichi:20140915150128p:plain

 

承認すると、最初に紹介した画面を見ることができました。

f:id:a2kichi:20140915143833p:plain

 


以上、今回は初歩的なところをまずやってみました。

今後は徐々にこの手のネタを展開させていく予定です。

 

 

 

機械学習の初心者がAirbnbのリスク管理について調べてみた

Airbnbというサービスをご存知でしょうか?

世界中の魅力的な家に泊まれてしまう素敵なサービスです。サンフランシスコ生まれ(育ち?)のスタートアップ企業が提供しています。

素敵なサービスですが、見ず知らずの人の家に見ず知らずの人が泊まることができるので、安全面どうなんだろう?とちょっと気になるサービスでもあります。

宿泊先で事件が起きたりすると、信用面でビジネスへのダメージは大きいです。その辺のリスク管理が重要なサービスだと思います。

 

リスク管理に機械学習を利用

安心して宿泊先を登録・利用してもらうため、Airbnbではリスク管理の一部に機械学習を利用しているようです。

機械学習が利用されるシーンとしては、例えば

  • 特定の地域で、普段の10倍の予約があった場合、詐欺の可能性が高いので検知してフィルタにかける。
  • クレジットカードの払い戻し要求の詐欺を検知する。

といったことに利用されているようです。

 

Airbnbのスコアリングフレームワーク

詐欺の手口は巧妙化してきているため、様々なケースを柔軟に追加できるアーキテクチャが要求されます。Airbnbでは下記のアーキテクチャで実現しているようです。

 

 

https://dchtm6r471mui.cloudfront.net/hackpad.com_86HnsLzAU5J_p.42337_1402006057128_undefined

 

ユーザーが宿泊先の予約を作成した場合の流れを例に説明します。

MAIN APP(Aribnbのアプリ本体)

宿泊先の予約が発生したら、FRAUD PREDICTION(詐欺検知)にクエリを投げる。 

FRAUD PREDICTION(詐欺検知)

「予約作成」のモデルに対して、検証用データを作成してOPENSCORING(機械学習を利用したデータの検証ロジック)に投げる。このときの検証用データとしては、どの場所でどのタイミングでどういった人が予約したか?そのときの周りの状況はどうか?といった内容だと思われます。負荷軽減のために、クエリの非同期化、DBリクエストの並列化などを行っているようです。

OPENSCORING(機械学習を利用したデータの検証ロジック)

受け取った検証用データをもとに、その検証スコアと、設定した閾値による判定(詐欺か、通常のユーザーか)をFRAUD PREDICTIONに返す。FRAUD PREDICTIONは、受け取った判定をもとにアクションをする。(例えば、詐欺であれば予約を差し止めるなど。)

ここではJSON REST形式のJavaのライブラリ(JPMML:Java Predictive Model Markup Language )が使われています。Predictive Model Markup Language (PMML)とは、Data Mining Groupが策定した、異なるデータマイニング製品間で分析モデルの交換・共有を可能にするXMLベースの言語です。PMMLについては、この辺のブログがわかりやすかったです。サポートしている機械学習のロジックとしては、tree models, logit models, SVMs, neural networks などで、Airbnbではrandom forests, kafka logging, statsd monitoringなどを利用しているようですが、この辺はさっぱりなので、後々勉強していったらログ残したいと思います。。

 

アーキテクチャを作るにあたってのポイント

Airbnbのデータサイエンスのチームによると、下記が大切とのことです。

  • 学習ロジックを組むときの前提を疑うことが大切。
  • どんなデータを検知・検証したらいいかよくわからない場合は、とにかく全部のデータを残しておくと良い。残しておけば、将来いつでも取り出せる。
  • 急成長のスタートアップ企業ではどんどんモデルも変わってくるので、それにロジックをあわせていくことが必要。 

 

下記に参考として元ネタを張りましたが、興味が湧いた方はそちらを参照するとより突っ込んだ内容が書いてあります。自分としては機械学習についてまだまだなので、買い置きしっぱなしだったこの辺の書籍などをまずは読んで勉強ログなどをUPしていければと思います。 

 

[参考]

Architecting a Machine Learning System for Risk - Airbnb Engineering

 

コーポレートブログをカイゼンする7の視点

f:id:a2kichi:20140831172513j:plain

 

これからコーポレートブログを書こうとしている方、今書いているけどもトラフィックがなかなか増えないとお困りの方のための、7つのポイントです。

 

1: ニッチを攻める

自社サービスに関連した一般的なコンテンツを提供するより、自社サービスの顧客の助けになるコンテンツを提供た方がよいです。

よいコンテンツの例

GROWTH HACK BLOG(グロースハックブログ) by KAIZEN platform |

 KAIZEN platformは、ABテストのツールのplanBCDというツールを提供していますが、自社のツールの利用者、または将来の利用者を想定した記事ばかりが書かれています。

 

2: メジャーなブログメディアに寄稿する

コーポレートブログのトラフィックが十分でない場合、良い記事を思いついたときは自社のブログに書かず、メジャーなブログメディアに寄稿して、自社ブログのリンクをはってトラフィックを流したほうが効果的です。

メジャーなブログメディアに寄稿するには、例えばそのメディアの主催・協賛するイベントなどに赴き、担当者とつながって記事を提案するなどの手があると思います。

 

3: 読者を教育する

コンテンツをただで提供し続けると、読者はただでもらうことに慣れてしまうので、何かアクションをしてもらうことを学習してもらうのが効果的です。ただ、慣れる前にドロップしてしまうリスクもあるので、程度の調整が必要だと思われます。

ブログの読者を自社ECサイトに訪問させて購買までつなげたい例
  • ただでEブックなどのコンテンツをあげるのではなく、コンテンツをよむにはEメールを登録しなければならないようにする。読者は情報を得るために、何かを差し出さなければならないと学ぶ。
  • Eブックをメールで送るのではなく、コンテンツをWeb上において、リンクをメールするようにする。読者は情報を得るために、クリックしないといけないと学んで、「買う」などのボタンを押しやすくなる。
  • 毎度コンテンツをシェアしてもらうようにする。読者はコンテンツに対してお礼をすることに慣れてくれる。


4: 書き続ける

自分のブログやSNSで既に感じていると思いますが、書くのをやめるとトラフィックはすぐ落ちてしまい、とり戻すのに時間がかかります。

 

5: 読者のコメントに返答する

コメントに返答すると、リピーターが増えます。ワンピースSBSと同じ要領ですね。

 

6: SNSを利用してトラフィックを加速する

自分でシェアするだけでなく、同僚や友人にもシェアをしてもらうとより広がります。(うざくない程度がよいと思われます。)また、Facebook広告は現状では費用対効果が高いので、出稿するのは効果的です。

 

7: 早くマネタイズする

早いうちからマネタイズをすると、下記の点からよいです。

  • 機会損失がなくなる。
  • 顧客に対して、ブログが現在どういう立ち位置にいるのかを確かなものにしてくれる。


[参考URL]
http://www.quicksprout.com/2014/08/25/corporate-blog/