person using laptop on white wooden table Photo by Alvaro Reyes on Unsplash

認知負荷を半減するプラットフォームの正体

今年の4月から生成AI専任ロールに異動した。コードを書く時間はほぼなくなって、社内のAI導入推進がメインになっている。

で、社内のエンジニアたちと話していて気づいたことがある。みんな、コードを書く時間が驚くほど少ないんだよね。デプロイ設定、環境構築、ツール間の調整、ミーティング。「今日1行もコード書いてない」という日が珍しくない。

この問題に対して、今まさに大きなうねりが来ている。プラットフォームエンジニアリングだ。Gartnerの予測では、2026年までに大規模エンジニアリング組織の80%が専任のプラットフォームチームを設置するとされている。2022年時点では45%だったから、ものすごいスピードで広がっているのがわかる。

なぜここまで急速に広がっているのか。その鍵は「認知負荷」にある。

開発者の時間はどこに消えている？

まず現実を見てみよう。

複数の開発者生産性調査によると、開発者の週40時間の内訳はこうなっている。

  • ミーティング: 約10時間
  • コンテキストスイッチ: 15〜20時間
  • 実際のコーディング（深い集中作業）: 約10時間

つまりコーディングに使えている時間は全体の25〜30%程度だ。しかも、一度集中が途切れると元の状態に戻るまで平均23分かかるという研究結果もある。

ここで重要になるのが、Matthew SkeltonとManuel Paisの著書「Team Topologies」で紹介されている認知負荷の3分類だ。

  • Intrinsic（内在的負荷）: タスク本来の複雑さ。プログラミング言語の習得やアルゴリズムの理解など
  • Extraneous（外在的負荷）: 環境に起因する余計な負荷。デプロイ手順の把握、インフラ設定、ツール間の接続など
  • Germane（本質的負荷）: ビジネス課題を解くために必要な思考。ドメインロジックの設計やユーザー体験の改善など

問題は、多くの開発者がExtraneous（外在的負荷）に時間とエネルギーを大量に消費していること。Kubernetesのネットワーキングやデプロイパイプラインの設定など、本来やりたい開発とは直接関係ない部分に頭のリソースを使い果たしている。

プラットフォームエンジニアリングが解決しようとしているのは、まさにこのExtraneous cognitive loadの削減なんだよね。

プラットフォームエンジニアリングとは何か

ここまで認知負荷の問題を見てきたけど、じゃあプラットフォームエンジニアリングって具体的に何をするのか。

一言でいうと、Internal Developer Platform（IDP）を構築・運用して、開発者がセルフサービスで必要なリソースを取得できるようにすること。

たとえば新しいマイクロサービスをデプロイしたいとき、従来は以下のような作業が必要だった。

  • Kubernetesの設定ファイル作成
  • CI/CDパイプラインの構築
  • モニタリングツールの設定
  • シークレット管理の設定
  • ネットワークポリシーの設定

これをIDPが抽象化して、開発者は「新しいサービスを作りたい」とだけ指定すれば、あとはプラットフォームが面倒を見てくれる。Team Topologiesでいう「Platform as a Product」の考え方だ。プラットフォームチームは社内の開発者を「顧客」として、プロダクトのようにプラットフォームを磨いていく。

DevOpsとの違いも押さえておきたい。DevOpsは「開発チームが運用も担う」という文化・思想だけど、現実にはすべてのチームがインフラの専門知識を持つのは難しい。プラットフォームエンジニアリングは、専門のプラットフォームチームが「ゴールデンパス（推奨される標準的な開発フロー）」を整備して、他のチームの認知負荷を引き受ける。

Gartnerが「2026年までに大規模組織の80%がプラットフォームチームを設置する」と予測した背景には、DevOpsだけでは解決できなかった認知負荷の問題がある。

Spotifyの成果と主要ツール

プラットフォームエンジニアリングがどのくらいの効果を生むのか。最も有名な事例はやっぱりSpotifyだと思う。

SpotifyはIDPとしてBackstageを自社開発し、2020年にオープンソースとしてCNCFに寄贈した。その成果がまじですごい。

  • 新規サービスのセットアップ: 70ステップ → 3〜5ステップに簡略化
  • 新入社員のオンボーディング: 60日 → 20日以下（10回目のPRマージまでの時間）
  • 開発者の認知負荷が40%削減
  • コードのサイクルタイムは17%短縮

70ステップが5ステップ以下になるって、冷静に考えてやばい。開発者が本来やりたいことに集中できる環境を作ると、これだけ変わるんだよね。

僕自身、RAGチャットボットを3つ作ったときに感じたけど、環境構築やデプロイに時間を取られると本来の開発に集中できなくなる。もしIDPがあったら、もっと早く価値を届けられたかもしれない。。

現在のIDP市場では、主に3つのツールが選択肢になっている。

  • Backstage（Spotify発、オープンソース）: IDP市場で89%のシェア。3,400以上の組織が採用。ただしセットアップに2〜3人のエンジニアが6ヶ月以上必要
  • Port（商用SaaS）: ノーコードでモデリングできるブループリント方式。2025年12月に1億ドル調達
  • Cortex（マネージドSaaS）: サービスオーナーシップ重視で導入が速い

日本でも動きは加速している。任天堂システムズがAWS Fargate上にIDPを構築し、リクルートは全社横断のデータ分析プラットフォームを提供している。Platform Engineering Kaigi 2024も開催されて、国内のコミュニティも活発になってきた。

注目すべき新しい動きとして、Platform Product Managerという専門職が登場している。CNCFが認定資格を提供していて、すでに25%の組織がこの職種を設置。PPMを持つチームは開発者満足度が40%向上したというデータもある。プラットフォームを「プロダクト」として育てるなら、専任のPMが必要という考え方はなるほどと思う。

導入のハードルと現実的な課題

ここまでプラットフォームエンジニアリングのメリットを見てきたけど、当然課題もある。バランスを取るために正直に触れておきたい。

定着の難しさがまず大きい。Backstageは89%の市場シェアを持つ一方、平均的な定着率は10%程度にとどまるという指摘がある。PoCで止まってしまうケースが多いんだよね。開発者が実際に何に困っているのかを理解しないまま導入すると、使われないプラットフォームが出来上がる。

初期投資の大きさも無視できない。Backstageのセットアップには2〜3人のフルタイムエンジニアが6ヶ月以上必要とされている。小規模なチームにとっては、この投資は現実的じゃないかもしれない。

もう一つ注意したいのが、認知負荷の移転問題だ。開発チームの認知負荷を減らせても、その負荷がプラットフォームチームに集中するだけという批判がある。これはまっとうな指摘だと思う。

ただ、これらの課題には対処法がある。Team Topologiesの著者が提唱するTVP（Thinnest Viable Platform） という概念が参考になる。「最小限の実行可能なプラットフォーム」から始めて、開発者からのフィードバックを受けながら段階的に育てるアプローチだ。

最初の一歩は小さく始める

課題を理解した上で、じゃあどう始めればいいのか。

僕は今、社内のAI導入推進をやっていて、大きなシステムを一気に導入しようとすると失敗しやすいということを痛感している。36歳で未経験からエンジニアに転職した初日、SSHすら何かわからなかったところから始まった身としては、小さく始めることの大事さは身に染みている。

プラットフォームエンジニアリングも同じだと思う。具体的なステップはこう。

  • まず1つの繰り返し作業を自動化する: 新規サービスのテンプレート作成やデプロイの標準化など
  • CTS（Concepts to Ship）メトリクスで効果を計測する: ある作業に必要な概念の数を四半期ごとに追跡する。デプロイに必要な概念が12個→3個に減れば、75%の認知負荷削減になる
  • 開発者の声を聞く: プラットフォームは「プロダクト」。顧客である開発者のフィードバックなしには育てられない
  • TVP（Thinnest Viable Platform）で始める: wikiとテンプレート集だけでもプラットフォームの第一歩になる

Backstageを導入するなら、公式ドキュメントのGetting Startedから始めるのが最短ルートだ。ただし前述の通り運用にはリソースが必要なので、まずはPortやCortexの無料トライアルで感触をつかむのも一つの手だと思う。

まとめ

プラットフォームエンジニアリングの本質は、開発者のExtraneous（外在的）な認知負荷を削減して、Germane（本質的）な思考に集中できる環境を作ること。

  • 開発者のコーディング時間は全体の25〜30%。残りはミーティングやコンテキストスイッチに消えている
  • Gartner予測で2026年までに大規模組織の80%がプラットフォームチームを設置
  • SpotifyではIDPにより認知負荷が40%削減、オンボーディングが60日→20日以下に
  • 導入の課題はあるが、TVP（最小限のプラットフォーム）から段階的に始めることで対処できる
  • CTS（Concepts to Ship）メトリクスで認知負荷の削減を定量的に追跡できる

まずは自分のチームで「一番時間を食っている繰り返し作業」を特定するところから始めてみて。そこがプラットフォームエンジニアリングの出発点になる。

参考リンク