book

プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン

Name: プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン
ISBN: 9784814401413

by Camille Fournier, Ian Nowland, 松浦隼人

November 2025

Beginner to intermediate

346 pages

5h 2m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　表紙
　大扉
　原書大扉
　クレジット
　本書への賛辞
　まえがき
　はじめに
第Ⅰ部　プラットフォームエンジニアリングとは何であり、なぜプラットフォームエンジニアリングなのか
　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　メタデータレジストリとの統合　　　プラットフォームエンジニアリングを提供するなら、社内開発者ポータル（IDP）は必須のコンポーネントか　　2.3　幅広いアプリケーション開発者を手助けする　　2.4　基盤としての運用　　　2.4.1　プラットフォーム全体の責任を持つ　　　2.4.2　プラットフォームのサポート　　　2.4.3　運用の規律　　　生成AIはプラットフォームエンジニアリングにとってどんな意味を持つのか　　2.5　まとめ

第Ⅱ部　プラットフォームエンジニアリングの実践
　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）　　　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　可能性のあるプラットフォーム製品を特定する　　　段階的デリバリとPoC　　　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：リアーキテクチャの最終ゴールを大きく考える　　　OSSやベンダシステムのへの大きな投資を評価する　　　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　まとめ
第Ⅲ部　プラットフォームエンジニアリングの成功指標
　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章　プラットフォームが愛されている
　　　見せかけの成功：嘘、大嘘、そして顧客満足度調査のスコア*2　　14.1　愛はうまくいくもの　　14.2　愛はハックのように見えることもある　　14.3　愛は明らかなこともある　　14.4　すべてをまとめる：愛はユーザを優秀にする　　14.5　まとめ：愛って何、ベイビー、俺を傷つけないでくれ*4
　結び
　訳者あとがき
　著者紹介
　奥付

404

Not Found

Either this content does not exist or you do not have access to it. Try searching for something new.

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン

by Camille Fournier, Ian Nowland, 松浦隼人

404

Not Found