omuronの備忘録

個人的な備忘録

Classmethod Showcase Road to 内製化「カルチャーは引き継げるのか? 〜企業のDevBizOpsへの挑戦〜」 受講メモ

classmethod.jp

絶賛内製化取組中なので、興味あるセッションがたくさんあります。

カルチャーは引き継げるのか? 〜企業のDevBizOpsへの挑戦〜

講師:アマゾン ウェブ サービス ジャパン合同会社 エバンジェリスト 亀田氏

日本には AWS に数十万のお客様がいる

  • 日本が遅れているわけではない、積極的に使っている
  • CI/CD などの最先端については若干遅れている
  • SI モデル(請負)と相性が悪いのではと思われる

サービス型

  • 固定資産型からサービス型へ
    • 初期投資不要、使用分のみ支払い
    • モノを買うわけではないのでチャレンジしやすい環境
    • カジュアルにものづくりができる

ビルダーズの育成がイノベーションの鍵

  • エンジニアがモノをつくるだけではない
    • 収益やお客様への責任も持つべき
    • 裁量がなければ限界がある
      • 経営陣が考える必要あり
    • 投資コストを最小化できるクラウドの相性がいい

SaaS

  • AWS を使わずに済む方法をまず考える
  • クラウドは高セキュリティ
    • 一般的な企業が作るよりもセキュリティにコストかけている
    • メガバンクも採用している
  • エンジニアのリソースはどこに使うべきかを考える
    • バックオフィス業務は作らずにサービスを使う
  • 88%の企業はクラウドファースト
    • 一方、IT予算はオンプレミスに86%かけている
  • クラウドの利用によるコスト削減

Innovation Fly Wheel

  • 営業とエンジニアを分けるのは古いやりかた
    • お客様からの要望は、サービス開発チームへフィードバックすべき
  • 責任と権限は表裏一体
    • 亀田さんはエバンジェリストとして月1回以上会社へフィードバックする責務がある
    • その代わり自由に日本中出張して講演が許可されている
  • クラウド移行の価値は、インフラ以外が9割以上締める
  • 顧客ニーズを追従する
    • 内製化が鍵

DevOps

  • DevOps は難しい
    • Ops は安定化が大事
    • Dev は追加機能やビジネスを実装
    • Dev と Ops は相反しやすい
  • DevBizOps にする
    • ビジネスとお客数の責任もエンジニアに持ってもらう

マイクロサービスアーキテクチャ

  • Conway の法則
    • 1967年に言われた言葉だけどそのとおりになっている
    • 上長の許可がいる環境ではアジャイル開発なんて不可能
    • 反復的に行われる作業(CI/CD)は組織そのもの
      • 組織の在り方は引き継げない
      • 自動化の仕組みは内部で作り運用する必要がある!
        • ファーストフードのアルバイトはこれができている
        • 社員が仕組みを考え自動化し、アルバイトは動くだけ
  • モノリシックアーキテクチャ
    • 定例会などで協調してみんなでものをつくる
  • マイクロサービスアーキテクチャ
    • チーム単体でビジネス判断できる、権限移譲が必要
      • ビジネス判断できないなら上手く行かない
    • 開発完了後ビジネスのスタート
      • 開発して終わりではなくそこからお客様と会話スタート
      • ビジネスが始まってからちゃんと責任も持つ
    • Two-pizza teams
      • 人数が増えすぎると調整が大変になる
        • 上限は10人程度
      • プロダクトのロードマップ、開発、運用、収益すべてやる
      • 全てのチームに SDE,PM,TPM,SE,SET が存在する
        • 常に人が足りないので外部リソースも必要になったりする

民法

  • 2020年民法改正
    • 瑕疵担保責任 -> 契約不適合責任
    • 納品から1年 -> 事実発覚から1年、時効5年に
  • 作って終わりではない

バイモーダル

分散モノリス

  • フロントエンドとバックエンドをわけても同じビジネスをしている場合などは「分散モノリス」になる
    • EC サイトなどで使われることが多い
    • サービスはマイクロサービスとして別れているけどビジネスが別れてないはコレ
  • ヘッドレスコマース
    • DB は分散したくない
      • センシティブデータの顧客情報は重複管理排除したい
    • フロントエンドは DB を直接見ない
      • 射影(Materialized View)を見る
      • 配送時などは DB から必要データを取り出して利用した後捨てる
    • カスタマージャーニーを起点に考える

所感

いつも素晴らしい話を上手にしてくれる亀田さんのセッションだったので真剣に聞きました。
語彙力崩壊状態ですが、うなずくことしか無い内容ですね。