hiroktsのブログ

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

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での会議室の予約システムが便利そうです。

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

docker-composeで特定のコンテナの中のファイルをホスト側にコピーする

パスや実行ディレクトリなどには注意

gist.github.com

ソフトウェアエンジニアとはどういう人が多い?

  • 一緒に働くとき
  • 採用するとき

「ソフトウェアエンジニアとはどういう人が多いのか」という内容に気を配るといいかもしれない。

または、逆に自分が説明するときの備忘録として。

概要

プログラマー三大美徳」「UNIX哲学」みたいな価値観を大事にしている

「コードを書くことによるものづくり」状態が整っていると楽しいし、そのことに集中して静かに働きたいと思っている。

ソフトウェアエンジニアはどんな価値を大事にしているか

プログラマー三大美徳」

  • 短気
  • 傲慢
  • 怠惰

これの反対側の価値も大切だということは理解しつつ、これらの感覚もプログラミングでの課題解決にとって非常に大切にしている

例えば、矛盾していると感じられるかもしれないが、「こんなダルいことはやりたくない。楽をしたい。楽するためには徹夜してでもコードを書く」というようなこと

UNIX哲学」

  • 小さいものは美しい。
  • 各プログラムが一つのことをうまくやるようにせよ。
  • できる限り早く原型(プロトタイプ)を作れ。
  • 効率よりも移植しやすさを選べ。
  • 単純なテキストファイルにデータを格納せよ。
  • ソフトウェアを梃子(てこ)として利用せよ。
  • 効率と移植性を高めるためにシェルスクリプトを利用せよ。
  • 拘束的なユーザーインターフェースは作るな。
  • 全てのプログラムはフィルタとして振る舞うようにせよ。

Wikipediaより

OSSに対する敬意

好き嫌いはあるかもしれないが、基本的にOSSに対しては敬意を払っていることが多い

それに加えて

多分このへんは好みになるが、ローコンテキストであること。

ソフトウェアエンジニアに必要な環境

静かに、自由に働く

背景として

複雑な問題に対するコーディングは基本的に思考や試作が分岐、分岐、分岐という感じで深く深くなる傾向がある

ある程度まとまった時間に集中してやらないと解決できないことが多い

環境

  • 広めの机、座りやすい椅子
  • 細切れの会議などがたくさん入る状況でなく、静かであること
    • 物理的に静かである、ということよりも意味の薄いインタラプトがないことでコンテキストのスイッチを最小にする
  • インターネットでの検索が自由にできたりするのは必須
  • 散歩したり、場所を変えて「コードを書いたり、ホワイトボードの前で議論する」ことができる環境であることもいいと思う

何を道具にしているか

  • terminal
    • コンピュータにソフトウェアを実行させるのに使う
    • 最小のソフトウェアを連結することで、簡潔にコンピュータを問題解決のために動かすことができる場所
  • editor, IDE
    • コードを書くのに使う
  • git
    • コードをバージョンごと、機能ごとに管理するのに使ったりする

ソフトウェアエンジニアの一般的な開発フロー

WEBアプリケーションの場合の一例

  1. 要求 -> 要件
  2. (システム構成設計)
  3. (開発環境構築)
  4. モデル設計 - 現実的な物事の意味構造からのプログラミング的な意味構造の設計
  5. プロトタイプ
  6. コーディング+テスト
  7. レビュー
  8. (本番環境構築)
  9. (デプロイスクリプトなどの構築)
  10. デプロイ
  11. (公開, ロギング、分析などの設定)

※ ()内は最初期のリリース ※ デプロイとはプログラムのコードをサーバーに配置して動かすこと