トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

トレタはRubyKaigi 2017に参加しています

サーバーサイドエンジニアの芹沢です。広島のホテルでこのエントリを書いています。

トレタはSilver SponsorとしてRuby Kaigi 2017にスポンサードしています。
また、トレタからは私を含むエンジニア3名とCTO増井が参加しております。

トレタはスポンサーブースは設置しておりませんが、増井が会場中を歩き回っておりますので、会場で見かけたらお気軽に話しかけてみてください。

f:id:serihiro:20170918102225j:plain

また、今回参加するエンジニア3名がそれぞれこのブログにて参加レポートを書く予定です。
そのレポートの中では、事前に決めた各自の担当セッションについて解説する予定です。こちらもご期待ください。

さきほど初日のセッションが全て終了しましたが、とても濃いセッションが多い1日でした。

ruby commiterであるnobuさんのruby開発生活を紹介するキーノートから始まり(nobuさんのトークはruby界隈では大変貴重です)、

  • RailsにおけるAPI開発のトレンドの移り変わりと最近の取り組み
  • productionで動作しているRails appを用いたベンチマーク環境の構築
  • opalでdruby対応した話
  • web application frameworkであるhanamiの紹介
  • pycallの紹介とデモ
  • 去年もすごく盛り上がったruby commiters vs worldのコーナー

という、以前から興味のあった話題が沢山聞けてとても楽しかったです。(英語トークもあってとても疲れましたが。。) 残り2日も楽しんでいきたいと思います。

f:id:serihiro:20170918184154j:plain

トレタにおけるBigQueryの活用法について

サーバーサイドエンジニアの芹沢です。

トレタは検索用のデータストアとしてBigQueryを使用しています。 奇抜な使い方はしていませんが、トレタにおけるBigQuery活用法を紹介します。

システム構成

BigQuery周りのシステム構成を1枚の図にまとめるとこんな感じです。珍しいものは使っていませんがその分安定した構成かと思います。

f:id:serihiro:20170530163636p:plain

BigQueryにimportしているデータ

大きく分けて以下2種類のデータをBigQueryにimportしています。

1.APIが参照しているRDBのデータ

APIが参照しているRDB(Amazon Aurora)のslaveからデータをimportしてデータ分析や調査用のデータ検索業務に使っています。

2.各種ログ

以下のログをfluentdでBigQueryに保存しています。

  • nginxのaccessログ
  • railsで1リクエスト単位で出力しているカスタムログ
  • sidekiqのログ(Sidekiq.loggerが出力するログ)
  • shoryukenのログ(Shoryuken.loggerが出力するログ)
  • sendgridのメール送信ログ

sendglidのログについては過去に佐野おにいさんが解説記事を書いていますのでこちらの記事を参照ください。

tech.toreta.in

データ可視化ツールとしての活用

社内向けのデータの可視化にはRedashを使い、用途別のDashboardを作成してセールス、カスタマーサポート、マーケティングチームが普段から追っている数値をエンジニアに頼らず検索できるようになっています。

また、BigQueryに入れたログをグラフで描画するなどのエンジニアリング方面でも使用しています。

f:id:serihiro:20170530161120p:plain

Redashの導入についてはaccountの権限管理など色々とハマりどころがあったようなのですが、その辺の話はRedash導入をリードしたサーバーサイドエンジニアの中村君がこのブログに書いてくれると思います。

データ集計基盤としての活用

最近トレタのRDBにたまったデータを活用する機運が高まり、データの集計や分析を行うようになりました。(今はどちらかと言えば集計と可視化がメインですが)

何かデータを使ってやりたいことがある時、試行錯誤段階ではRやPython + Jupyter Notebookで少量のデータを対象に前処理や集計をするのですが、それをproductionの全データに適用すると、処理時間がかかりすぎて丸1日かかってしまうといったケースが増えてきました。

そこで、複雑な集計処理や重たい処理はなるべくSQLに落とし込んでBigQueryで処理するようにすることで解決を図っています。

例えば、普通にコードで書くと全件ループせざるを得ず数十秒かかるような集計処理でも、WINDOW関数などを駆使してSQLに落としてこんでクエリを投げると、何事もなかったように数秒で結果が返ってきます。1回のクエリで処理できるデータのサイズに上限があるため、あらゆることが1回のクエリで解決する訳ではありませんが大抵は問題なく実行できています。
余談ですが、pythonのデータ分析ライブラリのpandasには、BigQueryにクエリを投げて結果をdataframeに変換して返す処理をread_gbqという関数一つで実現できるので大変便利です。

SQLに寄せる最適化を進めた結果、bqコマンドラインツールでクエリを投げて結果を別のテーブルにimportするだけで完了する処理も出てきました。BigQueryのUDFはまだ使っていないのですが、UDFも活用すればさらにscript less化が加速するのではないでしょうか。

なお、トレタではこういったデータエンジニアリングや、ビジネス方面のアナリティクスが得意なデータサイエンティストを募集しています。こちらもよろしくお願いします。

www.wantedly.com

ログ検索基盤としての活用

sidekiqとshoryukenのログ本文には、Workerの名前、ジョブのIDやステータス、実行したスレッドのIDなどが含まれています。これらの情報をキーとして利用しやすいにように、parseして構造化する必要があります。また、個人情報を出力することもあるため、マスキングも必須です。

これらの課題を解決するため、LogのFormatterを独自のものに置き換えて運用しています。現在は以下のようなjsonのformatでログを出力してBigQueryにimportしています。

{
   "datetime":1472553986,
   "hostname":"sidekiq-server",
   "pid":"17863",
   "tid":"owww1vp08",
   "severity":"INFO",
   "worker":"TestWorker",
   "jid":"JID-08102742edd82acc5b698f7e",
   "job_action":"done",
   "processing_time":10.000,
   "formatter_err":null,
   "message":"{\"class_name\":\"String\",\"body\":\"done\"}",
   "log_version":1
}

Sidekiq.loggerinfo , error 等のメソッドの引数に渡されたデータは messageというキーにjsonとして格納されるので、BigQueryのJSON関数を使ってカラムに展開した一時VIEWを作成し、そのVIEWに対してクエリを実行することでメッセージの本文で絞り込むことが可能です。

例えば、過去10日間のログの中からerrorという文字列がmessageに含まれるものを検索したい時は、こんな感じのSQLで取得できます。

#standardSQL
WITH
  MESSAGE_EXTRACTED AS(
  SELECT
    TIMESTAMP_SECONDS(datetime) AS UTC_DATETIME,
    worker,
    JSON_EXTRACT_SCALAR(message, '$.class_name') AS mesasge_class_name,
    JSON_EXTRACT_SCALAR(message, '$.body') AS message_body
  FROM
    `sidekiq_logs*`
  WHERE
    _TABLE_SUFFIX BETWEEN FORMAT_DATE("%Y%m%d", DATE_SUB(DATE(CURRENT_TIMESTAMP(), 'Asia/Tokyo'), INTERVAL 10 day))
    AND FORMAT_DATE("%Y%m%d", DATE(CURRENT_TIMESTAMP(), 'Asia/Tokyo')) )
SELECT
  *
FROM
  MESSAGE_EXTRACTED
WHERE
  message_body LIKE '%error%'
ORDER BY
  UTC_DATETIME DESC
LIMIT
  1000

まとめ

簡単ではありますがトレタにおけるBigQueryの活用方法について紹介させていただきました。
ビジネスにおけるデータ活用の重要度が日々高まる昨今、トレタもデータから得た知識を活用してビジネスを加速させていきたいと思います。

UX Days Tokyo2017に参加しました

トレタデザイン部の佐野 彩です。

先日行われたUX Days Tokyo2017というイベントに参加しました。 ニュースを流し読みするだけでは得られない、デザイナーの視点からの最新情報にまとめて触れることができる3日間でした。

2016年に起きた数々の事件が影響してか、UXというバズワードのみで捉えずに、心理学やモラルまでも踏まえた深みのあるセッションが多かったのが印象的でした。 それはもはやUXデザインがバズワードではなくなり常識になったことを示すのかもしれません。 とにかく1日でものすごい情報量に触れることができました。

まずは最初にカンファレンスの報告からいきたいと思います。

1. 計測のさらに先を読む(エリカ・ホール)

人間は完璧な存在ではありません。 データドリブンが良しとされがちな開発の現場で、デザイナーは数字に意味を見出す場合に気をつけるべきはどんなことかを問いかける発表でした。

カンボジアの国民病 貧血を改善した事例

データは物語があって初めて意味をなす、という話。

● 貧血を直すのには鉄分を摂取しなくてはいけないが、ただの治療用鉄石を配るだけでは全く状況が改善されなかった。 ● 人々の生活を観察して馴染みのある形に改善。製品の形にストーリーを加えて説明、やっと使ってもらえるものになった。

データは物語があって初めて意味をなす、というサービス開発にも活かせるエピソードですね。

定量と定性の罠

定量だけでは真実が見えない、定性だけでも真実が見えないという話も興味深かったです。

● 人間の合理的な理解能力には限界があり、人間の脳にはまず自分を考えてしまうというトラップがあるので、気分や偏見などのパターンに勝手に当てはめて数字を見てしまうのが定量の限界 ● 定性の限界はインタビュアーや観察者に依存してしまうこと。 また、簡単にできることを正しいと思いこみがち、大抵グラフにして満足して終わりになってしまう、という指摘も。

人間は不完全であり、それを認識するには脳の特性を知り、偏見にとらわれないで良い質問を繰り返し、クリティカルシンキングをすることが大事だということでした。

2. AI時代の倫理(ケニー・ボウルズ)

サービスを成長させるとなると必ず社会的責任がセットになり、企業側の倫理が問題になります。 去年だけでも、AI(人工知能)がいくら便利とはいえ、設計者が倫理についてルールを持たないと直接的なマイナスの影響を社会に及ぼす例がいくつも示されました。

2016年の例

  • マイクロソフトがTwitterアカウントとして運営していた人工知能のTay(差別発言)
  • カメラアプリの皮膚色変更スタンプ(人種差別的)
  • Facebookのお祝い機能(悲しい記憶に結びつくものをお祝いで出してしまう)
  • 配車サービスのUberやLyft(乗車拒否・差別)

技術は中立ではない

現在の日本に暮らしているとあまりデザイナーが倫理規範はどうあるべきかを議論する光景は目にしませんが、 モノにインターネットや人工知能が実装され、デザイナーが体験設計に関係する場面が増え、そこには人命も関わると認識されていくにつれ、日本でも議論が活発化するのではないでしょうか。

3. フリクション(ステファン・アンダーソン)

フリクションとは衝突・摩擦、という意味です。 ユーザービリティが悪いことで生じる摩擦は絶対悪なので無くしましょう、と語られることが多いですが、 プロダクトにおいて摩擦や衝突が起きるシチュエーションについて多様なコンテキストを踏まえて深堀りしましょうというセッションでした。6つのフリクションのうち、興味深いと感じたものを数点挙げてみます。

内省的フリクション

  • 表面化していないフリクション。支払いステップの最中にパスワードが必要になりそこからパスワードのリセットプロセスに入り・・・など。

境界フリクション

  • デバイス間の断絶による摩擦のこと。様々な改善例があるが、テレビの画面をハンドジェスチャーでキャプチャしてSNSにシェアするアイデアが面白かったです。
  • この改善にはExperience mapなどにデバイスのタッチポイントを記入することが助けになります。

学習的フリクション

  • 意図的なフリクション。摩擦があることで理解が向上したり損害の防止になるもの。
  • ゲームアプリなどにおいては学習が楽しい体験ということも言え、課題を乗り越える楽しさをデザインするのがゲームデザインとも言える。
  • どうしても困難な保険商品を選ぶ場合でも、困難だということを学ぶことで最善と思える選択をすることはできる。

4. 正しいMVPと顧客の学習(メリッサ・ペリ)

スピーカーが報告していたように、LeanUXを実践しようとするときに一番難しいのがMVPをどう定義するかということだと思います。 私も同業他社の方と話していて「MVPは無理だ」「とにかく出すことが重要だ」という両極端な考えをよく聞いた覚えがあります。

ここでのMVP定義とは

  • ベンダーとユーザーに最大のリターンがあるものをMVPと呼ぶ

となると、お客さんの本当に必要としていることを学習する必要があるし、本当に乗り超える問題があるのかを学習し、実験してそれを明らかにしなくてはいけないということを様々な例から学ぶことができました。

上手くいった例

  • HiFlyの例。航空会社が路線のニーズがあるか実験するときに使う乗り入れ航空機を出す会社。(事業と実験そのものがMVPになっている)
  • airBnBの例。良い写真がないせいでユーザーから申し込みが来ないとわかっていたので、カメラマンを雇う代わりに自分で良いカメラを買って写真を撮り乗せた。 などなど

必要とされているかをまず実験し、上手くいったらスケールさせる方法だと認識すると、チームの中でも意識が統一できそうだなと思いました!

5. 対話型UIの設計(ジャイルズ・コルボーン)

次世代インターフェイスとしてChatBotや音声入力が話題になりがちですが、本当にどんな場合でも便利なのでしょうか? Amazon echoやAlexaを例に挙げ、ユーザーのコンテキストを理解した提案を対話を踏まえ提供することこそが「人間的」なのではないかということでした。

次世代型インターフェイスの落とし穴

  • 人間の心は複雑なのでトラッキングする必要があり、人間側のコンテキストに対応する必要がある
  • マナーやエチケットを理解したインターフェイスである必要がある
  • 状態を人間に伝えることで安心してコミュニケーションが取れると人間側が間違えを起こしにくい。 などなど。

人間同士での会話のようにデバイスと会話でき、簡単に物事が済むとしたらとても便利ですね。

f:id:ayasano:20170428141804j:plain

会場の様子。休憩時間にAdobe XDのデモが実施されました。

私の感想

ユーザーを理解し、最適解を提供しよう、という意味でのUXの提唱ではなく、現場でUXをデザインする上でさらにより良くするためには心理学、倫理、脳科学など幅広い知識が必要になってきているという意味で、デザイナーが学ぶべきことはまだまだあるのだなと実感しました。深い学識の裏付けを備えたスピーカーばかりで、聞いていて非常に学びが多かったです。 今はサービスやインターネットが当たり前になった上で、インターフェイスが切り替わり、私たちの生活が変わる過渡期ならではの難しさがあるということなのかもしれません。

次回記事ではワークショップの感想をお送りします。

イベントURL : http://2017.uxdaystokyo.com/

トレタでは、最新の情報にキャッチアップし、考え続けることが好きなデザイナーを募集しています!

www.wantedly.com

© Toreta, Inc.

Powered by Hatena Blog