Platform Engineeringで クラウドの「楽しくない」を解消しよう

JAWS DAYS 2025で登壇した資料です

あなたにとってのPlatformのTVPとはWikiかもしれない、の情報元
https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp

Platform Engineering KaigiのManuel Paisさんセッションアーカイブ
https://www.cnia.io/pek2024/sessions/b425872b-4a02-49ab-858a-3fffeebe866d/

deeeetさんセッションアーカイブ
https://www.cnia.io/pek2024/sessions/768e0788-00cc-4055-88d2-27e32730b035/

Transcript

1. Platform Engineeringでクラウドの 「楽しくない」を解消しよう @jacopen
2. 今日はプラットフォームエンジニアリングの 話をしにきました！ ※ 資料公開にあたって、登壇時に口頭で補足し ていた部分はこの右下枠で解説します
3. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 Platform Engineeringの定義を調べると、いろい ろ出てきます。たとえばこんなやつとか。 でも、みなさんはコレ覚える必要ないです
4. でも、みなさんは プラットフォームのことなんて 忘れちゃって良い です！
5. AWS、楽しんで使ってますか？ 今日、一番話したいこと
6. 楽しい！ JAWS DAYSという、休日にも関わらず喜んで参 加する人ばかりのイベントだったんで、多くの人が 手を上げられていました
7. 個人で気軽に使うにはいいけど 仕事として使うときは 楽しくないこともある･･･ ただ、こういうイベントにはきてないけど、辛いなー と思いながらAWS使ってる人もいるでしょう
8. どういうときに『楽しくない』のか • やりたいことができないとき • 意図した通りに動いてくれないとき • 忙しすぎて手が回らないとき • 集中したいことに集中できないとき • 翻訳されたドキュメントがよく分からないとき • でも英語読んでもよく分からないとき
9. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @CloudNative Days
10. About me • PagerDutyという、インシデントを管理する SaaSのプロダクトエバンジェリスト • 前職はHashiCorpでTerraformやVaultの プリセールスエンジニア • その前はPivotal/VMwareでPaaSプロダクトの プロフェッショナルサービス • さらにその前は通信事業者でクラウドサービスを 作るエンジニア なので、基本的にはプラットフォーム側の人間です
11. でもたまにアプリを書くことも CloudNative Days 独自イベントプラットフォーム Dreamkast 汗中成分分析サービスによる インナーケアアシスト PITTAN
12. アプリを作っていて思うこと この開発したアプリをAWSに デプロイしないといけないけど･･･ クラウドくっそめんどくさい！ こんな作業やりたくない！ ▲ 一応クラウド系のエンジニア
13. • クラウドやコンテナの知識は持ち合わせている • でも、アプリを書いているときは、頭の中は開発モード • 開発モードからクラウドエンジニアモードに頭を切り替えるのは くっそめんどくさい • クラウドエンジニアモードから開発モードに戻すのも くっそめんどくさい アプリを作っているときは 元HashiCorpですし、Terraformの本も出したりしてるんです が、そんな自分からしても開発してる途中に HCLなんて書き たくないです。 じゃあCDKでTypeScriptだと解決？いや、そういう話ではな いです。それも頭切り替え必要なの変わんないです
14. くっそめんどくさい！
15. くっそめんどくさい！
16. 僕が思う、AWSが楽しくないとき • 学習の負荷が高すぎるとき ◦ 適度な学習の負荷なら、好奇心が勝って『楽しい』 ◦ 自分のキャパ超えてくると『楽しくない』 ▪ 単純に必要スキルが自分のレベルを超えている ▪ 情報が散在している結果、『検索する』という本質的ではない作 業に追われる ▪ 気に障るブロッカー • コンテキストスイッチが多すぎるとき ◦ TypeScript⇨HCL⇨TypeScript⇨YAMLみたいな反復横跳びしんどい • 今、注力したいのは『そっちじゃない』とき ◦ アプリの開発に注力したいのに･･･! ◦ UX考えるのに時間を使いたいのに！
17. • デプロイするためのDockerfile書き、imageづくり • Manifest書き • CI/CDパイプライン作成 • 認証基盤との連携 ◦ OIDCのフローとか何回勉強しても忘れちゃうんだけど･･･ • ロギング、モニタリングの設定 • セキュリティスキャン • IaCのコード書き • etc… アプリをデプロイしたいだけなのにやるべきことが多い！ みなさんも、くっそめんどくさい 経験ありませんか？
18. くっそめんどくさい！ の表現を専門用語にすると 認知負荷
19. https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷の増大が問題に クラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、 エンジニアの責任範囲の拡大により認知負荷が大変なことに
20. くっそめんどくさい！は 気のせいではなく あちこちで発生している差し迫った課題
21. 認知負荷の増大による生産性の低下が 無視出来なくなりつつある
22. じゃあ、どうすればいいのか
23. 分業しよう！
24. 人類の発明『分業』 • 世界で初めて分業について解説したのは、 18世紀の経済学者 アダム・スミス • ピン工場の例を用いて分業の効率性を説いた ◦ 1人の職人が分業無しでピンを作ろうとすると、1日 に20本程度 ◦ 工場では、18の工程に分けられ、10人の作業者が分 担 ▪ 針金を引き延ばす ▪ 針金を真っ直ぐにする ▪ 切断する ▪ 先端を尖らせる ▪ (以下略) ◦ こうすることで、1日に48,000本生産できる ▪ 生産性240倍向上！
25. なぜ分業で効率が向上するのか • 各作業者が特定の作業に特化することで熟練度が向上する • 異なる作業間の移動時間が節約される • 各作業に特化した工具や機械の開発が促進される
26. よっしゃ、じゃあ分業だ！ Build Test Ship Run 開発 運用 そういえばIT業界は数十年前 から分業してましたね。 こんな感じで
27. よっしゃ、じゃあ分業だ！ Build Test Ship Run 開発 運用 💢 💢 でも、この分業スタイルは上手 くいかないってのは歴史が証 明しているわけです
28. あれでしょ、DevOpsってやつでしょ Build Test Ship Run 開発 運用 じゃあDevOps？思われる方 もいるでしょう。この考え方は 悪くないしこれからも重要では あるんですが
29. システム障害はどういうときに起きるか “障害のほとんどはデプロイによって引き起こされる。 したがって、デプロイが増えると障害も増え、結果と してインシデント管理、軽減策、ポストモーテムが必 要となる” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか よ り引用
30. あれでしょ、DevOpsってやつでしょ Build Test Ship Run 開発 運用 信頼性を第１ にしたい 生産性を第１ にしたい それぞれ大事にしたいポイントが違うん で、上手くいかないこともあるんですね。信 頼性上げるための改善を開発にしてほし いけど、優先順位が上がらない･･･とか。
31. You build it, you run it. Werner Vogels, VP & CTO of Amazon 我らがAmazonのVP&CTO が、かつてこういうことを言い ました
32. フルサービスオーナーシップ 「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人 が 製品開発ライフサイクル全体の責任を引き受ける 運用モデル • 本番環境において自分が書いたコードの責任を負うよう、 最もシンプルな形でエンジニアに権限を与える • 呼び方は色々ある ◦ フルサイクル・デベロッパー (Netflix) https://netflixtechblog.com/full-cycle-developers-at-netflix-a08 c31f83249
33. “コードに責任を持つ” メリット • サービス品質が上がる ◦ 開発と運用を分けず一貫して担当することで、リリース後の振る舞 いまで考慮してコードを書くようになる。だれも深夜に叩き起こさ れたくないので。 • 障害対応の迅速化 ◦ 開発者がオンコールにいれば対応のスピードが格段に上がる。 自分たちが開発したシステムを熟知しているため、原因特定や復旧 が素早く行える。
34. “コードに責任を持つ” メリット • フィードバックループの高速化 ◦ 開発者が日常的に運用に関与すると、ユーザーからの生のフィード バックや本番環境での問題点が直接開発チームに届く ◦ 「不具合→修正」のサイクルが短くなり、サービスの継続的な改善 がスピーディーに行える • 運用負荷の軽減とチーム連携の強化 ◦ 従来運用担当に集中しがちだった負荷が分散される 。特定の運用 チームだけに深夜対応などの負担がかかる状況を和らげ、組織全体 で信頼性向上に取り組む姿勢が生まれる
35. つまりこう Build Test Ship Run 開発
36. あれ、分業どこいった
37. DevとOpsという分業スタイルが、時代に合わない • そもそもDevとOpsという分け方自体が、このクラウド時代・AI時代に合っ てない • クラウドやクラウドネイティブで高度化・高速化・自動化できたら、開発 担当と運用担当で分業することのデメリットが目立つようになる
38. これからの分業スタイル
39. Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラク ションモードが定義されている。
40. 4つのチームタイプ Stream-aligned team ビジネスのストリームに沿って配置するチーム。ビ ジネスの中心 Complicated Subsystem team 複雑なサブシステムやコンポーネントを扱うチー ム。その分野のスペシャリストが集まる Enabling team 他のチームが新しい技術やスキルを身につける支援 をするチーム ★Platform team インフラやツール、共通サービスなどのプラット フォームを提供するチーム
41. 3つのインタラクションモード ファシリテーション 一方のチームが他のチームの障害を取り除くために 支援をしたり、支援されたりする。同時に複数の チームと連携することもある コラボレーション 2つのチームが密接に協力して作業する。同時にコラ ボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利用す る関係性。責任分界点が明確。疎結合。
42. Team Topologiesでは、DevとOpsに分けない Stream-aligned team 開発から運用まで、ビジネス価値に関するところ を一気通貫で担う You build it, you run itの原則を体現する ここで重要なのは、Stream-aligned Teamは DevとOpsみたいに分けてないこと。Stream に関して1チームが責任を負うスタイル。
43. 例の、くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい
44. 例の、くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい その道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering 正直Platform Engineeringの理解は、この程度でいいと思います
45. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 冒頭にも紹介したように、定義みたい なものはあります。
46. Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的 に利用できるようにするための内部向け プラットフォーム インフラ、CI/CD、監視、認証などを抽 象化し、開発チームがアプリ開発に集中 できるようにする。 インフラやサービスの自己管理を支援 し、「セルフサービス」で素早く安全に 操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれる ことも多い 自社のサービスやインフラ、ツールの 情報を一元化し、開発者が必要なリ ソースや情報に簡単にアクセスできる ようにしたもの。 ドキュメントやAPI仕様、サービスの 稼働状況をカタログ形式で表示した り、検索可能にしたりする。 Platform Engineeringについて調べると、こういう2 つのIDPに関する情報が出てきます
47. Platform Engineeringでよく出る2つのIDP 開発チームがインフラやツールを効率的 に利用できるようにするための内部向け プラットフォーム インフラ、CI/CD、監視、認証などを抽 象化し、開発チームがアプリ開発に集中 できるようにする。 インフラやサービスの自己管理を支援 し、「セルフサービス」で素早く安全に 操作できるように設計する。 Internal Developer Platform Internal Developer Portal 開発者向けのインターフェース。 Internal Developer Portalに含まれる ことも多い 自社のサービスやインフラ、ツールの 情報を一元化し、開発者が必要なリ ソースや情報に簡単にアクセスできる ようにしたもの。 ドキュメントやAPI仕様、サービスの 稼働状況をカタログ形式で表示した り、検索可能にしたりする。 気にしなくていい でも、こんなの気にしなくて良いです。
48. あーあれでしょ 共通基盤作ろうってやつでしょ 大きな会社なら必要あるかもだけど ウチはまだそういう感じじゃないかなー だってIDPの話しちゃうと、こう思っちゃう人も多いで しょう？
49. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 この定義も気にしなくていい この定義だって気にしなくて良いです。忘れちゃっ てください
50. Platform Engineeringを 成功させるコツは プラットフォームのことなんて忘れること
51. めちゃくちゃシンプルにいうと 『くっそめんどくさい』『楽しくない』 Platform Engineering 『楽しい！』 Platform Team
52. 本質は 開発者体験 開発生産性 を高める取り組み
53. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
54. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
55. 1:多で、Stream-aligned Teamを支援する 開発チーム その道のプロ Facilitating 複数のチームに対して ファシリテーションモードで関わる。 たとえばAWS勉強会やりましょうとか ナレッジベースを作るとか まだ導入されていない新技術を検証するとか テンプレート・サンプルコードを提供するとか
56. 最も小さいプラットフォームは、ただの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
57. ゴールデンパス ベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く 安全にアプリケーションを開発・運用できるようにした一連のルートや仕組みの こと • 開発者の認知負荷を減らす • セキュリティやコンプライアンスを自然と担保する • 開発チームがビジネス価値の創出に集中できるよう支援する 例えば • 新規サービス生成時に使えるテンプレート • テストやCI/CDパイプラインのセットアップスクリプト • モニタリングやログ収集などの運用機能のガイド
58. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
59. 1:1で、コラボレーションをする Platform Teamは、まずはコラボレーションか らはじめる Stream-aligned Teamと1:1になり、クラウド 回りの構築・自動化を行ったり、支援ツールを 作ったりする。 そのStream-alignedが必要とするものを理解 して作れるので、誰得なものを作り込んでしま うことを防げる 開発チーム その道のプロ Collaboration
60. 1:1で、コラボレーションをする Platform Engineering Kaigiでの、 Manuel Paisさん(Team Topologies著者)や メルカリdeeeetさんのセッションが参考 になります
61. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
62. そのうえで、プラットフォーム(XaaS)を作る コラボレーションモードだと、同時に関われ るStream-aligned Teamは限られる。 ある段階でコラボは終了し、その知見をもと により多くのチームを助けられる疎結合な形 を模索する。それがXaaSモード ここではじめて、IDPの要素がでてくる 開発チーム その道のプロ XaaS
63. そのうえで、プラットフォーム(XaaS)を作る • セキュアバイデフォルトなプラットフォーム • ワンクリックで環境調達ができるポータル • 各種ミドルウェアのオンデマンド払い出し • 統一された認証認可 • メトリクス収集・監視の標準セットアップ • などなど 開発チーム その道のプロ XaaS 大事なことは、機能を揃えるのではなく、必要とされるものを提供すること
64. どっちがいい？ プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高
65. どっちがいい？ プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高 プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪
66. どっちがいい？ プラットフォームらしいものは無いけど、開発者体験は良い ⇨ 最高 プラットフォームはあるけど、開発者体験は悪い ⇨ 最悪 追い求めるべきは、こっち
67. だからこそ Platform Engineeringを 成功させるコツは プラットフォームのことなんて忘れる 開発者体験にフォーカスする
68. Platform Teamに求められること 第一に、開発者体験を追い求めること 第二に、　　　　　　　を作ること
69. Platform Teamに求められること 第一に、開発者体験を追い求めること 第二に、　　　　　　　を作ること 信頼関係
70. だって信頼してないやつの押しつけうざいじゃん 認知負荷を下げよう！ アジリティを高めよう！ Kubernetesでプラットフォーム組んで 実現！ Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ 特に課題感は 無いんだけど？
71. だからこそ、コラボレーションからはじめる まずは信頼関係を築くことが重要。 1:1でコラボレーションをしていくと、お互いに信頼関係が生まれる お互いに何を目指していて、何に困っているか見えるようになる そうすることで、本当に必要なものを提供できるようになる だからこそ、まずはプラットフォームなんて忘れて開発者体験向上に取り組む 「役立つものを提供していたら、いつの間にかプラットフォームになっている」 くらいがいい
72. だからこそ、継続が大事 正論言って去って行くような形だと信頼されない 『続ける』ことが何より大事 XaaSやコラボレーションを繰り返して、プラット フォームを「続ける」ことで信頼も生まれ、必要 とされるものが出来ていく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
73. Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト マネージャー • プラットフォームが最も達成したい指標は何か ◦ North Star Metricsの策定 • 顧客は何にペインを感じているのか ◦ ユーザーヒアリング • 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ◦ 実装する機能の優先順位付け • 社内にその存在を知ってもらう ◦ ブランディング、社内マーケティング
74. まとめ • 一緒に「AWSは楽しい」とみんなが思える世界を作っていきましょう • そのために、Platform Engineeringの考え方が役にたつかも • プラットフォームを作るという考えに囚われず、開発者体験を高めること を大事にしよう • プラットフォームを作らなくても、Platform Engineeringです