Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
スタートアップにおける、チーム拡⼤を⾒ 据えたコンポーネント分割の取り組み @技術的負債に向き合うOnline Conference Cloudbase 株式会社 岩井⿓之介 / @ryuke
Slide 2
Slide 2 text
株式会社メルカリ Microservices Platform CI/CD @ryuke 岩井 ⿓之介 Cloudbase株式会社 Scanner & Platform チーム Go / terraform / Datadog 前職 現在 SNS https://twitter.com/i_ryuke
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
https://cloudbase.ink/
Slide 5
Slide 5 text
システム構成
Slide 6
Slide 6 text
組織‧プロダクトの成⻑に伴って⽣じてきた課題 ● チーム(エンジニア+デザイナー+PdM)が9⼈になり、1チームでコミュニ ケーションを取るのが徐々に難しくなってきた ● 要求されるドメイン知識や関⼼事が、コンポーネントごとに⼤きく異な り、メンバーの認知負荷が⾼い
Slide 7
Slide 7 text
組織‧プロダクトの成⻑に伴って⽣じてきた課題 ● チーム(エンジニア+デザイナー+PdM)が9⼈になり、1チームでコミュニ ケーションを取るのが徐々に難しくなってきた ● 要求されるドメイン知識や関⼼事が、コンポーネントごとに⼤きく異な り、メンバーの認知負荷が⾼い → チーム分割へ
Slide 8
Slide 8 text
Team Topologies ● コンウェイの法則 = ソフトウェアアーキテク チャと組織構造の間には「同型⼒」が働く ● ソフトウェアの⾃然な境界 = 節理⾯ でチームを分割する マシュー・スケルトン (著), マニュエル・パイス (著), 原田 騎郎 (翻訳), 永 瀬 美穂 (翻訳), 吉羽 龍太郎 (翻訳)『チームトポロジー 価値あるソフト ウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセン ター, 2021
Slide 9
Slide 9 text
システムの要素を整理する お客様のクラウド環境から取得 した構成情報を元にセキュリ ティリスクを分析し、データ ベースに保存した結果をSaaS上 で表⽰する
Slide 10
Slide 10 text
システムの要素を整理する お客様のクラウド環境から取得 した構成情報を元にセキュリ ティリスクを分析し、データ ベースに保存した結果をSaaS上 で表⽰する
Slide 11
Slide 11 text
システムの要素を整理する 取得 分析 保存 表示 インフラ Step Functions Step Functions Step Functions ECS Service + Vercel 言語 Go Go NodeJS NodeJS ドメイン クラウド セキュリティ SaaS SaaS 関心事 データの正確性 データの正確性 データの正確性 顧客体験 変更のケイデン ス 低速 (機能開発的) 低速 (機能開発的) 低速 (機能開発的) 高速 (仮説検証的)
Slide 12
Slide 12 text
システムの要素を整理する 取得 分析 保存 表示 インフラ Step Functions Step Functions Step Functions ECS Service + Vercel 言語 Go Go NodeJS NodeJS ドメイン クラウド セキュリティ SaaS SaaS 関心事 データの正確性 データの正確性 データの正確性 顧客体験 変更のケイデン ス 低速 (機能開発的) 低速 (機能開発的) 低速 (機能開発的) 高速 (仮説検証的)
Slide 13
Slide 13 text
システムの要素を整理する 取得 分析 保存 表示 インフラ Step Functions Step Functions Step Functions ECS Service + Vercel 言語 Go Go NodeJS NodeJS ドメイン クラウド セキュリティ SaaS SaaS 関心事 データの正確性 データの正確性 データの正確性 顧客体験 変更のケイデン ス 低速 (機能開発的) 低速 (機能開発的) 低速 (機能開発的) 高速 (仮説検証的) Scanner Application
Slide 14
Slide 14 text
得られた結果 ● 結果として、お客様との接点でプロダクトを磨き込むStream-Aligned的なチー ム(Application)と、⼟台となるデータ基盤を提供し前線のチームの認知負荷 を取り除くPlatform的なチーム(Scanner)に分離 😄 チームサイズが下がったことでチーム内のコミュニケーションも密に 😄 ドメインが分割されたことで各チームの認知負荷も下がった 😄 前線のチームがより⾼速に仮説検証を回せるようになった
Slide 15
Slide 15 text
Fin.
Slide 16
Slide 16 text
本当にこれでよかったのか...?
Slide 17
Slide 17 text
よく⾒ると...? 取得 分析 保存 表示 インフラ Step Functions Step Functions Step Functions ECS Service + Vercel 言語 Go Go NodeJS NodeJS ドメイン クラウド セキュリティ SaaS SaaS 関心事 データの正確性 データの正確性 データの正確性 顧客体験 変更のケイデン ス 低速 (機能開発的) 低速 (機能開発的) 低速 (機能開発的) 高速 (仮説検証的) Scanner Application
Slide 18
Slide 18 text
よく⾒ると...? 取得 分析 保存 表示 インフラ Step Functions Step Functions Step Functions ECS Service + Vercel 言語 Go Go NodeJS NodeJS ドメイン クラウド セキュリティ SaaS SaaS 関心事 データの正確性 データの正確性 データの正確性 / 顧客体験 顧客体験 変更のケイデン ス 低速 (機能開発的) 低速 (機能開発的) 低速 (機能開発的) 高速 (仮説検証的) Scanner Application
Slide 19
Slide 19 text
境界の曖昧なコンポーネントが発⽣していた
Slide 20
Slide 20 text
境界の曖昧なコンポーネントが発⽣していた Application Scanner
Slide 21
Slide 21 text
曖昧なチーム境界が引き起こす課題 ● Loaderに両チームの様々なロジックが混在 ○ S3からのデータの取得、前回スキャン結果との差分の計算、DBへの永続化、差 分の通知、... ○ 徐々に「誰も怖くて触れない」コンポーネントに ● Scannerの最終成果物が、RDSに保存されている ○ DBの共通所有によるチーム間コミュニケーションコスト、所有権の曖昧さ ○ Scannerのテストスコープが肥⼤化
Slide 22
Slide 22 text
曖昧なチーム境界が引き起こす課題 ● Loaderに両チームの様々なロジックが混在 ○ S3からのデータの取得、前回スキャン結果との差分の計算、DBへの永続化、差 分の通知、... ○ 徐々に「誰も怖くて触れない」コンポーネントに ● Scannerの最終成果物が、RDSに保存されている ○ DBの共通所有によるチーム間コミュニケーションコスト、所有権の曖昧さ ○ Scannerのテストスコープが肥⼤化 → Loaderを分割することで、RDSよりも良い境界を⾒つけられないか?
Slide 23
Slide 23 text
モノリスからマイクロサービスへ ● データとロジックのオーナーシップを揃える ことで、何を共有して何を隠すかを決められ るようにする ● サービスの分割は段階的に⾏う (モジュラーモノリス) Sam Newman (著), 島田 浩二 (翻訳)『モノリスからマイクロサービスへ ―モノリ スを進化させる実践移行ガイド』オライリージャパン , 2020
Slide 24
Slide 24 text
Loaderを分割していく
Slide 25
Slide 25 text
1. コンポーネントの構造は維持したまま、中の実装だけを分割 interface = 契約
Slide 26
Slide 26 text
2. データとロジックの境界を揃える interface = 契約
Slide 27
Slide 27 text
3. 将来的には、コンポーネントとして分割していく interface = 契約
Slide 28
Slide 28 text
得られた結果 ● 現在はまだ「1. 中の実装だけを分割」の状態 😄 ロジックのオーナーシップが整理された 😄 DBより⼿前の段階でデータを検証できるようになった 😄 インターフェースを切ったことで、期待される出⼒が明確になった ● 「切り込み」に留めておくことで、変化に柔軟に対応できる形に ○ インターフェースを調整しながら固めていける、⼿戻りしやすい ○ データの不整合といった難しい問題に対処せずに済む
Slide 29
Slide 29 text
Key Messages:チーム分割において気をつけるべきポイント ● チームとシステムの境界のずれに、技術的負債が発⽣することがある 所有権の曖昧なロジックが詰め込まれ、メンテ性が低下しやすい ● ソフトウェアの⾃然な境界 = 節理⾯でチーム‧システムを分割する ⼀度決めたら終わりではなく、常により良い節理⾯を模索していく ● 「システムの切り込み」から始める 変化に対応しつつ、少しずつインターフェースを固めていく
Slide 30
Slide 30 text
ク ラ ウ ド 運 ⽤ を 安 全 に