目次を表示する

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

エピローグ ── 組織サイズと事業フェーズの意思決定マップ

振り返り ── 10の物語

10話を歩いた。

2014年、Spotifyのエンジニアが新サービスを立ち上げるのに2週間費やした朝から始まり、Mercariが Backstage を選ばなかった2023年の判断、adidasが「VM取得30分〜1週間」の世界から脱出した6ヶ月のスプリント、Tailscaleの3人インフラチームの黙々とした運用、Cloudbaseの「早すぎる最適化を最大の罠と認識する」10人スタートアップ、レバテックの「基盤グループを解散する」というPlatform Engineering をやめる判断──。

これらは一つの真理を共有していない。むしろ、それぞれの会社が 自社の規模・事業・組織文化に根ざした合理性 で別々の答えに辿り着いている。Spotify の Backstage が万能薬ではないように、Tailscale の3人体制も誰でも真似できるわけではない。

ただ、10話を並べて見ると、判断の 軸 は驚くほど共通している。本章では、その軸を「組織サイズ × 事業フェーズ」のマップとして整理する。

mindmap
  root((Platform Engineering<br/>意思決定))
    フェーズ
      ~10人 PaaS全乗せ
      10~50人 1人目SRE
      50~500人 SREチーム→PE
      500人~ 内製IDP/Backstage
    判断軸
      自由 vs 標準化
      内製 vs OSS/SaaS
      強制 vs 任意採用
      技術 vs 組織
    やらない選択
      PEを名乗らない
      PEを延期する
      PEを解散する
    次に来るもの
      AI Agent統合
      MCP Server
      Platform-as-a-Service外販

4つのフェーズ ── 組織サイズ別の意思決定マップ

10話で観察した事例を、組織サイズで4つのフェーズに整理する。各フェーズで 「何を選ぶ」「何を選ばない」「次のフェーズへの移行兆候」 を示す。

フェーズ1：〜10人（PaaS 全乗せフェーズ）

典型例： Plausible（ソロメイカー）、Resend（FE2人）、Cloudbase（〜10人）、Notion 2015〜2020

選ぶもの：

  • Vercel / Supabase / Render / Heroku / Fly.io / Cloud Run のいずれか
  • マネージドDB（RDS / Cloud SQL / Supabase Postgres）
  • 「退屈なツール」（Plausible 哲学）

選ばないもの：

  • 自前 Kubernetes クラスタ運用
  • 専任 Platform Engineer の採用
  • Backstage 等の IDP プロダクト
  • 自前 CI/CD パイプライン基盤

「Platform Engineering」を名乗るか：

  • 名乗らない。Cloudbase の言葉を借りれば「PE 実践の一部を取り入れる」程度。
  • 「早すぎる最適化」が最大のリスク。

次のフェーズへの移行兆候：

  • プロダクトが2本以上になり、共通基盤の必要性が見え始める
  • インフラ作業が機能開発を3週連続で阻害する
  • 創業エンジニアが他のことに時間を使えなくなる
  • セキュリティ・コンプライアンス要件（SAML/SSO）が契約条件になる

第6話で深掘りした内容。

フェーズ2：10〜50人（1人目 SRE フェーズ）

典型例： smartround（1人目 SRE）、LayerX バクラク初期、Bitkey（SRE 2名+ゲリラ2名）、カミナシ（専任なしの試行）

選ぶもの：

  • 1人目の SRE / インフラ専任を採用（あるいは創業エンジニアが兼任を明示化）
  • Terraform 化、Secret 管理、CI 高速化、APM/Log の標準化
  • GitHub Actions 集中リポジトリ・社内 RFC 等の「軽い標準化」
  • ECS Fargate / Cloud Run / GKE（マネージド K8s）

選ばないもの：

  • 専任 Platform Engineering チーム
  • Backstage 本格導入
  • 自前 K8s クラスタ運用

「Platform Engineering」を名乗るか：

  • 名乗っても良いが、SRE と PE の境界は曖昧で構わない。
  • Bitkey の「PE 専任チームはない」と明言しつつ実態として PE 活動を行う形は健全。

次のフェーズへの移行兆候：

  • SRE 1人がボトルネックになり、複数プロダクトの運用が回らなくなる
  • 「CTO が SRE を採用すべきか」を毎月議論し始める
  • 同じ問題（Terraform、CI高速化、SLO）が複数プロダクトで別々に解かれる
  • インシデントレビューに「専任の Platform 観点」が欠ける

第6話後半・第7話前半で深掘り。

フェーズ3：50〜500人（SRE → Platform Engineering への進化フェーズ）

典型例： 10X、LayerX バクラク、カケハシ、Sansan、freee、Visional、SmartHR

選ぶもの：

  • SRE チーム化（2〜10名）→ Platform Engineering への組織進化
  • 「Platform SRE × Embedded SRE」のハイブリッド型
  • ドメイン共通基盤（権限・課金・認証など）の独立化
  • 開発生産性指標（DORA / SPACE / 自社独自フレームワーク）
  • Terraform モジュール化（Service Kit / Team Kit）
  • Backstage の 検討開始（採用とは限らない）

選ばないもの：

  • 「全社1つのプラットフォーム」を一気に作る試み
  • 専任 Platform チームへの過剰な権限集中（Bottleneck 化）
  • Backstage 導入を「PE をやっていることの証明」にする

「Platform Engineering」を名乗るか：

  • 名乗る組織が出始める（LayerX「Platform Engineering 部」、Sansan「Platform Engineering Unit」、Visional「プラットフォーム基盤推進室」）。
  • ただし日本では2024年以降の現象。それ以前は SRE / DevOps / 基盤チーム呼称が主流。

次のフェーズへの移行兆候：

  • Stream-aligned チームが10チームを超える
  • ツールチェイン断片化（Spotify が “rumour-driven development” と呼んだ状態）
  • 開発者が「うちの Platform チームは何をしているか分からない」と言い始める
  • 内部マーケティング・アドボカシーの必要性が議論される

第5話・第7話・第8話で深掘り。

フェーズ4：500人〜（内製 IDP / 大規模 Backstage フェーズ）

典型例： Spotify、Netflix、Uber、Mercari、Zalando、adidas、Pinterest、HelloFresh、Money Forward

選ぶもの：

  • 大規模 Backstage 採用（Zalando Sunrise、Pinterest PinConsole、HelloFresh）または完全内製（Mercari SFD、Uber Up、Netflix Platform Console）
  • Paved Road / Golden Path の体系化（Netflix、Spotify、Twilio）
  • DOMA のようなアーキテクチャ＋プラットフォーム両輪の整理（Uber）
  • Platform-as-a-Product の本格運営（Platform PM、ロードマップ、NPS 計測）
  • ドメイン共通基盤の連邦化（Money Forward 事業者基盤、Sansan Orbit）

選ばないもの：

  • 「他社の事例をそのままコピー」（第10話アンチパターン11）
  • Day 2 の軽視（運用フェーズの予算欠落）
  • 強制採用での見かけ上の高採用率

「Platform Engineering」を名乗るか：

  • 明示的に名乗る。Director of Platform Engineering、Head of Platform、Platform PM などの役職が公式化される。
  • 一部企業（Atlassian Compass、Spotify Portal for Backstage）は 自社内製を商用化 する方向にも進む。

現フェーズの主要課題：

  • AI Agent 統合（Mercari は2025-12 に Single Front Door に MCP サーバーを統合）
  • マルチクラウド・コスト最適化（adidas Karpenter+VPA で月コスト50%削減）
  • 「内部 Platform を OSS / 商用展開する」かの判断

第2話・第3話・第4話・第8話で深掘り。

フェーズ移行の判断 ── 「いつ」と「いつでない」

各フェーズには 早すぎる移行のリスク と 遅すぎる移行のリスク がある。

flowchart LR
    P1[フェーズ1<br/>~10人] -->|早すぎ:過剰投資| Risk1[Magpie Platform<br/>第10話]
    P1 -->|遅すぎ:回らない| P2[フェーズ2<br/>10~50人]
    P2 -->|早すぎ:1人目に重荷| Risk2[Bottleneck化<br/>第10話]
    P2 -->|遅すぎ:複数プロダクト混乱| P3[フェーズ3<br/>50~500人]
    P3 -->|早すぎ:Operations Rebranding| Risk3[Field of Dreams<br/>第10話]
    P3 -->|遅すぎ:断片化| P4[フェーズ4<br/>500人~]
    P4 -->|失敗:Day 2軽視| Risk4[Under-invested Platforms<br/>第10話]
    P4 -->|成功:Platform-as-a-Product| Success[内部顧客との対話継続]

    style Risk1 fill:#ffcccc
    style Risk2 fill:#ffcccc
    style Risk3 fill:#ffcccc
    style Risk4 fill:#ffcccc
    style Success fill:#ccffcc

早すぎる移行の症状：

  • フェーズ1で Backstage を入れて「使われない」
  • フェーズ2で SRE チームを3人雇って「やることがない」
  • フェーズ3で Platform Engineering 部を作って「Operations Rebranding」になる

遅すぎる移行の症状：

  • フェーズ1のままプロダクトが3本になり、創業エンジニアが疲弊
  • フェーズ2のまま50人を超え、SRE 1人がインシデント対応に埋没
  • フェーズ3のまま300人を超え、ツールチェイン断片化が深刻化

判断基準は 組織サイズ単独ではない。事業フェーズ・プロダクト数・採用ペース・技術的負債の蓄積度を組み合わせて見る。

4つの横断する判断軸

10話を貫く判断軸を抽出すると、4つに集約できる。

軸1：自由 vs 標準化

各 Squad の自律性をどこまで認めるか。

  • 自由寄り： Spotify（System Z 以前）、Plausible（ソロメイカー）、PostHog（小チーム自律）
  • 標準化寄り： Twilio Admiral、adidas Kubernetes、10X Service Kit
  • 中庸（Paved Road）： Netflix、Mercari Golden Path、Yelp PaaSTA

第3話の主題。完全な自由は断片化を、完全な標準化は形骸化を生む。Paved Road は「外れる自由を残しつつ、デフォルトを最も楽にする」中庸の実装。

軸2：内製 vs OSS / SaaS

プラットフォームをどこまで自社で作るか。

  • 完全内製： Uber Up、Netflix Platform Console、Mercari SFD
  • OSSベース＋カスタマイズ： Zalando Sunrise（Backstage）、Pinterest PinConsole（Backstage+Gestalt）、HelloFresh
  • マネージドSaaS活用： フェーズ1〜2の全スタートアップ、Atlassian Compass（自社製を商用化）

第4話の主題。内製の理由は「規模が商用PaaSの想定を超える」「特殊な運用要件がある」のいずれか。それ以外は OSS / SaaS で十分なケースが多い。

軸3：強制 vs 任意採用

プラットフォームの採用を組織として強制するか、開発者の選択に委ねるか。

  • 強制寄り： （アンチパターンとして第10話で扱う）
  • 任意採用： Spotify、Netflix Paved Road、Mercari Golden Path、Twilio Admiral
  • 中間（標準だが逸脱可能）： 10X Terraform モジュール、freee Platform Delivery

第8話の主題。Platform-as-a-Product の核心は「採用は任意。低採用率はコンプライアンス問題ではなくプロダクト課題」。

軸4：技術 vs 組織

プラットフォームの本質を「技術スタック」に置くか、「組織の構造」に置くか。

  • 技術寄り： 個別ツール（Backstage、ArgoCD、Terraform）の選定
  • 組織寄り： Team Topologies の4チーム、Platform-as-a-Product、Embedded SRE
  • 両輪： Uber DOMA（アーキテクチャ＋プラットフォーム）、Sansan（Orbit + Embedded SRE）

第9話の主題。Conway’s Law と Inverse Conway Maneuver が示すように、組織構造とアーキテクチャは同型化する。技術選定だけでは Platform Engineering は完成しない。

「PE をやらない」「PE をやめる」 ── 第三の選択肢

10話を貫いてもう一つ重要な発見がある。「Platform Engineering をやらない」「途中でやめる」も明示的選択肢である ということだ。

  • Cloudbase（〜10人）： 「専任チームを置くより、PE 実践の一部を取り入れる」「スコープ拡大と早期最適化を警戒」
  • レバテック： Platform Engineering Kaigi 2024 で「基盤システムグループを解散」を公開。Stream-aligned チームの実課題に PE がフィットしないと判断
  • PostHog： Kubernetes サポート廃止（2023-05）。利用者3.5%のために小チーム疲弊するのは持続不能と判断

これらは「失敗」ではない。自社の状況に合わない選択を捨てる判断 だ。Platform Engineering はブームに乗って始めるものではなく、観察と分析の上で本当に必要になってから始めるもの──というのがレバテックの立場であり、本シリーズが繰り返し示してきた事実だ。

判断する問いは一つ。「うちの Stream-aligned チームの実課題は、PE で解けるのか」。解けるなら投資する。解けないなら別の手段を取る。

次に来るもの ── 2026年以降の Platform Engineering

10話で扱ったのは2026年5月時点の事例だ。すでに次のフェーズが始まっている。

AI Agent / MCP の統合

Mercari は2025-12にSingle Front Door に MCP（Model Context Protocol）サーバーを統合した。「AI 時代の開発者 UX 拡張」と位置付けている。Sansan も中長期で「AI Agent による認知負荷削減」を目標に掲げる。

開発者ポータルが「人間が情報を見つける場」から「AI Agent が情報を取得し、開発者を代理する場」に進化しつつある。これは第2話で扱った Internal Developer Portal の延長線上にあり、しかし質的に別物だ。

Platform 商用化の流れ

Atlassian Compass（2023-10 GA）、Spotify Portal for Backstage（2024〜）のように、自社内製を商用 SaaS として外販する 流れが始まっている。Platform Engineering が「コストセンター」から「プロダクト」になり、さらに「収益源」になるパターン。

ただしこれは規模と歴史を持つ企業に限定された選択肢で、ほとんどの組織には縁遠い。

Multi-tenant / Federated Platform

複数事業を持つコングロマリット型企業（Money Forward、LayerX のコンパウンドスタートアップモデル、Visional の複数事業 SaaS）では、事業ごとに Platform チームを持ちつつ、横断レイヤーで標準化する 連邦型のモデルが定着しつつある。Visional の ORE（Organisational Reliability Engineering）はその典型。

Platform Engineering のキャリア

「Platform Engineer」という職種としての確立は、日本では2024年以降の現象だ。今後5年で：

  • 専門スキルセット（IDP 設計、Backstage 開発、Terraform モジュール設計、社内 PM スキル）が言語化される
  • SRE / DevOps とは別の評価軸（採用率、NPS、開発生産性指標）でキャリアが評価される
  • 「Platform PM」という職種が SaaS 業界で標準化する

一つの原則 ── 各社の選択は、各社の文脈に根ざしている

10話と4軸が示しているのは、ひとつの単純な事実だ。

Platform Engineering の正解は組織ごとに異なる。 同じ規模の組織でも、事業フェーズ・プロダクト構成・採用市場・既存技術スタックが違えば、選ぶべき手段は違う。

Spotify Backstage の事例を読んで「うちも Backstage を入れよう」と決めるのは、第10話アンチパターン11「他社模倣（Copying the Platforms of Others）」の典型だ。Spotify が Backstage を作ったのは、彼らが Squad 自律性の文化を持っていたからだ。あなたの組織の文化が違うなら、Backstage は違う形で機能する──あるいは機能しない。

だから、本シリーズで提示したのは「答え」ではなく「判断の素材」だ。各社の選択を読み、自社の状況と照らし合わせ、自分の組織にとっての答えを設計する──それが Platform Engineering の実践だ。

考古学とは違って、Platform Engineering は 今この瞬間も書き換え続けている歴史 だ。あなたの組織の判断は、来年の誰かの参照事例になるかもしれない。

参考文献・情報源

主要書籍

  • Matthew Skelton & Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution Press, 2019)
  • Camille Fournier & Ian Nowland, Platform Engineering: A Guide for Technical, Product, and People Leaders (O’Reilly, 2024)
  • Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps (IT Revolution Press, 2018)
  • Betsy Beyer et al., Site Reliability Engineering: How Google Runs Production Systems (O’Reilly, 2016)

標準・公式文書

主要企業の公式エンジニアリングブログ（一次情報）

海外：

走り始めスタートアップ：

国内：

コミュニティ

最後の問い：あなたの組織は、いま4つのフェーズのどこにいるか。次のフェーズへの移行兆候は、もう現れていないか。Platform Engineering は「やる／やらない」の二択ではなく、いつ・どこから・どれだけ投資するかの設計判断だ。

そして次の問い：Platform Engineering を「やらない」「やめる」という第三の選択肢を、あなたは自社の経営に提示できるか。提示できないなら、あなたはまだ Platform Engineering を始める準備ができていない。