プラットフォームエンジニアリング

本書への賛辞
まえがき
はじめに

第I部　プラットフォームエンジニアリングとは何であり、なぜプラットフォームエンジニアリングなのか

1章　プラットフォームエンジニアリングが重要になりつつある理由
    1.1　「プラットフォーム」およびその他の重要な用語の定義について
    1.2　過度な一般化の泥沼
    1.3　私たちはなぜ過度な一般化の泥沼にはまってしまったのか
        1.3.1　変化その1：選択肢の爆発的増加
        1.3.2　変化その2：運用に対する高い要求
        1.3.3　結果：泥沼での溺死
    1.4　プラットフォームエンジニアリングによって泥沼から脱出する方法
        1.4.1　オーバヘッドを最小限に抑えながら基本的機能を制限する
        1.4.2　アプリケーションごとのグルーを減らす
        1.4.3　マイグレーションコストを集約する
        1.4.4　開発したものをアプリケーション開発者が運用できるようにする
    1.5　チームがプラットフォーム構築に専念できる環境づくり
    1.6　まとめ

2章　プラットフォームエンジニアリングの柱
    2.1　厳選されたプロダクトアプローチの採用
    2.2　ソフトウェアベースの抽象化の仕組みの開発
        2.2.1　主な抽象化の仕組み：プラットフォームサービスとそのAPI
        2.2.2　シッククライアント
        2.2.3　OSS のカスタマイズ
        2.2.4　メタデータレジストリとの統合
    2.3　幅広いアプリケーション開発者を手助けする
    2.4　基盤としての運用
        2.4.1　プラットフォーム全体の責任を持つ
        2.4.2　プラットフォームのサポート
        2.4.3　運用の規律
    2.5　まとめ

第II部　プラットフォームエンジニアリングの実践

3章　どのように、そしていつ始めるか
    3.1　規模が小さい段階でのプラットフォーム連携の促進
    3.2　相互協力的な体制を置き換えるプラットフォームチームの構築
        3.2.1　中央集権的体制のメリットがコストに見合うかを問う
        3.2.2　共同作業を行う時は過ぎたことを認識する
        3.2.3　新しい技術や新しいアーキテクチャではなく、問題解決に目を向ける
        3.2.4　大きな会社から来たエンジニアには注意する
        3.2.5　PdM の採用は遅らせる（かつ、PjM は採用しない）
        3.2.6　統合サービスプラットフォームや共有されるプラットフォームでの問題
    3.3　伝統的なインフラ組織の変革
        3.3.1　エンジニアリング文化全体の変化が必要
        3.3.2　手を付け始めるのに最も有望な領域を特定する
        3.3.3　PdM たちに押し付けておしまいではないことを認識する
        3.3.4　プロダクトをサポートする方法を変える
        3.3.5　面接のプロセスを新しくする
        3.3.6　成果の評価と報酬のシステムを新しくする
        3.3.7　PjM の数を制限する
        3.3.8　チームがコードを書くよりも顧客との会話に時間を使うことを受け入れる
        3.3.9　必要な組織改革を行う
        3.3.10　楽しむ
    3.4　まとめ

4章　素晴らしいプラットフォームチームを作る
    4.1　視野の狭いプラットフォームチームのリスク
        4.1.1　システムに焦点を当てすぎたチーム
        4.1.2　開発に焦点を当てすぎたチーム
    4.2　プラットフォームエンジニアのさまざまなロール
        4.2.1　ソフトウェアエンジニア
        4.2.2　システムエンジニア
        4.2.3　リライアビリティエンジニア
        4.2.4　システムスペシャリスト
    4.3　各ロールでのエンジニアの採用と評価
        4.3.1　ロール特有の肩書を許容する
        4.3.2　ソフトウェアエンジニア向けの新しい職階表を作るのは避ける
        4.3.3　システム系ロールの職階表は最大でも1 つ
        4.3.4　必要ならソフトウェアエンジニア向けの新しい面接プロセスを作る
        4.3.5　システムロール向けに面接を少しだけ変更する
        4.3.6　顧客への共感についての面接
    4.4　プラットフォームエンジニアリングの素晴らしいマネージャの条件
        4.4.1　プラットフォームの運用経験
        4.4.2　巨大で長期間にわたるプロジェクトの経験
        4.4.3　細部への配慮
    4.5　プラットフォームチームのその他のロール
        4.5.1　プロダクトマネージャ（PdM）
        4.5.2　プロダクトオーナー
        4.5.3　プロジェクトマネージャ（PjM）またはテクニカルプログラムマネージャ（TPM）
        4.5.4　デベロッパアドボケイト、テクニカルライタ、サポートエンジニア
    4.6　プラットフォームエンジニアリングチームの文化を作る
        4.6.1　開発チームとSRE チームに分かれたプラットフォーム
        4.6.2　開発チームの強みと弱み
        4.6.3　2 つのチームの統合とプロダクトマネジメントの導入
        4.6.4　プラットフォームエンジニアリング文化の浸透
    4.7　まとめ

5章　プロダクトとしてのプラットフォーム
    5.1　顧客に焦点を当てるプロダクト文化
        5.1.1　社内顧客の特徴
        5.1.2　社内顧客との協力
        5.1.3　顧客への共感
        5.1.4　フィーチャーショップの罠を避けて、広い視点で顧客に貢献する
    5.2　プロダクトディスカバリと市場調査
        5.2.1　可能性のあるプラットフォーム製品を特定する
        5.2.2　解決策を最適化するか問題を考え直すことで、既存のサービスを進化させる
        5.2.3　市場調査：新たな投資を検証する
        5.2.4　プロダクトメトリクス
    5.3　成功するプロダクトの達成条件：プロダクトロードマップの作成
        5.3.1　ビジョン：長期視点
        5.3.2　戦略：中期視点
        5.3.3　ゴールとメトリクス：年度ごと
        5.3.4　マイルストーン：四半期ごと
        5.3.5　顧客から見えるロードマップ
        5.3.6　機能の仕様
        5.3.7　練習が完璧を生む
    5.4　プロダクトの失敗モード
        5.4.1　マイグレーションコストを過小評価してしまう
        5.4.2　ユーザの変化予算を過大評価してしまう
        5.4.3　安定性が低いうちから新しい機能の価値を過大評価してしまう
        5.4.4　エンジニアリングチームのサイズに比べて多すぎるPdM を抱えてしまう
        5.4.5　EM が行うべき仕事をこなすPdM を抱えてしまう
    5.5　まとめ

6章　プラットフォームの運用
    6.1　オンコールへの取り組み方
        6.1.1　なぜ24 時間365 日のオンコールカバレッジが重要なのか
        6.1.2　なぜ融合型DevOps チームなのか
        6.1.3　継続性のあるオンコール負荷の実現に向けて
    6.2　サポートへの取り組み方
        6.2.1　プラットフォームエンジニアがサポート業務を行うべき理由
        6.2.2　ステージ1：サポートレベルを明確化する
        6.2.3　ステージ2：オンコールからクリティカルでないサポート業務を切り離す
        6.2.4　ステージ3：サポート専門家を雇う
        6.2.5　ステージ4：エンジニアリングサポート組織の規模拡大
    6.3　運用フィードバックへの取り組み方
        6.3.1　SLO とSLA は必須、エラーバジェットは任意
        6.3.2　変更管理
        6.3.3　シンセティック監視
        6.3.4　運用レビュー
    6.4　まとめ

7章　計画とデリバリ
    7.1　長期プロジェクトの計画
        7.1.1　提案文書でゴールと要求仕様を明確にする
        7.1.2　提案からアクションプランへ
        7.1.3　長期間の苦労を避ける
    7.2　ボトムアップのロードマップ計画
        7.2.1　KTLO 作業
        7.2.2　義務的要求
        7.2.3　システム改善
        7.2.4　すべてを1 つにまとめる
    7.3　ウィンアンドチャレンジ：2 週間ごとの成功と課題の共有を通じたステータスのコミュニケーション
        7.3.1　基本
        7.3.2　なぜやるべきか：その価値
        7.3.3　何をするのか：ウィンアンドチャレンジを構造化する
        7.3.4　チャレンジを書き漏らさないように
        7.3.5　ウィンアンドチャレンジはチームに書いてもらう
    7.4　まとめ

8章　プラットフォームのリアーキテクチャ
    8.1　v2 を作るよりリアーキテクチャを選ぶべき理由
        8.1.1　エンジニアリングマインドセットの違い
        8.1.2　アーキテクチャ上のニーズが必要なマインドセットを決める
        8.1.3　v2 プラットフォームは難しいのに、リアーキテクチャは可能である理由
    8.2　アーキテクチャでセキュリティに取り組む
    8.3　リアーキテクチャのガードレール
        8.3.1　互換性
        8.3.2　テスト
        8.3.3　本番以外の環境
        8.3.4　部分リリース、遅延リリース、1 つ前のバージョンの継続利用
    8.4　リアーキテクチャの計画
        8.4.1　ステップ1：リアーキテクチャの最終ゴールを大きく考える
        8.4.2　ステップ2：マイグレーションコストを計算に入れる
        8.4.3　ステップ3：12 か月間の大きなウィンを明確にする
        8.4.4　ステップ4：リーダーたちの賛同を得て、待つ準備をする
    8.5　まとめ

9章　プラットフォームのマイグレーションと廃止
    9.1　マイグレーションのアンチパターン
    9.2　容易なマイグレーションをエンジニアリングする
        9.2.1　グルーを最小化し、バリエーションを制限する抽象化を提供するプロダクトを使う
        9.2.2　透過的なマイグレーションのためのアーキテクチャを考える
        9.2.3　使用量メタデータを追跡する
        9.2.4　チェックリストを使わないようにするために自動化する
        9.2.5　開始方法と撤退方法を文書化する
    9.3　スムーズなマイグレーションの調整
        9.3.1　計画された変更のスコープを決め、制限し、優先順位をつける
        9.3.2　コミュニケーションは公開かつ早めに
        9.3.3　最後の20% をやり遂げる
        9.3.4　命令的要求は最低限に
    9.4　プラットフォームのサービス終了
        9.4.1　いつサービス終了するかを決める
        9.4.2　サービス終了を調整する
        9.4.3　理にかなっているならサービス終了を恐れない
    9.5　まとめ

10章　ステークホルダとの関係管理
    10.1　ステークホルダマッピング：権力と関心度のマトリクス
    10.2　適切な透明性を持ったコミュニケーション
        10.2.1　詳細の共有し過ぎに注意
        10.2.2　定期的な1:1 をうまく使う
        10.2.3　期待値とコミットメントを追跡する
        10.2.4　インターロックミーティングとカスタマーアドバイザリーボードによるスケールアップ
        10.2.5　困難な時期にはコミュニケーションを増やす
    10.3　許容できる妥協点を探す
        10.3.1　ビジネスインパクトを明確にする
        10.3.2　「可能です、ただし妥協案付きで」と言うべき時もある
        10.3.3　関係性を壊さずに「無理です」という
        10.3.4　シャドープラットフォームに関する妥協
    10.4　お金の話：コストと予算管理
        10.4.1　ステップ1：今後利益を得るのが誰なのかを特定する
        10.4.2　ステップ2：作業を（人員ごとではなく）チームごとに分割する
        10.4.3　ステップ3：何を削減すべきかの提案をすると共に、何を温存するか強い意見を提示する
    10.5　まとめ

第III部　プラットフォームエンジニアリングの成功指標

11章　プラットフォームに整合性がある
    11.1　目的への整合
        11.1.1　適切な人材の組み合わせを通じた、チームの目的への整合
        11.1.2　共通の取り組みを通じた、文化の目的への整合
        11.1.3　協力し合うチームを持つことによる、文化の目的への整合
    11.2　プロダクト戦略への整合
        11.2.1　独立したプロダクトマネジメントを通じた、プラットフォーム横断的な考え方の促進
        11.2.2　独立したリードIC を通じたプラットフォーム横断アーキテクチャの促進
        11.2.3　プラットフォーム全体の顧客調査のコメントからフィードバックを見つける
        11.2.4　組織再編で不整合を賢く解決する
    11.3　計画への整合
        11.3.1　細部ではなくプロジェクト全体でのみ整合させる
        11.3.2　不整合に立ち向かう時は率直に
        11.3.3　最終的な整合性は、原則に基づいたリーダーシップから生まれる
    11.4　すべてをつなげる：組織を整合させる
    11.5　まとめ

12章　プラットフォームが信頼されている
    12.1　運用方法に対する信頼
        12.1.1　経験豊かなリーダーに権限を与えて信頼を得る
        12.1.2　機能ではなくユースケースをサポートすることで信頼の獲得を最適化する
    12.2　大きな投資に対する信頼
        12.2.1　リアーキテクチャに対する信頼を得るため、技術ステークホルダからの支持を求める
        12.2.2　新しいプロダクトへの信頼を得るため、経営陣からの援助を求める
        12.2.3　信頼を保持するために古いシステムをメンテナンスする
        12.2.4　信頼を得るには、何が「正しいか」について柔軟に考える必要がある
    12.3　デリバリを優先順位付けするための信頼
        12.3.1　デリバリの速さを重視する文化を作る
        12.3.2　チームのキャパシティを解放するためにプロジェクトの優先順位付けする
        12.3.3　プロダクトスコープに関する思い込みを考え直す
    12.4　すべてをつなげる：過結合プラットフォームの例
    12.5　まとめ

13章　プラットフォームが複雑性を管理している
    13.1　人間の協調における偶発的複雑性の管理
    13.2　シャドープラットフォームの複雑性の管理
    13.3　成長をコントロールすることによる複雑性の管理
    13.4　プロダクトディスカバリを通じた複雑性の管理
    13.5　すべてをつなげる：内部と外部の複雑性のバランスをとる
        13.5.1　OSS の運用での燃え尽き
        13.5.2　ゲームのルール変更の試み（と失敗）
        13.5.3　シャドープラットフォームによるリセットの強制
        13.5.4　リセットの実行
    13.6　まとめ

14章　プラットフォームが愛されている
    14.1　愛はうまくいくもの
    14.2　愛はハックのように見えることもある
    14.3　愛は明らかなこともある
    14.4　すべてをまとめる：愛はユーザを優秀にする
    14.5　まとめ：愛って何、ベイビー、俺を傷つけないでくれ

結び
訳者あとがき
索引

コラム目次
    プラットフォームはイノベーションを支えるか
    プラットフォームエンジニアリングを提供するなら、社内開発者ポータル（IDP）は必須のコンポーネントか
    生成AI はプラットフォームエンジニアリングにとってどんな意味を持つのか
    板挟みになる立場
    PdM を採用できない時はどうなる？
    ステークホルダマネジメントか、プロダクトマネジメントか
    全員が顧客とかかわる
    段階的デリバリとPoC
    プロダクトマーケティング
    顧客にどうしてそれが欲しいのかを教えてくれるようお願いするべきでないのはなぜか
    プロセスではなく、本質的な取り組み方を考える
    広い範囲のタイムゾーンにまたがる顧客をサポートするには
    プロジェクトマネージャを引き込むのを急がない
    プラットフォームのアンチパターン：インナーソーシングに頼る
    堅牢なプラットフォームに開拓者のアジリティを導入する
    プラットフォームのアンチパターン：リアーキテクチャを率いる新参者
    OSS やベンダシステムのへの大きな投資を評価する
    早めにマイグレーションに着手しよう
    モノレポはマイグレーションの手助けになるか
    所有権メタデータを一元的に追跡する
    サービス終了に逆らうのは、顧客ではなく構築した人たちの場合もある
    ステークホルダ管理は、不要な社内政治なのか
    ステークホルダは常に正しい
    見せかけの成功：採用率のメトリクス
    見せかけの成功：リーダーに対する信頼をプラットフォームに対する信頼だと考えてしまう
    見せかけの成功：一元的ダッシュボード
    マイグレーションの複雑性を管理する
    シャドープラットフォームの管理例
    見せかけの成功：嘘、大嘘、そして顧客満足度調査のスコア