hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

Vue Fes Japan に参加してきました

2018.11.03 にあった、「Vue Fes Japan」に参加してきました。
素晴らしいイベントでした。
セッションだけでなく、ランチとかディナーもすごく評判が良かったみたいです。
スピーカーの皆様、スタッフの皆様、ありがとうございました。

f:id:hirokts:20181104103351j:plain

Keynote

vuefes.jp Vue.js の作者である Evan YouさんによるKeynoteでした。

英語がすごく聞き取りやすかったです。
全部は理解が追いつけなかったので、英語勉強したいと思いました。

内容はVue.3.0についての紹介で、3.0でものすごくパフォーマンスが向上するという感じでした。本当にすごいとしか言いようがない。

以下はメモ内容をそのまま載せていますが、書き間違いなど多々ありそうです。

Vue 3.0 についてのキーノートのメモ(書き間違いあり)

より速く、ちいさく、メンテしやすく、よりネイティブ向けに作りやすく
よりあなたのコードを保守しやすく

  • 仮装DOMの実装をフルスクラッチで作り直し mount, patchの処理が最大100%向上

  • proxyを用いた監視で完全な言語レベル 速度向上

  • 通知の仕組みを作ることができる ES5のGetterやSetterを使っているが、かわりにproxy機能を使うことになる プロパティの追加や削除についても知ることができる

Object.definePropertyはさようなら インスタンスのproxyという概念も登場

  • 実行時のオーバーヘッド削減のため、コンパイル時にヒントを追加

template is static analyzable テンプレートからのコンパイル コンポーネント探索の高速化 子要素数0であることをコンパイラ出力し、スキップする

Just in time optimization

  • スロット生成の最適化

インスタンスが依存関係を正しくトラッキングできるように 不要な親子のレンダリングを回避 Lazy Funcitonという仕組みを取り入れ、 子関数は必要に応じて呼び出される

  • Hoisting (巻き取り)
    • Static Tree Hoisting
    • Static Props Hoisting ノード全体への適用はしない
    • Inline Handler Hoisting

パフォーマンスが2.5から3.0protoで倍以上向上

  • Tree-shaking ビルトインのコンポーネント (keep-alive, transition)

  • カスタムrendererAPI Canvas, iOS, などネイティブ向けの出力を出すために作った

  • コードのメンテナンス性向上 リアクティビティAPI

  • Render Track

コンポーネント countをprop インスタンスを見るとどのようなキーがあり、mutateされたかわかる

  • TSXによるTypeScriptサポートの強化 型によるwarningが表示される

(TypeScriptよさそう)

  • 実験的なHooks API

  • Mixinのサポート 複数のmixinをコンポーネントで使うとネームスペースの問題が発生することがある

hooksはreact.jsのDanさんのプレゼンを聞いて

Vue.js と Web Components のこれから

speakerdeck.com スピーカーはTakanori Okiさんです。 FOLIOに所属しており、ウェブフォントが大好きとのこと。

Web ComponentsはEdge以外でほぼ実装が進んでおり、一気に普及していく見込みとのこと。
Vue.jsとWeb Componentsとの共存方法などについてのお話でした。
Webアプリケーションを作る上で、Vue.jsだけでなく将来的な移行も考えてUIのフレームワークを考える場合、Web ComponentsやAtomic Desginなどの考え方は非常に有用だと感じさせられました。 とても面白かったです。

この講演についてのメモ (書き間違いなどあり)

web標準技術 EDGE以外では動く polyfillを使わなくてもうごかせる

Custom Elements

独自の機能や見た目を持ったHTML Elementを定義できる

Shadow DOM

shadowRoot グローバルのCSS, JSSは影響できない

HTML Template

要素 HTML

HTML Modules

HTMLをJavaScriptをimportできる まだGitHubで議論中 CSS Modulesも

どうやって

来週のVue.js with Web Componentsの勉強会が参考になりそう

Build with Vue.js

Vue CLI 3 BUild Targets

vue/web-component-wrapper

Vueコンポーネントをラップしてカスタム要素として登録する

Example

UIフレームワークを統一したい JavaScriptフレームワークごとに切り替える、とかは効率が悪い

Scopeを制限したい -> Shadow DOM CSS

Demerit

属性値にStringsのみ 外部から渡されるイベントハンドリングが難しい DOM要素の取り回しが面倒 CSSの設計を大幅に見直す必要がある

いまのところ

Vue.jsの機能でコンポーネントを作ったほうがよい

Micro frontend

機能の集合体だとみなす

frontend モノリシック

フレームワークの移行

Web Components UIフレームワーク

Vue.sj = Webアプリケーションを構築するためのフレームワーク UIを作るためのものだけではない

Summary

Web componentsはpoduction ready Vue.jsとWeb Componentsは共存できる UIをWebComponentsに任せることで負債を減らすことができる

Q and A

有用な情報は?

  • Takanori OKiさんによる技術書典本

inutetraplus.booth.pm

  • webcomponents.org
  • よくわかるWebComponents せんすいさん

Vue Designer: デザインと実装の統合

slides.com

Katashinさん自身が開発している、Vue Designerについての紹介
Vueのコンポーネントの見た目のデザインがVSCode上でプレビューしたり、chrome devtoolのようにCSSいじったりできるみたいでものすごく便利そう。 これを使うと、デザイナーさんと一緒に開発するフローで革命が起きる感じがします。

この講演についてのメモ (書き間違いなどあり)

作っているVue Designerはまだプロトタイプ

デザインと実装が分かれている photoshop, adobe xd, sketch

デザイナー

UX, 情報設計、アクセシビリティ、スタイルガイド

開発者

コード設計 状態管理 レスポンシブ アニメーション

デザインと実装が分かれることでおきる問題

デザインはsketch, photoshop 開発は vueファイル

単純に二度手間

検索フォームをデザインせずに実装 デザインに戻すのを忘れると、、、

静的なモックアップ ウィンドウの幅 リキッドにするのか、固定にするのか

Dreamweaver デザインビュー

Vueegg

一回プロトチイプとしてデザインしたものが、Vueにつかえる Vueからは戻せない

FramerX

組み立てたUIはReactのコンポーネントになる Reactから戻せそう

ほしいデザインツール

SFCが実装、かつ、デザイン 長期開発、運用

デザイナー向けにするとUIを作りこむのが大変

直近の目標

まずは開発者が使って便利なもの GUI完結ではなくコードを併用

vscode上でVueコードを表示

GUI上であたっているスタイルを編集できる コード上に反映

データを入れて確認もできる 例:ボタンのコンポーネントはlabelというpropsを持っている labelに"test label"を入れた場合

サーバー側にSFCを持っている SFCをパーサーでASTに変更 WebSocketでクライアントに渡す クライアント上でレンダラーでVSCodeGUIに表示

GUI操作はWebcomponentsから逆パーサーにわたし、コードに反映

プレビュー上でデザイン デザインが動的

SFCの静的解析

パーサー自体は自前じゃない

vue-eslint-parser

babel/parser -> jsのブロックを解析 TypeScriptにも対応

postcss

AST プレビューのレンダリング 意味解析 props / data 当たっているスタイル importしているコンポーネント GUI上の操作と対応づけ コード編集・生成

プリプロセッサ

TypeScriptのみサポート

Vue Designerはオープンソースでやっている

プレビューはVueのレンダラーを再実装している Vueのテンプレートコンパイラーと同じことをやっている 描画するだけじゃなくて、任意の処理を挟めるようにしたい ドラッグ&ドロップなど 要素間のマージンのピクセル数を表示したい なので、再実装

たいへん

意外にエッジケースが多い Vueのレンダラを使う方法も模索したい

Vue3.0カスタムレンダラ を使いたい

サーバークライアント構成

プレビュー上で何か操作したら、コードに反映

VSCodeのWebViewが想定していない使い方 エディタの中のプロセスとコミュニケーションをとるのがリッチじゃない サーバーとクライアントにして、WebScoketで通信するほうが楽だった 今はVScodeのWebViewはもっと使いやすくなっている

debugがらく Chrome dev toolsつかえる

開発者が使って便利なものにしたい

1.0.0にむけて

Chrome devtools on VSCode

レイアウトできるツールにしたい 大まかなレイアウトを作るときはVue上でやりたい

npm installするだけでデザインを組み立てられる elment-vuetify quasar-framework vuesax

デザイナーと開発者がGitHubで同じコードを編集 すごく楽しい

コンポーネントカタログ 自動生成 右側から出てきたドロワーに一覧があった

Nuxt.js 2.0

Nuxt.jsの開発者である Sébastien Chopinさん自身によるNuxt.js2.0の紹介でした。 こちらもすごかった。 日本語での通訳も出ていたんですが、もっと英語勉強して普通に聞き取れるようになりたいと感じました。

内容としてはデモが非常に多く、ついていくだけで精一杯であまりメモは取れなかった感じです。

この講演についてのメモ (書き間違いなどあり)

Nuxt.jsを使うパターンの紹介

ブラウザー:リクエスト -> Nuxtサーバー:リクエスト-> APIサーバー
APサーバー:json -> Nuxtサーバー:HTML -> ブラウザ

  • serverside rendering and client navigation

  • 静的ファイルの生成パターン

ブラウザ リクエスト サーバー HTML+js

  • SPAパターン

Nuxt.js 2.0

webpack4 + babel7

CLIを改善

Webpack Bar DEBUG=nuxt consola

より速いBuild

コードスプリッティングの制御

build.splitChunksを利用

バンドルの分離

クライアントサーバーを分離できる

Nuxt-start

ランタム限定 軌道速度2倍

ESM対応

ESMモジュールサーバー ミドルウェア

Nuxtjs 2.3.0 coming soon

モダンブラウザー向けビルド

nuxt build --modern

内部リファクタ

note のフロントエンドを Nuxt.js で再構築した話

note.mu 福井 烈さんによる発表

noteRails とAngular.js 1系のSPAから、BFF を Nuxt.js(Vue.js)に移行していっているお話でした。 RailsAPIのみにとどめて, RederとclientナビゲーションをNuxt.jsとVue.jsに置き換える話は自分のやっていきたい開発としても、とても参考になる感じです。
AtomicDesignを活かしてコンポーネントを開発していく話もあり、過去に一旦挫折したStorybookをまた復活させたという話が響いた人も多かった模様でした。

この講演についてのメモ (書き間違いなどあり)

(メモよりもリンク先のスライドを読んでいただく方がいいと思います。)

noteを最初に開発した当時、react, vue はversion 1にもなっていなかったためAgular.jsを採用

課題

  • SSRをサポートしていない
  • 表示速度

フレームワークリニューアル

Vueを選んだ理由

  • 実行速度と開発効率の両立
  • SSRサポート

  • 学習コスト デザイナーもHTMLでかける Angularjsと書き方が近い

  • 日本語ローカライズ版が用意されている

  • コミュニティが活発

Vue.jsのエキスパートがコンサルに

@kitak - 実装のQA - 設計サポート - ハンズオン開催

Nuxtのきっかけ

VueでSSRするのに簡単

pages配下にコンポーネントを置く
asynccData()/ fech()で必要なデータを定義取得する

  • RailsAPI
  • View層だけをNuxt.jsに

開発体制

  • エンジニア3名
  • デザイナー2名

現時点でのパフォーマンス比較

  • Lighthouse 3 -> 41
    のこりは画像の最適化が大半

  • WebPageTest

開発環境

  • Nuxt 2.2.0
  • Jest
  • Eslint
  • Prettier (formatter)
  • Circle CI
  • Sentry

Vuexの主なルール

  • モジュールモード
  • mutation/actions/gettersのタイプには定数を使用
  • 状態管理に秩序

Vuexモジュールの肥大化

  • Nuxt.jsの新モジュールでリファクタ 半分以上がactions

  • 機能単位でモジュール分割

Atomic Design

アトミックデザインの書籍 と 菅原さん Vue.jsからみたAtomic Designの記事が参考になる

Atomic Desginの課題

Storybookを使っている

Nuxt.jsと設定周りを合わせるのが大変で 過去に挫折 廃止したものを復活した

Storybook webpack4対応 Nuxt2.0でいける
(挫折した時点より使えるようになっていた)

ユニバーサルJavaScript

  • クライアントでもサーバーでもどちらでも実行できるJavaScript
  • SSRは対応必須

DocumentAPIを使っているもの

ssrを使うときだけjsdomをグローバルに入れる

SSのライフサイクル

サーバーサイド、クライアントサイドどちらも通るライフサイクルを押さえる

Polyfill

Polyfill.io UserAgentごとに必要なpolyfillを選べる FastlyのCDN

Serverless

AWS Lambdaの上でNuxtを動かしている

Serverless Framework

過去の構成:EC2 + Node.js + pm2
ぜか突然pm2がおちる

Lambda + Nuxt

LambdaでExpressが動かせる nuxtはExpressのミドルウェアとして動かせる

クラウドフロントでリクエストを受けて ELB経由でRailsに飛ばすか、APIGateway経由でLambdaに飛ばす

まとめ

  • パス(URL)ベースで小さく移行するのは有効
  • SSRの導入は簡単
  • 導入は簡単だが、学習運用コストは上がる

  • 環境基盤のサポート、規約が非常に強力

  • プラグインミドルウェアのサポート

  • 技術的制約

  • 採用して良かった

#### 内容と関係ないですが

yatteiki.fm

この講演のあとに、Yatteiki.fmの@9mさんに声をかけていただきました。ありがとうございました。 たまたま自分がYatteikiパーカー着ていたのですが、となりに@9mさんが座ってました。。。全然気づかなかった。

1年間単体テストを書き続けた現場から送る Vue Component のテスト

speakerdeck.com

土屋 和良さんによる発表でした。 Atomic DesignのStorybookも活用しながら、Vue ComponentをVisual Testingするのが最高という内容だったと思います。

この講演についてのメモ (書き間違いなどあり)

(メモよりもリンク先のスライドを読んでいただく方がいいと思います。)

何をテスト

Componentのテストもそうでないテストも考え方は一緒

@t_wada プライベートメソッドはテストする必要がない 外部から見た振る舞いのテストじゃない

  • テストするとき マウントするのか、シャドウマウントするのか

  • シャドウマウント はchildコンポーネントコメントアウトするものとおなじ

  • Snapshotテスティング DOMの変更 差分がなければ通る
    フェイルした後に意図的な変更ならば、そのスナップショットを新しいExpectedに

Visual Testing

CSSもテストしたい

Visual TestingはSnapshotTestingの画像版

私が採用した最高のtesting

Visual Testing

Storybookを使う スクリーンショットはzisui 比較はreg-suit

vuexに依存しているcomponentはstoreを準備するのが面倒 対応策は
- PresentationalとContainer Componentにわける - 汎用的なmockを用意していく

Storybookがあるとvisualtestしやすくなる

QAでのE2Eもやらないのか、ということについての質問
CypressなどのE2Eでエッジケースまで対応するのは大変 APIをどうするかなどの問題を回避するためにもコンポーネント単位でテストをしたい、とのこと

Guildworks 勉強会「新しい技術を取り入れるための実験のやり方 〜サーバーレス・機械学習・PWAを実戦に投入するまで〜」に参加しました。

2018.06.12に開催された表題の勉強会に参加しました。 会場はアカツキさんです。

guildworks.doorkeeper.jp

発表者: ギルドワークス 前川さん

内容としては、「新しい技術を取りいれるための実験のやりかた」というお話で、ほぼ1ヶ月の期間で自社の内製プロダクトに新しい技術を3種類取り入れたというお話でした。

以下はかなりの概略ですが、個人的にメモした内容などです。

取り入れられた技術は以下の3つ

  1. Java on Lambda で作成するサーバレスアプリ
  2. iOS + Android + PWA 3プラットフォーム のアプリケーションを Ionic で開発する(20分)
  3. 機械学習サービス(Saas型)

新技術だとQCDSそれぞれにリスクがあり、漸進的な改善と根本的な改善をという2パターンでの導入が考えられるが、それぞれ「根本的な改善ができない」「ゼロからのリスタートになる」というリスクがある。

リスクを抑えた上で根本的な改善をしたいので次のような手段をとった

  • 新規自社プロダクトのMVP開発で小さく試す
  • 認証など、Saas化して外に出せるものは出す

Java on Lambda

話を聞いているとCognitoを利用した認証管理がすごく楽にうまくいったという感じが伝わってきました。

一番難しかった問題は、「ステージングをどう作るか?」ということみたいで、それはデータストアとして「DynamoDB、アノテーションベースでテーブルを定義している」というところに原因があったところみたいです。

IonicによるPWA

IonicをつかったPWAのメリットは「ドキュメントが非常に丁寧」ということと「CLIによるサポートが充実」しているということらしいです。 とくに「CLIを使うと定型作業がミスなく」というところ

この話題での難しさは、「Ionic標準からはずれるようなUIの作成は高コスト、レールから外れると大変」とのこと。 その場合は、標準のカスタマイズよりもWeb技術で作ってしまうのが早い

機械学習の導入

導入するときにぶつかる問題に以下の2つがある。

  • データセット足りない問題
  • 技術的ハードル高い問題

前提知識が不必要なSaas機械学習をまず、利用してみた

AWS/Microsoft/Google それぞれ用意されている

今回はGoogleでのトライ、Google日本語対応状況がよいとのこと

言語に対する解析として、以下のようなものを利用できた。

  • エンティティ
  • 感情
  • 文法 (ちょっとこれについてはメモミスかも)

感想

「リリースを前提に置くことで、より大きな舞台で活用していくのにも有用な知見が得られた」というところが印象的でした。 あとやはり1ヶ月程度でこんなに実験的に新技術を試せるのはいいなと思いました。 個人的に気になるのはPWAとCognitoかなぁ、と思いました。

発表者の前川さんと会場のアカツキさん、ありがとうございました。

Kubernetes Djangoチュートリアルのメモ

2018.05.26時点の情報です

Running Django on Kubernetes Engine  |  Python  |  Google Cloud

ローカル コンピュータでアプリを実行する

ハマりポイント

まずposgresqlがローカルでポート5432で動く前提になっている
Macならbrew install posgresqlなどでインストールする必要あり
ubuntuwindowsでも同じだろう
後、gcloud sqlと同じようにユーザとDBを作らないといけない

また、pipでインストールするrequirements.txtを見るとDjango 2.03となっているが、2.03ではmiddlewareのsettingが間違っている
詳しくはこの辺りを読む

stackoverflow.com

Middleware | Django documentation | Django

とりあえず、公式の通り 'django.contrib.auth.middleware.SessionAuthenticationMiddleware'

を入れないようにしないといけないところが落とし穴

GCPもk8sも全く関係なかった

追記

この記事だけだと片手落ちなので、tutorialのリポジトリにプルリク出しました。

approveがつけばマージされるそうなので、それを待つ感じみたいです。

カイゼン・ジャーニーと合宿する学習組織の強さ

むきなおり合宿

カイゼン・ジャーニー第16話の「チームとリーダーの境界」では、むきなおり合宿というプラクティスが取り上げられている。
振り返りでは過去の経験を生かして次のサイクルを良くするということができるが、それゆえに今までの方向性にひきづられることが多い。
むきなおりでは、「インセプションデッキ」など、前提になる大元に対しても修正を加えるので、そうした方向性もただすことができる、ということなのだろう。

むきなおりの手順は以下の通り

  1. ミッションビジョンを点検する
  2. 評価軸を洗い出し、現状を客観的に見定める
  3. 評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す
  4. 「課題解決」のために必要なステップを「バックログ」にする
  5. バックログ」の重要度と、一番効果の高いものを決める
  6. 時間軸を明らかにし、期限も明確に決める

詳細は実際にカイゼン・ジャーニーを手にとって確認してほしい。

こういったむきなおりに対して「合宿」を効果的に使えることが、カイゼン・ジャーニーの著者ふたりの強さだったり、市谷さんのGuildworksの強さだという感じがしている。

新井さんのこのスライドの合宿のところを見てほしい。
本の執筆のために、10月から2月にかけても4回も合宿している。

speakerdeck.com

市谷さんのスライドでとても印象的だった一節に

忠誠を誓う対象は、 アジャイルでも、 技術でも、 クライアントでも、 ユーザーでもない。 ⽬的に忠誠を誓う。

というのがある。

www.slideshare.net

「目的」にむきなおることのできる「合宿」ができる学習組織かどうか、ということは計り知れないほど重要なんだと思う。
Guildworks社は年に何回合宿しているのだろうか?
そして、その合宿で「目的」に立ち返ることがどれほど成果につながったのだろうか?

合宿と約束されたスクラム大勝利

アジャイル開発プロセスの一つスクラムの起源は、ハーバードビジネスレビューに投稿された論文がきっかけというのをご存知だろうと思う。
その論文の著者である、野中郁次郎さんが2011年の「Innovation Sprint 2011」というイベントで基調講演をなされた。
本当に素晴らしい内容なので皆さんも是非ご一読いただきたい。

www.publickey1.jp

その中で、以下のような一節があった。

ホンダの「わいがや」はそういうことなのかなと。三日三晩やり合いながら相互主観性を作っているのかな。三日三晩やり合いながら相互主観性を作っているのかな。よい宿、よい食事、よい温泉が大事で、ちまちました宿では高質の知はできないなと(笑)

スクラムの生みの親といっても良いお方が、「良い合宿」がどれほど大事かを説いていらっしゃるのだ。

カイゼン・ジャーニーの途中ではスクラムをやらなくなってしまっていた事に対して苦々しい思いをされていたスクラム信者の方も多いと思うが、やはりカイゼン・ジャーニーの強さ=「合宿する学習組織の強さ」=スクラムの恩恵といっても差し支えないだろう。

安心してスクラムを信じていきましょう。

多様性について

多様性について考えている2つのことがある。

まず1つ目は、ダイバーシティは異文化の人を集めるだけよりも、内向的な人、外交的な人みたいな側面も見ていくことが非常に重要なんじゃないかということだ。

2つ目は、どのように持つようにしてくかということ。

他の多くの物事と同じように、Whyを理解してやっていく必要がある。

「生物学的多様性って本当に必要なの?」っていうのはうちの研究室の教授が学生に結構な頻度でしていた質問だった。

働くとかビジネスについて人の多様性も多分同じで、本当に必要なのかは考えないといけない。

「じゃあどうする?」という指針を考えていく

チームをビルドするような最初の状態では多様性はなくてもいいけど、必要になったときは、変化とか不確実性への対応方針の柔軟性を普段から持てているかどうかがターニングポイントになる。
そういうものがあれば、多様性をもつ必要に直面したとき、「多様性を考慮することも必要だよね」だと対応できるはずだ。

チーム(もしくは個人の開発ポリシー)はローカルな問題を解決するように構築して、必要に応じて拡張できる感じにしていこう。

2018.05.11追記

1つめのどんなダイバーシティにするかということについてだけど、「SoE, SoR」に似た文脈で、「人 of Engagement, 人 of Record」っていう側面も非常に重要な気がする。
ITの人の中でもその分類はできるだろうが(アプリチームとインフラやSREチーム)、それ以外の人からするとITチーム=バックオフィス=人 of Recordになってしまうかもしれない。

「eureka Meetup #08 -Pairsのビッグデータ基盤の裏側」 に参加してきました

eureka Meetup #08 -Pairsのビッグデータ基盤の裏側-eure.connpass.com

エウレカさんのイベントに参加してきました。

前職でデータマーケティング・BIのエンジニアさんと関わることもあったので興味もあったのですが、とても業務的に、あるいはビジネス的に、技術的に話を聞ける機会でした。
すごく熱量の高い内容で面白かったです。

発表者の皆様、イベントの運営者の皆様、ありがとうございました。

以下メモした内容をまとめています。
(お酒が入っていたこともあり、誤りなどがあればすみません)

Tableauを導入した話

鈴木宏典さん | eureka,Inc.

Pairs
マッチングアプリ

今日のお話はPairsというプロダクトのデータについて

恋愛相手に求めている条件
理想の相手を探せるようにプロフィールを充実させる

興味関心といった情報を利用し分析が可能
(個人の特定はできないようになっている)

ユーザーの行動は
登録 -> 検索 ->いいね -> マッチング
といった流れになっている

各アクションのログに大量にある
ユーザーの行動ログを分析し常にサービスを改善

BIチームに課せられた、「データ可視化」との戰い

データ

  • 行動ログ
  • 課金
  • バイス
  • プロフィール
  • アンケート
  • 広告

PMさん
「こんなすばらしいデータがたくさんあるんだ。 プロダクトに生かそう」

BIチーム
SQLを書く -> 見たい数字が見せられるようにダッシュボードを使う

BigQuery 行動ログ
MySQL ユーザー情報などのマスターデータ

Redashの利用

  • クエリの保管
  • 実行
  • ビジュアライズ

バイス別 いいねの送信数 DAUとか売り上げとか基本

ビジュアライズめんどくさい
ダッシュボードじゃ間に合わない -> 「SQL書いて」

もう少し深掘りできるダッシュボードを作りたい
グルーピング数が大きいローデータを集める

Redash+GAS+Google Spreadsheet
SAMIF関数

シートの内容

  • 施策の効果測定
  • CRM施策の過去結果

ビジュアライズも綺麗
再利用しやすい

だが、
データ更新が不安定 Redashでつまる
可視化めんどくさい
データ量に制限 ,1万5千行あたりから辛い

結局SQL書いて欲しいという依頼が減らない

複雑度 x 依頼数 増大
クエリ作るということが業務になっている部隊に

本来はBIはデータを価値に変えてプロダクトに反映させる部隊

Tableau導入

BigQueryのViewTable(BigQueryから多少加工したもの)

イテレーションの考え方
ダッシュボードを増やしていく方向から、データソースを改善・拡充する方向に

Tableau導入後の世界

「これください」みたいなのを待たない
ビジュアライズなどはマーケティング側に任せられる部分は任せる

BIは高度な析に集中

めっちゃ大規模なデータも余裕
認証とかも楽チン

ただ、ライセンス料が高い

オンラインデーティングのデータは超面白い
本当に見たいデータが大量にある

こういったデータの分析についての本も発売されている

changelogと戦う

山口 将央さん | 株式会社トレタ

クエリの依頼はトレタでもあるある
今日午後から出かけるので こういうデータ用意して

トレタの事業紹介

iPADアプリ

飲食店 予約管理ツール
繁盛店のオーナーさんの意見を反映
飲食店のためになるツールを作っている

予約のフォーム
POSコネクト

グルメ予約サイトとの連携

電話:CTI きたことがある顧客の情報

3方よし
お店 顧客 エンジニア

トレタデータサイエンス研究所

現状のデータインフラについて

Rails, MySQL
GCPレプリケーションBigQuery embulk Digdag

Digdag serverをGithubで管理
トップのtaskだけがサーバー
プルリクベースでtaskがくる

足りないデータでChangelogの話をしていた
アプリケーション側としてはDBが肥大化するので、捨てているものもあった

本当に重要なものについてはとっていた

Reservationのジョブからsidekiq

データ側の要望で本番を重くしたくない
レプリケーションをかけている

Change log

Binlog
MySQLレプリケーションのログ

parseしてBQに突っ込めばいいじゃん
dockerでmysqlのmaster slaveを作ってコンフィグ周りを確認

binlog_format = ROW
Log-slave-updates

binlog-parserのレポジトリをfalk

「あとは取り込むだけ、、、」ではない

個人情報バンバン入っている
データを綺麗に
パースしたデータ
1日4G, 改行ありのjson

Sparkのコンフィグで何度も苦しめられた経験

CloudDataflow

Apache Beamで書いたデータパイプラインの実行環境(runserver)で
runnerをDirectRunnerにすればローカルでも可能

ApacheBeamのコードをどこで作るのをどこでやるか
Datalabでやろうとしている

ローカルで確認して、DataflowRunnerに変換

あとはDigdagに突っ込む

個人情報の削除、mask

サーバーサイドの工数を使うことなくChangelogが取れるようになった
Dataflow便利 処理速度が遅かったら勝手にautoscalingしている
ApacheBeamのデバッグが結構めんどくさい
BQに取り込んだフォーマットが今のままだと使いづらい

今後のやっていくこととして

Firebase

トレタとして欲しい人はどんな人?

最低ラインとしてSQLかける人 機械学習にゴリゴリよっていたというよりはビジネスによっている人が欲しい データサイエンティストが欲しい

パネルディスカッション

  • 鉄本 環さん | eureka,Inc. Head of BI Team. 

  • 山口 将央さん | 株式会社トレタ

  • 前田周輝さん| 株式会社リクルートライフスタイル

  • モデレータ:Eureka CTO 金子さん

  • 鉄本さん
    サーバサイド php -> go
    データの移行を全て担当したところからのBIチーム立ち上げ

  • 山口さん
    データ活用したサービス開発
    (2回目のセッションの内容)

  • 前田さん
    足回り系からデータインサイト
    Tableauユーザ会の代表

業務について

「BIチームとして一番力を入れているプロジェクト」

  • 鉄本さん
    早く正しいデータをいかに出せるか
    データの依頼 煩雑 質がともなわない
    窓口が増えてきた
    リードタイムを減らす

  • 山口さん
    データを使ったプロダクトを作る部分

  • 前田さん
    データを使って利益を出す
    PMO データそのもの
    アナリストも統計より 機械学習よりの人
    データは貴重

扱いに困っているツールとその理由は

「好きでもあり困っているものなど」

  • 前田さん

Redshift
スピードが出ない

Adobe analytics
ツールが進化しているが使いこなすことができず、やれる分析の幅が広がっていない

  • 鉄本さん

Redash
可愛いけど、負荷に耐えられなくなる メンテナンスに時間が割かれる

導入した当時より二次関数的に増えてくる 負荷に耐えられない

  • 山口さん

Metabase
Clousureで書かれたツール
これがあればTableauなくてもいいじゃん 導入した時点で完成度がまだ低かった
一万行のCSVでエラー

データについて

「 データの闇
データを使ってこんな価値を生み出した」

  • 鉄本さん

ゼロイチで管理した管理のカラムが「on, off」のstringで入っていたことが

不正検知
BIと機械学習エンジニアで連携して作っている

課題からブレークダウン
データを使ってボトムアップの提案 比重を強く

  • 前田さん

闇だらけ

10年以上のデータ
カラムが途中でできた
データの欠損 推定で補完
営業も強い 顧客行動 企業名でユニーク 営業担当者名前が入ってユニークになっていない
Distinctにするクエリの発行

中間テーブル マッピングテーブル
Datamart ある程度集約されて、制約が取れたもの
Datamart2

世代管理 ガバナンスがたいへん

よかったこと
レコメンデーション ABテストを金額換算
BI事業 武器となる顧客向けのレポートをTableau 渾身のビジュアライズ
6億 顧客の離脱を防止

  • 山口さん

電話番号をハッシュ化してBQ
グローバル対応 日本の電話番号
電話番号 生きている / 生きていない
日本語が入っている なんで?
店舗のオペレーション上仕方なくというところがある

営業とのやりとりが多い
営業と話しているとこういうデータがほしいというのが雑談ベースで出てくる
営業さんと普通にやるとデータ受け渡しが時間がかかる
今のところ山口さんだけがそういう感じで動いている
営業さんが他の店舗のデータを欲しがるなどリスクもある

組織としてはここから事業が作られていく
予約台帳だけじゃなくなる
データを活かしていこう
ここから新しいプロダクト
チームも

今後チームをどのようにしていきたいか

  • 山口さん

前の話題の最後の部分
情報リテラシーを担保する
B2Bの部分をせめるのは引き続き行う
B2Cをやっても良い

(金子さん)やっぱりデータに理解がある会社は良い

  • 前田さん

データチームの位置付け
組織に存在価値を証明するということを今までのフェーズでやってきた
インサイトの価値をどれだけ出せるか
GPUを使ってみたいんだ 強化学習を使ってみた
知的欲求を満たす
あれやりたい、あれやったほうがいいのではという思いつきが文化として醸成されてきている
前回失敗したことが今は変わっているかもしれない
即ABテストとして実施する
時系列大事

(金子さん)エウレカでも昔と違う ユーザーも全然違う 今過去の施策をやったらどうなるか常に考え続ける必要あり

  • 前田さん

データプロダクト
予測モデルそのもの
直接的な価値を生む
インサイトについては書籍化レベル

エンジニアのデータストーリーテリングのスキルを上げるべき

  • 鉄本さん

データに関わることすべて

マーケティング周りで重視している指標を対応したらどんどんプロダクトの成果が出てきた
データドリブンの風土ができてきた

ユーザーインタビューなどにも力を入れている
でもそこにも統計的な知識があるとなお良い

データがあるからデータを分析すれば何かしらできるんじゃないか、と言う感じでユーザのことよりもデータ第一にしていた感があった時期があった
しかし、一週間かかったことが30分インタビューしたら分かった

データを出せるところ
定量・定性をどちらも大事にする
ドメインナレッジを持っていてデータを出せるのが強い
そこから機械学習 または もっとビジネスよりな提案を出せる
違う分野で力を発揮し始めた
新しいキャリアを考えるのもいいかもしれない
チームの可能性、拡張性を高める
自分が先導してチームを作るくらいのメンバーになって欲しい

(金子さん)Pairsについての印象も ネガティブからポジティブに変わってきている
3ヶ月まえの頭のままだと時代に遅れる 常に自分をアップデートしていく必要がある

おまけ オフィス見学

オフィスを案内してもらいました。
日中はバリスタさんがコーヒーを淹れてくれるそう。
羨ましすぎます。

透明性を大事にする会社なので、会議室の壁も基本は透明とのこと。
ipadでの会議室の予約システムが便利そうです。

ため息が出るほど素晴らしいオフィスでした。