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

by Hideki SHINA

Slide 1

Slide 1 text

Slide 2

Slide 2 text

本セッションについて様々なバックグラウンドを持つ、Platform Engineering Meetupのメンバーが「すぐにでもPlatform Engineeringを始められる」ためのノウハウや実践方法を紹介こういう方におススメ！ ● 「Platform Engineering」をざっくり理解したい方 ○ 是非、ご理解のお役に立てると幸いです ● 「インフラに関わっている人だけに関係がある話なんでしょ？」と思っている方 ○ 実は、全Developerが実践できるものです ● 「大きな組織が取り組む話でしょ？」と思っている方 ○ 実は、小さい組織でも意義があるものです 2

Slide 3

Slide 3 text

自己紹介 3 四七秀貴個人参加石川諒株式会社CAM Creative Division 渡邊武志株式会社エウレカ Development 吉川俊甫株式会社ｴｰﾋﾟｰｺﾐｭﾆｹｰｼｮﾝｽﾞ ACS事業部

Slide 4

Slide 4 text

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/

Slide 5

Slide 5 text

おしながき ● Platform Engineeringとは（四七） ● アプリ開発における課題感（石川） ● Platform Engineeringによる解決のアプローチ（吉川） ● 運営メンバーによるプラクティス紹介（渡邊) 5

Slide 6

Slide 6 text

Platform Engineeringとは ● 2022年のガートナーによるハイプ・サイクルに初登場し注目 ● 2023＆2024年の戦略的テクノロジのトップ・トレンドにも登場 6 引用：https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231114-techtrends テクノロジが多様化、複雑化しライフサイクルも早くなっていく中で、開発者の負担は大きくなり、また、企業や組織にとっては十分な人材を確保すること自体が大きなチャレンジとなっています。プラットフォーム・エンジニアリングは、ソフトウェアのデリバリとライフサイクル管理を目的としたセルフサービス型の企業内開発者プラットフォームの構築と運用に関する取り組みです。各プラットフォームは、専任のプロダクト・チームによって構築・維持されるレイヤであり、ツールやプロセスと連動することで迅速で柔軟なサービスの提供を支えられるよう設計されます。プラットフォーム・エンジニアリングの目標は、生産性とユーザー・エクスペリエンスを最適化し、ビジネス価値の実現を加速させることです。

Slide 7

Slide 7 text

Platform Engineeringとは 7 引用：Platform Engineeringへの招待 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai アプリ開発者が開発に集中できるようプラットフォームが何を提供＆支援するか

Slide 8

Slide 8 text

背景：開発者の負担の増大 8 引用：https://www.infoq.com/articles/platform-engineering-primer/ ● クラウド技術の発展に伴い、エンジニアがやるべきこと（認知負荷）が激増

Slide 9

Slide 9 text

海外の動向 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 ● 大手クラウド事業者によるガイドライン作りが進む

Slide 10

Slide 10 text

日本の動向 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 ● 大手企業での適用や実践が進む

Slide 11

Slide 11 text

プラットフォームの理想と現実 ● 規模の拡大等見据え「共通化」をすすめるのは自然の流れ ● しかしながら、誰もが一度は耳にするであろう『 {次世代|新}{共通|汎用|統合}{基盤|プラットフォーム}』の取り組みがうまくいった、という話はあまり聞かないなぜか？ 11

Slide 12

Slide 12 text

プラットフォームの理想と現実 ● 理由１：プラットフォームを作る理由が曖昧 ○ クラウドネイティブでDevOpsしてDX！（意味不明） ● 理由２：技術を入れることが目的になっている ○ 俺の考えた最強のプラットフォーム！！ ○ キーパーソンいなくなる＆興味なくなったら崩壊 ● 理由３：開発することが目的になっている ○ プラットフォーム「開発」プロジェクト→運用や改善は誰が？ 12 参考：役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang プラットフォームの利用者＝アプリ開発者の困りごとに向き合えているか？

Slide 13

Slide 13 text

Platform as a Service ● 開発者を『顧客』として考え、顧客にプラットフォームという『プロダクト』を提供していくアプローチ ● 世の中に提供されているさまざまなプロダクトと同じ管理手法を、プラットフォームにも取り込んでいく ● 「プロジェクト」ではなく「プロダクト」として扱う ● アプリ開発者の課題と向き合い、認知負荷を軽減し生産性を高める改善を継続する（正しいことをやる） 13

Slide 14

Slide 14 text

アプリ開発における課題感アプリケーション開発に集中し、なるべく早く世に出して価値を検証したい世に出してからも、早く改善を回してサービスをよくしていきたい 14

Slide 15

Slide 15 text

アプリ開発における課題感そのためには開発だけでなく、自分たちでビルド・テスト・デプロイして運用もしていく You build it, you run it 15

Slide 16

Slide 16 text

アプリ開発における課題感 16 現代のソフトウェア開発は複雑で認知負荷が高すぎる You built it, you run it を簡単に体現はできない引用：Platform Engineeringへの招待 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai

Slide 17

Slide 17 text

アプリ開発における課題感実際にアプリケーションを開発していく中で、どんな時に課題や認知負荷を感じるでしょうかイメージしやすいように、自分の経験も踏まえつつストーリーを考えてみました 17

Slide 18

Slide 18 text

ストーリーの始まり入社して数ヶ月のボブは、新しいプロジェクトにアサインされましたステップアップに向けて意気込むボブに、様々な壁が立ちはだかりますストーリー 18

Slide 19

Slide 19 text

ボブは入社して数ヶ月が経過し、会社の主要なプロダクトに新機能を開発するためのプロジェクトにアサインされた会社では、異なる機能やコンポーネントに応じて複数の開発言語が使い分けられている（例: Go, Python, Node.js）チームは新しい機能の迅速な開発と、既存のシステムとのシームレスな統合を目指している物語の背景 19

Slide 20

Slide 20 text

登場人物ボブ・スミス年齢: 25歳職歴: 入社して数ヶ月が経過したアプリケーションデベロッパー。基本的な業務はこなせるようになり、新たな挑戦を求めているプロジェクトへの期待 ● 新しいチャレンジへの期待 ○ これまでの経験を活かし、より大きな責任を持つプロジェクトに取り組むことに期待している 20

Slide 21

Slide 21 text

● バックエンド開発に重点を置き、サーバーサイドのロジックやデータベースの設計を担当 ● API設計と実装、既存システムとの統合を目指すボブの任務 21

Slide 22

Slide 22 text

課題の出現プロジェクトが始まると、ボブは多くの課題に直面しました ● 環境構築の難しさ ● ドキュメントの不足とアクセスの問題 ● チーム間のコミュニケーションの課題 22

Slide 23

Slide 23 text

環境構築の難しさある程度仕様などが固まり始めたところで、ボブは開発ツール、ライブラリ、フレームワーク、インフラなどの環境構築を始めることに 23

Slide 24

Slide 24 text

環境構築の難しさ 1. 混乱と圧倒される感覚 ○ やるべきことや設定オプションと手順の多さに圧倒され、「どこから始めればいいのかわからない」と感じた 2. エラーとトラブルシューティングの苦労 ○ 環境を構築する過程で、ボブは様々なエラーメッセージに直面 ○ これらのエラーを解決するために、彼は多くの時間を費やし、しばしばフラストレーションを感じた 3. 不確実性と不安 ○ 正しい設定が完了したかどうかの不確実性は、ボブに不安を与えた ○ 「もし何かを間違えたら、後で大きな問題になるかもしれない」と心配になる 24

Slide 25

Slide 25 text

ドキュメントの不足とアクセスの問題ボブは環境構築や既存システムについて把握するために、さまざまな手順書や過去にされた意思決定について確認しようとするが、ここでも様々な課題に直面する 25

Slide 26

Slide 26 text

ドキュメントの不足とアクセスの問題 26 1. 情報探索の難しさ ○ 情報が断片化されており、一貫性がない ○ 「必要な情報がこれだけバラバラにあると、どこを見ればいいのかさっぱりわからない」とぼやく 2. 不完全・古い情報との格闘 ○ 必要な情報が一部しか記載されていない、または全く触れられていない ○ 見つけたドキュメントが古く、現在のプロジェクトの状態と合わないこと 3. 専門用語の理解の困難さ ○ ドキュメントにはプロジェクト特有の専門用語が多く使われており、ボブはそれらの意味を理解するのに苦労する ○ 「専門用語が多すぎて、何を言っているのかさえ理解できない」と感じ、孤立感を覚えた

Slide 27

Slide 27 text

ドキュメントの不足とアクセスの問題 27 ● アクセス権限の問題 ○ 一部の重要なドキュメントやリソースにアクセスするための権限がない ○ アクセスを申請するための時間が必要 ○ 「新人だからといって、重要な情報にアクセスできないのはフェアじゃない」とフラストレーションを感じる

Slide 28

Slide 28 text

チーム間のコミュニケーションの課題既存システムとの統合のために、他チームと連携を取ろうとするが、ここでも課題に直面する 28

Slide 29

Slide 29 text

1. 対象の特定 ○ 統合作業に、どのチームと連携をとる必要があるのか、まずは誰に連絡をすればいいのか分からない 2. コミュニケーションツール ○ 大量にある slack チャンネルから、どのチャンネルで他チームとやり取りをしたらいいのか分からない ○ 技術的な質問やリクエストの問い合わせ方法がチームにより異なる ■ slack, github issue…. 3. チーム間コミュニケーションの難しさ ○ 技術的な問い合わせに対して、なかなか返信がこないためフラストレーションがたまる ○ どこまでを他チームに依頼していいのか分からず、システム統合の調整に多くの時間を要してしまうチーム間のコミュニケーションの課題 29

Slide 30

Slide 30 text

ボブの心情 30 1. 時間の圧迫 ● 環境構築に予想以上に時間がかかり、ボブは「開発に取り掛かる時間がなくなってしまう」と焦りを感じる 1. フラストレーション ● 情報の不足・散らばり、様々な不確実性にフラストレーションを感じる ● チーム間とのやりとりがスムーズにいかず、フラストレーションを感じる 1. 自己疑念 ● 継続的な問題とエラーにより、ボブは自分のスキルを疑い始め、「もっと早くセットアップできるべきなのではないか」と感じ、自信を失いかける

Slide 31

Slide 31 text

● 環境構築の難しさ ○ 十分な手順書が提供されていない ○ エラーなどを解決するのに多くの時間が裂かれる ● 不十分なドキュメントとアクセスの問題 ○ ドキュメントに書かれていない・更新されていない ○ 情報が分散して見つけ出すのが困難 ○ 情報へのアクセス権限がなく申請にも時間がかる ● チーム間のコミュニケーション ○ コミュニケーション手段・連絡先などの情報がまとめられていない ○ うまく情報が共有できず、認識の齟齬が生まれ、開発に支障をきたすさまざまな課題や認知負荷による開発の遅れと焦りを感じるアプリ開発者の感じる課題感まとめ 31

Slide 32

Slide 32 text

じゃあその課題をどう解決していこう？ 32 Platform Engineering、始めてみませんか？

Slide 33

Slide 33 text

指針: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

Slide 34

Slide 34 text

Platform Engineering ことはじめ ●「ことはじめ」として、すぐ始められることを考える ●最初からレベル4を目指すのではなく、まずは 1→2が重要 ●Maturity Modelは「今のひとつ上」を目指す指針になる 34 レベル1 Provisional (暫定的）レベル2 Operational (運用可能) レベル3 Scalable （拡張可能）レベル4 Optimizing (最適化)

Slide 35

Slide 35 text

課題と解決策の整理 ● 環境構築の難しさ ● 不十分なドキュメントとアクセス ● チーム間のコミュニケーション 35 ゴールデンパスの整備チームAPI の整備

Slide 36

Slide 36 text

ゴールデンパス (Golden Path) とは開発のベストプラクティスを実際に動作する環境と共に提供する仕組みベストプラクティスをすぐ利用できる形で提供することで、開発者の生産性を向上させることを目的とする例として、以下のようなものが含まれる ● 実際に動くサンプルアプリケーションのコード ● アプリケーションをビルド/デプロイするCI/CDパイプライン ● 整備されたドキュメント ● 環境のオブザーバビリティ（可観測性） 36

Slide 37

Slide 37 text

ゴールデンパスを用いた解決アプローチ ➢ 環境の構築手順が統一されてない ➢ 整備された手順がない ➢ ドキュメントが更新されていない 37 未整備の状態成熟した状態 ➢ セルフサービスで払い出し可能な環境 ➢ 最新化されたドキュメントが集約されプラットフォーム上に公開されている

Slide 38

Slide 38 text

ゴールデンパスを用いたことはじめ環境を構築する過程で、ボブは様々なエラーメッセージに直面 → トラブルシュートの結果を基に、環境構築ドキュメントを更新情報が断片化されており、一貫性がない → 散逸したドキュメントにアクセスするためのリンク集・インデックスを作成するドキュメントにはプロジェクト特有の専門用語が多く使われている → プロジェクト内の用語集を作るこれらを関係者がアクセス可能な形で公開するところから始めてみる 38

Slide 39

Slide 39 text

チームAPI とはチーム間のやりとりについてのインターフェースを定義したものチームが持つサービスやドキュメント、仕事のやり方などを他チームに公開しコミュニケーションを円滑にする Team Topology で提唱されている用語 https://github.com/TeamTopologies/Team-API-template 39

Slide 40

Slide 40 text

チームAPIを用いた解決アプローチ ➢ ステークホルダーが不明 ➢ 連絡手段が不明 ➢ 相手の状況がわからずイライラ ➢ 各チームの担当領域が可視化 ➢ チームへの依頼窓口が明確 ➢ 透明性のある状況把握 40 未整備の状態成熟した状態

Slide 41

Slide 41 text

チームAPIを用いたことはじめどのチームと連携をとる必要があるのか、誰に連絡をすればいいのか分からない → 自チームの役割・担当サービスを公開し、相手からの連絡パスを明確化する大量にある slack チャンネルから、どのチャンネルで他チームとやり取りをしたらいいのか分からない → 自チーム宛のコミュニケーションラインを定める ▪ 依頼事項があればタスク管理ツールのチケットを起票してほしい ▪ 問い合わせであればチャットツールでチームをメンションして、など自チームの情報を公開し、他チームにも同等の情報公開を促していく。 41

Slide 42

Slide 42 text

解決のまとめ ●優れた前例・プラクティスは取り入れよう ●自分たちと優れている先行事例を見比べて悲観する必要はないひとつずつレベルを上げていこう ●できるところから取り組んでいこう ○メンバーレベル：自分が躓いた箇所を取り除く ○チームリーダー：情報を整備することを自チームのミッションと捉え、メンバーが稼働時間を割くことを許容する 42

Slide 43

Slide 43 text

ことはじめ、その先に ● 規模を拡大すると、個々のチームの頑張りだけでは破綻する ○ 恒常的に負荷が高くて対応が進まないチーム ○ それぞれのチームごとに情報公開する場所がバラバラ ○ 情報のフォーマットが統一されない ● 統一された開発者プラットフォーム・開発者ポータルの必然性 ○ プラットフォームの維持管理やゴールデンパスの整備を担うチーム ○ プラットフォームをプロダクトと捉えた継続改善 ○ 個々の開発チームの効率を高めるためのアプローチ 43

Slide 44

Slide 44 text

我々運営メンバーが実践している Platform Engineeringのプラクティスを紹介 44

Slide 45

Slide 45 text

運営メンバーが実践して3つの Platform Engineering プラクティス ● オンボーディングの工夫 ● 週報を活用した情報共有 ● チーム分け・役割の明確化 45 ゴールデンパスチームAPI 我々運営メンバーは意識してPlatform Engineeringのプラクティスをコミュニティ運営で実践することにトライしています

Slide 46

Slide 46 text

運営スタッフが実践するプラクティス① オンボーディングの工夫メンバーのオンボーディングタスクを用意し、タスクが完了した時点で、申し込みDoneとなる。 →各々運営にJoinするにあたってやるべきことが明確になっている 46

Slide 47

Slide 47 text

運営スタッフが実践するプラクティス② 週報を活用した情報共有本業が忙しく運営のやり取りのキャッチアップが困難な人のために週報が共有される →これだけ読んでおけば主要なアップデートをキャッチアップできる 47

Slide 48

Slide 48 text

運営スタッフが実践するプラクティス③ チーム分け・役割の明確化運営内で役割ごとにチームを分け、 Slackのチャンネルを分ける →カテゴリ毎に情報を整備 48

Slide 49

Slide 49 text

すぐにできる簡単なことから始めればいい 49 我々運営の取り組み、当たり前のことがほとんどでしたよね？成熟したチーム・組織もこのような簡単なことを継続した先にあります。なのでまずは今すぐできることから始めましょうレベル1 Provisional (暫定的）レベル2 Operational (運用可能) レベル3 Scalable （拡張可能）レベル4 Optimizing (最適化)

Slide 50

Slide 50 text

まとめ ● Platform Engineeringとは ○ アプリ開発者の課題と向き合い、認知負荷を軽減し生産性を高める改善を継続する（正しいことをやる） ● いますぐできることからはじめる ○ 自分のためにドキュメントを書くことがことはじめ ○ 正しい改善を継続していくと、自分→チーム→組織と影響が大きくなっていく 50

Slide 51

Slide 51 text

51 Platform Engineering Meetup#8 2024/04/19 (金) 大阪にて開催決定！！

Slide 52

Slide 52 text

PEK2024開催します！ 52 項目詳細名前 PEK（Platform Engineering Kaigi）2024 日時 2024年7月9日（火）場所 docomo R&D OPENLAB ODAIBA その他スポンサー募集、CFPも近日募集開始予定です！