第3話 Paved Road の敷き方 ── 自由とデフォルトの両立

場面

「セキュリティチームから連絡が来た」と、リードエンジニアがあなたのチャンネルに書き込む。「Datadogの構成が標準と違う、と。3月までに直せ、と」。

開発チームAは独自の監視ライブラリを使っている。優秀なエンジニアが3年前に作って、よく動いている。だが標準ではない。標準スタックに揃えるには2スプリント分の工数がかかる。チームAはそんな余裕がない。

選択肢は2つだ。

• 強制する：「3月までに移行しろ。例外はなし」。── チームAは形だけ移行し、内部では古いコードのラッパーを書く。形骸化が始まる。
• 自由にさせる：「無理ならスキップでいい」。── チームB、C、Dも「うちも独自で」と言い始める。標準が崩れる。断片化が始まる。

これがPlatform Engineering 設計者の 本質的なジレンマ だ。強制すると形骸化、自由にすると断片化。多くの組織がこのジレンマで詰まる。

この10年、シリコンバレーの先行企業は、第3の道を作ってきた。それが Paved Road / Golden Path という思想だ。「強制ではない。だが、これに乗るのが一番楽だ」という設計で、自然と乗ってもらう構造を作る。

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

• Paved Road / Golden Path という用語の正しい定義と、Netflix・Spotifyでの起源を説明できる
• Netflix、Twilio、Yelp、Spotifyの4社が どこまで強制し、どこから自由にしているか の温度差を判別できる
• 自社で Paved Road を始めるとき、最初の1本をどう設計するかの観点を持てる

---

Paved Road / Golden Path とは何か

定義から始めよう。Paved Road（舗装路）／ Golden Path は、「特定の工学領域（例：バックエンドサービス、データパイプライン、フロントエンドアプリ）における、意見を持って公式サポートされた構築経路」を指す。

実体としては次のような要素のセットだ。

• ベストプラクティスを埋め込んだプロジェクトテンプレート（cookiecutter, Backstage Software Templates 等）
• 公式に推奨されるツールチェーン（言語ランタイム、フレームワーク、観測スタック）
• 「これに乗ればSRE / セキュリティ / コンプライアンスが自動で満たされる」セットアップ
• ステップバイステップのチュートリアル付きドキュメント

肝は 「強制ではない」 ことだ。逸脱は可能だが、その分自分でメンテする責任がついてくる。

用語の起源

用語	提唱企業	元ネタ
Golden Path	Spotify（2020年公式公開、起源は2014年頃の社内ハックウィーク）	Frank Herbert Children of Dune（1976）の「Golden Path」（人類絶滅を回避する唯一の未来）に着想
Paved Road	Netflix が一般化（Spotify公式が “Netflix calls it a Paved Road” と書いている）	起源詳細は要追加検証
Paved Path	Google・Twilio・Airbnb・GitHub等が併用	同上

Spotify Engineering の Gary Niemen は2020年8月のブログでこう定義している。

「Golden Path とは、何かを構築するための 意見を持ち、公式にサポートされた 経路だ」

— Spotify Engineering: How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (2020-08)

Spotify はそれまでの社内文化を「rumour-driven development（噂駆動開発）」と表現していた（第2話参照）。Golden Path はその対極──暗黙知を形式化し、公式の最短経路 として提示する設計だ。

「Frank Herbert の SF」由来というのは余興ではない。Children of Dune の中で「Golden Path」は 「人類の絶滅を回避する唯一の未来」 を意味する。Spotifyのプラットフォームエンジニアは、Squad自律性の文化が崩壊することを「絶滅」になぞらえる程度には、フラグメンテーションを深刻に捉えていた。

---

4社の Paved Road を温度差で並べる

Paved Road は同じ言葉でも、各社で 強制度 が違う。最も「自由」寄りから「強制」寄りまで4社を並べてみる。

quadrantChart
    title Paved Road の強制度（横軸）と充実度（縦軸）
    x-axis 自由（外れる選択肢豊富） --> 強制（外れにくい）
    y-axis 薄い --> 充実
    quadrant-1 強制＋充実
    quadrant-2 自由＋充実
    quadrant-3 自由＋薄い
    quadrant-4 強制＋薄い
    Netflix Paved Road: [0.3, 0.95]
    Spotify Golden Path: [0.4, 0.85]
    Twilio Admiral: [0.55, 0.85]
    Yelp PaaSTA + Gondola: [0.5, 0.8]

1. Netflix ── 「外れる自由はあるが、外れたら運用責任」

Netflixの Paved Road 思想は、「Freedom & Responsibility」という同社の文化と整合している。中央プラットフォームチームが「ベストプラクティスを実装したデフォルト経路」を提供し、Squad はそこから外れる自由はあるが、外れた場合の運用責任は Squad が負う（Netflix TechBlog, 2018-05）。

Netflix の Paved Road の構成要素：

• Spinnaker：マルチクラウド対応の継続的デリバリープラットフォーム。Netflix主導で2014年から開発、2015年11月OSS公開
• Nebula：Gradleベースのビルド規約セット（内製）
• Jenkins：ビルド/CI
• gRPC ベースのRPC、サービスディスカバリ、OSイメージ “Bake”、設定、メトリクス、ロギング、トレーシング、ダッシュボード、アラート、ストリーム処理（InfoQ Paved PaaS report, 2017）
• Managed Delivery：Spinnaker上に重ねる宣言的デプロイ層（2020年頃〜）

そして、これらすべてを支える Full Cycle Developer モデル（2018-05公式化）。「自分が建てたものを自分で運用する」原則。これを成立させるために、Paved Road = セルフサービス基盤が前提条件として要請される という構造だ。

注意したいのは、Netflix の “Freedom” は トレードオフを伴う自由 だということだ。Paved Road の充実度がそのまま開発者体験の質に直結する。Paved Road が薄ければ、Full Cycle Developer は個人への過大な負荷とバーンアウトリスクを生む。これは Charity Majors が後年「DevOpsは失敗した」と書いた背景の一つでもある（第1話参照）。

Netflixの近年の動きとして、2023年〜PXDチームが内製の Platform Console（Backstageに近い思想だが内製）を構築している。ツール分断を解消する横断ポータルだ（PlatformCon talk: Netflix Platform Console）。

2. Twilio ── 「ルールではなくガードレール」

Twilio の Platform チーム（約100人、13の小チームで構成）は、内製IDP Admiral を中心に Paved Path を設計している（Built In: Ask Your Developer 抜粋）。

劇的なビフォア／アフターがある。

ビフォア（2013年頃）：
  - コミットから本番デプロイまで最大 12時間
  - ビルド失敗率 最大 50%
  - シニアエンジニアの「約半数」が退職

アフター（Admiral 導入後、2018年時点）：
  - Java サービスの新規立ち上げ 40日 → 20日

Admiralは、マイクロサービスごとに「pipeline」を定義し、ユニットテスト → 統合テスト → 障害注入テスト → 負荷テスト → ステージング → カナリア本番、という流れを 宣言的に並べる 仕組み。

Twilio Platform Foundation の Justin Kitagawa（Senior Director of Engineering）の登壇要旨と、Jason Hudak の有名なフレーズが、Twilioの哲学を端的に表す。

「ルールはない、ガードレールがある（We don’t have rules — we have guardrails）」

— Jason Hudak, Twilio

「舗装路を外れて野原を走るのは自由だが、セキュリティとレジリエンシは自分で面倒を見ること」。これが Hudak の整理だ。Netflix の “Freedom & Responsibility” とほぼ同じ思想だが、ガードレール という比喩が言い得て妙だ。「道」より少し強い。逸脱はできるが、横転は防ぐ──そのレベルの介入度。

3. Yelp ── 「単一 IDP に押し込めない」

Yelp は PaaSTA（2015年〜） と Gondola（2019年後半〜） という2つのPaaSを併存させている。これは Paved Road の作り方として独特な選択だ。

PaaSTA：Docker + Apache Mesos + Marathon + Chronos + SmartStack + Sensu + Jenkins を組み合わせた内製PaaS。開発者は YAML 系の宣言的 config でビルド・デプロイ・ルーティング・監視を指定する。OSS公開済み（Yelp Engineering Blog, 2015-11）。

Gondola：フロントエンドReactページのデプロイのみを切り出した内製PaaS。「不変なKVストア」とDynamoDBベースのページマニフェストで、アセットの即時ホットスワップを実現（Yelp Engineering Blog, 2023-03）。

なぜ2つに分けたか。フロントエンド（Reactページ群）が共有ビルド基盤に強く結合し、「フロントエンドだけ更新したくてもPythonサービス全体を再デプロイする必要があり、大規模ロールアウトは1時間以上」という遅延が発生していた。中央PaaSの枠に押し込めず、用途別PaaSを併存させた のが Yelp の選択だ。

Yelpの設計哲学で印象的なのは、PaaSTA採用時の意思決定だ。「車輪の再発明を避けつつ、各コンポーネントが独立しており シーム（接合部）が残る 構成」 を意図的に選んだ。これにより特定ベンダーや特定OSSプロジェクトへのロックインを避けた。Heroku など外部PaaSを採用しなかった理由はここにある。

これは「単一の正解を作って全員に乗せる」という発想とは対極だ。Paved Road を 複数本 敷く。それぞれの「道」は用途に最適化されている。Yelp の選択は、「一つのプラットフォームに全機能を詰め込むことの限界」を早い段階で認めた結果として読める。

4. Spotify ── Golden Path と Backstage Software Templates の合流

Spotify の Golden Path は、第2話で扱った Backstage と密接に統合されている。Backstage Software Templates（Scaffolder） で「Golden Path に沿ったテンプレート」からサービスを生成し、Explore セクション で「祝福された（blessed）」ツールを発見できる仕組み。

Spotify の独自性は、Golden Path が コードと文書とポータルの三位一体 で実装されていることだ。

Spotify Golden Path の三層構造：
  1. Backstage Software Templates（Scaffolder）
     → 「Golden Path に沿った骨格」をワンクリックで生成
  2. Explore セクション
     → 「祝福された（blessed）」ツールを発見可能に
  3. TechDocs（MkDocs ベース）
     → ステップバイステップのドキュメントが Portal 内で完結

新規Squadが「Spotifyのバックエンドサービスを作る」と決めたら、Backstageのテンプレートから生成し、その時点で認証・監視・CI/CD・ロギングが配線済みで動く。これがSpotify版「最も楽な選択肢」の実装だ。

---

Paved Road テンプレートの実例（擬似コード）

ここで具体性を補うために、Paved Road の「テンプレート」がどんな形をしているか、擬似コードで示す。Backstage Software Templates の実例に近い形だ。

# template.yaml（Backstage Software Template の例）
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: backend-service-paved-road
  title: バックエンドサービス（Paved Road）
  description: 認証・監視・CI/CD・SLO が組み込まれた Go サービスを 5 分で立ち上げる
  tags:
    - golden-path
    - go
    - kubernetes
spec:
  owner: platform-team
  type: service

  parameters:
    - title: サービス基本情報
      required: [name, owner, businessUnit]
      properties:
        name:
          type: string
          description: サービス名（kebab-case）
          pattern: '^[a-z][a-z0-9-]*$'
        owner:
          type: string
          description: オーナー Squad
        businessUnit:
          type: string
          enum: [search, recommendation, payment, infra]
        sloAvailability:
          type: number
          description: 月次可用性 SLO（%）
          default: 99.9

  steps:
    # 1. リポジトリ作成（オーナー・トピックタグ含む）
    - id: fetch-base
      name: Fetch base template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}

    # 2. GitHub にプッシュ（CODEOWNERS 自動設定）
    - id: publish
      name: Publish to GitHub
      action: publish:github
      input:
        repoUrl: github.com?owner=mycompany&repo=${{ parameters.name }}
        defaultBranch: main
        protectDefaultBranch: true

    # 3. Backstage Catalog に登録
    - id: register
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

    # 4. CI/CD パイプライン配線（GitHub Actions）
    - id: ci
      name: Provision CI pipeline
      action: ci:provision
      input:
        template: paved-road-go-service
        slo: ${{ parameters.sloAvailability }}

    # 5. 監視ダッシュボード自動生成
    - id: observability
      name: Provision observability
      action: datadog:provision
      input:
        slo: ${{ parameters.sloAvailability }}
        team: ${{ parameters.owner }}

このテンプレートに乗ると、開発者がZennに書く「サービス立ち上げの最初の1日」のチェックリストが、ほぼ全部 自動的に 満たされる。

✅ Paved Road に乗った場合の自動装填：
  - GitHub リポジトリ（CODEOWNERS・ブランチ保護込み）
  - Backstage Catalog 登録
  - CI/CD パイプライン
  - SLO 設定済み Datadog ダッシュボード
  - PagerDuty 連携
  - シークレット管理の Vault パス
  - Kubernetes Namespace と権限

❌ Paved Road から外れた場合：
  - 上記すべてを自分で配線する責任
  - セキュリティレビューを単独で受ける
  - ライブラリバージョンアップを追随する
  - インシデント時のオンコールを自分で用意

開発者は「Paved Road から外れる自由」を持っている。だが外れる時、「外れる正当な理由」と「自前運用するコスト」を秤にかける ことになる。多くの場合、「Paved Roadに乗る」が合理的選択になるよう、デフォルトの体験が磨かれている。これが「強制せず、自然と乗ってもらう」設計の正体だ。

---

摩擦を消すこと自体が Paved Road になる

ここで、消費財メーカーである adidas の事例が参考になる。

adidasは2017年頃、Kubernetes プラットフォーム移行を始めた。Daniel Eichten（当時 Senior Director, Platform Engineering）の証言によれば、移行前は 開発VMを入手するだけでも、最短30分・最悪1週間 かかっていた（adidas Case Study, kubernetes.io）。

申請には「目的・プロジェクト名・責任者・コストセンターへの連絡」が必要だった。開発者がツール本体に到達する前のオーバーヘッド が膨大だったわけだ。

adidasのプラットフォーム改革で本質的だったのは、新しいツールを導入したことではない。事前申請という摩擦を消したこと だ。Fernando Cornago（VP Engineering）の言葉として「私たちのKubernetesプラットフォームは、エンジニアによるエンジニアのためのもの」が引用されている。

結果は劇的だった。

adidas プラットフォーム改革の数字：
  - 6ヶ月で e-commerce サイトの 100% を Kubernetes に移行
  - 4,000 pods, 200 nodes, 月 80,000 ビルド
  - リリース頻度：4-6 週ごと → 1日 3-4回
  - ロード時間：半減

これは何を意味するか。Paved Roadの本質は、新しい技術を導入することではなく、既存の摩擦を構造的に消すことにある。事前申請のフォーム、承認プロセス、待ち時間、説明コスト──これらが消えた瞬間に、開発者は自然とそのプラットフォームに乗る。adidasの「Paved Road」という名前はブログには登場しないが、本質的にやっていることは同じだ。

---

共通パターンの抽出

4社（と adidas）を見て、共通する設計原則を抽出すると次のようになる。

1. 「自由を奪わずに、デフォルトを最も楽にする」

Airbnb の Anna Sulkina の言葉として知られる “Make common easy and uncommon possible”（共通は簡単に、例外は可能に）は、4社共通の根本思想を端的に表している（LinearB Blog（二次情報））。

2. 「外れる自由」と「外れた場合のコスト」をセットで提示

✅ 良い Paved Road：
   「これに乗ってください。乗ると認証・監視・CI/CD が自動。
    外れる自由はあります。ただし外れた場合は、これらすべてを自前で運用してください」

❌ 悪い Paved Road：
   「これを使ってください」（強制）
   「好きにしてください」（無関心）

3. 摩擦の構造的削減

申請フォーム、承認プロセス、説明コスト──これらは Paved Road を 採用する側 の摩擦だ。新しい技術スタックを導入する前に、既存の摩擦を消すことに投資する方が、採用率が上がる。

4. テンプレート + ドキュメント + サポートの三位一体

Spotifyの Golden Path 三層構造（Templates / Explore / TechDocs）が代表例だ。コードだけ、ドキュメントだけ、サポートだけ、では Paved Road にならない。

---

アンチパターンへの伏線：Mandated Adoption

ここまで「強制せず誘導する」設計を見てきた。だが組織が大きくなったり、コンプライアンス要求が強くなると、しばしば「強制」への誘惑が生じる。「採用率が低いなら、トップダウンで強制すればいい」と。

これは第10話で扱うアンチパターン「Mandated Adoption（強制採用）」になる。症状は 採用率は高いのに満足度が低い。隠れたシャドーITが増える（Jellyfish: 9 Platform Engineering Anti-Patterns）。

Tom Barkan-Benkler（Spotify）はInfoWorldでこう語っている。

「チームに オーナーシップを与えること。彼らに採用を強要するな」

— InfoWorld: 8 Platform Engineering Anti-Patterns

なぜ強制が機能しないか。強制採用がプラットフォームチームから「魅力的なプロダクトを作る動機」を奪う からだ。「強制したから使ってもらえる」と思った瞬間、UXを磨く動機が消える。やがて使われるが満足度の低いプラットフォームが完成し、やがてシャドーITに侵食される。

Netflixが「Freedom & Responsibility」と書き、Twilioが「ガードレール」と書き、Spotifyが「Golden Path（一本だが任意）」と書いたのは、すべてこのアンチパターンを 構造的に避けるための設計 だ。

---

4社比較サマリ

観点	Netflix	Twilio	Yelp	Spotify
用語	Paved Road	Paved Path	(明示語なし)PaaSTA/Gondola	Golden Path
強制度	中（外れる自由＋責任）	中（ガードレール比喩）	弱〜中（用途別併存）	弱〜中（Backstage統合）
中核要素	Spinnaker, Nebula, Managed Delivery	Admiral（Pipeline 宣言）	PaaSTA + Gondola	Backstage Software Templates
文化	Freedom & Responsibility	”We don’t have rules”	シーム残存・脱ロックイン	Squad自律性＋祝福ツール
数値の代表	週デプロイ多数・OSS化	立ち上げ40日→20日、ビルド12h→改善	1.5年以上本番、用途別併存	~700 Squad / 3,000+社
単一/複数IDP	単一基盤＋Console	単一IDP（Admiral）	複数併存（用途別）	単一統合（Backstage）

---

自社で Paved Road を始めるとき

最後に、このシリーズの読者──プラットフォームチームの立ち上げを任されたテックリード──向けに、最初の1本の Paved Road をどう設計するかの観点を示す。

Step 1: 最も摩擦の高い「型」を1つ選ぶ

「全社のすべてのワークロード」を対象にしない。最も頻度が高く、最も摩擦が高い1パターン を選ぶ。

✅ 良い選択：
  - 「新規バックエンドサービスの立ち上げ」
  - 「データパイプラインの新規追加」
  - 「フロントエンドアプリの新規追加」

❌ 悪い選択：
  - 「すべてのワークロードに対応した汎用テンプレート」
  - 「最も複雑なエッジケースに対応したテンプレート」

Step 2: 「乗った場合に何が自動で得られるか」を明文化

Paved Road の 価値命題 を明確にする。曖昧だと採用されない。

例：「このテンプレートに乗ると、以下が自動で配線されます」
  - GitHub リポジトリ + CODEOWNERS
  - CI/CD パイプライン（PR でステージングデプロイまで）
  - SLO 99.9% に設定済みの Datadog ダッシュボード
  - PagerDuty 連携（オーナー Squad へ通知）
  - シークレット管理（Vault 統合）
  - Kubernetes Namespace と適切な RBAC

Step 3: 「外れる場合のコスト」を明文化

強制ではなく、情報提供 として外れる場合のコストを提示する。

例：「このテンプレートを使わない場合、以下を自分で対応してください」
  - セキュリティレビューを個別に受ける（〜2週間）
  - SLO 監視と PagerDuty 連携を自前で構築（〜1週間）
  - シークレット管理の方針をセキュリティチームと合意

Step 4: 摩擦そのものを削減する

新ツールの導入と並行して、既存の摩擦 を消す。adidasがやったことだ。事前申請フォーム、承認プロセス、説明コスト──これらを残したまま Paved Road を敷いても、開発者は「乗る前」で詰まる。

---

次章への接続

ここまで2章を通じて、Spotify・Netflix・Twilio・Yelp・Pinterest・Mercari・adidas という規模の大きい企業の選択を見てきた。これらは数百〜数千エンジニアを抱える組織の話だ。

第4話「内製 IDP の極北」では、規模がさらに大きくなった時──Uber（4,000+エンジニア・4,500マイクロサービス・週10万デプロイ）、adidas（消費財メーカーとして K8s 全面採用）、Zalando（4万エンティティ・1,000+エンジニア）──「Backstageを採用するかどうか」「自社で全部作るかどうか」という選択が、規模ゆえに どのように制約されるか を見る。

そして第5話以降、日本のSaaS企業（SmartHR・Money Forward・Sansan）、走り始めスタートアップ（Tailscale・PostHog・Bitkey・Cloudbase）、中規模成長期の企業（10X・LayerX・カケハシ・freee・Visional）の選択を見ていく。

---

問い：あなたの会社で、もし「Paved Road を1本だけ敷ける」としたら、それはどの「型」のサービス立ち上げか？　その1本に乗ったとき、開発者が自動で得られるものを5つ書き出してみよう。書き出せない項目があるなら、それがまだ「未舗装の道」だ。

---

参考文献

Spotify Golden Path

• Spotify Engineering: How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem (2020-08, Gary Niemen)
• Backstage 101 — Spotify for Backstage

Netflix Paved Road

• Netflix TechBlog: Full Cycle Developers at Netflix (2018-05)
• Netflix TechBlog: How We Build Code at Netflix
• InfoQ: The Paved PaaS for Microservices at Netflix (Yunong Xiao QCon NY 2017)
• Spinnaker Community Blog: Managed Delivery
• PlatformCon talk: Netflix Platform Console
• The New Stack: How Netflix Built Spinnaker

Twilio Admiral

• Built In: How a Brilliant Platform Engineer Saved Twilio From ‘Absolute Disaster’
• InfoQ: Platforms at Twilio — Unlocking Developer Effectiveness

Yelp PaaSTA / Gondola

• Yelp Engineering Blog: Introducing PaaSTA (2015-11)
• Yelp Engineering Blog: Gondola — an internal PaaS architecture for frontend app deployment (2023-03)

adidas

• adidas Case Study — kubernetes.io
• The secret to cloud native success for adidas — CNCF blog (2019)
• How the Adidas Platform Team Reduced the Cost of Running Kubernetes Clusters — InfoQ (2024-07-31)

アンチパターン

• InfoWorld: 8 Platform Engineering Anti-Patterns
• Jellyfish: 9 Platform Engineering Anti-Patterns
• Octopus Deploy: Platform Engineering Patterns and Anti-patterns

＋ － ⟳ ✕