技術的負債の返済について

Transcript

1. 技術的負債の返済について
2. - 宮原周作(mish)
 - var_mish_run
 - 株式会社SODAで、バックエンド開発を担当
 - モデリングとか、DDDが好き
 - 7月からモジュール分割のPJTが動かせることになりました！！！！
 
 自己紹介

3. 国内 No.1 スニーカー・トレカ フリマ メディア コミュニティ マーケットプレイス
4. 技術スタック Pub/Sub 決済代行業 者 Worker Batch Server 決済Proxy JP Store Admin Batch Server Global Store Internal AWS Local CI/CD Monitoring (HTTPS endpoints)
5. 今日話すこと 
 - SNKRDUNKの歴史と技術的負債による影響
 - 負債に対し、どのように立ち向かおうとしているのか

6. リリース 2018.07 2019.08 2020.09 2021.01 2021.07 2021.09 2021.11 2021.12 2022.04 2023.01 マーケット機能 リリース 25億円 資⾦調達 SODA Singapore INT PTE. LTD.設⽴ SoftBank Vision Fund 2から資⾦調達 Global Appリリース 62億円資⾦調達 モノカブ買収 TVCM 全国放送 初の実店舗 原宿店OPEN ヤフオク!と 業務提携 リリース 代々⽊公園のビルの ⼀室でスタート オフィスを 渋⾕の岡崎ビルに移転 オフィスを BIZCORE渋⾕に移転 スニダンベースを 豊洲エリアの最新鋭都市型 物流センターに移転 シンガポール⽀社 海外ストア⼀号店を開設 History(沿革)

7. - 記事、コミュニティ
 - マーケットプレイス
 - C to C、B to C
 - スニーカー、アパレル、腕時計、トレカ、フィギュア
 - 購入形態
 - オファー、即購入、カート購入、抽選販売、予約販売
 - その他色々
 拡充された機能 

8. Team A Team B Team C Team D Web 🙋🙋🙋🙋🙋 | WebFE 🙋| Flutter 🙋🙋 | QAE 🙋 | Design 🙋 | PdM 🙋 EM 🙋🙋🙋🙋🙋 Web 🙋🙋🙋🙋 | WebFE 🙋🙋 | Flutter 🙋🙋🙋 | QAE 🙋 | Design 🙋 | PdM 🙋 Web 🙋🙋🙋🙋 | QAE 🙋🙋 | PdM 🙋 Web 🙋🙋🙋🙋 | WebFE 🙋| QAE 🙋 | Design 🙋 | PdM 🙋 SREs 🙋🙋🙋 Team EM Team SRE Team E Web 🙋🙋🙋🙋 | QAE 🙋 | Design 🙋 | PdM 🙋 Team G Web 🙋🙋🙋 | Flutter 🙋 | Design 🙋 | PdM 🙋 総勢59名 プロダクト開発組織 

9. 機能拡充、開発組織の成長の裏に技術的負債あり 

10. - 度重なる機能追加で、複数のコンテキストをまたいだファットなモデルやユースケー ス、テーブルが増加
 - JPとGlobalでリポジトリが分かれている
 技術的負債の具体例 

11. 深堀りする 

12. - 低凝集、密結合な状態
 - 新規機能実装時に、既存機能に影響する
 - 新規機能をAチームが開発する際に、Bチームが機能開発したものが影 響する
 - AチームがBチームの機能開発したものを0からキャッチアップする必要が あり
 - リファインメントに時間がかかるし、考慮漏れも度々発生する
 ファットなモデルやユースケース、テーブルが増加 

13. 定量的に循環的複雑度を計測してみる 

14. - ソフトウェアの複雑度を表す指標
 - 一般的に10以下が望ましいとされている
 循環的複雑度とは ?
 MATLAB & Simulink. 「循環的複雑度」. https://jp.mathworks.com/discovery/cyclomatic-complexity.html。
15. - いかなる変更も誤修正を生む関数、メソッドが15件
 - 循環的複雑度の最大値: 212 
 
 弊社の場合 

16. - 購入、検索などSNKRDUNKの重要な機能が多数
 - 改修頻度高め
 - 改修コストが圧倒的に高い状態
 - とてもつらい
 循環的複雑度 75以上のパターン 

17. JPとGlobalでリポジトリが分かれている 

18. - 立ち上がるか分からないGlobal Appの開発に工数をかけたくなかった
 - JPにGlobalのビジネスルールを入れて統合前提の開発を初期から実装する と、開発工数が膨れあがる
 - 0から作ったほうがGlobalの開発工数がかからない
 なぜ、JPとGlobalでリポジトリが分けたのか 

19. - 同じ機能を開発しようとすると、JPとGlobalで二度手間
 - JP機能開発時に、Globalへの考慮漏れが度々発生
 - JPの商品マスタがいびつな構造になっている
 - JPの商品マスタをGlobalがレプリケーションして取り込んでいる
 - JPの商品マスタの変更によって、Globalが影響受ける
 JPとGlobalでリポジトリが分かれている影響 

20. 技術的負債の影響まとめ 
 - 徐々に、機能開発の速度が鈍化しはじめる
 - 月ごとのインシデントの件数も増加傾向

21. 改善するには 
 - 本質的には、高凝集、疎結合なモジュールに切り出していく
 - 切り出したモジュールにチームを割り当てる
 - 切り出す際に、JPとGlobalを統合する

22. 適切なモジュールの単位は？ 
 - 境界づけられたコンテキストが適切と判断

23. 境界づけれられたコンテキストの定義方法 
 - イベントストーミングの実施してコンテキスト境界を判断
 - 詳細は下記の記事に記載
 - https://zenn.dev/team_soda/articles/bc967dd28b400f
 - 

24. 完成したコンテキストマップ草案 

25. どのコンテキストから切り出すか 
 - 結論、商品カタログから切り出す

26. 商品カタログとは ?
 - 商品などのマスタ情報を取り扱うコンテキスト
 - 商品名、品番、ブランド、定価、カテゴリなど
 - どの情報を商品カタログで取り扱うかはモデリング中

27. 商品カタログ選定理由 
 - 他コンテキストとの依存関係的に分割しやすそう
 - コアドメインの出品、一次在庫、販売は別のコンテキストに依存しているし、依存され ているので移行の難易度が高い
 - 商品カタログと決済は別のコンテキストに依存していない 
 - 商品マスタはGlobalとの連携がすでにProduction環境で動作済み
 - Global統合に向けて必要なことがある程度明確
 - マスタの変更がJPとGlobalで取り扱いやすい状態になっていることに対する事業貢献度が 高い

28. 7月 論理アーキテクチャ 設計 物理アーキテクチャ 設計 モジュール実装 モノリスコード 移行計画 モノリスコードの移行 カテゴリ データ構造の検討 Epic 8月 9月 10月 11月 商品カタログ暫定スケジュール 

29. 技術的負債は絶賛返済中！ 
 - 商品カタログが終わり次第、別のコンテキストの切り出しに取り掛かっていく予定
 - 何から切り出していくは未定

30. さいごに

31. 技術的負債は悪なのか？ 
 - 辛いことも多々あるが、振り返ってみると悪ではない
 - より早くユーザーへの価値提供することが軸にあり、その都度ベストエフォートな選 択をしてきた
 - 例: Globalのリポジトリ、アプリケーションをJPと分割して開発する意思決定は 正しかったと認識
 - 結果的に技術的負債になってしまったところは多々あるが、時価総額1,000億規模 のIPOを目指せるところまで会社は成長している
 - 技術的負債は溜まったら、適切に返済していくしかない

32. 技術的負債を一緒に返済しようとしてくれる人を募集しています！ 

33. 株式会社SODA 
 国内 No.1 スニーカー・トレカフリマ https://recruit.soda-inc.jp/engineer Entrance Book https://zenn.dev/p/team_soda Engineering Blog Goエンジニア 積極採用中です！ Designed by Renée French
34. ご清聴ありがとうございました