Backstageの概要と導入後の期待効果
Backstageとは
Backstage は、もともと Spotify が社内開発者ポータルとして開発し、2020年に OSS として公開、現在は CNCF（Cloud Native Computing Foundation）の Incubating プロジェクトとなっているプラットフォームです。
ひとことで言えば「散らばった開発インフラ・サービス・ドキュメント・ツールを、ひとつの統一されたUIに集約するためのフレームワーク」です。Backstage 自体は完成したアプリケーションではなく、プラグインを組み合わせて自社の開発者ポータルを構築するための土台である点が最大の特徴です。
用語の整理：Developer Portal と IDP
| 用語 | 意味 | Backstageとの関係 |
|---|---|---|
| Developer Portal | 開発者が必要な情報・ツールにアクセスする単一の入口（UI） | Backstage が提供する主要価値 |
| IDP（Internal Developer Platform） | 開発者がセルフサービスでインフラ・環境を扱える基盤の総称 | Backstage は IDP の「UI / ポータル層」を担う |
| Platform Engineering | IDP を「プロダクト」として設計・運用する組織的取り組み | Backstage 運用の前提となる考え方 |
Backstage は IDP のすべてではありません。CI/CD・Kubernetes・クラウド基盤などは別途存在し、Backstage はそれらを横断的に見せ、操作する窓口として機能します。
提供形態
| 形態 | 例 | 特徴 |
|---|---|---|
| OSS 版（セルフホスト） | backstage.io | 無料・最大の自由度・構築/運用工数が必要 |
| マネージド / 商用版 | Spotify Portal、Roadie | 構築不要・サポートあり・コスト発生 |
本ドキュメント群は基本的に OSS 版（セルフホスト） を前提に解説します。
なぜ導入するのか（解決したい課題）
組織が成長しサービス数・チーム数が増えると、以下のような「認知負荷（Cognitive Load）」の問題が顕在化します。
具体的には次のような課題です。
- 発見性（Discoverability）の欠如 — 「どこに何があるか分からない」。サービス・API・ドキュメント・オーナーの情報が複数のツールに散在する。
- オンボーディングの長期化 — 新メンバーが戦力化するまでに、暗黙知の習得や人づての情報収集に時間がかかる。
- 新規構築のボイラープレート — 新サービス立ち上げのたびに、リポジトリ作成・CI/CD 設定・監視設定などを手作業で繰り返す。
- 標準・ベストプラクティスの形骸化 — 推奨構成がドキュメントに書かれても守られず、実態がばらばらになる。
- オーナーシップの曖昧化 — 障害時に「これ誰の担当？」が即座に分からない。
中核機能の俯瞰
Backstage は主に以下の機能で上記の課題に対応します。各機能の詳細は中核コンセプトで扱います。
| 機能 | 役割 | 解決する課題 |
|---|---|---|
| Software Catalog | 全サービス・API・リソース・オーナーを一元管理 | 発見性・オーナーシップ |
| Software Templates（Scaffolder） | テンプレートから新規プロジェクトを自動生成（ゴールデンパス） | ボイラープレート・標準化 |
| TechDocs | コードと同じリポジトリで管理する docs-as-code | ドキュメントの陳腐化 |
| Search | カタログ・ドキュメント横断検索 | 発見性 |
| プラグイン群 | Kubernetes・CI/CD・コスト等を統合表示 | ツールの分散 |
アーキテクチャ概要
Backstage は フロントエンド（React） と バックエンド（Node.js） から構成され、両者にプラグインを追加して機能を拡張します。
- プラグインアーキテクチャ — コア機能もプラグインとして実装されており、必要な機能を追加・差し替えできる。
- データソース — 各サービスのメタデータは、リポジトリに置かれた
catalog-info.yamlや外部インテグレーションから取り込まれる。 - 永続化 — 本番では PostgreSQL が必須（開発では SQLite も可）。
アーキテクチャとデータモデルの詳細は中核コンセプトを参照してください。
導入後の期待効果
Backstage を導入し定着させることで、以下の効果が期待できます。
| 効果 | 内容 |
|---|---|
| オンボーディング短縮 | 新メンバーがカタログ・TechDocs・テンプレートから自走できる |
| オーナーシップと可視性の向上 | すべてのサービスにオーナーが紐づき、障害時の連絡先が明確になる |
| ゴールデンパスの提供 | 推奨構成をテンプレート化し、「正しいやり方が一番簡単」な状態を作る |
| ガバナンスの定量化 | 標準準拠率・カタログ網羅率をスコアカード等で可視化できる |
| 開発者体験（DevEx）の改善 | ツール横断の手間が減り、開発者は本質的な作業に集中できる |
「ゴールデンパス」とは、組織が推奨する標準的なやり方を、テンプレートや自動化で最も簡単な選択肢にすることです。強制ではなく「楽だから自然と従う」状態を目指します。詳細はベストプラクティスを参照。
ROI / 効果測定の考え方
Backstage は「導入して終わり」ではなく、効果を計測しながら育てる社内プロダクトです。導入判断・継続判断のために、以下のような指標を設定します。
計測すべきメトリクスの例
- オンボーディング時間 — 新メンバーが最初のPRをマージするまでの日数
- テンプレート利用率 — 新規サービスのうちゴールデンパス経由で作られた割合
- カタログ網羅率 — 実在サービスのうちカタログに登録されている割合
- DORA メトリクス — デプロイ頻度・変更リードタイム・変更失敗率・MTTR（SRE原則参照）
- 開発者満足度 — サーベイによる定性評価
コストとの比較
| コスト要素 | 内容 |
|---|---|
| 構築工数 | 初期セットアップ・認証連携・初期プラグイン導入 |
| 運用工数 | アップグレード・プラグイン保守・カタログ品質維持 |
| インフラコスト | ホスティング・PostgreSQL・ストレージ |
これらを上回る「開発者の時間削減」「障害対応の迅速化」「標準化による品質向上」が見込めるかを評価します。
段階的導入ロードマップ
詳細な導入戦略はベストプラクティスを参照してください。
ベストプラクティス
- スモールスタート — まずは最小限のカタログと1〜2のゴールデンパスから始め、価値を示してから拡大する。
- プロダクトとして運営 — 専任のプラットフォームチームがオーナーシップを持ち、開発者をユーザーと捉えてフィードバックを取り込む。
- 強制ではなく価値提供 — 「使わないと怒られる」ではなく「使うと楽」を徹底する。
よくあるアンチパターン
- カタログを整備しないまま公開し、情報が不正確で信頼されなくなる。
- プラットフォームチーム不在のまま導入し、誰も保守しなくなる。
- 利用を強制するだけで、開発者の課題解決につながらない。
詳細はBackstage導入のベストプラクティスを参照してください。