developers boost 2018
memo:
developers boost 初開催
13:00【C-1】U30エンジニアとしての技術的投資戦略
登壇:安野 貴博
内容
参加者は、皆エンジニア
「予想した未来にベッドする戦略」をテーマ
■ 会社紹介
AIに強い
簡単な質問は、AI側で一時対応。
難しい対応は、人手対応。(当たり前)
オラクル製チャットボットはどうなんだろう
日本語に特化している。
リリース後のチューニングがしやすい。
■ 経歴紹介
・東大・松尾濃研究室
・エレベーターの乗り方について考えた
→ 効率性を考えた(15階ボタンよりも先に閉まるボタンを押す?)
・ペッパーくんに興味を持った
→ 友達が「ペッパーズ」というコンビ名で、ペッパーくんと組んだそう
→ 裏手で、安野さんがペッパーくんを操作していた。(300msぐらいの遅延)
→ 遅延を考えてペッパーくんを動かした。
vTuber
→ 妻がハマった
■ 主内容
「予想した未来にベッドする戦略」
・資本主義ゲーム → 資本がないU30には、きつい
・不完全情報ゲーム → コネや情報がないため、きつい
・繰り返しゲーム (スキルや経験の積み上げ) → U30には経験がないため、きつい
U30の強み
・リスクをとれること
→ 収入が一時的に減るリストがとりやすい
→ 失敗しても、何度もチャンスが豊富にあるため、やりなおせる
・時間的なリソースを投下できること
→ 体力があるし、時間に縛られない
↓
新規に立ち上がり成長している領域で大きな勝負ができる。
U30の弱点がへる(資本はいらない、情報は少ない、経験もない → 平等)
U30の強みがでる(リスクを一定以上とれる、トライアンドエラーも許容)
■ U30の戦略
未来を予測する
機械学習は産業として立ち上がる
細かく実験してみる
ペッパー、vTuber、Oculus、機械学習など
価値として、皆が予測するものでないこと
アクションに結びつける
※ inputする情報が同じだと予測未来も皆同じ。
→ iinputで細かい情報を得る(実験)し、チームにフィードバックしてもらう
→ フィードバックループして、肌感を得る
2. 予測した未来に備える
→ハイリスクハイリターンな投資
→ 闇雲にとり得るよりも、シナリオを考える
→ 来るかどうかわからないものを先取りする(iphone普及、AIブーム、BitCoin)
3. 選択肢を定量比較しベットする
企業ステージでリスク・リターンと設計の自由度は変わる
13:50【C-2】ZOZOのGlobal ECを支えるフロントエンド
登壇:松井 菜穂子
内容
■ 自己紹介
Webフロントエンド開発チーム、サーバーサイドも軽く触れた
■ 会社紹介
・zozosuite → 体型がわかる
・zozo → 体型がわかれば、ピッタリ合う服を提供
・wear
■ 主内容
・ZOZO Global ECとWebフロントエンドについて
プライベートブランド(zozo)のみ。
配送地域は72国。
物流オペレーションのハードルが高い(安定稼働の改善が難しい)
また、通常のECサイトよりも機能が多い。
▼通常
・商品カタログ、カート、決済+注文、履歴、返品、交換
▼プラス
・多言語対応
・配送対象72国毎の出し分け
・zozosuit の計測、計測履歴、商品の部位ごとのサイズ調整
■ 技術stack
・フロント
→ vue.js (vue router) + Vuex + typescript (SPA)
→ コンポーネント指向で開発を進めている。
→ SEOのため、nuxtjsでレンダリングしてからしている(そりゃそうだ)
→ Three.jsでモデルを出している(WebGL、zozosuit用)
→ vueコンポーネントを活用することで、様々な商品コンポーネントを表現できる
翻訳テキストは、jsonファイルで一括管理
Vue.jsは、いいよ!!
■ フロントエンドの抱える課題と解決策
・フロントエンドは6人。バックエンドは20人。
→ 人の入れ替わりが激しい。
→ 機能ごとに担当分けされているが、それでも課題がある
(ここの機能にしか関心がない)
・人数が少ない!
→ 人を増やしていると、人のスキル感がわからなくなる。
→ マークアップレベルなのか、アーキテクトレベルなのか。
↓
アプリケーションが、密結合になっているため、開発者の認識をあわせる必要があり、スピードが落ちる
↓
ほどよい開発ルールの制定を決めた
Atomic Designを採用
・Atomicは、vuexのストアと結合しない。また、moleculesとあんまり違いはない。
・oraganismは、ストアと密結合する。
→ 要は、会社で定義した。
・storybookは、運用に課題があったため自前で仕組みを作った
↓
コンポーネント開発のルール選定したため、UI周りは疎結合になった!
アーキテクチャレベルでも疎結合にするように設計
→ View(store), Application(services,model), interface(adapters)の3層を作った
■ リファクタリング
・疎結合になったことで、改修による予想外の影響がへり、不具合が減少。
・リファクタリングの時間は、開発者が作ろうと積極的にならないといけない。
・リプレースチャンスは、大きなリファクタリングができる
→ それ以外は、頃合いをみて差し込んでいく
14:15【C-3】サーバーレス+SPAでつくる!ユーザーご意見管理システム
登壇:木村 タカトシ
内容
■ 自己紹介
2014年新卒入社
NavitimeJapan入社
→ 2000年創業
→ 500名のうち、8割がエンジニア
■ 主内容
ご意見管理システム (社内ツール)
・導入背景
→ ユーザーとコミュニケーションを取りながら、プロダクトを改善し、ロイヤリティを向上したい
・無印はご意見をプロダクト新規開発している。
■ マイクロサービス開発 開始
ご意見を投稿・取得できるAPI
ご意見をみるGUI
★ 主な狙いとして、経験が浅い人でも開発・運用できるようにしたい(複雑にしない)
node, mysql, …で構成しようと考えた
→ スモールスタートなのに、node,mysqlのインスタンスを立てるのはコストがかかる
→ サーバーレスは、従量課金のため関係ない。激安
→ API Gateway, Lambda だけで、インスタンスを立てるよりも5分の1
サーバーレスで、要件を満たせるのか
Labmdaで実装できるのか?
CRUDなんで、大丈夫
データ設計はどうなの?
Labmda + RDSはダメ
KVSのデータ設計するほうがベター
※ DynamoDBでのトランザクションサポートなど、データ制約は徐々に減るのではと
■ マイクロサービス開発 開始
AWS SAM (Servless application model)
Lambda関数、DynamoDBの各リソースによって構成される
★ ローカルでも動かせる
node.js (goがでたらgoだった)
技術スタックとして、jsを使うので学習コストが低いnode.jsを採用
typescriptで実装
ローカルで TypeScript + AWS SAM (Lambda/DynamoDB) の開発環境を構築するを書いた
API Gatewayは、swaggerで設定する
▼ 残念ポイント
設定を記述していくのが多い
swaggerのインポートエラーが分からない(invalidのみ)
▼ 良いポイント
ローカルで動く
フロントエンド
GUIは、特に悩まずSPA
vue.js
学習コストが低い、ドキュメントが充実、cliツールで一発
vue.js入門読めば、ハマりポイントが結構書いてある
■ 問題
▼ コンポーネント設計どこまでちゃんとやるか問題
→ Atomic Designやめた。そこまで凝る必要性が見いだせなかった
▼ JavaScript vs TypeScript問題
→ tsはユニットテストが動かなかったので、jsになった
■ S-in(サービスイン)後
・大きな問題はなし
APIの死活監視はどうするの?
→ cloud watchで監視
■ 今後の課題
→ どこまでスケールできるのか(わからない)
■ マイクロサービスに向いてそうなサービス
小さいアプリケーション(社内ツール)なら、サーバーレスが使える
CMSも簡単に作れそう
microservice化のあしがかりにでもなる
14:50【B-4】事業をBoostさせるデータ基盤(仮)
登壇:横山
内容
データ基盤、需要が高まっている
プロダクト開発における「使われるデータ基盤」
おおすぎ!
また、急いで発表されている印象で、ほとんどちゃんと話せてなかったイメージ。もったいない。
■ プロダクト紹介
ゼクシィ縁結び
■ データ基盤の必要性
どのようなデータ活用があるのか?
→ ビジネス指標の推移をモニタリング(行動履歴)
→ ABテストの結果
→ レコメンド
→ 過剰アクセスなど迷惑アクセスの分析
→ 広告の最適化
→ ニュースレター(市場活性化)
→ システムモニタリング
■ データ基盤で失敗したこと
データをいろんな部署が使って足したりすると
→ 消費税、割引分、按分、など、売上計算が部署ごとに変わってしまう
→ 結果、トラブルになる
■ 設計ポリシー
・model(蓄積/加工) と view(部署ごとに異なる)を分ける
→ viewは、excelやre:dash, tableau, jupyter など、部署毎に使い慣れているツールを採用する
■ なるべく楽したい
データ基盤は利益を出さないため、そこまでちゃんと作らなくて良い
→ python , bigqueryで、なんとなく作る
作る工程は、収集→蓄積→加工 の順
収集
python( requests + beautiful soup) on jupiterで、小さく進める
蓄積
bigquery
元データ:中間データ:加工後 を用意する。
SQLツリーによるWith句でオブジェクト化などして中間テーブルをきちんと管理(?)
加工したデータは、slackで通知する
■ 悲しい現実
ダッシュボードを部屋のモニターに写してみる
→ 誰も見ない結果になった。一部の人しかみない。
→ 良かれと思ってがっつり作ったのに、悲しかった
★ がっつり作っても、ちゃんと使われない
ヒアリングして、ほしいものをシステム反映する
→ 繰り返して、フィードバックを得て改善する。
チケット駆動開発で優先順位をつけるが、最も優先度が高いのは、
データが間違っている案件。
15:15【B-5】先端機械学習モデルを自社サービスに導入
登壇:森山直人
内容 (正直良くわからなったです)
■ 自己紹介
python中心
■ 会社紹介
persol careerの宣伝
■ 機械学習技術の適用について
必要な機械学習は、業界によって異なる
→ 製造業界、金融業界、医療業界、人材業界
→ 人材業界:求人レコメンデーション
■ レコメンデーションの基礎
協調フィルタリングをベースとしたものが多い
→ とても強力だが、逐次的学習が困難。
リアルタイムができないため、夜間バッチとかにすることが多い
→ 遅れてしまうので、もったいない。
↓
リアルタイムレコメンデーション可能で、少ない計算リソースがほしい
↓
先端研究
NIPS
ICML
ACL
KDD
→ 制度よりも、安定運用が求められている
※ recsys2018は除外
KDD
→ learning and transferring ids representation in e-commerce (とりあえず ID2Vecと呼称)
→ アリババ社による論文を採用
Word2Vec
Item2Vec
↓
リアルタイムレコメンデーション可能?
→ 閲覧履歴がない場合、学習できない(コールドスタート)
15:40【A-6】Fallacies of Client Side Programming
クライアントサイドの落とし穴-
登壇:Edward Fox
内容
■ 自己紹介
Webエンジニア、Web/ブラウザ技術全般、PWA
■ スポンサー紹介
→ アプリだけでなく、Webにも浸透してきた
■ 主内容
分散コンピューティングの落とし穴に似せて説明
クライアントサイド開発の落とし穴
ユーザーは合理的である
ユーザーは、怠惰で短期
複数タブ!鬼連打!
複数タブは、HTTPリクエストをAtomic(他の影響されないもの)にしよう
連打は、UIの状態管理を丁寧に作ろう
ユーザーは最新のバージョンを使ってくれる
Chrome, Firefoxは、自動アップデート
Chrome Devtoolsが優秀
開発に利用している人が多い
IEは、globalで10%
セキュリティポリシーで、更新が止められている会社はある
SDK配布時、サポート計画をよく練ること
extensionやpluginは行儀よく振る舞う
uBlock plusというアドブロックでanalyticsという文字列があると一律ブロック
jsonリクエストがブロックされ、分析画面が正しく表示できなかった
konami.js (を使っている extension)
ブラウザ上でコナミコマンドで、イベント発火を奪う
プロダクトのjsが正常に動かない
ユーザーの行動は、正しく理解できている
デプロイ・リリースして終わり?
No. エラートラッキングが大切
sentryのbreadcrumbsが良い
フロント界隈では、エラートラッキングの文化がない
ネットワークは常に高品質で安定している
モバイルであれば、ネットワークのハンドオーバーが常におきている。
パケットロスもある。
通信遅延もある。
pageSpeed Insight, webpagetest.orgを活用して、低品質なネットワークをエミュレート
Network Error Loggingという使用のドラフトが最近書かれた
Report URIというツールがサービス提供
16:15【B-7】検索結果の良さを計測して定量的に改善していく
登壇:大田
資料
内容
■ 主内容
何かを評価する際のものさしを探そう
→ 同じものなら、比較がしやすい (ぞうの体重)
→ 違うものなら、そこを合わせる(UIの使いやすさ)
認識がずれると、コミュニケーションミスになる
→ はかりやすいもの、はかりにくいもの
はかりにくいものの場合の話(アニメーションのよさとか)
→ ものさしがない
■ 自分で必要なものさしを探そう
※ 自社のプロダクトから話を進める
■ 背景と課題
ユーザーが探している食品を検索してもヒットしない
→ データとしては多いため、ヒットしていた
→ ただ、ほしいものが下の方にいっていたので、ないも同然になった
良い検索とは?
→ ある1つの結果の良さはなんとなくわかる
→ 人によって良さは違う
検索結果の評価ものさしがない
→ なんとかなくよくなっている気がするだけ
→ 売上などで評価しても良いが、時間が必要で、悪かったら損失になる
→ バグがあったとしても、良いか悪いのか判断ができない
→ ものさしが必要
■ 課題に対する解決策
ものさしをゼロから作るのは大変
→ 会社独自の問題ではないため、巨人の肩に乗りたい
→ 一般的な文書検索の概念
→ MRRを採用
→ 教師データは、ログから抽出(何をしたら何をクリックした→答えとする)
改善手順
・現在の状態を図る(MRRで計算)
・改善方法を考える(MRRを上昇する方法)
・試す
→ hyperoptでパラメータ組み合わせ
・ものさしで測る(MRR)
→ hyperoptが良かった
→ 検索の良さが、どれぐらいKPIに響くかABテストして最終確認
16:40【B-8】スーパーエンジニアではなくとも好きな分野で生きていくには
登壇:山中 亮
内容
■ 自己紹介
新卒後、社会人5年目でやりたいことを達成した。
世の中には、スーパーエンジニアがいっぱい
→ 比較しても無駄。自分のやりたいことを考えるべき。
★ 「今やっている仕事=将来の職務経歴 」という意識をする。
→ 次の目標に沿う職務経歴を選択しているか?
→ やりたい仕事をやれるのは、運が必要。(残念ながら)
→ ただし、コントロールすることができる
■ やりたいことを社内外に発信する重要性
・特に社内にも発信することを発信することが大切
→ 確かに。自分のbitbucket公開しよう
・1,2日で終わるハッカソンやジャムに言って成果物を出そう(だそう)
・上司の顔見るたび「○○やりたいです」を言う
→ 誰かの記憶に残るようにする!
上↑の行動を起こすことで、運を引き寄せる
■ キャリアパスに沿った環境選び
部署異動で解決するなら、したら良い
できないなら、転職しよう
転職する際、マイナス感情で動かしてはいけない
☓ ブラックだから、人間関係が苦手 (冷静さを見失う)
○ スキルアップ、チャレンジができる
→ マイナス面は、入ってみないとわからない。
→ プラス面は、メリットがある分、気持ちが保てる。
運を引き寄せる行動をとろう
17:05【B-9】大規模プロジェクトの制作裏話~改善から成し遂げるまでのプロセス~
登壇:畠山
内容
■ 自己紹介
・企画職を希望していたが、エンジニアになった
・エンドロールに自分の名前が乗ることが夢だった。
→ エンドロールの実装することに、夢を達成してしまった!
次の異動するまでの目標
「企画書→実装→リリースをする」こと
■ 課題と感じること
・スケジュール上では空き時間があるのに、いつも開発に追われる
・タスクが思った以上に進まない
・会議が多すぎる
・開発以外のタスクのせいで、開発できない
・質問の時間が多い
■ 質問への課題
プロジェクトに紐付いた環境に依存する質問
今回はスルー
新しく配属された方の制作手順に関する質問
テンプレ的な質問が減らない
実装が仕様
特殊処理は、共有されない
人員増加のせいで、開発スピードが遅くなる(導入資料が少ない)
ドキュメントの更新が遅れている
■ 質問への解決
ドキュメント運用化資料
画面仕様書、クライアントエンジニア、チケット、デバッグ便利機能の使い方
全部署が見えるようにする
Wikiが多いので、周知作業、整理
誰が見てもどこから見てもわかるようにする(データ元をリンクする)
ドキュメント作成・メンテナンスは、後回しにせず、積極的にしないといけない。
17:45【B-10】Hello, Cloud Native Apps!
登壇:加藤 ゆう
内容
■ 自己紹介
kubernetesを使いたい!(プロダクションに入れたい!)というモチベーションがあり、入社した。
会社の内情を聞いてみて、合うところがあったそう。
★ GKE, Spanner, Kubernetes ができる♪
■ Kubernetesを取り入れる
環境構築・・
デプロイ・・
構成変更・・
プロジェクトごとに秘伝のたれを使うため、よくわからなくなる
→ ゲーム作成に関係ないのに、時間を割いてしまうのはよろしくない
プロジェクト移行を始めた
PROJECT 1: Spanner移行
PROJECT 2: Spanner + GKE移行
PROJECT N: Spanner + GKE
■ MySQL → Spanner
移行作業
PrimaryKeyの変更
FORCE_INDEX対応
インデックス効かないから、forceする。
インターリーブ対応
インデックスの見直し
orderByができなくなるため?
(マスタースレーブの概念がないため、BigQueryを使う)
↓
PROJECT 1で、GKE移行を一緒にすることになった。
■ GKE
→ Kubernetesのマネージドサービス。このあたり、自動にやってくれるので便利
移行作業
アプリケーションのDocker化
Dockerfile作成
ローカル環境の移行
Kubernatesのマニフェストを作成
helm chart化(namespaceで環境切り替えする)
GKE・Kubernatesの機能検証
nodeでautoScaleしたとき、死んでほしくないnodeを死なせないようにするのが難しかった。
■ GKEを使ってメリットと感じた点
コンテナ化によって、立ち上げ・壊すがめっちゃ簡単
秒で立ち上がり死んでいく(ボットが勝手に死んで、勝手に生き返る)
環境ごとに設定ファイルを分ける必要がない
適切な設定がすべて環境変数で取ってこれる
Serviceリソースのよってエンドポイントを一元化
■ GKEを使って問題になった点
ログどうする問題
コンテナがすぐしんで、消える(ログも消える)
デフォルトは、stack driverに出すが、自前でfluentdに飛ばすようにした
↓
GCPのアプリケーションログで見れる
エラーレポーティングで、エラーが一箇所になった
2. デプロイどこでする問題
ローカルでイメージをビルドすると結局中身の保証がしづらい。
→ CLIで手動オペは危うい(タグの設定とかがそう)
→ Spinnakerを導入
Dev. GitLabでpush → Spinnaker で監視 → 自動でデプロイ → slack通知
Prod. 自動デプロイは怖いから、そこは手動。確認ボタンでSpinnakerが待ってくれている。
■ 今後やりたいこと
・マイクロサービス化、マネージドサービス化、DockerやKubernatesひろめたい
18:10【B-11】Docker/KubernetesによるCloud Nativeな開発と未来
登壇:青山 真也
内容
■ 自己紹介
・Kubernates完全ガイドという著者
・Kubernatesが好きすぎる
・Kubernetes Contributors Summit + KubeCon + CloudNativeCon に参加してきた。
■ Kubernetesの紹介
Container Orchestration Engine が必要な理由
▼ そもそも、CloudNativeとは?
→ Kubernetesは、Linux FoundationのサブプロジェクトCNCF
(Cloud Native Computing Foundation)
定義をざっくりと
疎結合なシステム
復元する
管理しやすい
可観測できる
堅牢な自動化
頻発かつ期待通りに最小限の労力で大きな変更
Cloud Native Ecosystem
→ 中心にあるのが、 Kubernates
▼ Kubernatesの良いところ
Declarative Code & APIs
yamlで書かれている
これがめちゃめちゃ良い。時間がないため割愛
以下の機能が良い
ReplicaSet
Self-Healing
Rolling Update (Automation)
Kubernetesは、Googleが社内で長年使っていた BorgをベースにOSS化
Microservice Architectureとの相性が良い
つなげるときは、gRPC がよい(HTTP)
Netflix, twitterは、500+のmicroservices
みんな、やりたくてやったのではない。巨大化になって分割しようとする。
Service Mesh
Kubernates は MySQL、AWS, GCP なんでも動かせる
operator framework
Kubernatesは、GCP, Azure, AWSで使われているので需要は高い
・Knative, Kubeflow が流行る?
follw me: @amsy810 , OSS活動も積極的