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

Spotify から走り始めスタートアップまで、規模・業種別の Platform Engineering 実践事例を10話＋エピローグで横断する。「なぜその手段か」を解剖する設計判断の地図。

全11章

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

シリーズ構成（全10話＋エピローグ）

第1話 Platform Engineeringとは何か / 第2話 Internal Developer Portal / 第3話 Paved Road の敷き方 / 第4話 内製IDPの極北 / 第5話 日本のSaaSの独自進化 / 第6話 走り始めスタートアップの最小構成 / 第7話 中規模成長期の選択 / 第8話 Platform-as-a-Product / 第9話 Cognitive Load と Team Topologies / 第10話 アンチパターンと失敗の解剖学 / エピローグ 組織サイズと事業フェーズの意思決定マップ

なぜ、この記事を書くのか

「Platform Engineering をやりましょう」と言われて、最初に困るのは 何をどこから始めるか だ。

Backstage を入れる？　いや、その前に組織を変えるべき？　それともマネージドプラットフォームで凌げる？　100人規模ならどう？　20人ならどう？　既存の SRE チームとは何が違う？

書籍を読むと「正解」が書いてある。CNCF Whitepaper、Team Topologies、Fournier & Nowland の O’Reilly 本。どれも価値ある。ただ、それらは 理想形 を語る本だ。現実の各社が、どんな状況でどう判断したか は書かれていない。

たとえば、Mercari は Backstage を採用していない。内製の Single Front Door を選んだ。なぜか。Spotify は Backstage を作った張本人だが、その前身 System Z は2014年にハックウィークから生まれた泥臭いマイクロサービスカタログだった。adidas（消費財メーカー）は「VM 取得に最短30分・最悪1週間」という前史から始まった。Tailscale はインフラチームが3人だ。レバテックは Platform Engineering を意図的に「やめた」。

これらの判断には、それぞれの規模・事業ステージ・組織文化に根ざした合理性がある。「なぜその手段か」を解剖することで、自社の判断材料が増える ──これが本シリーズの目的だ。

対象読者と読み方

対象：
  - SRE / プラットフォームチームの立ち上げを任されたテックリード・EM
  - 「Platform Engineering という言葉は聞くが、自社で何から始めるべきかわからない」状態
  - Backstage 導入を検討中／やめるか迷っている方
  - スタートアップで「うちは PE をやるべきか」を判断する立場の方

難易度：★★★☆☆〜★★★★☆（話による）
読了時間：1話あたり約20分、全体で約4時間
前提知識：Kubernetes・CI/CD・IaC の基礎。SRE 本（Google）の概念を聞いたことがある程度でOK

各話は独立して読める。自社の規模・状況に近い章から入って構わない。ただし以下の組み合わせは互いに呼応しているので、続けて読むと判断の精度が上がる。

  • 規模別の縦断ルート： 第6話（〜50人）→ 第7話（50〜500人）→ 第4話（500人〜）── フェーズ移行の解像度を上げたい場合
  • 思想軸の横断ルート： 第3話（Paved Road）→ 第8話（Platform-as-a-Product）→ 第9話（Team Topologies）── 「強制せず採用される」設計の根拠
  • 失敗回避ルート： 第10話（アンチパターン）→ 第8話（Product Mindset）→ 第9話（Cognitive Load）── 既に始めているが詰まっている方
  • 国内事情ルート： 第5話（日本のSaaS）→ 第7話（中規模成長期）→ 第6話の国内事例 ── 国内の進化パターンを掴みたい場合

最後にエピローグで全話を貫く「組織サイズと事業フェーズの意思決定マップ」を整理し、参考文献を付す。

各話の構造

すべての話が同じ4段構成に従う。

1. 状況     ── どんな組織が、何に困っていたか
2. 選択     ── どんな手段をとったか（複数社の比較）
3. なぜ     ── 他選択肢ではなくそれを選んだ理由・トレードオフ
4. 示唆     ── 自社で判断するときの問い

事例は 2026年5月時点で公開されている一次情報（公式エンジニアリングブログ・カンファレンス登壇・公式ドキュメント）に基づいている。各章末に出典を明記する。推測・憶測は明示する。

話一覧

話焦点主要事例
第1話 Platform Engineeringとは何か定義・歴史・なぜ今PlatformCon / Gartner / CNCF / Charity Majors の DevOps 失敗論
第2話 マイクロサービス爆発と Internal Developer PortalPortal が解いた問題Spotify Backstage / Mercari SFD / Pinterest PinConsole
第3話 Paved Road の敷き方強制せず誘導する技法Netflix / Twilio / Yelp / Spotify
第4話 内製IDPの極北規模が選択肢を狭めるときUber / adidas / Zalando
第5話 ドメイン共通基盤からの逆走日本のSaaSの独自進化SmartHR / Money Forward / Sansan
第6話 走り始めスタートアップの最小構成〜50人の現実解Tailscale / PostHog / Bitkey / Cloudbase / レバテック
第7話 中規模成長期の選択SRE→Platform Engineeringへの進化10X / LayerX / カケハシ / freee / Visional
第8話 Platform-as-a-Product内部顧客と社内マーケSpotify / Mercari / HelloFresh / SmartHR / Sansan
第9話 Cognitive Load と Team Topologies組織と技術の同型性Team Topologies / TVP / Inverse Conway Maneuver
第10話 アンチパターンと失敗の解剖学13の罠と脱出法Field of Dreams / Backstageで満足 / Bottleneck化 ほか
エピローグ 組織サイズと事業フェーズの意思決定マップフェーズ別の選択肢一覧〜10人 / 10〜50人 / 50〜500人 / 500人〜

この記事を読んだあとで

Platform Engineering の難しさは「正解の不在」ではなく 「自社にとっての正解の判別」 にある。Spotify の解は Spotify の組織文化・スケール・歴史の上で成立している。それを20人のスタートアップに移植しても動かない。

本シリーズが目指すのは、各社の選択を 「答え」ではなく「思考の素材」 として提供することだ。読み終えたとき、あなたの目の前のコードベースと組織図が、過去のどの会社の状況に似ていて、どんな選択肢が現実的かが見えるようになる──それが目的だ。

エピローグでは、全話を貫く判断軸を「組織サイズ × 事業フェーズ」のマップとして整理する。考古学はここで終わらない。あなたが書く次の章は、あなたの会社の事例だ。

目次

  1. 第1話 Platform Engineeringとは何か ── DevOpsの墓場と再生 「Platform Engineering」という言葉が業界に定着するまでの20年と、SREやDevOpsとの違いを、Charity Majorsの「DevOpsは失敗した」論を起点に解きほぐす
  2. 第2話 マイクロサービス爆発と Internal Developer Portal ── Spotify, Mercari, Pinterest Spotify Backstage の起源から、Mercari の内製 Single Front Door、Pinterest の PinConsole まで。同じ「マイクロサービスの発見可能性」問題に対する3社の異なる選択を比較する
  3. 第3話 Paved Road の敷き方 ── 自由とデフォルトの両立 Netflix・Twilio・Yelp・Spotify の4社が「強制せず誘導する」をどう実装したかを比較し、自社の Paved Road 設計に向けた判断軸を抽出する
  4. 第4話 内製IDPの極北 ── 規模が選択肢を狭めるとき Backstage で十分な企業と、十分でない企業の境界線はどこにあるのか。Uber / adidas / Zalando が選んだ「内製の極北」の合理性を解剖する。
  5. 第5話 ドメイン共通基盤からの逆走 ── 日本のSaaSの独自進化 海外がBackstage中心のIDPから始まる一方、日本のSaaSは「ドメインの共通基盤」が先にできて開発者基盤が後から整備される。SmartHR・Money Forward・Sansanに見る二段階進化の合理性。
  6. 第6話 走り始めスタートアップの最小構成 ── 〜50人の現実解 PaaS全乗せ、1人目SREの典型業務、PEを「やらない」判断──〜50人規模のスタートアップが Platform Engineering をどう実践しているか／していないかを横断する。
  7. 第7話 中規模成長期の選択 ── SREからPlatform Engineeringへの進化 エンジニア50〜500人規模の国内SaaSが、SREチームを起点にPlatform Engineeringへとミッションを拡張していった軌跡を10X・LayerX・カケハシ・freee・Visionalの5社で比較する
  8. 第8話 Platform-as-a-Product ── プラットフォームを内部プロダクトとして運営する 「使ってもらえないプラットフォーム」を作らないための原則を、Spotify・Mercari・HelloFresh・SmartHR・Sansanの実装で読み解く。内部顧客・採用任意・プロダクトメトリクス・社内アドボカシーの4つが核心
  9. 第9話 Cognitive Load と Team Topologies ── 組織と技術の同型性 「ツールを足したのに開発者の負担が減らない」状況を解剖する。Cognitive Loadの3分類、Team Topologiesの4チームと3 interaction mode、TVPと「3つの実例が出るまで抽象化を待つ」原則を、第7話の事例で再解釈する
  10. 第10話 アンチパターンと失敗の解剖学 ── 13の罠と脱出法 Platform Engineering で最も頻発する13のアンチパターンを「症状・根本原因・脱出法」の3点セットで解剖する。Field of Dreams、Backstageで満足、Bottleneck化、Cognitive load 増、誤メトリクスなど
  11. エピローグ ── 組織サイズと事業フェーズの意思決定マップ 10話を貫く判断軸を「組織サイズ × 事業フェーズ」のマップとして整理し、フェーズ移行の兆候・次に来るものを示す総括章。参考文献付き。