# プラットフォームエンジニアリング ## 定義 プラットフォームエンジニアリングは、開発者が安全・効率的にプロダクトを構築・デプロイ・運用できる内部セルフサービス基盤(IDP)を構築・運用するディシプリンである。[[SRE]] と密接に関係するが、対象は本番サービスの信頼性制御そのものではなく、開発者体験と基盤機能の汎用化にある。([[@2024__yuuk.io__SRE-NEXT-2024]]) ## 横断的知見 - SRE NEXT 2024 の文脈では、Platform Engineering と AI が国内 SRE の二大技術トレンドとして扱われた。([[@2024__yuuk.io__SRE-NEXT-2024]]) - プラットフォームエンジニアリングの浸透は、SRE、共通基盤開発、IT インフラの役割境界を明確化し、SRE を「信頼性を制御する工学」として捉え直す助けになる。 - 国内 SRE の成熟は、Blameless 文化、トイル削減、SLI/SLO、オブザーバビリティ、インシデント対応組織化を経て、基盤チームの責務整理へ進んだと読める。 - **Platform Engineering は「You build it, you run it」で開発者側に寄りすぎたインフラ運用の認知負荷を、プラットフォームチームが引き受け直す動きとして系譜づけられる**: mizzy(2026)は、DevOpsの実践が開発者自身にインフラ運用まで担わせる方向へ進んだ結果、開発者側の認知負荷が増大し、それをプラットフォームチームが再び引き受けようとする動きがPlatform Engineeringだと整理する。「プロダクトチームへ責任が移った結果インフラへの認知負荷が増え、プラットフォームで引き受け直す」という認識はCNCF Platforms White Paperにも書かれているとされる。この見立てでは、Platform Engineeringは [[DevOps]] が包含していた「誰がどこまでインフラ運用を担うか」という分担問題が、名前と形を変えて今も続いていることの表れであり、2022年前後の「DevOps is dead, long live Platform Engineering」という論争もこの分解の一段階として位置づけられる。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **Platform Engineeringが「認知負荷の引き受け直し」として機能しない2つの失敗パターンが、DORAの「AIは既存の行動を増幅するだけ」という知見と組み合わさると、AI時代にPlatform Engineeringの成否が組織の分岐点になる理由が見える**: 『Observability Engineering』第2版第23章は、Platform Engineeringの失敗を(1)プロジェクト化(ローンチして祝って終わり、他の仕事へ異動)、(2)単純改名(運用モデル・ディスカバリープロセスを変えないまま既存のDevOps/インフラチームを改称するだけ)の2パターンに分類する。mizzyが描く「認知負荷の引き受け直し」という理念上の系譜と重ねると、この2パターンはいずれも引き受け直しが実質的に起きていないケースであり、開発者は依然として顧客として扱われず、負債は新しい名前の下で存続する。第23章はさらに、AIによる変更量の増大がこの負債を指数的に増幅すると指摘しており、[[DORA]]の「AIは既存の行動パターンを増幅するだけ」という2025年知見と接続すると、Platform Engineeringを名ばかりでなく実装できた組織とできなかった組織の差がAI時代に急拡大するという予測が導ける。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]]) - **観測可能性(オブザーバビリティ)チーム自身の組織的位置づけを、プラットフォームエンジニアリングの型で規定する規範が第26章に現れる**: mizzy(2026)と第23章はプラットフォームエンジニアリングを「開発者側に寄りすぎた認知負荷をプラットフォームチームが引き受け直す動き」として一般的に系譜づけたのに対し、[[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]] はこの一般論を「オブザーバビリティチームはインフラ/運用型ではなくプラットフォームエンジニアリング型で運営すべき」という具体的な組織設計の処方箋に落とし込む。同章は platform の「Prime Directive」(その会社固有だが全チーム共有の部品を作る)に従い、ソフトウェアエンジニアを顧客とみなすデザイン思考・ユーザーリサーチを用い、自動計装を「魔法のように」感じさせ、開発者の認知的オーバーヘッドを最小化すべきだと述べる。第23章が指摘する「プロジェクト化」「単純改名」という2つの失敗パターンへの警句(「プラットフォームエンジニアリングチームと名乗るだけでOSSの寄せ集めを運用しているだけの状態」)も第26章に引き継がれており、オブザーバビリティという1機能ドメインに対してプラットフォームエンジニアリングの一般原則がそのまま適用される実例になっている。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]]) - **第23章が示した「プロジェクト化」「単純改名」という失敗パターンに対し、第28章は同じ書籍の中で回避策を具体化する**: 第23章はプラットフォームエンジニアリングの失敗を(1)プロジェクト化、(2)単純改名の2類型に分類したが、回避のための具体的な手順は詳述しない。第28章の「Platform Engineering Principles」節は、開発者・SRE・セキュリティ・サポート・経営層を明示的な「顧客」として扱い、フィードバックを継続的に収集し、採用率と満足度で成功を測るという運用原則を提示する。さらに「独自ソフトウェアは最小限にとどめ、OpenTelemetry のようなオープン標準とコモディティ購入を優先する」という具体的な指針は、単純改名(既存ツールをそのまま改称するだけ)ではなく実質的な基盤刷新を強制する仕組みとして機能しうる。同一書籍内の2章を並べることで、抽象的な失敗診断(第23章)と具体的な回避策(第28章)が補完関係にあることが見える。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **「ゴールデンパス」による認知負荷の引き受け直しは、mizzy の系譜論(DevOps→Platform Engineering)が描く理念を、具体的な設計原則として裏付ける**: mizzy(2026)は Platform Engineering を「開発者側に寄りすぎたインフラ運用の認知負荷を、プラットフォームチームが引き受け直す動き」と整理したが、これは理念レベルの説明にとどまる。第28章の「Pave the Path」節は、数行のコードでサービス境界を越えてコンテキストが自動伝播する計装ライブラリと、90%のケースで正しいデフォルト値という具体策を挙げ、「正しいことが同時に楽なことになれば導入が進む」という設計原則を示す。これは mizzy の系譜論が指す「引き受け直し」を、ライブラリ設計・デフォルト値というエンジニアリング上の実装単位まで分解したものと位置づけられる。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **第29章のbuild-versus-buyフレームワークは、第23・26・28章が積み上げてきた「プラットフォームエンジニアリング型で運営せよ」という規範に、何を自前で作り何をベンダーから買うべきかを判定する具体的な選別ロジックを与える**: 第23・26・28章は「独自ソフトウェアは最小限にとどめOpenTelemetryのようなオープン標準とコモディティ購入を優先する」という方向性は示すが、個々のコンポーネントごとに build/buy をどう判定するかの手続きは詳述しない。第29章のRick Clark考案の2×2マトリクス(ビジネス価値×普遍性)と「buy and build」のプラットフォームモデルは、この判定手続きそのものを提供する。同章が挙げるオブザーバビリティチームの役割(ライブラリ・共通命名規則の整備、ベンダー関係管理、他チームへの計装コンサルティング)は、第26章が処方する「デザイン思考でソフトウェアエンジニアを顧客として扱う」姿勢や第28章の「Platform Engineering Principles」節が示す運用原則と同一の職務リストであり、抽象的な規範(第23・26・28章)と判定ロジック(第29章)が相互に補完する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]], [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]], [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]]) - **第28章の「Pave the Path」がライブラリ設計・デフォルト値という実装単位の抽象論だったのに対し、第31章はGoogle Dapperの実例で「経路をどこに敷くべきか」を特定する具体的な調査手法を与える**: 第28章は「正しいことが同時に楽なことになれば導入が進む」という設計原則を、コンテキスト自動伝播の計装ライブラリと90%ケースで正しいデフォルト値というエンジニアリング単位に分解した。第31章はこれを一段具体化し、Dapperチームが「エンジニアが既にどのツール・画面で障害対応をしているか」を調査した上で、その監視グラフへリンクを1本追加しただけで利用が倍増・3倍増した逸話を紹介する。両者を重ねると、「舗装された道」戦略は(1)ライブラリ・デフォルト値による摩擦の除去(第28章)と(2)エンジニアが既に集まる場所の特定という導線設計(第31章)の2段構成であることが分かり、後者を怠るとどれだけ摩擦の少ないライブラリを作っても発見されないままになりうるという補完関係が見える。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]], [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]]) - **オブザーバビリティチームを「計装コード自体でなく計装フレームワーク・パイプライン・SLOツールを広く所有する」役割と定義する第31章の冒頭規範は、第26章「プラットフォームエンジニアリング型で運営せよ」の処方箋を計装領域に特化して再確認する**: 第26章はオブザーバビリティチーム全般をプラットフォームエンジニアリング型で運営すべきだと処方したが、具体的にどこまでの範囲を「所有」すべきかは詳述しない。第31章は冒頭で「計装コード・フレームワーク、テレメトリパイプライン設定・管理、アラート基盤、SLOツール」を広く所有すべきだが、計装コード自体を書くのは必ずしもチームの仕事ではなく、他者がどれだけ書くかで評価されると述べ、プラットフォームチームの典型像(セルフサービス基盤の提供者であり実装者ではない)をオブザーバビリティ領域で具体化する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]]) - **『SREをはじめよう』17章は、SREがプラットフォームエンジニアリングと「出会う」経路を、mizzyの系譜論より一段具体的な組織規模の軌跡として描く**: mizzy(2026)は Platform Engineering を「DevOpsが開発者側に寄せすぎた認知負荷を、プラットフォームチームが引き受け直す動き」として一般的に系譜づけたが、SREという特定の職能がその動きにどう合流するかには踏み込まない。17章は、SREチームが規模を拡大する過程で「組織全体の信頼性の階層」(監視ライブラリ・権限付与ライブラリ・カナリアデプロイツール・RPCライブラリ)を段階的に構築し始め、これが「SREがプラットフォームエンジニアリングと呼ばれる新しい潮流と出会う場所の1つ」になると明言する。著者は、SREが信頼性の面で貢献する経験とインセンティブを持ち、システム全般を長年扱ってきた経験から保守・運用が容易なプラットフォームの構築方法に強い意見を持つと述べており、mizzyの一般的な系譜論に「SREという職能がなぜこの引き受け直しに向いているか」という具体的な根拠を加える。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]], [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **17章の「組織全体の信頼性の階層」の4例(監視・権限付与・カナリア・RPCの各ライブラリ)は、第28章「Pave the Path」の設計原則を、本格的なプラットフォーム構築以前の段階的なステップとして裏付ける具体例を追加する**: 第28章は「正しいことが同時に楽なことになれば導入が進む」という設計原則を、コンテキスト自動伝播の計装ライブラリと90%ケースで正しいデフォルト値というエンジニアリング単位に分解した。17章は、監視ライブラリを例に「新サービスはこのライブラリにリンクするだけで監視システムに正しいことをするようになり、よほどの理由がない限り全サービスがこのライブラリを使うことが期待される」と述べ、第28章の原則と同型の「摩擦の少なさによる自然な普及」パターンを、権限付与・カナリアデプロイ・RPCという計装以外の3領域にも一般化できることを示す。両ソースを並べると、「舗装された道」戦略は計装領域に限らず、SREが組織で「誰もが使う」基盤を構築する場面全般に適用される設計原則であることが分かる。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **『SREエンタープライズロードマップ』第4章の「リスクの低いサービスから MVP で採用する」段階的採用曲線は、第28章のロードマップ実行段階(1ドメインでの実証→ゴールデンパス整備→段階的拡大)に「どのサービスから始めるか」という選定基準を追加する**: 第28章は「1つのドメインで実証し、ゴールデンパスを整備し、段階的に拡大する」という時間軸の手順は示すが、最初に選ぶドメイン(サービス)をどう選定するかには踏み込まない。第4章は、プラットフォームの機能拡張を「リスクの低いサービスを最初に採用して MVP(実用最小限の製品)を小さく保つ」と定式化し、図4-1でリスクの低いサービスは早期に緩やかに、リスクの高いサービスはプラットフォームへの信頼が育つまで意図的に採用を遅らせるという 2 本の軌跡を対比する。これは第28章の段階的拡大の「1ドメイン目」をどう選ぶべきかという未解決だった選定基準に、リスクという明示的な軸を与える。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **第4章の「開発者の要望」と「環境面の必要性」という2つの着想源は、第26章のデザイン思考による顧客ニーズ収集と第28章の Pave the Path 設計原則を、機能選定の意思決定プロセスとして束ねる**: 第26章はソフトウェアエンジニアを顧客とみなしニーズを収集すべきと処方し、第28章はコンテキスト自動伝播ライブラリやデフォルト値という実装単位の設計原則を示すが、両者とも「次に何を作るか」をどう決めるかの意思決定ロジックは明示しない。第4章は、開発者から直接寄せられる要望(「メッセージバスが必要だ」)と、環境が示す必要性(SDLC 強化・リライアビリティエンジニアリングの改善)という 2 系統の入力を並置し、プラットフォームの機能拡張をこの両輪で判断すべきだと述べる。これは第26・28章が前提としていた「顧客ニーズの把握」を、能動的な要望収集(開発者起点)と受動的な環境観察(信頼性課題起点)という 2 つの経路に分解する。(Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]], [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **『SREの探求』6章のSoundCloud「プラットフォーム」チーム(2012年)は、mizzyが2026年に理論化した「認知負荷の引き受け直し」を、名称も理論もない状態で14年早く実践した一次史料である**: mizzy(2026)は、Platform Engineeringを「DevOpsの実践が開発者自身にインフラ運用まで担わせた結果生じた認知負荷を、プラットフォームチームが再び引き受け直す動き」として系譜づけた。SoundCloudの事例はこの系譜の最初期の具体例そのものである——マイクロサービスへの移行で生じた大量のサービスに対し、専用サーバー・設定管理・デプロイ手順の準備が追いつかず摩擦とサイクルタイムの長期化が生じたため、Heroku に似せ12 Factor App をサポートするコンテナベースのデプロイプラットフォーム(愛称 Bazooka)が構築され、これを維持するために「プラットフォーム」チームが発足した。開発者はGitリポジトリへのプッシュだけでデプロイでき、「設定管理の習得に時間をかけなくてもアプリケーション開発者がすぐにアクセスできるもの」になったと明記されており、これはmizzyが描く「開発者側に寄りすぎた認知負荷を引き受け直す」動きの、Platform Engineeringという語が存在する前の実例である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2.1, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **ProdEngチームによるデプロイプラットフォームの「わざわざゲートキーパーにならない」提供様式は、第28章の「Pave the Path」原則を、ゲートキーピングの完全な放棄という一段強い形で先取りする**: 第28章の「Pave the Path」は摩擦の少ない計装ライブラリとデフォルト値による自然な普及を説く。SoundCloudのProdEngチームは、プラットフォームチームからデプロイプラットフォームの所有権を引き継いだ後、「わざわざゲートキーパーにならなくても、すべてのエンジニアリングチームとの間で必要な接触を維持する」ことを明言し、機能リリースを止める公式権限もエラーバジェットのような強制力も持たない。これは第28章が示す「正しいことが同時に楽なことになれば導入が進む」という設計原則を、権限による強制ではなく基盤サービスの必要性そのものによる自然な接点維持として、より徹底した形で実践する事例である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2.3, [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **『SREの探求』7章のSpotifyは「ゴールデンパス(Golden Path)」という語を、第28章「Pave the Path」より先に、義務化せず使いやすさで普及させる設計思想とともに明示的に用いている**: 第28章の「Pave the Path」原則は、コンテキスト自動伝播の計装ライブラリと90%ケースで正しいデフォルト値という実装単位で「正しいことが同時に楽なことになれば導入が進む」と説く。Spotify(7章、原書2018年)は2015年に「ゴールデンパス」という用語を使い始め、「『公認のスタック』を必須のソリューションとして義務付けるのではなく、ゴールデンパスをとても簡単に使えるものにすることで、あえて他の何かを使う理由など見当たらないと思ってほしかった」と明言し、Apollo(Javaマイクロサービスフレームワーク)・Heroic(TSDB)・Helios(Dockerオーケストレーション)という具体的なツール群でこれを実装した。既出の SoundCloud(6章、Bazooka)がデプロイプラットフォームという単一ツールの提供にとどまるのに対し、Spotify のゴールデンパスは開発・デプロイ・モニタリングを貫く複数ツールの統合された「道」であり、「Pave the Path」という語彙が体系化される前に、より広い範囲でこの設計思想を実践した先行例である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.7.1, [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]]) - **Spotifyのゴールデンパスは、対応範囲外のユースケースが断片化を招き、事実上の標準を運用チームが「マネージドサービスとして回収」する場面まで記録しており、第28章・第4章が扱わない「舗装された道の限界と是正」の事例を加える**: 第28・4章はゴールデンパス/プラットフォームの整備と段階的拡大の手順を扱うが、対応範囲外のユースケースが生じた場合の対処には踏み込まない。Spotify(7章)は、ゴールデンパスが Apollo サービス以外(レガシー Python・データパイプライン等)への明示的サポートを欠いたため、分隊が独自の Jenkins インスタンスを運用し始めて事実上の CI 標準となったが、メンテナンス不足からセキュリティ上の問題が生じ、最終的に運用チームが明示的にサポートするマネージド Jenkins サービスへ回収したと記録する。Cassandra クラスタも同様に、提供したのに開発者がメンテナンスしていない実態が判明し、マネージドサービスとして運用チームの所有に戻された。これは、舗装された道の対応範囲を「拡張し続ける」以外に、分隊の自主的な代替ツールが公式基盤へ回収されるべきタイミングをどう判断するかという、既出ソースにない運用局面を加える。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.7.3, [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]], [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]]) - **『SREの探求』10章のOaaS(Operations as a Service、原書2018年)は、SoundCloud(2012年、Bazooka)・Spotify(2015年、ゴールデンパス)という既出の無名の実践例と、mizzy(2026年)の事後的な理論化との間に、設計パターンそのものに明示的な名前を与えた中間点として位置づけられる**: 既出の知見は、SoundCloudのBazooka(2012年)を「Platform Engineeringという語が存在する前の実例」、Spotifyのゴールデンパス(2015年)を「Pave the Pathという語彙が体系化される前の先行例」として、いずれも実践が先行し命名が後追いした事例と位置づけてきた。10章のOaaSはこれらとは性格が異なる——Damon Edwardsは特定企業の1事例を語るのではなく、「自動化された手順を定義および実行するための機能を安全に分散させるためのプラットフォーム」を「汎用で一見シンプルな設計パターン」として最初から抽象化し、OaaSという名前を与えたうえで、機能横断型・開発運用分離型という異なる2つの組織モデルへの適用可能性まで論じる。SoundCloud・Spotifyが「まず作って、後で理論家が名付けた」のに対し、10章は「まず名付けて、汎用化した」という逆の順序を取っており、Platform Engineeringという用語が一般化する(mizzy, 2026年)以前に、汎用セルフサービス基盤という同種の設計思想に対して独立に生まれた命名の系譜が存在したことを示す。ただしOaaSはRundeck社(Edwardsの共同創業した会社)の製品思想と結び付いた用語でもあり、mizzyやObservability Engineering第2版が扱う「Platform Engineering」ほど業界に広く定着した語彙ではない。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 10 大企業でSRE導入の道を開く方法]] §10.7.3, [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] §6.2.1, [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] §7.7.1, [[@2026__mizzy.org__DevOpsとは何だったのか]]) ## 未解決の問い - OaaS(2018年、Damon Edwards)という名前を与えられた設計パターンが、その後の業界で「Platform Engineering」という用語に収斂せず独自の系譜(Rundeck社のマーケティング用語)にとどまった理由は何か。同時期に生まれた複数の命名(OaaS・ゴールデンパス・Pave the Path)のうちどれが業界標準の語彙として生き残ったかの比較は、本 concept の現ソース群ではまだ体系化できていない。 - SoundCloudのBazooka(2012年、コンテナベースのデプロイプラットフォーム)は、後にKubernetesへ完全移行したとされる。Docker以前に構築された独自コンテナオーケストレーションから業界標準への移行過程は、プラットフォームエンジニアリングの「自作から標準への収束」という一般的なパターンの具体例になりうるか。本 concept の現ソース群では他の移行事例との比較がまだない。 - プラットフォームチームと SRE チームの責務境界は、組織規模やプロダクト成熟度でどう変わるか。 - Internal Developer Platform の信頼性は、SRE の SLO/エラーバジェットでどう管理すべきか。 - AI/agentic SRE が浸透すると、プラットフォームエンジニアリングのセルフサービス性はどう変化するか。 - 「プロジェクト化」「単純改名」以外に、Platform Engineeringの導入が形骸化する典型パターンはあるか。成功事例(開発者を真に顧客として扱えた組織)の具体的な実践は他ソースでどう記述されているか。 - 第29章のbuild-versus-buyマトリクスを、プラットフォームエンジニアリングが扱うオブザーバビリティ以外の内部基盤(CI/CD、シークレット管理、Service Catalog等)にそのまま適用した場合、判定結果はどう変わるか。 - 17章が挙げる「監視・権限付与・カナリア・RPCライブラリ」という4例は、いずれも47章時点(48-108人規模)より前の段階的なステップとして提示されるが、本格的なIDP(Internal Developer Platform)構築へ至るまでの中間段階の具体例は他ソースでどう記述されているか。 ## 関連 - 概念: [[SRE]] / [[トイル]] / [[サービスレベル目標]] / [[agentic SRE]] / [[DevOps]] / [[ソシオテクニカル負債]] / [[DORA]] / [[SRE組織変革]] / [[Build Versus Buy]] - ソース: [[@2024__yuuk.io__SRE-NEXT-2024]] / [[@2026__mizzy.org__DevOpsとは何だったのか]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]] / [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]] / [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]] / [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]] / [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]] - 実体: [[Dapper]] / [[SoundCloud]] / [[Björn Rabenstein]] / [[Matthias Rampke]] / [[Spotify]] / [[Drew Michel]] / [[Lynn Root]] / [[Johannes Russek]] - 概念: [[分隊型運用]] / [[サービスとしての運用(OaaS)]] - ソース: [[@2021__OReillyJapan__SREの探求 - Chapter 10 大企業でSRE導入の道を開く方法]] — OaaS(Operations as a Service)という汎用セルフサービス設計パターンの明示的命名(2018年原書) - 実体: [[Damon Edwards]] / [[Rundeck Inc.]] ## 出典 - [[@2024__yuuk.io__SRE-NEXT-2024]] - [[@2026__mizzy.org__DevOpsとは何だったのか]] — DevOps から Platform Engineering への認知負荷再配分としての系譜 - [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]] — Platform Engineering導入の2つの失敗パターン(プロジェクト化・単純改名) - [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]] — オブザーバビリティチームをプラットフォームエンジニアリング型で運営すべきという処方箋 - [[@2026__OReilly__Observability Engineering 2E - Chapter 28 The Organizational Shift]] — 失敗パターンへの具体的な回避策(顧客志向・ゴールデンパス・オープン標準優先) - [[@2026__OReilly__Observability Engineering 2E - Chapter 29 Build Versus Buy (Versus Open Source)]] — 何を自前で作り何を買うかを判定する具体的なフレームワーク(2×2マトリクス・buy and build) - [[@2026__OReilly__Observability Engineering 2E - Chapter 31 Instrumentation for Observability Teams]] — Google Dapperの逸話による「舗装された道」の導線設計、オブザーバビリティチームの計装フレームワーク広範所有という規範 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 17 組織におけるSREの成長]](David N. Blank-Edelman, 2024, 第17章)— SREがプラットフォームエンジニアリングと出会う経路、組織全体の信頼性の階層(監視/権限付与/カナリア/RPCの各正規ライブラリ) - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 4 SREのプラクティス]](James Brookbank, Steve McGhee, 2022, 第4章)— リスクの低いサービスからの MVP 採用曲線(図4-1)、開発者の要望と環境面の必要性という2つの機能選定基準 - [[@2021__OReillyJapan__SREの探求 - Chapter 6 専任SREチームなしでSREの原則を適用する方法]](Björn Rabenstein, Matthias Rampke, 2021, 6章)— 2012年のデプロイプラットフォーム(Bazooka)構築という「認知負荷の引き受け直し」の最初期の実例、ゲートキーパー化を避けるProdEngの基盤サービス提供様式 - [[@2021__OReillyJapan__SREの探求 - Chapter 10 大企業でSRE導入の道を開く方法]](Damon Edwards, 2021, 10章 §10.7.3)— OaaS(Operations as a Service)という汎用セルフサービス設計パターンの命名と、機能横断型/開発運用分離型の2組織モデルへの適用 - [[@2021__OReillyJapan__SREの探求 - Chapter 7 SREのいないSRE：Spotifyのケーススタディ]](Daniel Prata Almeida ほか, 2021, 7章)— 2015年に導入された「ゴールデンパス」という語と Apollo/Heroic/Helios による実装、対応範囲外ユースケースの断片化とマネージドサービスへの回収という限界事例