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

by Kazuto Kusama

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association

Slide 3

Slide 3 text

クラウドの登場とDevOps Dev Ops Conﬁgure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるようにするアプローチ。このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登場した

Slide 4

Slide 4 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行するただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerﬁle Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が高すぎるこれをやり切れる人材は少ない

Slide 5

Slide 5 text

認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用

Slide 6

Slide 6 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野

Slide 7

Slide 7 text

Platform Team ● Platform Teamが提供するゴールデンパスに沿ってもらうことで、開発者の認知負荷を軽減し生産性を高める

Slide 8

Slide 8 text

ゴールデンパスベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと ● 開発者の認知負荷を減らす ● セキュリティやコンプライアンスを自然と担保する ● 開発チームがビジネス価値の創出に集中できるよう支援する例えば ● 新規サービス生成時に使えるテンプレート ● テストやCI/CDパイプラインのセットアップスクリプト ● モニタリングやログ収集などの運用機能のガイド

Slide 9

Slide 9 text

Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的に利用できるようにするための内部向けプラットフォームインフラ、CI/CD、監視、認証などを抽象化し、開発チームがアプリ開発に集中できるようにする。インフラやサービスの自己管理を支援し、「セルフサービス」で素早く安全に操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれることも多い自社のサービスやインフラ、ツールの情報を一元化し、開発者が必要なリソースや情報に簡単にアクセスできるようにしたもの。ドキュメントやAPI仕様、サービスの稼働状況をカタログ形式で表示したり、検索可能にしたりする。

Slide 10

Slide 10 text

じゃあ、Platform Engineeringを始めよう！

Slide 11

Slide 11 text

あーあれでしょ共通基盤作ろうってやつでしょ大きな会社なら必要あるかもだけどウチはまだそういう感じじゃないかなー

Slide 12

Slide 12 text

ちょっとまって

Slide 13

Slide 13 text

Team Topologies 価値のあるソフトウェアを素早く届けられるようにするための組織設計。 4タイプのチーム定義と、3つのインタラクションモードが定義されている。

Slide 14

Slide 14 text

3つのインタラクションモードファシリテーション一方のチームが他のチームの障害を取り除くために支援をしたり、支援されたりする。同時に複数のチームと連携することもあるコラボレーション 2つのチームが密接に協力して作業する。同時にコラボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利用する関係性。責任分界点が明確。疎結合。

Slide 15

Slide 15 text

Team Topologiesでは、DevとOpsに分けない Stream-aligned team 開発から運用まで、ビジネス価値に関するところを一気通貫で担う You build it, you run itの原則を体現する

Slide 16

Slide 16 text

開発者が運用まで担うの大変じゃない？ ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたい

Slide 17

Slide 17 text

開発者が運用まで担うの大変じゃない？ ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたいその道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering Platform Engineeringの理解は、この程度でいいと思います

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Platform Engineeringを成功させるコツはプラットフォームのことなんて忘れること

Slide 21

Slide 21 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野この定義も気にしなくていい

Slide 22

Slide 22 text

本質は開発者体験開発生産性を高める取り組み

Slide 23

Slide 23 text

まずは、ペインからはじめる開発フローのなかでの辛いところ(ペイン)を洗い出し、言語化するところから始める。本当にペインが無い(実際にはあり得ないけど) のであれば、PEは不要開発からデリバリー、運用からフィードバックまで一連のDeveloper journeyを書きだして、改善出来るポイントを考えていく。

Slide 24

Slide 24 text

ちいさいチームでも、だいたい課題はある ● CI/CDパイプライン作るのが後回しになって手作業増えてたりしない？ ● .envファイルの共有で毎回DMしてない？ ● 追加した環境変数がメンバーに共有されておらず、エラーが出てムキーってなったりしてない？ ● レビュー環境でのエラーログ確認方法がバラバラで手間かかってない？ ● などなど... → 数人規模のチームでも、こういったペインを解決していけば、開発者体験は向上する

Slide 25

Slide 25 text

Team Topologiesから考える、チームの関わり方開発チームその道のプロ開発チームその道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を開いたり、Slackで情報提供その道のプロが開発チームにジョインし Manifest書くのを担う開発チームその道のプロ XaaS その道のプロが用意したプラットフォームのレールの上で開発

Slide 26

Slide 26 text

Slide 27

Slide 27 text

1:多で、Stream-aligned Teamを支援する開発チームその道のプロ Facilitating 複数のチームに対してファシリテーションモードで関わる。たとえば勉強会やりましょうとかナレッジベースを作るとかまだ導入されていない新技術を検証するとかテンプレート・サンプルコードを提供するとか

Slide 28

Slide 28 text

最も小さいプラットフォームは、ただの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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

1:1で、コラボレーションをする Platform Teamは、まずはコラボレーションからはじめる Stream-aligned Teamと1:1になり、クラウド回りの構築・自動化を行ったり、支援ツールを作ったりする。そのStream-alignedが必要とするものを理解して作れるので、誰得なものを作り込んでしまうことを防げる開発チームその道のプロ Collaboration

Slide 32

Slide 32 text

1:1で、コラボレーションをする Platform Engineering Kaigiでの、 Manuel Paisさん(Team Topologies著者)やメルカリdeeeetさんのセッションが参考になります

Slide 33

Slide 33 text

Slide 34

Slide 34 text

そのうえで、プラットフォーム(XaaS)を作るコラボレーションモードだと、同時に関われるStream-aligned Teamは限られる。ある段階でコラボは終了し、その知見をもとにより多くのチームを助けられる疎結合な形を模索する。それがXaaSモードここではじめて、IDPの要素がでてくる開発チームその道のプロ XaaS

Slide 35

Slide 35 text

そのうえで、プラットフォーム(XaaS)を作る ● セキュアバイデフォルトなプラットフォーム ● ワンクリックで環境調達ができるポータル ● 各種ミドルウェアのオンデマンド払い出し ● 統一された認証認可 ● メトリクス収集・監視の標準セットアップ ● などなど開発チームその道のプロ XaaS 大事なことは、機能を揃えるのではなく、必要とされるものを提供すること

Slide 36

Slide 36 text

どっちがいい？プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高

Slide 37

Slide 37 text

どっちがいい？プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪

Slide 38

Slide 38 text

どっちがいい？プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪追い求めるべきは、こっち

Slide 39

Slide 39 text

だからこそ Platform Engineeringを成功させるコツはプラットフォームのことなんて忘れる開発者体験にフォーカスする

Slide 40

Slide 40 text

Platform Teamに求められること第一に、開発者体験を追い求めること第二に、　　　　　　　を作ること

Slide 41

Slide 41 text

Platform Teamに求められること第一に、開発者体験を追い求めること第二に、　信頼関係　　を作ること

Slide 42

Slide 42 text

だって信頼してないやつの押しつけうざいじゃん認知負荷を下げよう！アジリティを高めよう！ Kubernetesでプラットフォーム組んで実現！ Platform Team 言っていることは分かるけどそもそも取り組む余裕がないよ特に課題感は無いんだけど？

Slide 43

Slide 43 text

だからこそ、コラボレーションからはじめるまずは信頼関係を築くことが重要。 1:1でコラボレーションをしていくと、お互いに信頼関係が生まれるお互いに何を目指していて、何に困っているか見えるようになるそうすることで、本当に必要なものを提供できるようになるだからこそ、まずはプラットフォームなんて忘れて開発者体験向上に取り組む「役立つものを提供していたら、いつの間にかプラットフォームになっている」くらいがいい

Slide 44

Slide 44 text

だからこそ、継続が大事正論言って去って行くような形だと信頼されない『続ける』ことが何より大事 XaaSやコラボレーションを繰り返して、プラットフォームを「続ける」ことで信頼も生まれ、必要とされるものが出来ていく顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチーム

Slide 45

Slide 45 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プロダクトマネージャー ● プラットフォームが最も達成したい指標は何か ○ North Star Metricsの策定 ● 顧客は何にペインを感じているのか ○ ユーザーヒアリング ● 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ○ 実装する機能の優先順位付け ● 社内にその存在を知ってもらう ○ ブランディング、社内マーケティング

Slide 46

Slide 46 text

まとめ ● Platform Engineeringは、開発者体験を向上させアウトプットを向上させる取り組み ● その手段のひとつとして、内部開発者プラットフォーム(IDP)の作成があるが、最初の段階では全く気にしなくて良い ● 開発フローを振り返ると、何らしかペインがあるのでそれを解決するところから始めよう。最初はWiki, Notion, Conﬂuenceの1ページでいい ● 拡大していくにあたっては、Team Topologiesが大変役立つ ● 信頼がなによりも大事

Slide 47

Slide 47 text

よろしくお願いします！ Platform Engineering Kaigi 2025 9/18開催！