SRE課の飯野です。
去る2024/7/9(火)、『Platform Engineering Kaigi 2024』（以下PEK）が開催されました。
弊社からは7名（SRE課6名＋インフラ部長）が現地参加し、登壇企業の皆さまの熱量あふれるセッションを肌で体感してきました。
本ブログでは、PEK参加後にSRE課メンバーで実施した社内でのふりかえりの内容をお届けします。
目次
PEKとは？
『Platform Engineering Kaigi 2024』は、プラットフォームエンジニアリングをテーマにしたテックカンファレンスです。
もともと『Platform Engineering Meetup』という勉強会を主催していたコミュニティが「一般社団法人クラウドネイティブイノベーターズ協会」という団体を立ち上げ、その団体が今回日本で初めとなる大型カンファレンスを開催する運びとなりました。
オフライン会場は東京・お台場の「docomo R&D OPENLAB ODAIBA」にて行われ、オンライン配信も含むハイブリッド方式で開催されました。
記念すべき第一回のコンセプトは「 DevOpsの荒波を乗りこえる、エンジニアの羅針盤」。
Platform Engineering Kaigiは、現在注目を浴びているPlatform Engineeringをテーマにしたテクノロジーカンファレンスです。
コンテナをはじめとしたクラウドネイティブ技術の発展やDevOpsの浸透、さまざまな便利なツールの登場により、アプリケーション開発の現場は大きく変わりました。その一方で、開発者一人が扱わなくてはいけない技術の高度化、複雑化により認知負荷が年々高まっていると言われています。認知負荷の高まりは生産性の低下に繋がるおそれがあり、せっかく導入した新技術がスポイルされかねません。
その解決策として期待されているのがPlatform Engineeringです。Team topologiesに基づいた適切なチーム分け、そして認知負荷を減らすことを目的とした共通プラットフォームを構築することによって、技術のコントロールを取り戻し、組織のスケーラビリティと生産性を両立することができます。
本イベントは、そんなPlatform Engineeringの世界に深く潜り込むための絶好の機会です。最新のトレンド、実践的な知見、そしてこの分野のトップランナーたちとの交流を通じて、テクノロジーの未来を切り拓いていきましょう。
（公式サイトより）
現地で発表された情報によると、申込者数は996名！
Platform Engineeringの勢い、盛り上がりを感じますね〜。
当日の様子
タイムテーブル
チームトポロジー著者のManuel Pais氏の基調講演に始まり、2トラック開催で各30分ずつのセッションが行われました。
現地参加のメンバーは各々好きなセッションを拝聴しましたが、（もちろん重複はあるものの）チームとしてのインプット量が凄まじいですね！
その他、現地ではお昼ご飯にはサンドイッチ、おやつにはカヌレとコーヒーが提供されました。
（写真が食べ物しかなくてすみませんw）
各スポンサーブースではスタンプラリーが開催されており、おみやげをたくさんいただきました、スポンサー企業の皆さまありがとうございます！
また、セッション終了後には懇親会も行われました。
ふりかえりやってみよう
さて、現地参加の熱が冷めやらぬうちに、後日さっそくふりかえりを実施してみました。
実施するにあたって、事前に用意したフォーマットは下記です。
# 印象に残ったセッション ## タイトル ## 登壇者情報 ## スライド ## セッション概要 - セッションの内容を簡潔に ## 共有したい点、感想等 - どんな点に共感したか、疑問に思ったこと等 --- # 今後実施/挑戦したいこと - 参加してみてアクションを起こしたくなったものが何かあれば # 全体を通しての感想 - 率直な感想をご自由に
それぞれが印象に残ったセッションを選択し、セッション概要と共有したい点/感想等を事前にまとめてもらいました。
以下、実際にまとめてもらったふりかえりの内容をご紹介します。
タイミーを支えるプラットフォームエンジニアリング・成果指標設計から考える組織作り事例の紹介
セッション概要
- インフラ領域のタスクを消化するいわゆるインフラチームから、プラットフォームエンジニアリングを体現するチームへ進化するための1年間の取り組みを紹介
- 当初、プラットフォームチームはインフラ関連の散発的なタスクをこなすだけのチームになっていたが、この体制を改善した
共有したい点、感想等
- チームの存在意義や重要視する指標を定義し、課題探索の方法や他部署との関わり方をルール化することで、チーム内の目的意識を合わせるとともにミッションを体現するための施策に取り組むことができておりとても参考になった
- 成果指標を定義した背景として「説明可能であることの価値」を説いておりとても共感した
今後実施/挑戦したいこと
- プラットフォーム提供者として、作ったものをより使いやすくするために、マニュアルやリリースノート等のドキュメントのフォーマット決めと開発本部全体への周知ができると良いなと感じた
全体を通しての感想
- 立ち上がったばかりのプラットフォームチームのあり方がまとまっており、参考にしたい部分が多かった
- ドキュメンテーションや周知はストリームアラインドチームとの接点にもなるし信頼貯金にもつながるので積極的にやっていきたいと思った
明日から始める持続可能なドキュメンテーション戦略
セッション概要
- プラットフォームチームとして提供している技術ドキュメントの継続的な運用方法の紹介
- 構造品質よりも目的やゴールの達成がより重要（＝機能品質）
- どんなに品質の高いドキュメントを書いても徐々に腐るもの
- ドキュメントのライフサイクルを意識した、具体的な改善方法を紹介
- レビューのポリシーとフローの定義
- メンテナンスポリシーの定義
- メトリクスを指標として追う（鮮度と有効性）
- 想定読者に利用されているか（閲覧数）
共有したい点、感想等
- 「開発組織のポテンシャルを解放する」というチームのミッションがかっこいい！成果の最大化はよく聞くけど、この言い回しすてき！
- ドキュメントもプラットフォームの一部という考え方に気づけた
- 提供する機能だけに重きを置くのではなく、開発者がいかに自律的に使ってもらうかを意識してドキュメントの整備にここまで力を入れられているのは会社としてすごい
- たしかに業務をしていて資料を探している時間ってとても多いし、このドキュメント正しいのか？とメンテ状況を考えるのしんどいですよね（実態と合っていなかったりするとあちゃ〜ってなる）
- ドキュメント管理もデータドリブンでとてもよい取り組みだと思った、データは正義
今後実施/挑戦したいこと
- 今後SRE課で提供するもの、管理するものに関してはしっかりドキュメントもメンテナンスフローを構築したい
- リリース等のプロセス改善をしていく上で、本当に開発チームが楽になったのか？認知不可が下がっているのか？は常に意識していかないといけない
全体を通しての感想
- 改めて、プラットフォームは開発チームに強制的に使ってもらうものではなく、あくまでも開発チームを助けるもの（求められているもの）であるという理解
- プラットフォームチームとして活躍している他社の事例を目の当たりして、弊社の組織のあり方を再考するよい機会になった
モノリス開発の名残からの脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と堅牢性を追求した認可基盤刷新の過程と工夫
セッション概要
- アプリケーションから認可機能を切り出していくまでに検討したこと、安全に移行するまでにやったことなどの紹介
共有したい点、感想等
- 移行後の認可基盤にバグがあった場合、本来アクセスできない画面が見えてしまうといったこともあるかもしれないので、既存の認可機能を残しつつ新認可基盤もリリースし、認可機能と認可基盤の挙動としてどちらも同一であることを確認する方法をとっていた点が参考になった
- 万が一のためにガードレールを敷いて、認可基盤の信頼性を担保するというのはとても勉強になった
今後実施/挑戦したいこと
全体を通しての感想
- 複数のプロダクトを展開する他社の開発体制と自社の体制との差を再認識するよい機会となった
What is Platform as a Product and Why Should You Care
※チームトポロジーの著者Manuel Pais氏による基調講演
※スライドは非公開
セッション概要
- プラットフォーム構築の目的はストリームアラインドチーム（SA-T）の認知負荷を下げること
- 扱いが難しく、認知負荷を上げるプラットフォームは浸透しない
- SA-Tがプラットフォーマーの顧客である
- プラットフォームはプロダクトとして扱うべき。なので、ユーザー（SA-T）へのアプローチはプロダクトと同様にとるべきである
- プラットフォームの持続可能性を保つための4つの柱
- プラットフォームを信頼してもらう
- サクセスストーリーを共有していく
- プラットフォームチーム自身のconfidence（自信）が不可欠
- ユーザーのconfidence（自信）が不可欠
共有したい点、感想等
- 「ストリームアラインドチーム（開発チーム）がアプリケーション開発に専念できるようにする」ことが目的だが、これを実現するのは非常に困難
- プラットフォームをプロダクトと捉えるとうまく進む、というところが凄く腹落ちした
- 多くの会社でプラットフォーム化が失敗する原因もよく分かった
- エンジニア側の問題
- ビジネス観点が足りないことが多く、収支が見込めないサービスは投資してもらえない
- ビジネス側の問題
- エンジニアリングの観点が足りないことが多く、投資に足るサービスであるか否かを正確に判断できない
- エンジニア側の問題
- うまく行っている会社は上記2者間の相互理解がちゃんとできているなと思った
今後実施/挑戦したいこと
- 現プラットフォーム化プロジェクトで90点を目指す
- ストリームアラインドチームの認知負荷を下げるための改善を実施
- フィードバックを得る為のメトリクスの整備
- 利用者数を計画的に増やす
全体を通しての感想
- Platform Engineeringは実態として社内ベンチャーに近い存在であり、それが難しい理由の一つだと感じた
- しかし、顧客は社内の仲間であり、フィードバックや相互理解の機会が通常のプロダクトよりも多くあるはずなので、これらの機会をしっかりと活用することで成功の可能性が高まると思った
- ビジネスサイドの方々にも基調講演を見ていただく機会があれば、相互理解がより進みやすいのではないかと感じた
Platform Engineering at Mercari
セッション概要
- MercariのPlatform Engineeringチームがプラットフォームをどのように立ち上げ、発展させてきたのか、その中から得られた学びについて紹介
共有したい点、感想等
- 各チームが独自にプラットフォームを作ると、重複が生じて無駄が発生してしまう＝1つの会社で1つのプラットフォームであるべき
- 「古いシステム」＝「価値の高いシステム」であるという視点
- モノリシックなシステムは新しい基盤に移行するのに時間がかかり、すべてをマイクロサービスにするのは現実的ではないため、モノリスのまま移行する
- 新しい基盤にすべてを移行するメリットとして、古いインフラの管理をなくすことができる
今後実施/挑戦したいこと
- もし今各商材でプラットフォーム的なものが乱立しているなら、共通化することで無駄を削れるのではないかと思った
全体を通しての感想
- 異動してから初のSRE（Platform Engineering）系のイベントだったが、話がちょっとわかるぞ！となった
- 基調講演で「ストリームアラインドチームが必要としているプラットフォームを提供する」とあったが、まずはチームが求めるものが本当に問題解決につながるかどうかをよく考えた上で作ることが大切だと思った
いつPlatform Engineeringを始めるべきか？〜レバテックのケーススタディ〜
セッション概要
- レバテックにおけるプラットフォームチーム（基盤チーム）のこれまでの変遷を辿りながら、役割の整理や組織の再編といったリアルな取り組みを紹介
共有したい点、感想等
- プラットフォームとして何を提供するかしっかりと定義する事が重要
- ストリームアラインドチームが実際に困っている事を改めて整理して、自分たちが出来ることを考えている
- 日々の運用でかつかつになっている、技術的な負債を抱えたレガシーシステムを保守している等
- 自分たちがやれることに合わせて組織を再編、ケースによってはチームを撤廃して他チームへ合流
- SREとプラットフォームチームを分けるべきか否かについては組織規模による
- チームが多すぎると動きにくくなるので2ピザチームくらいが適切
- いずれもストリームアラインドチームありきなのでその成熟度にもよる
- ストリームアラインドチームが事業に貢献できているか？もしできていないとしたら阻害要因は何かを考えるのが重要
- 上記を解決するためにプラットフォームエンジニアリングが有効なのであれば、その時が始めるタイミング
今後実施/挑戦したいこと
- 改めてストリームアラインドチームの困りごとを考える必要があると思った
- もう一度、As-Is / To-Beを関係者と話す機会を持ちたい
全体を通しての感想
- プラットフォームエンジニアリングがBuzz Wordな事もあって飛びつきたくなる状態で、改めてその必要性を考える良い機会になった
総括
以上、『Platform Engineering Kaigi 2024』に参加したメンバーのふりかえりの内容をご紹介しました。
今回のカンファレンスでは、最新のPlatform Engineeringのトレンドや実践的な事例が多数紹介され、非常に有意義な時間を過ごすことができました。特に、現地に参加したことにより、リモートでは得られないリアルタイムでの情報共有や、他社のエンジニアの皆さまとの直接的なネットワーキングの機会を得ることができました。
また、課内のメンバーで参加したことにより、単純にインプットが増えただけでなく参加者同士での情報共有や議論の場が持てたことで、理解をより深めることができたのではないかと思います。
スタッフの皆さま、登壇者の皆さま、企画運営本当にお疲れ様でした。そしてありがとうございました！
（セッション終了後の集合写真！会場も綺麗でした〜）Platform Engineering Kaigi 2024は無事に終了致しました！
— Platform Engineering Kaigi / クラウドネイティブイノベーターズ協会 (@cnia_pfem) 2024年7月9日
多くの方にご参加頂きありがとうございました！#PEK2024 pic.twitter.com/8mF8UW5Dq0
そして、来月はついに『SRE NEXT』が開催されます（今年は2Days！）。
弊社SRE課のメンバーも参加予定なので、またその様子もお伝えできればと思います！
年に1度の技術イベント「RAKUS Tech Conference」を開催します！！
今年もラクス開発本部主催の技術カンファレンス、「RAKUS Tech Conference 2024」を開催します！
「RAKUS Tech Conference」は、SaaS開発における取り組みや知見を紹介する、ラクス開発本部主催の技術カンファレンスです。 ラクス開発本部のミッションに込めた想いをエンジニア/デザイナーが生の声でお届けします。
皆さまのご参加、お待ちしております！
techcon.rakus.co.jp
