Tweet
Tweet

Slide 1

Slide 1 text

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

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

Slide 6

Slide 6 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile 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 Dockerfile 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

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

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

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

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受付中！