目次を表示する

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

第10話 アンチパターンと失敗の解剖学 ── 13の罠と脱出法

場面

「Platform Engineering、入れてみたんだけど、なんかうまくいかないんですよね」

カンファレンスの懇親会、別社のSREリードがビール片手にそう言う。話を聞いてみる。Backstageを入れた。Terraformモジュールを整えた。CI/CDも刷新した。だが採用率が伸びない。プラットフォームチームの工数は逼迫している。CTOからは「これ、続ける意味ある？」と問われる。

何が起きているのか。聞いていくと、「ああ、これは典型的なField of Dreamsだ」「いや、Backstageで満足するパターンも入っている」「Bottleneck化の兆候もある」と、複数のアンチパターンが重なっていることに気づく。

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

Platform Engineering は、その失敗を踏まえて生まれた。同じ失敗を繰り返さないために、業界が積み上げてきた失敗事例の地図を整理しておく必要がある。

本章では、13個のアンチパターンを「症状・根本原因・脱出法」の3点セットで解剖する。これは Zenn 執筆原則11に従った形式だ。各アンチパターンは、第8話・第9話で扱った原則の 裏側 として位置づけられる。

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

  • 自社のプラットフォームで起きている問題を、13個のアンチパターンで診断できる
  • 「症状」と「根本原因」を切り分け、組織課題か技術課題かを見分けられる
  • 各アンチパターンに対する「最初の小さなアクション」を持ち帰れる

13のアンチパターン

13個のアンチパターンを、影響範囲で大きく4グループに分けて整理する。

graph TD
    A[戦略・思想の問題] --> A1[1. Field of Dreams]
    A --> A2[2. Operations Rebranding]
    A --> A3[11. 他社模倣]
    A --> A4[13. PaaS mindset]

    B[実装の問題] --> B1[3. Front End First]
    B --> B2[4. Backstage で満足]
    B --> B3[8. Magpie Platform]
    B --> B4[9. Cognitive load 増]

    C[運営・組織の問題] --> C1[5. Mandated Adoption]
    C --> C2[6. Bottleneck 化]
    C --> C3[7. Skill Concentration]
    C --> C4[12. Day 2 軽視]

    D[測定の問題] --> D1[10. 誤メトリクス]

    style A fill:#fdd
    style B fill:#dfd
    style C fill:#ddf
    style D fill:#ffd

順番に見ていく。

アンチパターン1：Field of Dreams（“Build it and they will come” 妄想）

  • 症状：数ヶ月かけて作ったプラットフォームを誰も使わない。開発者は依然として独自の手法でデプロイしている。社内ローンチ会で告知したが、3ヶ月後には誰も触っていない。
  • 根本原因：開発者ヒアリングなし。「作れば使ってもらえる」という建設先行思想。内部顧客の不在（第8話の核心原則の欠如）。
  • 脱出法：MVP（最小限）を1つの高摩擦ペインポイント向けに作り、ユーザー＝開発者と並走しながらイテレートする。社内マーケティングをセットで設計する。最初の3チームに「使ってください」ではなく「一緒に作りませんか」と声をかける。

→ 第8話「Platform-as-a-Product」、第9話「TVP」と表裏一体。

アンチパターン2：Rebranding the Operations Team（運用チームの看板掛け替え）

  • 症状：チケット駆動の働き方が変わらない。インフラ／運用チームが「Platform Engineering Team」に改名されただけで、自治権・プロダクト思考・採用任意性のいずれも導入されていない。看板は変わったが、依頼の入り方も処理の仕方も以前のまま。
  • 根本原因：プラットフォーム化を「組織図の変更」と誤解。プロダクト思考と Self-Service への構造転換が伴っていない。
  • 脱出法：成功指標を「チケット解決速度」から「採用率・開発者速度・onboarding 時間・NPS」に切り替える。Self-Serviceを実装してチケット由来の作業を減らす。Platform PMポジションを置く（第8話の中核要素2）。

→ 第7話で「SREチームの便利屋化」として警告した内容と同じ罠。

アンチパターン3：Building the Front End First（ポータル先行）

  • 症状：ピカピカのBackstageポータルがあるが、その裏で開発者は手作業でデプロイ・環境作成をしている。UIは整っているが、機能の中身がない。
  • 根本原因：Portal = Platform という誤認。UI 美しさを先行投資した結果、自動化エンジンが空っぽ。
  • 脱出法：API・Golden Path・Orchestrator 層を先に作る。「3時間の作業を自動化する見栄えの悪いCLI」のほうが「動かないキラキラPortal」より価値が高い。10X が Backstage より先に Terraform モジュール化に投資した判断は、この罠への解毒剤の一例だ。

→ 第7話の10X事例と対照的。

アンチパターン4：Backstage 導入で満足する（Portal-only Mindset）

  • 症状：「うちはBackstage入れたからPlatform Engineering やってます」と言うが、テンプレート数本とService Catalogだけが動いている。プラグインがほとんどない。
  • 根本原因：Backstage が「組み立て式フレームワーク」であることを軽視。プラグイン開発・Workflow・自動化の実装には専属チームの本格コミットが必要。
  • 脱出法：Backstageは IDP の Developer Control Plane の一部にすぎないと認識する。残り4 Plane（CD/Orchestration、Resource、Monitoring、Security）を埋めない限り価値は限定的。LayerXが Backstage 導入を慎重に検討している姿勢は、この罠を回避する判断と読める。

→ 第7話の LayerX、第2話の Internal Developer Portal 議論と直結。

アンチパターン5：Top-down Imposition / Mandated Adoption（強制採用）

  • 症状：採用率は高いのに満足度が低い。隠れたシャドーITが増える。「使わされている」という不満がSlackで散見される。
  • 根本原因：強制採用がプラットフォームチームから「魅力的なプロダクトを作る動機」を奪う。第8話の中核要素3「採用は任意」の真逆。
  • 脱出法：採用は任意にする。低採用率は「規律違反」ではなく「プロダクトの問題」として扱う。移行コストを下げる、ドキュメントを書き直す、社内マーケティングをする──プラットフォームチームの工数を「魅力を高めること」に振り向ける。

→ 第3話 Paved Road、第8話 Platform-as-a-Product の中核原則。

アンチパターン6：Platform team becomes the bottleneck（プラットフォームチームのボトルネック化）

  • 症状：あらゆる変更要求がプラットフォームチームに集中。開発チームが待ち状態になる。「プラットフォームチームが詰まっているので、リリースできません」というSlackが流れる。
  • 根本原因：(a) 抽象が固すぎてエッジケースをすべてプラットフォーム改修で対処、(b) Skill Concentration（次項）でプラットフォームチームに知識が集中し過ぎ。
  • 脱出法：Self-ServiceとEscape Hatch（生インフラへの逃げ道）を併設。InnerSourceモデルでアプリチームからプラグインを受け入れる。第9話の「Cognitive Leakage を見越した設計」を実装する。

→ 第9話の「Sensible defaults + Escape hatches」と裏表。

アンチパターン7：Skill Concentration Trap（スキル偏在）

  • 症状：シニアがプラットフォームチームに集中し、アプリチームのトラブルシューティング能力が下がる。「俺たち vs 奴ら」分断が発生する。プラットフォームチームのメンバーが辞めると組織全体が機能不全になる。
  • 根本原因：移籍時の知識継承計画なし。プラットフォームチーム＝精鋭、アプリチーム＝消費者という誤った階層化。
  • 脱出法：Embedded engineerローテーションで知識を流通させる。プラットフォーム側のメンバー選定基準にコミュニケーション能力を入れる。カケハシの「隔週SRE横断定例」、Sansanの「教える側として動くEmbedded SRE」は、この罠を回避する典型的な運用だ。

→ 第7話のカケハシ・Sansan事例と直結。

アンチパターン8：Magpie Platform（カササギ・プラットフォーム＝最新技術ハンター）

  • 症状：本番の地味な痛みは放置されたまま、最新技術スタックばかり積み上がる。Service Mesh、eBPF、最新のIaC言語──導入はしたが、5年前の壊れたデプロイパイプラインは放置されている。
  • 根本原因：プラットフォームエンジニアの好奇心駆動。組織痛みではなく技術新規性を成功指標にしている。「カササギ」は光る物に飛びつく鳥のメタファー。
  • 脱出法：地味なproduction課題（遅いテスト、不明瞭なドキュメント、不安定なステージング）を最優先。新技術導入はベースラインメトリクスを取ってから。第8話の「内部顧客の声を聞く」運用が、この罠への解毒剤になる。

→ 第8話 Platform-as-a-Product の「内部顧客リサーチ」原則と対立する罠。

アンチパターン9：Cognitive load を下げるはずが上げてしまう

  • 症状：抽象層が増えたのに、開発者が学ぶべきものは増えている（Score、Helm、Kustomize、Backstage、内部DSL… が全部必要）。「シンプルになるはずだったのに、なぜか覚えることが増えた」と現場が言う。
  • 根本原因：(a) Leaky Abstraction で内部実装が漏れる、(b) 抽象が早すぎて「3つの実例が出る前に共通化」してしまっている、(c) 既存の認知負荷を測らずに足し算している。
  • 脱出法：「3つの実例が出るまで抽象化を待つ」（Rule of Three、第9話）。Team TopologiesのCognitive Load Assessment で削減対象を特定。Sensible defaults + Escape hatches で「逃げ道」を残す。Cognitive Leakage（Thoughtworks）を意識する：抽象に隠した複雑性は、いつか問題として噴き出す。

→ 第9話「Cognitive Load と Team Topologies」の中核警告。

アンチパターン10：Tracking the Wrong Metrics（誤ったメトリクス追跡）

  • 症状：ポータルログイン数やAPI呼び出し数は健全だが、ROIの説明ができない。「メトリクスは健全」と言いながら、CTOから「で、これは何の役に立っているのか」と問われて答えに詰まる。
  • 根本原因：活動・出力を測っており、ビジネス成果や開発者体験を測っていない。
  • 脱出法：Time-to-Market、onboarding時間、インフラコスト削減、NPS、TTV（Time to first deploy）を測る。MONK metrics（Market share / Onboarding time / NPS / Key customer metrics）という整理もある。freeeの「目標数値ではなく改善能力（capability）に焦点」というガードレール、Visionalの SODA フレームワークは、この罠を回避する具体的な実装だ。

→ 第7話 freee・Visional事例、第8話の中核要素4「プロダクトメトリクス」と直結。

アンチパターン11：Copying the Platforms of Others（他社模倣）

  • 症状：Spotify や Netflix の事例をそのまま自社に持ち込み、規模が違うのに同じ構成を試して破綻。20人のスタートアップが Backstage + Spinnaker + Argo + Crossplane のフルスタックを構築しようとして、運用が回らない。
  • 根本原因：参照アーキテクチャを「青写真」と誤解し、自社のスケール・組織構造・成熟度を考慮していない。
  • 脱出法：参照アーキテクチャはガイダンスとして使う。CNCF Platform Engineering Maturity Model で自分たちの段階（Provisional / Operational / Scalable / Optimizing）を判定し、それに見合った投資量にする。第6話で見たレバテックの「Platform Engineeringを意図的にやめた」判断は、この罠を回避した賢明な選択だ。

→ 第6話の「規模に合わない選択をしない」原則と直結。

アンチパターン12：Day 2 を考えない（Under-invested Platforms）

  • 症状：ローンチ後にメンテナンスが止まり、ドキュメントが古びる。開発者は手作業に戻る。プラットフォームチームのメンバーが他プロジェクトに異動し、誰も保守していない状態に。
  • 根本原因：プラットフォームを「プロジェクト（完成日あり）」として扱っている。プロダクトとしての永続的投資が計画にない。
  • 脱出法：恒久的な Platform Product Team を設置。SLA／ロードマップ／予算を年単位で確保。ローンチが「終わり」ではなく「Day 1」だと組織で合意する。第8話の中核要素2「明確なロードマップ」を持つ Platform PM の存在が、Day 2 を持続させる装置になる。

→ 第8話の Platform-as-a-Product 思想の永続化。

アンチパターン13：Platform-as-a-Service mindset without product mindset

  • 症状：「うちのIDPはAWSやGCPみたいなものだ」とPaaS的に売り出すが、内部顧客との対話・採用率測定・ロードマップ管理がない。インフラを提供しているだけで、プロダクトとしての改善サイクルが回っていない。
  • 根本原因：「インフラ提供」という発想で止まり、「プロダクト運営」が欠落。第8話の5つの中核要素のうち、4つ以上が欠けている。
  • 脱出法：Platform PM役を立て、Platform-as-a-Product原則（第8話）を全面適用。内部顧客リサーチを始める。プロダクトメトリクス（採用率・NPS・onboarding時間）に切り替える。社内アドボカシーを始める。

→ 第8話 Platform-as-a-Product そのものの欠落。

分類まとめ表

13個のアンチパターンを、症状と根本原因で並べ直す。自社の状況を診断する道具として使ってほしい。

#アンチパターン症状根本原因関連章
1Field of Dreams誰も使わないユーザーリサーチなし／内部顧客の不在第8話
2Operations Rebranding看板だけ／チケット駆動が変わらないプロダクト思考の欠落第7話
3Front End First中身が空のキラキラPortalPortal = Platform の誤認第7話・第2話
4Backstage で満足機能が薄い／プラグインがないPortalは Platform の一部に過ぎない第7話・第2話
5Mandated Adoption高採用率／低満足度プロダクト動機の喪失第3話・第8話
6Bottleneck 化チームが詰まる抽象固すぎ＋Self-Service なし第9話
7Skill Concentration知識偏在／We vs They 分断移籍時の継承計画なし第7話
8Magpie Platform新技術病／地味痛み放置好奇心駆動の優先順位第8話
9Cognitive load 増学ぶべきものが増える早期抽象化＋Leaky Abstraction第9話
10誤メトリクスROI不明活動量を測っている第7話・第8話
11他社模倣スケール不一致参照を青写真と誤認第6話
12Day 2 軽視ローンチ後劣化プロジェクト思考第8話
13PaaS mindsetプロダクト運営なしインフラ提供で止まる第8話

アンチパターンの相関：複数が同時に発生する

実務でアンチパターンを観察するとき、ひとつだけ起きていることは稀だ。複数が連鎖して起きることがほとんどだ。

graph LR
    A[1. Field of Dreams] --> B[2. Operations Rebranding]
    A --> C[10. 誤メトリクス]
    B --> D[5. Mandated Adoption]
    C --> E[8. Magpie Platform]
    D --> F[6. Bottleneck化]
    E --> G[9. Cognitive load 増]
    F --> H[7. Skill Concentration]
    G --> I[12. Day 2 軽視]
    H --> I

    style A fill:#fdd

典型的な連鎖を見てみよう。

連鎖A：戦略不在から組織硬直へ

  1. ユーザーリサーチなしで作る（Field of Dreams）
  2. 使われないので「強制」する（Mandated Adoption）
  3. 開発者の本当のニーズが見えなくなる（誤メトリクス：ログイン数だけ追う）
  4. プラットフォームチームが「依頼処理」で詰まる（Bottleneck化）
  5. シニアが集中して属人化（Skill Concentration）

連鎖B：技術中心の罠

  1. 最新技術を追う（Magpie Platform）
  2. 抽象が増える（Cognitive load 増）
  3. キラキラPortalができる（Front End First）
  4. Backstageを入れて満足する（Backstage で満足）
  5. 地味なメンテが回らない（Day 2 軽視）

連鎖C：思想転換の不徹底

  1. PaaS的に売り出す（PaaS mindset）
  2. プロダクト運営がない（Operations Rebranding）
  3. 他社事例を青写真として持ち込む（他社模倣）
  4. 自社の規模に合わずに破綻

連鎖を見ると、アンチパターンは個別の問題ではなく、思想的な根のレベルで繋がっていることが分かる。第8話の Platform-as-a-Product と第9話の Cognitive Load / Team Topologies は、これらの連鎖を 一段上のレイヤーで断ち切るための原則だ。

「症状」を観察するためのチェックリスト

自社の状況を診断する際の観察ポイントを整理しておく。

✅ 戦略・思想レベルの観察
   □ プラットフォームチームのKPIに「採用率」が入っているか
   □ 「使ってもらえないのはプロダクトの問題」と言える文化があるか
   □ Platform PM ポジションがあるか（あるいはそれに準ずる役割）
   □ ロードマップが内部公開されているか

✅ 実装レベルの観察
   □ Portal だけでなく、その裏の自動化エンジンが動いているか
   □ 抽象を1つ追加するときに、3つの実例が揃っているか
   □ Sensible defaults + Escape hatches が両立しているか
   □ 新技術導入時にベースラインメトリクスを取っているか

✅ 運営レベルの観察
   □ 強制採用ではなく、移行コストを下げる工夫をしているか
   □ Self-Service が機能して、チケット由来の作業が減っているか
   □ Embedded engineer ローテーションがあるか
   □ Day 2 のための予算と人員が年単位で確保されているか

✅ 測定レベルの観察
   □ 活動量メトリクス（ログイン数等）に依存していないか
   □ プロダクトメトリクス（採用率・NPS・TTV）を取っているか
   □ メトリクスを「目標」ではなく「鏡」として使えているか

このチェックリストで「No」が3つ以上ついたら、アンチパターンが連鎖している可能性が高い。第8話・第9話に戻って、原則レベルで何が抜けているかを見直す価値がある。

「同じ失敗を繰り返さないために」── Charity Majors の問いに戻る

第1話で引用した Charity Majors の言葉に、もう一度戻ろう。

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

DevOps は何に失敗したのか。Charity Majors の整理を、本章のアンチパターンの言葉で書き直してみる。

  • 「全員が全部を運用する」を理想化した → 結果として開発者の Cognitive load が爆発した（アンチパターン9）
  • ツールチェーンが追いつかなかった → 個々のツールが増えて Magpie Platform 化した（アンチパターン8）
  • 個別最適の解が散在した → 結果として Bottleneck 化と Skill Concentration を招いた（アンチパターン6・7）

Platform Engineering は、これらの失敗を踏まえた 構造的な解決策 として登場した。「You build it, you run it」の精神を維持しつつ、運用に必要な認知負荷を構造的に下げる。Stream-aligned team が Germane な仕事に集中できるよう、Platform team が X-as-a-Service で能力を提供する。

ところが、Platform Engineering それ自体も、本章で扱った13個のアンチパターンに陥る。新しい看板を掲げただけでは、構造は変わらない。

DevOps が失敗したのと同じ轍を、Platform Engineering で踏まないために必要なのは、思想と運営原則を真摯に実装すること だ。Platform-as-a-Product として運営する。Cognitive Load を測って削減する。TVPから始める。3つの実例が出るまで抽象化を待つ。Conway’s Law を「使い倒す」。

これらは、CNCF Whitepaper や Team Topologies 書籍、Fournier & Nowland の書籍、PlatformCon の登壇群に分散して書かれている原則だ。本シリーズの目的は、それらを 国内外の各社の選択 と紐付けて、読者が自分の組織に持ち帰れる形に整理することだった。

次章へ

ここまで、各社の選択と、その失敗パターンを見てきた。次のエピローグでは、シリーズ全体を貫く判断軸を「組織サイズ × 事業フェーズ」のマップとして整理する。

  • 〜10人の段階：Tailscaleや Cloudbase の最小構成（第6話）
  • 10〜50人の段階：レバテックが Platform Engineering を意図的にやめた判断（第6話）
  • 50〜500人の段階：10X・LayerX・カケハシ・freee の進化軌跡（第7話）
  • 500人〜の段階：Spotify・Mercari・Uber・adidas の内製IDP（第2話・第4話）

それぞれの段階で、何が現実的な選択肢で、何が早すぎる投資か。本シリーズ全体を 意思決定の道具 として使うための地図を、最後に整理する。

考古学はここで終わらない。あなたが書く次の章は、あなたの会社の事例だ。

問い：本章の13個のアンチパターンのうち、自社で観察できる症状はいくつあったか。1つや2つなら早期発見、3つ以上が当てはまるなら、第8話・第9話の原則レベルに戻って構造を見直す段階だ。「症状」を見つけたとき、それを「規律違反」ではなく「プロダクトの問題」として扱えるかどうかが、最初の分岐になる。

参考文献