今日からはじめるプラットフォームエンジニアリング

UV Studyで登壇した資料です

1. 今日からはじめる プラットフォームエンジニアリング
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association
3. クラウドの登場とDevOps Dev Ops Configure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるよ うにするアプローチ。 このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登 場した
4. 真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
5. 認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用
6. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野
7. Platform Team • Platform Teamが提供するゴールデンパスに沿ってもらうことで、 開発者の認知負荷を軽減し生産性を高める
8. ゴールデンパス ベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安 全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと • 開発者の認知負荷を減らす • セキュリティやコンプライアンスを自然と担保する • 開発チームがビジネス価値の創出に集中できるよう支援する 例えば • 新規サービス生成時に使えるテンプレート • テストやCI/CDパイプラインのセットアップスクリプト • モニタリングやログ収集などの運用機能のガイド
9. Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的 に利用できるようにするための内部向け プラットフォーム インフラ、CI/CD、監視、認証などを抽 象化し、開発チームがアプリ開発に集中 できるようにする。 インフラやサービスの自己管理を支援 し、「セルフサービス」で素早く安全に 操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれる ことも多い 自社のサービスやインフラ、ツールの 情報を一元化し、開発者が必要なリ ソースや情報に簡単にアクセスできる ようにしたもの。 ドキュメントやAPI仕様、サービスの 稼働状況をカタログ形式で表示した り、検索可能にしたりする。
10. じゃあ、Platform Engineeringを始めよう！
11. あーあれでしょ 共通基盤作ろうってやつでしょ 大きな会社なら必要あるかもだけど ウチはまだそういう感じじゃないかなー
12. ちょっとまって
13. Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラクショ ンモードが定義されている。
14. 3つのインタラクションモード ファシリテーション 一方のチームが他のチームの障害を取り除くために支援をしたり、支 援されたりする。同時に複数のチームと連携することもある コラボレーション 2つのチームが密接に協力して作業する。同時にコラボレーションで きるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利用する関係性。責任分 界点が明確。疎結合。
15. Team Topologiesでは、DevとOpsに分けない Stream-aligned team 開発から運用まで、ビジネス価値に関するところ を一気通貫で担う You build it, you run itの原則を体現する
16. 開発者が運用まで担うの大変じゃない？ • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい
17. 開発者が運用まで担うの大変じゃない？ • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい その道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering Platform Engineeringの理解は、この程度でいいと思います
18. Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的 に利用できるようにするための内部向け プラットフォーム インフラ、CI/CD、監視、認証などを抽 象化し、開発チームがアプリ開発に集中 できるようにする。 インフラやサービスの自己管理を支援 し、「セルフサービス」で素早く安全に 操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれる ことも多い 自社のサービスやインフラ、ツールの 情報を一元化し、開発者が必要なリ ソースや情報に簡単にアクセスできる ようにしたもの。 ドキュメントやAPI仕様、サービスの 稼働状況をカタログ形式で表示した り、検索可能にしたりする。
19. Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的 に利用できるようにするための内部向け プラットフォーム インフラ、CI/CD、監視、認証などを抽 象化し、開発チームがアプリ開発に集中 できるようにする。 インフラやサービスの自己管理を支援 し、「セルフサービス」で素早く安全に 操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれる ことも多い 自社のサービスやインフラ、ツールの 情報を一元化し、開発者が必要なリ ソースや情報に簡単にアクセスできる ようにしたもの。 ドキュメントやAPI仕様、サービスの 稼働状況をカタログ形式で表示した り、検索可能にしたりする。 気にしなくていい
20. Platform Engineeringを 成功させるコツは プラットフォームのことなんて忘れること
21. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 この定義も気にしなくていい
22. 本質は 開発者体験 開発生産性 を高める取り組み
23. まずは、ペインからはじめる 開発フローのなかでの辛いところ(ペイン)を洗い出し、言語化するところから始 める。 本当にペインが無い(実際にはあり得ないけど) のであれば、PEは不要 開発からデリバリー、運用からフィードバックまで一連のDeveloper journeyを 書きだして、改善出来るポイントを考えていく。
24. ちいさいチームでも、だいたい課題はある • CI/CDパイプライン作るのが後回しになって手作業増えてたりしない？ • .envファイルの共有で毎回DMしてない？ • 追加した環境変数がメンバーに共有されておらず、エラーが出てムキーって なったりしてない？ • レビュー環境でのエラーログ確認方法がバラバラで手間かかってない？ • などなど... → 数人規模のチームでも、こういったペインを解決していけば、開発者体験は向 上する
25. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
26. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
27. 1:多で、Stream-aligned Teamを支援する 開発チーム その道のプロ Facilitating 複数のチームに対して ファシリテーションモードで関わる。 たとえば勉強会やりましょうとか ナレッジベースを作るとか まだ導入されていない新技術を検証するとか テンプレート・サンプルコードを提供するとか
28. 最も小さいプラットフォームは、ただのWikiかも At the same time, we're not aiming to build a massive platform. We're aiming to build what we in the book call a thinnest viable platform TVP. This TVP could be just a wiki page if that's all you need for your platform. 私たちは巨大なプラットフォームの構築を目指して いるわけではありません。私たちは、書籍で「最も 薄い実行可能なプラットフォーム（TVP）」と呼ん でいるものを構築することを目指しています。 このTVPは、プラットフォームに必要なものがウィ キページだけなら、ウィキページだけで構成するこ とも可能です。 https://teamtopologies.com/key-concepts-con tent/what-is-a-thinnest-viable-platform-tvp
29. ゴールデンパス ベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安 全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと • 開発者の認知負荷を減らす • セキュリティやコンプライアンスを自然と担保する • 開発チームがビジネス価値の創出に集中できるよう支援する 例えば • 新規サービス生成時に使えるテンプレート • テストやCI/CDパイプラインのセットアップスクリプト • モニタリングやログ収集などの運用機能のガイド
30. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
31. 1:1で、コラボレーションをする Platform Teamは、まずはコラボレーションか らはじめる Stream-aligned Teamと1:1になり、クラウド 回りの構築・自動化を行ったり、支援ツールを 作ったりする。 そのStream-alignedが必要とするものを理解し て作れるので、誰得なものを作り込んでしまう ことを防げる 開発チーム その道のプロ Collaboration
32. 1:1で、コラボレーションをする Platform Engineering Kaigiでの、 Manuel Paisさん(Team Topologies著者)や メルカリdeeeetさんのセッションが参考に なります
33. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
34. そのうえで、プラットフォーム(XaaS)を作る コラボレーションモードだと、同時に関われ るStream-aligned Teamは限られる。 ある段階でコラボは終了し、その知見をもと により多くのチームを助けられる疎結合な形 を模索する。それがXaaSモード ここではじめて、IDPの要素がでてくる 開発チーム その道のプロ XaaS
35. そのうえで、プラットフォーム(XaaS)を作る • セキュアバイデフォルトなプラットフォーム • ワンクリックで環境調達ができるポータル • 各種ミドルウェアのオンデマンド払い出し • 統一された認証認可 • メトリクス収集・監視の標準セットアップ • などなど 開発チーム その道のプロ XaaS 大事なことは、機能を揃えるのではなく、必要とされるものを提供すること
36. どっちがいい？ プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高
37. どっちがいい？ プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高 プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪
38. どっちがいい？ プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高 プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪 追い求めるべきは、こっち
39. だからこそ Platform Engineeringを 成功させるコツは プラットフォームのことなんて忘れる 開発者体験にフォーカスする
40. Platform Teamに求められること 第一に、開発者体験を追い求めること 第二に、　　　　　　　を作ること
41. Platform Teamに求められること 第一に、開発者体験を追い求めること 第二に、　信頼関係　　を作ること
42. だって信頼してないやつの押しつけうざいじゃん 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ 特に課題感は 無いんだけど？
43. だからこそ、コラボレーションからはじめる まずは信頼関係を築くことが重要。 1:1でコラボレーションをしていくと、お互いに信頼関係が生まれる お互いに何を目指していて、何に困っているか見えるようになる そうすることで、本当に必要なものを提供できるようになる だからこそ、まずはプラットフォームなんて忘れて開発者体験向上に取り組む 「役立つものを提供していたら、いつの間にかプラットフォームになっている」 くらい がいい
44. だからこそ、継続が大事 正論言って去って行くような形だと信頼されない 『続ける』ことが何より大事 XaaSやコラボレーションを繰り返して、プラット フォームを「続ける」ことで信頼も生まれ、必要とさ れるものが出来ていく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
45. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー • プラットフォームが最も達成したい指標は何か ◦ North Star Metricsの策定 • 顧客は何にペインを感じているのか ◦ ユーザーヒアリング • 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ◦ 実装する機能の優先順位付け • 社内にその存在を知ってもらう ◦ ブランディング、社内マーケティング
46. まとめ • Platform Engineeringは、開発者体験を向上させアウトプットを向上させる 取り組み • その手段のひとつとして、内部開発者プラットフォーム(IDP)の作成がある が、最初の段階では全く気にしなくて良い • 開発フローを振り返ると、何らしかペインがあるのでそれを解決するところ から始めよう。最初はWiki, Notion, Confluenceの1ページでいい • 拡大していくにあたっては、Team Topologiesが大変役立つ • 信頼がなによりも大事
47. よろしくお願いします！ Platform Engineering Kaigi 2025 9/18開催！