目次を表示する

Platform Engineering 実践地図 ── 各社はどんな課題に、どう答えたか

第2話 マイクロサービス爆発と Internal Developer Portal ── Spotify, Mercari, Pinterest

場面

2014年のストックホルム。Spotifyのあるエンジニアが、新しいバックエンドサービスを立ち上げようとしていた。

最初の1行のコードを書く前に、彼は次の質問の答えを探さなければならなかった。

  • このユースケースに使うべき認証ライブラリはどれか？
  • ロギングはどのスタックに合わせるべきか？
  • 隣のSquadが似たサービスを去年作っていたはずだ──どこにある？　オーナーは誰？
  • そのサービスのAPIドキュメントは？　最終更新日は？　まだ生きている？

社内のドキュメントは点在していた。GitHubのREADME、Confluenceのページ、誰かのGoogle Docs、Slackの過去ログ。彼は隣のSquadのリードに直接聞きにいった。彼女は知らなかった。「たぶんあのチームに聞くといい」と教えられた。聞きにいくと「3ヶ月前に解散した」と返ってきた。

最初の1行のコードを書く前に、2週間が過ぎた。

Spotifyはこの状態を社内でこう呼んでいた──“rumour-driven development（噂駆動開発）“。誰が何を作っているかが、Slackと立ち話と過去のCommit履歴という暗黙知に流れていく状態（Spotify Engineering: What the Heck is Backstage Anyway? (2020-03)）。

このSpotifyのエピソードは、規模を超えてマイクロサービス化したすべての組織が直面する 発見可能性の危機 を象徴している。本章では、この問題に対して3つの会社がどう答えたかを見る。

  • Spotify：内製の System Z（2014）から Backstage（2016）へ。2020年OSS化、現在3,000社以上が採用
  • Mercari：Backstageを採用せず、内製 CLI と Single Front Door を継続
  • Pinterest：Backstageを基盤に PinConsole を構築（2025年8月時点でベータ・日次700人利用）

この章を読み終えると、自社の規模と組織文化において Backstageを採用するか・自前で作るか・どこから始めるか を判断する観点を持てるようになる。

Spotify ── 噂駆動開発から Backstage へ

課題：自律性とスケールのトレードオフ

Spotifyの「Squad / Tribe / Chapter / Guild」モデルは2012年の白書以来、自律型エンジニア組織の代表例として知られている。各Squadは6〜12人のクロスファンクショナル・チームで、テクノロジー選定の自由度が高い。

この Squad 自律性の文化 が、副作用として「ツール多様性の爆発」を生んだ。Terraform、GCP/AWS/Azure CLI、GitLab CI、Prometheus、Kubernetes、Docker、各種監視ツール──個々のSquadが選んだツールの寄せ集めが、横断視点で見ると壮絶なフラグメンテーションになっていた（Spotify Engineering, 2020-03）。

2014年頃、エンジニアが100人を超え、毎週のように新しいマイクロサービスが追加されるフェーズに入る。サービススプロール、責任所在不明、可視性欠如 が深刻化した。「どのサービスが何をしているか」「誰がオーナーか」「どう使うか」を発見できず、開発開始までの時間がコーディング時間より長くなる──冒頭のエピソードは、この時期のものだ。

ここでSpotifyが取った選択は、ツール選定の自由を奪う ことではなかった。それは Squad 自律性という文化的核を否定することになる。代わりに彼らが選んだのは、「メタデータ層を統一して、その上のプラグインを各Squadが書く」 モデルだ。

解決策：System Z → Backstage の進化

graph LR
    A[2014<br/>System Z<br/>マイクロサービスカタログ] --> B[2016<br/>Backstage<br/>フルリライト]
    B --> C[2020-03<br/>OSS化]
    C --> D[2020-09<br/>CNCF Sandbox]
    D --> E[2022-03<br/>CNCF Incubation]
    E --> F[2024<br/>Backend v1.0]
    F --> G[2025-04<br/>~700 Squad/3,000+社]

System Z（2014年〜） は、プラットフォームチームが内製したマイクロサービスカタログだった。ハックウィークから生まれた。サービス名、コードへのリンク、オーナーSquad、プロダクトオーナー名などのメタデータを登録する素朴なシステム。

工夫は、マイクロサービス側に「自分のAPIドキュメントを返すエンドポイント」を実装させる という設計だった。各サービスが自己記述する。System Zがそれを取り込む。コードからドキュメントが生まれる ため、「ドキュメントだけ古くなる」現象が起きない（Roadie: Backstage Spotify Ultimate Guide）。

System Zは成功した。しかし、フロントエンド機能要求が膨張するにつれて、System Zは限界を迎える。2016年頃、Spotifyは フルリライト を決断する。これが Backstage の始まりだ。

Backstageは、System Zの「メタデータ層」というコア思想を継承しつつ、UIとプラグインアーキテクチャを大きく拡張した。各種CLIツールに統一UIを被せる「開発者ポータル」へと進化していく。2020年のOSS公開時点で、社内には 100以上のプラグイン が存在していた。

OSS化と現在の規模

2020-03  Backstage OSS 公開（Spotify 初の主要 OSS インフラ）
2020-09  CNCF Sandbox 寄贈
2022-03  CNCF Incubation 昇格
2024     Backend v1.0（バックエンド全面書き換え）
2025-04  Spotify 内 ~700 Squad が日次利用 / 社外採用 3,000+ 社

Spotify Engineering の5周年振り返りブログ（2025-04）によれば、社内利用は 約700 Squad、社外採用は 3,000社を超える（Spotify Engineering, 2025-04）。Backstage の ADOPTERS.md には、HelloFresh（500+ engineers globally）、Zalando、Twilio、American Airlines、Expedia、Netflix、Splunk、Wayfair──業界横断で並ぶ。

商用展開も始まっている。2024年4月にSpotifyは “Spotify Portal for Backstage”（エンタープライズ向けSaaS）の提供を開始した。「Backstageを自前運用するのは大変」というユーザー側の現実に応えた形だ。

なぜ Backstage が広く採用されたか

ここで一つ、構造的な気づきがある。Backstage は “Portal” であって “Platform” ではない。

Backstageが提供するのは、第1話で触れた IDP の5プレーンのうち、Developer Control Plane（開発者の入り口） の部分だけだ。CI/CDの実体、Kubernetesクラスタ、シークレット管理、モニタリング基盤──これらは別途用意する必要がある。

Backstageが広く採用された理由は、皮肉にも 「足りない部分が明確」 だったことだ。

  • メタデータカタログ：標準化（Software Catalog）
  • Software Templates：標準化（Scaffolder）
  • TechDocs：標準化（MkDocsベース）
  • 一方で、CI/CD・Kubernetes・モニタリングは 各社が好みに応じて選べる

「全部入りSaaS」ではなく「統合点を提供する基盤」という設計が、各社のスタック多様性を吸収した。これは、Spotify自身が「全社で1つのSaaSを導入する」アプローチを文化的に取れなかった事情と、構造的に相似形になっている。

これは伏線だ。第10話で扱うアンチパターン「Backstageで満足する」（症状：見栄えの良いPortalがあるが、その裏で開発者は手作業でデプロイしている）は、まさに「BackstageをPortalではなくPlatformそのものだと誤認した」結果として起きる。

Mercari ── Backstageを採用しなかった選択

同じ問題、違う解

Mercari のフリマサービスは2018年からマイクロサービス移行を始めた。GCP上のマイクロサービス化は、PHPモノリスからの段階移行という形で進んだ。2023年12月時点で、移行以来 数百のマイクロサービスをリリース、うちアクティブに保守されているのは約62%（Mercari Engineering, 2023-12）。残り38%は ゾンビ化 していた。

Spotifyが直面した「発見可能性の危機」と、課題の手触りはほぼ同じだ。だが、Mercari は Backstageを採用しなかった。

2026年5月時点でリサーチした2023〜2025年のMercari公式ブログ記事には、Backstage採用に関する記述は確認できない。代わりに彼らが選んだのは、内製の Single Front Door（SFD） という路線だ。

Mercari の Platform Team 進化史

Mercari の選択を理解するには、Platform Team 自体の進化を辿る必要がある。

2018年〜：発足期（2-3名） モノリス→マイクロサービス移行に伴い、各サービス開発チームに大量のインフラ知識を要求する状況が発生。当初2-3名で発足したPlatform Team は、ビルド・テスト・デプロイ・運用まで全方位を「1人1人が広く浅く担当」する状態に陥った。専門性が育たず、優先順位がつかない（Mercari Engineering, 2021-09）。

2020-07：機能別分割再編 単一チームを Build / Test / Deploy / Operate のライフサイクル軸で専門化。各サブチームが自分の領域に集中できる構造に変わった。

2022-01：DPE Camp 体制（8チーム / ~50名）

Developer Productivity Engineering（DPE）Camp として、以下の8チーム編成に整理された。

  • Platform Developer Experience（DX）
  • Platform Infra
  • CI/CD
  • Network
  • Microservices SRE
  • Search Infra
  • Web Platform
  • Core SRE

注目したいのは Platform DX チーム の存在だ。プラットフォームと機能チームの境界面（= 開発者向け UX）は 1つのDXチームが完全所有する という設計（Mercari Engineering, 2023-12）。

2025-12：1,600+アクティブリポジトリ規模 Single Front Door に MCP サーバーを統合、AI 時代の開発者UX拡張へ進化中（Mercari Engineering, 2025-12）。

Single Front Door の構成

SFDの実装は、Argo Workflows + Kubernetes + GitHub + GCP（Secret Manager / Datastore / KMS / Pub/Sub）+ OAuth 2.0 + Workload Identity という組み合わせだ。内製CLIとGCPなどの外部サービスを統一する開発者向けインターフェース として機能する。

特徴的なのは「ポータルUI」を主眼に置いていない点だ。CLIファースト の設計で、開発者が普段触れるGitHubやターミナルから自然に呼び出せる体験を作っている。

開発者の体験イメージ：
  $ mercari service create my-service --template=microservice
  → Argo Workflows がトリガーされ、GitHub にリポジトリ作成、
    GCP の各種リソース（Secret Manager / Service Account / Workload Identity）が
    プロビジョニングされ、CI/CD パイプラインが用意される

なぜ Backstage を選ばなかったか（推察を含む）

注：以下は公開情報からの推察であり、Mercari公式の説明ではない。

公開情報からは、Backstageを評価検討した記録は見つからなかった。だが、Mercari の選択には次の合理性があると読める。

  1. 既に内製CLIが社内文化になっていた：開発者の手が「ターミナル」に向いている文化で、Webポータルよりも CLI の方が体験が一貫する
  2. GCP 中心の構成：Argo Workflows + Workload Identity という構成は、GCP のIDフェデレーション機能を活用する。Backstageの汎用性より、GCPに特化した自動化の方が深く統合できる
  3. Backstage の運用コスト：Backstage は「組み立て式フレームワーク」であり、プラグイン開発・Workflow・自動化の実装には専属チームの本格コミットが必要。Mercariは限られたリソースを 自社固有のドメイン課題 に集中させた

そして決定的に重要なのは、Mercari Director of Platform Engineering 田中氏（Speaker Deck: Platform Engineering at Mercari, 2023-05）が登壇で繰り返し強調する Product Mindset だ。「プラットフォーム自身をプロダクトとして継続的に磨く」方針。Backstageを「便利なフレームワーク」として導入するのではなく、自社の文脈に最適化したUXを内部プロダクトとして作る という選択だ。

これは第8話「Platform-as-a-Product」への伏線になる。Mercari の選択は、「プラットフォームをどう 作る か」ではなく「プラットフォームをどう 運営する か」に重心を置いた結果として読める。

Pinterest ── Backstage と自社デザインシステムの折衷

PinConsole の構成

Pinterest は2025年8月にエンジニアリングブログで PinConsole を公開した。「Backstage を基盤に、Pinterest 内部 OAuth + LDAP 統合、AWS RDS PostgreSQL、Pinterest 自社デザインシステム Gestalt を組み合わせて構築」というスタック（Pinterest Engineering, 2025-08-22）。

主要プラグインは、PinCompute（社内Kubernetes管理）、GitHub、Jira、PagerDuty。Pinterestエンジニアがこう表現している──「Backstage と Kubernetes と gRPC からインスピレーションを受けたIDPモデル」。

課題：20種類以上のツール分断

Pinterestの問題設定は明快だった。開発者は 日々20種類以上の社内ツール を使い分ける状態。同じ目的のツールがUI違いで複数存在し、ドキュメントは Google Docs・Wiki・GitHub に分散。公式ブログは「コンテキストスイッチが生産性最大の阻害要因」と明言している。

ここでPinterestが選んだのは、Mercariのような「全部内製」ではなく、Spotifyのような「全部の自社製造」でもなく、「土台はBackstage、UXレイヤーはGestalt」 というハイブリッド戦略だ。

なぜ Backstage を選んだか

Pinterest がBackstageを選んだ合理性は、Zalando（Sunrise）とほぼ同じだ。Zalando エンジニアブログは率直にこう書いている──

「自前でデザインシステムとプラグインアーキテクチャを作るリソースもスキルも、ポータルチーム単独では不足していた」

— Zalando Engineering Blog (2023-08)

100社以上で実績のあるBackstageを土台にすることで、UI/プラグイン機構の自前開発コストを回避。一方で、デザインシステムだけは自社のGestaltに揃えることで、Pinterest社員にとっての一貫したUXを担保した。

現在の運用指標

PinConsoleは2025年8月時点で ベータ。しかし指標は印象的だ。

  • 日次700人以上のエンジニアが利用
  • 月次利用率約30%

数千人規模のエンジニア組織に対する月次30%という採用率は、ベータ段階としては相当に高い。Pinterest がここまでの採用率を達成できた背景には、第3話で扱う Paved Road の設計思想 がある。「強制せず、デフォルトを楽にする」アプローチで、自然と乗ってもらう構造を作った結果だ。

3社の比較

観点SpotifyMercariPinterest
ポータル戦略自社製造（OSS化）Backstage非採用、内製SFDBackstageベース＋Gestalt
インターフェースWeb Portal中心CLIファーストWeb Portal中心
中核思想メタデータ統一＋プラグイン拡張DX単一チーム＋Product Mindset既存基盤の再利用＋自社UX
規模~700 Squad / 3,000+社採用~50 PE / 1,600+ リポジトリ~700 日次利用 / 月30%
始動時期System Z 2014 → OSS 2020Platform Team 2018 → DPE 2022PinConsole 2025-08（ベータ）
自由度プラグイン書けるCLI拡張可能Backstageプラグイン書ける
quadrantChart
    title 開発者ポータル戦略の選択軸
    x-axis 自前で作る --> 既存基盤を使う
    y-axis CLI中心 --> Web Portal中心
    quadrant-1 既存Web基盤
    quadrant-2 自前Web基盤
    quadrant-3 自前CLI基盤
    quadrant-4 既存CLI基盤
    Spotify Backstage: [0.15, 0.85]
    Mercari SFD: [0.2, 0.2]
    Pinterest PinConsole: [0.75, 0.85]
    Zalando Sunrise: [0.7, 0.85]

3社に共通するのは、「マイクロサービスの発見可能性」という同じ問題意識から出発していることだ。違うのは、自社の組織文化・既存スタック・利用可能な人的リソースに応じて、どこに線を引いたか。

  • Spotify：プラットフォーム業界に通用する汎用性を持つPortalを「作って世界に貢献する」選択
  • Mercari：自社の文脈に最も深く統合された内製を「磨き続ける」選択
  • Pinterest：すでに証明されている基盤を借りて、UXだけを自社最適化する選択

どれが「正解」かを問うのは意味がない。自社の規模・文化・リソースに対して、どの選択が成立するか を問うのが、判断のための問いだ。

Portal は IDP の一部に過ぎない

最後に、本章で繰り返し示してきた構造的な気づきを明示しておく。

Backstage（あるいはどんなPortalであれ）は、IDPの Developer Control Plane の一部に過ぎない。

IDPの参照アーキテクチャでは5つのプレーンがあった（第1話）。Portalはそのうち最上層の入り口だ。CI/CD、Kubernetes、シークレット管理、モニタリング、セキュリティ──残り4プレーンが埋まっていなければ、Portalは「美しい入り口だけがあって、その奥に機能が薄い建物」になる。

これは第10話で扱うアンチパターン「Building the Front End First」の警鐘でもある。Luca Galante（Platform Engineering community core contributor）はInfoWorldで明確に言っている。「Platform implementation should begin with a solid back end, not the front end」（InfoWorld）。

3,000社が採用するBackstageの実例は、それ自体は希望だ。しかし「Backstageを入れたから Platform Engineering をやっている」と言える状態は、Portal の裏側に Paved Road が存在して初めて成立する。

ではその Paved Road は、どう設計するのか。次章では、Netflix・Twilio・Yelp・Spotifyの4社が選んだ「強制せず誘導する」設計の方法論を比較する。

問い：あなたの会社が今 Backstage 導入を検討しているなら、その裏側で開発者が踏み続ける「道」は、もう舗装されているか？　それとも、Portal を入れた瞬間に、誰も乗らない美しい入り口だけが残るか？

参考文献

Spotify

Mercari

Pinterest

関連