トップ > Developpers Summit 2020 Summer に参加してきました

Developpers Summit 2020 Summer に参加してきました

  • 2020年7月21日に開催された「Developper Summit 2020（デブサミ2020夏）」に参加しました。
  • 今回は、初のオンライン開催で開催されました。
  • 関連資料等についてはこちらにまとめられておりますが、私が参加したセッションの内容のレポートを書いておこうと思います。

【A-1】その後のソフトウェア・ファースト（及川 卓也[Tably]）

  • 講演概要ページ
  • 書籍も読ませていただきましたし、別の機会でお話を聞かせていただいたこともあります。しかし、COVID-19 をきっかけにもう一度考えさせられたことや自分がエンジニアとして持つべき視点についてわかり易くお伝えいただけたと思います。

講演内容メモ

  1. 書籍の内容の簡単な紹介

    • ログミーの記事に書いたこと+α
    • どんな事業・プロダクトであってもソフトウェアをどう活かすかを考える、全体を見通す。
      • 別にソフトウェアが一番偉いと言いたいわけではない。
    • SIer は 顧客が国内の競争に勝てる支援 をする
    • 国内企業のものと海外の同様のアプリケーションを見たときに使い勝手の違いに驚くことがある。
    • 視座を以下の順で上げていく
      1. 自社が儲かる
      2. 顧客が儲かる
      3. 日本が儲かる
      4. 世界が儲かる
    • 上記は理想論だけど、収益を考えたら大事なこと
      • お客さんから搾り取るものが無くなったら意味ない
      • IT でもSDGs ：みんなで成長する
    • 地域によるソフトウェアに対する捉え方の違い
      • 米国：ビジネス
      • 欧州：科学
      • 日本：製造
    • 日本の考え方は大量生産には向いているけど、世界は発展しない

  2. with COVID-19 での「ソフトウェア・ファースト」

    • アナログからデジタルにすると、情報が欠落する。
      • よって、意識して落ちた情報を追加して伝えないといけない。
    • 「自分が相手に与える価値は何か」 をちゃんと伝えないといけない。
    • リモートワークは「ソフトウェア・ファースト」では否定的だった：安易に警鐘を鳴らしていた
      • 親の介護、子供の世話だから、はOK
      • リモートで働くと、開発に必要な情報が欠落する可能性がある。
        • 逆に、全員がリモートなら問題ない
        • 誰かだけがリモートだと情報格差が出る：ランチ中の会話でのひらめきとか
    • COVID-19 をきっかけに、もともと不要だったものを見直すことになった
      • 本当にいるもの、いらないものを考えることがソフトウェアを作っていく上でも重要 になってくる。
    • プロダクトの強い軸の「視点の抽象度」を上げて考えることが必要
      • 本当に提供したかったのはなにか、本当に大事なものは何か
      • How : 「Output」のレベルではなく、 Why : 「Core」を考え、伝えられるようになることが必要
    • ソフトウェア開発からプロダクト開発へ：コードの向こうにユーザーを見る

【C-2】心理的安全ジャーニー ～Slackで安全を実装する5つの手法～（片岡 俊行[ゆめみ]）

  • 講演概要ページ
  • 講演スライド資料
  • 発表者による発表後記
  • 流れるような発表だったので、講演中のメモはうまく取れませんでしたので、内容は上記発表資料をじっくり見ていただくのが良いです。
  • 実践例として Slack でのコミュニケーションにおける「心理的安全性」をお話しいただきましたが、それ以外の手段におけるコミュニケーションにおいても重要なことをお話しいただきました。
    • たしかに、テキストベースでどんどん流れる Slack におけるコミュニケーションではより一層気を使うなとも思います。

講演内容メモ

  • 企業が生き残るためには挑戦が必要
  • 挑戦の過程で 無知・無能・批判・横槍の4行動 が行えることが重要
    • リスクある行動 = 挑戦 は競争の打ち勝つために必要
  • そもそも、 心理的安全性 の定義を誤って理解している人が多い：「信頼」と混同しないように
    • 心理的安全性：「挑戦モード」での協力・督促
    • 信頼：「通常モード」での協力・督促
  • 心理的安全性は、4行動を妨害する行為を除去されたときに確保されるもの
    • 妨害する行動は丁寧に除去すること
  • 強い意見を弱く持つ：意思は強く、でも、人から言われたら変える余裕を持つことが必要。 知らんけど。

【A-3】New RelicのOSSツールとKubernetesクラスターの可観測性（田中 孝佳[New Relic]）

  • 講演概要ページ
  • K8s の運用に置けるオブザーバリティ（可観測性）を高めるための OSS ツールとその背景にある考え方をお話しいただきました。
  • K8s のコマンドに明るくない人と一緒に運用も含めたチームを組む際には、こうした SaaS の導入も選択肢に入るなと感じました。

講演内容メモ

  • オブザーバリティ（可観測性）とは
    • モニタリング：なにかが間違っているときに通知
    • 可観測性：問題の根本原因まで特定可能
  • K8s クラスタ運用の課題
    • 運用ツールの設計・運用
      • オブザーバリティプラットフォームの活用
    • 計測する指標の選定
    • 動的に変化するクラスターへの追随
      • K8s オブジェクトに関連付けた計測
    • アプリも対象とした運用
      • アプリ中心の計測も採用
  • オブザーバリティプラットフォームに求められる特性
    • 多くの人が使える：運用のエンジニアも開発のエンジニアも、アクセスしやすい
    • 運用コストが低い：特別なスキルが必要ない、コストの予測が立てやすい
    • →オブザーバビリティの民主化
  • ツール選定にあたって考えること
    • 広く使われているツール：CNCF プロジェクトに加盟している OSS
    • SaaSの活用：New Relic など

【A-4】apt update my-society: シビックテックとCOVID-19（関 治之[Code for Japan]）

講演内容メモ

【A-5】Amazon/AWSの安全で自動化されたContinuous Deploymentsへの道（林 政利[アマゾン ウェブ サービス ジャパン]）

  • 講演概要ページ
  • AWS において実現されている Continuous Deployments (CD) について、背景の考え方と実践事例のご紹介でした。
  • CD の事例についてはネットで検索すれば色々出てきたりしますが、

講演内容メモ

  • AWS のデプロイプロセスはハンズフリー
    • メインブランチに変更したら、開発者はそのことは忘れる → 次の開発タスクに走る
    • ハンズフリーでなければ、デプロイをドキドキしながら見守る羽目になる
  • デプロイパイプライン：Source -> Build -> Test -> Production
    • Source：コーディング、コードレビュ、IaC、コンテナ定義ファイル、設定
      • 人の手でやる
    • Build：ソースをビルドして Artifacts を作る
    • Preproduction : Alpha -> Beta -> Gamma
      • Alpha ：自動テスト、ここで継続してエラーが発生するのは珍しくない
      • Beta : 自動テスト＆結合テスト、自動ブラウザテスト
      • Gamma : 本番環境と同じところで時間をかけてテスト。ここまででエラーは出しておく。
    • Production
      • 大事なことは、 デプロイパイプラインを信頼する こと
      • 自動ロールバックの仕組みを作ること
  • Bake Time の考え方：デプロイの結果がメトリックスに反映されるまで時間がかかる
    • Bake Time は長いほうが安全だが、リリース速度が遅くなる
      • デプロイの前段階で長く取り、後のステップに向かって徐々に短くする
    • パイプラインを停止するイベント
  • ソースの種類ごとに独立したパイプラインを用意する こと
    • アプリコード、設定値、IaC、コンテナのベースイメージを独立したデプロイプロセスで
    • 独立したパイプラインから同じステップを利用する
  • コードレビューは手作業で行う最後の工程
  • AWS CodeDeploy: AWS の各種サービスへのデプロイを自動化
  • デプロイ時におけるロールバックの安全性の確保

【C-6】人の仕事、機械の仕事。エンジニアによるカスタマーサポート改善（本間 光宣[ミクシィ]）

  • 講演概要ページ
  • 発表資料
  • mixi の CRE (Customer Reliability Engineering：顧客信頼性エンジニアリング) チームの取り組み事例の紹介でした。
  • CRE としての取り組みの話のみならず、機械学習を「小さいところから始める」という点においても参考になるお話でした。

講演内容メモ

  1. CRE に関して

    • CRE とは
      • Google が 2016 年に提唱
      • 顧客の信頼の最大化を目的としたエンジニア
      • 仕事内容に明確な定義はない
    • mixi に置ける CRE
      • CS に必要なシステムの開発・運用
      • 問い合わせ調査
      • 問い合わせ起因のプロダクト開発
    • mixi の CRE は全社横断組織

  2. ゲームの問い合わせでの取り組み事例

    • ゲームに関する問い合わせ：仕様、操作方法、機種変更時のデータ移行、クリアできないなどの不満の問い合わせ
    • これらを 機械でも対応できる問い合わせ と 人でしか対応できない問い合わせ に分類
      • 仕様などに関する問い合わせ：テンプレートでも対応できる。機械でも対応できる
      • 感情を伝えるための問い合わせ：話を聞いてほしいって場合が多い。テンプレートで対応できない（ネガティブな話だけではない）→ 人でしか対応できない問い合わせ
    • エンジニアによるCS改善事例： 機械学習を活用して、テンプレ対応を効率化
      • 大量のテンプレから適切なテンプレを検索することを効率化
    • 改善の大方針：効果は小さくても良いので、早く成果を出す
    • 効率化施策：新規問い合わせに対して、システムからテンプレを提案
    • 技術構成：すべて AWS で
      • 過去の問い合わせをすべて S3 にインポート
      • 機械学習は SageMaker
      • CodeBuild：処理を定義
    • チームが抱えていた課題：機械学習が初めてなので、利用可能なモデルを開発できるか？
      • 取り組む問題を簡単に、試行回数を増やす、試行の精度を高める
      • モデルへのインプットは問い合わせ本文のみにして問題をシンプルに。 まずは、1つのモデルを対象に。
      • ドメイン知識を身につけることで、明確な仮説を持って施行する
        • 一次データ（実際の問い合わせ）を見て、傾向を理解する
      • システム開発：少ないリソースで開発できるか？
        • シンプルな構成で、作るものを減らす
        • マネージドサービスを使うことで、必要なものを減らす
        • 機械学習のモデル開発に時間が割けるように
    • このツイートがまさにまとめ

【C-7】モダンなアーキテクチャでゼロから作る証券基盤（石橋 淳志[Finatext]/大木 卓哉[Finatext]）

  • 発表概要ページ
  • 発表資料
  • Finatext が手掛けた証券プラットフォーム（Brokerage as a Service = BaaS）の事例紹介でした。
  • 金融業界にはあまり馴染みがなかったのですが、業界特有の事情等もお話しいただきました。
  • 個人的には、BaaS のような API を実現する際に考慮すべきポイントなどを知ることができた講演です。

講演内容メモ

  • 証券プラットフォーム：Brokerage as Service
    • 証券サービスの共通機能をクラウド化し、他システムとの接続部を API 化
  • 金融事業の立ち上げには様々な課題
    • 免許制・登録制
    • システムコストは数十億円規模
  • 金融系は、業務ごとにシステムが大きく異る
  • クレジットカードを用いた株の積立は日本では少ない
    • 手数料の問題：株式の売買手数料片道1%未満+投資信託の信託報酬0.5-1.5%+クレジットカードの決済手数料3%超
    • クレディセゾンだからこそできたこと
  • バッチ処理の設計で意識していること：冪等性とトランザクション制御
    • 冪等性：ある操作を複数回行っても、入力が同じなら結果は同じ
      • 実装方法
        1. すべての処理をやり直す（おそらく、厳密な意味での冪等性）
          • 場合によっては既存のデータを最初に削除
        2. 未処理のもののみ実行する
      • 外部に作用を持ってしまうものは 2

【A-8】コンテナベースの開発パイプラインへ“セキュリティ”を実装してみよう（野原 峰彦[マクニカネットワークス]）

  • 講演概要ページ
  • コンテナ開発の基礎と DevOps の入門から始まり、コンテナ開発をする上で考慮すべきセキュリティのポイントをお話いただきました。

講演内容メモ

  • 実行環境にも注意
    • 環境変数でパスワードを設定すると、起動時に見えてしまう
  • 野良イメージにマイニングスクリプトが仕組まれてたりするので注意
  • NIST SP.800-190 に準拠したものを使おう
  • セキュアにツールを使う
    • Github, Cicle CI, JFrog Aritifactory(成果物管理システムのパイオニア), JFrog Xray（脆弱性診断とライセンスチェック）, Twistlock
  • DevSecOps：セキュリティを担保しながら DevOps を継続する
    • 開発に近いところでセキュリティチェック
    • チェックを自動化していく
  • 開発において、野良イメージの利用をブロックする
  • セキュアに、かつ利便性を損なわない環境の構築
  • https://www.macnica.net/devops/

【A-9】プロダクト作りのトランスフォーメーション（市谷 聡啓[レッドジャーニー]/粕谷 大輔[はてな]/門脇 恒平[プレイド]）

  • 講演概要ページ
  • 3 人の方のリレー講演でした。
  • 各々の会社でコロナ禍におけるリモートワークにどう取り組んだか、変化が激しい中でのプロダクト開発をどう変革させていったのか、という事例紹介でした。
  • もちろん、緊急事態が起こった時に急にこうした取り組みができるわけではないので、普段からの土壌づくりが必要であると痛感しました。

粕谷 大輔[はてな]：この半年で変わったもの、変わらないもの

  • もともと東京・京都にメンバーがそれぞれ在籍してるリモートチームだったので、開発プロセスがリモート前提に作られていた
  • ただし、働き方は在宅想定ではなかった
  • 仮説：在宅になれてない人はパフォーマンス低下するのでは？
    • ただし、「緊急事態なので、同じパフォーマンスを求めてはいけない」「防空壕の中で同じ仕事はできないよね」という考えは持っていた
    • 結果・・・パフォーマンスの低下は見られなかった（プルリクベースの指標）：4月時点
  • 仮説：在宅勤務で頑張りすぎてないか？これは持続可能なペースかな？
    • 結果：7月時点でもチームとしてのパフォーマンスは大きな影響はなかった
      • 個人としてのパフォーマンス低下はあるかも知れないが…
  • その他の計測：ジローでジニ係数を見る
    • それでもパフォーマンス低下はなかった
  • リモートワークの課題：コミュニケーションの低下
  • ワーキングアグリーメント ：チームの約束事を明文化する
    • なぜ重要か：個人の裁量とチーム運営のためのある程度強制力を持ったもののバランス

門脇 恒平[プレイド]：不確実性の高い世界の中で非連続な成長を生み出す

  • 会社の変化：原則リモートワーク
  • 顧客の変化もあった
  • 大事にしていること
    • ルールはなるべき決めない
    • 自分の生産性は自分で上げる
    • 常にゼロベースで考える
    • プロダクトアウトを大事にする
      • 個人のアイデアはアウトプットする
  • Why を CPO だけに依存しない（ CPOのトラックナンバー n 化 ）

市谷 聡啓[レッドジャーニー]：トランスフォーメーションジャーニー

  • 講演資料
  • プロダクト開発で立ちふさかるもの：不確実性、逆境、断絶
  • 「私の考えた最強のプロダクト」はだいたい調査不足
  • 企画者本人もよくわかってない
  • 「何を作るべきなのか」がわかっていない
  • オーバーエンジニアリング：「実験 = そのまま適用」になりがち
  • ゼロエキスパート：モダンな開発に必要な専門家がいない
  • リモートワークによって、会話を始めるコストが上がっている。「あなたのことがわからない」
  • 方向性を変える約束=タイムボックスを構造化

全体所感

  • オンライン開催でしたが、得るものは大きく、逆にオンラインのコメントや Twitter でのコメント発信は盛んに行われていたのではないかと感じました。
  • 昨今の変化は目まぐるしいですが、その中で自分の軸を見つけるのに参考になった講演が多い印象でした。
    • 登壇者の方々は、各々なんかしらの信念を持っていらっしゃるように思いました（だからこそ"強い"のかな・・・）。
  • 単なる技術的な勉強会で得られるものとは違ったものを吸収できる良い機会でした。