スケールするプロダクトと膨らむ組織 SREの挑戦と解決策 2025年2月27日 株式会社コドモン 佐々木真也 3社が語るSREの役割 組織の変遷と直面した課題とは？

2 ● 名前 ○ 佐々木真也 ● 所属 ○ 株式会社コドモン ■ SREチーム マネージャー ● X ○ @taishin ● 居住地 ○ 大阪 ● 趣味 ○ サッカー観戦 自己紹介

3 Mission

4 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。

5

● SREチームの変化と課題 ● プラットフォームチームとしての取り組み ● 現状と新たな課題 ● まとめ

● SREチームの変化と課題 ● プラットフォームチームとしての取り組み ● 現状と新たな課題 ● まとめ

8 コドモン プロダクト開発チーム ○○ チーム 保護者系 機能チーム メモリー チーム … 請求系機能 チーム ○○ チーム UI/UXデザイナー CRE エンジニア・EM・QA プロダクトマネージャー ○○ チーム 1チームは関連する複数の機能を担当 技術戦略 SRE

9 ● 開発とインフラ(運用)の時代 ● 社内インフラとか情シス的なものも兼ねている ● チーム間の役割は割と明確 インフラチーム時代 インフラチーム 開発チーム コーポレート系

10 ● インフラチームがなんとなくSREチームへ・・ ● プロダクトの対応もコーポレート的な対応も・・・ ● チーム間の役割はあいまい SREチームになった(2021年くらい) SREチーム 開発チーム コーポレート系 開発チーム

11 ● 開発チーム数の増加にSREの人数が対応できていない プロダクトも拡大、組織も拡大 SREチーム 開発チーム 開発チーム コーポレート系 開発チーム 開発チーム

12 ● 各開発チームの依頼に都度対応する 課題

13 ● 各開発チームの依頼に都度対応する ● 全体最適を考慮する余裕がなく、個別最適なものが増えていく 課題

14 ● 各開発チームの依頼に都度対応する ● 全体最適を考慮する余裕がなく、個別最適なものが増えていく ● プロダクト全般の一貫性がなくなる 課題

15 ● 各開発チームの依頼に都度対応する ● 全体最適を考慮する余裕がなく、個別最適なものが増えていく ● プロダクト全般の一貫性がなくなる ● 認知負荷が上がる ○ 開発者だけでなくSREも 課題

16 ● 各開発チームの依頼に都度対応する ● 全体最適を考慮する余裕がなく、個別最適なものが増えていく ● プロダクト全般の一貫性がなくなる ● 認知負荷が上がる ○ 開発者だけでなくSREも 課題 プラットフォームチームとして取り組む

● SREチームの変化と課題 ● プラットフォームチームとしての取り組み ● 現状と新たな課題 ● まとめ

18 ● ストリームアラインドチームとの接点はX as a Service ● 開発チームの変動に対応しやすい形にする プラットフォームチーム Stream-aligned team Platform team XaaS Stream-aligned team Stream-aligned team Stream-aligned team XaaS XaaS XaaS

19 1. SREチームでやることを明確にする 2. 自分たちのプラットフォームを定義する 3. プロダクト全般で一貫したシステムを構築する 4. 計測し、改善する プラットフォームチームとしてやっていくために

20 ● ミッションを作成 ○ 最重要課題は開発者の認知負荷を減らし つつ、運用まで自己完結できる環境を提 供する ● やらないことを明確にする ○ プロダクトに特化する ■ それ以外は他チームへ ■ 振れない場合は、本来のべき論を認識 した上で対応する 1. SREチームでやることを明確にする

21 ● 新しいプラットフォームをつくることより、 自分たちのプラットフォームを定義 ○ これやるときはこれっていうのがはっきりして るだけでも認知負荷は減るはず ○ 強制はしない、開発者自身でメンテしていくな ら別のものでもOK ● なるべく聞かなくても、依頼しないでもでき る環境を目指す ○ チームトポロジーのX-as-a-Service 2. 自分たちのプラットフォームを定義する

22 ● アプリケーション実行基盤を統一 ○ メインアプリケーションをEC2 → ECS に移行し、全アプリケーションをECSに 3. プロダクト全般で一貫したシステムを構築する マイクロサービス ECS メインアプリケーション EC2 Ansible Github Actions + CodeDeploy Github Actions + ecspresso + Dockerfile 開発チーム 開発チーム SRE マイクロサービス ECS メインアプリケーション ECS 開発チーム Github Actions + ecspresso + Dockerfile https://speakerdeck.com/codmoninc/from-ec2-to-ecs-migrating-to-containers-and-rebuilding-a-massive-legacy-php-application

23 ● CI/CDフローの整備 ○ Amazon Inspectorの脆弱性スキャンをCI/CDで実施、通知する 3. プロダクト全般で一貫したシステムを構築する https://speakerdeck.com/codmoninc/building-and-managing-a-container-image-workflow-for-multiple-teams

24 ● セキュリティ通知 ○ Security Hubの通知、対応フローの整備 3. プロダクト全般で一貫したシステムを構築する https://speakerdeck.com/codmoninc/improving-the-untouched-security-hub-operation

25 ● パイプラインの実行時間の計測 ● SREに対する依頼、問い合わせのカウント ● アンケートの深堀り 4. 計測し、改善する https://speakerdeck.com/taishin/platform-engineering-meetup-number-8

● SREチームの変化と課題 ● プラットフォームチームとしての取り組み ● 現状と新たな課題 ● まとめ

27 ● 完全なXaaS化は難しい ● 各チームでの対応の差が出てくる ● SREでつくったものをどう広めるか 新たな課題

28 ● 開発チームにどう関わるかの検討 ● フィードバックをもらいやすい環境をつくって、さらに開発者の認知 負荷を減らせるプラットフォームに イネイブリングの検討 Stream-aligned team Platform team XaaS Stream-aligned team Stream-aligned team Stream-aligned team XaaS XaaS XaaS SRE SRE SRE SRE

● SREチームの変化と課題 ● プラットフォームチームとしての取り組み ● 現状と新たな課題 ● まとめ

30 ● 組織の変化/拡大に対応するため、SREチームではプラット フォームチームの考え方を取り入れた ● プラットーフォームチームやっていくために考えたこと ○ 1. SREチームでやることを明確にする ○ 2. 自分たちのプラットフォームを定義する ○ 3. プロダクト全般で一貫したシステムを構築する ○ 4. 計測し、改善する ● イネイブリング等で開発チームと連携することも重要 まとめ

31 コドモン採用ページ 開発ブログ コドモンでは一緒に働きたい仲間を募集しています！

No content