Backstage+Crossplane+ArgoCDで構築するPlatform Engineeringの設計と導入
この記事でわかること
- Platform Engineeringの基本概念と、なぜ従来のDevOpsだけでは開発者体験が向上しないのか
- Backstage・Crossplane・ArgoCDの「Golden Triangle」アーキテクチャでIDP（内部開発者プラットフォーム）を設計する方法
- Crossplane CompositionとBackstage Software Templateを組み合わせたセルフサービスインフラ構築の実装例
- Golden Path（推奨パス）の設計原則と、開発者の認知負荷を40〜50%削減するための戦略
- DORA・SPACEメトリクスによるPlatform Engineering導入効果の測定手法
対象読者
- 想定読者: Kubernetesの基本操作を理解しているMLエンジニア・インフラエンジニア
-
必要な前提知識:
- Kubernetes v1.28以降の基本操作（
kubectl apply、マニフェスト作成） - YAML記法の基礎
- GitOpsの概念（Gitリポジトリを信頼できる唯一の情報源として扱う考え方）
- Helmチャートの基本的な利用経験
- Kubernetes v1.28以降の基本操作（
結論・成果
Platform Engineeringを導入した組織では、Gartnerの調査によると開発者のセルフサービス率が向上し、インフラリクエストのチケット待ち時間が数日から数分に短縮されたと報告されています。Backstage+Crossplane+ArgoCDの「Golden Triangle」構成により、開発者はKubernetesのマニフェストやクラウドAPIの詳細を意識せず、Backstageのカタログからワンクリックでインフラをプロビジョニングできるようになります。
Jellyfish社の調査では、成熟したPlatformチームが開発者の認知負荷を40〜50%削減し、Developer Experience Index（DXI）で1ポイント改善するごとに開発者1人あたり週13分の時間節約、100人規模の組織で年間約$100Kのコスト削減効果があると報告されています。
Platform Engineeringの基礎を理解する
DevOpsとPlatform Engineeringの違い
DevOpsは「開発チームと運用チームの壁を取り払う」という文化的ムーブメントとして広まりました。しかし実際には、各開発チームがCI/CDパイプライン、Kubernetesマニフェスト、モニタリング設定などを個別に構築・管理する状況が生まれ、「全員がインフラも担当する」という認知負荷の増大を招いたケースが多く報告されています。
Platform Engineeringは、この問題に対して社内向けの製品（Internal Developer Platform: IDP）を構築するアプローチで対処します。Platformチームがインフラの複雑さを抽象化し、開発者にはセルフサービスのインターフェースだけを提供します。
| 観点 | 従来のDevOps | Platform Engineering |
|---|---|---|
| インフラ管理 | 各チームが個別に管理 | Platformチームが共通基盤を提供 |
| 開発者体験 | ツール選定から自力で実施 | Golden Pathで推奨構成を提供 |
| 認知負荷 | 全員がKubernetes/IaCを理解 | 必要な抽象レベルのみ公開 |
| ガバナンス | チームごとにバラバラ | Policy-as-Codeで統一 |
| スケーラビリティ | チーム数に比例して複雑化 | プラットフォームが吸収 |
IDP（内部開発者プラットフォーム）とは
IDP（Internal Developer Platform）は、開発者がコードのデプロイやインフラリクエストなどの日常的な作業をセルフサービスで実行できるようにする、標準化されたツールと技術の集合体です。Red Hatの定義によると、IDPは技術的な複雑さを抽象化し、開発者の認知負荷を削減することを目的としています。
IDPには「Developer Portal」（Backstageなど）と「Developer Platform」（Crossplane + ArgoCDなど）の2つの側面があります。Portalはカタログ・ドキュメント・テンプレートを提供するUIレイヤーで、Platformはインフラプロビジョニング・デプロイ・ポリシー適用を担うバックエンドレイヤーです。
注意: IDPは「Internal Developer Portal」と「Internal Developer Platform」の2つの意味で使われることがあります。Portalは情報の集約とUI提供、Platformはインフラ自動化とセルフサービスを指します。本記事では両者を含む「プラットフォーム」の意味でIDPを使用します。
Platform as a Productの考え方
Platform Engineeringで最も重要な原則は、プラットフォームを社内製品として扱うことです。InfoWorldが報告する8つのアンチパターンの筆頭に「プロダクト思考の欠如」が挙げられています。
具体的には以下の実践を意味します。
- ユーザーリサーチ: 開発者へのインタビューとアンケートで課題を把握
- プロダクトロードマップ: 四半期ごとの機能追加計画を公開
- ドッグフーディング: Platformチーム自身がプラットフォームの最初のユーザーになる
- NPS測定: 四半期ごとに開発者満足度を計測し、改善サイクルを回す
よくある間違い: 最初は「既存のインフラチームをPlatform Engineeringチームにリブランディングすればよい」と考えがちですが、実際にはプロダクトマネージャーの役割を含むチーム構成が必要です。技術だけでなく、ユーザーリサーチやフィードバックループの設計が成功の鍵になります。
Golden Triangleアーキテクチャを設計する
Backstage・ArgoCD・Crossplaneを組み合わせた「Golden Triangle」は、CNCF（Cloud Native Computing Foundation）プロジェクトを中心としたIDP構築の定番アーキテクチャとして2025〜2026年に広く採用されています。
Backstage: 開発者ポータルを構築する
BackstageはSpotifyが開発しオープンソース化した開発者ポータルフレームワークです。CNCFのIncubatingプロジェクトであり、組織を横断したソフトウェアのカタログ管理、テンプレートによるプロジェクト作成、ドキュメント集約を1つのUIで提供します。2026年時点で、IDPを導入した組織の約89%がBackstageを採用しているとRoadie社のレポートで報告されています。
Backstageの核となる機能はSoftware Template（Scaffolder）です。開発者がUIから必要なパラメータを入力すると、テンプレートに基づいてGitリポジトリの作成、Kubernetesマニフェストの生成、カタログへの登録を自動実行します。
以下は、PostgreSQLデータベースをCrossplane経由でプロビジョニングするBackstage Software Templateの例です。
# backstage-templates/postgres-database/template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: provision-postgres
title: PostgreSQL Database Provisioning
description: Crossplane経由でRDS PostgreSQLインスタンスを作成します
tags:
- database
- postgresql
- crossplane
spec:
owner: platform-team
type: resource
# 開発者が入力するパラメータ定義
parameters:
- title: Database Configuration
required:
- name
- environment
properties:
name:
title: Database Name
type: string
description: データベースの識別名
pattern: "^[a-z][a-z0-9-]{2,28}[a-z0-9]$"
environment:
title: Environment
type: string
enum:
- development
- staging
- production
description: デプロイ先環境
instanceSize:
title: Instance Size
type: string
default: small
enum:
- small # db.t3.micro
- medium # db.t3.small
- large # db.r6g.large
description: インスタンスサイズ（本番はmedium以上推奨）
storageGB:
title: Storage Size (GB)
type: integer
default: 20
minimum: 20
maximum: 1000
# テンプレートの実行ステップ
steps:
# Crossplane Claimマニフェストを生成してGitリポジトリにpush
- id: create-claim
name: Generate Crossplane Claim
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
environment: ${{ parameters.environment }}
instanceSize: ${{ parameters.instanceSize }}
storageGB: ${{ parameters.storageGB }}
- id: publish
name: Push to GitOps Repository
action: publish:github:pull-request
input:
repoUrl: github.com?repo=infra-gitops&owner=my-org
title: "feat: provision PostgreSQL ${{ parameters.name }}"
branchName: "provision-db-${{ parameters.name }}"
description: |
Crossplane経由でPostgreSQL (${{ parameters.environment }}) を作成
# Backstageカタログに登録
- id: register
name: Register in Catalog
action: catalog:register
input:
catalogInfoUrl: https://github.com/my-org/infra-gitops/blob/main/databases/${{ parameters.name }}/catalog-info.yaml
なぜBackstageを選んだか:
- CNCF Incubatingプロジェクトとして活発にメンテナンスされている
- プラグインエコシステムが豊富（2026年時点で200以上の公開プラグイン）
- Software TemplateのScaffolderにより、任意のワークフローをノーコードで定義可能
- 他のIDPツール（Port、Cortexなど）と比較してベンダーロックインが少ない
注意: Backstageは柔軟性が高い反面、初期構築に一定の工数が必要です。Roadie社のレポートでは「DIYでのBackstage構築は運用コストが想定以上にかかる」と指摘されており、小規模チーム（10人以下）の場合はマネージドBackstageサービス（Roadie、Cortex等）の検討も有効です。
Crossplane: Kubernetesネイティブのインフラプロビジョニング
Crossplaneは、Kubernetes APIを通じてクラウドリソースをプロビジョニングするCNCF Graduatedプロジェクトです。2025年11月にCNCFを卒業し、成熟度と広範な採用が認められました。
Crossplaneの核心はCompositionという仕組みです。複数のクラウドリソース（例: RDSインスタンス + セキュリティグループ + サブネットグループ）を1つのカスタムリソースとして抽象化し、開発者には簡潔なインターフェースだけを公開します。
まず、XRD（CompositeResourceDefinition）で開発者向けのAPIを定義します。
# crossplane/xrd-postgres.yaml
apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
name: postgresinstances.database.example.com
spec:
group: database.example.com
names:
kind: PostgresInstance
plural: postgresinstances
# Namespaced scopeで開発者がClaimとして利用可能
claimNames:
kind: PostgresClaim
plural: postgresclaims
versions:
- name: v1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
# 開発者が指定するパラメータ（最小限に抑える）
environment:
type: string
enum: ["development", "staging", "production"]
storageGB:
type: integer
default: 20
minimum: 20
maximum: 1000
instanceSize:
type: string
enum: ["small", "medium", "large"]
default: "small"
required:
- environment
status:
type: object
properties:
endpoint:
type: string
port:
type: integer
status:
type: string
次に、Compositionで実際のAWSリソースへのマッピングを定義します。
# crossplane/composition-postgres-aws.yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: postgres-aws
labels:
provider: aws
database: postgresql
spec:
compositeTypeRef:
apiVersion: database.example.com/v1
kind: PostgresInstance
mode: Pipeline
pipeline:
- step: patch-and-transform
functionRef:
name: crossplane-contrib-function-patch-and-transform
input:
apiVersion: pt.fn.crossplane.io/v1beta1
kind: Resources
resources:
# RDS SubnetGroup
- name: subnet-group
base:
apiVersion: rds.aws.upbound.io/v1beta1
kind: SubnetGroup
spec:
forProvider:
region: ap-northeast-1
subnetIds:
- subnet-xxxxxxxxx
- subnet-yyyyyyyyy
tags:
managed-by: crossplane
# RDS Instance
- name: rds-instance
base:
apiVersion: rds.aws.upbound.io/v1beta2
kind: Instance
spec:
forProvider:
region: ap-northeast-1
engine: postgres
engineVersion: "16.4"
autoMinorVersionUpgrade: true
backupRetentionPeriod: 7
deletionProtection: true
storageEncrypted: true
# パスワードはKubernetes Secretから参照
passwordSecretRef:
name: db-master-password
namespace: crossplane-system
key: password
patches:
# instanceSizeに基づくインスタンスクラスのマッピング
- type: FromCompositeFieldPath
fromFieldPath: spec.instanceSize
toFieldPath: spec.forProvider.instanceClass
transforms:
- type: map
map:
small: db.t3.micro
medium: db.t3.small
large: db.r6g.large
# storageGBのマッピング
- type: FromCompositeFieldPath
fromFieldPath: spec.storageGB
toFieldPath: spec.forProvider.allocatedStorage
# ステータスへのエンドポイント書き戻し
- type: ToCompositeFieldPath
fromFieldPath: status.atProvider.endpoint
toFieldPath: status.endpoint
開発者は以下の簡潔なClaimだけを書けばデータベースが作成されます。
# 開発者が書くのはこれだけ
apiVersion: database.example.com/v1
kind: PostgresClaim
metadata:
name: my-app-db
namespace: team-alpha
spec:
environment: staging
instanceSize: medium
storageGB: 50
制約条件: Crossplaneは強力ですが、すべてのクラウドリソースをサポートしているわけではありません。AWSプロバイダー（upbound/provider-aws）はほとんどのサービスをカバーしていますが、新しいAWSサービスへの対応には数週間のラグがあります。また、Compositionのデバッグは複雑で、crossplane beta traceコマンドによるリソース依存関係の追跡が必要になる場面があります。
ArgoCD: GitOpsでデプロイを自動化する
ArgoCDは、Gitリポジトリの状態をKubernetesクラスタに自動同期するGitOpsコントローラーです。CNCF Graduatedプロジェクトであり、Gitに格納されたマニフェストを「Single Source of Truth」としてクラスタの状態を宣言的に管理します。
Golden Triangleにおいて、ArgoCDは以下の役割を担います。
- Backstageが生成したマニフェストの自動デプロイ: Backstage TemplateがGitリポジトリにpushしたCrossplane Claimを自動検知し、クラスタに適用
- ドリフト検知: クラスタの実態とGitの宣言の差分を検知・修正
- マルチクラスタ管理: 複数のKubernetesクラスタへのデプロイを一元管理
# argocd/application-infra.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: infra-crossplane-claims
namespace: argocd
spec:
project: platform
source:
repoURL: https://github.com/my-org/infra-gitops
targetRevision: main
path: crossplane-claims/
directory:
recurse: true
destination:
server: https://kubernetes.default.svc
namespace: crossplane-system
syncPolicy:
automated:
prune: true # Git上で削除されたリソースはクラスタからも削除
selfHeal: true # 手動変更を自動的にGitの状態に戻す
syncOptions:
- CreateNamespace=true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
トレードオフ: ArgoCDのselfHeal: trueは強力ですが、緊急時のホットフィックス（直接kubectl editする運用）が無効化されます。本番環境ではselfHealを有効にしつつ、緊急時の一時停止手順（argocd app pause-sync相当）を運用マニュアルに含める必要があります。
Golden Pathを設計して開発者体験を向上させる
Golden Pathとは
Golden Path（推奨パス）は、プラットフォームが提供する「最も推奨される開発・デプロイの道筋」です。Red Hatの定義によると、Golden Pathは開発者の日常的な作業（クラウドへのデプロイ、他チームへのサービスリクエストなど）をセルフサービスで実行できるようにするものです。
重要なのは、Golden Pathは強制ではなくガイドレールであることです。開発者は推奨パスから外れることもできますが、推奨パスに従えば「セキュリティ・コンプライアンス・監視がデフォルトで組み込まれた」環境を得られます。
Golden Path設計の5原則
Golden Pathを設計する際に守るべき5つの原則を紹介します。
1. 90%ルール: ユースケースの90%をカバーすることを目指し、残り10%のエッジケースは個別対応とする。Xebia社の報告では、この割り切りがプラットフォームの複雑さを指数的に削減すると述べられています。
2. Composability（構成可能性）: テンプレートは組み合わせ可能な小さなモジュールとして設計する。「Webアプリ + PostgreSQL + Redis」のように、必要なコンポーネントを選択して組み合わせられるようにします。
3. Escape Hatch（脱出口）: Golden Pathに従えないケースのために、手動設定やカスタムCompositionへの移行パスを用意する。
4. Progressive Disclosure（段階的開示）: 初期設定では最小限のパラメータだけを表示し、詳細設定は「Advanced」セクションに隠す。Backstage TemplateのJSONスキーマで実現できます。
5. Feedback Loop（フィードバックループ）: テンプレートの利用率・完了率・エラー率を計測し、四半期ごとに改善する。
ハマりポイント: Golden Pathのテンプレート数を増やしすぎると、開発者がどれを選べばよいか分からなくなる「Choice Paralysis（選択のパラドックス）」が発生します。最初は3〜5個のテンプレートから始め、利用データに基づいて段階的に追加するのが効果的です。
セルフサービスフローの実装例
Backstage TemplateからCrossplane経由でインフラをプロビジョニングし、ArgoCDが自動デプロイするフローを実装してみましょう。
以下は、開発者がBackstage UIから新規マイクロサービスを作成する際のテンプレート例です。
# backstage-templates/microservice/template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: create-microservice
title: Create New Microservice
description: |
Golden Path: Kubernetes上にデプロイされる
マイクロサービスの雛形を作成します
spec:
owner: platform-team
type: service
parameters:
- title: Service Details
required:
- serviceName
- owner
properties:
serviceName:
title: Service Name
type: string
pattern: "^[a-z][a-z0-9-]{2,30}[a-z0-9]$"
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
ui:options:
catalogFilter:
kind: Group
language:
title: Language
type: string
default: python
enum:
- python
- typescript
- go
description:
title: Description
type: string
- title: Infrastructure
properties:
needsDatabase:
title: PostgreSQL Database
type: boolean
default: false
needsRedis:
title: Redis Cache
type: boolean
default: false
environment:
title: Initial Environment
type: string
default: development
enum:
- development
- staging
steps:
# アプリケーションコードのスキャフォールディング
- id: fetch-skeleton
name: Fetch Service Skeleton
action: fetch:template
input:
url: ./skeletons/${{ parameters.language }}
values:
serviceName: ${{ parameters.serviceName }}
owner: ${{ parameters.owner }}
description: ${{ parameters.description }}
# Crossplane Claimの生成（DB/Redisが必要な場合）
- id: generate-infra
name: Generate Infrastructure Claims
action: fetch:template
input:
url: ./infra-claims
values:
serviceName: ${{ parameters.serviceName }}
needsDatabase: ${{ parameters.needsDatabase }}
needsRedis: ${{ parameters.needsRedis }}
environment: ${{ parameters.environment }}
# GitHubリポジトリの作成
- id: publish
name: Create GitHub Repository
action: publish:github
input:
repoUrl: github.com?repo=${{ parameters.serviceName }}&owner=my-org
defaultBranch: main
protectDefaultBranch: true
repoVisibility: internal
# Backstageカタログに登録
- id: register
name: Register Component
action: catalog:register
input:
repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
catalogInfoPath: /catalog-info.yaml
output:
links:
- title: Repository
url: ${{ steps.publish.output.remoteUrl }}
- title: Open in Backstage
icon: catalog
entityRef: ${{ steps.register.output.entityRef }}
このテンプレートが実行されると、以下が自動的に行われます。
- 選択した言語のボイラープレートコードを含むGitHubリポジトリが作成される
- DBやRedisが必要な場合、Crossplane Claimがリポジトリに含まれる
- ArgoCDが新しいリポジトリを検知し、Kubernetesへデプロイする
- Backstageカタログにサービスが登録され、オーナーやドキュメントが紐付く
アンチパターンを回避してPlatform Engineeringを成功させる
Platform Engineeringの導入には多くの落とし穴があります。InfoWorldの報告する8つのアンチパターンとserce.meの「Six Sins of Platform Teams」から、特に重要な4つを紹介します。
アンチパターン1: Big-Bang導入
問題: プラットフォーム全体を一度に構築・リリースしようとすること。完成までに6〜12ヶ月かかり、リリース時には開発者のニーズが変わっている。
対策: MVPアプローチを採用する。最初は最も痛みの大きい1つのユースケース（例: データベースのプロビジョニング）だけを自動化し、開発者のフィードバックを得てから拡張する。
# 段階的導入のロードマップ例
# platform_roadmap.py
phases = {
"Phase 1 (Month 1-2)": {
"goal": "最初のGolden Pathを1つ提供",
"deliverables": [
"Backstage初期セットアップ",
"PostgreSQL Crossplane Composition",
"ArgoCD GitOps設定",
],
"success_metric": "3チーム以上がセルフサービスでDB作成",
"anti_pattern": "全インフラをカバーしようとしない",
},
"Phase 2 (Month 3-4)": {
"goal": "マイクロサービステンプレート追加",
"deliverables": [
"言語別スキャフォールディング",
"CI/CDパイプライン自動生成",
"監視ダッシュボード自動作成",
],
"success_metric": "新規サービス作成の80%がテンプレート経由",
},
"Phase 3 (Month 5-6)": {
"goal": "ガバナンスとセキュリティの統合",
"deliverables": [
"OPA/Kyverno Policy-as-Code",
"コスト可視化ダッシュボード",
"セキュリティスキャン自動化",
],
"success_metric": "セキュリティ監査指摘事項ゼロ",
},
}
# 各フェーズのKPI追跡
def calculate_adoption_rate(
self_service_requests: int, total_requests: int
) -> float:
"""セルフサービス率 = セルフサービスリクエスト / 全リクエスト"""
if total_requests == 0:
return 0.0
return (self_service_requests / total_requests) * 100
アンチパターン2: プロダクト思考の欠如
問題: プラットフォームを「インフラチームの内部ツール」として構築し、開発者のフィードバックを集めない。技術的に優れていても、開発者が使いたいと思わないプラットフォームになる。
対策: Platformチームにプロダクトマネージャーを配置し、開発者の痛みを定期的にヒアリングする。JellyFish社の推奨する17のメトリクスのうち、NPS（Net Promoter Score）と利用率を最低限追跡する。
アンチパターン3: 全ユースケースへの対応
問題: 全チームの全要件に対応しようとして、プラットフォームが複雑化する。Xebia社の報告では「最後の10%が複雑さを指数的に増加させる」と警告されています。
対策: 前述の90%ルールを厳守する。標準外の要件には、Crossplane Compositionのカスタマイズポイント（パラメータの追加）で対応し、Composition自体の分岐は避ける。
アンチパターン4: 単一障害点の人依存
問題: 数人のDevOpsエキスパートにプラットフォームの知識が集中し、その人が離職すると運用が破綻する。
対策: ドキュメント駆動開発を徹底する。BackstageのTechDocsプラグインを活用し、すべてのCompositionとTemplateにドキュメントを自動生成する。また、ペアプログラミングやローテーションで知識を分散させる。
| アンチパターン | 症状 | 対策 | 測定指標 |
|---|---|---|---|
| Big-Bang導入 | リリースが遅延し続ける | MVP + 段階的拡張 | Time to First User |
| プロダクト思考の欠如 | 利用率が上がらない | PM配置 + NPS測定 | NPS、月間アクティブユーザー |
| 全ユースケース対応 | Compositionが複雑化 | 90%ルール | テンプレート数、Composition行数 |
| 人依存 | 特定メンバー不在で障害対応不能 | TechDocs + ローテーション | ドキュメントカバレッジ率 |
DORA・SPACEメトリクスで導入効果を測定する
Platform Engineeringの効果は、感覚ではなくデータで示す必要があります。2025年のState of Platform Engineering Reportでは、40.9%のプラットフォーム施策が初年度に測定可能な価値を示せなかったと報告されています。適切なメトリクス設計が不可欠です。
DORAメトリクスの活用
DORAメトリクスは、ソフトウェアデリバリのパフォーマンスを測定する業界標準フレームワークです。採用率40.8%で最も広く使われています。
| メトリクス | 説明 | エリートチームの基準 | Platform Engineering導入後の期待値 |
|---|---|---|---|
| デプロイ頻度 | コードを本番にデプロイする頻度 | オンデマンド（1日複数回） | 週次→日次への改善 |
| 変更リードタイム | コミットから本番稼働までの時間 | 24時間以内 | 数日→数時間への短縮 |
| 変更失敗率 | デプロイ後に障害が発生する割合 | 5%以下 | Golden Pathの標準化で低減 |
| 復旧時間 | 障害発生から復旧までの時間 | 1時間以内 | セルフヒーリング + 自動ロールバックで短縮 |
SPACEフレームワークの補完
DORAメトリクスだけでは開発者体験の全体像を捉えられません。SPACEフレームワーク（Satisfaction、Performance、Activity、Communication、Efficiency）を組み合わせることで、定量的・定性的の両面から評価できます。
# platform_metrics.py
# Platform Engineering効果測定ダッシュボードの構成例
from dataclasses import dataclass
from enum import Enum
class MetricCategory(Enum):
DORA = "dora"
ADOPTION = "adoption"
DEVELOPER_EXPERIENCE = "developer_experience"
BUSINESS_VALUE = "business_value"
@dataclass
class PlatformMetric:
name: str
category: MetricCategory
description: str
target: str
measurement: str
# Platform Engineering推奨メトリクスセット
PLATFORM_METRICS = [
# DORA メトリクス
PlatformMetric(
name="deployment_frequency",
category=MetricCategory.DORA,
description="本番デプロイ頻度",
target="日次以上",
measurement="ArgoCD sync回数 / 日",
),
PlatformMetric(
name="lead_time_for_changes",
category=MetricCategory.DORA,
description="コミットから本番までのリードタイム",
target="24時間以内",
measurement="GitコミットからArgoCD sync完了までの時間",
),
# 採用メトリクス
PlatformMetric(
name="self_service_rate",
category=MetricCategory.ADOPTION,
description="セルフサービスで完了したインフラリクエストの割合",
target="80%以上",
measurement="Backstage Template実行数 / 全インフラリクエスト数",
),
PlatformMetric(
name="time_to_first_deploy",
category=MetricCategory.ADOPTION,
description="新規サービスの初回デプロイまでの時間",
target="30分以内",
measurement="Backstage Template開始からArgoCD初回sync完了まで",
),
# 開発者体験メトリクス
PlatformMetric(
name="developer_nps",
category=MetricCategory.DEVELOPER_EXPERIENCE,
description="プラットフォームに対する開発者NPS",
target="30以上",
measurement="四半期アンケート",
),
PlatformMetric(
name="cognitive_load_score",
category=MetricCategory.DEVELOPER_EXPERIENCE,
description="開発者の認知負荷スコア（1-10）",
target="4以下",
measurement="SPACE frameworkアンケート",
),
# ビジネス価値メトリクス
PlatformMetric(
name="platform_roi",
category=MetricCategory.BUSINESS_VALUE,
description="プラットフォームROI",
target="初年度で200%以上",
measurement="(開発者時間節約額 + インフラ削減額) / Platformチームコスト",
),
]
def calculate_platform_roi(
developer_hours_saved: float,
hourly_rate: float,
infra_savings: float,
platform_team_cost: float,
) -> float:
"""
Platform ROIの算出式（Jellyfish社推奨）
ROI = (開発者時間節約額 + インフラ削減額) / Platformチームコスト
"""
total_savings = (developer_hours_saved * hourly_rate) + infra_savings
if platform_team_cost == 0:
raise ValueError("Platform team cost must be greater than 0")
return (total_savings / platform_team_cost) * 100
メトリクス導入時の注意点
注意: メトリクスの導入初期にありがちな失敗は、「測定すること自体が目的化する」ことです。JellyFish社は17のメトリクスを提示していますが、最初から全てを追跡する必要はありません。まずはセルフサービス率と開発者NPSの2つに絞り、四半期ごとに追加メトリクスを検討することを推奨します。
よくある問題と解決方法
| 問題 | 原因 | 解決方法 |
|---|---|---|
| Backstageの初期構築に時間がかかる | プラグイン選定とカスタマイズの工数が大きい | マネージドBackstage（Roadie等）の検討、または最小構成から開始 |
| Crossplane Compositionのデバッグが困難 | エラーがネストしたリソースの深い階層で発生 |
crossplane beta traceコマンドで依存関係を可視化 |
| ArgoCDの同期が遅い | 大量のリソースを監視している | ApplicationSetでリソースを分割、syncオプションのチューニング |
| 開発者がGolden Pathを使わない | テンプレートが複雑、または要件に合わない | 利用率データに基づくテンプレート改善、ユーザーインタビュー実施 |
| Platformチームがボトルネックになる | リクエスト対応に追われ、プラットフォーム開発が進まない | セルフサービス化の優先、チケット対応のSLA設定 |
| Compositionの変更でリソースが再作成される | CrossplaneのmanagementPolicies設定不足 |
ObserveOnlyポリシーの活用、変更影響のdry-run確認 |
まとめと次のステップ
まとめ:
- Platform Engineeringは、DevOpsの「全員がインフラを管理する」負荷を、社内製品としてのプラットフォームで解決するアプローチ
- Backstage（Developer Portal）+ ArgoCD（GitOps）+ Crossplane（Infrastructure Provisioning）の「Golden Triangle」が2025-2026年のIDP構築の定番構成
- Golden Path設計では90%ルールを守り、段階的に拡張する。Big-Bang導入は失敗の最大要因
- DORA + SPACEメトリクスで効果を定量化し、セルフサービス率と開発者NPSを最優先で追跡する
- プラットフォームは「構築したら終わり」ではなく、継続的なフィードバックループで改善し続ける
次にやるべきこと:
- 現状分析: 開発者へのアンケートで最も痛みの大きいインフラ作業を特定する
- MVPの構築: Backstage + Crossplaneで1つのGolden Path（例: データベースのセルフサービス）を構築する
- メトリクスの設定: セルフサービス率と開発者NPSの計測を開始する
参考
- Backstage公式ドキュメント - Software Templates
- Crossplane公式ドキュメント - Composite Resource Definitions
- ArgoCD公式ドキュメント
- 10 Platform Engineering Predictions for 2026 - platformengineering.org
- 17 Platform Engineering Metrics to Measure Success and ROI - Jellyfish
- 8 Platform Engineering Anti-Patterns - InfoWorld
- Six Sins of Platform Teams - serce.me
- What is a Golden Path for Software Development? - Red Hat
- DORA Metrics Guide - dora.dev
- Platform Engineering in 2026: Why DIY Is Dead - Roadie
- Crossplane CNCF Graduation Announcement
注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。