エンジニアのにのみやです。 トレジャーデータが新サービスを発表するというので行ってきました。 内容については以下のようなメディアで記事化されている他、 トレジャーデータ，新サービスを発表 ─高速クエリエンジンとデータ可視化エンジン トレジャーデータ、POSデータ300億件が30秒で処理できるビッグデータ分析 米トレジャーデータ、DWHのクラウドにアドホッククエリーなどを追加 以下ではパネルディスカッションの様子も詳しく書かれています。 『トレジャーデータ、新サービス発表！〜進化したクラウドデータサービス〜』に参加してきた なので、ここではこのような会に参加したきっかけや個人的な感想等を書いてみたいと思います。 エニグモ にはEG labという制度があり、エンジニアが技術的に興味があることを試したり作ったりすることができるようになっています。(参考:  金曜は午後フリー？！エンジニアの「やる気」に火をつける。エニグモのスゴい社員モチベート術 ) 以前からこの時間には ビッグデータ 関連のことをやっていました。バイマでは世界75か国に在住する4万5千人のバイヤーが随時出品を行なっており、それらを150万人の会員が購入しています。ここから得られる大量のページ閲覧データや取引データをもとに、商品詳細ページで提示するおすすめ商品を出してみたり(レコメンデーション)、ある商品Xを買った人は別の商品Yも買う傾向にあるといったルールを抽出(バスケット分析)したりするわけです。最初は自社でサーバを用意してCloudera Managerで管理するといったことをしていました。しかし、ラボとして試してみるにしてはサーバ管理といった周辺作業が面倒なのと、バイマの成長に伴ってデータ量も増大していくこと(スケーラビリティ)を考えると クラウド サービスを活用した方が良いということになりました。こうした中でSkytapやJoyent、そしてトレジャーデータのサービスを試用したことがあります。 そのときはウェブサーバのログをtd-agentで拾ってトレジャーデータのサーバに流し込み、ため込んだデータを分集計したりエクポートしました。その際、td-agent設定ファイルに書くログフォーマットについて太田さんとチャットしてカスタマーサポートを受けたことがあります。 今回は、そのトレジャーデータが新しいサービスを発表するというのでどんなものなのか気になったのと、太田さんが話すということなので参加してみることにしました。 新製品として発表されたのは アドホック 解析エンジンのTreasure Query  Acceleratorと可視化ツールのTreasure Viewerです。これまではエンジニア向けの機能しかなかったのですが、ついに マーケティング 担当者や営業担当者も使えるような製品を出してきました。 ビッグデータ 業界ではこのような流れがあるので特に驚きはないのですが、Treasure Query  Acceleratorは スキーマ レスである点が特長だということです。 上の写真はTreasure Viewerを太田さんがデモンストレーションしているところです。 ドラッグ&ドロップ で操作できるなどUIを工夫しているようです。 トレジャーデータを活用している顧客の例として回転寿司チェーンのスシローの話がありました。注文時に使用するタッチパネルのクリック(?)データを分析し、寿司ネタの表示配置を変更したところ売上が大幅に増加したということです。ウェブページのボタン配置最適化と似ています。 PentahoやTableauといった アドホック 分析・レポートツールや、ストリーミングデータをリアルタイムに処理するCEP(Complex Event Processing)は ビッグデータ の中でもアツい分野なので、EG labを活用して今後も注目していきたいと思っています。

エンジニアのおざわです。 エンジニア部門にはラボ制度というのがありまして、 売上とかいいかんじにみんなの見えるところに表示したい という取り組みを行いました。 結果 そうだね、見せられないね。 上の方に数値、下の方にグラフが表示されているのがわかるかと思います。 正直に申し上げますと、 Team Dashboardで目標数字をチームで共有する - komagata  というブログエントリを読んでやってみたいと思ったのでやってみたのです。 そちらのエントリにある通り、 Team Dashboard  というソフトウェアを利用しました。 Jenkins のステータスや Shell Command の実行結果をデータソースに数値やBoolean、グラフを表示したりできるのですが、今回は BUYMA の数値を取得するために http_proxy データソースを利用しました。 http_proxy はその名の通り、Team Dashboard から HTTP でデータソースにアクセスします。結果を JSON で返すと数値やグラフを表示できます。 そのために JSON を返す API をアプリに用意しました。 たとえば、 { " users " : { " total " : 300 , " today " : 10 } } みたいな JSON を返して、以下のように設定すると数値を表示できます。 [ { " target " : " PC " , " datapoints " : [ [ 0 , 1385737200 ] , [ 24 , 1385737800 ] , [ 40 , 1385738400 ] ] } , { " target " : " SP " , " datapoints " : [ [ 0 , 1385737200 ] , [ 65 , 1385737800 ] , [ 94 , 1385738400 ] ] } ] こちらの JSON は、グラフを表示するときに使います。配列の0番目が値、1番目がタイムスタンプです。target の数だけグラフを重ねて表示できます。 グラフの設定も簡単です。 Source を http_proxy にして、 Proxy Url にさっきの JSON を返す API を指定するだけです。Periods 、Targets で指定した値が API のパラメータに渡ってきますので、いい感じに JSON を返してあげてください。 今はこんな感じで執務室入り口の壁に表示しています。 以上、簡単ではありますがチーム ダッシュ ボードの紹介でした。 エニグモ では思いを壁にぶつけたいエンジニアを募集しています。 http://www.enigmo.co.jp/recruit/

EGテックブログを始めることになりました。 技術的なことを中心に、エンジニ アメンバー が持ち回りでブログポストしていきます。 宜しくどうぞ。 先ほどわかりやすく「テックブログ」と書いたわけですが、 エニグモ のエンジニア部門にはService Engineering本部というれっきとした正式名称があります。 その昔、運良く創業メンバーの安藤から声をかけてもらい エニグモ に入ることになったのですが、実は当時の エニグモ は システム開発 は全て外注していました。作れる人がいなかったためです（現在はフル内製化しています。その辺りはまた別途）。 そんな中たまたま一人目の技術系社員として入社しまして、当然一人しかいないので部門も何もないわけですがとりあえず部署名を考えることになりました。 「どうしよっか？」ということですかさずブレストが始まったわけですが、こだわったことは1つ。「システム」という言葉を使わないことでした。 「オヤジが出てきそうな響きで、嫌っすねぇ！」といった旨の発言をした記憶があります。 （語弊がありそうな表現ですがそこは見逃して頂いて）要は一度しかない人生、自分が納得するサービスを自分たちの力で作り上げていきたいという意気込みだけは当時からあったような気がします。 ユーザファーストとかUXとか、最近だとグロースハックとか色んな言葉やテクニックがあり、現に自分も勉強しているわけですが、何よりも大事なことは「自分ならこうしたい」といった情熱だなぁと最近つくづく感じます。 そんなサービスエンジニアリング本部。 エニグモ らしさを大事に、いいサービスを作っていきたいと思っています。 それでは！！