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サイクルに共感して、踏み出し方を大きく変えていただいた
岡大勝さんともお話できて、新しい活動も始まりそうです。

来年のデブサミでは、どう変わっているのだろう。

ワクワクする刺激をもらいながら、新しい出会いと、ふりかえりにも使えるイベント。すごいですね！

とても楽しい時間でした！
登壇者の皆さん、運営の皆さん、ありがとうございました！！

■講演資料まとめ