バックエンドエンジニアが考えるプロダクトへの向き合い方

by GODoda

Slide 1

Slide 1 text

バックエンドエンジニアが考えるプロダクトへの向き合い⽅ SaaS企業の成⻑を⽀えるバックエンドの裏側株式会社IVRy Odashi 1

Slide 2

Slide 2 text

⾃⼰紹介 ● 名前：Odashi ● 領域：バックエンド ● 考え⽅：楽しい⽅の⾒⽅ ● 趣味：クラヴマガ‧ジム 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 4

Slide 5

Slide 5 text

今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 5

Slide 6

Slide 6 text

IVRyのシステム概要 6

Slide 7

Slide 7 text

IVRyのシステム概要 7 - ECS - APIとバッチ処理 - 通話データの同期 - Aurora PostgreSQL - Redis - ⼀部LLMの利⽤も

Slide 8

Slide 8 text

今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 8

Slide 9

Slide 9 text

マインド - 1⼈1⼈がプロダクト志向のエンジニアが多い - ⾃分たちもいちクライアントとして実際に使ってみる - As Is, To Beをしっかり考えられる - Design Docの活⽤ 9

Slide 10

Slide 10 text

プロダクト志向プロダクト志向とはチームメンバー全員がプロダクトをまるで⾃分の⼦どものように愛し、⾃分の担当領域だけではなく、プロダクト全体のことを考えることを「プロダクト志向」とよぶ。引⽤及川卓也; ⼩城久美⼦; 曽根原春樹. プロダクトマネジメントのすべて事業戦略‧IT開発‧UXデザイン‧ マーケティングからチーム‧組織運営まで . 株式会社翔泳社. Kindle 版. 10

Slide 11

Slide 11 text

プロダクト志向 - ⼊社後のオンボーディングで全オプションを含めた⾃由に使えるアカウントを発⾏する - エンジニアもCLインタビューや展⽰会に参加する - 触ってみて実感することが⼤事 - プロダクトをどう成⻑させていくかを⾃分の中に持つことができる 11

Slide 12

Slide 12 text

プロダクト志向 12

Slide 13

Slide 13 text

As Is, To Be As Is, To Beとは As Is：現在の状態 To Be：理想の状態現在と理想のギャップ（課題）を明確にし、解決のためのアクションを導き出すための分析フレームワーク 13

Slide 14

Slide 14 text

As Is, To Be - スタートアップ＝⼈⼿不⾜ - 「今まではこうだった」「今はこうなっているから」と省エネ志向に⾛りがち - 今ある知識だと本当はどうなるのが理想かを常に追求するカルチャーがある 14

Slide 15

Slide 15 text

Design Doc Design Docとはこれから新しく開発しようとするソフトウェアの全体の設計や、既存のコードのpatchやプルリクエスト(PR)のコード変更の基本的な要点をまとめる⽂書引⽤ https://myenigma.hatenablog.com/entry/2021/07/25/140308 15

Slide 16

Slide 16 text

Design Doc 16 - ⼤きな案件は必ず書く - 規模が⼩さくても⽅向性の擦り合わせなどにも有⽤

Slide 17

Slide 17 text

Design Doc 17 - 重要なのはスコープと設計 - スコープはシステム影響範囲 - スコープアウトも書いた - 設計は実装の⽅針

Slide 18

Slide 18 text

Design Doc - 正確さが重要なので基本は⽂字で残す - 図などは補助する位置付け（システム全体像、ER図やシーケンス図など） 18

Slide 19

Slide 19 text

Design Doc - 人は必ず忘れる生き物 - 1人が考えるTo Beにも限界がある - あの時どう考えていたかを振り返る方法になる - 今ならあの時のTo Beを実現できそう？ - もっと良さそうなTo Beを思いついた - 方向性の擦り合わせにもなる 19

Slide 20

Slide 20 text

マインドプロダクト志向 As Is, To Be Design Doc 20

Slide 21

Slide 21 text

今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 21

Slide 22

Slide 22 text

テック - Rubyバージョンと向き合う - デプロイ頻度の改善 22

Slide 23

Slide 23 text

バージョンと向き合う - Ruby = 3.3.2（最新は3.3.3） - 3.3.1の時にYJITを有効化した ※2024/6/25現在 23

Slide 24

Slide 24 text

Rubyバージョンアップ 24

Slide 25

Slide 25 text

Rubyバージョンアップ 25

Slide 26

Slide 26 text

Rubyバージョンアップ 26 最初は3.1.2だった

Slide 27

Slide 27 text

Rubyバージョンアップ 27 バージョンと向き合い始めた頃 3.2.2のリリースは2023-3-30なので約1年遅れ

Slide 28

Slide 28 text

Rubyバージョンアップ 28 3.2.3のリリースは2024-1-18なので約3ヶ⽉遅れ

Slide 29

Slide 29 text

Rubyバージョンアップ 29 3.2.4のリリースは2024-4-23（脆弱性対策のパッチで2⽇遅れ）

Slide 30

Slide 30 text

Rubyバージョンアップ 30 3.3.1のリリースは2024-4-23なので約1週間遅れここでYJIT有効化

Slide 31

Slide 31 text

Rubyバージョンアップ 31 3.3.2のリリースは2024-5-30なので約1週間遅れ

Slide 32

Slide 32 text

YJITとは - Ruby3.1に導⼊されたJIT(Just In Time)コンパイラ - 実⾏時に機械語を⽣成することで最適化が⾏われる - 3.1導⼊、3.2正式サポート、3.3安定化と進化している 32

Slide 33

Slide 33 text

Rubyバージョンアップ 33 - YJITは3.2.0から有効化できたがあえてしなかった - YJITが⽣成する機械語やその管理のために確保するメモリが際限なく増える可能性があった - ⼀応対策はあったが3.3で改善されたこともわかった - 状況を適切に理解し、しないという判断も⼤事

Slide 34

Slide 34 text

Rubyバージョンアップ 34 Matz（Rubyのパパ）からのクリスマスプレゼントと⾔われたり⾔われなかったり

Slide 35

Slide 35 text

Rubyバージョンアップ - 基本的に後回しにされがち - 直接的なアウトカムが⾒えないから - とは⾔え間接的に貢献する - プロダクトの本質に向き合える時間を増やす 35

Slide 36

Slide 36 text

デプロイ頻度の改善⽬標：毎⽇デプロイ 36

Slide 37

Slide 37 text

デプロイ頻度の改善 - mainブランチにマージされたら⾃動デプロイとslack通知 - Staging環境で動確が終わればemojiをつける＝いつデプロイしてもOKという⽰し - Productionへのデプロイはワークフローで⾏う - BEにはメンションして共有 - だいたいemojiがついているのでそのままデプロイを進められることが多いいつでもデプロイ可能にするための仕組みを作り、可能な限り⾃動化させる 37

Slide 38

Slide 38 text

デプロイ頻度の改善 38

Slide 39

Slide 39 text

デプロイ頻度の改善 - デプロイの頻度が多いことはプロダクトの変更を容易にする - 差分が少ない→レビューに時間がかからない→すぐ価値を届けられる→次の作業にすぐ取り掛かれる - ライブラリのバージョンアップも容易になるので新しいバージョンを利⽤しやすくなる - エンジニアにとって⼀種の福利厚⽣だと思う 39

Slide 40

Slide 40 text

伝えたいことエンジニアがその本分である技術的な領域に注⼒するのも⼤事だけど、SaaS企業の成⻑を⽀えるにはプロダクトを知るということもまた⼤事⾃分が関わっているプロダクトのこと、どのくらい知ってますか？ 40

Slide 41

Slide 41 text

We are Hiring !!! 41