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

by kaminashi, Inc.

Slide 1

Slide 1 text

株式会社カミナシ今日からできる! 技術的負債返済への最初の一歩 2023.07.19 発表資料技術的負債、どうやって解消した？リアーキテクチャ・リファクタ事例から学ぶ Lunch LT

Slide 2

Slide 2 text

自己紹介鈴木健太郎 / Kentaro SUZUKI @szk3 すずけん | Cloud Architect, Software Engineer 株式会社カミナシ　エンジニアリング本部　Harami Engineering 第2ユニット　ソフトウェアエンジニア

Slide 3

Slide 3 text

現場DXプラットフォームカミナシ

Slide 4

Slide 4 text

アジェンダ

Slide 5

Slide 5 text

5 １．技術的負債になりかけていた機能を　　リアーキテクティングしたら　　めちゃくちゃ改善した話　（ダイジェスト版）２．リアーキテクティングPJで学んだこと３．まとめアジェンダ

Slide 6

Slide 6 text

技術負債になりかけていた機能をリアーキテクティングしたらめちゃくちゃ改善した話（ダイジェスト版）

Slide 7

Slide 7 text

古くから存在する１つの機能をリアーキテクティングしたら... 目に見える成果を出すことができました 🙌 ● 処理時間は、4分の１以下に ● AWSリソースの利用コストは、90％程度削減

Slide 8

Slide 8 text

お客様が記録した帳票データを、Excel形式のファイルに変換し、出力するバッチ処理をリアーキテクティングリアーキテクティングの対象となった機能 xlsx形式 DB xlsx形式 xlsx形式ファイル

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

利用者の増加とともに、設計当初のシステムアーキテクチャが技術的負債（当時の最適が今の最適ではなくなった）になっていた抱えていた課題１．バッチ処理のスループットをあげにくい２．AWSリソースの利用コストが無駄にかかる３．バッチ処理が失敗するとスクラムに影響が大きい旧システムアーキテクチャが抱えていた課題

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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を中心に非同期処理を実現

Slide 13

Slide 13 text

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. バッチ処理を責務で分離

Slide 14

Slide 14 text

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. スケールアウトの実現と、自動リトライの導入

Slide 15

Slide 15 text

抱えていた課題を、きれいに解消 👍 １．バッチ処理のスループットをあげにくい　→　スケールアウトできる仕組みを実現２．AWSリソースの利用コストが無駄にかかる　→　AWS リソースの利用コストを約90%削減３．バッチ処理が失敗するとスクラムに影響が大きい　→　リトライ処理および監視の効率化新システムアーキテクチャで解消した課題

Slide 16

Slide 16 text

変換処理が集中する月初でのバッチ処理時間 (※移行時の計測データ）　先月との比較で、処理時間は４分の１に 👏 　＼２時間7分(127分) → 29分／リアーキテクティングの成果

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

リアーキテクティングPJからの学び

Slide 19

Slide 19 text

リアーキテクティングPJが、一定の成果を出せた要因として考えられるものリアーキテクティングPJを振り返り、何がよかったのかを再考 👀 成果に繋がった要因と考えられること 1. 技術的負債に対する、組織的な理解がある 2. Design Doc を通じてチームメンバー間の認識齟齬を減らす 3. 新システムアーキテクチャの不確実性を可能な限り減らす

Slide 20

Slide 20 text

1．技術的負債に対する、組織的な理解組織やPJの生成に決裁権を持つ人のPJに対する理解 ● ワーキンググループではなく、業務としてPJ化 https://speakerdeck.com/toricls/the-debt?slide=33 https://speakerdeck.com/toricls/the-debt?slide=34

Slide 21

Slide 21 text

1．技術的負債に対する、組織的な理解システムが要求を満たせなくなる前に、最適を再評価・反映 https://speakerdeck.com/toricls/the-debt?slide=18 https://speakerdeck.com/toricls/the-debt?slide=17

Slide 22

Slide 22 text

1．技術的負債に対する、組織的な理解現場の人は、ステークホルダーに説明する責任があり、意思決定者は、合意形成と認識共有に責任がある https://speakerdeck.com/toricls/the-debt?slide=36 https://speakerdeck.com/toricls/the-dbt?slide=37

Slide 23

Slide 23 text

2．Design Doc を通じて、チームメンバー間の認識齟齬を減らす認識齟齬・情報格差をなくす為に Design Doc が機能した ● PJの遂行は新しいチームで担当 ● 入社間もないメンバーもいた

Slide 24

Slide 24 text

2．Design Doc を通じて、チームメンバー間の認識齟齬を減らす Design Doc を書くと、何がもたらされるのか？ ● 現状、課題、目標・アウトカムの目線が揃えやすくなる(※) ● 対象とする範囲が明確になる（ノンゴールの明示） ● チームとしてトレードオフを考慮した意思決定ができる (※) 例えば、前述のPJにおけるアウトカムは以下のように定義　「変換処理が集中する月初の目標処理時間を1時間以内にする」

Slide 25

Slide 25 text

2．Design Doc を通じて、チームメンバー間の認識齟齬を減らす Design Doc 記述の工夫 ● スクラムタスクとして、妥当な工数を確保 ● チームで共通のフォーマットを使う ● レビューはチーム全員で行う

Slide 26

Slide 26 text

3．新システムアーキテクチャの不確実性を可能な限り減らす新システムアーキテクチャが安定している保証はない ● 大きな変更ほど、ビッグバンリリースは避ける ● ロールバックのしやすさを重視 ● Feature Flagsなどを用い、段階的ロールアウトを計画する

Slide 27

Slide 27 text

3．新システムアーキテクチャの不確実性を可能な限り減らすエンジニア以外のチームにも、協力を依頼する前提で調整 ● カスタマーサポート(CS) チームがサポートしやすい移行計画 ● PJは新しいチームで担当したのでチームの力を過信しすぎない

Slide 28

Slide 28 text

まとめ

Slide 29

Slide 29 text

リアーキテクティングPJからの学びを踏まえ... 今日からできる!技術的負債返済への最初の一歩を提案 1. 技術的負債について対話を増やそう 2. 技術的負債について課題となりたい状態を言語化しよう

Slide 30

Slide 30 text

共通認識を作るため、チームや組織で対話を増やそう ● 最適は、時間や環境で変化しうるものだから ● 当事者は、自分（とそのチーム）なのだから ● あなたとわたしの技術的負債の捉え方は違うかも知れないからまとめ - 1．技術的負債について対話を増やそう

Slide 31

Slide 31 text

まとめ - 2．技術的負債について、課題となりたい状態を言語化しよう Design Doc で現状を整理し、課題となりたい状態を言語化しよう ● 人は、忘れる生き物だから ● 課題の整理とゴール設定が、推進力を産むから ● なりたい状態が、設計の精度を上げるから

Slide 32

Slide 32 text

まとめ - 今日からできる!技術的負債返済への最初の一歩新しく何かを作るより、既存のシステムを運用しながら改善するほうが難易度が高い (※ことが多い) なので、地に足をつけてPJを前に進めるには、対話やゴール設定など、普通のことを普通にやりきるための仕組みやチームのマインドが大切

Slide 33

Slide 33 text

ﾀﾉｼｲﾖ-! ﾏｯﾃﾙﾖ-! We’re Hiring !! We're Hiring !! CTO at Kaminashi, Inc. Tori Hara @toricls