ストーリー
田
田中VPoE
ここまでプラットフォームの技術面を設計してきた。Step 5では「人と組織」の話をする。プラットフォームチームをどう組織し、運営するか
あなた
技術だけでなく、組織設計も必要なんですね
あ
田
田中VPoE
コンウェイの法則を覚えているか？「組織の構造がシステムの構造を決定する」。プラットフォームの成功は、プラットフォームチームの組織設計にかかっている。Team Topologiesの考え方を使って設計しよう
あなた
Team Topologiesの「Platform Team」ですね
あ
田
田中VPoE
その通り。Platform Teamは他のチーム（Stream-Aligned Team）にセルフサービスのプラットフォームを提供する。ただし、プラットフォームチームの役割は「技術を提供する」だけではない。「開発者を成功させる」ことだ
Team Topologiesとプラットフォームチーム
4つのチームタイプ
| チームタイプ | 役割 | CloudOps社での例 |
|---|---|---|
| Stream-Aligned | ビジネス価値のフローに沿って動く | payment-team, user-team等 |
| Platform | セルフサービスのプラットフォームを提供 | platform-team |
| Enabling | 他チームの能力向上を支援 | SREチーム（一時的に各チームを支援） |
| Complicated Subsystem | 専門知識が必要なサブシステムを担当 | ML基盤チーム（将来） |
インタラクションモード
| モード | 説明 | プラットフォームチームの例 |
|---|---|---|
| X-as-a-Service | セルフサービスで提供 | IDP、テンプレート、セルフサービスカタログ |
| Collaboration | 一時的に密接に協力 | 新チームのオンボーディング支援 |
| Facilitating | 他チームの学習を促進 | ベストプラクティスの共有、ワークショップ |
プラットフォームチームの構成
CloudOps社のプラットフォームチーム（目標構成）
| ロール | 人数 | 責務 |
|---|---|---|
| Platform Product Manager | 1 | ロードマップ管理、開発者ニーズの把握、優先順位決定 |
| Platform Engineer | 3 | IDP開発、テンプレート、セルフサービス機能の実装 |
| SRE / Infrastructure | 2 | Kubernetes、CI/CD、GitOps基盤の運用 |
| Developer Advocate | 1（兼務可） | ドキュメント、ワークショップ、開発者サポート |
段階的なチーム立ち上げ
プラットフォームチームの段階的立ち上げ:
Phase 1（1-3ヶ月）: 3名
├── Platform Engineer × 2（既存インフラチームから異動）
└── SRE × 1（既存SREチームから異動）
目標: サービスカタログ + 最初のテンプレート
Phase 2（4-6ヶ月）: 5名
├── 上記3名
├── Platform Engineer × 1（新規採用）
└── Platform Product Manager × 1（既存PMから異動）
目標: IDP本番稼働 + セルフサービスカタログ
Phase 3（7-12ヶ月）: 7名
├── 上記5名
├── SRE × 1（新規採用）
└── Developer Advocate × 1（兼務）
目標: 全機能展開 + 自律的な運営プラットフォームチームの運営原則
5つの運営原則
| 原則 | 説明 | アンチパターン |
|---|---|---|
| ユーザー中心 | 開発者のニーズから機能を決定 | 技術的興味から機能を開発 |
| プロダクト思考 | バックログ、スプリント、リリースサイクル | 場当たり的な対応 |
| 計測駆動 | メトリクスに基づく改善判断 | 感覚的な優先順位付け |
| ドッグフーディング | 自チームでプラットフォームを使う | 自チームだけ特別な方法を使う |
| 透明性 | ロードマップ、障害情報の公開 | 密室での意思決定 |
プラットフォームチームのスプリント運営
| 活動 | 頻度 | 内容 |
|---|---|---|
| スプリント計画 | 2週間ごと | バックログの優先順位付け、スプリント目標設定 |
| デイリースタンダップ | 毎日 | 進捗確認、ブロッカーの解消 |
| 開発者オフィスアワー | 週1回 | 開発者からの質問・要望を直接受付 |
| プラットフォームレビュー | 月1回 | メトリクスレビュー、ロードマップ更新 |
| 全社デモ | 月1回 | 新機能のデモ、フィードバック収集 |
プラットフォームチームとの関係設計
サポートモデル
サポートの段階:
Tier 0: セルフサービス
├── ドキュメント（TechDocs）
├── FAQ
└── テンプレート・ツール
→ 目標: 80%の問い合わせをTier 0で解決
Tier 1: コミュニティサポート
├── Slackチャンネル（#platform-help）
├── 他の開発者による回答
└── Platform Bot（FAQ自動回答）
→ 目標: 15%の問い合わせをTier 1で解決
Tier 2: プラットフォームチーム
├── 直接サポート
├── ペアリング
└── バグ修正・機能追加
→ 目標: 5%の問い合わせがTier 2に到達「プラットフォームチームの成功は、チケットの数がゼロに近づくことだ。問い合わせが多いのはプラットフォームの品質問題。セルフサービスとドキュメントで解決できる状態が理想だ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| Team Topologies | Platform Teamとして、Stream-Aligned Teamにセルフサービスを提供 |
| チーム構成 | PM、Platform Engineer、SRE、Developer Advocate |
| 運営原則 | ユーザー中心、プロダクト思考、計測駆動、ドッグフーディング、透明性 |
| サポートモデル | Tier 0（セルフサービス）で80%解決を目標 |
チェックリスト
- Team Topologiesにおけるプラットフォームチームの役割を説明できる
- プラットフォームチームの構成と段階的立ち上げを設計できる
- 5つの運営原則を理解した
- サポートモデルの設計方法を把握した
次のステップへ
次は「採用メトリクスと効果測定」を学びます。プラットフォームの成功をどう測定するかを身につけましょう。
推定読了時間: 30分