目次を表示する

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

第8話 Platform-as-a-Product ── プラットフォームを内部プロダクトとして運営する

場面

半年かけて作ったプラットフォームを、誰も使わない。

社内ローンチ会を開き、ドキュメントを書き、Slackで告知した。最初の数週間は、何人かが触ってくれた。ところが3ヶ月経つと、各チームは元の手作業デプロイに戻っている。「使いたいのは山々だが、自分たちのワークフローに合わない」「ドキュメントを読む時間がない」「結局、自前で書いた方が早い」。

CTOから問われる。「で、これは費用対効果に見合っているのか？」

答えに詰まる。MAU（月間アクティブユーザー）は10チーム中3チーム。コミットメッセージから「移行完了」と書かれたPRは1割程度。プラットフォームチームは消耗している。「もう半年やれば回ると思います」と返すしかない。

このシーンは、Platform Engineeringにまつわる失敗の中で 最も頻発する典型 だ。第10話で詳述するが、業界では「Field of Dreams（“Build it and they will come” 妄想）」というアンチパターン名がついている。

このアンチパターンへの解毒剤として、業界が辿り着いた答えが Platform-as-a-Product だ。プラットフォームを「インフラ提供」ではなく「内部プロダクト」として運営する。開発者を「ユーザー」、開発チームを「内部顧客」と呼び、プロダクトオーナーを置き、ロードマップを引き、マーケティングする。

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

  • Platform-as-a-Productを構成する5つの中核要素を、自社のプラットフォームで実装する道筋を描ける
  • 「採用率が低いのは規律違反ではなくプロダクトの問題」という発想転換の意味を、各社の実例で説明できる
  • 「TVP（Thinnest Viable Platform）から始める」アプローチを、自社の規模で実行する具体策を持てる

なぜ「内部プロダクト」と呼ぶのか

Platform-as-a-Productの起源は、第1話で触れた2つの源流の合流点にある。

graph LR
    A[Team Topologies 2019<br/>Platform Team章] --> C[Platform-as-a-Product<br/>2020-2022 普及]
    B[Spotify Backstage 運用<br/>2016-2020] --> C
    C --> D[CNCF Whitepaper<br/>2023]
    C --> E[Fournier & Nowland 書籍<br/>2024]
    A -.「Treat the platform as a product/service」.-> C
    B -.「Backstageの最大の機能は<br/>マインドセットそのもの」.-> C

『Team Topologies』（2019）の Platform Team 章で、SkeltonとPaisは「Treat the platform as a product / service」を原則として提示した。同じ頃、Spotifyは社内でBackstageを育てていた。2020年のOSS化に際してSpotifyは、後にこの言葉を強調するようになる。「Backstageの最大の機能は本体ではなく、platform-as-a-productのマインドセットそのものだ」（Platform Engineering org: Platform as a Product talk）。

OSSとして配布されているのはコードだ。だが、それを動かしている 思想 こそが本体である──Spotifyはそう言っている。

なぜ「内部プロダクト」と呼ぶのか。普通のインフラチームと何が違うのか。決定的な違いは、「強制」を放棄しているかどうか だ。

普通のインフラチームは、CTO通達やセキュリティ基準を背景に、組織全体に何かを「強制できる」前提を持っている。新しいデプロイ基盤を全プロジェクトに展開する。新しいセキュリティスキャンを必須化する。それが普通のインフラチームの役割だ。

Platform-as-a-Productはこれを 意図的に手放す。新しい基盤を強制せず、開発チームに「選んで」もらう。低採用率は「規律違反」ではなく「プロダクトの問題」として扱う。これによって、プラットフォームチームには「魅力的なプロダクトを作らなければならない」という構造的な動機が生まれる。

中核要素 1：Internal Customer の特定

Team Topologies と CNCF Whitepaper を統合すると、Platform-as-a-Product の中核要素は5つに整理できる。順番に見ていく。

最初の要素は Internal Customer の特定 だ。

用語意味
User（ユーザー）プラットフォームを実際に触る個々の開発者
Internal Customer（内部顧客）プラットフォームを採用するかどうかを決める開発チーム

外部向けプロダクトでも、ユーザーと顧客は分かれる。SaaSなら「使う人（社員）」と「契約する人（情シス・経営）」が別だ。Platform-as-a-Productはこの構造を内部に持ち込む。

実装上、これが何を意味するか。プラットフォームチームは 2種類のリサーチを回す必要がある。

  • ユーザーリサーチ：個々の開発者がどこで詰まっているか。CLI のエラーメッセージは分かりやすいか。チュートリアルは追えるか。
  • 顧客リサーチ：開発チームのリードやEMが、なぜこのプラットフォームに移行する／しない判断を下したか。
❌ 普通のインフラチームの問い：
   「全チームに新しいデプロイ基盤を展開する。何月までに完了させる？」

✅ Platform-as-a-Product の問い：
   「現時点で3チームが採用している。採用しなかった7チームは何で詰まったのか。
    その障害を取り除けば、次に2チームが乗り換えてくれるか？」

中核要素 2：明確なロードマップ（Platform PMを置く）

第二の要素は 明確なロードマップ だ。プロダクトオーナーまたは Platform PM を置く。

国内の実例で先行しているのが SmartHR だ。マルチプロダクト戦略を支える共通基盤チーム（権限基盤、プロダクト連携、課金基盤、従業員データ基盤の4チーム）に、テクニカルプロダクトマネージャー（テクニカルPM） ポジションを設置している。

テクニカルPMの役割は明確だ。

  • 内部の開発者を「顧客」とみなしたプロダクトマネジメント
  • 共通基盤の優先順位付け（RICEスコア+開発者フィードバックなど）
  • 「大きく作りがち」な傾向への歯止め

SmartHRが過去にマルチプロダクト戦略を一気に展開しようとして失敗した経験から、この役割が生まれた。「内部の開発者を顧客とみなす」プロダクトマネジメント思想を組織レベルで採用するためには、その役割を担う具体的なポジションが必要だった、ということだ。

海外では HelloFresh が同じ構造を持つ。HelloFreshのプラットフォーム組織は4つに分かれている。

チーム役割
Engineering ExperienceDX担当（Senior Product Managerがリード）
Cloud Runtimeインフラ
Site Reliability信頼性
Data Infrastructureデータ基盤

特筆すべきは Engineering Experience を Senior Product Manager がリードしている ことだ。「プラットフォームをプロダクトとして開発者に提供する」プロダクトマインドセットが、組織図のレベルで宣言されている。

中核要素 3：採用は任意（強制せず、選んでもらう）

第三の要素は 採用の任意性 だ。これが Platform-as-a-Product の最も特徴的な原則であり、最も誤解されやすい部分でもある。

CNCF Whitepaper と Jellyfish の整理を統合するとこうなる。

低採用率は「コンプライアンス問題」ではなく「プロダクト課題」である。

開発チームがあなたのプラットフォームを採用しないとき、それは規律違反ではない。プラットフォームに採用されない理由がある ということだ。可能性は多岐にわたる。

  • 既存の手作業の方が、移行コストを払うより楽
  • ドキュメントが追えない（オンボーディング体験の問題）
  • 自分たちのワークフローに合わない（カスタマイズ性の問題）
  • そもそも知らない（マーケティングの問題）

普通のインフラチームなら「全社員に通達」で解決できる。Platform-as-a-Productはそれを禁じ手にする。代わりに、**「移行コストを下げる」「ドキュメントを書き直す」「カスタマイズ性を上げる」「社内マーケティングをする」**で乗り越える。

第3話で扱った Paved Road / Golden Path の思想がここに直結する。Twilioの「ルールはない、ガードレールがある」、Spotifyの「Golden Pathは強制ではない」、Netflixの「Paved Roadから外れる自由はある、ただし運用責任は自分で負う」──これらはすべて、採用任意性を技術的に実装した形だ。

採用任意の原則は、第10話で扱う「Mandated Adoption（強制採用）」アンチパターンへの解毒剤でもある。強制採用は、見た目の採用率を上げる代わりに、プラットフォームチームから「魅力を高める動機」を奪う。長期的にはプラットフォームの劣化を招く。

中核要素 4：プロダクトメトリクスで測定する

第四の要素は プロダクトメトリクスでの測定 だ。

普通のインフラチームの成功指標は「チケット解決時間」や「インシデント数」だ。Platform-as-a-Productはこれを切り替える。

普通のインフラチームPlatform-as-a-Product
チケット解決速度採用率（Adoption Rate）
インシデント数開発者NPS / 満足度
稼働率Onboarding時間（初回デプロイまでの時間）
デプロイ回数Time to Value（TTV、価値が出るまでの時間）

国内では Sansan の HEART フレームワーク がプロダクトメトリクスの典型だ。Google の HEART フレームワーク（Happiness / Engagement / Adoption / Retention / Task Success）を社内向けプラットフォーム「Orbit」の評価に適用している。Orbitの利用やマージ活動はQ4 2024 → Q1 2025で定量的に増加した、という形でレポートされている。

加えて、RICEスコア + 開発者フィードバック で改善優先度を決める運用が定着している。RICEは Reach / Impact / Confidence / Effort の頭文字で、外部向けプロダクトのプロダクトマネジメントで定番の優先度付け手法だ。それを内部向けプラットフォームに持ち込んでいる。

これは第7話で見た freee の「目標数値ではなく改善能力（capability）に焦点」というガードレールと表裏一体だ。**メトリクスは「追うべき北極星」ではなく「現状を映す鏡」**として使う。

中核要素 5：マーケティングと社内アドボカシー

第五の要素は マーケティング・社内アドボカシー だ。Platform Engineering コミュニティで広く引用される一節がある。

Even the best products don’t sell themselves.（最高のプロダクトでも、勝手には売れない）

外部向けSaaSであれば、誰もマーケティングを軽視しない。LP、デモ動画、SEO、セールスエンゲージメント──「作ったら勝手に売れる」とは誰も思わない。ところが内部向けプラットフォームになると、なぜか「作って告知すれば使ってもらえる」と期待してしまう。

社内マーケティングの実例を挙げる。

  • 社内開発者コミュニティ（SmartHR）：プロダクト基盤チームが各プロダクトチームの開発者と週次で集まり、共通基盤への課題・フィードバックを循環させる。新機能のローンチもこの場で告知される
  • オンボーディングコンテンツ：単なるREADMEではなく、5分の動画 + ハンズオンチュートリアル + よくある質問
  • 採用率ダッシュボード：誰がいつ採用したかを社内に公開する。社内の「先進事例」を作る
  • アンバサダー制度：先行採用したチームのメンバーに、他チームへの説明役を担ってもらう

これらは全て、プラットフォームチームの工数の一部を「告知・教育・対話」に意図的に振り向けることを意味する。エンジニアの本能としては「コードを書く方が偉い」という感覚が残るが、Platform-as-a-Productは「マーケティングもプロダクト開発の一部」と位置づける。

各社の実装比較

5社のPlatform-as-a-Product実装を、5つの中核要素に沿って整理する。

会社Internal Customerロードマップ・PM採用任意メトリクスマーケティング
SpotifySquad（6-12人）プラグイン拡張モデルでSquadが共同所有Golden Pathは推奨、強制なしBackstageの内部利用率（〜700 Squad）OSS化そのものが社内外マーケに
MercariプロダクトチームDirector of Platform Engineeringが「Platform as a Product」を明文化Golden Path推奨アクティブリポジトリ数、SFD利用統計DX単一チーム化で「窓口」を1つに
HelloFresh500+エンジニアの各チームEngineering Experienceを Senior PMがリードBackstageは選択肢として提供開発者満足度・Backstage採用率プラットフォームを「プロダクト」と社内発信
SmartHRプロダクトチーム（マルチプロダクト体制）テクニカルPMポジション新設4つの基盤チームへの導入は段階的採用プロダクト数、開発者FB週次の社内開発者コミュニティ
Sansanプロダクトチーム + Bill One等の独立SREチームPlatform Engineering Unit + Embedded SREOrbitへの移行は段階的HEARTフレームワーク、利用・マージ活動”Platform as social product”と発信

各社の選択を一つずつ見てみよう。

Spotify：プラグイン拡張で「採用任意」を技術的に実現

第2話で詳述するが、Spotify は Backstage を「プラグイン拡張モデル」として設計した。Backstage本体は薄い枠組みだけを提供し、各 Squad（あるいは社外コントリビュータ）が自分のドメインのプラグインを書く。これによって、Squad は 「Backstage を採用するか否か」ではなく「自分たちのプラグインを Backstage に書くか否か」 を選ぶ立場になる。採用が「Yes/No」ではなく「どこまで」のグラデーションになる。

これは Platform-as-a-Product の「採用任意」原則の、最も技術的に巧妙な実装と言える。

Mercari：「Platform as a Product」の明文化と DX 単一チーム化

Director of Platform Engineering が登壇で繰り返し強調しているのが、Platform as a Product を組織の公式言語にすることだ。プラットフォームと機能チームの境界面（= 開発者向け UX）を、1つの DX チームが完全所有する設計を採用している。境界面を分散させると、各チームが部分最適に走る。ひとつのチームが「内部顧客の体験全体」に責任を持つことで、Platform-as-a-Productが構造的に保証される。

Mercariの内製ポータル Single Front Door (SFD) は、文字通り「ひとつの正面玄関」だ。第2話で見たMercariのSFDが、なぜ複数のCLIや内製ツールを束ねる「Front Door」として設計されたか──その思想的根拠は、ここにある。

HelloFresh：Engineering Experience を Senior PM がリード

500+エンジニアの規模で、プラットフォーム組織を4つ（Engineering Experience / Cloud Runtime / SRE / Data Infra）に分け、Engineering Experience を Senior Product Manager がリードする構成は、Platform-as-a-Product を最もシンプルに体現している。「プラットフォームを開発者にプロダクトとして提供する」という宣言が、組織図そのものに刻まれている。

SmartHR：テクニカルPM の新設

第5話・第7話でも触れたが、テクニカルPMポジションの新設は SmartHR の Platform-as-a-Product 実装の核心だ。社内の開発者を「顧客」とみなして、共通基盤の機能を プロダクトのバックログ として運営する。週次の社内開発者コミュニティで顧客の声を集める運用は、外部向けSaaSのカスタマーサクセスのモデルそのものだ。

Sansan：「Platform as social product」と TVP

最も象徴的なフレーズが、Sansanの “Platform as social product” だ。「social」という言葉が含意するのは、プラットフォームが人と人の関係を媒介する装置であるということ。プラットフォームチームが一方的に提供するのではなく、内部顧客との対話・採用率の交渉・改善の優先度付けが、プラットフォームの一部として組み込まれている。

加えて、Sansanは TVP（Thinnest Viable Platform）から始めて段階的に拡張するアプローチを明示している。最初から完成形を作らず、最小限のセットで価値が出る形を作って、需要があるところだけ厚くしていく。次章（第9話）で詳述するが、これはTeam Topologiesの中核概念だ。

TVP：「Wikiページ1枚でもよい」

Platform-as-a-Productを実装するときに最も重要なメンタルモデルが、Thinnest Viable Platform（TVP） だ。Team Topologies の言葉を引く。

A TVP is a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform. — Team Topologies: What is a TVP?

要は「最小限で価値が出る形を作って、需要があるところだけ厚くしていく」。

具体的には何か。Team Topologies は驚くほどシンプルな例を挙げる。プラットフォームは Wiki ページ1枚でもよい。

「現在推奨されているデプロイ手順はこちらです」 「監視ダッシュボードの作り方はこちら」 「セキュリティ・コンプライアンス要件はこちら」 「困ったらこのSlackチャンネル」

このWikiページ1枚も、立派なプラットフォームだ。TVPは「物理的な実装の薄さ」ではなく 「ユーザーから見たときの薄さ」 が肝だ。情報が散らばっていない。意思決定がはっきりしている。問い合わせ先が分かる。これだけで開発者の認知負荷は劇的に下がる。

❌ よくある失敗：
   1年かけてBackstageの全機能を実装し、CI/CDも作り直し、
   Terraformの全リファクタリングが終わってから「使ってください」と発表

✅ TVPアプローチ：
   1週間でWikiページを書き、推奨ツール一覧を載せ、Slackチャンネルを作る
   → 使ってもらいながら、需要のある部分から自動化していく

Sansanのアプローチがまさにこれだ。Orbit を最初から完成形として出すのではなく、TVPから始めて段階的に拡張している。RICEスコアと開発者フィードバックで「次に厚くするのはどこか」を決める。

第9話で詳述するが、TVPと表裏一体の原則として 「3つの実例が出るまで抽象化を待つ」（Rule of Three）がある。プラットフォーム化したい欲求が出たとき、まずは3チームが似たような問題を解いているのを観察する。1チームのために共通化するのは早い。2チームでもまだ早い。3チーム目が出たら、ようやく共通化する。これは Sandi Metz の “Prefer duplication over the wrong abstraction” と同じ思想だ。

「内部顧客」が決定的である理由

ここまで5つの中核要素と TVP を見てきた。全体を貫いている思想は何か。それは、「内部顧客」という概念が決定的であるということだ。

graph TD
    A[インフラチーム<br/>強制でき&#39;る] --> B[活動量メトリクス<br/>チケット数・稼働率]
    A --> C[改善動機が弱い<br/>使われなくても困らない]

    D[Platform-as-a-Product<br/>強制でき&#39;ない] --> E[プロダクトメトリクス<br/>採用率・NPS]
    D --> F[改善動機が強い<br/>使われないと存在意義消失]

    style A fill:#fdd
    style D fill:#dfd

「強制できる」という状態は、一見プラットフォームチームを楽にするように見える。だが実際には、改善する動機を奪う。使ってもらえなくても、存在意義が問われない。やがてプラットフォームは「使うのが面倒」「ドキュメントが古い」「現場のニーズに合わない」という慢性疾患を抱える。

「強制できない」という制約は、一見プラットフォームチームを苦しめるように見える。だが実際には、強い改善動機を埋め込む。使ってもらえなければ、存在意義が消える。だから内部顧客の声を聞き、移行コストを下げ、ドキュメントを磨き、社内マーケティングをする。

第10話で扱うアンチパターン13個のうち、半分以上は「内部顧客」の概念を欠いた結果として発生するものだ。

  • Field of Dreams（誰も使わない）→ 内部顧客の不在
  • Rebranding the Operations Team（看板掛け替え）→ プロダクト思考の欠落
  • Mandated Adoption（強制採用）→ 内部顧客を「ユーザー」に降格
  • Magpie Platform（最新技術ハンター）→ 内部顧客の優先度ではなく好奇心駆動
  • Tracking the Wrong Metrics（誤メトリクス）→ 内部顧客の体験ではなく活動量を測る

「内部顧客」を中心に据えるかどうかで、プラットフォームの運命は分かれる。

✅ 良い運営 / ❌ 悪い運営

Platform-as-a-Product を実装するときの典型的な誤解と、それを避ける選択を整理しておく。

❌ 悪い運営：
   - 「全社員にプラットフォームの利用を通達する」
     → Mandated Adoption。プラットフォームチームから改善動機を奪う

   - 「プラットフォームは便利屋。チケットで依頼してください」
     → Operations Rebranding。普通のインフラチームに退化

   - 「Backstage を入れたから Platform Engineering をやっている」
     → 内部顧客の声を聞かないと、ピカピカのPortalが置物になる

   - 「全機能が完成してから内部公開する」
     → Field of Dreams。半年後には現場のニーズが変わっている

   - 「KPIはチケット解決時間と稼働率」
     → 活動量メトリクス。プロダクトの本質的な価値を測らない

✅ 良い運営：
   - 「採用率が低いチームに『なぜ使わないか』を聞きに行く」
     → 内部顧客リサーチを継続する

   - 「Platform PM ポジションを置く」
     → SmartHR のテクニカル PM、HelloFresh の Senior PM

   - 「TVPから始めて段階的に拡張する」
     → Sansan のOrbit、Wikiページ1枚も立派なプラットフォーム

   - 「採用任意を維持する。低採用率はプロダクト課題として扱う」
     → Spotify の Golden Path、Twilio の Paved Path

   - 「メトリクスは『鏡』として使う。目標化しない」
     → freee のガードレール、Sansan のHEARTフレームワーク

次章へ

Platform-as-a-Product の思想は、組織と技術の両面に染み込んでいく。「内部顧客の認知負荷を下げる」という目的を達成するためには、組織構造そのものを再設計する必要がある。誰がどんなチームに属し、どんな相互作用パターンで動くか──これを構造化する道具が、第9話で扱う Cognitive Load と Team Topologies だ。

Stream-aligned team / Platform team / Enabling team / Complicated-subsystem team の4チームタイプ。X-as-a-Service / Collaboration / Facilitating の3つの interaction mode。TVP の理論的背景。「3つの実例が出るまで抽象化を待つ」原則。Inverse Conway Maneuver の正しい使い方。

これらは、Platform-as-a-Product を 組織のアーキテクチャ として実装するための設計道具だ。次章では、第7話で見た10X・カケハシ・Sansanのハイブリッド型を、Team Topologies の4チームタイプで再解釈しながら、組織設計の原則を整理していく。

問い：あなたの組織では、プラットフォームの「採用率が低い」という事実を、誰かが「規律違反だ」と言っているか、それとも「プロダクトの問題だ」と言っているか。その答えが、Platform-as-a-Productを実装できる組織かどうかを分ける。

参考文献