developers summit 2020メモ

全体

2020/02/13-14

Developers Summit 2020

デブサミ2020、講演関連資料まとめ:CodeZine(コードジン)

02/13 10:00~10:45 13-E-1 UXデザインが大事なのはわかるけどエンジニアの私ができることってなんでしょう?

UXデザインが大事なのはわかるけど エンジニアの私ができることってなんでしょう?

  • モノ ⇒ 体験
  • UX白書
  • 期間のモデル
  • 予期的UX:使う前、口コミとか。お化け屋敷から出てきた客を見て想像するとか。
  • 瞬間的UX:インタラクション
  • エピソード的UX:目的を果たすまで、タスク
  • 累積的UX:意味のレベル   ※課題の解決に偏ってたかも?
  • 後半は積み重ねの結果、包含する。
  • 積み重ねなので、通して扱った方が良い
    • 大きい企業だと別れがち
  • UX、ユーザのプロパティ、体験
  • どのような体験をしてもらうか、計画する
  • 体験を量産、再生産、仕組み、スケール
  • サービスとしてのデザイン、品質、継続性
  • コアとなる体験と、コアとなるコンピタンスの整合性
  • 行き来して見る、設計する、レンズのフォーカス、調整
  • 体験の仮設、実態の観測
  • 良さを、他者にどのように伝えるか?逆算

02/13 11:05~11:50 13-C-2 CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見

30 million workflows reveal about DevOps in practice - Speaker Deck

  • 数字に振り回されない。
  • 開発者に、適切なフィードバックを、素早く行う。
  • フィーチャーフラグのOn/Off、ロールバック

02/13 12:10~12:40 13-C-3 noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦

noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦|こんぴゅ|note

  • 単一のKPIを追わない
  • グロースモデル
  • 目標値には関係性がある、表現する
    ※グロースモデルにユーザを入れる
  • チームはプロダクトに対して時間軸で切ってる
    • 基盤(長期)
    • 機能開発(中期)
    • カイゼン(短期)
       ※クネビンと合わせて考えると楽しいかも
       ※活動のフレーム変えられていいかも?
  • 定性と定量どちらも大事。バランスをとる。
  • グロースモデルの線で、データを取る
  • データについては定義が必要
    • 論点の整理、合意形成プロセスもチームの学びになる
    • 議論の過程、データ、仮説、捉え

02/13 13:05~13:50 13-C-4 インターネットが変えた世界・変える未来

  • 独自プロトコルの時代
  • BSDすごかったんや(Berkeley Software Distribution)
  • Mosaic
  • Windows
  • http
    • getしかなかった。
    • 1995年にPost
    • httpサーバにも動的処理の仕組みはなかった。(CGI
  • イノベーションはエッジ側で起きる。
      ※利用者側の活動が変わったときに起きる
      ※フリクションレス
  • エッジ
    • 単なるコンソール
    • TCP/IP
    • PC、CPUとストレージがやってきた
  • インターネット
    • 初期は≒メール
    • 常時接続、帯域増ADSL
  • ブラウザ
  • スマホ
    • ブラウザ、表現力が遜色なく
    • 場所の制約がなくなる
    • インターフェースの変化

02/13 14:10~14:55 13-B-5 Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法

  • Latest問題
  • どこまでコントロールしたいのか  

02/13 15:15~16:00 13-F-6 「厳密な共通言語」としての形式手法

「厳密な共通言語」としての形式手法 #devsumi / Developers Summit 2020 - Speaker Deck * 曖昧さに対して、形式手法 * 曖昧さは、イメージの外からくる * 例としてTCCパターン(Try operations, Confirmation, and Cancellation)
※メモ:TCCパターンとSagaパターンでマイクロサービスのトランザクションをまとめてみた - Qiita * 世の中の変化 * アーキテクチャの複雑さが増した * 知識のばらつきは大きく * 明文化の必要性も増した * テスト? * イメージの外にあることは、テストケースに含められない * 実装時のバグではなく、仕様バグ * 自然言語は曖昧である * 共通言語、形式手法 * 安全性と活性 * 活性は時相論理式が必要
※不確実とか予想不可能で思考停止しない必要性

02/13 16:20~17:05 13-E-7 クラウドサービスとゲーミフィケーション:「TwilioQuest 3」を用いた開発者オンボーディング

02/13 17:25~18:25 13-E-8 チームをつくるモブプログラミング ~内側と外側から語る~  

チームをつくるモブプログラミング / Mob Programming to build teams - Speaker Deck

  • モブをチームに合わせて使いこなす。
  • 学習の側面、成果を出す側面。
  • リアルタイムレビューとしての表現。
  • フィードバックは早ければ早い方がいい。
  • わからないことを宣言すること。
  • 暗黙知の共有 。 ※メンバーの知識、活動(練度)、美学、正義はそんな簡単にわからん。
    言語化能力にも差がある。
    ※そもそも自覚できない。無知の知問題。
    ※以後のコミュニケーション品質を高める効果。
    形式知が増えれば、埋める必要のある差分は減る
    ※コンテキストの共有、ピンポイントですり合わせ、適切なストーリーとメタファー

02/14 10:00~10:45 14-A-1 チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜

チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

  • 理想の変化速度(求められる変化の量)と、変化することの辛さ。
  • 急な階段はむりがあるので刻む。坂に、なだらかに。
  • 変わる人(変わりたい人)、今まで通りの人(変わりたくない人)
    • 分断と対立、しがらみ。
    • 2項対立 ※実際はグラデーションなことの方が多いと思うが。
  • 1Wスプリントだけでは表現しきれない。
  • チームの成長にも方向感を。
    言語化はともかく明文化してこなかったなー。
  • 段階によりチームの在り方もかわる。場合によっては必要なロールも変わる。
  • 専門性は必要だが、自分の役割、可能性にふたをしない。

02/14 11:05~11:50 14-E-2 プリンシプル・オブ・“ともにつくる”~ Web Performerを支えるドクトリン ~

  • プリンシプル!
    • めっちゃメタい。知ってると早い。強い。
  • 我と汝(ブーバー)、我とそれ
  • シニフィアンシニフィエ
    • 言葉で世界を切り取っている。
    • 言葉から世界を認識している。
      • 知っているものがフォーカスされる。
           ※理解と分類は近い、分類できないものは同じものと認識、もしくは知らない何か。
    • 世界は言葉により歪む。
    • 同じ言葉でも同じ理解にはならない
      • 言葉が世界を構築する、知識を増やせば思考も豊かになる
  • 無知の知
    • 無知は問題ではなく、無知を自覚しないのが問題   常に無知であるという姿勢で誰からも学ぶ
      ※質問できるのは新人の特権とか言うが、みんな質問すればいい  
      知れば知るほど知らないことが増える   既知すら疑う謙虚さ、世界は変化している   当たり前は要注意ワード
  • エンジニアリング:工学:役に立つ
    • 役に立つ為には、余らせる
    • あまらせるために人(汝)を犠牲にしてはいけない、人を削らない

02/14 12:10~12:40 14-A-3 A retro on agileアジャイルをふりかえる

02/14 13:05~13:50 14-B-4 プロダクトを10年運用するチームをつくる

  • スキルマップ、厳密でなくてよい。
    • チーム内の認識合わせ用。
  • 障害対応訓練。
    • 緊急性が高く、学習目的多めのペアプロなどが向かないナレッジの共有。
  • 定期的に作り直す。式年遷宮
    • リファクタリングによる経験値。
    • 技術的負債の解消
       ※自分のモノ感。精神的な継承(オーナーシップ)も進みそう。

02/14 14:10~14:55 14-D-5 マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと

02/14 15:15~16:00 14-C-6 オープンソースのこれまでとこれから

  • 自由を求める戦士
    • 学生中心
  • マイクロソフト帝国

  • 資本主義の権化(VC)と自由の権化

  • ユーザ企業(カーネルがテクノロジー)の時代へ
    • 扱う課題が面白い ⇒ つよいエンジニア集まる
  • インセンティブの合致と仕掛け
    • オープンにするだけで上手く回るわけがない
    • 交換すると上手くいく?徳がある?
    • 見せるための場、価値の表明(外から⇒内で使う)
    • 会社のビジネスゴールと活動を繋ぐ。他部のゴールとつなぐ。
    • 視座を上げる。
    • 目立つ、外から見てわかりやすいもの。アイコン。
      • 中身はそんなにきれいじゃなくても、人が集まれば力になる。
    • コントリビューターガイドライン
    • 作るだけのロールでは不足

02/14 16:20~17:05 14-C-7 Hackが好きなエンジニアが組織をHackしてみる考えと実践を経てきたヒストリー

02/14 17:25~18:25 14-A-8 キャリアトランスフォーメーションをみんなで考えよう~開発者から事業責任者、役員へのキャリアパスはどうよ~

ichitani / 正しいものを正しくつくる on Twitter: "自分のハンドルは自分で握れ by @papanda #devsumi https://t.co/Hkc59Fpwy4 @SlideShareさんから… "

  • 目の前の最適化に陥らない。
  • 外に行ってDiffを取る。
  • 自分で決める、一歩でも踏み出す。

偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話。 #devsumi #devsumia

  • 相対的に得意 (でいいんだな)
  • 食わず嫌いしない。好奇心大事。
  • 傾聴・・・からの課題共有。
  • 関心を持ち、敬意を持ち、傾聴する。
    • 後から入ったコンサルがロジックツリーで整理してぶっこわしちゃうパターン(気を付けよう)
  • 謙虚であれ!

見れなかったやつ!

質とスピード(2020春版) / Quality and Speed 2020 Spring Edition - Speaker Deck

サービスメッシュは本当に必要なのか、何を解決するのか / Service meshes - Do we really need them? What problems do they solve? - Speaker Deck

最新のブラウザで変わるCookieの取り扱いやPrivacyの考え方 - Speaker Deck

レガシーコードからの脱却 | Ryuzee.com