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

Transcript

1. バックエンドエンジニアが考える プロダクトへの向き合い⽅ SaaS企業の成⻑を⽀えるバックエンドの裏側 株式会社IVRy Odashi 1
2. ⾃⼰紹介 • 名前：Odashi • 領域：バックエンド • 考え⽅：楽しい⽅の⾒⽅ • 趣味：クラヴマガ‧ジム 2
4. 今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 4
5. 今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 5
6. IVRyのシステム概要 6
7. IVRyのシステム概要 7 - ECS - APIとバッチ処理 - 通話データの同期 - Aurora PostgreSQL - Redis - ⼀部LLMの利⽤も
8. 今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 8
9. マインド - 1⼈1⼈がプロダクト志向のエンジニアが多い - ⾃分たちもいちクライアントとして実際に使ってみる - As Is, To Beをしっかり考えられる - Design Docの活⽤ 9
10. プロダクト志向 プロダクト志向とは チームメンバー全員がプロダクトをまるで⾃分の⼦どものよう に愛し、⾃分の担当領域だけではなく、プロダクト全体のこと を考えることを「プロダクト志向」とよぶ。 引⽤ 及川 卓也; ⼩城 久美⼦; 曽根原 春樹. プロダクトマネジメントのすべて 事業戦略‧IT開発‧UXデザイン‧ マーケティングからチーム‧組織運営まで . 株式会社 翔泳社. Kindle 版. 10
11. プロダクト志向 - ⼊社後のオンボーディングで全オプションを含めた⾃由に 使えるアカウントを発⾏する - エンジニアもCLインタビューや展⽰会に参加する - 触ってみて実感することが⼤事 - プロダクトをどう成⻑させていくかを⾃分の中に持つこと ができる 11
12. プロダクト志向 12
13. As Is, To Be As Is, To Beとは As Is：現在の状態 To Be：理想の状態 現在と理想のギャップ（課題）を明確にし、解決のためのアク ションを導き出すための分析フレームワーク 13
14. As Is, To Be - スタートアップ＝⼈⼿不⾜ - 「今まではこうだった」「今はこうなっているから」と省 エネ志向に⾛りがち - 今ある知識だと本当はどうなるのが理想かを常に追求する カルチャーがある 14
15. Design Doc Design Docとは これから新しく開発しようとするソフトウェアの全体の設計 や、既存のコードのpatchやプルリクエスト(PR)のコード変更 の基本的な要点をまとめる⽂書 引⽤ https://myenigma.hatenablog.com/entry/2021/07/25/140308 15
16. Design Doc 16 - ⼤きな案件は必ず書く - 規模が⼩さくても⽅向性の 擦り合わせなどにも有⽤
17. Design Doc 17 - 重要なのはスコープと設計 - スコープはシステム影響範 囲 - スコープアウトも書いた - 設計は実装の⽅針
18. Design Doc - 正確さが重要なので 基本は⽂字で残す - 図などは補助する位 置付け（システム全 体像、ER図やシーケ ンス図など） 18
19. Design Doc - 人は必ず忘れる生き物 - 1人が考えるTo Beにも限界がある - あの時どう考えていたかを振り返る方法になる - 今ならあの時のTo Beを実現できそう？ - もっと良さそうなTo Beを思いついた - 方向性の擦り合わせにもなる 19
20. マインド プロダクト志向 As Is, To Be Design Doc 20
21. 今⽇話すこと 1. IVRyのシステム概要 2. マインド 3. テック 21
22. テック - Rubyバージョンと向き合う - デプロイ頻度の改善 22
23. バージョンと向き合う - Ruby = 3.3.2（最新は3.3.3） - 3.3.1の時にYJITを有効化した ※2024/6/25現在 23
24. Rubyバージョンアップ 24
25. Rubyバージョンアップ 25
26. Rubyバージョンアップ 26 最初は3.1.2だった
27. Rubyバージョンアップ 27 バージョンと向き合い始めた頃 3.2.2のリリースは2023-3-30なので約1年遅 れ
28. Rubyバージョンアップ 28 3.2.3のリリースは2024-1-18なので約3ヶ⽉遅れ
29. Rubyバージョンアップ 29 3.2.4のリリースは2024-4-23（脆弱性対策 のパッチで2⽇遅れ）
30. Rubyバージョンアップ 30 3.3.1のリリースは2024-4-23なので約1週間遅れ ここでYJIT有効化
31. Rubyバージョンアップ 31 3.3.2のリリースは2024-5-30なので約1週間遅れ
32. YJITとは - Ruby3.1に導⼊されたJIT(Just In Time)コンパイラ - 実⾏時に機械語を⽣成することで最適化が⾏われる - 3.1導⼊、3.2正式サポート、3.3安定化と進化している 32
33. Rubyバージョンアップ 33 - YJITは3.2.0から有効化できたがあえてしなかった - YJITが⽣成する機械語やその管理のために確保するメモリ が際限なく増える可能性があった - ⼀応対策はあったが3.3で改善されたこともわかった - 状況を適切に理解し、しないという判断も⼤事
34. Rubyバージョンアップ 34 Matz（Rubyのパパ）からの クリスマスプレゼントと⾔ われたり⾔われなかったり
35. Rubyバージョンアップ - 基本的に後回しにされがち - 直接的なアウトカムが⾒えないから - とは⾔え間接的に貢献する - プロダクトの本質に向き合える時間を増やす 35
36. デプロイ頻度の改善 ⽬標：毎⽇デプロイ 36
37. デプロイ頻度の改善 - mainブランチにマージされたら⾃動デプ ロイとslack通知 - Staging環境で動確が終わればemojiを つける＝いつデプロイしてもOKという ⽰し - Productionへのデプロイはワークフロー で⾏う - BEにはメンションして共有 - だいたいemojiがついているのでその ままデプロイを進められることが多い いつでもデプロイ可能にするための仕組み を作り、可能な限り⾃動化させる 37
38. デプロイ頻度の改善 38
39. デプロイ頻度の改善 - デプロイの頻度が多いことはプロダクトの変更を容易にす る - 差分が少ない→レビューに時間がかからない→すぐ価 値を届けられる→次の作業にすぐ取り掛かれる - ライブラリのバージョンアップも容易になるので新しい バージョンを利⽤しやすくなる - エンジニアにとって⼀種の福利厚⽣だと思う 39
40. 伝えたいこと エンジニアがその本分である技術的な領域に注 ⼒するのも⼤事だけど、SaaS企業の成⻑を⽀え るにはプロダクトを知るということもまた⼤事 ⾃分が関わっているプロダクトのこと、どのく らい知ってますか？ 40
41. We are Hiring !!! 41