ストーリー
佐藤CTOの問いに、あなたは苦笑いしました。
Internal Developer Platform(IDP)
IDPとは
| 項目 | 内容 |
|---|---|
| 定義 | 開発者がセルフサービスでアプリケーションの構築・デプロイ・運用を行える内部プラットフォーム |
| 目的 | 開発者の認知負荷を軽減し、生産性を向上させる |
| 提供者 | プラットフォームチーム |
| 利用者 | ストリームアラインドチームの開発者 |
IDPの構成要素
graph TD
IDP["Internal Developer Platform"]
IDP --> DP["Developer Portal
(Backstage等)"]
DP --> DP1["サービスカタログ"]
DP --> DP2["APIドキュメント"]
DP --> DP3["テンプレート(Scaffolding)"]
DP --> DP4["テックドキュメント"]
IDP --> IA["Infrastructure Abstraction"]
IA --> IA1["Kubernetes as a Service"]
IA --> IA2["データベース Provisioning"]
IA --> IA3["メッセージキュー Provisioning"]
IA --> IA4["シークレット管理"]
IDP --> CI["CI/CD Platform"]
CI --> CI1["パイプラインテンプレート"]
CI --> CI2["自動テスト基盤"]
CI --> CI3["セキュリティスキャン"]
CI --> CI4["デプロイ自動化"]
IDP --> OB["Observability Platform"]
OB --> OB1["ログ集約"]
OB --> OB2["メトリクス収集"]
OB --> OB3["分散トレーシング"]
OB --> OB4["アラート管理"]
IDP --> SC["Security & Compliance"]
SC --> SC1["ID管理・認証基盤"]
SC --> SC2["ポリシー自動適用"]
SC --> SC3["監査ログ"]
style IDP fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
style DP fill:#d1fae5,stroke:#059669,color:#065f46
style IA fill:#d1fae5,stroke:#059669,color:#065f46
style CI fill:#d1fae5,stroke:#059669,color:#065f46
style OB fill:#d1fae5,stroke:#059669,color:#065f46
style SC fill:#d1fae5,stroke:#059669,color:#065f46
style DP1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style DP2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style DP3 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style DP4 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style IA1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style IA2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style IA3 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style IA4 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style CI1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style CI2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style CI3 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style CI4 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style OB1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style OB2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style OB3 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style OB4 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style SC1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style SC2 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style SC3 fill:#f3f4f6,stroke:#9ca3af,color:#374151
セルフサービスの原則
5つのレベル
| レベル | 内容 | 例 |
|---|---|---|
| L1: ドキュメント | 手順書を提供 | 「DBを作るにはこの手順を実行」 |
| L2: テンプレート | 設定テンプレートを提供 | Terraform モジュール、Helm Chart |
| L3: CLI/API | コマンドで操作可能 | platform db create --type postgres |
| L4: UIポータル | GUIで操作可能 | Backstage のフォーム入力 |
| L5: 宣言的 | 意図を宣言するだけ | I need a database → 自動プロビジョニング |
「目指すべきはL3〜L4だ。L5は理想だが、現実にはまだ遠い組織が多い。**チケットを切ってプラットフォームチームに依頼する(L0)**の状態から、少しずつレベルを上げていく」 — 佐藤CTO
ゴールデンパス(Golden Path)
概念
ゴールデンパスとは、組織が推奨する「最も効率的で安全な開発パス」です。
golden_path_example:
new_microservice:
step1: "Backstageのテンプレートから新規サービスを作成"
step2: "GitHubリポジトリが自動生成(CI/CD設定済み)"
step3: "Kubernetes Namespace が自動プロビジョニング"
step4: "監視ダッシュボードが自動作成"
step5: "コードを書いてPushすればデプロイ完了"
total_time: "30分で本番デプロイ可能な状態に"
without_golden_path:
step1: "インフラチームにチケットを起票"
step2: "1週間待ってリポジトリ作成"
step3: "CI/CD設定を手動で作成"
step4: "インフラチームにK8s設定を依頼"
step5: "監視設定を手動で追加"
total_time: "2-3週間"
ゴールデンパスの原則
| 原則 | 説明 |
|---|---|
| 推奨であり強制ではない | パスを外れることも可能(ただし自己責任) |
| デフォルトが安全 | セキュリティ、監視がデフォルトで組み込まれている |
| 段階的に拡張 | 一度にすべてを作らず、需要の高いものから |
| フィードバック駆動 | 利用チームの声を元に改善し続ける |
Backstage(Spotifyの開発者ポータル)
概要
Backstage は Spotify が開発し、CNCFに寄贈した開発者ポータルフレームワークです。
backstage_features:
software_catalog:
description: "全サービス・ライブラリのカタログ"
includes:
- "オーナーチーム"
- "依存関係"
- "APIドキュメント"
- "ヘルスステータス"
software_templates:
description: "新サービスのスキャフォールディング"
includes:
- "言語・フレームワーク選択"
- "CI/CD自動設定"
- "監視自動設定"
- "セキュリティ設定"
techdocs:
description: "技術ドキュメントの統合管理"
approach: "Docs as Code(Markdownから自動生成)"
plugins:
description: "200以上のプラグインで拡張可能"
examples:
- "Kubernetes プラグイン"
- "GitHub Actions プラグイン"
- "PagerDuty プラグイン"
- "Cost Insights プラグイン"
Backstage導入のロードマップ
| フェーズ | 期間 | 内容 |
|---|---|---|
| Phase 0 | 2週間 | Backstage環境構築、基本セットアップ |
| Phase 1 | 1ヶ月 | ソフトウェアカタログ(既存サービスの登録) |
| Phase 2 | 2ヶ月 | テンプレート作成(主要言語2-3種類) |
| Phase 3 | 3ヶ月 | TechDocs統合、プラグイン導入 |
| Phase 4 | 継続 | フィードバックベースの改善 |
プラットフォームをプロダクトとして扱う
プロダクトマネジメントの適用
graph TD
PM["プロダクトマネジメント手法
顧客 = 社内の開発者"]
PM --> UR["ユーザーリサーチ"]
UR --> UR1["開発者へのインタビュー、サーベイ"]
PM --> RM["ロードマップ"]
RM --> RM1["四半期ごとの機能計画"]
PM --> MT["メトリクス"]
MT --> MT1["利用率、満足度、セルフサービス率"]
PM --> DOC["ドキュメント"]
DOC --> DOC1["Getting Started、APIリファレンス"]
PM --> SP["サポート"]
SP --> SP1["Slackチャンネル、オフィスアワー"]
style PM fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e40af
style UR fill:#d1fae5,stroke:#059669,color:#065f46
style RM fill:#d1fae5,stroke:#059669,color:#065f46
style MT fill:#d1fae5,stroke:#059669,color:#065f46
style DOC fill:#d1fae5,stroke:#059669,color:#065f46
style SP fill:#d1fae5,stroke:#059669,color:#065f46
style UR1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style RM1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style MT1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style DOC1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
style SP1 fill:#f3f4f6,stroke:#9ca3af,color:#374151
成功指標
| 指標 | 計算方法 | 目標 |
|---|---|---|
| セルフサービス率 | セルフサービスリクエスト / 全リクエスト | > 80% |
| 開発者満足度(NPS) | 四半期サーベイ | > 50 |
| 新サービス立ち上げ時間 | テンプレート選択からデプロイまで | < 1時間 |
| チケット削減率 | プラットフォームチームへのチケット数の推移 | 四半期で20%減 |
まとめ
| ポイント | 内容 |
|---|---|
| IDP | 開発者がセルフサービスで開発・デプロイ・運用できる基盤 |
| ゴールデンパス | 推奨される効率的で安全な開発パス |
| Backstage | Spotify発の開発者ポータルフレームワーク |
| プロダクト思考 | プラットフォームを内部プロダクトとして運営する |
チェックリスト
- IDPの構成要素を理解した
- セルフサービスの5レベルを把握した
- ゴールデンパスの概念と原則を理解した
- プラットフォームのプロダクトマネジメントを理解した
次のステップへ
次は「デベロッパーエクスペリエンス(DX)」を学びます。プラットフォームの先にある、開発者体験全体を設計する方法を見ていきましょう。
推定読了時間: 40分