PEK2024 Recap

Platform Engineering Kaigi 2024を振り返る資料です

Transcript

1. 運用マニュアル Notion 配信マニュアル Platform Engineering Kaigi 2024 Recap 2024/08/19 Platform Engineering Meetup Online #3 - PEK Recap!
2. PEK2024、無事開催できました 

3. 全セッション、動画切り抜きをしました！ 🎉
 本日より、PEK2024のセッションページから視聴可能です

4. Keynote 

7. プラットフォームの課題 
 • 社内プラットフォームは新しい概念ではないが、強制的に与えられる プラットフォームは他のチームに負担をかける 
 ◦ チケットベースの作業と待ち時間 
 ◦ サービス間の統合の欠如 
 ◦ 異なるインターフェースやAPIによる認知負荷の増加 
 ◦ パフォーマンスの問題 
 • 「Accelerate」という本の研究によると、高性能なチームには以下の 特徴がある
 ◦ リードタイムが短い 
 ◦ デプロイ頻度が高い 
 ◦ 平均復旧時間が短い 
 ◦ 変更失敗率が低い 
 プラットフォームは、プロダクトチームがこういったメトリクスを達成できるよ うに助けてくれるものでなければいけない。 

8. Teamperature 
 Teamperatureというツールを作った 
 • 認知負荷を押し上げている要素は何なのか 
 • 何が認知負荷を上げているのか 
 • チームとしてどのように改善できるのか 
 ということを検討できるツール 

9. Platform as a Productとは 
 Evan Bottcherの定義 
 「魅力的な内製品としてまとめられたセルフサービスAPI、ツー ル、サービス、知識、およびサポートの基盤」 
 重要な要素
 • セルフサービス
 • 知識とサポート
 • 魅力的な社内プロダクト 
 プラットフォームというのは、社内のユーザーに提供するもので あってもプロダクトとして見なすもの。社内のお客様に提供するも の。それがなぜ重要なのか 

10. プラットフォームの設計原則 
 「負担の少ない道を作る。 
 正しいことを最も簡単に行えるものにする」 
 = Golden Path
 インフラであろうが、監視であろうが、データサービスであろうが。8割 方はゴールデンパスを通ることができる。 
 もちろんプラットフォームでは実現出来ない特殊な問題は存在し、そ れは起こることとして受け入れるべき。 
 Thinnest Viable Platform 
 プラットフォームはできるだけ厳選された相互補完的なサービスやパ ターンでなっているもの。そしてデリバリーをより一緒に使うことで簡素 化し加速化するものであるべき。 

11. Thinnest Viable Platformの例 
 例えばスタートアップ企業で仕事していても 
 • Wikiページがあって、「AWSやGoogleクラウドをこのように使う」 「このサービスを使っていける」「これがデフォルトの設定で、セ キュリティも担保されている」などと纏まっている 
 • このWikiページ1つだけで、新しいチームやエンジニアもすぐに 仕事に取りかかることができる。より早く会社に価値をデリバ リーできるようになる。 それはプラットフォームですよね 。
 • 何もテクノロジーを構築したり、サービスやツールを作っていな いが、このWikiページもプラットフォーム。 
 • 時間が経つとプラットフォームがどんどん成長して、サービスや 価値をさらに提供するようになる。 でも本当に価値のあるもの だけにとどめるというのが重要 

12. チームの進化 
 いきなり大きい物を作らない、は大事。では、どのくらいの大きさがちょうどいいの か？
 • 社内のチームとやり取りをしながら、ベストなサイズを見つけていく 
 • 健全かつ持続可能な社内プラットフォームは、チームのインタラクションで 進化していくもの
 • 他のチームとやり取りをしながら正しい方向に進んでいるのか、チームの 役に立っているのかを試行錯誤しながら考える 
 DevOpsの定義 (by Patrick Debois)
 「DevOpsとはサイロ間の摩擦を克服するための全てのこと。残りは全て単純なエ ンジニアリング」
 どのようにサイロを避けるのか
 • チームに独立性を持たせたい
 ◦ でも常に独立ばかりではなく、チーム間の相互作用、インタラクションも必要 
 • このチームはプラットフォームから何を必要としているのか、こちらのチーム はどうなのかというやり取りが必要。
 • 往々にしてチームのインタラクションが少ないと、プラットフォームが健全に 成長、進化しない

13. チームの進化 
 Team Topologiesでは定義された明確なインタラクションをチーム間で 持つ
 • コラボレーション
 ◦ 新しいプラットフォームに機能や改善をする場合、プラットフォームチーム だけでなく、利用しているチームと一緒にコラボレーションしていく 
 • X-as-a-Service
 ◦ 信頼性やドキュメントを改善 
 ◦ サポートの提供 
 ◦ プラットフォームがより成熟するにつれて必要なものも増えていく 
 • 簡単に理解できて、プラットフォームチームが何の関与もせずと もプロダクトチームが簡単使ってくれるプラットフォームにする のが理想。
 ◦ AWSやGoogleクラウドを使っていても、GoogleのエンジニアやAWSのエン ジニアと直接話しながら使えない。 
 ◦ 通信事業者だったら、アクセス回線などを提供していても、その会社のエ ンジニアと話さない 
 ◦ なぜかというと、サービスはもうエンジニアと話さなくても理解できて、しっ かりとドキュメントも揃っているから 

14. インタラクションモードの変更 
 • まずはコラボレーションから始める 
 • サービスが安定し、ほとんどのチームがこのサービスを必要と なると、X-as-a-Serviceとなっていく 
 • どこかの時点でコラボレーションに戻る必要がある。新しいリク エストがあったり、新しいこのサービスが欲しいとか。 
 ◦ コラボレーションに戻って、新しいものをサービスに追加 するかどうかというのを話し合う 
 • 信頼の構築が重要であり、難しい。特に大きな組織では。 
 ◦ プラットフォームチームは、全ての時間ではないが、特に 初期の段階ではファシリテーションが必要。 
 ◦ プラットフォームチームはインフラやデータ、オブザーバビ リティのドメインに関してはエキスパート。でもプロダクト チームは違う。こういう点を助けていき、技術の理解と信 頼の構築を行うのが重要 
 ◦ 信頼を勝ち取ると、チームが簡単にプラットフォームを採 用してくれるようになる。 

15. ケーススタディ: アディダス 

16. プラットフォームの成功指標 
 • 採用率とエンゲージメント 
 ◦ このプラットフォームを消費しているチームは何チームあって、使用 していないチームはどのぐらいあるのか。 
 ◦ いくつのアプリケーションがどのようなプラットフォームのサービスを 使ってるか
 • ユーザー満足度
 • 信頼性メトリクス
 • デリバリーメトリクス 
 ◦ リードタイム
 ◦ デプロイ頻度
 ◦ MTTR
 ◦ 変更失敗率

17. 金言

18. 経営陣への価値提示 
 ビジネス側の言葉で説明 
 • 例えば、CFOの立場で想像を巡らしてみる 
 ◦ 新人エンジニアが1週間で本番にデリバリーできた ⇨ ？？？ 
 ◦ プラットフォームでクラウドのコストを10%、全てのサービスで削減す ることができた！　⇨　素晴らしいね 
 プラットフォームチームとして、相手の視点に立つ。相手は何を大 切にしているのか、相手は何を成功とみなすのか。それを意識し て会話する必要がある。 
 ラストマイルにフォーカスする。どのような価値を創造しているか を示す。
 ここでアディダスの例も説明されていた。 

19. プラットフォームの持続可能性 
 うまくいってるように思えても、 長期的には非常に課題が出てくる 。「なぜこれだけの費用をプラットフォームに かけているの」「なんでプラットフォームにこれだけの人数必要なの」 
 企業の利益があまり上がっていない時期、このような話題が出がち。 
 4つの柱：
 • 信頼の構築
 ◦ サービスだけでなくてプラットフォームチームが信頼されなければならない 
 • 成功事例の共有
 ◦ マーケティング、売り込みをしなければならない。 
 ◦ どのように役立っているのか、どのような成功事例があるのか。利用チームのメトリクスが上がったということを情報収集して、 それを共有していく必要がある 
 • チーム内の自信
 ◦ 正しい方向に進んでるとチーム全員が理解している必要がある。メトリクスやプラットフォームの採用率、ユーザー満足度、信 頼性によって内部の自信がつく 
 • 外部からの信頼
 ◦ 外部の方々が「コンフィデンス」を持ってくれるということ。プラットフォームの収支、売上にどう貢献しているか、プロダクトチー ムの生産性がどれだけ上がっていって、その結果エンドユーザーにどれだけフォーカスできているのか。 
 ◦ タイム・トゥ・マーケット、サービス提供までの時間がどれだけ短縮されているのか 
 ◦ CxOはこういう点を重要視する。 

20. 2023 State of DevOps Report 
 是非セッションをみてください！
21. Q&A (1) 
 Q. プラットフォームチームが開発チームの信頼を勝ち取る上で大事なポイントは何でしょうか？社内でプラット フォームを提供し始める時に何から着手していくと良いでしょうか？具体的な例を教えてください。 
 A.
 • チームとの対話を通じて、彼らのニーズと現在の課題を理解する。 
 • プラットフォームが提供できる価値を具体的に示す。例えば、より効率的な仕事の方法を提案 
 • プラットフォームチームのメンバーを紹介し、人間関係を構築する。プロダクトチームがプラットフォーム チームを知り、理解することが重要。 
 • 最初から大きな変更を求めるのではなく、基本的なステップから始める。例えば、モニタリングやオブザー バビリティについて理解が不足している場合、そこから始める。 

22. Q&A (2) 
 Q. 経営陣から「君たちは成果を出せていない。作る能力があるなら自らが売れる製品を作れ」と言われていま す。そのため3年くらいごとにプラットフォームチームが解体されてしまっています。チームも成果が出せなくなっ ているのですが、経営陣には何を見せるのが効果的でしょうか？ 
 A.
 • 難しい質問ですね
 • CFOやCEOの視点で考えるということが重要なこと。こういった方々、その経営陣の方々も自分たちの心 配事や仕事でいっぱいいっぱい。なので明確な情報が必要 
 • 例えば3年前プラットフォームを解体した時、プロダクトチームが突然サービスを使えなくなって、このプラッ トフォームチームのリードタイムが上がったとか、サービスに問題が増えて修復が難しくなったとか。それ を裏付けるデータが必要 
 • 大きなインシデントがあって、数時間サービスが提供できなくなって、損失が数百万ドル出た　とか 
 • 経営陣レベルの人は技術の詳細は分からない。なので、彼らが理解出来る言葉に翻訳して伝える必要が ある。

24. メルカリのプラットフォームエンジニアリング概要 
 • ミッション
 a. メルカリグループの開発者がお客様に対して新しい価値、良い体験早く安全 に届けることをサポートするための、インフラ、ツール、ワークフローを提供し ていく
 • 対象範囲
 a. ほぼ全ての開発者が対象 
 b. メルカリ、メルペイ、メルコイン、メルカリハロー 
 • 規模
 a. 200以上のサービス 
 b. 4000以上のKubernetes Pod 
 

25. 立ち上げフェーズ 
 立ち上げていく中で最も大事なのは、 なんでやるのかという疑問にちゃんと答えること 
 
 どういう課題を解決したいのかっていうのは、組織によって変わってくる。メルカリの場合は 
 • マイクロサービスアーキテクチャへの移行が出発点 
 a. 組織がどんどん成長していくことによって、モノリスのアーキテクチャがボトルネックになってきた 
 • アーキテクチャだけでなく開発プロセスや体制の考え方も大きく変えていく必要があった 
 a. たとえばQAフェーズ、テストフェーズ、運用フェーズが、それぞれ特定のチームに依存してしまうのを買えていく必要があった 
 b. これを続けてしまうと、そこがボトルネックになる 
 • チームがちゃんとテストから運用まで自分たちで実施できるようにする 
 a. 一言でいってもやることいっぱいあるし、いきなり言っても難しい要求 
 • なのでプラットフォームエンジニアリングチームが登場した 
 

26. 立ち上げフェーズ 
 • 初期のプラットフォーム開発では、コラボレーションから始める のが最も大事
 a. Manuelさんも同じことを言っていた！ 
 • メルカリの場合は、モノリスだったものからAPIゲートウェイを置く 形にして、リクエストをコントロールしながら段階的にマイクロ サービスとして抜き出していった 
 • このアプローチをやる際、最初にターゲットにした機能は、今後 力を入れていくぞ考えていた出品機能 
 a. メルカリの中でもコアの機能。付随していろんな機能を抜き出す必要が あった。アイテムを管理するサービス、配送を管理するサービス、ユー ザーを管理するサービスなどなど 
 • 開発チームは開発、プラットフォームチームはAPIゲートウェイ の開発やk8s基盤の整備という、ざっくりとした役割分担はあっ た。が、基本的にはプロジェクトの立ち上げからリリースするま で1つのタスクフォースを作って、一緒に実行するってことをやっ た
 • 組織的に分かれているメルペイのときも同様にした。 

27. 立ち上げフェーズ 
 • 狙ってやったわけではないが、いい戦略だったなと思う 
 • プロダクトチームと一緒に働くことによって、彼らが直面している 問題に自分たちも直面できるので、プラットフォームとしてどうい う問題を解くべきかってのがすぐに分かる。解くべき課題の解像 度が上げることができた。 
 • 次に、同じチームで働いてるので近さがあるから、新しく仕組み 作りました、ツール作りましたってなった時に、フィードバックもし やすい。それによって大きく期待を外れたツールを作ることも少 なくなった
 • 出品機能を抜き出す、メルペイをリリースするみたいな、特定の プロジェクトに組み込まれ、それを完遂させることによって、プ ラットフォームを作るだけではなくて、事業的な貢献にも繋がっ た

28. 拡大フェーズ (1): 組織のアップデート 
 ずっと1チームだったが、拡大期に複数のチームに分離した。人数が増えた のと、見るべき領域の拡大による認知負荷が高くなったため。 
 • 3つの戦略
 1. 開発ライフサイクルに合わせたチーム配置 
 i. 各フェーズには異なるドメインの知識が必要になってくる。フェーズごとに チームを配置して、専門性に特化した改善 
 2. プラットフォームチームのためのプラットフォームチーム 
 i. チームトポロジーの中でも書かれているが、プロダクトのチームから見た時 に共通基盤を提供するプラットフォームっていう関係性はフラクタル的に考 えることができる。 
 ii. プラットフォームチームのためのプラットフォームチームとして、Kubernetes を管理するクラウドインフラチームだったりとか、ネットワークを管理する ネットワークチーム 
 3. インターフェースとなるチームの配置（DXチーム） 
 i. これを一番結構気にしてやった 
 ii. 各チームが自分たちのやり方ツールやドキュメントを公開していくと、プロ ダクトチームがそのチームをちゃんと理解して使う必要があり、結果として 認知負荷が上がってしまう。そこをDeveloper eXperienceチームとして一貫 性を持たせるようにした 

29. 拡大フェーズ (2): シングルプラットフォームへの移行 
 deeeetさんとしては1つの会社で1つのプラットフォームがあるべきだと考えている。そうでなければ、事業ごとに 同じような基盤を作っただろうし、それぞれに人をアサインしてムダが多くなったはず。 
 シングルプラットフォームを実現するためにやったこと2つ: 
 • レガシーなコンポーネントをちゃんと載せていくこと 
 ◦ マイクロサービス化は進めていったが、どうしても綺麗に抜き出せないモノリスもあった。 
 ◦ このモノリスは古い基盤で動いていたが、これを新しい基盤に載せていくプロジェクトをやった 
 ▪ 1年くらいはかかったが移行した。古いインフラをちゃんと撤退させることで全体の運用コストを低くできる。古い基盤の メンバーも新しい領域で活躍していくことができる。全体としての最適化が進んでいく 
 • 新しいビジネスもその基板上に載せていくこと 
 ◦ 新規事業が乗ってこないことが結構ある 
 ▪ 新規事業だから新しいテクノロジー使うぞ！ 
 ▪ セキュリティ的に、その他の事業から隔離したい 
 • でも基盤分けるほどなのか？ ということも多い 
 ◦ ではどうするか。依頼を待つという受け身ではなく、積極的に突っ込んでいって議論に巻き込まれる 
 ▪ こういう地道な取り組みは必要 
 ◦ 新規事業のためのゴールデンパスを整備する 
 ▪ 利用可能な技術スタックやプラクティスをドキュメント化 

30. プラットフォームの進化の方向性 
 是非セッションをみてください！
31. Breakoutセッション 

36. 実行委員の話 

37. メンバー
 • 実行委員メンバー、24人(途中で入れ替わりあり)
 • 当日スタッフ 8人
 • 会場周りのお手伝いやオブザーバー参加の方 数名

38. チーム構成 
 Admin Contents Promotion Broadcasting Automation IT Organizer DayStaff Keynote CFP International Venue Sponsor Publishing Monthly Event Website Creators Social Analytics チーム サブチーム
39. キックオフの資料から抜粋 

40. ドキュメント化 
 よく整備されたドキュメントは、それ自体が最小のプ ラットフォーム。
 Notionを使ってドキュメントを集中管理した 

41. チームAPI 
 たくさんのチーム・サブチームができるので、 チームのありかたやチーム間のコミュニケーショ ンを明文化したかった 
 右はAnalyticsチームのもの 
 
 ただ、実践したのは一部チームのみで徹底しき れなかったので、次回への課題 

42. 独特なチーム 
 5月の技書博・技術書典で本を出すことで、 Platform Engineeringの啓蒙とPEKの宣伝を行お う！というチーム。
 今ご覧のPlatform Engineering Meetup Onlineを 開催することで、継続的な情報発信を行っていこ うというチーム
 Publishing Monthly Event
43. 独特なチーム 
 Toilを無くしていくために、便利なSaaSを積極的 に使って色々自動化していこうというチーム。 
 主にZapierを使ってノーコードで自動化していっ た。NotionやSlack、Google FormsやSNSの自動 化まで色々実現
 たくさんのSaaSを使っていくことになるため、アカウント管 理やユーザーのオンボーディングを担うチーム。 
 
 Slack, Discord, X, Bluesky, LinkedIn, Facebook, Google Workspace, AWS, SocialBee, Notion, Miro, GitHub, Cloudflare, Zapier, Google Form, Eventbrite, StreamYard, Bitly, Amazon Business, Graphic, Raksul, しまや出版, 宅 配紙販売, 対面電書, Freee,, UPSIDER, PR TIMES, Square, Paypal
 Automation IT
44. 独特なチーム 
 X、Facebook、LinkedIn、Blueskyを使って情報発 信。
 媒体が多いのでAutomationチームと連携して Notionから自動投稿できるようにした 
 全てにおいて数字で示し、分析していくことが大 事。感覚に頼るのではなく、数字にしていくことで イベントの質や満足度、情報発信を分析し、改善 に繋げるチーム
 Automation IT Social Analytics
45. PEK2025もやっていきます 
 興味のある方、是非運営にご参加下さい！