DevSumi 2019
TL;DR
例年雅叙園で行われるオープン・Web系技術カンファレンス
今回は2日目の午後のみ参加
聞いた講演
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ -
Elixirを実際に使い込んだ人ならではの本当の楽しさ、辛さが滲み出ていた。自分もElixir使ってみようかな
プロダクトオーナー の立場で データドリブンなグロースハックをする話。KPIを設定する際の選定基準について詳しく話していて参考になった
セキュアな環境でDevOpsを実現する厳選ツール
セガゲームスにおける github Enterprise の導入事例。 git自体は今更感があるが、新しい技術を会社組織に導入した事例としては、大いに参考になった
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方
講演者のエンジニアとしてのリタイアするまでの約40年のキャリアを、コンピューターの歴史と共に振り返る講演
これも聞いてみたかった
システムエンジニアは空を飛ぶ夢を見れるのか～普通のSEがドローン系SEになるまで～（佐藤 明）
Site Reliability Engineering at Google（中井 悦司[グーグル・クラウド・ジャパン]）
これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ -
発表者
幾田 雅仁
gumi Inc. CTO
2014年 Elixirと出会う
Web開発者の悩み
- 複雑化するコード
- 肥大化するサーバー構成
- 増え続けるクライアント
- 素早くリリースしたい
- 複雑化するサーバー構成
Web開発の辛さを改善し、以下の3つを実現するのが Elixir/Erlang
gumiでの利用実例
流行ってない
Elixir/ErlangはWeb開発のための優秀なツールが完備されているのに…
- サーバー構成をシンプルに保てるのに
- コードをシンプルに保てるのに
- 夜寝れるのに
- 流行ってない
- 転職サイトの求人数でみるとRubyの100分の一
なぜ流行らない？
- 学習コストが高い（と思われている）× 実際のWeb開発では納期が短い
- ＝Elixir採用されない
学習コストが高い（とも思われている）要素
実は、Webシステムの開発に限定すれば、学習コストは高くも低くもない
学ぶことと学ばないことを取捨選択して学習コストする
- 学習コストを割くこと
- しばらく学習コストを割かないこと
- 逐次処理を書くだけで軽量プロセスの恩恵を享受できる
- よって、しばらく、並行処理は忘れてよい
- 学習コストを払うのも後回しでよい
並行処理
独立したCPUを持つ
- ErlangVM(EVM)上で動くPhoenixの動作
- PhoenixではEVM上にCowboyプロセスが常駐
- Cowboyプロセスがhttpリクエストを受けたら、個別のリクエスト毎に軽量プロセスを生成して軽量プロセスがリクエストに対する処理を行う
- この動きは、OS上でApacheが動く仕組みと似ている
- EVM = OS
- Cowboy = Web Server(Apache)
- 軽量プロセス = CGI
- iex = Shell
- コンテキストスイッチはEVMに任せ、軽量プロセス上で動く処理は逐次処理として書くだけでよい
- 一つの逐次処理の負荷が他の処理に影響しにくい
ネットワーク上の一意なアドレスを持つ
- EVMは軽量プロセスに一意なアドレスを割り当てる
- アドレスを使って軽量プロセス間で通信できる
- 軽量プロセス同士をlinkすることができて、片方で異常が起きたらもう一方へと知らせてくれる
EVM(Erlang VirtualMachine)＝OSと似たプロセスの仕組みを持つ
- 軽量プロセスは耐障害性を向上する
- 速さは…中程度
- 結果として、並行処理の学習コスト不要で、ほどほどに遅くない、とても楽で安全
関数型
巷で噂されている良い話
- 副作用が少ない
- データ処理に集中できる
- gotoは処理フローの迷子
- OOは状態の迷子
そのような話は前提条件が誤り
- Elixirは純粋な関数型ではないから…
- 関数型由来の仕組みが少ない
- OO由来の仕組みが少ない
- 複雑さが排除されていて、理解するための文脈が少ない
- 参照等価な関数で表現できることが多い
- e.g. 演算子、例外、IOなどが関数で表現されている
Elixirはあまり純粋ではない
Elixirらしいコードの読み書きを学ぶおすすめの学習方法
- プログラミングElixir
- Elixir入門
- Elixir School
- Phoenix GUIDES
初歩 - プログラミングElixirを読む前に…
- リスト
- 活用のカギは構造と再帰
- リストを再帰でどう使うか解説
- Enum
- filter, map, sort 等
- 関数がたくさんあるが、よく使うものから覚える
- まずは、プログラミングElixirやElixirSchoolで紹介されている関数を覚えるとよい
- _by, _while, _every サフィックスを覚える
- パイプライン
- パイプラインの存在意義は、関数定義に一貫性が生じること
- パイプラインが使えるように関数を定義する癖をつけよう
- パイプラインはJavaScriptにも入るかも
- do
- do内にはスコープがあるのでif文が読みやすくなる
EVMについて
EVMは高機能
機能があると使いたくなる…が、Webシステム開発ではほぼ必要ない
Elixirの用途を割り切るため断捨離
関数型とOOについて - 混線する関数型とOO
OOにどっぷり漬かっている人はモジュールをクラス定義のように使ってしまう
- モジュール単位で抽象化するのはやめよう＞やるなら関数単位で
と覚える
マクロは高機能
- マクロは言語作者が楽をする機能
- あまりに強力すぎるので使わないようにしよう
- ともあれ、マクロを書けなくても、読めるようになったほうが良い
まとめ
- EVMは高機能だが断捨離しよう
- モジュールで設計（抽象化）するな、関数中心で考えよう
講演者
- プロダクトのグロースはS字カーブをたどる
- 複数回の改善で連続したS字カーブをたどるのが理想
- プロダクトグロース = 改善の繰り返し = データドリブン
データ駆動戦略とは何か？
- データドリブンに戦略を組み立てていく
- 不確実性に強い組織へ
Why
なぜデータドリブン？
- 直観に頼る仮説は量産されがち > 開発者を圧迫する
- リリース後にデータがないと学習できない、次の仮説が立てづらい
What
データ駆動戦略で何ができるのか
- プロダクトの状態を可視化できる
- 仮説／施策を作り、売り上げに貢献できる
- 意思決定を最速化できる
- 意思決定を定量的に共有できる
- 未来を予測して戦略が作れる
How to
データ駆動戦略における3種の神器 を駆使して行う
- データ分析基盤
- 優れた指標 - 指標に基づくKPI
- 開発プロセス - リーン・アジャイル・アジャイルマーケティング
DMMには40以上のサービスがある
自己組織化したチームにおいて、Product Owner の強い味方が データアナリスト である
データアナリストはプロダクトオーナーとデータを見ながら日々会話する
購買ログ、レコメンド履歴、行動ログなどのBigDataに蓄積
データアナリストがデータ分析を行って仮説立案する
データアナリスト×プロダクトオーナー が、データドリブンで仮説立案→意思決定する
ユーザーレビュー基盤プロダクトについて
コンテンツに対するユーザーレビューは購入決定の強力な動機
70%以上のユーザーが、レビューを見て購入の決定をしているという統計結果もある
DMMでは、サービスで利用されるユーザーレビューの仕組みは一つのプロダクトチームが専門で開発、運用している
データを一元管理することにより、データドリブンな開発が可能になる
- 星の数・コメント・平均評価
- 参考になった数・いいね押下ユーザー
- レビューのどこまでスクロールしたか
- レビューを見た後の行動（購入・カード追加・離脱）
データ分析基盤について
データ駆動戦略は組織として進行しないとビジネス価値が集まらず、効果は薄い
データ駆動がもたらすメリットを定量的にデータを使って提示しなければいけない
データアナリストが分析しやすいデータ分析基盤を構築しなければならない
- データ基盤の規模
- テーブル数：数千テーブル
- 総レコード数：数億レコード（感想：DMMの規模で数億は少なくない？）
- BIツール：Redash
優れた指標でないとデータは「駆動」しない
- データが駆動する とは？
- データを見ることで 次の行動 につながること
- Action → Result → Next Action
優れた指標の3つの土台と4つの指標
3つの土台
- 優れた指標は 比較 ができる
- 優れた指標は わかりやすい
- 優れた指標は 比率 や 割合 である
4つの指標
- 定量的指標 vs 定量的指標
- 定性的 = 主観的で感覚的な指標 インタビュー・調査・クレームなど
- 定量的 = 科学的数値な指標 - 会員登録数・売上金額など
- ユーザーレビューにあてはめて考えると
- 書く人の定量的指標は
- レビュー増加率（CV)
- レビュアー増加率（CV)
- レビュアー種別増加率
- 見る人の定量的指標は
- 虚栄の指標 vs 本物の指標
- 虚栄の指標 = 次の行動につながらない指標
- 本物の指標 = 次の行動につながる指標
- ex. 会員登録数+離脱率+アクティブユーザー率
- 会員登録数だけ見ると虚栄だが、他の指標と合わせてみると次の行動につながる
- ユーザーレビューに当てはめて考えると
- 先行指標 vs 遅行指標
- 先行指標 = 未来を予測した指標
- 遅行指標 = 変動後の数値を示す指標
- 相関指標 vs 因果指標
- 相関指標 = AとBが関係していること
- 因果指標 = AtoBであること
- ex. 「交番の量」が多いほど「犯罪件数」が多い → 鋼板を減らしても犯罪は減らない。相関関係であっても因果関係ではない
未来を変えたい指標があって、その指標と因果関係になっている指標を見つけたい！
- 因果関係を探すために、相関関係がありそうな数値をグラフ化してモニタリングし続ける
ユーザーレビューで使っているKPIツリーを公開！（ここが本講演の目玉）
- レビュー増加率
- レビュー投稿増加率（星のみ）
- レビュー投稿増加率（コメントあり）
- レビュー掲載コンテンツ率
- レビュー投稿→承認タイムラグ日数
- レビュアー増加率
- レビュー閲覧率
- レビュー先頭閲覧率
- レビュー末端閲覧率
- レビュー「次へ」閲覧率
- レビュー経由購入率
- LEARN → IDEA
- 仮説に妥当性を持たせる検証 (ex. A/Bテスト等)
- 仮説立案
- 事前に検証をすることで、開発しなくていい機能を減らす
- BUILD → PRODUCT
- アジャイルでリードタイムを短くMVPを開発 → リリース
- MEASURE → DATA
- データサイエンスをもとにデータを計測 → KPIに落とし込む
- キャンペーン中に「ニアタイム」でデータを取得。小さく初めて、小さく改善をデータ駆動で高速で繰り返す
- 過去のキャンペーンのデータを必ず蓄積して計測する。そこから計測→学習して次のキャンペーンにつなげる
事例：購入した商品にレビューするだけで、1レビュー10ポイントをプレゼント
- 想定される効果
- レビューが増えると購入意欲が上がるので売り上げが伸びると予想される
- レビュー数0→ 1、 1→2、 2→3でコンテンツ当たりの売り上げ増加見込みは違う
- それぞれのパターン×コンテンツ当たり売上増加見込み×コンテンツ数で増加額を予測する
- キャンペーンを終了させる基準
- 予算に対して費用がペイしているかを毎月確認していく
- ROI や ROAS を指標とする
- 大きく成功した際、どこにリソースを再配分するか
セキュアな環境でDevOpsを実現する厳選ツール
講演１
GitHub Enterprise 導入から定着までにやってきたこと
講演者
はじめに
- 3年前(2016/1)は…
- 今現在は…
- 全員がGitHubEnterpriseを利用
- アカウント数 450
- Organization数 35
- リポジトリ数 630
- CircleCIなどとも連携
本日伝えたいこと
- 何をして導入を進め定着させたか
- 人員・サポート方法・会社への説明・現場の声・活用方法
導入から定着させるまでの参考になれば
試験導入
2016/2 導入委員会立ち上げ
- 3名で片手間
- 小さいチームへの導入サポート
- VMサーバー整備
- 自分たちもGitHubの勉強をしながら
2016/5 新規プロジェクトで導入開始
- 新プロジェクト立ち上げ時に導入
- 50ライセンス購入
- 利用者向けの説明会などサポート開始
2016/9 導入規模の拡大
- 利用プロジェクトの規模拡大に合わせて100ライセンスに増量
- 委員会3人中、1人はGitHub専任に
- 物理サーバー整備
採用プロジェクトを増やすよりも、同プロジェクトの人数が増える方が導入がスムーズ
プロジェクトメンバー同士で教えあってくれるので。
2016/10 正式な物理サーバーを導入
- CPU 8コア
- メモリ 128GB
- ディスク 4TB SSD
- トラブルなし
会社に対し正式導入を提案
2016/12 正式な導入へ向けて
- もうすでにSVNへは後戻りできないプロジェクトができ始めている
- 利用しているプロジェクトからのポジティブな意見
- サポート人数も増やす必要がある
ネガティブ意見への対応
- SVNではダメなのか
- レビューの価値がよくわからない
- ゲームアプリのビルドは数時間かかるので、ビルド前にレビューすることによって手戻りの時間コストを減らせる と、具体的なコスト見積もり数字を出して説得した
- 無料のGitHubクローンではだめなのか
説明の結果、本格導入決定となった
正式導入
- 改めてサポートを強化した
- 使い方ドキュメントとの拡充
- 社内ハンズオンの実施
- 新しく使い始める人全員に実施
- 1時間程度
- 概要、プルリク、ツールの使い方
- 教わる人は理解しやすくなるし、サポート側はその後のサポートコストが減る
- トラブル対応
- Gitのトラブル
- 巻き戻り、コミットできない、プルできない
- 呼ばれたらすぐに飛んで行って解決
アンケートからの振り返りと対策
2018/1 アンケート実施
- Gitの理解度 - ほぼ全員が普段の操作は支障なく行えるようになった
- 作業フロー - プルリクを作成する人が全体の85%
- まあまあ使えている
- ゲーム開発ではすべてのファイル（ゲームパラメータの設定ファイル、画像ファイル、コード）がリポジトリに入っているので、プランナーやデザイナーもGitHubを利用せざるを得ない
アンケートではエンジニア以外のメンバーからはネガティブなコメントも
- 概念が難しい
- 操作が大変
- 衝突時やマージ時の解決が大変
- 良く巻き戻りが発生して大変
- ローカルの変更ファイルでプルできない
- SVNに戻してほしい
非エンジニア向けに独自のGitHubクライアント(Pengit)を作成して対応した
- Gitの学習コストの大幅な削減
- 行える操作をある程度絞って簡略化
- プルリク発行までの簡潔な作業フロー
- 分かりやすい競合解決
- 親しみやすいエクスプローラー風画面
- 日本語によるUIやエラーメッセージ
定着へ
- 社内ハンズオン依頼が減少
- エンジニア以外からのトラブル対応依頼も減少
- 終了PJの振り返りで効果が認められ始める
CircleCI Enterpriseの導入
- Enterprise版(社内サーバー)
- ローカルのDockerレジストリ
- ローカルでセキュアな環境
- GHEとの最高の組み合わせ
GHEとPengitの持つデータの活用
- 作業内容の可視化
- プロジェクトごとの特性などを分析
- データは蓄積しつつある状態
まとめ
- 規模が拡大しそうな小さいPJへの導入がおすすめ
- ネガティブ意見への丁寧な説明の準備
- 利用し始める人へのハンズオンの実施
- アンケート、振り返りの実施
- （理解が深まらないなら）サポートツールで対応
- CircleCIなど他のシステムとの連携
- GHEの持つデータの活用
講演２
根本 竜也[マクニカネットワークス]
代理店の講演
内容は、ソフトウェアリリースプラットフォーム JFrog の宣伝
JFrogはソフトウェアリリースのための複数のツールの集合である
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方
講演者
DEC, Oracleに勤務後、MiracleLinux創業メンバーとなる
60歳で定年退職後は大学院に入りひたすら論文を読み、問題を発見する訓練を続ける
散漫とした講演だったが、70’以降のコンピュータ歴史年表は感慨深いものがあったのでまとめておく
|
年
|
できごと
|
|
|
1971
|
|
世界初の1チップマイクロプロセッサ
パーソナルコンピューター発展の基礎
|
|
1975
|
|
|
|
1977
|
|
初期のパーソナルコンピューター
|
|
1977
|
|
信用できないネットワーク上でもセキュアな通信ができるように
|
|
1980
|
|
LAN
|
|
1981
|
|
豊富なソフトウェアでエコシステムを形成、企業向けコンピューター製造販売最大手がPC市場に殴り込み
|
|
|
|
|
|
1988
|
|
ソフトウェア国際化の嚆矢
|
|
1989
|
|
Webの起源
|
|
1991
|
Web site が作られるように
|
|
|
1993
|
|
グラフィカルなブラウザ
|
|
1994
|
|
|
|
1995
|
|
|
|
1998
|
|
|
|
2000
|
ITバブル
|
|
|
2004
|
|
|
|
2007
|
|
講演者は出た当時、影響力を過小評価してしまった
|
|
2009
|
|
|
|
2012
|
深層学習
|
画像認識の分野で画期的な精度を実現したことで一気にブームに
|
