「共通基盤」を超えよ！今、Platform Engineeringに取り組むべき理由

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

Platform Engineering推進の団体をやっています一般社団法人クラウドネイティブイノベーターズ協会 Platform Engineering Kaigi 2024 7/9開催！

Slide 4

Slide 4 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野まずはおさらいから。 Gartnerをはじめ、いくつかの団体ではこのような定義がなされています

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用認知負荷が爆上がりな昨今。マイクロサービスやクラウドネイティブ技術の発展に伴って、開発者がやらないといけないことがものすごく増えた

Slide 8

Slide 8 text

Internal Developer Platform プラットフォームチームによって構築される、開発者のセルフサービスによる利用を可能にする基盤。さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽象化することなく、開発者の認知負荷を軽減していく Kubernetes Buildkit Helm Dockerﬁle Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP Developer Platform Team self service そこで提唱されている解決方法が、内部開発者プラットフォーム。

Slide 9

Slide 9 text

ここまではいいんだけど

Slide 10

Slide 10 text

ブコメ以前別の資料を公開したときについたブコメ。実は重要なポイントを突いている

Slide 11

Slide 11 text

従来のプラットフォームは夢を見て死んでいくものだった

Slide 12

Slide 12 text

共通プラットフォームは特に新しい話では無い業種業態問わず、ある一定の規模以上の会社であれば、共通のプラットフォームを作ろうという話が一度は出ているはず。 (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいな名称のプロジェクト、関与したことある人も多いのでは

Slide 13

Slide 13 text

たとえば検索してみると GoogleでPlatform Engineering登場以前の日付を指定して「共通基盤」について検索すると、すごーくたくさん出てくる。でも、このうち生き残っているのはどれだけあるのだろう？

Slide 14

Slide 14 text

上手くいくプラットフォーム作りは、本当に難しい ● 4割の共通プラットフォームは、生まれながらに死んでいる ● 4割の共通プラットフォームは、上手く運用出来ずに死んでいく ● 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません！)

Slide 15

Slide 15 text

従来の『共通基盤』の視点コスト削減システム統合 OSS プロセス改善運用一元化ガバナンス強化中央管理プロセス整備標準化一見合理的に見えるが･･･昔の共通基盤の取り組みについて事例を見てみると、そのモチベーションはこの 2つに集約されていることが多いと気づきました。

Slide 16

Slide 16 text

もしあなたが開発者だったとして･･･コスト削減のために共通基盤を使えガバナンスのために共通基盤を使え突然こんなこと言われたらどう思いますか？

Slide 17

Slide 17 text

もしあなたが開発者だったとして･･･コスト削減のために共通基盤を使えガバナンスのために共通基盤を使えうるーせ馬鹿

Slide 18

Slide 18 text

もしあなたが開発者だったとして･･･コスト削減のために共通基盤を使えガバナンスのために共通基盤を使えうるーせ馬鹿 (渋い顔をしながら) はい、わかりましたすごくいい取り組みだと思います！ですが今回の案件は XXXがXXXでXXXX なので独自の環境で (以下長文) ぼくたちは大人なのでホンネは胸に押し込みつつ、仕方なく受け入れるか、あるいは理由を立てて断るかのどっちかになります。これじゃぁ使われないのも当然

Slide 19

Slide 19 text

第一目的がコスト削減やガバナンス強化な共通基盤を使いたがる人はいない

Slide 20

Slide 20 text

共通基盤でコストが下がるは幻想システムA システムB システムC システムD 共通基盤 A B C 共通基盤に載ってこないシステムもあるこの瞬間、一時的にコストが下がることはある

Slide 21

Slide 21 text

共通基盤でコストが下がるは幻想システムA システムB システムC システムD 共通基盤 A B C 数年後かつて共通基盤だったもの A B C E F D G 新共通基盤もはや独自基盤古い基盤にしびれを切らして乗り換え新しい技術が使いたい新規事業我が道を行く中長期で見てコストは下がったのか？

Slide 22

Slide 22 text

共通基盤だから、投資をしつづけるべき共通基盤 A B C D 最初は載らないものもある共通基盤 A B 共通基盤 C D 半年後投資 & 進化 X 年後投資 & 進化進化により載るように A C D E F B Good bye ノウハウ蓄積があるので新規事業も載りやすい事業環境の変化にも柔軟に対応コスト削減を大義名分にすると、投資ができなくなる。そして進化できずに死ぬ

Slide 23

Slide 23 text

とはいえ ● 闇雲に投資すればいいわけではない ● 闇雲に人を突っ込めばいいわけではない ● とにかく機能を詰め込めばいいわけではない従来の共通基盤の考え方と、Platform Engineeringの違いは、これを解決するアプローチに重点が置かれている点

Slide 24

Slide 24 text

Platform Engineeringとは開発者の認知負荷を軽減し生産性を向上させる共通基盤を『正しく』作り続けるための方法論

Slide 25

Slide 25 text

Platform Engineeringとは開発者の認知負荷を軽減し生産性を向上させる共通基盤を『正しく』作り続けるための方法論

Slide 26

Slide 26 text

開発者の認知負荷を軽減し生産性を向上させる共通基盤 Golden Path Internal Developer Portal Internal Developer Platform

Slide 27

Slide 27 text

Platform Engineeringとは開発者の認知負荷を軽減し生産性を向上させる共通基盤を『正しく』作り続けるための方法論

Slide 28

Slide 28 text

『正しい』とは何か ● 絶対的な正解はない。 ● 開発者の認知負荷を軽減し生産性を向上させる共通基盤 ○ これを実現するための技術、規模、チームは会社によって全く異なる ○ 同じ組織であっても、状況の変化や時間経過で正解は変わりうる ● 正解が変わり続けることを前提に考えることが重要

Slide 29

Slide 29 text

こういうのは『正しい』？ ● 開発者の認知負荷増大が課題となっている ● 開発者は運用側との調整に時間が取られ、本来の業務に注力できていない ● そこで、セルフサービスでワークロードをデプロイできる Kubernetes環境を提供する ● また、CI/CD環境を提供し、各オペレーションの自動化を実現する ● これをプラットフォームとして提供し、ビジネスのアジリティ向上に貢献する

Slide 30

Slide 30 text

『正しい』とは何か認知負荷を下げよう！アジリティを高めよう！ Kubernetesでプラットフォーム組んで実現！ Platform Team 言っていることは分かるけどそもそも取り組む余裕がないよオンプレはvSphereで、クラウドはServerlessで、特に課題感は無いんだけど？

Slide 31

Slide 31 text

『正しい』とは何か認知負荷を下げよう！アジリティを高めよう！ Kubernetesでプラットフォーム組んで実現！ Platform Team 言っていることは分かるけどそもそも取り組む余裕がないよオンプレはvSphereで、クラウドはServerlessで、特に課題感は無いんだけど？いやこれがこれからのデファクトスタンダードなんだよつかえよ

Slide 32

Slide 32 text

Slide 33

Slide 33 text

誰に何をどうやって失敗するプラットフォームはここばかり気にする

Slide 34

Slide 34 text

誰に何をどうやってプラットフォームの利用者 ○○という価値を技術ツールチェーンワークフローここにちゃんとフォーカスすることこれを継続的に回せること

Slide 35

Slide 35 text

Platform as a Product ● 開発者を『顧客』として考え、顧客にプラットフォームという『プロダクト』を提供していくというアプローチ ● 世の中に提供されているさまざまなプロダクトと同じ管理手法を、プラットフォームにも取り込んでいく顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチーム

Slide 36

Slide 36 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチームどういう価値を提供できれば使って貰えるか顧客が何に困っているかどうやってサポートしていくかどうやって教育していくかどうやって安定したチームを作るかプラットフォームによる効果がどのくらい出ているか何をいつまでに提供するか世の中のトレンドはどうなっているか

Slide 37

Slide 37 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プロダクトマネージャープロダクトマネジメントの手法がそのまま使える。チームに専任のプロダクトマネージャーを置き、プロダクトとしてのプラットフォームの方向性を決めていく

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

従来の『共通基盤』の視点コスト削減システム統合 OSS プロセス改善運用一元化ガバナンス強化中央管理プロセス整備標準化

Slide 40

Slide 40 text

Slide 41

Slide 41 text

コスト削減効果でROIを測らないコスト削減を第一の目標として共通基盤を作るのはNG いちどコスト削減したら、そのあとは「何もしない」ことが最適解となってしまい、継続的な投資を受けられなくなってしまう可能性が高い新しいものを導入する時に、ついついコスト削減効果でROIを算出しがちだが、安易な方向に流れないように注意 ● 導入する側: 内部の説得のためにコスト削減ROIを求めがち。でも、数年で使われなくなってしまい実績に繋がらない ● 提案する側: 短期間でChurnしてしまい残念な結果に

Slide 42

Slide 42 text

でも、ROIを考えるのは大事 ● ROIを測って経営層の理解を得ることはとても大事。お金はユビキタス言語 ● コスト削減では無く、どれだけ価値を生み出せたかでROIを測ろう ○ ユーザー満足度と生産性 ■ プラットフォームの利用者数(増加/減少) ■ プラットフォーム利用者のNPS(Net Promoter Score) ■ SPACEフレームワーク ○ 組織としての効率 ■ サービスのリクエストから提供までの待ち時間 ■ 新しいサービスを本番環境にデプロイするまでの時間 ■ 新規開発者が最初のコードをコミットするまでの時間 ○ DevOpsチームのパフォーマンス ■ Four Keys

Slide 43

Slide 43 text

これらの数値を金額換算参考例: Productivity [Productivity Impact] = [Engineering hour saved] * [Impact per engineering hour] Stability [Stability Impact] = [Impact per minute] * [Time to restore] Efficiency [Efficiency Impact] = [Cost saving] - [Negative Impact] Risk [Risk Impact] = [RIsk in money before] - [Risk in money after]

Slide 44

Slide 44 text

従来の『共通基盤』の視点コスト削減システム統合 OSS プロセス改善運用一元化ガバナンス強化中央管理プロセス整備標準化

Slide 45

Slide 45 text

ガバナンスも大事 ● 統制が取れていて、セキュアな環境を提供するという考え方自体は正しい ● ただ、「統制のためにここを使いなさい」という押しつけをしても、使われないガバナンスのために共通基盤を使えやだ共通基盤 ● 制限が強くやりたいことがやれない ● 利用するのにいちいち申請しないといけない ● 使ったところでセキュリティチェックシートは出さないといけない

Slide 46

Slide 46 text

ガバナンスも大事 ● セキュアバイデフォルト ● あるべきガードレールをプラットフォーム側で実現することによって、開発者側はパフォーマンスを発揮できるじゃあ使おうあるべき共通基盤 ● 開発者の業務を阻害しない形で、きちんとセキュアに保たれている ● プラットフォームチームのガードレールのもと、セルフサービスで必要な変更を行える ● ここを使うことで、面倒なチェックシートは不要になるここを使えば、簡単かつセキュア

Slide 47

Slide 47 text

今までとこれから開発者プラットフォームチーム Platform 押しつけ開発者技術の洪水 Platform Portal Tools X-as-a-Service Collaboration Facilitation 立ち向かう生産性を高める⤴

Slide 48

Slide 48 text

よろしくお願いします！ Platform Engineering Kaigi 2024 7/9開催！現在Proposal受付中！