Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hideki SHINA
February 15, 2024

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

Hideki SHINA

February 15, 2024
Tweet

More Decks by Hideki SHINA

Other Decks in Technology

Transcript

  1. 本セッションについて 様々なバックグラウンドを持つ、Platform Engineering Meetupのメンバーが 「すぐにでもPlatform Engineeringを始められる」ためのノウハウや実践方法を紹介 こういう方におススメ! • 「Platform Engineering」をざっくり理解したい方

    ◦ 是非、ご理解のお役に立てると幸いです • 「インフラに関わっている人だけに関係がある話なんでしょ?」と思っている方 ◦ 実は、全Developerが実践できるものです • 「大きな組織が取り組む話でしょ?」と思っている方 ◦ 実は、小さい組織でも意義があるものです 2
  2. 自己紹介 3 四七 秀貴 個人参加 石川 諒 株式会社CAM Creative Division

    渡邊 武志 株式会社エウレカ Development 吉川 俊甫 株式会社エーピーコミュニケーションズ ACS事業部
  3. 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/
  4. Platform Engineeringとは • 2022年のガートナーによるハイプ・サイクルに初登場し注目 • 2023&2024年の戦略的テクノロジのトップ・トレンドにも登場 6 引用:https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20231114-techtrends テクノロジが多様化、複雑化しライフサイクルも早くなっていく中で、開 発者の負担は大きくなり、また、企業や組織にとっては十分な人材を確保

    すること自体が大きなチャレンジとなっています。プラットフォーム・エ ンジニアリングは、ソフトウェアのデリバリとライフサイクル管理を目的 としたセルフサービス型の企業内開発者プラットフォームの構築と運用に 関する取り組みです。 各プラットフォームは、専任のプロダクト・チームによって構築・維持さ れるレイヤであり、ツールやプロセスと連動することで迅速で柔軟なサー ビスの提供を支えられるよう設計されます。プラットフォーム・エンジニ アリングの目標は、生産性とユーザー・エクスペリエンスを最適化し、ビ ジネス価値の実現を加速させることです。
  5. プラットフォームの理想と現実 • 理由1:プラットフォームを作る理由が曖昧 ◦ クラウドネイティブでDevOpsしてDX!(意味不明) • 理由2:技術を入れることが目的になっている ◦ 俺の考えた最強のプラットフォーム!! ◦

    キーパーソンいなくなる&興味なくなったら崩壊 • 理由3:開発することが目的になっている ◦ プラットフォーム「開発」プロジェクト→運用や改善は誰が? 12 参考:役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方 https://speakerdeck.com/jacopen/yi-nili-tupuratutohuomuwozuo-rou-puratutohuomuenziniagazhi-tuteokubeki-purodakuto-falsekao-efang プラットフォームの利用者=アプリ開発者 の困りごとに向き合えているか?
  6. Platform as a Service • 開発者を『顧客』として考え、顧客にプラットフォーム という『プロダクト』を提供していくアプローチ • 世の中に提供されているさまざまなプロダクトと同じ管 理手法を、プラットフォームにも取り込んでいく

    • 「プロジェクト」ではなく「プロダクト」として扱う • アプリ開発者の課題と向き合い、認知負荷を軽減し生産 性を高める改善を継続する(正しいことをやる) 13
  7. 環境構築の難しさ 1. 混乱と圧倒される感覚 ◦ やるべきことや設定オプションと手順の多さに圧倒され、 「どこから始めればいいのかわからない」と感じた 2. エラーとトラブルシューティングの苦労 ◦ 環境を構築する過程で、ボブは様々なエラーメッセージに直面

    ◦ これらのエラーを解決するために、彼は多くの時間を費やし、 しばしばフラストレーションを感じた 3. 不確実性と不安 ◦ 正しい設定が完了したかどうかの不確実性は、ボブに不安を与えた ◦ 「もし何かを間違えたら、後で大きな問題になるかもしれない」 と心配になる 24
  8. ドキュメントの不足とアクセスの問題 26 1. 情報探索の難しさ ◦ 情報が断片化されており、一貫性がない ◦ 「必要な情報がこれだけバラバラにあると、どこを見ればいいのかさっぱ りわからない」とぼやく 2.

    不完全・古い情報との格闘 ◦ 必要な情報が一部しか記載されていない、または全く触れられていない ◦ 見つけたドキュメントが古く、現在のプロジェクトの状態と合わないこと 3. 専門用語の理解の困難さ ◦ ドキュメントにはプロジェクト特有の専門用語が多く使われており、ボブ はそれらの意味を理解するのに苦労する ◦ 「専門用語が多すぎて、何を言っているのかさえ理解できない」と感じ、 孤立感を覚えた
  9. 1. 対象の特定 ◦ 統合作業に、どのチームと連携をとる必要があるのか、まずは誰に 連絡をすればいいのか分からない 2. コミュニケーションツール ◦ 大量にある slack

    チャンネルから、どのチャンネルで他チームとや り取りをしたらいいのか分からない ◦ 技術的な質問やリクエストの問い合わせ方法がチームにより異なる ▪ slack, github issue…. 3. チーム間コミュニケーションの難しさ ◦ 技術的な問い合わせに対して、なかなか返信がこないためフラスト レーションがたまる ◦ どこまでを他チームに依頼していいのか分からず、システム統合の 調整に多くの時間を要してしまう チーム間のコミュニケーションの課題 29
  10. ボブの心情 30 1. 時間の圧迫 • 環境構築に予想以上に時間がかかり、ボブは「開発に取り掛かる時間がな くなってしまう」と焦りを感じる 1. フラストレーション •

    情報の不足・散らばり、様々な不確実性にフラストレーションを感じる • チーム間とのやりとりがスムーズにいかず、フラストレーションを感じる 1. 自己疑念 • 継続的な問題とエラーにより、ボブは自分のスキルを疑い始め、「もっと 早くセットアップできるべきなのではないか」と感じ、自信を失いかける
  11. • 環境構築の難しさ ◦ 十分な手順書が提供されていない ◦ エラーなどを解決するのに多くの時間が裂かれる • 不十分なドキュメントとアクセスの問題 ◦ ドキュメントに書かれていない・更新されていない

    ◦ 情報が分散して見つけ出すのが困難 ◦ 情報へのアクセス権限がなく申請にも時間がかる • チーム間のコミュニケーション ◦ コミュニケーション手段・連絡先などの情報がまとめられていない ◦ うまく情報が共有できず、認識の齟齬が生まれ、開発に支障をきたす さまざまな課題や認知負荷による開発の遅れと焦りを感じる アプリ開発者の感じる課題感まとめ 31
  12. 指針: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
  13. ゴールデンパス (Golden Path) とは 開発のベストプラクティスを 実際に動作する環境 と共に提供する仕組み ベストプラクティスをすぐ利用できる形で提供することで、 開発者の生産性を向上させる ことを目的とする

    例として、以下のようなものが含まれる • 実際に動くサンプルアプリケーションのコード • アプリケーションをビルド/デプロイするCI/CDパイプライン • 整備されたドキュメント • 環境のオブザーバビリティ(可観測性) 36
  14. ゴールデンパスを用いた解決アプローチ ➢ 環境の構築手順が統一されてない ➢ 整備された手順がない ➢ ドキュメントが更新されていない 37 未整備の状態 成熟した状態

    ➢ セルフサービスで払い出し可能な環境 ➢ 最新化されたドキュメントが集約され プラットフォーム上に公開されている
  15. チームAPIを用いた ことはじめ どのチームと連携をとる必要があるのか、誰に連絡をすればいいのか分からない → 自チームの役割・担当サービスを公開し、相手からの連絡パスを明確化する 大量にある slack チャンネルから、どのチャンネルで他チームとやり取りをしたら いいのか分からない →

    自チーム宛のコミュニケーションラインを定める ▪ 依頼事項があればタスク管理ツールのチケットを起票してほしい ▪ 問い合わせであればチャットツールでチームをメンションして、など 自チームの情報を公開し、他チームにも同等の情報公開を促していく。 41
  16. ことはじめ、その先に • 規模を拡大すると、個々のチームの頑張りだけでは破綻する ◦ 恒常的に負荷が高くて対応が進まないチーム ◦ それぞれのチームごとに情報公開する場所がバラバラ ◦ 情報のフォーマットが統一されない •

    統一された 開発者プラットフォーム・開発者ポータル の必然性 ◦ プラットフォームの維持管理やゴールデンパスの整備を担うチーム ◦ プラットフォームをプロダクトと捉えた継続改善 ◦ 個々の開発チームの効率を高めるためのアプローチ 43
  17. 運営メンバーが実践して3つの Platform Engineering プラクティス • オンボーディングの工夫 • 週報を活用した情報共有 • チーム分け・役割の明確化

    45 ゴールデンパス チームAPI 我々運営メンバーは意識してPlatform Engineeringのプラクティスを コミュニティ運営で実践することにトライしています
  18. まとめ • Platform Engineeringとは ◦ アプリ開発者の課題と向き合い、認知負荷を軽減し生産 性を高める改善を継続する(正しいことをやる) • いますぐできることからはじめる ◦

    自分のためにドキュメントを書くことがことはじめ ◦ 正しい改善を継続していくと、 自分→チーム→組織と影響が大きくなっていく 50
  19. PEK2024開催します! 52 項目 詳細 名前 PEK(Platform Engineering Kaigi)2024 日時 2024年7月9日(火)

    場所 docomo R&D OPENLAB ODAIBA その他 スポンサー募集、CFPも近日募集開始予定です!