『絶園のテンペスト』のアニメの紹介
dアニメで視聴できる模様です。(2020年10月現在) anime.dmkt-sp.jp
現代を舞台とした魔法が存在するファンタジーだが、バトルアクションよりも駆け引きを重点的に描いているアニメ。
シェイクスピア作品からの引用が会話内容に散りばめられており、タイトルの「テンペスト」もまたシェイクスピア作品『テンペスト』に由来する。
性格が正反対のダブル主人公、冒頭からすで亡くなっている影のヒロイン、魔法を有する一族から樽に詰められて無人島に閉じ込められた最強術者のヒロインなど、キャラクターは癖が強い。
人類の文明品を対価としないと発動しないという制約のある魔法をいかに使うか、「はじまりの樹」や「絶園の樹」の本当の意味とは何かという世界観の読み解き、影のヒロインの死の真相などの謎解きの要素などが面白い。
あと、24や名探偵コナンの小五郎を演じている小山力也さんの演技が面白いのでそちらもオススメです。
Vue Fes Japan に参加してきました
2018.11.03 にあった、「Vue Fes Japan」に参加してきました。
素晴らしいイベントでした。
セッションだけでなく、ランチとかディナーもすごく評判が良かったみたいです。
スピーカーの皆様、スタッフの皆様、ありがとうございました。
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 テンプレートからのコンパイル コンポーネント探索の高速化 子要素数０であることをコンパイラ出力し、スキップする
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は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 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さんによる技術書典本
- webcomponents.org
- よくわかるWebComponents せんすいさん
Vue Designer: デザインと実装の統合
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でクライアントに渡す クライアント上でレンダラーでVSCodeのGUIに表示
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にむけて
レイアウトできるツールにしたい 大まかなレイアウトを作るときはVue上でやりたい
npm installするだけでデザインを組み立てられる elment-vuetify quasar-framework vuesax
デザイナーと開発者がGitHubで同じコードを編集 すごく楽しい
コンポーネントカタログ 自動生成 右側から出てきたドロワーに一覧があった
Nuxt.js 2.0
Nuxt.jsの開発者である Sébastien Chopinさん自身によるNuxt.js2.0の紹介でした。 こちらもすごかった。 日本語での通訳も出ていたんですが、もっと英語勉強して普通に聞き取れるようになりたいと感じました。
内容としてはデモが非常に多く、ついていくだけで精一杯であまりメモは取れなかった感じです。
この講演についてのメモ （書き間違いなどあり）
Nuxt.jsを使うパターンの紹介
- REST APIパターン
ブラウザー:リクエスト -> 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
ランタム限定 軌道速度２倍
ESM対応
ESMモジュールサーバー ミドルウェア
Nuxtjs 2.3.0 coming soon
モダンブラウザー向けビルド
nuxt build --modern
内部リファクタ
note のフロントエンドを Nuxt.js で再構築した話
noteをRails とAngular.js 1系のSPAから、BFF を Nuxt.js（Vue.js）に移行していっているお話でした。
RailsをAPIのみにとどめて, RederとclientナビゲーションをNuxt.jsとVue.jsに置き換える話は自分のやっていきたい開発としても、とても参考になる感じです。
AtomicDesignを活かしてコンポーネントを開発していく話もあり、過去に一旦挫折したStorybookをまた復活させたという話が響いた人も多かった模様でした。
この講演についてのメモ （書き間違いなどあり）
（メモよりもリンク先のスライドを読んでいただく方がいいと思います。）
noteを最初に開発した当時、react, vue はversion 1にもなっていなかったためAgular.jsを採用
課題
- SSRをサポートしていない
- 表示速度
フレームワークリニューアル
Vueを選んだ理由
Vue.jsのエキスパートがコンサルに
@kitak - 実装のQA - 設計サポート - ハンズオン開催
Nuxtのきっかけ
VueでSSRするのに簡単
pages配下にコンポーネントを置く
asynccData()/ fech()で必要なデータを定義取得する
開発体制
- エンジニア３名
- デザイナー２名
現時点でのパフォーマンス比較
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の@9mさんに声をかけていただきました。ありがとうございました。 たまたま自分がYatteikiパーカー着ていたのですが、となりに@9mさんが座ってました。。。全然気づかなかった。
1年間単体テストを書き続けた現場から送る Vue Component のテスト
土屋 和良さんによる発表でした。 Atomic DesignのStorybookも活用しながら、Vue ComponentをVisual Testingするのが最高という内容だったと思います。
この講演についてのメモ （書き間違いなどあり）
（メモよりもリンク先のスライドを読んでいただく方がいいと思います。）
何をテスト
Componentのテストもそうでないテストも考え方は一緒
@t_wada プライベートメソッドはテストする必要がない 外部から見た振る舞いのテストじゃない
テストするとき マウントするのか、シャドウマウントするのか
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に開催された表題の勉強会に参加しました。 会場はアカツキさんです。
発表者： ギルドワークス 前川さん
内容としては、「新しい技術を取りいれるための実験のやりかた」というお話で、ほぼ１ヶ月の期間で自社の内製プロダクトに新しい技術を３種類取り入れたというお話でした。
以下はかなりの概略ですが、個人的にメモした内容などです。
取り入れられた技術は以下の３つ
- Java on Lambda で作成するサーバレスアプリ
- iOS + Android + PWA 3プラットフォーム のアプリケーションを Ionic で開発する（20分）
- 機械学習サービス(Saas型)
新技術だとQCDSそれぞれにリスクがあり、漸進的な改善と根本的な改善をという２パターンでの導入が考えられるが、それぞれ「根本的な改善ができない」「ゼロからのリスタートになる」というリスクがある。
リスクを抑えた上で根本的な改善をしたいので次のような手段をとった
- 新規自社プロダクトのMVP開発で小さく試す
- 認証など、Saas化して外に出せるものは出す
Java on Lambda
話を聞いているとCognitoを利用した認証管理がすごく楽にうまくいったという感じが伝わってきました。
一番難しかった問題は、「ステージングをどう作るか？」ということみたいで、それはデータストアとして「DynamoDB、アノテーションベースでテーブルを定義している」というところに原因があったところみたいです。
IonicによるPWA
IonicをつかったPWAのメリットは「ドキュメントが非常に丁寧」ということと「CLIによるサポートが充実」しているということらしいです。 とくに「CLIを使うと定型作業がミスなく」というところ
この話題での難しさは、「Ionic標準からはずれるようなUIの作成は高コスト、レールから外れると大変」とのこと。 その場合は、標準のカスタマイズよりもWeb技術で作ってしまうのが早い
機械学習の導入
導入するときにぶつかる問題に以下の２つがある。
- データセット足りない問題
- 技術的ハードル高い問題
AWS/Microsoft/Google それぞれ用意されている
今回はGoogleでのトライ、Google日本語対応状況がよいとのこと
言語に対する解析として、以下のようなものを利用できた。
- エンティティ
- 感情
- 文法 （ちょっとこれについてはメモミスかも）
感想
「リリースを前提に置くことで、より大きな舞台で活用していくのにも有用な知見が得られた」というところが印象的でした。 あとやはり１ヶ月程度でこんなに実験的に新技術を試せるのはいいなと思いました。 個人的に気になるのはPWAとCognitoかなぁ、と思いました。
発表者の前川さんと会場のアカツキさん、ありがとうございました。
Kubernetes Djangoチュートリアルのメモ
2018.05.26時点の情報です
Running Django on Kubernetes Engine | Python | Google Cloud
ローカル コンピュータでアプリを実行する
ハマりポイント
まずposgresqlがローカルでポート5432で動く前提になっている
Macならbrew install posgresqlなどでインストールする必要あり
ubuntuやwindowsでも同じだろう
後、gcloud sqlと同じようにユーザとDBを作らないといけない
また、pipでインストールするrequirements.txtを見るとDjango 2.03となっているが、2.03ではmiddlewareのsettingが間違っている
詳しくはこの辺りを読む
Middleware | Django documentation | Django
とりあえず、公式の通り 'django.contrib.auth.middleware.SessionAuthenticationMiddleware'
を入れないようにしないといけないところが落とし穴
GCPもk8sも全く関係なかった
追記
この記事だけだと片手落ちなので、tutorialのリポジトリにプルリク出しました。
プルリク拒否られた（botに）
— hirokts (@hirokts) May 26, 2018
Contributor Licenseがいるってことなのかー
approveがつけばマージされるそうなので、それを待つ感じみたいです。
カイゼン・ジャーニーと合宿する学習組織の強さ
むきなおり合宿
カイゼン・ジャーニー第１６話の「チームとリーダーの境界」では、むきなおり合宿というプラクティスが取り上げられている。
振り返りでは過去の経験を生かして次のサイクルを良くするということができるが、それゆえに今までの方向性にひきづられることが多い。
むきなおりでは、「インセプションデッキ」など、前提になる大元に対しても修正を加えるので、そうした方向性もただすことができる、ということなのだろう。
むきなおりの手順は以下の通り
- ミッションビジョンを点検する
- 評価軸を洗い出し、現状を客観的に見定める
- 評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す
- 「課題解決」のために必要なステップを「バックログ」にする
- 「バックログ」の重要度と、一番効果の高いものを決める
- 時間軸を明らかにし、期限も明確に決める
詳細は実際にカイゼン・ジャーニーを手にとって確認してほしい。
こういったむきなおりに対して「合宿」を効果的に使えることが、カイゼン・ジャーニーの著者ふたりの強さだったり、市谷さんのGuildworksの強さだという感じがしている。
新井さんのこのスライドの合宿のところを見てほしい。
本の執筆のために、10月から２月にかけても4回も合宿している。
市谷さんのスライドでとても印象的だった一節に
忠誠を誓う対象は、 アジャイルでも、 技術でも、 クライアントでも、 ユーザーでもない。 ⽬的に忠誠を誓う。
というのがある。
www.slideshare.net
「目的」にむきなおることのできる「合宿」ができる学習組織かどうか、ということは計り知れないほど重要なんだと思う。
Guildworks社は年に何回合宿しているのだろうか？
そして、その合宿で「目的」に立ち返ることがどれほど成果につながったのだろうか？
合宿と約束されたスクラム大勝利
アジャイル開発プロセスの一つスクラムの起源は、ハーバードビジネスレビューに投稿された論文がきっかけというのをご存知だろうと思う。
その論文の著者である、野中郁次郎さんが2011年の「Innovation Sprint 2011」というイベントで基調講演をなされた。
本当に素晴らしい内容なので皆さんも是非ご一読いただきたい。
その中で、以下のような一節があった。
ホンダの「わいがや」はそういうことなのかなと。三日三晩やり合いながら相互主観性を作っているのかな。三日三晩やり合いながら相互主観性を作っているのかな。よい宿、よい食事、よい温泉が大事で、ちまちました宿では高質の知はできないなと（笑）
スクラムの生みの親といっても良いお方が、「良い合宿」がどれほど大事かを説いていらっしゃるのだ。
カイゼン・ジャーニーの途中ではスクラムをやらなくなってしまっていた事に対して苦々しい思いをされていたスクラム信者の方も多いと思うが、やはりカイゼン・ジャーニーの強さ＝「合宿する学習組織の強さ」＝スクラムの恩恵といっても差し支えないだろう。
安心してスクラムを信じていきましょう。
多様性について
多様性について考えている２つのことがある。
まず１つ目は、ダイバーシティは異文化の人を集めるだけよりも、内向的な人、外交的な人みたいな側面も見ていくことが非常に重要なんじゃないかということだ。
２つ目は、どのように持つようにしてくかということ。
他の多くの物事と同じように、Whyを理解してやっていく必要がある。
「生物学的多様性って本当に必要なの？」っていうのはうちの研究室の教授が学生に結構な頻度でしていた質問だった。
働くとかビジネスについて人の多様性も多分同じで、本当に必要なのかは考えないといけない。
「じゃあどうする？」という指針を考えていく
チームをビルドするような最初の状態では多様性はなくてもいいけど、必要になったときは、変化とか不確実性への対応方針の柔軟性を普段から持てているかどうかがターニングポイントになる。
そういうものがあれば、多様性をもつ必要に直面したとき、「多様性を考慮することも必要だよね」だと対応できるはずだ。
チーム（もしくは個人の開発ポリシー）はローカルな問題を解決するように構築して、必要に応じて拡張できる感じにしていこう。
2018.05.11追記
１つめのどんなダイバーシティにするかということについてだけど、「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でつまる
可視化めんどくさい
データ量に制限 ,１万５千行あたりから辛い
結局SQL書いて欲しいという依頼が減らない
複雑度 x 依頼数 増大
クエリ作るということが業務になっている部隊に
本来はBIはデータを価値に変えてプロダクトに反映させる部隊
Tableau導入
BigQueryのViewTable（BigQueryから多少加工したもの）
イテレーションの考え方
ダッシュボードを増やしていく方向から、データソースを改善・拡充する方向に
Tableau導入後の世界
「これください」みたいなのを待たない
ビジュアライズなどはマーケティング側に任せられる部分は任せる
BIは高度な析に集中
めっちゃ大規模なデータも余裕
認証とかも楽チン
ただ、ライセンス料が高い
オンラインデーティングのデータは超面白い
本当に見たいデータが大量にある
こういったデータの分析についての本も発売されている
changelogと戦う
山口 将央さん | 株式会社トレタ
クエリの依頼はトレタでもあるある
今日午後から出かけるので こういうデータ用意して
トレタの事業紹介
iPADアプリ
飲食店 予約管理ツール
繁盛店のオーナーさんの意見を反映
飲食店のためになるツールを作っている
予約のフォーム
POSコネクト
グルメ予約サイトとの連携
電話：CTI きたことがある顧客の情報
３方よし
お店 顧客 エンジニア
トレタデータサイエンス研究所
現状のデータインフラについて
Rails, MySQL
GCPにレプリケーションBigQuery embulk Digdag
Digdag serverをGithubで管理
トップのtaskだけがサーバー
プルリクベースでtaskがくる
足りないデータでChangelogの話をしていた
アプリケーション側としてはDBが肥大化するので、捨てているものもあった
本当に重要なものについてはとっていた
Reservationのジョブからsidekiq
データ側の要望で本番を重くしたくない
レプリケーションをかけている
Change log
parseしてBQに突っ込めばいいじゃん
dockerでmysqlのmaster slaveを作ってコンフィグ周りを確認
binlog_format = ROW
Log-slave-updates
binlog-parserのレポジトリをfalk
「あとは取り込むだけ、、、」ではない
個人情報バンバン入っている
データを綺麗に
パースしたデータ
１日４G, 改行ありの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チーム立ち上げ山口さん
データ活用したサービス開発
（２回目のセッションの内容）前田さん
足回り系からデータインサイト
Tableauユーザ会の代表
業務について
「BIチームとして一番力を入れているプロジェクト」
鉄本さん
早く正しいデータをいかに出せるか
データの依頼 煩雑 質がともなわない
窓口が増えてきた
リードタイムを減らす山口さん
データを使ったプロダクトを作る部分前田さん
データを使って利益を出す
PMO データそのもの
アナリストも統計より 機械学習よりの人
データは貴重
扱いに困っているツールとその理由は
「好きでもあり困っているものなど」
- 前田さん
Redshift
スピードが出ない
Adobe analytics
ツールが進化しているが使いこなすことができず、やれる分析の幅が広がっていない
- 鉄本さん
Redash
可愛いけど、負荷に耐えられなくなる メンテナンスに時間が割かれる
導入した当時より二次関数的に増えてくる 負荷に耐えられない
- 山口さん
Metabase
Clousureで書かれたツール
これがあればTableauなくてもいいじゃん
導入した時点で完成度がまだ低かった
一万行のCSVでエラー
データについて
「 データの闇
データを使ってこんな価値を生み出した」
- 鉄本さん
ゼロイチで管理した管理のカラムが「on, off」のstringで入っていたことが
不正検知
BIと機械学習エンジニアで連携して作っている
課題からブレークダウン
データを使ってボトムアップの提案 比重を強く
- 前田さん
闇だらけ
１０年以上のデータ
カラムが途中でできた
データの欠損 推定で補完
営業も強い 顧客行動 企業名でユニーク 営業担当者名前が入ってユニークになっていない
Distinctにするクエリの発行
中間テーブル マッピングテーブル
Datamart ある程度集約されて、制約が取れたもの
Datamart2
世代管理 ガバナンスがたいへん
よかったこと
レコメンデーション ABテストを金額換算
BI事業 武器となる顧客向けのレポートをTableau 渾身のビジュアライズ
６億 顧客の離脱を防止
- 山口さん
電話番号をハッシュ化してBQ
グローバル対応 日本の電話番号
電話番号 生きている / 生きていない
日本語が入っている なんで?
店舗のオペレーション上仕方なくというところがある
営業とのやりとりが多い
営業と話しているとこういうデータがほしいというのが雑談ベースで出てくる
営業さんと普通にやるとデータ受け渡しが時間がかかる
今のところ山口さんだけがそういう感じで動いている
営業さんが他の店舗のデータを欲しがるなどリスクもある
組織としてはここから事業が作られていく
予約台帳だけじゃなくなる
データを活かしていこう
ここから新しいプロダクト
チームも
今後チームをどのようにしていきたいか
- 山口さん
前の話題の最後の部分
情報リテラシーを担保する
B2Bの部分をせめるのは引き続き行う
B2Cをやっても良い
（金子さん）やっぱりデータに理解がある会社は良い
- 前田さん
データチームの位置付け
組織に存在価値を証明するということを今までのフェーズでやってきた
インサイトの価値をどれだけ出せるか
GPUを使ってみたいんだ 強化学習を使ってみた
知的欲求を満たす
あれやりたい、あれやったほうがいいのではという思いつきが文化として醸成されてきている
前回失敗したことが今は変わっているかもしれない
即ABテストとして実施する
時系列大事
（金子さん）エウレカでも昔と違う ユーザーも全然違う 今過去の施策をやったらどうなるか常に考え続ける必要あり
- 前田さん
データプロダクト
予測モデルそのもの
直接的な価値を生む
インサイトについては書籍化レベル
エンジニアのデータストーリーテリングのスキルを上げるべき
- 鉄本さん
データに関わることすべて
マーケティング周りで重視している指標を対応したらどんどんプロダクトの成果が出てきた
データドリブンの風土ができてきた
ユーザーインタビューなどにも力を入れている
でもそこにも統計的な知識があるとなお良い
データがあるからデータを分析すれば何かしらできるんじゃないか、と言う感じでユーザのことよりもデータ第一にしていた感があった時期があった
しかし、一週間かかったことが30分インタビューしたら分かった
データを出せるところ
定量・定性をどちらも大事にする
ドメインナレッジを持っていてデータを出せるのが強い
そこから機械学習 または もっとビジネスよりな提案を出せる
違う分野で力を発揮し始めた
新しいキャリアを考えるのもいいかもしれない
チームの可能性、拡張性を高める
自分が先導してチームを作るくらいのメンバーになって欲しい
（金子さん）Pairsについての印象も ネガティブからポジティブに変わってきている
３ヶ月まえの頭のままだと時代に遅れる 常に自分をアップデートしていく必要がある
おまけ オフィス見学
オフィスを案内してもらいました。
日中はバリスタさんがコーヒーを淹れてくれるそう。
羨ましすぎます。
透明性を大事にする会社なので、会議室の壁も基本は透明とのこと。
ipadでの会議室の予約システムが便利そうです。
ため息が出るほど素晴らしいオフィスでした。
