目次を表示する

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

第4話 内製IDPの極北 ── 規模が選択肢を狭めるとき

場面

Backstage で十分なはずだ──そう思える企業と、思えない企業がある。

第2話で見た Spotify Backstage、第3話で見た Netflix の Paved Road。これらを読むと、たいていの企業が「では Backstage を入れよう」「Spinnaker を真似よう」という発想になる。実際、Zalando や Pinterest は Backstage を採用してうまくいっている。

しかし、規模がある閾値を超えた瞬間、OSS や SaaS では要件を満たせなくなる地点が現れる。週10万デプロイ、ペタバイト級メトリクス、4,500個のマイクロサービス──こうした数字が並び始めたとき、市場に存在するプロダクトはひとつもない。Uber が µDeploy / Up を、adidas が CNCF エコシステム上の独自プラットフォームを、Zalando が Backstage 上に2,000PR以上を積み上げた Sunrise を作った理由はそこにある。

この章では、3社の「内製の極北」を解剖する。Uber はほぼフル内製、Zalando はBackstage に乗せる、adidas はCNCF エコシステムを組み合わせる。同じ「規模が選択肢を狭めた」帰結でありながら、判断は3通りに分かれた。何が選択を分けたのか。

状況：それぞれの「規模」

3社の数字を並べる。

観点Uber (2023)adidas (CNCF ケース時点)Zalando (2023)
エンジニア組織約4,000人e-commerce 約300人1,000人以上
プラットフォームチーム巨大（陣容不明・OSS還元あり）約35人Builder Portal 4人
主要プラットフォームUp（社内PaaS）Kubernetes + CNCFSunrise（Backstageベース）
管理対象4,500マイクロサービス・週10万デプロイ・約200万コア相当4,000 pods・200ノード・月8万ビルド4万エンティティ日次同期・27ツール・30+プラグイン
内製の中核Up / Michelangelo / M3 / DOMA（CNCF OSS の組み合わせ）Backstage 上の Zalando 統合層

数字の桁が違う。だが、注目したいのはプラットフォームチームの陣容だ。Zalando の Builder Portal はわずか4人で4万エンティティ規模を支えている。adidas は35人で e-commerce 全体のクラスタコストを月50%削減した（InfoQ, 2024-07）。Uber は陣容こそ巨大だが、M3 や Cadence を OSS化することで社外貢献者を取り込み、維持コストを希釈している。

「規模が大きいから内製した」だけでは説明が足りない。規模に対して、どこまで自前で持つかの線引きが、3社の判断を分けている。

選択：3つの「内製の濃さ」

Uber：ほぼフル内製の総合プラットフォーム

Uber が公開している主要コンポーネントを並べると、その総合性が見える。

  • Up（社内PaaS）：µDeploy（2015〜）から発展。2018年開発開始、2020年中盤GA、2022年に4,500サービス・約200万コア相当を移行完了 (Uber Engineering, 2023-09)
  • Michelangelo（ML 基盤）：2015年中盤開発開始、2017年公開時点で運用1年・数十チーム・約10,000特徴量を共有Feature Storeに登録 (Uber Engineering, 2017-09)
  • M3（メトリクスストア）：ペタバイト級。OSS化済み
  • DOMA（Domain-Oriented Microservice Architecture）：約2,200のクリティカルなマイクロサービスを70ドメインに分類。新機能オンボーディング時間を25〜50%削減 (Uber Engineering, 2020-07)

DOMA は、ここでの注目点だ。これは「アーキテクチャの整理」ではなく、アーキテクチャとプラットフォームの両輪として設計されている。ドメイン定義・ゲートウェイ生成・依存階層を、Up や CI/CD と統合することで初めて効果が出る。コードを整理しただけでは2,200サービスは管理できない。

Uber が解こうとした課題は、公式ブログで「マイクロサービス半減期1.5年」と表現されている (Uber Engineering, 2020-07)。サービスの寿命が短く、書き換え・マイグレーションが恒常的に発生する。この前提では、「特定のサービス構成に最適化されたツール」では追いつかない。プラットフォーム自体が、サービスのライフサイクル管理機能を持つ必要がある。Up が DOMA と連動するのはそのためだ。

adidas：消費財メーカーが、CNCF ケーススタディの代表例になった理由

adidas の事例は3社の中で異色だ。スポーツウェアメーカーであり、テック企業ではない。それでも CNCF のケーススタディで繰り返し参照される (kubernetes.io)。

なぜか。adidas の前史を読むと、答えは**「ツールではなく、ツールに到達するまでの摩擦」を最大の課題と認識した**点にある。

開発VMを取得するだけで、最短30分・最悪1週間。申請には目的・プロジェクト名・責任者・コストセンターへの連絡が必要だった。 （CNCF/Kubernetes ケーススタディ要旨）

これは技術選定の問題ではない。ガバナンスとセルフサービスの問題だ。Daniel Eichten（当時 Senior Director, Platform Engineering）はこの摩擦を消すために、AWS とオンプレを併用した Kubernetes プラットフォームを CNCF エコシステム（Prometheus、コンテナ、CI/CD、Karpenter、VPA）の組み合わせで構築した。Giant Swarm を運用パートナーに選定し、開発者起点でツール導線を再設計した（“started from the developer point of view”）。

結果：プロジェクト開始から6か月で e-commerce サイトの100%を Kubernetes に移行、リリース頻度は4-6週ごと→1日3-4回、ロード時間は半減。2024年にはKarpenter + VPA + kube-downscaler の組み合わせで開発・ステージング環境のクラスタコストを月50%削減した (InfoQ, 2024-07)。

ここで重要なのは、adidas はBackstage や Spinnaker を選ばなかったことではなく、そもそもその選択を必要としていない、という点だ。「申請フォームを消す」という課題に対しては、CNCF エコシステムの組み合わせで十分だった。プラットフォームチームの規模（約35人）も、その範囲に閉じている。

Zalando：Backstage の上に「Zalando」を乗せる

Zalando の Sunrise は、3社の中で最もハイブリッドな構造を持つ。土台は Spotify Backstage、その上に Zalando 固有の CI/CD・インフラ管理・コスト・チーム情報・API リンタ（Zally）を統合する。

数字だけ見ると、Sunrise は十分「自社製 IDP」と呼べる。

  • 4万を超える登録エンティティ（アプリ・チーム・ユーザー）
  • 1,000人以上のエンジニアにサービス提供
  • 27種類のツール／サービスを30以上のフロントエンドプラグインで統合
  • 開発期間中に2,000を超える PR をマージ
  • Builder Portal チームはエンジニア4名 (Zalando Engineering, 2023-08)

注目したいのは、Zalando 公式が「自前でデザインシステムとプラグインアーキテクチャを作る」リソースもスキルも、ポータルチーム単独では不足していたと率直に書いている点だ。Backstage という土台を借りることで、Zalando 固有の統合に時間を割けた。これは「Backstage で十分ではない」企業が、それでも Backstage を使う合理性を示している。

そして、もうひとつ言及されているのが移行コストの本質だ。

最大の移行コストは、人々のブックマーク習慣だった。 （Zalando Engineering Blog 要旨）

ツール100以上の断片化を統合するとき、技術的な統合はもちろん大変だが、それ以上に「これまで開発者が長年使ってきた個別ツールへのブックマーク」を捨てさせるのが難しい。Sunrise は機能を作るだけでなく、既存ツールから人を引き剥がす設計を強いられた。これは Backstage が解決してくれる類の問題ではない。

なぜ：3社の選択を分けた変数

3社の「内製の濃さ」は、3つの変数で説明できる。

quadrantChart
    title 内製の濃さ × プラットフォームチーム規模
    x-axis "Backstage/OSS依存度" --> "フル内製"
    y-axis "PFチーム小規模" --> "PFチーム大規模"
    quadrant-1 "総合内製ゾーン"
    quadrant-2 "OSS+大量人員"
    quadrant-3 "Backstage薄塗り"
    quadrant-4 "OSSテコ入れゾーン"
    Uber: [0.92, 0.95]
    adidas: [0.45, 0.55]
    Zalando: [0.35, 0.20]

変数1：商用 PaaS が要件を満たすか

Uber が内製を選んだ理由は単純で、当時（2015年〜）ペタバイト規模メトリクスや週10万デプロイをホストする商用PaaSが存在しなかった。M3 が生まれたのは Prometheus がペタバイト級に耐えなかったからであり、Up が生まれたのは Kubernetes 単体では4,500サービスの全社統制を成立させられなかったからだ。

adidas はこの問題を持っていなかった。e-commerce サイトは Kubernetes + CNCF エコシステムで十分動く規模だった。Zalando も、Backstage の土台が Sunrise の要件を概ね満たした。「内製しか選択肢がない」のと「内製した方が良い」は別の話だ。

変数2：マルチクラウド・規模・週次デプロイ頻度

Uber は AWS / GCP / オンプレを跨いだ「ポータブルなマイクロサービス」を Up の中心思想に据えている (Uber Engineering, 2023-09)。週10万デプロイの全社統制を、各クラウドの個別ツールに分散させたら破綻する。

adidas は AWS とオンプレを併用しているが、デプロイ頻度は1日3-4回規模。「全社で統一する」レイヤは Kubernetes API そのもので足りた。Zalando は AWS 中心で、CI/CD の統合面が課題の中心だった。

変数3：プラットフォームチームの陣容と OSS 還元戦略

Uber は陣容を巨大化させる代わりに、M3・Cadence・Jaeger などの OSS 還元で社外貢献者を取り込んでいる。これは「内製の維持コストを希釈する」戦略であり、後述する内製の罠に対する Uber 流の答えだ。

adidas はその逆で、CNCF エコシステムを採用することで「OSSの維持は CNCF コミュニティに任せる」設計にした。Karpenter / VPA は AWS と CNCF の上流に乗っており、35人の Platform Engineering チームはアプリケーション層と統合に集中できる。

Zalando は最も極端で、Builder Portal チームは4人。Backstage コミュニティの土台を借り、Zalando 固有の統合だけを4人で支える。**「内製を最小化する内製」**という呼び方が一番近い。

内製の罠と OSS 還元

3社の事例は、内製の極北を見せると同時に、その罠も浮かび上がらせる。

graph LR
    A[規模拡大] --> B[OSS/SaaSが要件を満たさない]
    B --> C[内製判断]
    C --> D[陣容の拡大]
    D --> E{維持コストの希釈策}
    E -->|Uber| F[OSS還元で社外貢献者]
    E -->|adidas| G[CNCFエコシステム採用]
    E -->|Zalando| H[Backstage上に最小限内製]

❌ 罠1：陣容の巨大化 内製したコンポーネントが増えるほど、それを保守するチームが必要になる。Uber 規模なら成立するが、中規模企業が真似ると破綻する。

❌ 罠2：OSS との乖離 内製化すると、業界標準の進化（Backstage の Backend v1.0、Spinnaker の Managed Delivery など）から取り残される。再合流のコストは時間とともに増える。

✅ 罠1への答え：OSS還元 Uber の M3 / Cadence、Netflix の Spinnaker、Spotify の Backstage は、内製コアを OSS 化することで社外コミュニティに保守を任せている。これは戦略的な選択だ。

✅ 罠2への答え：上流のフレームワークを採用する Zalando は Backstage を、adidas は CNCF エコシステムを採用することで「上流の進化」を取り込み続けている。Sunrise は Backstage の Backend v1.0 リリースに伴うリベースを継続的に行っている。

示唆：あなたの会社は「内製の極北」が必要か

3社の事例から、自社判断のための問いが3つ抽出できる。

  1. 商用 PaaS / OSS が、要件のうち何%を満たすか？

    • 80%以上満たすなら、内製は不要。Backstage や Render、Cloud Run で十分。
    • 50〜80%なら、Zalando 型（OSS の上に乗せる）。
    • 50%未満なら、Uber 型（内製の総合プラットフォーム）を検討する。

  2. プラットフォームチームの陣容を、何人まで張れるか？

    • 4人なら Zalando 型（Backstage 薄塗り）。
    • 35人なら adidas 型（CNCF エコシステム組み合わせ）。
    • 100人以上を継続投資できるなら、Uber 型が選択肢に入る。

  3. OSS 還元のコミットができるか？

    • 内製コアを OSS 化することで、保守コストを社外コミュニティに分散できるか。
    • これができないと、内製は陣容の巨大化に直結する。

まとめ

観点UberadidasZalando
内製の濃さフル内製CNCF組み合わせBackstage薄塗り
Why 内製商用PaaSが要件を満たさない申請フォームを消したい100以上のツール統合
PFチーム規模巨大（OSS還元で希釈）約35人4人
上流依存自社の OSS 群CNCF エコシステムBackstage

「内製の極北」は、規模が選択肢を狭めた帰結だ。だが、内製の濃さは規模だけでは決まらない。商用 PaaS の充足率、陣容、OSS 還元戦略の3つで決まる。Zalando のように、規模が大きくても「Backstage 薄塗り」を選べる場合がある。adidas のように、消費財メーカーでも「CNCF 組み合わせ」で十分な場合がある。

そして、3社に共通するもうひとつの真実がある。内製の中核ですら、内部顧客との対話なしには定着しない。Zalando が「ブックマーク習慣」と格闘したように、Uber DOMA がアーキテクチャとプラットフォームの両輪として設計されたように。これは第8話「Platform-as-a-Product」につながる主題だ──内製であろうと OSS であろうと、プラットフォームは内部顧客の使い方によって生死が決まる。

次の第5話では、視点を日本に移す。海外の Platform Engineering 議論が「Backstage 中心の IDP」から始まりがちなのに対し、日本の SaaS は「ドメイン共通基盤」が先に成立し、後から開発者基盤が整備されるという逆走の進化を辿った。なぜそうなったのかを、SmartHR・Money Forward・Sansan の事例から解きほぐす。

問い：あなたの会社で「商用 PaaS / OSS が要件のうち何%を満たすか」を、最後に試算したのはいつだろうか。50%・80%という閾値を意識せずに、習慣で内製や採用の判断をしていないか。

参考文献