ストーリー
田
田中VPoE
IDP概要、Backstage、サービスカタログ、スキャフォールディング。IDPの構成要素を一通り学んだ。実際にCloudOps社のIDPを設計してもらう
あなた
Backstageベースで、25マイクロサービスを管理するIDPですね
あ
田
田中VPoE
そうだ。サービスカタログの設計からテンプレートの定義、ヘルススコアカードの設計まで、IDPの全体像を設計してくれ
あなた
開発者が「これさえ見れば何でもわかる」ポータルにします
あ
田
田中VPoE
いい心構えだ。ただし、最初から完璧を目指す必要はない。TVPの原則を忘れるな。Phase 1で最も価値のある機能を特定し、そこに集中する
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | Internal Developer Portalの設計 |
| 想定時間 | 90分 |
| 成果物 | IDP設計書(カタログ + テンプレート + スコアカード) |
| 対象組織 | CloudOps社(Step 1から継続) |
Mission 1: サービスカタログの設計
要件
CloudOps社の25マイクロサービスを管理するサービスカタログを設計してください。
- データモデル(Domain、System、Component、API、Resource)を定義する
- 代表的なサービス3つのcatalog-info.yamlを記述する
- ヘルススコアカードの項目と配点を設計する
解答例
データモデル
| Domain | System | Components | APIs |
|---|
| Payments | payment-system | payment-service, payment-worker | payment-api |
| Users | user-system | user-service, auth-service | user-api, auth-api |
| Notifications | notification-system | notification-service, email-worker | notification-api |
| Analytics | analytics-system | analytics-service, report-service | analytics-api |
| Platform | platform-system | api-gateway, config-service | gateway-api |
catalog-info.yaml(payment-service)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: "決済処理のコアサービス。Stripe/PayPay連携、課金管理を担当"
tags: [typescript, nestjs, production, tier-1]
annotations:
github.com/project-slug: cloudops/payment-service
backstage.io/techdocs-ref: dir:.
datadoghq.com/service-name: payment-service
argocd/app-name: payment-service
spec:
type: service
lifecycle: production
owner: payment-team
system: payment-system
providesApis: [payment-api]
consumesApis: [user-api, notification-api]
dependsOn: [resource:payment-db, resource:payment-redis]
ヘルススコアカード
| カテゴリ | 項目 | 配点 | 自動チェック方法 |
|---|
| オーナーシップ | ownerが設定されている | 10 | catalog-info.yaml |
| ドキュメント | TechDocs存在 + 3ヶ月以内更新 | 10 | GitHubファイル確認 |
| API仕様 | OpenAPI定義あり | 10 | catalog-info.yaml |
| CI/CD | パイプラインが設定・稼働 | 10 | GitHub Actions API |
| テスト | カバレッジ70%以上 | 10 | CI実行結果 |
| セキュリティ | SAST有効 + Critical 0件 | 15 | Semgrep結果 |
| 監視 | SLO定義 + アラート設定 | 15 | Datadog API |
| 依存関係 | 依存パッケージが最新-2以内 | 10 | Dependabot結果 |
| デプロイ | Golden Path準拠 | 10 | GitOps設定確認 |
Mission 2: ソフトウェアテンプレートの設計
要件
CloudOps社で使用するソフトウェアテンプレートを設計してください。
- テンプレート一覧(最低4種類)と各テンプレートの概要を定義する
- 最も利用頻度が高いテンプレートのtemplate.yamlを記述する
- テンプレートから生成されるスケルトンコードのディレクトリ構成を設計する
解答例
テンプレート一覧
| テンプレート | 用途 | 含まれるもの | 優先度 |
|---|
| typescript-api | REST APIサービス | NestJS, Prisma, Jest, Docker, k8s, CI/CD | Phase 1 |
| typescript-worker | バックグラウンドワーカー | NestJS, SQS, DLQ, Docker, k8s | Phase 1 |
| react-web | Webフロントエンド | Next.js, Storybook, Cypress | Phase 1 |
| python-ml | ML推論サービス | FastAPI, PyTorch, Docker, k8s | Phase 2 |
| documentation | ドキュメントサイト | MkDocs Material, TechDocs | Phase 2 |
template.yaml(typescript-api)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: typescript-api-service
title: TypeScript APIサービス
description: "NestJS + Prisma のREST APIサービス"
spec:
owner: platform-team
type: service
parameters:
- title: サービス情報
required: [name, owner]
properties:
name:
title: サービス名
type: string
pattern: "^[a-z][a-z0-9-]{2,30}$"
owner:
title: オーナー
type: string
ui:field: OwnerPicker
- title: オプション
properties:
database:
title: データベース
type: string
enum: [none, postgresql, redis, both]
default: none
size:
title: サイズ
type: string
enum: [small, medium, large]
default: small
steps:
- id: generate
name: コード生成
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
- id: publish
name: リポジトリ作成
action: publish:github
input:
repoUrl: github.com?owner=cloudops&repo=${{ parameters.name }}
- id: argocd
name: Argo CD登録
action: argocd:create-application
input:
appName: ${{ parameters.name }}
- id: register
name: カタログ登録
action: catalog:register
input:
repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
catalogInfoPath: /catalog-info.yaml
ディレクトリ構成
${{ values.name }}/
├── src/
│ ├── domain/
│ ├── application/
│ ├── adapters/
│ ├── app.module.ts
│ └── main.ts
├── test/
├── docs/index.md
├── k8s/platform.yaml
├── catalog-info.yaml
├── Dockerfile
├── .github/workflows/ci.yaml
├── package.json
└── README.md
Mission 3: IDP導入ロードマップ
要件
CloudOps社のIDP導入ロードマップを策定してください。
- 3フェーズの導入計画(各フェーズの機能、期間、成功指標)を定義する
- 導入のリスクと対策を3つ以上特定する
- 開発者への展開戦略(Opt-inアプローチ)を設計する
解答例
3フェーズ導入計画
| フェーズ | 期間 | 機能 | 成功指標 |
|---|
| Phase 1 | 1-2ヶ月 | サービスカタログ(25サービス登録)、検索 | カタログ登録率100%、週次アクセス数50+ |
| Phase 2 | 3-4ヶ月 | テンプレート3種、TechDocs、セルフサービスDB | テンプレート利用率80%、新規サービス作成時間10分以内 |
| Phase 3 | 5-6ヶ月 | ヘルススコア、コスト可視化、全セルフサービス | 平均ヘルススコア70+、セルフサービス率80% |
リスクと対策
| リスク | 影響 | 対策 |
|---|
| catalog-info.yamlの情報が古くなる | IDPの信頼性低下 | CI/CDで情報鮮度チェック、スコアカードで可視化 |
| 開発者が使わない | 投資の無駄 | Opt-inアプローチ、アーリーアダプター3チームから開始 |
| Backstageのアップデート追従 | 技術的負債 | 月次アップデートサイクルの確立、E2Eテスト |
展開戦略
| 段階 | 対象 | 施策 |
|---|
| Week 1-2 | payment-team(アーリーアダプター) | 1対1で導入支援、フィードバック収集 |
| Week 3-4 | user-team, notification-team | 成功事例を共有、ハンズオンセッション |
| Month 2 | 全チーム | 全体向けデモ、ドキュメント整備 |
| Month 3+ | 自然拡大 | テンプレート利用の利便性で自発的採用 |
達成度チェック
| 観点 | 達成基準 |
|---|
| サービスカタログ | データモデルが設計され、catalog-info.yamlが記述できている |
| ヘルススコア | 自動チェック項目と配点が定義されている |
| テンプレート | 4種類以上のテンプレートが定義され、template.yamlが記述できている |
| 導入ロードマップ | 3フェーズの計画、リスク対策、展開戦略がある |
| 実現可能性 | CloudOps社の技術スタックとチーム規模に適合している |
推定所要時間: 90分