スタートアップにおける、チーム拡大を見据えたコンポーネント分割の取り組み
by
Ryunosuke Iwai
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
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
ク ラ ウ ド 運 ⽤ を 安 全 に