プラットフォームエンジニアリングのすべて：なぜ必要で、どう構築し、成功とはどんな姿か

• 社内エンジニアをユーザーとみなし、内部製品を構築・運用する組織的規律として、単なるDevOpsのリブランディングやKubernetesクラスター管理とは本質的に異なる領域
• 2025 DORAレポートによれば、組織の90%が少なくとも1つの内部プラットフォームを導入しており、プラットフォーム品質がAIツールの価値創出可否を直接予測する指標として浮上
• クラウドとオープンソースが無限のプリミティブを提供することで、各チームがばらばらにパイプラインを構築する**「過剰一般化の沼地（over-general swamp）」**問題を解決することが中核的な存在意義
• プラットフォームを実際の製品として扱い、中央値の開発者向けのソフトウェア抽象化・メタデータレジストリ・運用SLOを備えることが成功の構造的条件
• 良いプラットフォームは開発者がその存在を忘れるほど自然に動作し、悪いプラットフォームはAIツールが混乱を増幅させる一方で、良いプラットフォームはスループットを増幅させる

---

プラットフォームエンジニアリングが存在する理由

• 過剰一般化の沼地（Over-General Swamp）

  • クラウドとOSSがキュー、オブジェクトストア、データベース、CIランナー、サービスメッシュなど無限のプリミティブを提供することで、各アプリケーションチームが異なる選択をするようになる
  • 1年後には、すべてのサービスが独自のデプロイパイプライン、リトライロジック、監視慣行、微妙に誤ったIAMバインディングを持つ「グルーコードの沼」に変質
  • 選択肢の爆発と、より高い運用期待値（24/7稼働、セキュリティ、コンプライアンス、コスト管理）が、この沼を生んだ2つの原因
  • 実際のランディングゾーンプロジェクトでは、20チームがVPC、IAM、予算アラート向けのほぼ同一のTerraformモジュールをそれぞれ再発明し、それぞれ異なるバグを抱えていた事例がある

• プラットフォームエンジニアリングが実際に行う4つのこと

  • 開発者が目にするプリミティブを制限し、キュレーションされた方式でのみ利用するよう導く
  • 反復的な配管作業を共有サービスとして吸収し、アプリケーションごとのグルーコードを削減
  • 基盤プリミティブ変更時にプラットフォームチームが一度だけ対応することで、移行コストを集中化
  • 開発者がLinuxカーネルの専門家にならなくても自分が作ったものを自ら運用できるよう支援
  • DevOpsは「開発者が運用を所有せよ」だったが、プラットフォームエンジニアリングは「その運用のための良いツールを実際の製品として提供する」ということ
  • DORA 2025のコンピテンシーページでも、ツールカテゴリではなく社会技術的（sociotechnical）規律として定義されている

5つの柱（Pillars）

• キュレーションされた製品アプローチ（Curated Product Approach）

  • プラットフォームがサポートするものとしないものを意図を持って決定する
  • チームがPub/Subの代わりにKafkaを望むとき、「ドキュメントのリンクはこちら」ではなく、「サポート範囲とその理由、合わない場合のオフランプ」を案内する
  • 断ることも仕事の一部

• ソフトウェアベースの抽象化（Software-Based Abstractions）

  • プラットフォームはWikiではなくソフトウェアであり、インターフェースはAPI、CLI、SDK
  • 開発者は小さな宣言的ファイルを書くだけで、本番グレードのサービスをプロビジョニングできるべき
  • CNCF傘下のScoreプロジェクトが代表例で、1つのワークロード仕様からデータベース、トピック、サービスアカウント、デプロイを自動プロビジョニングする
    • 開発者は内部的にCloud SQL、Pub/Sub、Cloud Runなのかを知る必要はない

• OSSカスタマイズとメタデータレジストリ

  • 素のArgo CDやBackstageをそのまま使うのではなく、組織に合ったプラグイン・デフォルトポリシー・統合を適用して運用する
  • メタデータレジストリ（サービスカタログ）がなければ、誰が何を所有し、依存関係がどうなっており、実際に何が動いているのかを把握できない
  • Backstageはこのレイヤーの事実上の標準OSSフレームワークであり、270以上の組織が本番で運用
    • CNCFはCertified Backstage Associate、Certified Cloud Native Platform Engineering Associate認定を開始
    • Backstage、Port、Cortexなど何を使うにせよ、「どのサービスが存在し、誰が所有し、依存関係は何か」に関する**単一の信頼できる情報源（single source of truth）**が必要

• 幅広いユーザー基盤へのサービス

  • 内部プラットフォームは少数の非常に声の大きい顧客を抱えるが、目的は中央値（median）の開発者による中央値の作業をうまく支援すること
  • エリートユーザーだけのために構築すると、残りのチームがプラットフォームを迂回し、シャドープラットフォームが生まれる

• 基盤として運用する

  • プラットフォームが停止すれば会社が止まるため、24/7のオンコール、実際のSLO、実際の変更管理、サポート負荷が伴う
  • 「ツール」ではなく**「床（floor）」**の役割であり、その上に構築されるすべてのものは床が耐えることを前提とする

始める時期と方法

• プラットフォームチームを早く作りすぎないこと

  • エンジニア10人規模では、プラットフォームチームではなく**協力（cooperation）**が必要
    • 1人がデプロイスクリプトを、別の1人がTerraformを管理し、慣行に合意すれば十分
  • 1〜2人で早すぎる段階でチームを組むと、彼らがチケットキューとなり、残りの組織は受け身になる
  • 通常はエンジニアが50人を超えた後、複数のデプロイ先が生まれ、「新しいサービスをどうデプロイするか」に対する正解を誰も知らなくなったときに、チーム編成が適切

• 既存インフラ組織の転換

  • インフラ/SREチームをプラットフォーム組織へ転換する際に最も難しいのは、技術ではなく文化
  • インフラ担当者は「ダメです」のゲートキーパー役に慣れているが、プラットフォーム担当者は**「簡単なイエスを提供する人」**にならなければならない
    • 顧客と多く対話する
    • 運用者だけでなく、ツール作りを楽しむソフトウェアエンジニアを採用・育成する
    • 「新しいクラスターをデプロイした」より「200チームを5%速くした」が評価されるよう、報酬体系を更新する
  • PMを上に振りかけて終わりにするのが最も一般的な失敗パターンであり、これはプラットフォームではなく**演劇（theater）**を生み出す

プラットフォームチームの構築

• 4つの役割

  • Software Engineer: API、SDK、ポータルなどプラットフォームの製品表面を構築
  • Systems Engineer: Kubernetes、Linux、ネットワーキング、クラウドコントロールプレーンなど基盤プリミティブに精通
  • Reliability Engineer: 運用品質、オンコール、SLO、可観測性に集中
  • Systems Specialist: データベース、セキュリティ、ネットワーキングなど深いドメイン専門家
  • ソフトウェア偏重が過ぎると美しいポータルが実負荷で崩壊し、システム偏重が過ぎると堅牢なクラスターを誰もチケットなしでは使えない

• 採用

  • **顧客共感（customer empathy）**を最優先に採用すべき
  • 苛立ったアプリ開発者と話した後に問題を明確に理解して出てこられないエンジニアは適任ではない
  • 共感のない技術的卓越性は、正確だが誰にも使われないプラットフォームを生み出す
  • ソフトウェア職には同じレベルマトリクスを使いつつ、システムスペシャリストは市場価値とスキルがソフトウェアエンジニアのラダーにきれいに対応しないため、柔軟な肩書きを許容する

• マネージャーおよびその他の役割

  • 優れたプラットフォームエンジニアリングマネージャーに共通する3つの特性：実際のプラットフォーム運用経験、長期の複数四半期プロジェクトのデプロイ経験、ディテールへの執着
    • プラットフォームはディテールに報い、まれに見えるため飛ばした1%のケースがサポート時間の80%を占める
  • PM、テクニカルライター、デベロッパーアドボケイト、サポートエンジニアはいずれも重要だが、エンジニアリングチームが十分に成熟した後で採用する
  • 4人のプラットフォームチームに早期投入されたPMは、ロードマップの形をした椅子になるだけ

プロダクトとしてのプラットフォーム

• 内部顧客のほうが難しい

  • 内部顧客は離脱しにくい captive userであり、意見は強い一方でプロダクト感覚は弱い
  • 欲しいもの（want）は語るが、実際に必要なもの（need）とは異なることが多い
  • プラットフォームに自分の仕事を代行してほしいのであって、仕事をうまく進めるための道具を求めているわけではない
  • 彼らの隣に座り、1つの変更をデプロイするために何回コンテキストスイッチしているかを観察することが、実際のバックログになる

• ディスカバリー、ロードマップ、失敗モード

  • プラットフォームのディスカバリーはA/Bテストではなくパイロットで行い、協力的なチームを対象に実際のデプロイ後のリードタイム短縮を測定する
  • ロードマップの4つの時間軸
    • Vision（複数年）：プラットフォームの方向性
    • Strategy（年次）：今年の賭け
    • Goals and Metrics（四半期〜年次）：成功の定義
    • Milestones（四半期）：実際のデプロイ対象
  • チームをしばしば崩壊させる失敗モード
    • 移行コストの過小評価（常に想定の2〜3倍）
    • ユーザーの新機能に対する変更予算の過大評価
    • 実際の問題は安定性なのに機能追加に集中すること
    • エンジニアリングチームの規模に対してPMが多すぎる（エンジニア5人にPM2人なら問題）

プラットフォーム運用

• オンコールは任意ではない

  • 基盤として運用する以上、24/7のカバレッジは交渉の余地がない
  • 「作った人が運用する（you build it, you run it）」はここでも当てはまり、これは罰ではなくフィードバックループである
  • 単一のエンジニアが週に何度もページを受けるなら、スケジュールではなくシステムを修正しなければならない
  • 燃え尽きたプラットフォームエンジニアは悪いプラットフォームをデプロイする

• サポート：業務の隠れた半分

  • カンファレンスではほとんど語られない領域だが、プラットフォームエンジニアリングの中核となる半分である
  • 4段階のフレームワーク
    • 1段階：サポートレベルを明文化する（P0 vs P3、応答時間など）
    • 2段階：重要ではないサポートをオンコールから切り離し、「CronJob の追加方法」の質問で誰かが叩き起こされないようにする
    • 3段階：ボリュームが正当化されるなら専任のサポートスペシャリストを採用する
    • 4段階：規模に見合ったエンジニアリングサポート組織を構築する
  • 1段階を飛ばすと、エンジニアは時間の半分をSlack DMへの返信に、残り半分を不満に費やすことになる

• 運用フィードバック

  • SLOとSLAは必須であり、エラーバジェットは有用だが任意である
  • Synthetic monitoringは、ユーザーがチケットを送る前に失敗モードを捉える
  • Operational review は、緑色のダッシュボードをちらっと見ることではなく、実データの確認を強制するものだ
  • DORA 2025のデータでユーザー体験と最も高い相関を示したプラットフォーム能力は、作業結果に対する明確なフィードバックだった — 失敗時には何が失敗し、どうすべきかをユーザーが正確に分からなければならない

計画とデリバリー

• 長期プロジェクトには提案書が必要

  • 移行、リアーキテクチャ、新しいコントロールプレーンなどのプラットフォームプロジェクトは四半期単位でかかる
  • 良い提案書の必須要素：解決しようとしている問題、受益者、スコープ、明示的にスコープ外であるもの、成功の定義
  • コードを書く前にまず文書を書き、レビューを受けた後で具体的なマイルストーンを伴う実行計画に変換する
  • 「長い泥沼（long slog）」という失敗モード — プロジェクトが何年も引き延ばされ、誰もその理由を覚えていない — は、ほとんど常にこの段階を飛ばした結果である

• ボトムアップのロードマップ計画

  • プラットフォームロードマップの4つの業務タイプ：KTLO（keep-the-lights-on）、リーダーシップ命令、自主的に決めるシステム改善、直接的な顧客要望
  • 顧客需要だけで優先順位は付けられず、KTLOが1位、命令が2位で、残りはステークホルダーとの率直な議論が必要

• 隔週の成果と課題（Biweekly Wins and Challenges）

  • 2週間ごとに短い文書を書く：デプロイしたもの（成果）、詰まっているもの（課題）、短く公開で、誇張なく
  • 同時に3つの効果がある：チームが進捗を明確に表現できる、ステークホルダーに実際の状況を伝えられる、課題を早期に露出してリーダーシップの支援を促せる
  • 成果しかない文書は誰にも信頼されない文書なので、課題を省略してはならない

リアーキテクチャと移行

• v2ではなくリアーキテクチャ

  • プラットフォームが古くなったとき、「v2を作ろう」という本能はほぼ常に誤りである
  • v2プロジェクトが失敗する理由：v1への投資凍結、想定より長い所要時間、v2への移行コストが回避したリアーキテクチャのコストより高いこと
  • 既存プラットフォームの内部でリアーキテクチャし、可能な限り互換性を維持しつつ、下位環境・段階的ロールアウト・トランチベースの移行を活用する
  • 4つの計画段階
    • 最終的なアーキテクチャ目標を大きく考える
    • 移行コストを織り込む（常に2〜3倍）
    • 継続投資を正当化する12か月の主要成果を特定する
    • リーダーシップの合意を取り、待つ準備をする

• セキュリティはアーキテクチャの問題

  • 構築後にセキュリティを付け足すことは不可能であり、アーキテクチャは設計時点から最小権限、分離、追跡可能性を強制しなければならない
  • すべてのチームが正しい IAM バインディングを覚えていなければならないプラットフォームなら、問題があるのはチームではなくプラットフォームの側である

• 移行：過小評価される難題

  • 最も一般的なアンチパターン
    • すべてのチームにクリップボードと締め切りを渡して自力で移行しろと要求する
    • 明確なオンランプ・オフランプなしに命令だけを出す
    • 特異なユースケースのロングテールを過小評価する
  • 移行を楽にするエンジニアリング手法
    • 利用メタデータを追跡して旧バージョンの利用者を正確に把握する
    • 200チームが移行しなければならないなら、アプリチームではなくプラットフォームチームがスクリプトを書く
    • 新しいシステムが旧APIを使う透過的な移行アーキテクチャを設計する
    • 新しいチームがセルフサービスできる程度にオンランプを明確に文書化する
  • 命令（mandate）は1、2回しか効果がなく、その後はノイズになる
  • ほとんどの場合、新しい経路を十分によくして古い経路が自然に衰退するようにするのが最善である

• サンセット（Sunsetting）

  • プロダクトをなくすことを恐れてはならない
  • 半端にサポートされたデプロイシステム7つより、堅牢なデプロイシステム1つのほうが優れており、サンセットは成熟したチームの特徴である

ステークホルダーとの関係

• パワー・インタレスト・グリッド（Power-Interest Grid）

  • ステークホルダーを**権限（power）と関心度（interest）**の2軸でマッピングする
    • 権限が高く関心も高い：定期的に更新し、協議する
    • 権限が低く関心も低い：ステータスページで十分
  • 関心の低いVPに Kubernetes アップグレード情報を提供してチームの時間を無駄にしてはならない

• 過剰共有しないコミュニケーション

  • 透明でありつつ過剰ではなく — シニアリーダーが知るべきなのは3つの gRPC リトライ戦略の議論ではなく、マイルストーン達成可否とリスクである
  • 1:1ミーティングは慎重に使い、期待値と約束を見える場所で追跡する

• 関係を壊さずに断る

  • 「この機能を追加すると移行が1四半期遅れ、会社に $X のコストがかかる」のように、ビジネスインパクトを明確にする
  • 「妥協付きのイエス」「断りつつ経路を示す」、時にはシャドープラットフォームを許容するほうが争うコストよりましな場合もある
  • 予算シーズンには、人員単位ではなくチーム・能力単位で束ねて提示し、何を削り何を維持するかについて強い意見を持つべきだ — そうしないと財務部門が代わりに決めて、誤った判断をする

成功の姿

• 整列されたプラットフォーム（Aligned）

  • 目的の整列（なぜ存在するのか）、戦略の整列（賭けがチーム間で一貫していること）、計画の整列（マイルストーンの衝突がないこと） が必要
  • ランタイムチームは全員 Kubernetes を望み、可観測性チームはあらゆるフレームワークをサポートしようとする場合、整列の不一致 が発生
    • 相反する顧客ガイド、重複作業、板挟みになった怒れる開発者として表面化
    • コンセンサスではなく、原則あるリーダーシップ で解決

• 信頼されるプラットフォーム（Trusted）

  • 信頼はゆっくり積み上がり、たった一度の悪いマイグレーションで失われる
  • 運用のやり方（障害時のコミュニケーション、約束の履行）、投資のやり方（売り込んだ大きな賭けを実際にデプロイすること）、デリバリーの優先順位 から信頼が形成される
  • 「過結合プラットフォーム（overcoupled platform）」の事例：過剰に多くのカスタムロジックをプラットフォームに入れ、あらゆる変更に数か月を要する — 解決策は追加のエンジニアリングではなく、スコープに関する前提への挑戦
    • ときに信頼の問題は、やることが少なすぎるからではなく、やりすぎているから 起きる

• 複雑性を管理するプラットフォーム

  • ソフトウェアの複雑性は不可避だが、偶発的複雑性（accidental complexity） はそうではない
  • 還元不可能な問題の複雑性と、人間同士の調整不足、同じ問題を二度解くシャドープラットフォーム、無限の成長が生む 偶発的複雑性を区別
  • 3つの実用的なレバー
    • 成長の統制：すべてをサポートするプラットフォームは何ひとつうまくサポートできない、スコープを明示する
    • プロダクトディスカバリー を、何を追加するかだけでなく 何をやめるか を把握するためにも活用
    • シャドープラットフォームの管理：チームが並行ソリューションを作るなら、プラットフォームに実際の不足があるか、誰かが領域を拡張しているサイン — どちらにも対応が必要

• 愛されるプラットフォーム（Loved）

  • 3つの形
    • 「ただ動く」愛：大半の利用者はプラットフォームを意識せず、デプロイでき、CI が通る — 退屈であることが最高の賛辞
    • 「ハックみたいな」愛：別途説明がなくても明らかに正しい動作をする CLI コマンドのような 小さな喜び
    • 「明白な」愛：アンケートのスコア、リテンション、オーガニックな採用、他チームへのプラットフォームの推薦
  • プラットフォームが愛されていれば、予算要求の際に人々が 代わりに戦ってくれる が、単に許容されているだけなら、一度の悪いインシデントで 置き換えられる危機 に陥る

実践的な優先順位

• ゼロから始める、または再構築するときのおおよその順序
  • 1番目：サポート範囲を決めて 文書化し、防衛する
  • 2番目：Wiki ではなく ソフトウェア抽象化に投資（Score、Crossplane、自社 SDK など実際の API を持つソフトウェア）
  • 3番目：メタデータレジストリ を構築（Backstage などで何がどこで動いており、誰がオーナーなのかを把握）
  • 4番目：最もうるさいチームではなく 中央値のチームのために構築
  • 5番目：SLO、オンコール、サポートティアなど 運用を第一級の機能として 扱う
  • 6番目：システム能力と同じくらい 共感力を基準に採用
  • 7番目：隔週の成果・課題、透明なロードマップ、率直なステークホルダー管理など 容赦ないコミュニケーション
  • 8番目：不要なものを 終了、統合、拒否
• DORA データと一貫して、プラットフォーム品質は AI 導入を含むあらゆるものの乗数 — 悪いプラットフォームでは AI ツールが混乱を増幅し、良いプラットフォームではスループットを増幅する
• ロケットを作る前に、まず床を作らなければならない

[kalista22]

社内コミュニケーションが何より重要だと考えています。