Platform Engineering：Internal Developer Platform の構築方法

spinny:~/writing $ less platform-engineering-internal-developer-platform.md

1 
2ソフトウェアシステムがより複雑になるにつれて -  - マイクロサービス、Kubernetes、マルチクラウド、CI/CD パイプライン、オブザーバビリティスタック -  - 開発者はインフラストラクチャにより多くの時間を費やし、プロダクトの構築に費やす時間が少なくなっています。**Platform Engineering** は、複雑さを抽象化し、開発者にセルフサービスツールを提供する内部プラットフォームを作成することで、この問題を解決します。
3 
4Gartner は、2027年までに**ソフトウェアエンジニアリング組織の80%**がプラットフォームチームを設立すると予測しています。このガイドでは、Platform Engineering とは何か、なぜ重要なのか、そして Internal Developer Platform をゼロから構築する方法を探ります。
5 
6## Platform Engineering とは？
7 
8Platform Engineering は、ソフトウェアエンジニアリング組織にセルフサービス機能を提供するツールチェーンとワークフローを設計・構築する分野です。その成果物は **Internal Developer Platform (IDP)**  -  - 開発者とインフラストラクチャの間に位置する抽象化レイヤーです。
9 
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17 
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24 
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31 
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43 
44### Platform Engineering vs DevOps
45 
46Platform Engineering は DevOps の代替ではありません -  - 次の進化です。DevOps は「あなたが作り、あなたが運用する」と言いました。Platform Engineering は「構築と運用を楽にします」と言います。
47 
48| 側面 | DevOps | Platform Engineering |
49|------|--------|---------------------|
50| **焦点** | 文化とプラクティス | プロダクトとセルフサービス |
51| **アプローチ** | 各チームがインフラを管理 | プラットフォームチームがインフラを抽象化 |
52| **認知負荷** | 高い（各チームがすべてを学ぶ） | 低い（ゴールデンパスが提供される） |
53| **成果物** | CI/CD パイプライン、IaC スクリプト | Internal Developer Platform |
54| **ユーザー** | 全エンジニアリング | プラットフォームチームがエンジニアリングに奉仕 |
55 
56## なぜ Platform Engineering が重要なのか
57 
58### 認知負荷の問題
59 
60典型的な現代の組織では、開発者は以下を理解する必要があります：
61 
62- Git ワークフローとブランチ戦略
63- CI/CD パイプラインの設定
64- コンテナのビルドとレジストリ管理
65- Kubernetes マニフェストと Helm Charts
66- クラウドプロバイダーサービス（AWS/GCP/Azure）
67- ネットワーキング、DNS、TLS 証明書
68- モニタリング、ロギング、アラート設定
69- データベースのプロビジョニングとマイグレーション
70- セキュリティポリシーとコンプライアンス
71 
72これは実際のプロダクトから注意をそらす膨大な認知負荷です。
73 
74### ゴールデンパス
75 
76Platform Engineering は**ゴールデンパス**の概念を導入します -  - 一般的なタスクに対する意見を持った、十分にサポートされ、文書化されたパスです。ゴールデンパスは強制ではありません。開発者は*逸脱できます*が、プラットフォームは正しいことを簡単なことにします。
77 
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88 
89**新しいマイクロサービス作成のゴールデンパスの例：**
901. 開発者がポータルで「新しいバックエンドサービス」を選択
912. 言語/フレームワークを選択（Node.js、Go、Python）
923. プラットフォームが自動作成：Git リポジトリ、CI/CD パイプライン、Kubernetes ネームスペース、モニタリングダッシュボード、アラートルール
934. 開発者がリポジトリをクローンして、すぐにコーディングを開始
94 
95## Internal Developer Platform の構築
96 
97### レイヤー1：Developer Portal
98 
99ポータルは開発者のための単一のエントリポイントです。最も人気のあるオープンソースの選択肢は **Backstage**（Spotify が作成、現在は CNCF プロジェクト）です。
100 
101主要な機能：
102- **サービスカタログ**：すべてのサービス、そのオーナー、ドキュメント、依存関係
103- **ソフトウェアテンプレート**：ベストプラクティスが組み込まれた新しいサービスのスキャフォールディング
104- **技術ドキュメント**：コードとしてのドキュメント、レンダリングされ検索可能
105- **プラグインエコシステム**：カスタム機能で拡張可能
106 
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127 
128### レイヤー2：インフラストラクチャの抽象化
129 
130開発者は Terraform や Kubernetes YAML を直接書くべきではありません。プラットフォームが抽象化を提供すべきです。
131 
132**ツール：**
133- **Crossplane**：Kubernetes ネイティブのインフラストラクチャプロビジョニング
134- **Terraform モジュール**：事前構築・テスト済みのインフラストラクチャモジュール
135- **Pulumi**：実際のコードとしてのインフラストラクチャ（TypeScript、Python、Go）
136 
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149 
150RDS パラメータ、VPC サブネット、セキュリティグループ、バックアップポリシーを設定する代わりに、開発者は `size: small` と `backup: daily` を指定するだけです。プラットフォームが残りを処理します。
151 
152### レイヤー3：CI/CD の標準化
153 
154各チームが独自のパイプラインを構築しなくて済むよう、CI/CD を標準化します。
155 
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163 
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172 
173**主要なプラクティス：**
174- チームがインクルード（コピーではなく）する共有 CI/CD テンプレート
175- 自動セキュリティスキャン（SAST、依存関係監査）
176- 標準化されたデプロイメント戦略（カナリア、ブルー/グリーン）
177- ヘルスチェック失敗時の自動ロールバック
178 
179### レイヤー4：オブザーバビリティ
180 
181事前設定されたモニタリングにより、開発者はすぐに使えるダッシュボードとアラートを取得できます。
182 
183- **メトリクス**：Prometheus + Grafana、サービスごとの標準ダッシュボード
184- **ロギング**：集中収集による構造化ロギング（Loki、ELK）
185- **トレーシング**：OpenTelemetry による分散トレーシング
186- **アラート**：合理的なデフォルトによる PagerDuty/Opsgenie 連携
187 
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199 
200## 成功の測定
201 
202プラットフォームが機能しているかどうかをどう判断しますか？以下のメトリクスを追跡しましょう：
203 
204### DORA メトリクス
205- **デプロイ頻度**：コードが本番環境に到達する頻度
206- **変更のリードタイム**：コミットから本番環境までの時間
207- **変更失敗率**：障害を引き起こすデプロイメントの割合
208- **平均復旧時間**：インシデント後にサービスを復旧するまでの時間
209 
210### プラットフォーム固有のメトリクス
211- **初回デプロイまでの時間**：「新しいサービス」から最初の本番デプロイまでの所要時間
212- **開発者満足度（NPS）**：ユーザーに定期的にアンケート
213- **セルフサービス率**：チケットなしで処理されるインフラリクエストの割合
214- **ゴールデンパス採用率**：推奨パスに従うサービスの割合
215 
216## よくある間違い
217 
218### 1. 早すぎる段階で作りすぎる
219壮大なビジョンではなく、最大のペインポイントから始めましょう。デプロイメントが苦痛なら、そこから始めます。プロビジョニングに数週間かかるなら、そこから始めます。
220 
221### 2. プラットフォームをプロダクトとして扱わない
222プラットフォームチームにはプロダクトマネージャー、ユーザーリサーチ、フィードバックループが必要です。開発者はあなたの顧客です -  - 彼らのニーズを理解しましょう。
223 
224### 3. 引き付けるのではなく強制する
225最良のプラットフォームは、開発者の生活を楽にするため自発的に採用されます。使用を強制しなければならないなら、プラットフォームが十分に良くないということです。
226 
227### 4. 開発者体験を無視する
228UX がひどいプラットフォームは使われません。明確なドキュメント、役立つエラーメッセージ、迅速なフィードバックループに投資しましょう。
229 
230## はじめに
231 
232最初の IDP を構築するための実践的なロードマップ：
233 
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239 
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243 
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247 
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251 
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256 
257### 最小限の実用的なプラットフォーム
258 
2591. **サービスカタログ**（Backstage） -  - 何が存在し、誰がオーナーかを把握
2602. **1つのサービステンプレート** -  - 最も一般的なサービスタイプのゴールデンパス
2613. **標準化された CI/CD** -  - チームがインクルードする共有パイプライン
2624. **基本的なドキュメント** -  - プラットフォームの使い方、ヘルプの入手先
263 
264この MVP は 2-3 名のエンジニアチームで 2-3 か月で構築できます。
265 
266## まとめ
267 
268Platform Engineering は初日から完璧なプラットフォームを構築することではありません。開発者の認知負荷を段階的に軽減し、プロダクト構築に集中できるようにすることです。小さく始め、影響を測定し、開発者のフィードバックに基づいて反復しましょう。
269 
270Platform Engineering に投資する組織は、大きな競争優位性を持つことになります：より速いデリバリー、より幸せな開発者、そしてより信頼性の高いシステム。
271 
272**リソース：**
273- [Team Topologies](https://teamtopologies.com/)  -  - プラットフォームチームを普及させた書籍
274- [Backstage](https://backstage.io/)  -  -  Spotify のオープンソース開発者ポータル
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  - コミュニティによる定義とベストプラクティス
276- [platformengineering.org](https://platformengineering.org/)  -  - コミュニティ、イベント、リソース
277

:Platform Engineering：Internal Developer Platform の構築方法lines 1-277 (END) — press q to close

2ソフトウェアシステムがより複雑になるにつれて - - マイクロサービス、Kubernetes、マルチクラウド、CI/CD パイプライン、オブザーバビリティスタック - - 開発者はインフラストラクチャにより多くの時間を費やし、プロダクトの構築に費やす時間が少なくなっています。**Platform Engineering** は、複雑さを抽象化し、開発者にセルフサービスツールを提供する内部プラットフォームを作成することで、この問題を解決します。

4Gartner は、2027年までに**ソフトウェアエンジニアリング組織の80%**がプラットフォームチームを設立すると予測しています。このガイドでは、Platform Engineering とは何か、なぜ重要なのか、そして Internal Developer Platform をゼロから構築する方法を探ります。

6## Platform Engineering とは？

8Platform Engineering は、ソフトウェアエンジニアリング組織にセルフサービス機能を提供するツールチェーンとワークフローを設計・構築する分野です。その成果物は **Internal Developer Platform (IDP)** - - 開発者とインフラストラクチャの間に位置する抽象化レイヤーです。

10```mermaid

11graph TD

12 subgraph "Developers"

13 D1[Frontend Team]

14 D2[Backend Team]

15 D3[Data Team]

16 end

18 subgraph "Internal Developer Platform"

19 Portal[Developer Portal]

20 Templates[Service Templates]

21 CICD[CI/CD Pipelines]

22 Infra[Infrastructure Abstraction]

23 end

25 subgraph "Infrastructure"

26 K8s[Kubernetes]

27 Cloud[Cloud Services]

28 DB[Databases]

29 Monitor[Monitoring]

30 end

32 D1 --> Portal

33 D2 --> Portal

34 D3 --> Portal

35 Portal --> Templates

36 Portal --> CICD

37 Portal --> Infra

38 Infra --> K8s

39 Infra --> Cloud

40 Infra --> DB

41 CICD --> Monitor

42```

44### Platform Engineering vs DevOps

46Platform Engineering は DevOps の代替ではありません - - 次の進化です。DevOps は「あなたが作り、あなたが運用する」と言いました。Platform Engineering は「構築と運用を楽にします」と言います。

48| 側面 | DevOps | Platform Engineering |

49|------|--------|---------------------|

50| **焦点** | 文化とプラクティス | プロダクトとセルフサービス |

51| **アプローチ** | 各チームがインフラを管理 | プラットフォームチームがインフラを抽象化 |

52| **認知負荷** | 高い（各チームがすべてを学ぶ） | 低い（ゴールデンパスが提供される） |

53| **成果物** | CI/CD パイプライン、IaC スクリプト | Internal Developer Platform |

54| **ユーザー** | 全エンジニアリング | プラットフォームチームがエンジニアリングに奉仕 |

56## なぜ Platform Engineering が重要なのか

58### 認知負荷の問題

60典型的な現代の組織では、開発者は以下を理解する必要があります：

62- Git ワークフローとブランチ戦略

63- CI/CD パイプラインの設定

64- コンテナのビルドとレジストリ管理

65- Kubernetes マニフェストと Helm Charts

66- クラウドプロバイダーサービス（AWS/GCP/Azure）

67- ネットワーキング、DNS、TLS 証明書

68- モニタリング、ロギング、アラート設定

69- データベースのプロビジョニングとマイグレーション

70- セキュリティポリシーとコンプライアンス

72これは実際のプロダクトから注意をそらす膨大な認知負荷です。

74### ゴールデンパス

76Platform Engineering は**ゴールデンパス**の概念を導入します - - 一般的なタスクに対する意見を持った、十分にサポートされ、文書化されたパスです。ゴールデンパスは強制ではありません。開発者は*逸脱できます*が、プラットフォームは正しいことを簡単なことにします。

78```mermaid

79flowchart LR

80 Dev[Developer] -- "Create new service" --> Portal[Portal]

81 Portal -- "Select template" --> Template[Service Template]

82 Template -- "Auto-provision" --> Repo[Git Repository]

83 Template --> Pipeline[CI/CD Pipeline]

84 Template --> Infra[Kubernetes Namespace]

85 Template --> Monitor[Dashboards + Alerts]

86 Repo --> Ready[Ready to Code!]

87```

89**新しいマイクロサービス作成のゴールデンパスの例：**

901. 開発者がポータルで「新しいバックエンドサービス」を選択

912. 言語/フレームワークを選択（Node.js、Go、Python）

923. プラットフォームが自動作成：Git リポジトリ、CI/CD パイプライン、Kubernetes ネームスペース、モニタリングダッシュボード、アラートルール

934. 開発者がリポジトリをクローンして、すぐにコーディングを開始

95## Internal Developer Platform の構築

97### レイヤー1：Developer Portal

99ポータルは開発者のための単一のエントリポイントです。最も人気のあるオープンソースの選択肢は **Backstage**（Spotify が作成、現在は CNCF プロジェクト）です。

100

101主要な機能：

102- **サービスカタログ**：すべてのサービス、そのオーナー、ドキュメント、依存関係

103- **ソフトウェアテンプレート**：ベストプラクティスが組み込まれた新しいサービスのスキャフォールディング

104- **技術ドキュメント**：コードとしてのドキュメント、レンダリングされ検索可能

105- **プラグインエコシステム**：カスタム機能で拡張可能

106

107```yaml

108# backstage/catalog-info.yaml

109apiVersion: backstage.io/v1alpha1

110kind: Component

111metadata:

112 name: user-service

113 description: Manages user accounts and authentication

114 annotations:

115 github.com/project-slug: myorg/user-service

116 backstage.io/techdocs-ref: dir:.

117spec:

118 type: service

119 lifecycle: production

120 owner: team-auth

121 system: identity-platform

122 dependsOn:

123 - resource:postgresql-main

124 providesApis:

125 - user-api

126```

127

128### レイヤー2：インフラストラクチャの抽象化

129

130開発者は Terraform や Kubernetes YAML を直接書くべきではありません。プラットフォームが抽象化を提供すべきです。

131

132**ツール：**

133- **Crossplane**：Kubernetes ネイティブのインフラストラクチャプロビジョニング

134- **Terraform モジュール**：事前構築・テスト済みのインフラストラクチャモジュール

135- **Pulumi**：実際のコードとしてのインフラストラクチャ（TypeScript、Python、Go）

136

137```yaml

138# Example: Crossplane composition for a database

139apiVersion: database.example.com/v1

140kind: PostgreSQLInstance

141metadata:

142 name: user-db

143spec:

144 size: small # Abstraction: small = 2 vCPU, 4GB RAM

145 version: "16"

146 backup: daily

147 team: auth-team

148```

149

150RDS パラメータ、VPC サブネット、セキュリティグループ、バックアップポリシーを設定する代わりに、開発者は `size: small` と `backup: daily` を指定するだけです。プラットフォームが残りを処理します。

151

152### レイヤー3：CI/CD の標準化

153

154各チームが独自のパイプラインを構築しなくて済むよう、CI/CD を標準化します。

155

156```yaml

157# .github/workflows/platform-ci.yml

158# Teams just include the shared workflow

159name: Build and Deploy

160on:

161 push:

162 branches: [main]

163

164jobs:

165 pipeline:

166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2

167 with:

168 language: node

169 deploy-target: production

170 secrets: inherit

171```

172

173**主要なプラクティス：**

174- チームがインクルード（コピーではなく）する共有 CI/CD テンプレート

175- 自動セキュリティスキャン（SAST、依存関係監査）

176- 標準化されたデプロイメント戦略（カナリア、ブルー/グリーン）

177- ヘルスチェック失敗時の自動ロールバック

178

179### レイヤー4：オブザーバビリティ

180

181事前設定されたモニタリングにより、開発者はすぐに使えるダッシュボードとアラートを取得できます。

182

183- **メトリクス**：Prometheus + Grafana、サービスごとの標準ダッシュボード

184- **ロギング**：集中収集による構造化ロギング（Loki、ELK）

185- **トレーシング**：OpenTelemetry による分散トレーシング

186- **アラート**：合理的なデフォルトによる PagerDuty/Opsgenie 連携

187

188```mermaid

189graph LR

190 Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]

191 Collector --> Prometheus[Prometheus]

192 Collector --> Loki[Loki]

193 Collector --> Tempo[Tempo]

194 Prometheus --> Grafana[Grafana Dashboards]

195 Loki --> Grafana

196 Tempo --> Grafana

197 Grafana --> PagerDuty[PagerDuty Alerts]

198```

199

200## 成功の測定

201

202プラットフォームが機能しているかどうかをどう判断しますか？以下のメトリクスを追跡しましょう：

203

204### DORA メトリクス

205- **デプロイ頻度**：コードが本番環境に到達する頻度

206- **変更のリードタイム**：コミットから本番環境までの時間

207- **変更失敗率**：障害を引き起こすデプロイメントの割合

208- **平均復旧時間**：インシデント後にサービスを復旧するまでの時間

209

210### プラットフォーム固有のメトリクス

211- **初回デプロイまでの時間**：「新しいサービス」から最初の本番デプロイまでの所要時間

212- **開発者満足度（NPS）**：ユーザーに定期的にアンケート

213- **セルフサービス率**：チケットなしで処理されるインフラリクエストの割合

214- **ゴールデンパス採用率**：推奨パスに従うサービスの割合

215

216## よくある間違い

217

218### 1. 早すぎる段階で作りすぎる

219壮大なビジョンではなく、最大のペインポイントから始めましょう。デプロイメントが苦痛なら、そこから始めます。プロビジョニングに数週間かかるなら、そこから始めます。

220

221### 2. プラットフォームをプロダクトとして扱わない

222プラットフォームチームにはプロダクトマネージャー、ユーザーリサーチ、フィードバックループが必要です。開発者はあなたの顧客です - - 彼らのニーズを理解しましょう。

223

224### 3. 引き付けるのではなく強制する

225最良のプラットフォームは、開発者の生活を楽にするため自発的に採用されます。使用を強制しなければならないなら、プラットフォームが十分に良くないということです。

226

227### 4. 開発者体験を無視する

228UX がひどいプラットフォームは使われません。明確なドキュメント、役立つエラーメッセージ、迅速なフィードバックループに投資しましょう。

229

230## はじめに

231

232最初の IDP を構築するための実践的なロードマップ：

233

234```mermaid

235flowchart TD

236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]

237 B --> C[Month 5-6: Iterate]

238 C --> D[Month 7+: Scale]

239

240 A --> A1[Interview developers]

241 A --> A2[Map pain points]

242 A --> A3[Choose first golden path]

243

244 B --> B1[Deploy Backstage]

245 B --> B2[First service template]

246 B --> B3[Standardized CI/CD]

247

248 C --> C1[Gather feedback]

249 C --> C2[Add infrastructure abstraction]

250 C --> C3[Improve docs and onboarding]

251

252 D --> D1[More templates and golden paths]

253 D --> D2[Self-service infrastructure]

254 D --> D3[Advanced observability]

255```

256

257### 最小限の実用的なプラットフォーム

258

2591. **サービスカタログ**（Backstage） - - 何が存在し、誰がオーナーかを把握

2602. **1つのサービステンプレート** - - 最も一般的なサービスタイプのゴールデンパス

2613. **標準化された CI/CD** - - チームがインクルードする共有パイプライン

2624. **基本的なドキュメント** - - プラットフォームの使い方、ヘルプの入手先

263

264この MVP は 2-3 名のエンジニアチームで 2-3 か月で構築できます。

265

266## まとめ

267

268Platform Engineering は初日から完璧なプラットフォームを構築することではありません。開発者の認知負荷を段階的に軽減し、プロダクト構築に集中できるようにすることです。小さく始め、影響を測定し、開発者のフィードバックに基づいて反復しましょう。

269

270Platform Engineering に投資する組織は、大きな競争優位性を持つことになります：より速いデリバリー、より幸せな開発者、そしてより信頼性の高いシステム。

271

272**リソース：**

273- [Team Topologies](https://teamtopologies.com/) - - プラットフォームチームを普及させた書籍

274- [Backstage](https://backstage.io/) - - Spotify のオープンソース開発者ポータル

275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - - コミュニティによる定義とベストプラクティス

276- [platformengineering.org](https://platformengineering.org/) - - コミュニティ、イベント、リソース

277