Platform Engineering #Team Organization 井上翔太（MIXI）による、一人 SRE が小規模から Platform Engineering を実践した経験報告（クラウドネイティブ会議, 2026）。「Platform Engineering は大規模チームの専売特許ではない」と説く アプリエンジニア→SRE→PE と段階的に守備範囲を広げた実践録 Platform as Code（Terraform / IaC）、AI 付き Slack bot によるセルフサービス権限管理、Golden Path 改善、Workload Identity 導入 制約はリソース不足と設計の相談相手不在。AI が一人実践のイネーブラーになった https://speakerdeck.com/syossan27/ren-sregabu-ndaplatform-engineeringsumorusutatoshi-jian-lu-kuraudoneiteibuhui-yi-ban

Platform Engineering Internal Developer Portal Backstage https://codezine.jp/article/detail/19578

Platform Engineering #Product Management Platform Engineering に MVP の発想を持ち込んだ概念。包括的な機能ではなく、ステークホルダーへ数週間で価値を実証できる最小限のプラットフォームを指す

Platform Engineering Spotify社が開発するInternal Developer Portal。CNCF incubating project core（フレームワーク）と plugin から成り、App 本体は各要素を配線するだけで、機能は plugin が提供する Software Catalog / Software Templates / TechDocs / Search 等の中核機能も built-in plugin として実装される plugin は frontend（ブラウザの React）と backend（Node.js）の2層に分かれ、各 backend plugin は独立して動作する https://backstage.io/ https://github.com/backstage/backstage

Platform Engineering Internal Developer Platform Kubernetes RBAC Internal Developer Portal https://codezine.jp/article/detail/19376

Platform Engineering Team Topologiesのプラットフォームチームがストリームアラインドチームに向けてプラットフォームを提供する際、X-as-a-Serviceによって実現する考え

Author: 草間 一人 SRE/SRE サイトリライアビリティエンジニアリング エレガントパズル Four Keys/DevOps Platform Engineering Team Topologies Building Effective AI Agents

Platform Engineering Author: 草間 一人 https://codezine.jp/article/detail/18752 Gartner Identifies the Top 10 Strategic Technology Trends for 2024 認知負荷 チームトポロジー Golden Path

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 プラットフォームチームが内部開発者向けに提供するプラットフォーム 以下の5つのコンポーネントを網羅するように設計すべきとされている アプリケーションの構成管理 インフラストラクチャのオーケストレーション 環境の管理 デプロイメントの管理 ロール単位のアクセス制御 https://internaldeveloperplatform.org/

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

Platform Engineering 認知負荷 Team Topologies DevOpsトポロジー https://www.infoq.com/jp/articles/platform-engineering-primer/ DevOps

Platform Engineering SRE SLI/SLO/SLA https://codezine.jp/article/detail/18856

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

Platform Engineering 技術選定が多く必要とされるケースで、会社として利用するものはどれでどのように使えばよいか道筋を立てること

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 Internal Developer Platformを、統一されたインターフェースで操作できるようにしたもの

PEMM Platform Engineering #Cloud Native #Team Organization CNCFが提供するPlatform Engineeringの成熟度を評価するフレームワーク 5つの評価軸で組織のプラットフォーム進捗を測定する Investment（投資） Adoption（採用） Interfaces（インターフェース） Operations（運用） Measurement（測定） 2026年までに大規模ソフトウェア組織の80%がプラットフォームチームを持つとGartnerが予測しており、AI統合、測定実践、開発者体験の向上が重要な要素となる https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/

#Continuous Integration リポジトリ設定を policy-as-code で組織横断に宣言・適用する GitHub App（Probot ベース）。admin リポジトリに設定を集中管理し、各 repo の実設定を GitHub API 経由で宣言状態へ収束させる、repo 設定版の Infrastructure as Code。Platform Engineering の guardrails 実装の一つ 設定は admin repo の 3 階層（.github/settings.yml=org / suborgs/*.yml / repos/*.yml）で各 repo にマージ適用、優先度は repo > suborg > org full sync（CRON）で drift を検出・修正、PR では nop モードで dry-run 差分を提示 管理対象は GitHub API で扱う設定のみ（branch protection / labels / collaborators / teams / topics / custom properties / environments / rulesets 等）。ファイル内容は扱えず .github/workflows/*.yml の配布はできない（GitHub Actions の強制は ruleset / require workflows 経由） Organization 専用で個人アカウントでは動かない https://github.com/github/safe-settings

Gartner社が2023年10月16日に発表した2024年の技術トレンド10個 Democratized Generative AI AI Trust, Risk and Security Management AI-Augmented Development Intelligent Applications Augmented-Connected Workforce Continuous Threat Exposure Management Machine Customers Sustainable Technology Platform Engineering Industry Cloud Platforms https://www.gartner.com/en/newsroom/press-releases/2023-10-16-gartner-identifies-the-top-10-strategic-technology-trends-for-2024 https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231114-techtrends

#Continuous Integration Platform Engineering Go 言語で書かれた、多数の Git リポジトリへ一括で変更を加える CLI ツール。マイクロサービス のように小さなリポジトリが多数に分かれた構成で有用と公式は述べている init → clone → plan → push → merge の 5 段階のワークフローで、ターゲットリポジトリの選定からスクリプトベースの一括編集・差分プレビュー・PR 作成・マージまでを順に進める。バックエンドは GitHub と GitLab（self-hosted 含む） https://github.com/Clever/microplane