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

Platform Engineering Kaigi 2025の登壇資料です。
https://www.cnia.io/pek2025/

Transcript

1. Platformに“ちょうどいい”責務ってどこ？ 関心の熱さにあわせて考える、責務分担のプラクティス Platform Engineering Kaigi 2025
2. 株式会社estie 徳原 晋一 github: stkhr, x: @wh_choco estieではSRE, Platform Engineer 領 域を担当 自己紹介
3. 社内IaaS / PaaS / SaaS プロダクトから利用される共通機能 (認証 etc) CI/CDパイプライン / Deploy Flow 開発ドキュメント管理 それらのイネーブルメント Platform Engineeringって何をすれば良いのだろう?
4. 社内IaaS / PaaS / SaaS プロダクトから利用される共通機能 (認証 etc) CI/CDパイプライン / Deploy Flow 開発ドキュメント管理 それらのイネーブルメント Platform Engineeringって何をすれば良いんだろう? どんなレベルで？？？？？？
5. © 2025 estie Inc. 今日話すこと 4
6. © 2025 estie, inc. アジェンダ • estieのPlatformチーム • プロダクトチームとPlatformチームの関わり • Platformに“ちょうどいい”責務って？ • まとめ 5
7. Confidential estieのPlatformチーム 6
8. © 2025 estie, inc. estieのPlatformチーム estieはコンパウンドスタートアップ • コンパウンドスタートアップ => 複数プロダクトを同時展開し、それらが相互に連携することで 市場での競争優位性を高める戦略を取っているスタートアップ Platformチームは、その実現に向けて - 組織横断で必要な機能を提供 - 組織全体の開発フローを整備 開発がプロダクトの価値に直結する状態を作り出すことを ミッションとしている 7 開発者の開発がプロダクトの価値になる
9. © 2025 estie, inc. estieのPlatformチーム どの組織・チームにも属さず、組織間で発生する対応した方が良さそうな 問題を対処するボランティア的な集まりが起源 認証基盤の構築や、「プロダクト立ち上げ」におけるフットワークの軽さ を作り出すため、プロトタイピングアプリを爆速に立ち上げるツールを作 ることから始めた プロダクト数が増えていき、また認証認可をはじめとする基盤機能の提供 が増えてきたことで、同じく横断的に組織課題を対応していたSREチーム と合流し、Platformチームとして正式に動き出した 8 Platformチームの沿革
10. © 2025 estie, inc. estieのPlatformチーム 9 Platformチームが提供しているもの X as a Service ファシリテーション コラボレーション プロトタイピング 爆速立上げツール CI/CDテンプレート デプロイフロー Preview環境 Feature Toggle 認証認可基盤 Observability インフラ基盤 Terraform Workflow データアクセス基盤
11. Confidential プロダクトチームと Platformチームの関わり 10
12. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり 対外的に発表しているプロダクト数は10(未公表含む) • その裏にプロダクトを支えるためのプロダクトがいくつもある 各事業部にいくつかのチームがあり、1チームが1プロダクトもしくは複数 プロダクトを見ている 上記以外に、組織横断で動くチームがいる 11 チーム体制とプロダクト
13. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり プロダクトチームはインフラ含めて、担当プロダクトに関わるコードに責 務を持っている プロダクトごとにモノレポで管理 12 ソフトウェア開発 Platformチームのツールからリポジトリを作成したらこの状態 ・.github => CI/CD フロー ・backend => Rustで必要最低限実装 ・frontend => Next.jsで認証含めた必要最低限実装 ・infra => アプリケーションが起動する必要最低限の実装(ECS) ・sql => DB Migrationの必要最低限実装 => すでに必要な機能一式が導入済みですぐにコードを書き始められ る
14. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり 将来にむけてやっておくべきこと 日常の会話や、チャットから潜在的なニーズがありそう 負債になりかけているもの、会社として課題になっているもの 共通化することに明確なニーズ・メリットがあると誰もが思う 13 どういった観点でPlatformを生み出すか? 明確さ 会社の戦略、開発状況を見つつ重要度を決め実装していく
15. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり データアクセス基盤 背景 • estieではData as a Service(DaaS) に分類されるプロダクトが多い • 大元のデータはデータ基盤にあり、各チームがバッチ処理的にRDBにLoadしていた • 他プロダクトでも同様のデータを使いたい場合、新しく移送する処理を作る、プロ ダクト連携用のAPIを作るといったことが頻発していた 課題 • このままプロダクトが増えてくると、データ取り回しの問題が発生する (開発効率、処理の複雑化) • データガバナンスが各チームに依存し、そのレベルがまばらになる 14 これまでの機能提供の事例 データアクセス基盤を作ろう!
16. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり データアクセス基盤の事例 Design Docs展開時の反応 • ほぼ全てのプロダクトに関わってくるコア機能になるので関心はすごく高い 言及された問題 • 共通化に伴う影響 • SPOF • データ整合性 • データ提供範囲 15 これまでの機能提供からの学び
17. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり データアクセス基盤の事例 データ提供範囲の取り決め 全部提供した方が責務が明確 <------> 開発効率への懸念で柔軟性が欲しい => 条件付きで、データアクセス基盤に集約していく方針へ 条件 • 新規プロダクトはデータアクセス基盤を使う • 既存処理の置換によりロジックが複雑化したり開発へのデメリットが大きい場合は例外とし てデータアクセス基盤を使わない • Platformチームがすべての開発を行うわけではなく、必要に応じてプロダクトチームから Pull Requestを受け、それをPlatformチームは支援する(Platformチームが整合性担保) 16 これまでの機能提供を振り返ってみる
18. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり インフラ基盤の例 背景 • プロダクトごとにVPCレベルで環境が分離されている。それぞれのVPCがTGWで接 続されNWレイヤーの疎通を実現している • インフラコード、そのデプロイフローが各プロダクトのリポジトリに紐付いている 課題 • 専用線や、VPNがあるわけではないのに、プロダクトが増えるごとにTGWの課金が 増えてきて、全体におけるTGWの占めるコスト割合が結構高い • プロダクト数がこんなに増えるとは思っておらず、基盤機能の更新をする際など、 Pull Requestをプロダクト数分作る必要があり、運用コストが辛い 17 これまでの機能提供を振り返ってみる VPC統合 & インフラモノレポ作ろう
19. © 2025 estie, inc. プロダクトチームとPlatformチームの関わり インフラ基盤の例 Design Docs展開時の反応 • よしなに • よしなに • よしなに 元々インフラ側作業に関してはSREが支援しているケースが大半 なのでどのプロダクトもSREが設計したテンプレートを踏襲した設計になっており、問題 になるようなケースが存在しなかった 18 これまでの機能提供を振り返ってみる
20. Confidential Platformに “ちょうどいい”責務って？ 19
21. © 2025 estie, inc. Platformに“ちょうどいい”責務って？ 提供する機能によってチームごとに温度差がある • 提供する機能がどのレイヤーのものか? • プロダクト状況(PMF前なのか、後か) • チーム開発状況 その温度差に対してPlatformチームは、どこで責務を線引きをして いくと良い感じにビジネスを前に進めることができるか? 20 基盤・機能に対する関心の差
22. © 2025 estie, inc. Platformに“ちょうどいい”責務って？ 当初想定していたこと 21 機能・基盤単位で責務の線引きが一律になるとおもっていた 基盤(infra) データ 基盤(app) ビジネスロジック 例: Platform機能A プロダクトチーム 責務 API Platformチーム 責務
23. © 2025 estie, inc. Platformに“ちょうどいい”責務って？ 実際 22 責務の線引きは固定ではなく、柔軟に変えていく この責務の線引きが対面するチームごとに存在する プロダクト状況・関心による差分 ・ビジネスロジックに集中できる 状態 ・ガンガン使いたい。 欲しい機能/データは自分で実装 してPRを出すから整合性は任せ た! ・単純に手が足りないので実装も 含めやってほしい 基盤(infra) API 基盤(app) ビジネスロジック データアクセス基盤の例 データアクセス制御 Platform チーム責務 プロダクトA チーム Platform チーム責務 プロダクトB チーム Platform チーム責務 プロダクトC チーム
24. © 2025 estie, inc. Platformに“ちょうどいい”責務って？ 実際 23 責務の線引きは固定ではなく、柔軟に変えていく Feature Toggleの例 基盤(infra) API 基盤(app) ビジネスロジック アクセス制御 Platform チーム責務 Platform チーム責務 Platform チーム責務 プロダクトA チーム プロダクトB チーム プロダクトC チーム シンプルな機能なものは一律で線引きができる
25. © 2025 estie, inc. Platformに“ちょうどいい”責務って？ 機能ごとに責務は一律ではないことの方が多い Platformチームとしてはそのプロダクトの事業状況・開発チーム状況両方 を見つつ、関わり方 (X as a Service, ファシリテーション, コラボレーション) を柔軟に見定めていく必要がある Platformはみんなで育てていく 適切に他チームを巻き込みながら利用者 / Platform 視点でちょうど良い関 わりを作っていくことが大事 24 責務の線引きは固定ではなく、柔軟に変えていく
26. © 2025 estie, inc. Platformに“ちょうどいい”責務って？ 25 Platform Teamが責務を握るべきもの アクセス権限等守るべき要件があり、それを継続して運用していく必要性があ るもの • 例 認証認可基盤 インフラの監査関連の設定 組織で共通化しておくことで、プロダクト価値、開発効率に直結するもの • 例 アプリケーションエコシステム 開発フロー(ブランチ戦略・デプロイフロー) => 逆にそれ以外は、状況を見つつ柔軟に変えていってよさそう
27. Confidential まとめ 26
28. © 2025 estie, inc. まとめ 責務の線引きは固定ではなく、プロダクトを取り巻く状況で変わ るので、それに合わせて柔軟に変えていくと上手くいく 守るべきところはPlatformチームが責務を握る それ以外はチームの状況に応じて委ねる／協働する 27
29. © 2025 estie, inc. まとめ estieでも今はこれで上手くいっているが、今後プロダクト数や 組織規模が拡大していった場合には、この通りにはいかないはず 現状に満足せず、今後も常に良い関わり方は模索していくことが 大事 28