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

Platform Engineering Meetup #15
https://platformengineering.connpass.com/event/375153/

Transcript

1. プラットフォームエンジニアリングとは何であり、なぜプ ラットフォームエンジニアリングなのか Platform Engineering Meetup #15
2. 自己紹介 松浦隼人 • X : dblmkt • 本業 : オーティファイ株式会社 • 趣味(副業) : 翻訳
3. 著者 : Camille Fournier 　　 Ian Nowland 出版 : オライリー・ジャパン 発売日 : 2025/11/29 ページ : 346 価格 : 4,400円 原著 : Platform Engineering O’Reilly / 2024年10月
4. 第I部　プラットフォームエンジニアリングとは何であり、 なぜプラットフォームエンジニアリングなのか 1章　プラットフォームエンジニアリングが 　　 重要になりつつある理由 2章　プラットフォームエンジニアリングの柱 第II部　プラットフォームエンジニアリングの実践 3章　どのように、そしていつ始めるか 4章　素晴らしいプラットフォームチームを作る 5章　プロダクトとしてのプラットフォーム 6章　プラットフォームの運用 7章　計画とデリバリ 8章　プラットフォームのリアーキテクチャ 9章　プラットフォームのマイグレーションと 　　 廃止 10章　ステークホルダとの関係管理 第III部　プラットフォームエンジニアリングの成功指標 11章　プラットフォームに整合性がある 12章　プラットフォームが信頼されている 13章　プラットフォームが複雑性を管理している 14章　プラットフォームが愛されている
5. ✖ Kubernetesその他ツールの使い方 ✖ コード ✖ 設定例 ✖ 使えるアーキテクチャ例 ⭕ いつどのように始めるか ⭕ 理想的なプラットフォームチームの 　 構成・失敗例 ⭕ プロダクトとしてプラットフォームを 　 作る考え方 ⭕ プラットフォームの計画・デリバリ・ 　 運用・マイグレーション・廃止 ⭕ ステークホルダーとの 　 コミュニケーション ⭕ 成功指標
6. プラットフォームエンジニアリングとは 何か
7. プラットフォームエンジニアリングとは • プラットフォーム を開発・運用する技術分野 ◦ プラットフォームとは ▪ 自己完結型のAPI、ツール、サービス、知識、サポートを社内プロダクトとして 構成した基盤 ◦ アプリケーションチームが手間をかけずに早いペースで製品を作れるようにする仕組み • ビジネスにおけるレバレッジ を実現する • システム全体の複雑さを管理 する • プラットフォームをプロダクト として扱う
8. プラットフォームエンジニアリングとは • ビジネスにおけるレバレッジを実現する ◦ 少数のプラットフォームエンジニアの仕事によって、組織全体の業務を削減できる ▪ 生産性の向上と、重複作業を減らす • システム全体の複雑さを管理する ◦ プラットフォーム内に複雑さを閉じ込める = 複雑さを管理する • プラットフォームをプロダクトとして扱う ◦ ツールを提供するだけでなく、ユーザを中心に考える ◦ その上で、必要な機能・あえて作らない機能を選別して、洗練されたものを作る
9. なぜプラットフォームエンジニアリングが必要 なのか
10. プラットフォームがないと起こる問題 • 選択肢の爆発的増加 • グルーの蔓延 • 保守コストの増大 • 運用負荷の増加
11. 選択肢の爆発的増加
12. グルーの蔓延→保守コスト増大・運用負荷増加
13. プラットフォームによる解決 • 基本的機能の選択肢を制限 • グルーの量を制限 • マイグレーションコストの集約 • 運用の簡素化
14. プラットフォームによる解決 アプリチームのタ スクの移譲・集約
15. プラットフォームをプラットフォーム たらしめる4つの柱
16. プロダクトとして扱う • 厳選されたプロダクトアプローチ ◦ プロダクト アプローチ＝ユーザを中心に、必要な機能・体験を提供する ◦ 厳選された アプローチ＝プラットフォームの対象を明確にして、提供内容を厳選する • 舗装道路型 ◦ 既存システムとのギャップを埋めて多くのユーザをカバーできるようにする ◦ どちらかというとユーザの自由度に重き • 線路型 ◦ 既存システムにはカバーされていない部分を埋める ◦ どちらかというと型にはめる
17. ソフトウェアベースの抽象化 • (OSSなど裏で動く仕組みの )複雑さを管理するには、ソフトウェアが必要 ◦ 開発者が必要になる • 注意点 ◦ カプセル化と APIの提供 ◦ シッククライアント ←→シンクライアント ◦ OSSのカスタマイズ ◦ メタデータの扱い
18. 幅広いアプリケーション開発者向けの基盤 • 個別最適ではなく、様々な開発者・チームをカバーできる必要 ◦ セルフサービスな仕組み ◦ ユーザから見たオブザーバビリティ ◦ ガードレール ◦ マルチテナンシー
19. 運用の規律を持つ • プラットフォームチームがプラットフォーム全体の責任を持つ ◦ OSSなど自分が制御できない仕組みに依存しすぎると、責任を取れない
20. Kubernetes入れたら プラットフォームエンジニアリング ではない
21. 開発者ポータル(IDP)作ったら プラットフォームエンジニアリング ではない
22. ツールやプロセスを導入することを プラットフォームエンジニアリングと いうなかれ
23. プラットフォームエンジニアリングとは、 Site Reliability EngineeringやDevOpsのように、 マインドセットあるいはパラダイム