Platformに“ちょうどいい”責務ってどこ？関心の熱さにあわせて考える、責務分担のプラクティス

by estie | エスティ

Slide 1

Slide 1 text

Platformに“ちょうどいい”責務ってどこ？関心の熱さにあわせて考える、責務分担のプラクティス Platform Engineering Kaigi 2025

Slide 2

Slide 2 text

株式会社estie 徳原晋一 github: stkhr, x: @wh_choco estieではSRE, Platform Engineer 領域を担当自己紹介

Slide 3

Slide 3 text

社内IaaS / PaaS / SaaS プロダクトから利用される共通機能 (認証 etc) CI/CDパイプライン / Deploy Flow 開発ドキュメント管理それらのイネーブルメント Platform Engineeringって何をすれば良いのだろう?

Slide 4

Slide 4 text

社内IaaS / PaaS / SaaS プロダクトから利用される共通機能 (認証 etc) CI/CDパイプライン / Deploy Flow 開発ドキュメント管理それらのイネーブルメント Platform Engineeringって何をすれば良いんだろう? どんなレベルで？？？？？？

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Confidential estieのPlatformチーム 6

Slide 8

Slide 8 text

© 2025 estie, inc. estieのPlatformチーム estieはコンパウンドスタートアップ • コンパウンドスタートアップ => 複数プロダクトを同時展開し、それらが相互に連携することで市場での競争優位性を高める戦略を取っているスタートアップ Platformチームは、その実現に向けて - 組織横断で必要な機能を提供 - 組織全体の開発フローを整備開発がプロダクトの価値に直結する状態を作り出すことをミッションとしている 7 開発者の開発がプロダクトの価値になる

Slide 9

Slide 9 text

© 2025 estie, inc. estieのPlatformチームどの組織・チームにも属さず、組織間で発生する対応した方が良さそうな問題を対処するボランティア的な集まりが起源認証基盤の構築や、「プロダクト立ち上げ」におけるフットワークの軽さを作り出すため、プロトタイピングアプリを爆速に立ち上げるツールを作ることから始めたプロダクト数が増えていき、また認証認可をはじめとする基盤機能の提供が増えてきたことで、同じく横断的に組織課題を対応していたSREチームと合流し、Platformチームとして正式に動き出した 8 Platformチームの沿革

Slide 10

Slide 10 text

© 2025 estie, inc. estieのPlatformチーム 9 Platformチームが提供しているもの X as a Service ファシリテーションコラボレーションプロトタイピング爆速立上げツール CI/CDテンプレートデプロイフロー Preview環境 Feature Toggle 認証認可基盤 Observability インフラ基盤 Terraform Workflow データアクセス基盤

Slide 11

Slide 11 text

Confidential プロダクトチームと Platformチームの関わり 10

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2025 estie, inc. プロダクトチームとPlatformチームの関わりプロダクトチームはインフラ含めて、担当プロダクトに関わるコードに責務を持っているプロダクトごとにモノレポで管理 12 ソフトウェア開発 Platformチームのツールからリポジトリを作成したらこの状態・.github => CI/CD フロー・backend => Rustで必要最低限実装・frontend => Next.jsで認証含めた必要最低限実装・infra => アプリケーションが起動する必要最低限の実装(ECS) ・sql => DB Migrationの必要最低限実装 => すでに必要な機能一式が導入済みですぐにコードを書き始められる

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2025 estie, inc. プロダクトチームとPlatformチームの関わりデータアクセス基盤背景 • estieではData as a Service(DaaS) に分類されるプロダクトが多い • 大元のデータはデータ基盤にあり、各チームがバッチ処理的にRDBにLoadしていた • 他プロダクトでも同様のデータを使いたい場合、新しく移送する処理を作る、プロダクト連携用のAPIを作るといったことが頻発していた課題 • このままプロダクトが増えてくると、データ取り回しの問題が発生する (開発効率、処理の複雑化) • データガバナンスが各チームに依存し、そのレベルがまばらになる 14 これまでの機能提供の事例データアクセス基盤を作ろう!

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2025 estie, inc. プロダクトチームとPlatformチームの関わりデータアクセス基盤の事例データ提供範囲の取り決め全部提供した方が責務が明確 <------> 開発効率への懸念で柔軟性が欲しい => 条件付きで、データアクセス基盤に集約していく方針へ条件 • 新規プロダクトはデータアクセス基盤を使う • 既存処理の置換によりロジックが複雑化したり開発へのデメリットが大きい場合は例外としてデータアクセス基盤を使わない • Platformチームがすべての開発を行うわけではなく、必要に応じてプロダクトチームから Pull Requestを受け、それをPlatformチームは支援する(Platformチームが整合性担保) 16 これまでの機能提供を振り返ってみる

Slide 18

Slide 18 text

© 2025 estie, inc. プロダクトチームとPlatformチームの関わりインフラ基盤の例背景 • プロダクトごとにVPCレベルで環境が分離されている。それぞれのVPCがTGWで接続されNWレイヤーの疎通を実現している • インフラコード、そのデプロイフローが各プロダクトのリポジトリに紐付いている課題 • 専用線や、VPNがあるわけではないのに、プロダクトが増えるごとにTGWの課金が増えてきて、全体におけるTGWの占めるコスト割合が結構高い • プロダクト数がこんなに増えるとは思っておらず、基盤機能の更新をする際など、 Pull Requestをプロダクト数分作る必要があり、運用コストが辛い 17 これまでの機能提供を振り返ってみる VPC統合 & インフラモノレポ作ろう

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Confidential Platformに “ちょうどいい”責務って？ 19

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2025 estie, inc. Platformに“ちょうどいい”責務って？実際 22 責務の線引きは固定ではなく、柔軟に変えていくこの責務の線引きが対面するチームごとに存在するプロダクト状況・関心による差分・ビジネスロジックに集中できる状態・ガンガン使いたい。欲しい機能/データは自分で実装してPRを出すから整合性は任せた! ・単純に手が足りないので実装も含めやってほしい基盤(infra) API 基盤(app) ビジネスロジックデータアクセス基盤の例データアクセス制御 Platform チーム責務プロダクトA チーム Platform チーム責務プロダクトB チーム Platform チーム責務プロダクトC チーム

Slide 24

Slide 24 text

© 2025 estie, inc. Platformに“ちょうどいい”責務って？実際 23 責務の線引きは固定ではなく、柔軟に変えていく Feature Toggleの例基盤(infra) API 基盤(app) ビジネスロジックアクセス制御 Platform チーム責務 Platform チーム責務 Platform チーム責務プロダクトA チームプロダクトB チームプロダクトC チームシンプルな機能なものは一律で線引きができる

Slide 25

Slide 25 text

© 2025 estie, inc. Platformに“ちょうどいい”責務って？機能ごとに責務は一律ではないことの方が多い Platformチームとしてはそのプロダクトの事業状況・開発チーム状況両方を見つつ、関わり方 (X as a Service, ファシリテーション, コラボレーション) を柔軟に見定めていく必要がある Platformはみんなで育てていく適切に他チームを巻き込みながら利用者 / Platform 視点でちょうど良い関わりを作っていくことが大事 24 責務の線引きは固定ではなく、柔軟に変えていく

Slide 26

Slide 26 text

© 2025 estie, inc. Platformに“ちょうどいい”責務って？ 25 Platform Teamが責務を握るべきものアクセス権限等守るべき要件があり、それを継続して運用していく必要性があるもの • 例認証認可基盤インフラの監査関連の設定組織で共通化しておくことで、プロダクト価値、開発効率に直結するもの • 例アプリケーションエコシステム開発フロー(ブランチ戦略・デプロイフロー) => 逆にそれ以外は、状況を見つつ柔軟に変えていってよさそう