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

OpenShift.Runで登壇した資料です。

1. 「共通基盤」を超えよ！ 今、Platform Engineeringに 取り組むべき理由
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association この四角枠は資料公開にあたって、登壇 中に喋った内容に近くするために補足で 追加したモノです
3. Platform Engineering推進の団体をやっています 一般社団法人 クラウドネイティブイノベーターズ協会 Platform Engineering Kaigi 2024 7/9開催！
4. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 まずはおさらいから。 Gartnerをはじめ、いくつかの団体では このような定義がなされています
5. クラウドの登場とDevOps Dev Ops Configure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるよ うにするアプローチ。 このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登 場した
6. 真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
7. 認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷が爆上がりな昨今。マイクロ サービスやクラウドネイティブ技術の発 展に伴って、開発者がやらないといけな いことがものすごく増えた
8. Internal Developer Platform プラットフォームチームによって構築される、開発者のセルフサービスによる利 用を可能にする基盤。 さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽 象化することなく、開発者の認知負荷を軽減していく Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP Developer Platform Team self service そこで提唱されている解決方法が、内 部開発者プラットフォーム。
9. ここまではいいんだけど
10. ブコメ 以前別の資料を公開したときについたブ コメ。実は重要なポイントを突いている
11. 従来のプラットフォームは 夢を見て死んでいくものだった
12. 共通プラットフォームは特に新しい話では無い 業種業態問わず、ある一定の規模以上の会社であれば、 共通のプラットフォームを作ろうという話が一度は出ているはず。 (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいな名称のプロジェクト、関与したことある人も多いのでは
13. たとえば検索してみると GoogleでPlatform Engineering登場 以前の日付を指定して「共通基盤」 について検索すると、すごーくたく さん出てくる。でも、このうち生き 残っているのはどれだけあるのだろ う？
14. 上手くいくプラットフォーム作りは、本当に難しい • 4割の共通プラットフォームは、生まれながらに死んでいる • 4割の共通プラットフォームは、上手く運用出来ずに死んでいく • 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません！)
15. 従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備 標準化 一見合理的に見えるが･･･ 昔の共通基盤の取り組みについて事例を 見てみると、そのモチベーションはこの 2つに集約されていることが多いと気づ きました。
16. もしあなたが開発者だったとして･･･ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え 突然こんなこと言われたら どう思いますか？
17. もしあなたが開発者だったとして･･･ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え うるーせ馬鹿
18. もしあなたが開発者だったとして･･･ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え うるーせ馬鹿 (渋い顔をしながら) はい、わかりました すごくいい取り組み だと思います！ ですが今回の案件は XXXがXXXでXXXX なので独自の環境で (以下長文) ぼくたちは大人なのでホンネは胸に押し 込みつつ、仕方なく受け入れるか、ある いは理由を立てて断るかのどっちかにな ります。これじゃぁ使われないのも当然
19. 第一目的がコスト削減やガバナンス強化 な共通基盤を使いたがる人はいない
20. 共通基盤でコストが下がるは幻想 システムA システムB システムC システムD 共通基盤 A B C 共通基盤に載ってこ ないシステムもある この瞬間、一時的に コストが下がること はある
21. 共通基盤でコストが下がるは幻想 システムA システムB システムC システムD 共通基盤 A B C 数 年 後 かつて共通基盤 だったもの A B C E F D G 新共通基盤 もはや 独自基盤 古い基盤に しびれを切 らして乗り 換え 新しい技術 が使いたい 新規事業 我が道を行く 中長期で見てコストは下がったのか？
22. 共通基盤だから、投資をしつづけるべき 共通基盤 A B C D 最初は載らない ものもある 共通基盤 A B 共通基盤 C D 半 年 後 投資 & 進化 X 年 後 投資 & 進化 進化により 載るように A C D E F B Good bye ノウハウ蓄積が あるので新規事 業も載りやすい 事業環境の変化 にも柔軟に対応 コスト削減を大義名分にする と、投資ができなくなる。 そして進化できずに死ぬ
23. とはいえ • 闇雲に投資すればいいわけではない • 闇雲に人を突っ込めばいいわけではない • とにかく機能を詰め込めばいいわけではない 従来の共通基盤の考え方と、Platform Engineeringの違い は、これを解決するアプローチに重点が置かれている点
24. Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
25. Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
26. 開発者の認知負荷を軽減し生産性を向上させる共通基盤 Golden Path Internal Developer Portal Internal Developer Platform
27. Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
28. 『正しい』とは何か • 絶対的な正解はない。 • 開発者の認知負荷を軽減し生産性を向上させる共通基盤 ◦ これを実現するための技術、規模、チームは 会社によって全く異なる ◦ 同じ組織であっても、状況の変化や時間経過で 正解は変わりうる • 正解が変わり続けることを前提に考えることが重要
29. こういうのは『正しい』？ • 開発者の認知負荷増大が課題となっている • 開発者は運用側との調整に時間が取られ、本来の業務に 注力できていない • そこで、セルフサービスでワークロードをデプロイできる Kubernetes環境を提供する • また、CI/CD環境を提供し、各オペレーションの 自動化を実現する • これをプラットフォームとして提供し、 ビジネスのアジリティ向上に貢献する
30. 『正しい』とは何か 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、 クラウドはServerlessで、 特に課題感は無いんだけど？
31. 『正しい』とは何か 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、 クラウドはServerlessで、 特に課題感は無いんだけど？ いやこれがこれからの デファクトスタンダードなんだよ つかえよ
32. 『正しい』とは何か 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、 クラウドはServerlessで、 特に課題感は無いんだけど？ いやこれがこれからの デファクトスタンダードなんだよ つかえよ 使われるわけがない
33. 誰に 何を どうやって 失敗するプラットフォームは ここばかり気にする
34. 誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー ここにちゃんとフォーカスすること これを継続的に回せること
35. Platform as a Product • 開発者を『顧客』として考え、顧客にプラット フォームという『プロダクト』を提供していく というアプローチ • 世の中に提供されているさまざまなプロダクト と同じ管理手法を、プラットフォームにも取り 込んでいく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
36. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム どういう価値を提供できれば 使って貰えるか 顧客が何に困っているか どうやってサポートしていく か どうやって教育していくか どうやって安定したチームを 作るか プラットフォームによる効果 がどのくらい出ているか 何をいつまでに提供するか 世の中のトレンドはどうなっ ているか
37. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー プロダクトマネジメントの 手法がそのまま使える。 チームに専任のプロダクトマ ネージャーを置き、プロダク トとしてのプラットフォーム の方向性を決めていく
38. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー • プラットフォームが最も達成したい指標は何か ◦ North Star Metricsの策定 • 顧客は何にペインを感じているのか ◦ ユーザーヒアリング • 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ◦ 実装する機能の優先順位付け • 社内にその存在を知ってもらう ◦ ブランディング、社内マーケティング
39. 従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備 標準化
40. 共通基盤だから、投資をしつづけるべき 共通基盤 A B C D 最初は載らない ものもある 共通基盤 A B 共通基盤 C D 半 年 後 投資 & 進化 X 年 後 投資 & 進化 進化により 載るように A C D E F B Good bye ノウハウ蓄積が あるので新規事 業も載りやすい 事業環境の変化 にも柔軟に対応 コスト削減を大義名分にする と、投資ができなくなる。 そして進化できずに死ぬ
41. コスト削減効果でROIを測らない コスト削減を第一の目標として共通基盤を作るのはNG いちどコスト削減したら、そのあとは「何もしない」ことが最適解となってしまい、継続的 な投資を受けられなくなってしまう可能性が高い 新しいものを導入する時に、ついついコスト削減効果でROIを算出しがちだが、安易な方向 に流れないように注意 • 導入する側: 内部の説得のためにコスト削減ROIを求めがち。でも、数年で使われなく なってしまい実績に繋がらない • 提案する側: 短期間でChurnしてしまい残念な結果に
42. でも、ROIを考えるのは大事 • ROIを測って経営層の理解を得ることはとても大事。お金はユビキタス言語 • コスト削減では無く、どれだけ価値を生み出せたかでROIを測ろう ◦ ユーザー満足度と生産性 ▪ プラットフォームの利用者数(増加/減少) ▪ プラットフォーム利用者のNPS(Net Promoter Score) ▪ SPACEフレームワーク ◦ 組織としての効率 ▪ サービスのリクエストから提供までの待ち時間 ▪ 新しいサービスを本番環境にデプロイするまでの時間 ▪ 新規開発者が最初のコードをコミットするまでの時間 ◦ DevOpsチームのパフォーマンス ▪ Four Keys
43. これらの数値を金額換算 参考例: 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]
44. 従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備 標準化
45. ガバナンスも大事 • 統制が取れていて、セキュアな環境を提供するという考え方自体は正しい • ただ、「統制のためにここを使いなさい」という押しつけをしても、使われない ガバナンスのために 共通基盤を使え やだ 共通基盤 • 制限が強くやりたいことがやれない • 利用するのにいちいち申請しないといけない • 使ったところでセキュリティチェックシートは 出さないといけない
46. ガバナンスも大事 • セキュアバイデフォルト • あるべきガードレールをプラットフォーム側で実現することによって、 開発者側はパフォーマンスを発揮できる じゃあ使 おう あるべき共通基盤 • 開発者の業務を阻害しない形で、 きちんとセキュアに保たれている • プラットフォームチームのガードレールのも と、セルフサービスで必要な変更を行える • ここを使うことで、面倒なチェックシートは 不要になる ここを使えば、 簡単かつセキュア
47. 今までとこれから 開発者 プラットフォームチーム Platform 押しつけ 開発者 技術の洪水 Platform Portal Tools X-as-a-Service Collaboration Facilitation 立ち向かう 生産性を高める⤴
48. よろしくお願いします！ Platform Engineering Kaigi 2024 7/9開催！ 現在Proposal受付中！