こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
Platform Engineeringとは、クラウドネイティブ時代において、ソフトウェアエンジニアリング組織にセルフサービス機能を提供するためのツールチェーンやワークフローを設計・構築する技術分野です。
Gartnerが発表した2024年トップ10の戦略的テクノロジートレンドにも登場しており、5年以内にソフトウェアエンジニアリング組織の80%が採用するだろうとも予測されています。
ついに今年も終わりに差し迫り、その2024年を迎えることになる訳ですが、2023年から一足先に2024年のPlatform Engineeringがどの様になっていくのかをPlatform Engineering Meetupのオーガナイザーでもあるjacopenさんをお招きしてお伺いしつつ、Platform Engineeringを実践するSONY社にも現在と今後の展望をお伺いしていきます。
会の様子
2024年のPlatform Engineeringはこうなる(なってほしい)
2023年のPlatform Engineering
2023年は、Platform Engineeringの概念がガートナーのパイプサイクルに登場し、DevOpsのターニングとなるというお話や2026年にはどの企業もPlatform Engineeringが必要になるだろうという予測が出るなど、Platform Engineeringが大きな盛り上がった年だったという話がありました。
認知負荷理論とTeam Topologies
DevOpsが叫ばれるようになってきた一方で、Dev/Opsすべての仕事を一つのチームや開発者が担うのは認知負荷の観点で非常に難しいという話があり、そこで出てきたのがTeam Topologiesであり、そのなかのチームの一つであり開発者の認知負荷を減らす目的を持つPlatform Engineeringだという話がありました。
Platform Engineeringを理解するにあたって
Platform Engineeringの理解に役立つ資料やコミュニティとして、Team Topologies以外で紹介がありました。
以下、紹介されていた話を記載する
- CNCF Platforms White Paper
- Platform Engineering Maturity Model
- PlatformCon 2023
- Platform Engineering Meetup
- CloudNative Days Tokyo 2023
2024年以降のPlatform Engineering
これまでの流れを踏まえると、2024年以降は、
- Platform Engineeringの実践企業の増加
- 体系化された知見の取り込み
- 各ベンダーの機能が充実
- 生成AIの活用
- スタートアップにおける実践例・知見の増加
がトレンドとして挙げられるという話がありました。
プラットフォームの価値
誰に何をどうやって実現するか？というのがプラットフォームではおざなりになりがちであり、Platform as a Productのアプローチを継続して実践していくことやプロダクトマネージャー不足/マイグレーションが今後課題になってくるだろうということでした。
ソニーでの事例から考えるプラットフォーム開発
ソニーにおけるプラットフォーム開発
様々なプロダクトに応じたエンジニアがいるため、SEEDS Cloudと呼ばれるプラットフォーム化を通して開発者のアカウントを支えるプラットフォームを作っているということでした。
Platform Engineering視点で考えるSEEDS Cloud
SEEDS Cloudは社内プラットフォームの中でもうまくいっているといってよいプラットフォーム*1であるということで、なぜうまくいっていると考えられるのかに関してCNCFの観点からふりかえりがありました。
- Platform as a Product...クライアントと一緒にユーザーに対してどういう体験を届けるか、それに対して何が必要なのかを議論しながら開発している。継続的に開発しており、プラットフォーム化する目的をコストダウンのみにしないようにしている
- User Experience...APIを提供しているもののJIRAのチケット等の申請ベースになっている。開発者視点で利用手段を強いないようにしていく
- Documentation and onboarding...ドキュメントサイトを用意
- Self-Service...あまりできていない。チームがサポートして立ち上げしている
- Reduced cognitive load for users...他社サービスをラップしている。証明書管理をはじめとした社内申請やセキュリティ対策など、業務以外の認知負荷も多く存在している
- Secure by default...社内ルールや一般的セキュリティ基準は満たす形で提供している
Q&A
発表の後はQ&Aセッションがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
認知負荷を計測する方法はあるのか？
- 個人に関しては数値化できない。チームだとFour KeysやSPACE frameworkなど。他にもリクルートの方が発表していた内容などはある。
- 認知負荷を計測するというよりはアウトカムを計測する
プラットフォームチームはストリームアラインドチームの外に作る必要があるのか？
社内の開発者は「お客様」化するのは良くない気もするのだがどうしているのか？
- コスト=プラットフォームと見られないようにする工夫が重要
- InnerSourceの考え方を社内に取り込んでいくのはありだと思う
Platform Engineeringでありがちな娯解は？
- 共通基盤を作るだけのチームだという誤解
- 狭い定義に固執してしまう娯解
ソニーの失敗事例を聞いてみたい
最初のお客さんに向けてプラットフォームを作った結果、横串でプラットフォームを広げられないとかはあった
ドキュメントの継続的メンテナンスの事例が知りたい
- ドキュメント更新したのか？をPRのチェックリストに含めている
- チーム内に奉行を入れる
- InnerSourceの考え方を入れる
会全体を通した感想
Platform Engineeringの定義や実践事例に加えて2024年の予測が聞けて、広範囲のトピックを楽しめたのが非常によかったなあと思いました。
CNCFからもう一歩進んだ実践の話が聞けるとより嬉しいかな、と思っていましたが、そこは次の回のお楽しみとしていきたいです。
*1:1000万人が利用
