Platform Engineering Platform Engineering が黎明期から産業標準へ成熟したことを前提に、2026年の Platform Engineer 像を問い直す Mallory Haigh の記事 役割が6つの専門職に分化（Head / Platform Product Manager / Infrastructure / DevEx / Security / Reliability） AI リテラシーが「生存レベル」の必須スキルに DORA・SPACE などの測定リテラシーと プロダクト思考が前提 プラットフォームは技術的負債ではなく開発者に使われないこと（アダプション）で失敗する https://platformengineering.org/blog/being-a-platform-engineer-in-2026

Platform Engineering Platform Engineering を実現する上で重要な組織論チームトポロジーを解説した記事 組織的センシング SAT Platform as a Product https://codezine.jp/article/detail/19001

Minimum Viable Platform #Product Management Luca Galante による Minimum Viable Platform の解説記事。プラットフォームの失敗は技術選定ではなく文化・プロセス（価値実証の遅さ）が原因とし、2週間で主要ステークホルダーに価値を示す MVP を説く Representative: クラスタ/コンテナ/VCS/単一DB/DNS/CI/CD 等の典型リソースを最小構成で含む Repeatable: 他チームのクイックスタートになるテンプレート Iterative: スケールを前提に設計する Innovative: 先行チームが新技術を試せる余地を残す 先行採用チーム（lighthouse teams）の賛同を起点にフィードバックを反復し、予算を確保する 抽象度は Platform as a Product で調整し、開発者ポータルと混同しない https://platformengineering.org/blog/what-is-a-minimum-viable-platform-mvp

Platform Engineering #Team Organization Rebecca Murphey（Swarmia）による、専任 プラットフォームチーム をいつ作るべきかを組織規模から論じた記事 目安は約100エンジニア（Peter Seibel のモデル）。それ未満は専任チームのオーバーヘッドが便益を上回る 「2〜3チームを超えた時点で、未文書で脆くても既に Internal Developer Platform は存在する」。4チーム以上が検討の目安 早すぎ（20人規模）は機能開発リソースの浪費、遅すぎ（100人超で不在）は複数ペア＋専任マネジメントが必要になる 「Minimum Viable Platform Team」＝最小構成のチーム（自走リード1＋伸びしろ1＋兼任EM）から始める。チーム版の Minimum Viable Platform とも言える発想で、IDP をプロダクトとして利用者の声と指標で測る（Platform as a Product） https://www.swarmia.com/blog/when-to-start-a-platform-team/

Platform Engineering Gartner Identifies the Top 10 Strategic Technology Trends for 2024 認知負荷 Team Topologies/プラットフォームチーム Golden Path Platform as a Product Internal Developer Portal/Internal Developer Platform 組織的センシング Backstage Crossplane KubeVela Kubernetesで実践する Platform Engineering