X-as-a-Serviceを目指して Team Topologiesの実践で見えた現実

enechainは国内最大のエネルギーマーケットプレイスを運営するスタートアップで、今年で創業6年目になります。組織のスケールに伴い、インフラ周りを一手に担っていたSREチームから分離する形で、より開発者体験(DX)の向上にフォーカスするPlatform Engineeringチームが昨年発足されました。

しかし、『Team Topologies』におけるプラットフォームチームをいきなり実践できるわけではありません。SREチームとの責任分解やプロダクト開発チームとの関わり方など、チームの体制を整える準備フェーズが必要でした。発足から1年で、ようやくフィードバックを受け入れながらX-as-a-Serivceとして振る舞える場面が増えています。今回はその過程を共有し、スタートアップにおけるPlatform Engineering実践のリアルをお伝えします。

DX向上に投資したい小規模の開発組織の方々はもちろん、Platform Engineeringにおけるプロダクト開発チームとの関わり方や、スムーズにガバナンスを効かせる方法を模索している方々の参考になれば幸いです。

CloudNative Days Winter 2025 プレイベントで登壇。
https://cloudnativedays.connpass.com/event/370227/

Transcript

1. X-as-a-Serviceを目指して Team Topologiesの実践で見えた現実 ＠kumashun88 2025/10/14 CloudNative Days Winter 2025 プレイベント
2. 2 自己紹介 大隈 隼 @kumashun88 2020-2024 freee(現地!) SRE, サービス基盤 (Engineer) 2025- enechain Platform Engineering Desk (Engineer) 技術: k8s, AWS, Google Cloud, GitHub Actions, Terraform, Golang 趣味: 映画🍿、ランニング󰝊、ビール🍺 (Far East Tokyoおすすめ!!)
3. 3 会社紹介 - 株式会社enechain さらっと紹介する感じ。 hiyosiさんの時のやつを使えばよさそう。そもそも会社のこと話ししてok?
4. 4 メインターゲット/得られる学び より学びが得られる視聴者層 - Platform Engineeringをやり始めた or これからやろうとしている方 得られる学び - どうPlatform Engineeringを始めるといいか、その一例 - Team Topologiesのプラットフォームチームを構築する過程
5. 5 アジェンダ - 導入 ←ｲﾏｺｺ - Platform Engineeringチーム発足の経緯 - チームの課題 - 課題に対するアプローチ - 結果 - (時間があれば) X-as-a-Serviceの取り組み - まとめ
6. 6 前提の補完(1) Platform Engineering - Platform : プロダクトの開発、デプロイ、運用を支援するもの - Platform Engineering : Platformを設計、開発および運用する取り組み https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/
7. 7 前提の補完(1) Platformがもたらすもの CNCFプラットフォームホワイトペーパー 認知負荷の 軽減 プロダクトチームの 認知負荷を 軽減し、 プロダクト開発と デリバ リーを 加速 責任の 明確化 プラットフォーム能力を 構成・管理する 専門家を 配置する こと で、 彼らに 依存する 製品の 信頼性と 回復力を 向上 スケーラビリティの担保 企業内の 多くの チームで プラットフォームツールや ナレッジを 再利 用・共有する ことで、 プロダクト開発と デリバリーを 加速 ガバナンスの 強化 プラットフォーム能力、 ユーザー、 ツール、 プロセスを 統制する こ とで、 製品と サービスに おける セキュリティ、 規制、 機能面の リス クを 軽減する
8. 8 前提の補完(2) Team Topologies ソフトウェア開発における組織構造とチーム設計のベストプラクティス - 4つのチーム - ストリームアラインドチーム（ドメイン開発） - コンプリケイテッド・サブシステムチーム（専門領域） - イネイブリングチーム（スト...の自律をサポート） - プラットフォームチーム（内部サービスの提供） - 3つのインタラクションモード - コラボレーション（協業） - ファシリテーション（サポート的関与） - X-as-a-Service（サービスとしての提供） JMAMeショップから引用
9. 9 前提の補完(2) Team Topologies プラットフォームチーム ストリームアラインドチーム イネイブリング チーム コンプリケイテッド・ サブシステムチーム ファシリテーション X-as-a-Service X-as-a-Service
10. 1 0 Platform Engineering チーム発足の経緯
11. 11 当時の開発組織体制 (2024/06) チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog 複数のプロダクトチームに対して、SREチームがインフラの何でも屋さん状態に。それぞれの 立場で問題が生じていた。 - 開発者目線: 意思決定が中央集権的になっており、新技術の導入がスムーズにできない - SRE目線: 問い合わせが多すぎて、中長期課題に取り組めない 今から投資しないと、SREチームがボトルネックになる。 - プロダクト増加に伴う、標準策定やガバナンス強化が必要になるのは明白
12. 12 組織体制の見直し (2024/06) チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog チームトポロジーを参考にSREチームからPlatform Engineering、Security専門チームを 分割。 チーム ミッション チームタイプ インタラクションモード SRE Desk 全プロダクトの Reliability向上に責任を 持つ イネイブリング チーム ファシリテーション（定常時）, コ ラボレーション（プロダクト開始 時や重要機能実装時） Platform Engineering Desk プラットフォーム領域に おいて、各開発チームの デベロッパー体験の最大 化に責任を持つ プラットフォー ムチーム X-as-a-Service
13. 13 Platform Engineeringチーム発足後の変化 Platform Engineeringの思想を取り入れることができた。 (2024/06) Before After 開発者目線: 意思決定が中央集権的に なっており、新技術の導入がスムーズ にできない チームごとに明確なミッションを持つ状態になったこと で、将来像を描いた上で適切に判断できるようになった！ SRE目線: 問い合わせが多すぎて、中 長期課題に取り組めない SRE/PEで責務が分かれたことで問い合わせが分散し、並 行して中長期課題に取り組めるようになった！
14. 14 Platform Engineeringチーム発足後の変化 自分の入社時点 (2025/01) - 前述の効果が継続しており、Platfoform Engineeringのカルチャーは醸成されてきてい た - しかし、運用面や体制面において課題がいくつか残っていた
15. 1 5 チームの課題
16. 16 現状の課題を調査 自分の入社に合わせてチームをより良くするために、 現状の課題点を洗い出した。 - チームの状態 - 入社直後のフラットな目線で、定例の様子やメ ンバーの仕事の進め方を分析 - 開発者全体へアンケートの実施 - インフラやプラットフォームに対する課題感の ヒアリングを実施
17. 17 現状の課題を調査 自分の入社に合わせてチームをより良くするために、 現状の課題点を洗い出した。 - チームの状態 - 入社直後のフラットな目線で、定例の様子やメ ンバーの仕事の進め方を分析 - 開発者全体へアンケートの実施 - インフラやプラットフォームに対する課題感の ヒアリングを実施 → 大きく2つの課題が見えてきた
18. 18 課題(1) ユーザー目線の欠如 - 課題解決は実践できているが、プロダクトチームに その 背景や目的が 伝わっておらず、 実 践後の影響が分かっていなかった - プロダクトチーム向けのガイドラインが少ない - 過去の 意思決定の 経緯が チーム外から 把握しにくい => プロダクトチームに対して何を提供しているのか分かりにくいため、プラットフォームの 価値が届いていなかった 仕組みは整っているが、どう運用しているのかが伝わっていない回答の例
19. 19 課題(2) PDCAを回せていない - 提供したプラットフォームに対するフィードバックや意見を集める習慣がなかった - プラットフォームを継続的に評価する指標がなかった => プラットフォームのPDCAを回せておらず、継続的なDX向上に貢献できていなかった
20. 2 0 課題に対するアプローチ
21. 21 課題にどう対処するか - ユーザー目線の欠如 - PDCAを回せていない
22. 22 課題にどう対処するか - ユーザー目線の欠如 - PDCAを回せていない Team Topologies p.114 「プラットフォームチームの振る舞い」のベストプラクティス - プロダクトチームと 密接に 関わり、 ニーズを 理解する - プロダクトチームを 巻き込んで、 フィードバックループを 回す - プラットフォームを プロダクトと して 扱い、 定期的に ユーザビリティを 評価する - 作った ものを 実際に 使い、 手本を 示す - 新技術の 採用に 責任を 持つことのアピール
23. 23 課題にどう対処するか - ユーザー目線の欠如 - PDCAを回せていない Team Topologies p.114 「プラットフォームチームの振る舞い」のベストプラクティス - プロダクトチームと 密接に 関わり、 ニーズを 理解する <ユーザー目線> - プロダクトチームを 巻き込んで、 フィードバックループを 回す <PDCA> - プラットフォームを プロダクトと して 扱い、 定期的に ユーザビリティを 評価する <PDCA> - 作った ものを 実際に 使い、 手本を 示す <ユーザー目線> - 新技術の 採用に 責任を 持つことのアピール <ユーザー目線>
24. 24 ベストプラクティスからアプローチを計画 課題 ベストプラクティス アプローチ ユーザー目線の欠如 プロダクトチームと 密接に 関わる アンケートを継続し、オフィスアワーを 開催 作った ものを 実際に 使い、 手本を 示 す 自分たちがユーザーでもあるプラット フォームの改善から始める 新技術の 採用に 責任を 持つことのア ピール 意思決定フローの見直し チーム内外向けストック情報の整備 PDCAが回せていない プロダクトチームを 巻き込んで、FB ループを回す 早い段階からプロダクトチームを巻き込 んで施策を進める 定期的に ユーザビリティを 評価する 簡単な指標からチームの目線を揃える
25. 25 ベストプラクティスからアプローチを計画 課題 ベストプラクティス アプローチ ユーザー目線の欠如 プロダクトチームと 密接に 関わる アンケートを継続し、オフィスアワーを 開催 作った ものを 実際に 使い、 手本を 示 す 自分たちがユーザーでもあるプラット フォームの改善から始める 新技術の 採用に 責任を 持つことのア ピール 意思決定フローの見直し チーム内外向けストック情報の整備 PDCAが回せていない プロダクトチームを 巻き込んで、FB ループを回す 早い段階からプロダクトチームを巻き込 んで施策を進める 定期的に ユーザビリティを 評価する 簡単な指標からチームの目線を揃える
26. 26 アンケートを継続し、オフィスアワーを開催 アンケートから潜在的なニーズを拾い、それをテーマに したオフィスアワーでナレッジシェア
27. 27 ベストプラクティスからアプローチを計画 課題 ベストプラクティス アプローチ ユーザー目線の欠如 プロダクトチームと 密接に 関わる アンケートを継続し、オフィスアワーを 開催 作った ものを 実際に 使い、 手本を 示 す 自分たちがユーザーでもあるプラット フォームの改善から始める 新技術の 採用に 責任を 持つことのア ピール 意思決定フローの見直し チーム内外向けストック情報の整備 PDCAが回せていない プロダクトチームを 巻き込んで、FB ループを回す 早い段階からプロダクトチームを巻き込 んで施策を進める 定期的に ユーザビリティを 評価する 簡単な指標からチームの目線を揃える
28. 28 自分たちがユーザーでもあるプラットフォームの改善から始める - まず自分たちも利用するCI/CD周りから、チケット起 票による改善をチームで始める - 気になったらとりあえずチケットを切ってもらう - 起票そのものを賞賛するカルチャーの醸成 - 後から優先度を評価し、定期的に担当者をアサイン - 改善と同時にガイドラインの整備も行う
29. 29 ベストプラクティスからアプローチを計画 課題 ベストプラクティス アプローチ ユーザー目線の欠如 プロダクトチームと 密接に 関わる アンケートを継続し、オフィスアワーを 開催 作った ものを 実際に 使い、 手本を 示 す 自分たちがユーザーでもあるプラット フォームの改善から始める 新技術の 採用に 責任を 持つことのア ピール 意思決定フローの見直し チーム内外向けストック情報の整備 PDCAが回せていない プロダクトチームを 巻き込んで、FB ループを回す 早い段階からプロダクトチームを巻き込 んで施策を進める 定期的に ユーザビリティを 評価する 簡単な指標からチームの目線を揃える
30. 30 意思決定フローの見直し / チーム内外向けストック情報の整備 - これまでの意思決定の見直し - 当時の経緯がわからないものは、現状をもとにADRを作成して再検討 - 暗黙のルールを放置しない - 影響が大きそうなADRのレビューはプロダクトチームにも依頼し、積極的に意見を取り入 れる - チーム内外向けストック情報の整備 - CI/CDのガイドラインやトラブルシュート集を作成 - Notion WikiのVerification機能を使い、陳腐化も防止
31. 31 ベストプラクティスからアプローチを計画 課題 ベストプラクティス アプローチ ユーザー目線の欠如 プロダクトチームと 密接に 関わる アンケートを継続し、オフィスアワーを 開催 作った ものを 実際に 使い、 手本を 示 す 自分たちがユーザーでもあるプラット フォームの改善から始める 新技術の 採用に 責任を 持つことのア ピール 意思決定フローの見直し チーム内外向けストック情報の整備 PDCAが回せていない プロダクトチームを 巻き込んで、FB ループを回す 早い段階からプロダクトチームを巻き込 んで施策を進める 定期的に ユーザビリティを 評価する 簡単な指標からチームの目線を揃える
32. 32 早い段階からプロダクトチームを巻き込んで施策を進める - 取り組む施策について、「なぜやるのか」「どんな効果が あるのか」事前告知や説明会の実施を積極的に行った - リリース速度が上がる、レイテンシが下がる といった ビジネスインパクトに繋がることをアピール - 完了後は振り返り会を実施し、KeepやTryを創出 - 再現性の高いものはOKRに組み込んだ
33. 33 ベストプラクティスからアプローチを計画 課題 ベストプラクティス アプローチ ユーザー目線の欠如 プロダクトチームと 密接に 関わる アンケートを継続し、オフィスアワーを 開催 作った ものを 実際に 使い、 手本を 示 す 自分たちがユーザーでもあるプラット フォームの改善から始める 新技術の 採用に 責任を 持つことのア ピール 意思決定フローの見直し チーム内外向けストック情報の整備 PDCAが回せていない プロダクトチームを 巻き込んで、FB ループを回す 早い段階からプロダクトチームを巻き込 んで施策を進める 定期的に ユーザビリティを 評価する 簡単な指標からチームの目線を揃える
34. 34 簡単な指標からチームの目線を揃える - メトリクスの整備は時間がかかるので、現状から簡単に計測できる指標を採用 - e.g. プロダクトチームからの問い合わせ数、放置されているPR数 - OKRも定量的な成果目標にすることを徹底し、チームで目指すゴールの認識を揃えた - OKRについて終日議論する時間をとり、みんなで目標設定する
35. 35 アプローチ以外で意識したこと チーム内 - チーム全員でアプローチを意識する体制を作った - やってほしいことはちゃんと伝える (ADRや手順書の作成など) - チーム内でもナレッジシェアの機会を作る - お互いFBしあえるカルチャーを醸成した - 当番制で、定例のアイスブレイクを実施 - 定期的なレトロスペクティブ、オフラインコミュニケーション(飲み会)の開催 チーム外 - 偶発的なコミュニケーションを見逃さない - Slackのtimesチャンネル、出社時のランチ雑談など - 経験豊富なメンバー(TLなど)からの個別ヒアリング
36. 3 6 結果
37. 37 アプローチを半年ほど続けた結果 ユーザー目線の欠如 - 導入前の説明や導入後のガイドライン整備によって、プラットフォームの価値を届ける導 線ができた - プロダクトチームのニーズや課題感が可視化され、プラットフォームとして提供すべき機 能が明確になってきた - 丁寧に施策を進めて信頼を得たことで、プロダクトチームからのfeature requestも 積極的に来るようになった
38. 38 アプローチを半年ほど続けた結果 PDCAが回っていない - チームとして改善サイクルを回すカルチャーが定着して、継続的なDX向上ができている - ドキュメントも整備が進んだことで新メンバーへのナレッジシェアが容易になり、入社後 すぐにタスクに着手できるようになった 作成されたADRの数
39. 39 前提の補完(1) Platformがもたらすもの (再掲) CNCFプラットフォームホワイトペーパー 認知負荷の 軽減 プロダクトチームの 認知負荷を 軽減し、 プロダクト開発と デリバ リーを 加速 責任の 明確化 プラットフォーム能力を 構成・管理する 専門家を 配置する こと で、 彼らに 依存する 製品の 信頼性と 回復力を 向上 スケーラビリティの担保 企業内の 多くの チームで プラットフォームツールや ナレッジを 再利 用・共有する ことで、 プロダクト開発と デリバリーを 加速 ガバナンスの 強化 プラットフォーム能力、 ユーザー、 ツール、 プロセスを 統制する こ とで、 製品と サービスに おける セキュリティ、 規制、 機能面の リス クを 軽減する
40. 40 現状のPlatform まだまだやるべきことはたくさんある!! 認知負荷の 軽減 ドキュメント面では順調 抽象化,セルフサービス化による認知負荷の軽減は道半ば 責任の 明確化 チーム発足、ドキュメント整備で責務を体現できるようになった スケーラビリティの担保 CI/CDなどプラットフォームの標準は整えた バリエーションを増やすことが次の課題 ガバナンスの 強化 ADRで決まった施策が多いので、順次実行計画を立て、着手してい く
41. 41 Next Actions - セルフサービス化の推進 - 権限管理の仕組みやIDP(Internal Developer Portal/Platform)などを提供し、プロダ クトチームが迷わず必要なリソースを用意できるようにする - プラットフォームのメトリクス収集 - アンケートだけではなく、数値としてチームのアウトプットを評価できる仕組み - チームのロードマップ策定 - いつ頃に何の機能が提供されるのか プロダクトチームに伝わるにようにする - プロダクトチームにワクワクしてもらえるような計画を立てる！
42. 4 2 X-as-a-Serviceの取り組み
43. 43 X-as-a-Service 主に提供しているものは以下。 - Terraform / k8s manifestのCI/CD - Golden Path
44. 44 Terraform / k8s manifest CI/CD Terraform - tflint, trivy, tfstateのdrift checkをパスした状 態で自動マージ → Apply - RenovateによるバージョンアップPRの自動マー ジ機能も実装中
45. 45 Terraform / k8s manifest CI/CD k8s manifest - ツールとしてArgo CDを利用
46. 46 Terraform / k8s manifest CI/CD k8s manifest - Argo CD Sync前に、PRでkustomize diffの結果を出力
47. 47 Terraform / k8s manifest CI/CD k8s manifest - conftestで標準を満たしているかチェックし て、変更の提案を行うCIを開発中
48. 48 Golden Pathのアップデート - ワンショットのshell scriptによるコード生成から、Backstage互換のyamlファイルを基 にしたサービスカタログモデルにリアーキ - いきなりのBackstage導入(GUI提供)は見送り、独自のCLIを開発
49. 4 9 まとめ
50. 50 まとめ • 立ち上げ期を終えたフェーズで、プロアクティブにPlatform Engineeringチームを発足 した • プロダクトチームとの関わり方をアップデートし、徐々にTeam Topologiesのプラット フォームチーム的な振る舞いができるようになった • 現状の改善を続けながらも中長期的なロードマップを定めて、enechainのプロダクト開 発をもっとスケーラブルにしていく！