マイクロサービス以外（例えばフロントエンド領域など）で提供しているプラットフォームはありますか？
あります．今回の自分のセッションは主にBackendのマイクロサービスに特化した話でした (Backendのプラットフォームが特に大きいので) が，社内には他にもWeb frontend開発のためのWeb Platform，iOS/AndroindのためのMobile Platformがあります．他にもData warehouseやそのためのPipelineなどを管理するData PlatformやA/B testingのためのExperimentaion Platform，MLのためのML Platformなどなど特化した基盤が存在しています
メルカリは人の入れ替わりが激しいイメージがあるのですが新しく入られた人がすぐプラットフォーム全容を理解できるようにするための工夫、オンボーディングなどどのようなものがありますか？
あります．そもそも全体のオンボーディングとしてDev Dojoという仕組みがあって，Platformに限らず会社全体のエンジニアリングについて学べるトレーニングが存在しています．もちろんPlatformチームが提供している専用のドキュメントサイトも存在しており，そこでも一通りオンボーディングが可能なコンテンツが存在しています．一応直近のDeveloper Surveyとかをみると，新しくチームに配属されて2-3日で何かしら本番にコードをデプロイするということはできてるというのは見えてるので，過度に利用のコストが高いというのはなさそうと見ています．
小規模のチームでPlatform Teamを立ち上げるにはどうしたらいいでしょうか。
僕らも最初は2-3人で始めています．やれること，優先度が高そうなところにどんどん突っ込んでいくしかないと思います．コラボレーションからやるべきという話をしましたが，一緒に貢献できそうなプロジェクトを見つけてとにかく始めるしかないかなと思います．例えば，僕らの本当に一番最初はマイクロサービスの移行ではなくて，新しく作り始めたMLのサービスを既存のシステムのサブシステムとして動かせるようにするというところから始めてます(それがまず始められることだったので)．そんな感じで実績を積みながら，仕組みを徐々に整えて，発表でも話した出品機能の移行に向かっていくことになります
メルカリが Platform Enginneringを進めるにあたり一番苦労されたこととどう解決されたのかについて教えていただけますでしょうか。
初期で一番苦労したのはDevOps的な考え方を浸透させることだと思います．今となっては結構普通になりつつありますが，当時は開発チームが本番の運用まで関わるってのは全然普通ではなかった．特にオンコールをやりますとか．中でも話したようにマイクロサービスとしてこういうビジョンがあります，それを達成するにはこういう新しい体制が必要であるってのを粘り強くコミュニケーションし続けるしかなかったです．
一つ目のX-as-a-Serviceを構築した後に次の柱を探すのはどの様に行なっていきましたか？
立ち上げのときの話だとすると，初期は足りない機能しかないし，コラボレーションで一緒にやってれば，優先度も結構すぐに見えてくると思います．
Platformチームはエンジニア組織全体に対してどのくらいの規模ですか？人数を決める上での指針は何かありますか？
これは一般的にも言われてるんですが全体のエンジニアリングの人数に対して20%と言われています (getDXからレポートが出ています)．最近はわからないですがUberが1/10, Stripeが1/5ってのを見たこともあります．で比率的には規模が大きくなるほど一般的には小さくなるようです．例えば1000+名規模だと12%とか．とはいえあくまでこれらはベンチマークとして考えて自分らが作ってるもの組織によってかわるものくらいで考えた方がいいと思います
Platform team を分離することで生まれたデメリットはなかったでしょうか？
中でも軽く触れましたがやはりサイロ化は大きな問題でした．もちろんサイロ化は狙ってやっていてそれによってプロジェクトの並列度を上げて全体としてのアウトプットの量は高まったと思うんですが、プラットフォーム全体からみた改善ってのは進められなかったなあと．なので，あくまでチームは専門性とコンポーネントのオーナーシップとしてみて，プロジェクトの構成はもうちょっと全体視点から構成するみたいなのがあってもよかったなあと (これはマイクロサービスのチームでもやったらよかったかなと)
ソフトウエアライフサイクル全体をプラットフォーム化する場合、信頼性専門のSRE、品質専門のQAとも連携が必要になったのだと思いますがどのように取り組まれましたか
おっしゃる通りでQAチームやSREチームとの連携はとても重要です．特にSREチームはメルカリの場合は明確にPlatform Engineeringチームとは分けていて異なるミッションを持っています．ちょっと抽象的になりますが，全体の80%の自動化可能な問題を解決するのがPlatformで，残りの20%のよりドメインやビジネスに特化した複雑な課題に取り組むのがSREという，イメージを持っています．組織的にはSREチームはPlatformチームとProductチームの間にいて，ProductチームにEmbeddedして直接サポートをするといったことをしています．
CxOやVPのレイヤーで「プラットフォーム関連への投資が過剰ではないか？」をどう判断してアクセル/ブレーキしていますか？
人的な投資だとすると上の「組織規模におけるPlatformの規模」が一部回答になってるとは思います．他社のベンチマークを参考しつつ，どれだけPlatform Engineering領域に人を当てるべきか，とう議論が行われています
Platform DX チームの考えなどとても良いと思ったのですが、組織のレイヤーが増えるとプロダクトのアジリティが下がるという現象が発生するように思えます。この辺りに課題はなかったでしょうか。
自分のスライドの表現が良くなったかもしれないが，概念的にはインターフェースですが，組織上は他のチームとフラットで，レイヤーを増やしたわけではないです．Platform DXチームとしてなるべく他のチームが使えるようなフレームワークを作ろうとはしています (例えばKubernetesの設定を抽象化するためのフレームワークをつくり、CI/CDチームがそれを使いDeliveryの機構と連携できるようにする) が，ツールの公開時には毎回Platform DXチームを巻き込む必要がありスピードに影響を与えたということは起こっています．なのではやりフレームワーク化が重要かなと
CIツール等の移行はどのように進めましたか？呼びかけても中々移行してくれないことが多いと思いますが。
簡単には応じてくれないですね．とはいえこういったPlatformの移行を組織としてやっていくようにはなっていて，全社Engineering OKRとして進めています．CIの移行は特にセキュリティに関わることでもあるので、この全社Engineering OKRを設定して半年以上くらいかけて移行を完了させました．もちろん全部ぶん投げたわけではなくてCI/CDチームは移行ツールをつくったり、移行のサポートを全面にするといったことをしました
弊社でもプロダクトチームのインタフェースとなるPlatformのサブチームを組成しているのですが、当該チームがプロダクトの追加に伴い人数もスケールしています。システムの規模に応じて人が増えている状況で、あまり持続可能性がないように考えているのですが、この課題は発生していますか？
発生していないですね．むしろ人は少ないです．いわゆるアーキテクトにも近いチームだと思っていて，シニアかつ他のPlatformを分かってるメンバーしか入れないようにはなってるので．上でも書きましたがあくまでドキュメントやツールの抽象化などのフレームワークを作り，他のチームがそれを使って機能を提供できるように，ということをしているので，プロダクトが増えるごとに人を増やさなくても良いようにはなってるとは思います
インターフェースチーム、プラットフォームが少ない時にどこまで重視するか悩ましいなと思っています。仮にプラットフォームが2個の時はどれくらい重視すべきだと思いますか？
2チームの場合はあえてチームを作る必要はないとは思いますが，そういう役割のひと，全体の統一感をコントロールできるひと，を置いても良いかなと思います．ちなみに僕らの場合は最初2人だけ始めました．
Platform へのサービスレベル要求が事業サービスごとに異なることはなかったでしょうか？特定の事業サービスの要求が高すぎて、Platform の変更や変更失敗に関して困ることはありませんでしたか？
ありました．例えばメルペイは金融事業なのでメルカリとは求められるセキュリティレベルが異なりました．ただそのセキュリティはメルカリでも価値がある，やる必要がある，のでそれを実施していくことは問題なかったと思います．PlatformというよりプロダクトレベルだとMonotlihへの依存がいくつかの事業から発生しているのでそれが原因で全体に影響がってのはいまだに起こってるのでどうにかしたいですね
統一した1つのプラットフォームを作るのって大変そうです。シングルプラットフォームのツラさを上回るメリットは何ですか？
Single Platformのメリットとしてはまず人のアサインが最適化されると思います．Platformを別々につくるとして，事業ごとに同じようなものをつくるために，同じようなスキルセットを持っているひとを分散してアサインしないといけないのって無駄すぎるのでは? と自分は思います．人が分散されてる分深い改善，例えばCIをSelf hostedに切り替えて運用するみたいなことまで手を回せないのでは? と思います．Platformを共通にしておくとその改善が組織全体に行き渡るってもの良い点だと思います．例えば，CIシステムができたときにそれを皆で使える，Kubernetesの抽象化のフレームワークを使える，などなど
Platform TeamのQAや保守フェーズについて、その体制や取り組みを教えて欲しいです。例えばマイクロサービスを立ち上げるツールキットはマイクロサービスの新規立ち上げ機会が少ないと腐りやすいように思っていて、いざ使おうと思ったら動かないといった状況を避けるための取り組みはありますか？
ある程度作ったものは移行するまでやってるので、中途半端に使われて放置されて腐ってるものは少ないとは思っています．使われているので継続的に保守がされています．質問にあるマイクロサービスを立ち上げるツールキットもありますが、僕らの場合は立ち上げだけではなくて、継続的に全てのサービスが持つべき設定や仕組みを導入するためのツールになっていて (例えば、新しいDeliveryツールを作ったらそのツールで有効にする、セキュリティ的な設定を追加するなど) 立ち上げだけではなくて継続的に更新され、かつバージョンの追従をしてもらってるツールになっています (なるべく自動でバージョンを上げていく仕組みもある)．それだけではなくてマイクロサービスもいまだにどんどん作られてますね．Single Platformとして新規事業を取り込んでいるのが大きいのかもしれません．
プラットフォームを維持していくコストと開発するコストをどうやってバランスとっていますか？
定式はないので難しいですが、自分達としてやりたいこと vs. 利用者から要求されていること，今すぐやるべき vs. 長期的にやるべき，という軸を考えて，それらでバランスを取ってると思います．例えば要求されてて緊急度が高いものはやるしかない．時期によっても違うと思います．
レガシーシステムの開発者から移行にコスト（稼働）を払いたくないという反対意見言われた経験があるのですが、そのようなことはなかったのでしょうか。ない場合どのような組織文化がそれを可能にしたと思われますか
いまのところない，とは思っています．明確に新規に移動することにメリットがあったから，例えば同じツールで開発できる，オートスケールでコストの最適化ができる，などなど．上でも回答していますが，Engineering OKRとして移行をちゃんとやるってのを続けているのも，プラスには働いているとは思っています
パッと見ですが、プラットフォームがTVPから遠いように見えました。TVP目線で課題感あったりしますか？また、サービス削除等はどれぐらいされたことがありますか？
Thinではないですね．古いものや一つのツールで吸収できるものは消していってると思います．あとは消すというよりは新しいものに置き換えるということも続けています
single platformが足枷になった事例はありますか？
自分の観点では今のところないです．むしろ逆に全然違う基盤を別途立ててその運用に苦戦してしまっている例があります (Single Platformに載せるプロジェクトをやっている)．会社によって違うかもしれないですが，メルカリみたいにいろんな事業とどんどん立ち上げる，やめるときはやめる，ということをやる会社だとSingleのがあってると思います．
モノレポ vs マルチレポ戦略を考えたとき、Platform Engineeringの視点から見たときのそれぞれのメリデメ、それを踏まえてメルカリではどちらの方針を取ろうとしているなどありますか？
monorepo vs. polyrepoはいろいろ議論がありますね… これは組織文化によっても変わってくると思います．前者は標準化思考で後者は自由度思考といったところですかね．メルカリのMicroservicesは基本的にはPolyrepoで進んできましたが，長年運用してきて本当に大変です．いろんな設定を全てのサービスに共通で導入したいことは何度もあって，polyrepoでそれをやるのはとにかくコミュニケーションをやり続けないといけないので大変すぎます．今からやるならマイクロサービス自体やめた方がいいと思いますが、やるならかなり強い共通化・標準化でやるべきで、そういった仕組みをつくるならmonorepoの方がやりやすいと思います (なので流れ的には monolith → modular monotlih → monorepo microservices → polyrepo microservicesでやるべきで最後は本当に例外だけやるみたいなのが良いかなと) ．Monorepoをやって価値があるのはMonorepoの仕組みをちゃんと作って運用できるチーム = platform engineering的なチーム を配置できるときだと思うので，やるならそういうチームをちゃんと持つべきだと思います．