株式会社コドモンでSREチームのマネージャーをしています、佐々木です。 今回は 「スケールするプロダクトと膨らむ組織SREの挑戦と解決策」というテーマでブログを書かせていただければと思います。
最初に、コドモンは「子どもを取り巻く環境をテクノロジーの力でよりよいものに」というミッションのもと、保育・教育施設向け業務支援システム「CoDMON（コドモン）」を開発、提供しています。
導入施設数は2025年1月には21,000施設を突破しました。今後ますますプロダクトがスケールしていく中で、SREチームがどのように変化し、どんな挑戦や解決策が見えてくるのか—その取り組みについてこれからお伝えします。
SREチームの変遷と直面する課題
SREチームの概要とプロダクト開発体制
コドモンの開発組織は現在全体で70〜80名規模となっており、機能ごとに編成された複数のチームから構成されています。請求系機能チーム、保護者系機能チームなどがあり、各チームにはエンジニア、デザイナー、プロダクトマネージャーが配置されています。これらは「ストリームアラインドチーム」として機能しています。 また、技術戦略やCREといった組織横断的な役割を持つチームも存在しており、SREチームもその1つとして横断的な視点で開発をサポートしています。
現在はこのような体制になっていますが、ここに至るまでには様々な変遷がありました。
2021年以前：インフラチームからSREチームへの変遷
組織が小規模だった頃、現在のSREチームは「インフラチーム」という名称で活動していました。当時は開発とインフラが明確に分離されており、インフラチームは社内インフラや情報システム関連の業務も兼任していました。
チーム間の役割分担も明確で、開発チームがアプリケーションを開発し、その運用やデプロイはインフラチームが担当するという構図でした。2021年頃に「SREチーム」へと名称変更しましたが、これは業界トレンドに合わせた変更であり、実質的な業務内容に大きな変化はありませんでした。
2021年〜2023年：組織拡大に伴う役割の曖昧化と課題
SREチームは引き続きプロダクト対応とコーポレート対応の両方を担当していましたが、開発チームの数が増加するにつれて、チーム間の役割が徐々に曖昧になっていきました。プロダクトと組織の拡大に伴い、開発チームが複数に分かれる一方で、SREチームの人員はそれに比例して増加していなかったため、様々な対応が難しくなっていきました。
結果として、SREチームは開発チームからの依頼に対して都度対応する形になり、戦略的な取り組みよりも日々の対応に追われる状況が生まれました。
2023年5月以降：プラットフォームチームとしての新たな取り組み
本来であれば全体最適を考慮したいところでしたが、その余裕がなく個別最適なソリューションが増えていきました。これにより、プロダクト全体の一貫性が失われ、開発者とSREチームメンバー双方の認知負荷が増大する結果となりました。「このチームはここまで対応している」「このチームはこのツールを使用している」といった違いがチームごとに生まれ、特に新しく加入したSREメンバーにとっては対応が難しくなるという問題が顕在化しました。
これらの課題に対応するため、2023年5月頃から「プラットフォームチーム」としての取り組みを開始しました。この新しいアプローチにより、個別最適から全体最適へと舵を切り、より体系的なサポート体制の構築を目指しています。
プラットフォームチームとしての取り組み
プラットフォームチームを取り巻く背景
ここから、私たちプラットフォームチームが、具体的にどのような取り組みを行ってきたかをお伝えします。 「プラットフォームチーム」という概念は、チームトポロジーの考え方に基づいています。これは、複数のストリームアラインドチーム（機能別に編成されたチーム）が存在する環境において、それらを横断的にサポートするためのチームを配置し、プラットフォームをサービスとして提供するモデルです。
この体制を採用することで、一貫性を保ちつつ、開発チームの増減にも柔軟に対応できる構造を目指しました。またプラットフォームチームとしての活動を進めるにあたり、以下の4つの重点施策を設定しました。
- SREチームの役割の明確化：責任範囲と提供価値を明確にする
- プラットフォームを定義：開発チームが活用できる共通基盤を整備する
- 一貫したシステム構築：プロダクト全体で統一された設計と実装を促進する
- 計測と改善：データに基づく継続的な改善サイクルを確立する
これらの施策を念頭に置き、段階的に取り組みを進めていきました。プラットフォームチームへの移行は、単なる組織変更ではなく、開発効率の向上とシステムの安定性を両立させるための戦略的な取り組みです。
プラットフォームチームとしての取り組み
1. SREチームのミッション確立と「やらないこと」の明確化
もともと会社のミッションは存在していますが、チーム単位のミッションは明確ではありませんでした。そこでまず、SREチームで何を行うのかを明確にするため、チームミッションを策定しました。そこで定義したのが「開発者の認知負荷を減らして開発・運用が自己完結できる環境を提供する」というミッション です。
このミッションが決まったことで「やらないこと」も明確になりました。画像に示しているようにやらないことや対象外となる領域を整理し、プロダクトに特化するという方針のもと、それ以外の領域は他のチームに依頼するという形で進めていきました。
もちろん、すべてが明確に区分できるわけではなく、グレーゾーンも存在します。そのような場合は「本来どのチームが担当すべきか」という点を意識しながら、状況に応じて自分たちで対応するという柔軟な姿勢で取り組みました。
2. 自分たちのプラットフォームを定義する
次のステップとして、「プラットフォームの範囲」を具体的に定義しました。一般的に「プラットフォームを新規構築する」という発想がありますが、私たちが重視したのは「プラットフォームの境界線を引く」ことでした。つまり、何がサポート対象で何が対象外かを明確にすることです。
このように境界を設定することで、SREチームへの依頼が整理され、不必要なコミュニケーションコストを削減できました。ただし、「サポート範囲外は一切対応しない」という硬直的なアプローチではなく、「チームとして公式にサポートするかどうか」という観点から線引きしています。サポート範囲外の技術やサービスであっても、開発チーム自身がメンテナンスできるのであれば、その利用を禁止するわけではありません。
このアプローチにより、SREチームへの過度な依存を避け、開発チームが自律的に開発を進められる「プラットフォーム as a Service」の実現を目指しています。明確な境界設定は、サポートの拒否を意味するのではなく、むしろ開発者のエンパワーメントと自律性を促進するための重要な施策なのです。
3. プロダクト全般で一貫したシステムを構築する
3つ目の取り組みとして、プロダクト全体における技術スタックとインフラ構成の標準化を推進しました。当初の状況では、メインアプリケーションがEC2で運用される一方、新たに開発したマイクロサービスはECSで稼働させるなど、サービスごとに異なる環境が混在している状況でした。このような分散状態を解消するため、すべてのサービスをECS（Fargate）へ統合し、デプロイメカニズムとインフラ構成の一元化を実現しました。[1]
標準化の取り組みはインフラだけでなく、継続的デリバリー（CD）パイプラインも統一しました。[2] 具体的には、AWS Inspectorを活用して脆弱性スキャンを自動化し、Security Hubからの通知をSlackやGithubへシームレスに連携させる一貫したワークフローを構築しました。[3] このような基盤レベルでの統一により、以前はサービスごとに異なっていた運用プロセスを体系的に整備することができました。
4. 計測し、継続的に改善する
4つ目の取り組みとして、構築した仕組みの有効性を継続的に評価・改善するサイクルを確立しました。デプロイパイプラインの実行時間を常時モニタリングし、異常値を即座に検出できる体制を整えています。[4]また、SREチームへの依頼数や問い合わせ頻度を定量的に追跡し、開発者向けのアンケートやヒアリングも定期的に実施しています。
これらの指標を通じて「開発者の認知負荷が実際に軽減されたか」という、私たちのミッションの達成度を客観的に評価しながら、必要な改善を継続的に行っています。
このようにして、SREチームがミッションを明確化し、プラットフォームの範囲を定義することで、開発チームにとって使いやすい「サービスとしてのプラットフォーム」を提供する体制を構築してきました。 この取り組みの成果として、従来の依頼ベースのコミュニケーションが大幅に減少し、開発スピードの向上や運用効率の改善に貢献できたと実感しています。標準化されたプラットフォームの提供により、各開発チームがインフラや運用の詳細に悩まされることなく、本来のプロダクト開発に集中できる環境が整いつつあります。
今後の課題とEnablingの検討
これまでの取り組みを通じて成果を上げる一方で、いくつかの現実的な課題も明らかになりました。
特に「完全なPlatform as a Service化の難しさ」があります。開発チームごとに開発スタイルや依存関係が異なるため、均一なサポートの提供が難しいという課題が出てきました。また「構築したプラットフォームや機能の効果的な周知方法」などといった課題も出てきました。
これらに対応するため、「Enabling」の考え方を取り入れ、プラットフォームの提供だけに留まらず、開発チームとより緊密に連携し、フィードバックを取り入れやすい環境を構築することで、開発者の認知負荷をさらに軽減し、より効率的な開発環境を目指しています。
まとめ
コドモンのSREチームでは、組織やプロダクトの拡大に合わせて“プラットフォームチーム”の考え方を取り入れてきました。その中で意識したのが以下の4点です。
- SREチームでやることを明確にする
- 自分たちのプラットフォームを定義する
- プロダクト全般で一貫したシステムを構築する
- 計測して改善する
今後は、これらの取り組みを加速させるため、SREメンバーをまだまだ募集しています。もしご興味をお持ちいただけたなら、ぜひお気軽にご連絡ください。[5]
-
この記事は2025/02に開催されたイベントの内容を編集した記事です ↩
