Platform Engineering ことはじめ ～コミュニティと一緒に新たな旅に出よう！～

2024/2/15 Developers Summit 2024 で発表したスライドです

（概要）
Platform Engineeringは、Gartnerが発表した2024年トップ10の戦略的テクノロジートレンドにも登場しており、5年以内にソフトウェアエンジニアリング組織の80%が採用するだろうとも予測されています。「インフラに関わっている人だけに関係がある話なんでしょ？」とよく勘違いされがちなのですが、実は全Developerが実践できるものです。本セッションでは、様々なバックグラウンドを持つ、Platform Engineering Meetupのメンバーが「すぐにでもPlatform Engineeringを始められる」ためのノウハウや実践方法を紹介します。

https://event.shoeisha.jp/devsumi/20240215/session/4807

Transcript

1. Platform Engineering ことはじめ ～コミュニティと一緒に新たな旅に出よう！～
2. 本セッションについて 様々なバックグラウンドを持つ、Platform Engineering Meetupのメンバーが 「すぐにでもPlatform Engineeringを始められる」ためのノウハウや実践方法を紹介 こういう方におススメ！ • 「Platform Engineering」をざっくり理解したい方 ◦ 是非、ご理解のお役に立てると幸いです • 「インフラに関わっている人だけに関係がある話なんでしょ？」と思っている方 ◦ 実は、全Developerが実践できるものです • 「大きな組織が取り組む話でしょ？」と思っている方 ◦ 実は、小さい組織でも意義があるものです 2
3. 自己紹介 3 四七 秀貴 個人参加 石川 諒 株式会社CAM Creative Division 渡邊 武志 株式会社エウレカ Development 吉川 俊甫 株式会社ｴｰﾋﾟｰｺﾐｭﾆｹｰｼｮﾝｽﾞ ACS事業部
4. Platform Engineering Meetupのご紹介 • 近年急速に注目を集めつつあるPlatform Engineeringについて、 学んで、発信して、交流していくための勉強会です。 4 compass登録メンバ：2300人以上 開催実績：7回 2023/03/09 #1 東京（神田） 2023/05/15 #2 東京（新宿） 2023/06/30 #3 名古屋 2023/08/02 #4 福岡（CNDF2023併催） 2023/10/05 #5 東京（田町） 2023/12/06 #6 東京（お台場） 2024/02/06 #7 東京（渋谷） https://platformengineering.connpass.com/
5. おしながき • Platform Engineeringとは（四七） • アプリ開発における課題感（石川） • Platform Engineeringによる解決のアプローチ（吉川） • 運営メンバーによるプラクティス紹介（渡邊) 5
6. Platform Engineeringとは • 2022年のガートナーによるハイプ・サイクルに初登場し注目 • 2023＆2024年の戦略的テクノロジのトップ・トレンドにも登場 6 引用：https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231114-techtrends テクノロジが多様化、複雑化しライフサイクルも早くなっていく中で、開 発者の負担は大きくなり、また、企業や組織にとっては十分な人材を確保 すること自体が大きなチャレンジとなっています。プラットフォーム・エ ンジニアリングは、ソフトウェアのデリバリとライフサイクル管理を目的 としたセルフサービス型の企業内開発者プラットフォームの構築と運用に 関する取り組みです。 各プラットフォームは、専任のプロダクト・チームによって構築・維持さ れるレイヤであり、ツールやプロセスと連動することで迅速で柔軟なサー ビスの提供を支えられるよう設計されます。プラットフォーム・エンジニ アリングの目標は、生産性とユーザー・エクスペリエンスを最適化し、ビ ジネス価値の実現を加速させることです。
7. Platform Engineeringとは 7 引用：Platform Engineeringへの招待 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai アプリ開発者が開発に集中できるよう プラットフォームが何を提供＆支援するか
8. 背景： 開発者の負担の増大 8 引用：https://www.infoq.com/articles/platform-engineering-primer/ • クラウド技術の発展に伴い、エンジニアがやるべきこと（認知負荷）が激増
9. 海外の動向 9 https://learn.microsoft.com/en-us/platform-engineering/ https://cloud.google.com/blog/ja/products/application-development/how-to-become-a-platform-engineer https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-caf-platform-perspective/platform-eng.html Google Microsoft AWS • 大手クラウド事業者によるガイドライン作りが進む
10. 日本の動向 10 https://speakerdeck.com/shunsato123/sonidenoshi-li-karakao-erupuratutohuomukai-fa https://www.youtube.com/watch?v=grdawJ3icdA https://findy.connpass.com/event/301577/ SONY 任天堂 Mercari • 大手企業での適用や実践が進む
11. プラットフォームの理想と現実 • 規模の拡大等見据え「共通化」をすすめるのは自然の流れ • しかしながら、誰もが一度は耳にするであろう 『 {次世代|新}{共通|汎用|統合}{基盤|プラットフォーム}』 の取り組みがうまくいった、という話はあまり聞かない なぜか？ 11
12. プラットフォームの理想と現実 • 理由１：プラットフォームを作る理由が曖昧 ◦ クラウドネイティブでDevOpsしてDX！（意味不明） • 理由２：技術を入れることが目的になっている ◦ 俺の考えた最強のプラットフォーム！！ ◦ キーパーソンいなくなる＆興味なくなったら崩壊 • 理由３：開発することが目的になっている ◦ プラットフォーム「開発」プロジェクト→運用や改善は誰が？ 12 参考：役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang プラットフォームの利用者＝アプリ開発者 の困りごとに向き合えているか？
13. Platform as a Product • 開発者を『顧客』として考え、顧客にプラットフォーム という『プロダクト』を提供していくアプローチ • 世の中に提供されているさまざまなプロダクトと同じ管 理手法を、プラットフォームにも取り込んでいく • 「プロジェクト」ではなく「プロダクト」として扱う • アプリ開発者の課題と向き合い、認知負荷を軽減し生産 性を高める改善を継続する（正しいことをやる） 13
14. アプリ開発における課題感 アプリケーション開発に集中し、 なるべく早く世に出して価値を検証したい 世に出してからも、早く改善を回して サービスをよくしていきたい 14
15. アプリ開発における課題感 そのためには開発だけでなく、自分たちで ビルド・テスト・デプロイして運用もしていく You build it, you run it 15
16. アプリ開発における課題感 16 現代のソフトウェア開発は複雑で認知負荷が高すぎる You built it, you run it を簡単に体現はできない 引用：Platform Engineeringへの招待 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai
17. アプリ開発における課題感 実際にアプリケーションを開発していく中で、 どんな時に課題や認知負荷を感じるでしょうか イメージしやすいように、自分の経験も踏まえつつ ストーリーを考えてみました 17
18. ストーリーの始まり 入社して数ヶ月のボブは、新しいプロジェクトにアサインされました ステップアップに向けて意気込むボブに、様々な壁が立ちはだかります ストーリー 18
19. ボブは入社して数ヶ月が経過し、会社の主要なプロダクトに新機能 を開発するためのプロジェクトにアサインされた 会社では、異なる機能やコンポーネントに応じて複数の開発言語が 使い分けられている（例: Go, Python, Node.js） チームは新しい機能の迅速な開発と、既存のシステムとのシームレ スな統合を目指している 物語の背景 19
20. 登場人物 ボブ・スミス 年齢: 25歳 職歴: 入社して数ヶ月が経過したアプリケーションデベロッパー。基 本的な業務はこなせるようになり、新たな挑戦を求めている プロジェクトへの期待 • 新しいチャレンジへの期待 ◦ これまでの経験を活かし、より大きな責任を持つプロジェク トに取り組むことに期待している 20
21. • バックエンド開発に重点を置き、サーバーサイドのロジックやデ ータベースの設計を担当 • API設計と実装、既存システムとの統合を目指す ボブの任務 21
22. 課題の出現 プロジェクトが始まると、ボブは多くの課題に直面しました • 環境構築の難しさ • ドキュメントの不足とアクセスの問題 • チーム間のコミュニケーションの課題 22
23. 環境構築の難しさ ある程度仕様などが固まり始めたところで、ボブは開発ツール、 ライブラリ、フレームワーク、インフラなどの環境構築を始める ことに 23
24. 環境構築の難しさ 1. 混乱と圧倒される感覚 ◦ やるべきことや設定オプションと手順の多さに圧倒され、 「どこから始めればいいのかわからない」と感じた 2. エラーとトラブルシューティングの苦労 ◦ 環境を構築する過程で、ボブは様々なエラーメッセージに直面 ◦ これらのエラーを解決するために、彼は多くの時間を費やし、 しばしばフラストレーションを感じた 3. 不確実性と不安 ◦ 正しい設定が完了したかどうかの不確実性は、ボブに不安を与えた ◦ 「もし何かを間違えたら、後で大きな問題になるかもしれない」 と心配になる 24
25. ドキュメントの不足とアクセスの問題 ボブは環境構築や既存システムについて把握するために、さまざま な手順書や過去にされた意思決定について確認しようとするが、こ こでも様々な課題に直面する 25
26. ドキュメントの不足とアクセスの問題 26 1. 情報探索の難しさ ◦ 情報が断片化されており、一貫性がない ◦ 「必要な情報がこれだけバラバラにあると、どこを見ればいいのかさっぱ りわからない」とぼやく 2. 不完全・古い情報との格闘 ◦ 必要な情報が一部しか記載されていない、または全く触れられていない ◦ 見つけたドキュメントが古く、現在のプロジェクトの状態と合わないこと 3. 専門用語の理解の困難さ ◦ ドキュメントにはプロジェクト特有の専門用語が多く使われており、ボブ はそれらの意味を理解するのに苦労する ◦ 「専門用語が多すぎて、何を言っているのかさえ理解できない」と感じ、 孤立感を覚えた
27. ドキュメントの不足とアクセスの問題 27 • アクセス権限の問題 ◦ 一部の重要なドキュメントやリソースにアクセスするための 権限がない ◦ アクセスを申請するための時間が必要 ◦ 「新人だからといって、重要な情報にアクセスできないのは フェアじゃない」とフラストレーションを感じる
28. チーム間のコミュニケーションの課題 既存システムとの統合のために、他チームと連携を取ろうとするが、 ここでも課題に直面する 28
29. 1. 対象の特定 ◦ 統合作業に、どのチームと連携をとる必要があるのか、まずは誰に 連絡をすればいいのか分からない 2. コミュニケーションツール ◦ 大量にある slack チャンネルから、どのチャンネルで他チームとや り取りをしたらいいのか分からない ◦ 技術的な質問やリクエストの問い合わせ方法がチームにより異なる ▪ slack, github issue…. 3. チーム間コミュニケーションの難しさ ◦ 技術的な問い合わせに対して、なかなか返信がこないためフラスト レーションがたまる ◦ どこまでを他チームに依頼していいのか分からず、システム統合の 調整に多くの時間を要してしまう チーム間のコミュニケーションの課題 29
30. ボブの心情 30 1. 時間の圧迫 • 環境構築に予想以上に時間がかかり、ボブは「開発に取り掛かる時間がな くなってしまう」と焦りを感じる 1. フラストレーション • 情報の不足・散らばり、様々な不確実性にフラストレーションを感じる • チーム間とのやりとりがスムーズにいかず、フラストレーションを感じる 1. 自己疑念 • 継続的な問題とエラーにより、ボブは自分のスキルを疑い始め、「もっと 早くセットアップできるべきなのではないか」と感じ、自信を失いかける
31. • 環境構築の難しさ ◦ 十分な手順書が提供されていない ◦ エラーなどを解決するのに多くの時間が裂かれる • 不十分なドキュメントとアクセスの問題 ◦ ドキュメントに書かれていない・更新されていない ◦ 情報が分散して見つけ出すのが困難 ◦ 情報へのアクセス権限がなく申請にも時間がかる • チーム間のコミュニケーション ◦ コミュニケーション手段・連絡先などの情報がまとめられていない ◦ うまく情報が共有できず、認識の齟齬が生まれ、開発に支障をきたす さまざまな課題や認知負荷による開発の遅れと焦りを感じる アプリ開発者の感じる課題感まとめ 31
32. じゃあその課題をどう解決していこう？ 32 Platform Engineering、始めてみませんか？
33. 指針:Platform Engineering Maturity Model •CNCFが公開しているPlatform Engineeringの成熟度を表すモデル •以下の5つの軸において1～4のレベルを設けている ◦Investment - 予算と人員の割り当て ◦Adoption - 導入 ◦Interfaces - プラットフォームの操作と利用 ◦Operations - プラットフォームの運用 ◦Measurement - 効果測定とフィードバックの収集 https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ 33
34. Platform Engineering ことはじめ •「ことはじめ」として、すぐ始められる ことを考える •最初からレベル4を目指すのではなく、まずは 1→2が重要 •Maturity Modelは「今のひとつ上」を目指す指針になる 34 レベル1 Provisional (暫定的） レベル2 Operational (運用可能) レベル3 Scalable （拡張可能） レベル4 Optimizing (最適化)
35. 課題と解決策の整理 • 環境構築の難しさ • 不十分なドキュメントとアクセス • チーム間のコミュニケーション 35 ゴールデンパス の整備 チームAPI の整備
36. ゴールデンパス (Golden Path) とは 開発のベストプラクティスを 実際に動作する環境 と共に提供する仕組み ベストプラクティスをすぐ利用できる形で提供することで、 開発者の生産性を向上させる ことを目的とする 例として、以下のようなものが含まれる • 実際に動くサンプルアプリケーションのコード • アプリケーションをビルド/デプロイするCI/CDパイプライン • 整備されたドキュメント • 環境のオブザーバビリティ（可観測性） 36
37. ゴールデンパスを用いた解決アプローチ ➢ 環境の構築手順が統一されてない ➢ 整備された手順がない ➢ ドキュメントが更新されていない 37 未整備の状態 成熟した状態 ➢ セルフサービスで払い出し可能な環境 ➢ 最新化されたドキュメントが集約され プラットフォーム上に公開されている
38. ゴールデンパスを用いた ことはじめ 環境を構築する過程で、ボブは様々なエラーメッセージに直面 → トラブルシュートの結果を基に、環境構築ドキュメントを更新 情報が断片化されており、一貫性がない → 散逸したドキュメントにアクセスするためのリンク集・インデックスを作成する ドキュメントにはプロジェクト特有の専門用語が多く使われている → プロジェクト内の用語集を作る これらを 関係者がアクセス可能な形で公開する ところから始めてみる 38
39. チームAPI とは チーム間のやりとりについてのインターフェースを定義したもの チームが持つサービスやドキュメント、仕事のやり方などを他チーム に公開しコミュニケーションを円滑にする Team Topology で提唱されている用語 https://github.com/TeamTopologies/Team-API-template 39
40. チームAPIを用いた解決アプローチ ➢ ステークホルダーが不明 ➢ 連絡手段が不明 ➢ 相手の状況がわからずイライラ ➢ 各チームの担当領域が可視化 ➢ チームへの依頼窓口が明確 ➢ 透明性のある状況把握 40 未整備の状態 成熟した状態
41. チームAPIを用いた ことはじめ どのチームと連携をとる必要があるのか、誰に連絡をすればいいのか分からない → 自チームの役割・担当サービスを公開し、相手からの連絡パスを明確化する 大量にある slack チャンネルから、どのチャンネルで他チームとやり取りをしたら いいのか分からない → 自チーム宛のコミュニケーションラインを定める ▪ 依頼事項があればタスク管理ツールのチケットを起票してほしい ▪ 問い合わせであればチャットツールでチームをメンションして、など 自チームの情報を公開し、他チームにも同等の情報公開を促していく。 41
42. 解決のまとめ •優れた前例・プラクティスは取り入れよう •自分たちと優れている先行事例を見比べて悲観する必要はない ひとつずつレベルを上げていこう •できるところから取り組んでいこう ◦メンバーレベル：自分が躓いた箇所を取り除く ◦チームリーダー：情報を整備することを自チームのミッションと捉え、 メンバーが稼働時間を割くことを許容する 42
43. ことはじめ、その先に • 規模を拡大すると、個々のチームの頑張りだけでは破綻する ◦ 恒常的に負荷が高くて対応が進まないチーム ◦ それぞれのチームごとに情報公開する場所がバラバラ ◦ 情報のフォーマットが統一されない • 統一された 開発者プラットフォーム・開発者ポータル の必然性 ◦ プラットフォームの維持管理やゴールデンパスの整備を担うチーム ◦ プラットフォームをプロダクトと捉えた継続改善 ◦ 個々の開発チームの効率を高めるためのアプローチ 43
44. 我々運営メンバーが実践している Platform Engineeringの プラクティスを紹介 44
45. 運営メンバーが実践して3つの Platform Engineering プラクティス • オンボーディングの工夫 • 週報を活用した情報共有 • チーム分け・役割の明確化 45 ゴールデンパス チームAPI 我々運営メンバーは意識してPlatform Engineeringのプラクティスを コミュニティ運営で実践することにトライしています
46. 運営スタッフが実践するプラクティス① オンボーディングの工夫 メンバーのオンボーディングタスクを用意し、 タスクが完了した時点で、申し込みDoneとなる。 →各々運営にJoinするにあたって やるべきことが明確になっている 46
47. 運営スタッフが実践するプラクティス② 週報を活用した情報共有 本業が忙しく運営のやり取りのキャッチアップ が困難な人のために週報が共有される →これだけ読んでおけば主要な アップデートをキャッチアップできる 47
48. 運営スタッフが実践するプラクティス③ チーム分け・役割の明確化 運営内で役割ごとにチームを分け、 Slackのチャンネルを分ける →カテゴリ毎に情報を整備 48
49. すぐにできる簡単なことから始めればいい 49 我々運営の取り組み、当たり前のことがほとんどでしたよね？ 成熟したチーム・組織もこのような簡単なことを継続した先に あります。なのでまずは今すぐできることから始めましょう レベル1 Provisional (暫定的） レベル2 Operational (運用可能) レベル3 Scalable （拡張可能） レベル4 Optimizing (最適化)
50. まとめ • Platform Engineeringとは ◦ アプリ開発者の課題と向き合い、認知負荷を軽減し生産 性を高める改善を継続する（正しいことをやる） • いますぐできることからはじめる ◦ 自分のためにドキュメントを書くことがことはじめ ◦ 正しい改善を継続していくと、 自分→チーム→組織と影響が大きくなっていく 50
51. 51 Platform Engineering Meetup#8 2024/04/19 (金) 大阪にて開催決定！！
52. PEK2024開催します！ 52 項目 詳細 名前 PEK（Platform Engineering Kaigi）2024 日時 2024年7月9日（火） 場所 docomo R&D OPENLAB ODAIBA その他 スポンサー募集、CFPも近日募集開始予定です！