今日からできる! 技術的負債返済への最初の一歩 / You Can Start Today! Take Your First Step To Paying Off Technical Debt

2023/07/19　技術的負債、どうやって解消した？リアーキテクチャ・リファクタ事例から学ぶLunch LT

今日からできる! 技術的負債返済への最初の一歩
https://findy.connpass.com/event/288877/

ソフトウェアエンジニア
鈴木 健太郎

Transcript

1. 株式会社カミナシ 今日からできる! 技術的負債返済への最初の一歩 2023.07.19 発表資料 技術的負債、どうやって解消した？ リアーキテクチャ・リファクタ事例から学ぶ Lunch LT
2. 自己紹介 鈴木 健太郎 / Kentaro SUZUKI @szk3 すずけん | Cloud Architect, Software Engineer 株式会社カミナシ 　エンジニアリング本部 　Harami Engineering 第2ユニット 　ソフトウェアエンジニア
3. 現場DXプラットフォーム カミナシ
4. アジェンダ
5. 5 １．技術的負債になりかけていた機能を 　　リアーキテクティングしたら 　　めちゃくちゃ改善した話 　 （ダイジェスト版） ２．リアーキテクティングPJで学んだこと ３．まとめ アジェンダ
6. 技術負債になりかけていた機能を リアーキテクティングしたら めちゃくちゃ改善した話 （ダイジェスト版）
7. 古くから存在する１つの機能をリアーキテクティングしたら... 目に見える成果を出すことができました 🙌 • 処理時間は、4分の１以下 に • AWSリソースの利用コストは、90％程度削減
8. お客様が記録した帳票データを、Excel形式のファイルに変換し、 出力するバッチ処理をリアーキテクティング リアーキテクティングの対象となった機能 xlsx形式 DB xlsx形式 xlsx形式 ファイル
9. Read / Write AWS Cloud 旧システムアーキテクチャの構成図 Amazon EventBridge AWS CodeBuild Amazon Elastic Container Registry (Amazon ECR) Amazon Aurora Amazon Simple Storage Service (Amazon S3) 1 2 3 4 Triger Image pull Docker run Create xlsx file goroutine(1..n) Put xlsx
10. 利用者の増加とともに、設計当初のシステムアーキテクチャが 技術的負債（当時の最適が今の最適ではなくなった）になっていた 抱えていた課題 １．バッチ処理のスループットをあげにくい ２．AWSリソースの利用コストが無駄にかかる ３．バッチ処理が失敗するとスクラムに影響が大きい 旧システムアーキテクチャが抱えていた課題
11. AWS Cloud Amazon Fargate 新システムアーキテクチャの構成図 xlsx Amazon EventBridge Job Submit 1 2 3 4 Triger Find conversion targets Amazon Aurora Create xlsx file Container AWS Batch Amazon Fargate Amazon S3 Job Scheduling 5 6 xlsx xlsx Find export data
12. AWS Cloud Amazon Fargate 新システムアーキテクチャのポイント - 1. AWS Batchを中心に非同期処理を実現 xlsx Amazon EventBridge Job Submit 1 2 3 4 Triger Find conversion targets Amazon Aurora Create xlsx file Container AWS Batch Amazon Fargate Amazon S3 Job Scheduling 5 6 xlsx xlsx Find export data 4 AWS Batch Job Scheduling 1. AWS Batchを中心に非同期処理を実現
13. AWS Cloud 新システムアーキテクチャのポイント - 2. バッチ処理を責務で分離 xlsx Amazon EventBridge 1 2 4 Triger Find conversion targets Amazon Aurora Container AWS Batch Amazon S3 Job Scheduling xlsx xlsx Amazon Fargate Job Submit 3 5 Find export data Amazon Fargate Create xlsx file 6 2. バッチ処理を責務で分離
14. AWS Cloud Amazon Fargate 新システムアーキテクチャのポイント - 3. スケールアウトの実現と、自動リトライの導入 xlsx Amazon EventBridge Job Submit 1 2 3 Triger Find conversion targets Amazon Aurora Create xlsx file Container Amazon S3 5 6 xlsx xlsx Find export data 4 AWS Batch Amazon Fargate Job Scheduling 3. スケールアウトの実現と、自動リトライの導入
15. 抱えていた課題を、きれいに解消 👍 １．バッチ処理のスループットをあげにくい 　→　スケールアウトできる仕組みを実現 ２．AWSリソースの利用コストが無駄にかかる 　→　AWS リソースの利用コストを約90%削減 ３．バッチ処理が失敗するとスクラムに影響が大きい 　→　リトライ処理および監視の効率化 新システムアーキテクチャで解消した課題
16. 変換処理が集中する月初でのバッチ処理時間 (※移行時の計測データ） 　先月との比較で、処理時間は ４分の１に 👏 　＼ ２時間7分(127分) → 29分 ／ リアーキテクティングの成果
17. LTで収まらないので、もっと詳しく！ スライドを公開しています 👀 (※ AWS Dev Day 2023 Tokyo のオンデマンド配信で動画もご覧いただけます) https://speakerdeck.com/kaminashi/a-story-that-improved-a-lot-when-re-architecting-a-function-that-was-about-to-become-technical-debt
18. リアーキテクティングPJからの学び
19. リアーキテクティングPJが、一定の成果を出せた要因として考えられるもの リアーキテクティングPJを振り返り、何がよかったのかを再考 👀 成果に繋がった要因と考えられること 1. 技術的負債に対する、組織的な理解がある 2. Design Doc を通じてチームメンバー間の認識齟齬を減らす 3. 新システムアーキテクチャの不確実性を可能な限り減らす
20. 1．技術的負債に対する、組織的な理解 組織やPJの生成に決裁権を持つ人のPJに対する理解 • ワーキンググループではなく、業務としてPJ化 https://speakerdeck.com/toricls/the-debt?slide=33 https://speakerdeck.com/toricls/the-debt?slide=34
21. 1．技術的負債に対する、組織的な理解 システムが要求を満たせなくなる前に、最適を再評価・反映 https://speakerdeck.com/toricls/the-debt?slide=18 https://speakerdeck.com/toricls/the-debt?slide=17
22. 1．技術的負債に対する、組織的な理解 現場の人は、ステークホルダーに説明する責任があり、 意思決定者は、合意形成と認識共有に責任がある https://speakerdeck.com/toricls/the-debt?slide=36 https://speakerdeck.com/toricls/the-dbt?slide=37
23. 2．Design Doc を通じて、チームメンバー間の認識齟齬を減らす 認識齟齬・情報格差をなくす為に Design Doc が機能した • PJの遂行は新しいチームで担当 • 入社間もないメンバーもいた
24. 2．Design Doc を通じて、チームメンバー間の認識齟齬を減らす Design Doc を書くと、何がもたらされるのか？ • 現状、課題、目標・アウトカムの目線が揃えやすくなる(※) • 対象とする範囲が明確になる（ノンゴールの明示） • チームとしてトレードオフを考慮した意思決定ができる (※) 例えば、前述のPJにおけるアウトカムは以下のように定義 　「変換処理が集中する月初の目標処理時間を1時間以内にする」
25. 2．Design Doc を通じて、チームメンバー間の認識齟齬を減らす Design Doc 記述の工夫 • スクラムタスクとして、妥当な工数を確保 • チームで共通のフォーマットを使う • レビューはチーム全員で行う
26. 3．新システムアーキテクチャの不確実性を可能な限り減らす 新システムアーキテクチャが安定している保証はない • 大きな変更ほど、ビッグバンリリースは避ける • ロールバックのしやすさを重視 • Feature Flagsなどを用い、段階的ロールアウトを計画する
27. 3．新システムアーキテクチャの不確実性を可能な限り減らす エンジニア以外のチームにも、協力を依頼する前提で調整 • カスタマーサポート(CS) チームがサポートしやすい移行計画 • PJは新しいチームで担当したのでチームの力を過信しすぎない
28. まとめ
29. リアーキテクティングPJからの学びを踏まえ... 今日からできる!技術的負債返済への最初の一歩 を提案 1. 技術的負債について対話を増やそう 2. 技術的負債について課題となりたい状態を言語化しよう
30. 共通認識を作るため、チームや組織で対話を増やそう • 最適は、時間や環境で変化しうるものだから • 当事者は、自分（とそのチーム）なのだから • あなたとわたしの技術的負債の捉え方は違うかも知れないから まとめ - 1．技術的負債について対話を増やそう
31. まとめ - 2．技術的負債について、課題となりたい状態を言語化しよう Design Doc で現状を整理し、課題となりたい状態を言語化しよう • 人は、忘れる生き物だから • 課題の整理とゴール設定が、推進力を産むから • なりたい状態が、設計の精度を上げるから
32. まとめ - 今日からできる!技術的負債返済への最初の一歩 新しく何かを作るより、既存のシステムを運用しながら改善するほうが 難易度が高い (※ことが多い) なので、地に足をつけてPJを前に進めるには、対話やゴール設定など、 普通のことを普通にやりきるための仕組みやチームのマインドが大切
33. ﾀﾉｼｲﾖ-! ﾏｯﾃﾙﾖ-! We’re Hiring !! We're Hiring !! CTO at Kaminashi, Inc. Tori Hara @toricls
34. ご静聴ありがとうございました
35. https://kaminashi.jp 株式会社カミナシ