Effective Platform Engineeringの邦訳版が出たので読んでみた。

実践 プラットフォームエンジニアリング─開発者体験を加速するセルフサービス基盤の設計と構築

• 執筆: Ajay Chankramath, Nic Cheneweth, Bryan Oliver, Sean Alvarez
• 翻訳: 株式会社スリーシェイク（元内柊也、小池玲斗、木曽和則、下村俊貴）
• マイナビブックス、2026年

私が読んだのはPDF板。 なお本書は会社のSLP（Self Learning Program）という仕組みを利用して購入した。

どんな本か

こんにち、プラットフォームエンジニアリングのマインドセットは言語化され、例えば “CNCF Platforms White Paper” などで参照可能になっている 一方で、それらを具体的にどのように実現するかについては、まだまだ情報は充分とはいえない。 本書は、コンサルタントとしてエンジニアリングプラットフォームの実装に関わり、多くの場数を踏んだ著者らによるものなのでこの “how” の部分が手厚く解説されている。 ちなみに著者陣のキャリアは、4人全員がThoughtworksあるいはBrillioにあり、これはつまりプラットフォームエンジニアリングにとって重要な要素であるスケール性を扱った経験が豊富ということを意味する。 また、特定のプラットフォームプロダクトのベンダー企業ではないというところも、実践形式の書籍として良い点といえる。

本書の他に、プラットフォームエンジニアリングに関して体系的に読める別の書籍としてはオライリージャパンの『プラットフォームエンジニアリング』¹もあるが、本書のほうが後発なだけあって現時点におけるプラットフォームエンジニアリングの業界の標準が反映されている。 2026年時点において、プラットフォームエンジニアリングについて知りたい人がまず読むならば、あちらの本よりも本書を先に読むと良さそう。 本書で「どんな世界観をどう実装するか」を理解したあと、「それを社内（政治的制約がある環境）でどう推進するか」について『プラットフォームエンジニアリング』を読みながら考えてみるとよい。

また本書はプラットフォームエンジニアリングの定義に成功指標の計測も含めており、オブザーバービリティを第一級市民として扱っているところも特徴といえる。

個人的に目に止まったところ

第2章 ソフトウェア・デファインドのプロダクトとアーキテクチャ

1年後にプラットフォームがどう使われるかを予測するのは不可能（p.44）

この解釈は難しいところだと思う。 本書は技術選定時にはなるべく少ない機能のものを選ぶことを推奨しているが、だからといってここの記述は「今だけを見て意思決定しろ」という意味ではないはず。 チームとして戦略的視点に基づいた動きをしていることは恐らく前提（…そうだよな？）。 要はよくよく気をつけろというメッセージと理解した。

それにしても「不可欠だと思われていたケイパビリティが実は不要だった」は肝に命じておきたい。 YAGNIとは昔から言われるが、ここで述べられているのは「あったら良いと思ったが不要だった」ではなく、「不可欠だと思ったが不要だった」だから恐ろしい。 要件を考える段になってYAGNIを唱えるのではなく、戦略レベルから注意を払わないとだめということ（難しい）。

ドメイン駆動プラットフォーム設計（p.54）

プラットフォームエンジニアリングの文脈でDDDを強調しているのは本書の一つの特徴。 個人的には、ソフトウェア開発ど真ん中のキャリアではないながらも、DDDについては本業とは別に継続的に自己投資してきたので、これまで学んできたことが本書を読んで数年（5年くらい？）のタイムラグを経てつながった感じがある。

スムーズな開発者体験を実現するインフラコスト配賦（p.59）

ここで書かれているスムーズな開発者体験は、顧客チームにインフラのコスト配賦をできている前提。 バックオフィスとも連携がとれた組織のレベルが高い話だ。

手動プロセスによる機会損失（p.60）

手動プロセスが機会損失につながることは誰でも知っているが、コストや効果の計測を第一級市民として扱う本書では、機会損失は言葉だけでなく実際に算出する値としての意味を持っている。 こういった広い意味でのオブザーバービリティは、短期的な顧客価値につながりづらいので推進が難しいが、裏を返せばオブザーバービリティ確保の先延ばしは、チームが「このプロダクトは（たぶん）顧客の生産性を高めた（んだと思う…）」という状態で働き続けることを意味する。

組織固有のケイパビリティをk8sのAPI拡張でオーケストレーションする（p.62）

自動化はソフトウェアエンジニアリング文化の空気みたいなものだが、オーケストレーション──確実に動き続ける──まで保証できるのはプラットフォームエンジニアリングならではのアプローチだと思う。

第3章 計測で導くプラットフォームエンジニアリングの成功

エンジニアリングプラットフォーム構築のデシジョンツリー（p.70）

図3.2のデシジョンツリーは、プラットフォーム構築がプラスになるかどうかの境界フェーズにある組織にとってはなかなか役立ちそう。

プラットフォーム価値モデリング（p.77）

プラットフォームチームの取組みが組織のバリューストリームから遠ざかることについて、これまでにもアンチパターンとして認識されてきた（例）。 本書が「プラットフォーム価値モデリング」としてモデル化したことで、世のプラットフォームチームは「アンチパターンに陥らないようにする」という具体性を欠いた否定形ではなく「プラットフォーム価値モデリングする」と能動態で考えられるようになった。 これは一種のケイパビリティだと思う。

パフォーマンスメトリクス | オンボーディング時間（p.86）

社内プラットフォームだからといって認証をおろそかにすると、こういったオブザーバービリティ面でツケが回ってくる。

エンジニアリングプラットフォームのプロダクトドメイン（p.91）

図3.8は抽象的だが、ここで表されているものは、AWS上にEKSで環境を構築しているチームならば普通に使っているリソースを、本書の基準で分類したもの。 この8つの分類は初見時にはあまりしっくりこないかもしれないが、“6.4 クラウド管理ID”（p.193）以降で登場するそれぞれの分類の解説を読めば、その合理性がだんだんわかってくる。

第4章 ガバナンス・コンプライアンス・信頼

IDプロバイダーソリューション（p.117）

チームの境界で見られがちな「依頼」という協働パターンを撲滅するヒントがある。

第5章 進化するオブザーバービリティ

オブザーバービリティの8つのレンズ（p.131）

2026年現在、「オブザーバービリティ」といえば一般にはアプリケーションのオブザーバービリティを指すと思うが、本書ではそれをエンドユーザー（社内の開発者ユーザーのこと）体験を制限するアンチパターンと言い切っている。 本書はオブザーバービリティを「エンジニアリング」カテゴリと「ビジネス」カテゴリそれぞれ4つづつの主要8軸に分類し、組織のすみずみまで可観測性がある世界観を提示している。 当然「データ分析基盤」と呼ばれるものまで含むので、恐らくすべてプラットフォームチームが担当するわけではないだろう。 もしくは、いま「データエンジニアリングチーム」と呼ばれるものもプラットフォーム組織配下のチームとして考えているのかもしれない。

第6章 ソフトウェア・デファインドなエンジニアリングプラットフォームの構築

名前空間レベルのパイプライン（p.170）

ここで解説されているpreviewクラスタはおもしろい。 社内顧客を抱えるチームとして、インフラのメンテを安心して当てるのに合理的な構成となっている。

第7章 プラットフォームコントロールプレーンの基礎

クラウドアカウントのベースライン（p.214）

ここに差し掛かると、本書がこの「クラウドアカウントベースライン」を、前章で解説された「クラウド管理ID」とは異なるレイヤーのリソースとして認識していることを理解できる。 本来、AWSのリソースモデルの構造としては「アカウント」の下に「IAMロール」があるわけだが、本書の認知モデルではまず「クラウド管理ID（IAMロールが含まれる）」があり、その上に「クラウドアカウントベースライン（AWSアカウントを指す）」が載っている。 もちろん、AWSのリソースモデルとは異なるこの認知モデルが常に最高なわけはないが、複数アカウントの運用そのものが業務ドメインの中心にあるプラットフォームエンジニアリングの文脈では、なるほどこの整理は合理的だ。

ただ環境を動かすだけなら誰にでもできる。 きれいに運用するのが難しい。 こうやって見せてもらえれば腹落ちするのだが、この整理は自分では思いつけそうにない。 ここはなかなか勉強になった。

第8章 コントロールプレーンのサービスとエクステンション

プラットフォームエンジニアリングとDevOpsのアプローチの違い（p.317）

「スターターキット」のプラクティスを例に、DevOpsとプラットフォームエンジニアリングの違いが解説されている。 この解像度での解説は本書ならではで、両者は全く違うことがわかる。 特にプラットフォームエンジニアリングをする立場にあるならば、きちんと理解しておく必要がある。

第9章 スケールを支えるアーキテクチャの変更

アジャイルプラクティスの導入（p.358）

『プラットフォームエンジニアリング』はプラットフォームチームがアジャイルな進め方をすることにかなり注意深い態度だったが、本書はけっこうアジャイル派な印象。

第10章 プラットフォームプロダクトの進化

内部開発者プラットフォーム（IDP）と開発者ポータルの比較（p.378）

名前からしてそもそも紛らわしいので、ここは多くの読者が注意深く読みそう。 解説されてみれば、両者は確かに全く異なるし、はっきり使い分ける必要がある。

理解しにくかった箇所の個人的メモ

p.10

3つの概念は互いに依存し合っています

“4つの概念” だろうか。

余談だが、図1.3のような循環を表す模式図は、矢印を曲線にするだけで飛躍的に理解しやすくなる。

p.20

ハンドオフ: 仕事の受け渡しのこと

p.21

図1.8

• SAST: static application security testing
• DAST: dynamic application security testing

p.29

セキュリティステークホルダーが企業認証基準を、(1) 内部認証の単一の信頼できるソースを要求し、(2) 内部実装をOAuth 2.0 フレームワークに基づくものと定義する場合です

これは恐らく下記の意味だと思う。

セキュリティステークホルダーが企業認証基準を下記のように定義する場合です。

• (1) 内部認証の単一の信頼できるソースを要求するもの
• (2) 内部実装をOAuth 2.0 フレームワークに基づくもの

p.33

成功は、独立してドメインに専念する開発チームから生まれます。各チームは自分たちのドメインに固有のアイデアを試行します。計測可能な体験と価値を生み出すためにソフトウェアを構築してテストします。そして、ソフトウェアを顧客にリリースし、質の高いユーザー体験を確保しながら結果を注視して管理します

これは恐らく下記の意味だと思う。

成功は、独立してドメインに専念するアプリケーション開発チームから生まれます。各チームは自分たちのドメインに固有のアイデアを試行します。計測可能な体験と価値を生み出すためにソフトウェアを構築してテストします。そして、ソフトウェアを社外顧客にリリースし、質の高いユーザー体験を確保しながら結果を注視して管理します

p.80

「認知負荷の増加は10%以内」はどう計測するんだろう。 p.82には「認知負荷の影響を評価する体系的な手法が存在します」とだけ書いてある。 認知心理学の分野では確立されていたりするんだろうか。

ちなみに、複数のプラットフォームプロダクトが時間差でリリースされた場合、認知負荷の変化がどのプロダクトによるものなのかわからなくなりそう。 成功指標の計測を徹底している組織では、同じ認知コンテキストに影響する変更が一つづつになるよう、リリース管理するんだろうか？

p.89 表3.1, 3.2

これらの情報は表で表してはいけない（同じ行間を比較したくなる）。 実査には下記のように、単なるリストで表示するのが正しい。

表3.1

• 計画
  • 開発者の関与
  • 顧客フィードバックループ
  • …
• 設計
• コード
• ビルド

表3.2

• テスト
  • テストの種類
  • テスト自動化
  • …
• リリース
• 監視
• 運用

p.138

5.2.1 エンドユーザーのアクセス体験

エンドユーザーとは、プラットフォームサービスとしてのオブザーバービリティ機能を利用する社内開発者ユーザーのこと。 個人的には「エンド」と付くと本当の末端（会社が提供しているプロダクトのユーザー）をイメージしてしまうので紛らわしく感じる。

p.139

5.2.2 顧客データの自動収集

ここの「顧客」とは社内開発者ユーザーのこと打と思う。 判断根拠は、p.140に「アプリケーションチームは、自分たちのデータがどのように収集され保存されるかという内部の仕組みを気にせず済みます」とあること。 よって「自分たちのデータ」とは「自分たちが所有するデータ」の意味であって、「自分たちが生成したデータ」ではないはず。 従って、実際にはデータの中身は会社が提供しているサービスのユーザーのアクセスデータなどが含まれているはず。

p.186 図6.14

• 誤: my-orb/name of job-in-orb
• 正: my-orb/name-of-command-in-orb

p.193 図6.16

「エンジニアリングプラットフォームドメイン」が指しているのはたぶん「EPステートアカウント」配下なんだろう。 「EPステートアカウント」は「Engineering Platformステートアカウント」と思われる。 「EP非本番アカウント」と「EP本番アカウント」はプラットフォームの社内顧客が使うんだと思う。 「domain-nameアカウント」はどこかのチームが何かの用途に使っているアカウントとの関係を示しているだけで、これらの解説は恐らく本書には出て来ていない。

p.214

このドメインは、同じくクラウドアカウントレベルの設定を扱う点で前のドメインと似ている

これは下記の意味、

「この概念は、同じくクラウドアカウントレベルの設定を扱う点で、前章（6.4）で説明したクラウド管理IDと似ている」

p.275

エンジニアリングプラットフォームプロダクトのリーダー層に直接属さないチームも含めて作業を分担せざるを得ない圧力もかかる

これは恐らく下記の意味:

「直接属さないチームも含めて作業を分担せざるを得ない圧力が、エンジニアリングプラットフォームプロダクトチームのリーダー層にかかる」

両者の違いをもう一度見てみましょう

「もう一度」とあるが初出と思われる。

p.276

エクステンション

私は「サービス」「エクステンション」という分類にあまり馴染みがなかったが、本書が示す分類基準でいえば、例えばCrossplaneは恐らく「エクステンション」に分類されるのだろう。

p.340 図9.11

図中に見慣れない黒い点があるが…ストリームイベントを示している？

p.344 図9.15

2本の垂直線の太さが同じだが、恐らく左はy軸、右はリリースイベントがあったx軸上の位置を示すものと思われる。

所感

本書を読むと、自チームでも適用 or 参考にしたくなるものが何かしら見つかるのではないかと思う。