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

by Hayato Okuma

Slide 1

Slide 1 text

X-as-a-Serviceを目指して Team Topologiesの実践で見えた現実＠kumashun88 2025/10/14 CloudNative Days Winter 2025 プレイベント

Slide 2

Slide 2 text

2 自己紹介大隈隼 @kumashun88 2020-2024 freee(現地!) SRE, サービス基盤 (Engineer) 2025- enechain Platform Engineering Desk (Engineer) 技術: k8s, AWS, Google Cloud, GitHub Actions, Terraform, Golang 趣味: 映画🍿、ランニング󰝊、ビール🍺 (Far East Tokyoおすすめ!!)

Slide 3

Slide 3 text

3 会社紹介 - 株式会社enechain さらっと紹介する感じ。 hiyosiさんの時のやつを使えばよさそう。そもそも会社のこと話ししてok?

Slide 4

Slide 4 text

4 メインターゲット/得られる学びより学びが得られる視聴者層 - Platform Engineeringをやり始めた or これからやろうとしている方得られる学び - どうPlatform Engineeringを始めるといいか、その一例 - Team Topologiesのプラットフォームチームを構築する過程

Slide 5

Slide 5 text

5 アジェンダ - 導入 ←ｲﾏｺｺ - Platform Engineeringチーム発足の経緯 - チームの課題 - 課題に対するアプローチ - 結果 - (時間があれば) X-as-a-Serviceの取り組み - まとめ

Slide 6

Slide 6 text

6 前提の補完(1) Platform Engineering - Platform : プロダクトの開発、デプロイ、運用を支援するもの - Platform Engineering : Platformを設計、開発および運用する取り組み https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/

Slide 7

Slide 7 text

7 前提の補完(1) Platformがもたらすもの CNCFプラットフォームホワイトペーパー認知負荷の軽減プロダクトチームの認知負荷を軽減し、プロダクト開発とデリバリーを加速責任の明確化プラットフォーム能力を構成・管理する専門家を配置することで、彼らに依存する製品の信頼性と回復力を向上スケーラビリティの担保企業内の多くのチームでプラットフォームツールやナレッジを再利用・共有することで、プロダクト開発とデリバリーを加速ガバナンスの強化プラットフォーム能力、ユーザー、ツール、プロセスを統制することで、製品とサービスにおけるセキュリティ、規制、機能面のリスクを軽減する

Slide 8

Slide 8 text

8 前提の補完(2) Team Topologies ソフトウェア開発における組織構造とチーム設計のベストプラクティス - 4つのチーム - ストリームアラインドチーム（ドメイン開発） - コンプリケイテッド・サブシステムチーム（専門領域） - イネイブリングチーム（スト...の自律をサポート） - プラットフォームチーム（内部サービスの提供） - 3つのインタラクションモード - コラボレーション（協業） - ファシリテーション（サポート的関与） - X-as-a-Service（サービスとしての提供） JMAMeショップから引用

Slide 9

Slide 9 text

9 前提の補完(2) Team Topologies プラットフォームチームストリームアラインドチームイネイブリングチームコンプリケイテッド・サブシステムチームファシリテーション X-as-a-Service X-as-a-Service

Slide 10

Slide 10 text

1 0 Platform Engineering チーム発足の経緯

Slide 11

Slide 11 text

11 当時の開発組織体制 (2024/06) チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog 複数のプロダクトチームに対して、SREチームがインフラの何でも屋さん状態に。それぞれの立場で問題が生じていた。 - 開発者目線: 意思決定が中央集権的になっており、新技術の導入がスムーズにできない - SRE目線: 問い合わせが多すぎて、中長期課題に取り組めない今から投資しないと、SREチームがボトルネックになる。 - プロダクト増加に伴う、標準策定やガバナンス強化が必要になるのは明白

Slide 12

Slide 12 text

12 組織体制の見直し (2024/06) チームトポロジーの観点で見直すプラットフォーム開発組織 - enechain Tech Blog チームトポロジーを参考にSREチームからPlatform Engineering、Security専門チームを分割。チームミッションチームタイプインタラクションモード SRE Desk 全プロダクトの Reliability向上に責任を持つイネイブリングチームファシリテーション（定常時）, コラボレーション（プロダクト開始時や重要機能実装時） Platform Engineering Desk プラットフォーム領域において、各開発チームのデベロッパー体験の最大化に責任を持つプラットフォームチーム X-as-a-Service

Slide 13

Slide 13 text

13 Platform Engineeringチーム発足後の変化 Platform Engineeringの思想を取り入れることができた。 (2024/06) Before After 開発者目線: 意思決定が中央集権的になっており、新技術の導入がスムーズにできないチームごとに明確なミッションを持つ状態になったことで、将来像を描いた上で適切に判断できるようになった！ SRE目線: 問い合わせが多すぎて、中長期課題に取り組めない SRE/PEで責務が分かれたことで問い合わせが分散し、並行して中長期課題に取り組めるようになった！

Slide 14

Slide 14 text

14 Platform Engineeringチーム発足後の変化自分の入社時点 (2025/01) - 前述の効果が継続しており、Platfoform Engineeringのカルチャーは醸成されてきていた - しかし、運用面や体制面において課題がいくつか残っていた

Slide 15

Slide 15 text

1 5 チームの課題

Slide 16

Slide 16 text

16 現状の課題を調査自分の入社に合わせてチームをより良くするために、現状の課題点を洗い出した。 - チームの状態 - 入社直後のフラットな目線で、定例の様子やメンバーの仕事の進め方を分析 - 開発者全体へアンケートの実施 - インフラやプラットフォームに対する課題感のヒアリングを実施

Slide 17

Slide 17 text

17 現状の課題を調査自分の入社に合わせてチームをより良くするために、現状の課題点を洗い出した。 - チームの状態 - 入社直後のフラットな目線で、定例の様子やメンバーの仕事の進め方を分析 - 開発者全体へアンケートの実施 - インフラやプラットフォームに対する課題感のヒアリングを実施 → 大きく2つの課題が見えてきた

Slide 18

Slide 18 text

18 課題(1) ユーザー目線の欠如 - 課題解決は実践できているが、プロダクトチームにその背景や目的が伝わっておらず、実践後の影響が分かっていなかった - プロダクトチーム向けのガイドラインが少ない - 過去の意思決定の経緯がチーム外から把握しにくい => プロダクトチームに対して何を提供しているのか分かりにくいため、プラットフォームの価値が届いていなかった仕組みは整っているが、どう運用しているのかが伝わっていない回答の例

Slide 19

Slide 19 text

19 課題(2) PDCAを回せていない - 提供したプラットフォームに対するフィードバックや意見を集める習慣がなかった - プラットフォームを継続的に評価する指標がなかった => プラットフォームのPDCAを回せておらず、継続的なDX向上に貢献できていなかった

Slide 20

Slide 20 text

2 0 課題に対するアプローチ

Slide 21

Slide 21 text

21 課題にどう対処するか - ユーザー目線の欠如 - PDCAを回せていない

Slide 22

Slide 22 text

22 課題にどう対処するか - ユーザー目線の欠如 - PDCAを回せていない Team Topologies p.114 「プラットフォームチームの振る舞い」のベストプラクティス - プロダクトチームと密接に関わり、ニーズを理解する - プロダクトチームを巻き込んで、フィードバックループを回す - プラットフォームをプロダクトとして扱い、定期的にユーザビリティを評価する - 作ったものを実際に使い、手本を示す - 新技術の採用に責任を持つことのアピール

Slide 23

Slide 23 text

23 課題にどう対処するか - ユーザー目線の欠如 - PDCAを回せていない Team Topologies p.114 「プラットフォームチームの振る舞い」のベストプラクティス - プロダクトチームと密接に関わり、ニーズを理解する <ユーザー目線> - プロダクトチームを巻き込んで、フィードバックループを回す - プラットフォームをプロダクトとして扱い、定期的にユーザビリティを評価する - 作ったものを実際に使い、手本を示す <ユーザー目線> - 新技術の採用に責任を持つことのアピール <ユーザー目線>

Slide 24

Slide 24 text

24 ベストプラクティスからアプローチを計画課題ベストプラクティスアプローチユーザー目線の欠如プロダクトチームと密接に関わるアンケートを継続し、オフィスアワーを開催作ったものを実際に使い、手本を示す自分たちがユーザーでもあるプラットフォームの改善から始める新技術の採用に責任を持つことのアピール意思決定フローの見直しチーム内外向けストック情報の整備 PDCAが回せていないプロダクトチームを巻き込んで、FB ループを回す早い段階からプロダクトチームを巻き込んで施策を進める定期的にユーザビリティを評価する簡単な指標からチームの目線を揃える

Slide 25

Slide 25 text

25 ベストプラクティスからアプローチを計画課題ベストプラクティスアプローチユーザー目線の欠如プロダクトチームと密接に関わるアンケートを継続し、オフィスアワーを開催作ったものを実際に使い、手本を示す自分たちがユーザーでもあるプラットフォームの改善から始める新技術の採用に責任を持つことのアピール意思決定フローの見直しチーム内外向けストック情報の整備 PDCAが回せていないプロダクトチームを巻き込んで、FB ループを回す早い段階からプロダクトチームを巻き込んで施策を進める定期的にユーザビリティを評価する簡単な指標からチームの目線を揃える

Slide 26

Slide 26 text

26 アンケートを継続し、オフィスアワーを開催アンケートから潜在的なニーズを拾い、それをテーマにしたオフィスアワーでナレッジシェア

Slide 27

Slide 27 text

27 ベストプラクティスからアプローチを計画課題ベストプラクティスアプローチユーザー目線の欠如プロダクトチームと密接に関わるアンケートを継続し、オフィスアワーを開催作ったものを実際に使い、手本を示す自分たちがユーザーでもあるプラットフォームの改善から始める新技術の採用に責任を持つことのアピール意思決定フローの見直しチーム内外向けストック情報の整備 PDCAが回せていないプロダクトチームを巻き込んで、FB ループを回す早い段階からプロダクトチームを巻き込んで施策を進める定期的にユーザビリティを評価する簡単な指標からチームの目線を揃える

Slide 28

Slide 28 text

28 自分たちがユーザーでもあるプラットフォームの改善から始める - まず自分たちも利用するCI/CD周りから、チケット起票による改善をチームで始める - 気になったらとりあえずチケットを切ってもらう - 起票そのものを賞賛するカルチャーの醸成 - 後から優先度を評価し、定期的に担当者をアサイン - 改善と同時にガイドラインの整備も行う

Slide 29

Slide 29 text

29 ベストプラクティスからアプローチを計画課題ベストプラクティスアプローチユーザー目線の欠如プロダクトチームと密接に関わるアンケートを継続し、オフィスアワーを開催作ったものを実際に使い、手本を示す自分たちがユーザーでもあるプラットフォームの改善から始める新技術の採用に責任を持つことのアピール意思決定フローの見直しチーム内外向けストック情報の整備 PDCAが回せていないプロダクトチームを巻き込んで、FB ループを回す早い段階からプロダクトチームを巻き込んで施策を進める定期的にユーザビリティを評価する簡単な指標からチームの目線を揃える

Slide 30

Slide 30 text

30 意思決定フローの見直し / チーム内外向けストック情報の整備 - これまでの意思決定の見直し - 当時の経緯がわからないものは、現状をもとにADRを作成して再検討 - 暗黙のルールを放置しない - 影響が大きそうなADRのレビューはプロダクトチームにも依頼し、積極的に意見を取り入れる - チーム内外向けストック情報の整備 - CI/CDのガイドラインやトラブルシュート集を作成 - Notion WikiのVeriﬁcation機能を使い、陳腐化も防止

Slide 31

Slide 31 text

31 ベストプラクティスからアプローチを計画課題ベストプラクティスアプローチユーザー目線の欠如プロダクトチームと密接に関わるアンケートを継続し、オフィスアワーを開催作ったものを実際に使い、手本を示す自分たちがユーザーでもあるプラットフォームの改善から始める新技術の採用に責任を持つことのアピール意思決定フローの見直しチーム内外向けストック情報の整備 PDCAが回せていないプロダクトチームを巻き込んで、FB ループを回す早い段階からプロダクトチームを巻き込んで施策を進める定期的にユーザビリティを評価する簡単な指標からチームの目線を揃える

Slide 32

Slide 32 text

32 早い段階からプロダクトチームを巻き込んで施策を進める - 取り組む施策について、「なぜやるのか」「どんな効果があるのか」事前告知や説明会の実施を積極的に行った - リリース速度が上がる、レイテンシが下がるといったビジネスインパクトに繋がることをアピール - 完了後は振り返り会を実施し、KeepやTryを創出 - 再現性の高いものはOKRに組み込んだ

Slide 33

Slide 33 text

33 ベストプラクティスからアプローチを計画課題ベストプラクティスアプローチユーザー目線の欠如プロダクトチームと密接に関わるアンケートを継続し、オフィスアワーを開催作ったものを実際に使い、手本を示す自分たちがユーザーでもあるプラットフォームの改善から始める新技術の採用に責任を持つことのアピール意思決定フローの見直しチーム内外向けストック情報の整備 PDCAが回せていないプロダクトチームを巻き込んで、FB ループを回す早い段階からプロダクトチームを巻き込んで施策を進める定期的にユーザビリティを評価する簡単な指標からチームの目線を揃える

Slide 34

Slide 34 text

34 簡単な指標からチームの目線を揃える - メトリクスの整備は時間がかかるので、現状から簡単に計測できる指標を採用 - e.g. プロダクトチームからの問い合わせ数、放置されているPR数 - OKRも定量的な成果目標にすることを徹底し、チームで目指すゴールの認識を揃えた - OKRについて終日議論する時間をとり、みんなで目標設定する

Slide 35

Slide 35 text

35 アプローチ以外で意識したことチーム内 - チーム全員でアプローチを意識する体制を作った - やってほしいことはちゃんと伝える (ADRや手順書の作成など) - チーム内でもナレッジシェアの機会を作る - お互いFBしあえるカルチャーを醸成した - 当番制で、定例のアイスブレイクを実施 - 定期的なレトロスペクティブ、オフラインコミュニケーション(飲み会)の開催チーム外 - 偶発的なコミュニケーションを見逃さない - Slackのtimesチャンネル、出社時のランチ雑談など - 経験豊富なメンバー(TLなど)からの個別ヒアリング

Slide 36

Slide 36 text

3 6 結果

Slide 37

Slide 37 text

37 アプローチを半年ほど続けた結果ユーザー目線の欠如 - 導入前の説明や導入後のガイドライン整備によって、プラットフォームの価値を届ける導線ができた - プロダクトチームのニーズや課題感が可視化され、プラットフォームとして提供すべき機能が明確になってきた - 丁寧に施策を進めて信頼を得たことで、プロダクトチームからのfeature requestも積極的に来るようになった

Slide 38

Slide 38 text

38 アプローチを半年ほど続けた結果 PDCAが回っていない - チームとして改善サイクルを回すカルチャーが定着して、継続的なDX向上ができている - ドキュメントも整備が進んだことで新メンバーへのナレッジシェアが容易になり、入社後すぐにタスクに着手できるようになった作成されたADRの数

Slide 39

Slide 39 text

39 前提の補完(1) Platformがもたらすもの (再掲) CNCFプラットフォームホワイトペーパー認知負荷の軽減プロダクトチームの認知負荷を軽減し、プロダクト開発とデリバリーを加速責任の明確化プラットフォーム能力を構成・管理する専門家を配置することで、彼らに依存する製品の信頼性と回復力を向上スケーラビリティの担保企業内の多くのチームでプラットフォームツールやナレッジを再利用・共有することで、プロダクト開発とデリバリーを加速ガバナンスの強化プラットフォーム能力、ユーザー、ツール、プロセスを統制することで、製品とサービスにおけるセキュリティ、規制、機能面のリスクを軽減する

Slide 40

Slide 40 text

40 現状のPlatform まだまだやるべきことはたくさんある!! 認知負荷の軽減ドキュメント面では順調抽象化,セルフサービス化による認知負荷の軽減は道半ば責任の明確化チーム発足、ドキュメント整備で責務を体現できるようになったスケーラビリティの担保 CI/CDなどプラットフォームの標準は整えたバリエーションを増やすことが次の課題ガバナンスの強化 ADRで決まった施策が多いので、順次実行計画を立て、着手していく

Slide 41

Slide 41 text

41 Next Actions - セルフサービス化の推進 - 権限管理の仕組みやIDP(Internal Developer Portal/Platform)などを提供し、プロダクトチームが迷わず必要なリソースを用意できるようにする - プラットフォームのメトリクス収集 - アンケートだけではなく、数値としてチームのアウトプットを評価できる仕組み - チームのロードマップ策定 - いつ頃に何の機能が提供されるのかプロダクトチームに伝わるにようにする - プロダクトチームにワクワクしてもらえるような計画を立てる！

Slide 42

Slide 42 text

4 2 X-as-a-Serviceの取り組み

Slide 43

Slide 43 text

43 X-as-a-Service 主に提供しているものは以下。 - Terraform / k8s manifestのCI/CD - Golden Path

Slide 44

Slide 44 text

44 Terraform / k8s manifest CI/CD Terraform - tﬂint, trivy, tfstateのdrift checkをパスした状態で自動マージ → Apply - RenovateによるバージョンアップPRの自動マージ機能も実装中

Slide 45

Slide 45 text

45 Terraform / k8s manifest CI/CD k8s manifest - ツールとしてArgo CDを利用

Slide 46

Slide 46 text

46 Terraform / k8s manifest CI/CD k8s manifest - Argo CD Sync前に、PRでkustomize diﬀの結果を出力

Slide 47

Slide 47 text

47 Terraform / k8s manifest CI/CD k8s manifest - conftestで標準を満たしているかチェックして、変更の提案を行うCIを開発中

Slide 48

Slide 48 text

48 Golden Pathのアップデート - ワンショットのshell scriptによるコード生成から、Backstage互換のyamlファイルを基にしたサービスカタログモデルにリアーキ - いきなりのBackstage導入(GUI提供)は見送り、独自のCLIを開発

Slide 49

Slide 49 text

4 9 まとめ

Slide 50

Slide 50 text

50 まとめ ● 立ち上げ期を終えたフェーズで、プロアクティブにPlatform Engineeringチームを発足した ● プロダクトチームとの関わり方をアップデートし、徐々にTeam Topologiesのプラットフォームチーム的な振る舞いができるようになった ● 現状の改善を続けながらも中長期的なロードマップを定めて、enechainのプロダクト開発をもっとスケーラブルにしていく！

Slide 51

Slide 51 text

No content