プラットフォームエンジニアリングと内部開発者プラットフォーム

DevOpsの分業疲れが生んだ問い

「You build it, you run it」の理念でDevOpsは開発チームに運用責任を移譲しました。しかし数十チームがそれぞれTerraform・Kubernetes・可観測性基盤を独自に学び直すと、認知負荷が個々のチームに際限なく積み上がるという別の問題が露呈します。プラットフォームエンジニアリングは、この分業のやり過ぎに対する揺り戻しとして生まれました。運用を丸ごとチームへ戻すのではなく、プラットフォームチームが内部プロダクトとしてセルフサービス基盤（IDP: Internal Developer Platform）を提供し、開発チームはそれを消費するという第三の分業線を引き直します。

ゴールデンパス：自由の量を設計する

IDPの中心概念がゴールデンパス（golden path）です。これは「この構成・このテンプレート・この手順に乗れば、セキュリティ承認・可観測性連携・デプロイまで自動で揃う」という推奨された一本道を指します。ゴールデンパスは強制ではなく、外れることも可能ですが、外れた分だけ自分で舗装されていない道を進む（＝自分でIAM設定やアラート連携をやる）ことになります。

ゴールデンパスがない状態:
  各チームが独自にTerraform設計・可観測性連携・シークレット管理を学ぶ
  → チームごとに品質・セキュリティレベルがばらつく
  → プラットフォーム側は個別問い合わせ対応に追われる（チケット窮乏）

ゴールデンパスがある状態:
  「新サービステンプレート」を選ぶと以下が自動で揃う:
    - リポジトリ雛形、CI/CDパイプライン定義
    - 名前空間、IAMロール、シークレットの初期配線
    - ダッシュボード・アラートのひな形登録
  外れたい場合は各要素を個別に選び直せるが、その分の責任は自チーム

ゴールデンパスの設計原理は認知負荷の再分配です。開発チームが持つべき認知負荷は「自分のドメインロジック」に限定し、インフラの詳細（クラスタのスケジューリング方式や証明書のローテーション）はプラットフォームが抽象化して隠します。ここで重要なのは、隠すことと制御を奪うことは違う、という点です。ゴールデンパスから外れる自由（エスケープハッチ）を残さないIDPは、柔軟性を求めるチームの反発を招き、結局シャドーITに近い迂回を生みます。

ソフトウェアカタログの位置づけ：入口であって本体ではない

BackstageのようなソフトウェアカタログはIDPの代表的な構成要素ですが、カタログはIDPの発見・可視化層（UI/API）であり、自動化の実体ではありません。カタログが持つのは「どのサービスが存在し、誰が所有し、どんなAPIを持つか」というメタデータと、テンプレートを起動するための入口（スキャフォールディング）です。実際にリポジトリを作り、CI/CDパイプラインを配線し、クラウドリソースをプロビジョニングするのは、カタログの裏で動く自動化（Terraformモジュール、Operator、CI/CDシステム）であり、これらは既存の/devops/config-management/や/devops/gitops/の延長線上にあります。

この整理を誤ると「Backstageを導入すればIDPが完成する」という誤解に陥ります。カタログは可視化と入口を提供するだけで、裏側の自動化とテンプレート設計がなければ見た目だけのポータルに終わります。逆に自動化だけあってカタログがないと、便利な仕組みが個々に散在し、開発者は「どのリポジトリのどのREADMEを読めば使えるのか」を探すコストを払い続けます。

プラットフォームをプロダクトとして扱う

プラットフォームエンジニアリングが強調するもう一つの原則は、プラットフォームチームは開発者を内部顧客とするプロダクトチームであるという自己認識です。従来の運用チームはチケットで依頼を受け、個別対応で応えていました。これはスケールしません（チームが増えるほど対応工数が線形以上に増える）。プロダクトとしてのプラットフォームは、個別対応の代わりにセルフサービスAPI/UIとドキュメントで99%のケースをカバーし、残りの例外だけ人が介入します。

この転換には計測が伴います。プラットフォームの成功指標は「チケット数の少なさ」ではなく、開発者が最初のデプロイに到達するまでの時間（time to first deploy）やゴールデンパス採用率のような、プロダクト的な利用指標で測られます。DevOpsツールチェーン全体の思想的背景は/devops/devops-toolchain-lineage/、パイプラインを通る成果物の受け渡し先は/devops/artifact-registry/を参照してください。

まとめ

• プラットフォームエンジニアリングは、DevOpsで開発チームに移譲された運用の認知負荷を、プラットフォームチームがIDP（セルフサービス基盤）として再吸収する組織再編である。
• 核となる設計概念はゴールデンパス：推奨された一本道を舗装し認知負荷を下げつつ、外れる自由（エスケープハッチ）を残すことで中央集権化を避ける。
• ソフトウェアカタログ（Backstage等）はIDPの発見・入口層であり、実体を作る自動化（GitOps・Operatorパターン等）とは別レイヤー。両方揃って初めて機能する。
• プラットフォームチームは開発者を顧客とするプロダクトチームであり、成功はチケット対応数ではなく利用体験の指標で測る。