2019-02-15 Developers Summit 2019 Day2
2019/02/15 に開催された Developers Summit 2019 Day2 のイベントレポートです。
■Day1 の様子
■カイゼン・ジャーニーから見つかった新たなfunと前進への旅路
新井 剛さん [ヴァル研究所・エナジャイル]
●新たな出会い
・4つの役割
時間のコントロール大変
出会い 他業界、国外企業、社外講演
・共通の悩み
いつの時代も同じことを悩んでいる
人間関係論
管理プロセス
一般システム理論系
●組織の変え方
・コンウェイの法則
・カイゼン・ジャーニー カオスマップ
3F シリウスで配ってます
チームは今どこにいるのか
課題に合わせたフレームワークを使おう
・トリプルループ学習
スピードカイゼン
プロセスと構造
イノベーション
・長期的視点で組織育成が大切
●組織のあり方
・チェンジ・エージェントは組織の中に増えてきた
自己実現したい熱意ある人
・Give & Take
taker
matcher
giver 他人にプラスの影響を与える
他者指向の成功するgiver
自己犠牲的なgiver
・チェンジ・エージェントの評価が必要
役割によるので評価方法も変えなくちゃ
・本気度を見抜く
管理職の意思決定の経験は本物！
直談判していこう
・それでも咎められるのであれば、いる場所ではないのかもしれない
・自ら機会を作り出し、機会によって自らを変えよ
●Fun
・調整役(ガーディアン)が必要になってきた
・whyは大脳辺縁系から生まれる -> 感情
貢献 することで 影響 になる
・チームには 瞬間的な犠牲はあるが 常にはない
・支援する側はされる側から見るとプロ
でも関係は公平であるべき
・社内に帰るとがっかりするよね
デブサミに来ている時点で大きな一歩
・仕事とは企てること
・あの働
カオスマップは3連休でつくったw
仕事でも、遊びでも、金儲けでもない
・簡単には餓死しなそうだ
・未来は何が起きるかわからない
ビッグバン時点で、今日の登壇が決まってたらかなしい
一瞬・刹那を大切に
未来に向けて、目の前の機会に飛び込んでいこう
■我々に越境できない境界は無い。
市谷 聡啓さん [ギルドワークス]
自分の時間だ、自分の話をしようw
・カイゼン・ジャーニーとはなんだったのか？
自分のジャーニーを表現した、そのもの
人との関わりがあったからこそ
・問いを投げたら、打ち返してくれる人がいた
直接会いに行った
70回以上
買ってきたボールがボーリング玉の人もいたw
自分たちで動いたら良い
・場が必要なんだな
自分が先達から、組織を超えた学びの場
気の狂った人たちw
スペースを作って、次の世代に渡す
・DevLOVE に帰ってきた
戻るべき場所 = 自分が居場所と決めた所
・個人になる選択が乏しい
人間をリソースとして扱える時代は終わる
一人の時間をシェアするポートフォリオに
・ギグ化する社会、複業の時代
ぼっちにはなりやすい
自立しながらチームが得られる場
・The Agile Guild
ベースは、spotify の agile guild model
共通する信念があるから、チームになる
・チームの有り様でデザインする
役割
交流の場
ルール
共有されたミッション
-> 中村主水すごいw
・自分は何者なのか？
むきなおりの時間は意図的につくる
チーム、プロダクト、事業、組織、社会 は越境できる
slideshare見てね
「こうありたい」から捉え直す
・人と人との関わりを 取引 -> 共創 に変えたい
信用 -> 信頼
・ともにつくる の境界
ギルドのクラス制度
ギルドの多様性
チームビルドは、プロジェクトがはじめてからでは遅い
師範を市販する ShihanWorks
自分たちに足りないスキル、経験を一点集中で補う
狂気なメンバーが集っている
プロダクト開発のための GuildHub
仮説、プロダクトバックログをつないでいく
・正解がない -> あらゆる手段を取りうる -> 振れ幅最大
手段に恋をしない。
他が選べなくなる
目的に忠誠を誓え。
これでいいんだっけ？を問い続ける
・正しいものを正しくつくる
・逆境からの越境
・まだまだストレンジ・ジャーニーは続く
あなたはどんな作品に自分の名前を残すのか
エンドロールに自分の名前を残すならどんな作品か？
■CI/CDを使い倒して数段上のソフトウェア開発をしよう！
金 洋国さん [CircleCI]
●CI/CD戦国時代
・大手が進出
・古株が買収されて統合
●CircleCI Japan
・日本語で問い合わせできます！
日本語の問い合わせが少ないことが課題W
●What is CI?
・なぜテストを書くべきか
手順をくり課さないといけない
人では見落としやミスが発生
-> コンピュータにやらせよう
・CIはテストを自動で実行する仕組み
●Why CI?
・テストを書くだけでは不十分
あるけど実行し忘れた
昔のテストが壊れている
環境依存
-> 信頼性がない
・テストの実行し忘れ
-> VCSの変更を検知して実行
・テストが壊れる
原因がコードかテストかわからない
-> 壊れた時点で検知
「使われていない自動化は壊れていく」
・テストが環境依存
false nagative問題
-> 毎回、同じ環境で、クリーンに実行
・CIは新陳代謝を高めて信頼性を上げる
●Why Not CI?
・一番厄介な問題: テストがない
・テストがなくてもCIをはじめられる
1. CI/CDツールを選ぶ
2. テスト以外のタスクを自動化
linting
カバレッジ
静的解析
ドキュメント生成
3. CI結果を可視化
ステータスバッジ
ダッシュボード
メール・チャットでの通知
-> チームに興味が生まれる
4. マージブロック有効化
5. 少しずつテストを追加
UTは後回し
ビジネスロジックから
頑張りすぎないで
・問題: メンテナンス
CI/CDのメンテは大変: Jenkinsおじさん問題
-> クラウド型
●Beyond CI
・開発フロー
push -> CI -> master merge -> リリース
●What is CD?
・Delivery？ Deployment？
Deliveryは、人間の意思が介在
Deploymentは、自動でデプロイ
・広義の継続的デリバリー
ビジネス価値を継続的にデリバリーしていくこと
・デプロイとリリース
デプロイ: コードを配置すること
リリース: 配置したコードで、トラフィックをさばく
●Why CD?
・よくある問題
検証環境でみつからなった問題が露呈
-> フィードバックループを早く回そう
・CIなしだとループが回らない
許可、ヒューマンエラー
・No CD, No Feedback Loop
●Why Not CD?
・技術的な問題
アーキテクチャがCDに向いていない
エンプラ、レガシー
-> 時間をかけてアップデート
マイクロサービス化
徐々にモダン化
・組織的な問題
誰か教えてください
エンジニアリング組織論への招待 読んでね。
・最初からクライマックスだぜ！
CI/CDは、建物でいう「基礎」
-> 新システムを作るなら、初めから
●CircleCIでの事例
・Before
200台異常のビルドマシンのフリーと
ChatOpsでデプロイ
2日かかる
-> しばらく新旧が混在
・CDを導入
1年かけて
Docker/k8s
マイクロサービス化
●Beyond
・迅速なロールバック
git revert -> CD -> 修正完了
= gitの一つ前のコミットをリリース
・本番環境でのテスト
テストするべき範囲
CI/CDでテスト可能な部分
外部サービス
ビジネス要求試用
トラフィック・負荷
-> 本番環境でしか確認できない
リリースしてみないと結局わかない！
いかに安全に、迅速に進めるか
DevOps, Agile, Lean
・高度なリリース手法
カナリー、ブルー・グリーン
・プログラミングに対する心理的安全
-> CI/CD Makes Programming FUN!!
●CI/CDの未来
・CI -> CDelivery -> CDeployment -> ?
・自動化で進化してきた = 今何を手動でやっている？
・CI/CDの設定
・モニタリング
・デプロイ環境の構築
・first commit からクライマックス!!
■機械学習システムのアーキテクチャ アラカルト ～ BrainPad における実例を交えて～
太田 満久さん [ブレインパッド]
機械学習のシステムを構築して運用に乗せるのは大変
ベストプラクティスもまだない
●機械学習の基本
・典型的な機械学習システム
特集 機械学習高額 情報処理 vol 60
推論フェーズ、訓練フェーズ
・データから、システムの挙動をつくる
・特有の難しさは訓練フェーズ
簡単にするなら
訓練パイプラインを自作しない
-> API使う
・はじめの一歩
1. やりたいことに機械学習は必要か？
2. 既存API(訓練なし)で実現できないか？
3. 既存API(訓練あり)で実現できないか？
4. 既存の訓練モデルで実現できないか？
5. 独自のデータを使ってモデルを訓練する
●既存API(訓練なし)をつかう
・前処理で使う
・フィルタリング: 顔の検出
・モザイク処理: ナンバープレート検出
：
・自前の処理
●既存API(訓練あり)をつかう
・Cloud AutoML
機械学習エンジニアがライトに構築したモデル
開発エンジニアが構築したモデル
でほぼ同じ精度
・オンライン推論
ロードバランサを噛ませて
ABテスト
ブルー・グリーン
前処理はどこでやる？
モデルによって違うから、各推論サーバ
・バッチ推論
非機能要件がゆるい
-> 複雑な前処理、複雑なモデルを使える
・訓練の頻度
1. 不要
2. システム化は不要
PoCで構築したモデルを利用
3. 訓練と更新の仕組みが必要
定期的な更新
●PoCで構築したモデルを利用
トイレはトイレ、居間は居間 なら、更新不要
バージョンアップに近いイメージ
人が監視
●PoCのモデルで十分でない例
フリマの画像など
新しい商品が次々と出てくるもの
傾向や対象範囲が変わるもの
-> 精度を評価するときは、新しいデータが必要
●はずれチェックの例
スピードが必要だから、訓練済みモデルをエッジに載せる
ログ、データをバッチでクラウドにup
訓練済みモデルを配信
■Less Code & Have Fun! IoTアプリ開発をはじめる際のポイント
山崎 亘さん [ウフル]
●そもそもIoTアプリの開発って…
・デバイスからデータを取って処理する
デバイス： 組込開発？
データを取って： Arduino, C/C++？
処理する：クラウドにデータを持っていく？
・センサーからデータ取得
ネットではなく、リアルワールドにある
現場によって変わってくる
・試行錯誤を早く回して精度の向上
IoTの基本・仕組み・重要事項が全部わかる教科書
DevとOpsが行ったり来たりする
・こうしたい
複数のテクノロジーを簡単に扱えると良い
PDCAサイクルのスピードを早くできると良い
●SHARE MY FUN!
・Node-RED
ノードをつないでデバイスとのやりとりも作れます
・使い始める
Install
Managed
enebular
●IoTアプリを開発してみる
・シナリオ
実家の母親が、暑すぎたり、寒すぎたりするときに、空調などを対応するように促してあげたい。
・要件
既定値以下 or 以上の気温になったら、遠隔地 に通知する
・実機を置くのは大変そう
蹴られたら、電源抜かれたら
Amazonで検索
Netatmo Weather Station
・enebular editor
electron版のNode-REDフローエディタ
フローエディタなら
条件の試行錯誤くらいなら、高速にできる
クラウドサービス間でのデータやりとり
Netatmo -データ受け渡し-> enebular -デプロイ-> Heroku
・RaspberryPiで動くフローも作れます
ブースで小冊子配ってます
全てのRaspberryPiへのデプロイって、個別だと大変
AWS IoTなどを使って、遠隔地のセンサー全てにリモートデプロイ
・可視化
enebular -> Firebase -> enebular InfoMotion
状況が把握しやすい -> PDCAサイクルを回しやすい
●Step Upしてみよう！
・ループ処理とかもノンコーディング？
もちろん。
blog.enebular.com/enebular/
・NodeNode-RED デザインパターン
Node-RED界のバイブル
目からウロコ！Node-REDのデザインパターン10選
・NodeNode-RED アンチパターン
4年後のアンサーソングw
目からウロコ！Node-REDのアンチパターン10選
・小さなチーム -> 会社の場合
役割に応じた権限付与
役割
Project Owner
Project Collaborator
Outside Collaborator
・大きなチーム -> コミュニティの場合
IoT開発資産の公開/共有
Discoverで、Flow, InfoMotionのアセットが見れる
LINE clova向けのassetもある
VUIもサクッと繋げられる
・発表してみよう！
enebular developer Meetup vol.8 2/28
・キャンペーン中
enebular のノウハウや開発例を投稿
enebular developer Meetup でLT
-> Tシャツもらえます
●まとめ
・コーディング減らそう
・試行錯誤を低コストで高速に
・先人の知恵を借りよう
●コードを書いた方が早くない？
デバイス、複数クラウド テクノロジーなどが重なると
わかりにくくなってくる
-> enebular便利
■プロダクトをGrowthさせるデータ駆動戦略の基礎知識～DMM.comにおけるユーザーレビュー基盤のKPIツリー公開～
石垣 雅人さん [DMM.com]
●つねに問われ続けている
プロダクトをGrowthさせたいですか？
どうやってやりますか？
その道具は手元にありますか？
●どう実現するか？
GrowthのS字カーブを機能ごとに重ねていきたい
Product Growth = Data-Driven
●データ駆動戦略とは何か？
1. データ・ドリブンに戦略を組み立てていく
2. 不確実性に強い組織へ
-> データを使って、どう不確実性と戦っていくか
・よくある流れ
直感に頼る仮説
量産されやすい
PBLが肥大化して開発者を圧迫
-> スーパー経営者だったらそれでも良いけどね
開発->リリース
効果検証
リリース後にデータがないと、学べず一発屋になりやすい
・データ戦略で何ができるのか？
1. プロダクトの状態を可視化
2. 仮説/施策を作り、売上に貢献
3. 意思決定を最速化
4. 意思決定を定量的に共有
5. 未来を予測して戦略が作れる
・三種の神器
データ分析基盤
優れた指標
開発プロセス
●組織
・DMMでは
・SoE
BtoC
・SoR
BtoB
-> ドメインごとに自己組織化したスクラムチーム
・POの強い味方 = データアナリスト
BigData
ユーザ行動ログ
購買履歴
データアナリスト x プロダクトオーナー
仮説立案 + 意思決定
●どんなデータ？
・ユーザーレビュー
1チームで管理
行動ログ
星の数、コメント、平均評価
スクロール位置
離脱率
：
●データ分析基盤
・優れたデータ基盤がないと戦略が立てられない
・BIツール
Re:dash
権限があれば誰でもクエリを打てる
営業にも教育中
●優れた指標
・データが駆動するとは？
データをみることで次の行動につながる
Action -> Result -> NextAction
・優れた土台
比較できる
他者、時間軸など
分かりやすい
数字を追う文化につなげる
比率や割合
数に意味がないことが多い、割合。
・定性的
インタビュー、調査、クレーム
・定量的
登録数、売上
・定量的な指標
・レビューを書く人
レビュー増加率
星だけ・コメント付きレビュー増加率
レビュアー増加率
レビュアー種別増加率
購入済レビュアー率
未購入レビュアー率
・レビューを見る人
レビュー経由購入率
見ただけでは意味がない
・虚栄の指標 = 次の行動につながらない指標
会員登録数 = 時間経過で増える
・本物の指標 = 行動につながる
会員登録率 + 離脱率 + アクティブユーザー率
-> 新規レビュアー率、アクティブレビュアー率
・先行指標 = 未来を予測
3ヶ月後のレビュー数を予測
・遅行指標 = 変動後の数値
チャーン
離脱率
・相関指標
AとBが関係している
・因果指標
A to Bであること
-> これがほしい
因果関係を探すために、相関関係がありそうなデータをモニタリング
・KPIツリー
レビュー増加率
レビュアー増加率
レビュー閲覧率
●開発プロセス
・リンスタのBMLループ
・Learn/Idea: 仮説に妥当性をもたせる
・Build/Product: スクラム開発
・Measure/Data: データ基盤に必ず貯まる
●キャンペーン実施方法
・アジャイルマーケティング
キャンペーン中にニアタイムにデータ取得
常にデータを見ながら、変えていく
過去のキャンペーのデータを必ず蓄積
学習して次のキャンペーンへつなげる
・指標
・想定される効果
・終了させる基準
・どこにリソースを再分布するか
Q: レビューが増えるたびにどのくらい売上が上がるのか？
レビュー、購入増加額、コンテンツ数
Q: いつキャンペーンを終わらせる？
どの様に成果を評価していくかで、終了を見極める
レユー、売上、データ収集
ROI / ROAS
Q: どの様に再分布させる？
どの様に成果を評価していくかで、見極める
どこに割り当てると効果が出るかを仮説検証
■無意味なアラートからの脱却 〜 Datadogを使ってモダンなモニタリングを始めよう 〜
池山 邦彦さん [Datadog]
●なぜアラートの嵐に埋もれるのか？
・監視する必要がない
・通知する必要がない
・1つに引きづられて発泡している
・複数の条件がそろって発砲するべき
DATADOGの社員は猫派が多いw
●Datadogって何？
・モニタリングのSaaS
・いろいろできる
・self serviceしやすい
●レガシーなモニタリングツールでは
クラウド時代のスピードとペースに追いつけない
分散
マイクロサービス
アジャイル
多種tayouna
OSS， SaaSコンポーネント
複数チーム
●なぜモニタリングするの？
・1時間のサービスダウンでの機会損失
amazon: 14億円
・99.999 まで達成する必要ある？
・いち早く気づいて、いち早く回復させるが命題
●可視化の3本柱
・Traces
・Metrics
・Logs
-> これらを組み合わせて状況を理解する
●Why Datadog
・セルフサービス
・250以上のインテグレーション
全てセルフサービス
・すぐに価値を得られる
サイバーマンデーでスパークしたが、入れて1時間で復旧
Cattle, not pets
・メトリクスにタグを付けられる
使い込むと重要になるよ
●モニタリングのポイント
・ワークメトリクス
アプリのKPI
・リソースメトリクス
ワークメトリクスの深掘りに使おう
・イベント
処理が遅延しだしたときに何をした？
・APM
6言語対応中
サービスマップで依存関係が見える
・ログ
ログをクラスタリングして、パターンを分析できる
●アラートの種類
・3段階で考えよう
・記録する
・通知する
・呼び出す
+ 個別にミュート
+ メンテナンスウィンドウ
・検知パターン
閾値、異常検知、外れ値
それらの複合条件
・アラートワークフローで役に立つインテグレーション
UIから簡単にセルフインストール
・外形監視
プライベートベータで公開中
●デモ動画
・ワンライナーでインストール
・tagの変更は /etc/datadog-agent/datadog.yml を編集
Let's explore monitoring in the cloud age.
■エンジニア人生と定年退職、人生100年時代のエンジニアの生き方
よしおかひろたかさん [東京大学大学院]
●還暦です
・体力的に衰えているわけではない
多くの人は延長したりする
定年退職の規定を使ってみた
・最初の会社でプログラマとして働き始めた
どんな進み方をするのかの話
・人生100年時代の、一つのケーススタディ
●パラダイムシフトの時代に生きる
・パラダイム
科学革命の構造
コペルニクスが出てきて、常識と反対のことを言い出す
この、多くが信じている規範がパラダイム
・パラダイムシフト
アノマリーに気づいて、変えていくこと
科学革命の分野でよく使われる
一生に一度あるかないか
●自己紹介的なIT史
・1971: マイクロプロセッサ
・1975: Microsoft BASIC
・1977: AppleIIなど & RSA Public Key Cryptography
インターネットなんて普及してなかったから、誰も気づいてなかった
雑誌 ASCII が創刊
・1980: Ethernet
・1981: IBM PC
破壊的イノベーション
・1984: Macintosh
・1988: Unicode提案
重要性に気づいている人は少なかった
・1989: HTML, HTTP, URL提案
これも重要性に気づいている人は少なかった
破壊的イノベーション
・1991: Web site
・1993: NCSA Mosaic
・1994: Netscape Navigator
・1995: Windows 95
・1998: Netscape/Mozilla OSS
売るソフトをつくっていた。タダにする？
意味がわからない。
・1999: YLUG
・2000: ITバブル
Miracle Linux創業
未踏ソフトウェア
・2004: Facebook, mix, Web2.0
・2007: iPhone
・2008: 勉強会ブーム
情報が流れるのが普通になった
・2009: Bitcoin
・2012: 深層学習
●仕事観
・X: 好きなこと、楽しいこと
・Y: 時代の流れ
・X + Y
-> ものから情報へ
ものを作るイノベーションがあったから、製造業が伸びていた
人間だけが情報を処理できていた
-> コンピュータが処理できるようになった
●ものづくりから情報づくりへ
・たかだか50年程度しか歴史がない
->前例がなくて、変化が前提
・変化がゆっくりのものもある
ノイマン型コンピュータ
●パラダイム
・当たり前過ぎて見えなくなっていること
-> ある年齢で引退する(定年退職)
・新しいパラダイム
-> 働き続ける(生涯現役)
・定年退職したのは働き続けるため
・自分をバージョンアップし続けてサバイブする
●ムーアの法則の終焉
新しいマシンは常に早くなる、高性能、高機能、安くなる
-> プログラマは性能を意識しなくてよかった
年間50%成長は、限界
many core
-> プログラムも変えないと
●なぜ学生なのか
・情報生産者になる
解くべき問題を見つけ、それを解決する
パラダイムを疑う訓練中
・論文を読む、読む、読む、まとめる、問題を発見する
ムーアの法則の終焉後どうしていくかを、ここ2,3年でやる
・学び方も陳腐化する
学び方を学び続ける
楽しみながら
・どんな分野であれ「問題を発見して、解決する」は必要
・これから 10〜20年は、収入が得られれば続けていく
Be a Hacker
Make the World Better
■感想
生き方、マイクロフロントエンド、マイクロサービス、デザイン、MR、組織戦略、Kubernetes、コミュニティ運営、エモ成分、越境、アジャイル、機械学習、IoT、DevOps、マーケティング戦略、モニタリング
2 日間を通して聞かせていただいたハンガーフライトの領域を並べてみました。さすがデブサミですね！興味の幅を全方位で刺激していただけました！！
ぼっちでそわそわ過ごし、ワクワクのやり場がわからなかった去年。
カイゼン・ジャーニーに人生を曲げられ、大きく活動が変わった一年。
今年は、いろいろな場所で、話せる人たちに出会い、ワクワクを共有できました。
SRCAサイクルに共感して、踏み出し方を大きく変えていただいた
岡大勝さんともお話できて、新しい活動も始まりそうです。
来年のデブサミでは、どう変わっているのだろう。
ワクワクする刺激をもらいながら、新しい出会いと、ふりかえりにも使えるイベント。すごいですね！
とても楽しい時間でした！
登壇者の皆さん、運営の皆さん、ありがとうございました！！
■講演資料まとめ
この記事が参加している募集
いつも応援していただいている皆さん支えられています。