目次を表示する

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

第1話 Platform Engineeringとは何か ── DevOpsの墓場と再生

場面

「来期から Platform Engineering をやることになった」とSlackで告げられた瞬間、あなたは考える。「で、何から手をつければいい？」

検索すると、CNCFのWhitepaper、Team Topologiesの図、Backstageの画面キャプチャ、Humanitecの参照アーキテクチャ、PlatformConのキーノート──情報は湧き出るように出てくる。読み進めるほどに、しかし、どんどん輪郭がぼやけていく。

ある記事は「IDP（Internal Developer Platform）を構築すること」と言う。別の記事は「組織変革であって技術ではない」と言う。さらに別の記事は「SREの進化形」と書き、別の記事では「SREとは別の概念」と書く。Backstageを入れた事例もあれば「Backstageを入れただけでは Platform Engineering ではない」と書く事例もある。

定義は揃わない。なのに「2026年までに大規模ソフトウェア組織の80%が Platform Engineering チームを持つ」とGartnerは予測している（Humanitec, Gartner Hype Cycleの解説）。市場は走り出している。

このシリーズを通じて私たちが追うのは、「Platform Engineering」という単語の 正しい定義 ではない。各社が どんな状況で、何を選び、何を捨てたか だ。だがその前に、この言葉が立ち上がってきた20年の文脈を整理しておく必要がある。なぜなら、各社の選択は、この20年の問いに対するそれぞれの答えだからだ。

この章を読み終えると、次の3つができるようになる。

  • 「Platform Engineering」という言葉がなぜ定義の揺らぎを抱えているかを説明できる
  • DevOps・SRE・Platform Engineering の関係を、対立ではなく 進化の系譜 として説明できる
  • 自社の文脈で「我々が解こうとしているのはどの世代の問題か」と問えるようになる

「DevOps は失敗した」と Charity Majors は言った

2024年8月、Honeycomb の CTO・Charity Majors はブログにこう書いた。

「振り返ってみれば、DevOps運動全体は、たった一つのことを達成するための、20年にわたる壮大な戦いだった。開発者と本番環境を結ぶ、一本のフィードバックループを作ることだ。その基準で言えば、DevOps は失敗した」

— The Future of Ops Is Platform Engineering, 2024-08-27

この一文は、業界の多くの人がうっすら感じていたことを言語化した。

DevOpsの起源を辿ろう。2006年、AmazonのCTO・Werner Vogelsが ACM Queue のインタビューで語った”You build it, you run it”。「自分で作ったものを自分で運用しろ」。これがDevOps思想の原点とされる（ACM Queue 2006）。2009年にはVelocityカンファレンスでJohn AllspawとPaul HammondがFlickrの “10+ Deploys per Day” を発表し、同年Patrick DeboisがGhentで初のDevOpsDaysを開催。「DevOps」という言葉が広がっていく。

それから15年。何が起きたか。CIパイプラインは延び、KubernetesのYAMLは2,000行を超え、Terraformはモジュールがネストし、開発者は「自分のサービスをデプロイするまでに何を覚えなければならないのか」を把握できなくなった。「You build it, you run it」の重みは、開発者一人が背負うには重すぎた。

Charity Majorsの整理を要約するとこうなる。

  • DevOpsは「全員が全部を運用する」を理想化した。だがツールチェーンが追いつかず、開発者は疲弊した。
  • SREはGoogleの社内文化として「信頼性の専門性」を担う形で発展したが、Googleと同じスケールを持たない多くの組織にとっては機能しなかった。
  • Platform Engineering は、その失敗を踏まえて生まれた。「開発者が自分のコードを運用するために必要な能力を、Platform team がパッケージして提供する」というモデルだ。

「You build it, you run it」の精神は維持される。ただし、運用に必要な認知負荷は構造的に下げる。これがPlatform Engineeringの基本姿勢だ。

言葉が「公式デビュー」した2022年

「Platform Engineering」という単語そのものは、それ以前から散発的に使われていた。だが ディシプリン（規律ある実践領域）として広く認知された のは2022年だ。決定打は3つある。

timeline
    title Platform Engineering 成立までの主要マイルストーン
    2003 : Google が SRE 実践開始
    2006 : Werner Vogels "You build it, you run it"
    2009 : DevOpsDays Ghent / Flickr "10+ deploys/day"
    2014 : Spotify System Z（Backstage の原型）始動
    2016 : Google SRE Book / Backstage 内部開発開始
    2019 : Team Topologies 出版（Platform Team の理論化）
    2020 : Spotify Backstage OSS化 / Golden Path 公開
    2022 : 第1回 PlatformCon（約6,000人）/ Gartner Hype Cycle 入り
    2023 : CNCF Platforms Whitepaper / Maturity Model 発表
    2024 : Fournier & Nowland 書籍 / DORA 2024 で定量化

1. Gartner Hype Cycle 入り（2022年7月）

2022年7月25日、Gartner Hype Cycle for Emerging Technologies に「Platform Engineering」が初登場した。続く8月のSoftware Engineering向けHype Cycleにも掲載され、Gartnerはこれを「セルフサービス型 Internal Developer Platform を構築・運用するディシプリン」と定義した。さらに「2026年までに大規模ソフトウェア組織の80%がPlatform Engineering チームを持つ」と予測している（The Stack: Platform Engineering The First Hype Cycle）。

2. PlatformCon 2022（2022年6月）

Humanitec の Luca Galante らが立ち上げた platformengineering.org が主催した初回カンファレンス。第1回で 78のコミュニティ提出トーク、約6,000人参加 という規模を集めた（CNCF blog: Platform engineering trends in 2023）。「Platform Engineering」という看板を業界に焼き付けたのはこのイベントだ。

3. Team Topologies の Platform Team 章（2019）

Matthew SkeltonとManuel Paisが2019年に出版した『Team Topologies』が、組織パターンの一つとして “Platform Team” を理論化した。これが後の用語定着の 意味的な土台 になった（teamtopologies.com）。

その後、CNCFが2023年にPlatforms Whitepaperを、同年11月にMaturity Model v1.0を公開する。2024年11月にはCamille FournierとIan Nowlandの共著 “Platform Engineering: A Guide for Technical, Product, and People Leaders” がO’Reillyから出版され、現時点での 決定版 と位置づけられている（O’Reilly）。

20年かけて積み上がってきた問いと実践が、2022年に「Platform Engineering」という看板の下に集合した──これが、この言葉が抱える 歴史的な重み であり、同時に 定義の幅広さ の正体でもある。

CNCF と Humanitec、二つの定義

定義の揺らぎを実感するために、業界の二大定義を並べて読んでみよう。

CNCF の定義（2023, Platforms Whitepaper）

「クラウドネイティブコンピューティングのためのプラットフォームとは、プラットフォーム利用者のニーズに応じて定義され提示された、能力（capabilities）の統合されたコレクションである。それは、セルフサービスAPI、ツール、サービス、知識、サポートの基盤であり、説得力ある内部プロダクトとして編成される」

— CNCF Platforms Whitepaper

注目したいのは、CNCFは「IDP」という略称を使わず “platform” を主語にしていることだ。そして “compelling internal product” という言葉。プラットフォームは「インフラ」ではなく「内部プロダクト」だ、という強い立場を取っている。

Humanitec の定義

「Internal Developer Platform (IDP) とは、Platform Engineering チームが開発者のための Golden Path を舗装するために束ねる、すべての技術とツールの総体である」

— Humanitec: What Is an Internal Developer Platform?

Humanitec は「IDP」という略称を業界に広めた立場の企業で、定義は 技術スタックの集合体 という色合いが濃い。「束ねる（bind together）」という動詞が示すように、ツールの統合が中心にある。

違いから見えてくるもの

二つの定義の違いは、強調点の違いだ。

観点CNCFHumanitec
主語platform（プラットフォーム）IDP（Internal Developer Platform）
中核イメージ内部プロダクト技術とツールの総体
強調点能力（capabilities）の統合Golden Path の舗装
派生する焦点プロダクト思考・採用率・NPS参照アーキテクチャ・5プレーン構造

どちらが正しいというより、どちらの軸でも語れる多面体 がPlatform Engineeringだ、と理解する方が実際的だ。組織論の側から定義すると CNCF 寄りになり、技術スタックの側から定義すると Humanitec 寄りになる。

これが「Platform Engineering の定義がふわっとしている」と感じる正体だ。技術と組織と思想が交差する地点に立っているために、どこから見るかで定義が変わる。

SRE とは何が違うのか

ここでよく聞かれる問いに正面から答えておこう。「SREチームがすでにあるのに、Platform Engineering を別に立ち上げる意味は？」

観点SRE（Google起源）Platform Engineering
主目的信頼性（SLO・Error Budget）開発者体験・速度（Cognitive Load 削減）
対象スタック層比較的下層・運用寄りより上層・セルフサービスAPI
代表メトリクスSLI / SLO / Error Budget採用率 / NPS / Time-to-Deploy
組織形サイト信頼性チームPlatform team + Stream-aligned + Enabling
中心の問いこのシステムは信頼できるかこのシステムを 作る人 は速く・安全に動けるか
関係Platform に内包されるケースが多いSREを内包する／併走する

ポイントは、SREとPlatform Engineeringは 対立する概念ではない ことだ。Charity Majorsの整理を借りれば──

  • DevOps は「複数の技術世代と広範なインフラを抱える組織」に向く
  • SRE は「エンジニアが概ね本番コードを所有しているが、信頼性の専門性が必要な大企業」に向く
  • Platform Engineering は「開発者が self-serve で自分のコードを運用できる体験を提供する」レイヤーで成立する

SREの「信頼性」という能力は、Platform Engineering の文脈では プラットフォームが提供する複数のcapabilityのうちの一つ として取り込まれることが多い。たとえばPagerDutyとの統合、SLOダッシュボード、エラーバジェット消費率の可視化──これらをセルフサービスで使える形で提供するのが、Platform Engineering 配下のSRE機能だ。

実務的には、こう考えるとよい。

❌ 二項対立で考える
   「SREチームを潰してPlatform Engineering チームに改名するか」

✅ レイヤーとして考える
   「SREが担っていた capability（SLO・インシデント対応・キャパシティプランニング等）を、
    Platform チームが提供する セルフサービスAPI として再構成できないか」

第10話で扱う「Operations Rebranding」というアンチパターン──運用チームの看板掛け替えだけで本質が変わらない──は、まさにこの二項対立で考えた結果として起きる。

押さえておきたい4つの中核概念

各社の事例を読み解くために、最低限の概念道具を持っておこう。第3話以降で詳しく扱うが、ここでは輪郭だけ示す。

1. Internal Developer Platform (IDP)

開発者向けのセルフサービス基盤の総称。Humanitec と McKinsey が共同で提唱した参照アーキテクチャでは、IDPは5つの “Plane” に分解される。

Plane役割
Developer Control Plane開発者の入り口（Backstage 等のPortal）
Integration & Delivery Planeコード→デプロイ可能状態を作る（CI/CD・Orchestrator）
Resource / Infrastructure Plane実際のクラスタ・DB・DNS等
Monitoring & Logging Plane観測と運用
Security Planeシークレット・ID管理

ここで重要な気づきが一つある。Backstageは Developer Control Plane の一部に過ぎない。Backstageを入れただけでは、残り4プレーンは埋まらない。これは第10話のアンチパターン「Backstage で満足する」の伏線だ。

2. Paved Road / Golden Path

「強制ではないが、最も推奨される構築経路」のこと。Netflixが “Paved Road” を、Spotifyが “Golden Path” を広めた。実体は、ベストプラクティスを埋め込んだプロジェクトテンプレート、推奨ツールチェーン、「これに乗ればSRE/セキュリティ/コンプライアンスが自動で満たされる」セットアップだ。逸脱は可能だが、その分自分でメンテする責任がついてくる。第3話で詳述する。

3. Platform-as-a-Product

「プラットフォームを内部プロダクトとして扱う」考え方。開発者は「ユーザー」、開発チームは「内部顧客」。Backstageを開発したSpotify自身が「Backstageの最大の機能は本体ではなく platform-as-a-product のマインドセットそのもの だ」と説明している（Platform Engineering org: Platform as a Product talk）。第8話で詳述する。

4. Cognitive Load（認知的負荷）

Team Topologiesの核心概念。3種類ある。

  • Intrinsic（内在的）：課題本来の難しさ。訓練で軽減
  • Extraneous（外在的）：仕組みやツール由来の不要な負荷。プラットフォームで削減すべき主対象
  • Germane（関連的）：専門性・ドメイン知識への深まり。残しておきたい

Platform Engineering の存在意義は、Extraneous Cognitive Load を構造的に削減し、Stream-aligned team が Germane な仕事に集中できる状態を作ることだ。第9話で詳述する。

✅ 良い理解 / ❌ 悪い理解

最後に、Platform Engineering を語るときの典型的な誤解を整理しておく。

❌ 悪い理解：
   - 「DevOps の進化版・上位互換である」
     → DevOps が消えるわけではない。Platform Engineering は DevOps の理想を
       実現するための **構造的な装置** として現れた

   - 「Backstage を入れること」
     → Backstageは IDP の Developer Control Plane の一部。残り4プレーンが
       埋まっていなければ、ピカピカの Portal に過ぎない（第10話「アンチパターン3」）

   - 「インフラチームを Platform Engineering チームに改名すること」
     → これは「Operations Rebranding」というアンチパターン名がついている
       （第10話「アンチパターン2」）

   - 「すべての開発者を強制的に乗せること」
     → 採用は任意であるべき。低採用率は「規律違反」ではなく
       「プロダクト課題」として扱う（第3話・第8話）

✅ 良い理解：
   - 「Stream-aligned team の Cognitive Load を構造的に下げるための、
     セルフサービス基盤と組織モデルの組み合わせ」

   - 「Platform-as-a-Product の発想で運営される、内部プロダクト」

   - 「SRE・DevOps・Team Topologies が交差する地点に立つ、新しいディシプリン」

   - 「会社の規模・事業フェーズ・組織文化によって、最適解が大きく変わる」

最後の点が、このシリーズの出発点だ。Spotifyの解はSpotifyの規模と文化の上で成立している。20人のスタートアップに移植しても動かない。adidasがVM取得30分→1週間という前史から始まった事情と、Mercariがマイクロサービスのゾンビ化に直面した事情は、課題の手触りが違う。

では、各社はどう実践しているのか

ここまでで、Platform Engineering という言葉が立ち上がってきた20年の文脈と、定義の幅広さの正体、SREとの関係、4つの中核概念を整理した。

ここから先は 各社の実践 の話だ。

第2話では、最も歴史的に重要な実例──Spotify Backstage の起源を追う。Spotify社内のあるエンジニアが、新しいバックエンドサービスを立ち上げようとして最初の1行のコードを書く前に2週間が過ぎた、という2014年の状況。そこから生まれた System Z、それを書き直した Backstage、2020年のOSS化、そして現在 ~700 Squad で日次利用される規模感までを辿る。

そして同じ「マイクロサービスの発見可能性」という問題に、Mercariが内製のSingle Front Doorで答え、Pinterestが Backstageベースの PinConsole で答えた──同じ問いに対する選択の違いを比較する。

その先で、第3話では「強制せず、自然と乗ってもらう」という設計思想──Paved Road / Golden Path──をNetflix・Twilio・Yelp・Spotifyの4社で比較する。

定義の話はここまでだ。次章からは、現実の話に入る。

問い：あなたの組織が今直面している課題は、DevOps以前の世代の問題か、DevOps後の認知負荷の問題か、それとも Platform Engineering が解こうとしている「セルフサービスの境界線」の問題か。どこに位置しているかが、次の一手を決める。

参考文献