- Authors
- Name
- はじめに: DevOpsからプラットフォームエンジニアリングへ
- プラットフォームエンジニアリングの核となる原則
- Backstage実装: 実践ガイド
- ゴールデンパスの実装
- インパクト測定: DORAとSPACEメトリクス
- 実例: グローバル金融サービス企業
- 課題と解決策
- 結論: プラットフォームエンジニアリングは必須
- 参考資料

はじめに: DevOpsからプラットフォームエンジニアリングへ
2010年代初頭、DevOpsは革命でした。開発チームと運用チームの分離という問題を解決するために、すべての人が「DevOpsエンジニア」になるべきだと思われていました。しかし10年後、現実は異なっていました。
大規模組織では、開発チームは以下を自分たちで処理する必要がありました:
- Kubernetesクラスターの設定
- CI/CDパイプラインの構築
- モニタリングとロギングシステムの構成
- セキュリティとネットワークポリシーの管理
これはすべて開発者の認知負荷を急増させました。
2026年、プラットフォームエンジニアリングはこの問題を解決しています。核となる考え方は優雅です:
「開発者が基本的なインフラストラクチャ複雑性に対処しないように、プラットフォームチームが『ゴールデンパス』を作成して提供する。」
プラットフォームエンジニアリングの核となる原則
内部開発者ポータル(IDP)の役割
IDPは開発者がセルフサービスで実行できるようにするプラットフォームです:
開発者の視点でのIDP:
IDPポータルにアクセス
↓
「新規マイクロサービス作成」ボタンをクリック
↓
[テンプレート選択] → [言語選択: Python/Go/Java]
↓
[自動生成されるもの]
- Gitリポジトリ
- CI/CDパイプライン
- セキュリティスキャン
- モニタリングダッシュボード
- ロギング収集
- デプロイ権限
- ネットワークポリシー
↓
[開発者の作業] → コード作成だけ (インフラ心配なし)
SpotifyのBackstage フレームワーク
Spotifyが2020年にオープンソース化したBackstageは、現在、最も広く採用されているIDPフレームワークです。2026年現在:
- 導入企業: Fortune 500の45%
- 活発なコミュニティ: 15,000+ 開発者
- プラグイン数: 200個以上
Backstageの核機能:
Backstage コンポーネント:
1. Service Catalog (サービスカタログ)
- 組織のすべてのマイクロサービスの中央レジストリ
- メタデータ: 所有権、依存関係、テックスタック
2. Software Templates (ソフトウェアテンプレート)
- 事前設定されたプロジェクトテンプレート
- 自動生成とデプロイメント
3. TechDocs (技術ドキュメント)
- コードの隣のドキュメント
- 自動生成とホスティング
4. Plugins (プラグインエコシステム)
- CI/CD統合 (GitHub、GitLab、Jenkins)
- モニタリング (Datadog、New Relic)
- コミュニケーション (Slack)
- セキュリティスキャン (Snyk、SonarQube)
Backstage実装: 実践ガイド
ステップ1: インストールと基本設定
# Backstageプロジェクト作成
npx @backstage/create-app@latest my-backstage-app
cd my-backstage-app
# 必須プラグインをインストール
yarn add-all
# ローカルで実行
yarn dev
基本設定ファイル(app-config.yaml):
app:
title: Acme プラットフォームエンジニアリング
baseUrl: http://localhost:3000
backend:
baseUrl: http://localhost:7007
listen:
port: 7007
cors:
origin: http://localhost:3000
database:
client: better-sqlite3
connection: ':memory:'
integrations:
github:
- host: github.com
token: ${GITHUB_TOKEN}
catalog:
import:
entityFilename: catalog-info.yaml
pullRequestBranchName: backstage-entity-update
rules:
- allow: [Component, System, API, Resource, Location]
locations:
# GitHub リポジトリのcatalog-info.yamlを自動検出
- type: url
target: https://github.com/my-org/repos/blob/main/catalog-info.yaml
rules:
- allow: [Component, API]
techdocs:
builder: 'local'
generateStatic: true
publisher:
type: 'local'
ステップ2: サービスカタログの設定
各マイクロサービスのルートにcatalog-info.yamlを作成:
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: 支払い処理マイクロサービス
tags:
- java
- microservice
- critical
annotations:
github.com/project-slug: my-org/payment-service
backstage.io/techdocs-ref: dir:.
spec:
type: service
owner: payment-platform-team
lifecycle: production
dependsOn:
- component:billing-service
- resource:payment-database
consumedBy:
- component:checkout-service
providesApis:
- payment-api
ステップ3: ソフトウェアテンプレート作成
開発者が新しいサービスを簡単に作成できるようにテンプレートを作成:
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: microservice-template
title: マイクロサービス作成
description: 新しいマイクロサービスを作成します
tags:
- recommended
- microservice
spec:
owner: platform-team
type: service
parameters:
- title: 基本情報
required:
- name
- owner
properties:
name:
title: サービス名
type: string
description: マイクロサービスの名前 (snake_case)
ui:autofocus: true
pattern: '^[a-z]+(-[a-z]+)*$'
owner:
title: チーム
type: string
description: サービスを所有するチーム
ui:field: OwnerPicker
ui:options:
allowedKinds:
- Group
description:
title: 説明
type: string
description: サービスの簡潔な説明
maxLength: 200
- title: テクノロジースタック
required:
- language
properties:
language:
title: プログラミング言語
type: string
enum:
- python
- golang
- java
- typescript
default: typescript
framework:
title: フレームワーク
type: string
enum:
- fastapi
- gin
- spring-boot
- express
dependsOn: language
- title: インフラストラクチャ
properties:
setupDatabase:
title: データベースが必要
type: boolean
default: false
databaseType:
title: データベースタイプ
type: string
enum:
- postgresql
- mysql
- mongodb
if:
properties:
setupDatabase:
const: true
required:
- setupDatabase
steps:
- id: fetch-base
name: ベーステンプレートをダウンロード
action: fetch:template
input:
url: ./skeletons/${{ parameters.language }}
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
description: ${{ parameters.description }}
- id: publish
name: GitHubにリポジトリを作成
action: publish:github
input:
allowedHosts: ['github.com']
description: ${{ parameters.description }}
repoUrl: github.com?owner=my-org&repo=${{ parameters.name }}
- id: create-catalog
name: カタログエントリを作成
action: catalog:create
input:
catalogInfoUrl: ${{ steps.publish.output.repoContentsUrl }}/catalog-info.yaml
- id: setup-argocd
name: ArgoCD デプロイメント設定
action: argocd:create-app
input:
appName: ${{ parameters.name }}
argocdInstanceAddress: argocd.company.com
appNamespace: default
repoUrl: ${{ steps.publish.output.repositoryUrl }}
- id: setup-database
name: データベース作成
if: ${{ parameters.setupDatabase }}
action: custom:create-database
input:
serviceName: ${{ parameters.name }}
databaseType: ${{ parameters.databaseType }}
output:
links:
- title: リポジトリを開く
url: ${{ steps.publish.output.repositoryUrl }}
- title: カタログでサービスを表示
url: /catalog/component/${{ steps.catalog.output.entityRef }}
- title: CI/CD パイプライン
url: ${{ steps.publish.output.repositoryUrl }}/actions
ゴールデンパスの実装
ゴールデンパスは、組織が問題を解決することを推奨する「正しい」方法です。
例: マイクロサービス配備のゴールデンパス
従来のパス (以前):
開発 → 手動K8s設定 → 手動デプロイ → 問題発生 → 手動修正
(開発者がすべてを処理)
ゴールデンパス (現在):
開発 → Gitプッシュ → 自動CI/CD → 自動デプロイ → 自動監視 → 自動ロールバック
(プラットフォームがすべてを処理)
インパクト測定: DORAとSPACEメトリクス
プラットフォームエンジニアリングの効果を測定する方法:
DORAメトリクス (4つの主要メトリクス)
class DORAMetrics:
"""
2026年の高パフォーマンスチームのベンチマーク:
"""
# 1. デプロイメント頻度
deployment_frequency = {
'elite': 'オンデマンド (複数回/日)',
'high': '週1-3回',
'medium': '月1回',
'low': '半年または年1回'
}
# 2. 変更のリードタイム
lead_time = {
'elite': '1時間未満',
'high': '1日未満',
'medium': '1か月未満',
'low': '1か月以上'
}
# 3. 平均復旧時間
mttr = {
'elite': '1時間未満',
'high': '1時間-1日',
'medium': '1日-1週',
'low': '1週以上'
}
# 4. 変更失敗率
cfr = {
'elite': '0-15%',
'high': '16-30%',
'medium': '31-45%',
'low': '46-60%'
}
def measure_impact(self):
"""
実装前後の比較 (実データ):
"""
return {
'before_platform_eng': {
'deployment_frequency': 'medium (月1回)',
'lead_time': '2週',
'mttr': '4時間',
'cfr': '35%',
'level': 'medium'
},
'after_platform_eng': {
'deployment_frequency': 'high (週2回)',
'lead_time': '2日',
'mttr': '45分',
'cfr': '12%',
'level': 'high',
'improvements': {
'deployment_frequency': '+200%',
'lead_time': '85%削減',
'mttr': '80%削減',
'cfr': '65%削減'
}
}
}
SPACEメトリクス (開発者生産性)
class SPACEMetrics:
"""
開発者生産性の5つの側面:
"""
dimensions = {
'Satisfaction': {
'description': '開発者の満足度とウェルビーイング',
'measurement': 'アンケート、離職率',
'target': '満足度 4.2/5.0 以上',
'improvement': '+0.8ポイント'
},
'Performance': {
'description': '開発の速度と効率性',
'measurement': 'デプロイ頻度、リードタイム',
'target': 'リードタイム 1週以内',
'improvement': '2週 → 3日'
},
'Activity': {
'description': '開発活動の量',
'measurement': 'コミット、PR、コードレビュー',
'target': '週平均20PR',
'improvement': '+40%'
},
'Collaboration': {
'description': 'チーム間協力の質',
'measurement': 'コードレビュー時間、問題解決時間',
'target': 'PRレビュー 4時間以内',
'improvement': '12時間 → 2時間'
},
'Execution': {
'description': '目標達成と納期遵守',
'measurement': 'スプリント消化率、品質',
'target': 'スプリント消化率 85% 以上',
'improvement': '72% → 88%'
}
}
実例: グローバル金融サービス企業
導入前 (2023年)
課題:
- チームあたり平均2週間をインフラ設定に消費
- セキュリティ規制でデプロイメント遅延
- チーム間での不一貫な実装
- 新開発者のオンボーディングに3か月
プラットフォームエンジニアリング導入 (2024-2025)
Phase 1 (最初の3か月):
- Backstage インストールと設定
- 20個の主要マイクロサービスのカタログ化
- 3つの基本ソフトウェアテンプレート
- プラットフォームチーム構成 (6名)
Phase 2 (次の6か月):
- 50+ マイクロサービスをカタログ化
- 15個のドメイン別テンプレート
- 自動セキュリティスキャン統合
- モニタリング・ロギング自動化
Phase 3 (12か月):
- 組織全体のマイクロサービスをカタログ化 (200+)
- 30+ テンプレート (ドメイン別、テックスタック別)
- AI駆動の自動推奨機能
- 自動SLA追跡
導入後 (2026年)
成果:
- インフラ設定時間: 2週 → 20分 (98%削減)
- デプロイリードタイム: 2週 → 2日 (85%削減)
- 開発者オンボーディング: 3か月 → 2週 (85%削減)
- セキュリティコンプライアンス: 72% → 99%
- デプロイ頻度: 月2回 → 週3回 (650%増加)
- 開発者満足度: 3.2/5.0 → 4.4/5.0
財務影響:
- 開発生産性向上による年間節減: 1200万ドル
- セキュリティインシデント削減: 年5件 → 0件
課題と解決策
課題1: 初期導入の困難
問題: 既存インフラと新プラットフォームの二重化 解決策:
- 段階的移行 (チーム別3か月単位)
- 既存システムとの互換性保持レイヤー構築
- 強力な変化管理と教育プログラム
課題2: プラットフォームの継続的進化
問題: 技術変化に伴うテンプレート更新の必要性 解決策:
- CI/CDと同様にプラットフォームも管理
- テンプレート検証の自動化テスト
- 開発チームのフィードバックループ構築
課題3: プラットフォーム採用への抵抗
問題: 開発チームが既存方式を固守 解決策:
- 成功事例の共有 (DORAメトリクス)
- 「脱出ハッチ」を提供 (必要なら既存方式も許可)
- プラットフォーム経由の改善をリアルタイムで表示
結論: プラットフォームエンジニアリングは必須
2026年現在、プラットフォームエンジニアリングは以下をもたらします:
- 生産性: 開発生産性30-40%向上
- 信頼性: デプロイ失敗率60-70%削減
- 開発経験: 開発者満足度の大幅改善
- 運用効率: DevOpsエンジニアの負担大幅削減
実装チェックリスト:
- 現在のDORAメトリクスを測定
- プラットフォームチーム組成 (5-10エンジニア)
- BackstageまたはIPD選択
- 1チームで3か月のパイロット実行
- 成功事例に基づいて組織全体に展開
プラットフォームエンジニアリングなしで競争力を保つことは難しい時代になっています。
参考資料
- Spotify Backstage 公式サイト
- DORAメトリクス - Accelerate本
- SPACEメトリクス - 開発者生産性測定
- Gartner プラットフォームエンジニアリング報告書
- Puppet State of DevOps 2026
Internal Developer Portal (IDP) dashboard showing Backstage interface with service catalog on left side, golden path templates in center, and developer tools/integrations on right side. Show metrics dashboard displaying DORA metrics (deployment frequency, lead time, MTTR, change failure rate). Include icons for multiple tools (GitHub, ArgoCD, Kubernetes, Slack, DataDog). Modern enterprise UI design with clean typography and data visualization.