欧米では「DevOpsの次」としてPlatform Engineeringが急速に主流化しています。内製開発基盤(IDP)、Team Topologies、Backstage、Platform as a Product。これらのキーワードの背後にある実務の勘所を、CNCF・DORA・Gartnerの一次情報にあたりながら、日本のSIer・情シスの目線で整理します。
01「DevOpsの次」という言われ方の正体
欧米のエンジニアリング組織では、ここ数年「Platform Engineering(プラットフォーム・エンジニアリング)」という言葉が急速に定着しました。日本では「DevOpsの次に来るもの」という紹介のされ方をよく見かけますが、これはDevOpsを否定する話ではありません。DevOpsが掲げた「開発と運用の分断をなくす」という理念は正しかった一方で、その実装をすべてのアプリケーションチームに委ねた結果、各チームがKubernetes、CI/CD、監視、シークレット管理、セキュリティ統制までを個別に抱え込む「認知負荷(cognitive load)の過積載」が現場で起きました。
Platform Engineeringは、この負荷を専門チームが引き取り、開発者に対して「セルフサービスで使える社内製品」として基盤を提供する考え方です。CNCF(Cloud Native Computing Foundation)のPlatforms White Paperは、プラットフォームを「利用者のニーズに応じて定義・提示された、統合されたケイパビリティの集合」と定義しています(CNCF Platforms White Paper)。ポイントは「統合された」「提示された」という部分です。技術の寄せ集めではなく、利用者体験を設計した提供物である、という点にこの潮流の本質があります。
02数字で見る主流化 — Gartner・DORAの一次情報
「主流化した」という言い方が誇張でないことは、調査データが裏づけています。Gartnerは、大規模なソフトウェアエンジニアリング組織のうちPlatform Engineeringチームを持つ割合が、2022年の45%から2026年には80%に達すると予測しています。ただし注意したいのは、Platform EngineeringはGartnerの2026年「Top Strategic Technology Trends(戦略的テクノロジートレンド)」の一項目には入っていない点です。Gartnerは『Strategic Trends in Platform Engineering』のような個別テーマのリサーチとしては継続的に扱っていますが、2026年のフラッグシップの戦略的テクノロジートレンドとしての位置づけは維持されていません(Gartner: Top Strategic Technology Trends for 2026)。
ただし、導入すれば無条件に良くなるという単純な話ではありません。Googleが主導するDORA(DevOps Research and Assessment)の研究は、Platform Engineeringを「チーム間の社会的相互作用と、自動化・セルフサービス・再現性という技術的側面の交差点に立つ、社会技術的(sociotechnical)な規律」と位置づけたうえで、慎重な観察結果を示しています。内製開発基盤(IDP)は個人の生産性・チームパフォーマンス・組織パフォーマンスを向上させる一方、実装を誤るとスループットや変更の安定性を下げうる、と明言しています(DORA: Platform engineering capability)。
03設計思想の土台 — Team Topologies
Platform Engineeringの「チームの置き方」を語るとき、欧米では必ずと言っていいほどTeam Topologies(マシュー・スケルトンとマヌエル・パイス、2019年)が参照されます。この本は、組織を4つのチームタイプ — ストリームアラインド(価値の流れに沿った主役チーム)、プラットフォーム、イネーブリング、コンプリケイテッド・サブシステム — に整理します(Team Topologies: Key concepts)。
ここで重要なのが、プラットフォームチームとストリームアラインドチームの関係を「X-as-a-Service」モードで結ぶという考え方です。つまり、プラットフォームは「一緒に作業してあげる」対象ではなく、「セルフサービスで勝手に使ってもらう」対象として設計されるべきだ、という原則です。もし利用のたびにプラットフォームチームへの問い合わせや調整が必要なら、それは自動化の失敗であり、認知負荷を右から左へ移しただけになります。
04内製開発基盤(IDP)とは何を指すのか
Platform Engineeringの成果物が、内製開発基盤(Internal Developer Platform、IDP)です。CNCFのWhite Paperは、IDPが典型的に提供するケイパビリティとして次を挙げています(CNCF Platforms White Paper)。
- Webポータル/APIによるセルフサービス・プロビジョニング
- コンピュート・ストレージ・ネットワークなどのインフラサービス
- データベース・キャッシュ・オブジェクトストアなどのデータサービス
- テンプレート化された開発環境とワークフロー
- ビルド・テスト・デプロイのCI/CD自動化
- 監視とコスト可視化のオブザーバビリティ
- セキュリティ・コンプライアンスの統制、ID・シークレット管理
ここで日本の実務者が誤解しやすいのが、IDP=UIポータル、という理解です。ポータル(見た目)は氷山の一角で、本体は「ゴールデンパス(golden path)」と呼ばれる、標準化され舗装された道です。たとえば「新しいマイクロサービスを作る」というボタンを押すと、リポジトリ生成・CI/CDパイプライン・監視ダッシュボード・IAMロール・ネットワーク設定までが、組織の統制ルールに沿った状態で自動的に整う。開発者はビジネスロジックに集中でき、統制部門はガードレールが自動で効くことを担保できる。この「速さと統制の両立」がIDPの核心です。マルチアカウント環境でのガードレール設計は、まさにこのゴールデンパスの土台になります(マルチアカウント統制)。
05Backstage — 事実上の標準になったポータル基盤
IDPのポータル層で事実上の標準になったのが、Spotifyが開発しCNCFに寄贈したBackstageです。CNCFのプロジェクトページによれば、Backstageは2020年9月にCNCFに受け入れられ、2022年3月にIncubatingレベルへ昇格。数千の組織に採用されています(CNCF: Backstage)。Airbnb、Booking.com、Toyota North Americaなど、名だたるエンタープライズが採用企業として名を連ねます。
Backstageの中核は、次の2つのコンポーネントに集約できます。
- Software Catalog:社内に散在するサービス・API・リソースを一元的にカタログ化し、「誰が何を所有しているか」を可視化する。属人化・野良システムの棚卸しに直結します。
- Scaffolder(Software Templates):標準テンプレートから本番相当のプロジェクトを生成する。前述のゴールデンパスを実装する仕組みそのものです。
06核心思想 — Platform as a Product
Platform Engineeringが従来の「共通基盤チーム」と決定的に違うのは、基盤を「プロジェクト」ではなく「プロダクト(製品)」として運営する点です。CNCFのWhite Paperが引くマーティン・ファウラーの定義 — 「デジタルプラットフォームとは、魅力的な社内製品として構成された、セルフサービスのAPI・ツール・サービス・知識・サポートの基盤である」 — が、この思想を端的に表しています。
プロダクトとして運営するとは、具体的には次を意味します。基盤に専任のプロダクトマネージャーを置く。開発者を「顧客」と捉え、その体験(Developer Experience)を継続的に計測する。ロードマップを持ち、フィードバックループを回す。DORAの研究も、高品質なプラットフォームの成功要因として「プロダクトマネジメントの発想」「認知負荷の低減」「拡張性の設計」「明確なフィードバック機構」を挙げています(DORA: Platform engineering)。作って終わりの「納品物」ではなく、使われ続けるために磨き続ける「製品」だ、という発想の転換が肝です。
07日本のSIer・情シスにとっての含意
ここまでは欧米の潮流ですが、日本のSIer・情シスの文脈に翻訳すると、いくつかの示唆が見えてきます。
- 「共通基盤チーム」は既に持っている場合が多い:多くのエンタープライズには、すでにインフラ共通チームや基盤部門があります。Platform Engineeringはゼロからの新設ではなく、既存チームの運営思想を「問い合わせ対応窓口」から「セルフサービス製品」へ寄せていく、という漸進的な移行として捉えるのが現実的です。
- 統制部門との相性が良い:日本のエンタープライズが重視するセキュリティ統制・監査・標準化は、ゴールデンパスと極めて相性が良いです。ガードレールを基盤側に埋め込めば、統制を効かせながら開発速度を上げられます。統制と速度をトレードオフと捉えてきた組織ほど、効果が大きい領域です。
- SIerにとっては提供価値の再定義:従来の「基盤を構築して納品する」モデルから、「顧客の内製開発基盤をプロダクトとして共に育てる」モデルへ。手を動かせる伴走者としての価値が問われます。監視・アラート設計のような運用の土台づくりも、この基盤の一部として組み込む発想が有効です(導入事例)。
Platform Engineeringは、新しいツールの名前ではなく、開発基盤を「誰かのための製品」として設計し直す運動です。DevOpsが理念で示した理想を、認知負荷という現実に向き合いながら実装する。欧米で先に起きたこの試行錯誤の蓄積は、統制と速度の両立に悩む日本のエンタープライズにこそ、そのまま効く教訓を含んでいます。
—まとめ
- Platform EngineeringはDevOpsの否定ではなく、増大した認知負荷を専門チームが引き取る実装解。Gartnerは2026年に大規模組織の80%が導入と予測。
- 設計思想の土台はTeam Topologies。プラットフォームは「セルフサービスで使ってもらう」X-as-a-Serviceとして提供する。
- 成果物はIDP。核心はUIポータルではなく、統制を埋め込んだゴールデンパス。ポータル層の事実上の標準はBackstage。
- 核心思想はPlatform as a Product。作って終わりでなく、開発者体験を計測し磨き続ける。ただしDORAが示すとおり、導入初期のスループット低下は起こりうる。
- 日本では既存の共通基盤チームの運営思想を寄せる漸進的移行として、最小限の1本のゴールデンパスから始めるのが現実的。