アイキャッチ編集

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

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

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

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


■講演資料まとめ


この記事が参加している募集

いつも応援していただいている皆さん支えられています。