© LY Corporation © LY Corporation Public ワークロードを処理しない プラットフォームに専念する LINEヤフー株式会社 Embedded SRE @maru in Platform Engineering Kaigi 2025 1 / 25 

© LY Corporation © LY Corporation Public 「ワークロードを処理しないプラットフォーム」とは？ この発表では、以下のような区別をしています。 ワークロードを処理する Kubernetesクラスタ CI/CDのためのツール(タスクランナーやワークフローエンジン) その他、開発者やエンドユーザーのためのリアルタイム処理を必要とするもの ワークロードを処理しない ドキュメント 便利なCLI その他、利用する際にスタンドアロンで動くもの 2 / 25 

© LY Corporation © LY Corporation Public この発表で扱う内容 組織構造と働き方の観点からのプラットフォームチーム事例 プラットフォームを支援する Embedded / Enabling 型のアプローチとその成果 Embedded SRE in 横断組織のチームを運営する上でのリアルな苦悩 開発者ポータル構築やKubernetesなどの特定技術は扱いません 3 / 25 

© LY Corporation © LY Corporation Public 自己紹介 @maru 2020: LINEに入社（LINEスタンプ/着せかえ/タブのSRE） 2022: LYPプレミアム立ち上げSRE 2023: 新サービス立ち上げSRE 常にプロダクト開発のSREとして、開発チームと綿密にやりとり。 4 / 25 

© LY Corporation © LY Corporation Public この発表で使う用語の解説 主にTeam Topologiesの用語で説明します。 用語 説明 コラボレーション 相手チームと密接に協力する。まるで1つのチームのように振る舞う。 ファシリテーション 相手チームが持っていない知見や技術を導入・支援する。 コンサルタントやエヴァンジェリストに近い。 XaaS サービス・責任境界を明確にし、複数チームに低コストで横展開する。 5 / 25 

© LY Corporation © LY Corporation Public SREチームの成り立ち 私たちは元々は事業部の Embedded SREチーム 1プロダクト × 1SREで、開発者と一緒に改善していくコラボレーション型 企画担当者との会議にも同席し、新機能の仕様決定からSREとして参加する リリースやオンコールの輪番も開発チームに混じる 信頼性に関わるイシューを一緒に開発していく中で発見して改善する 2年前、これまでの活動が評価され、横断部署に異動 「もっと広い貢献」を求められる 6 / 25 

© LY Corporation © LY Corporation Public 私たちの強みと「もっと広い貢献」のギャップ 私たちの強み プロダクトと開発チームの両方に解像度が高い 1つのプロダクトに専任している 課題をヒアリングするのではなく、独自に課題を発見して解決の提案をする 1プロダクトにSREは1人だけ 勝手に改善することはできず、改善するためにも開発チームとの相談が必須 = 開発チームを置き去りにしない 広く貢献するためには...? 1プロダクト × 1SREのコラボレーションはスケールできない... 他のプラットフォームと同じようにXaaSにすると、私たちの強みが失われる... 7 / 25 

© LY Corporation © LY Corporation Public Train the Trainerによるスケーラビリティ改善 開発チーム内に育成メンバー(準SRE)を育成し、プラクティスを波紋のように伝播させる構想 SREs → 開発チームA → 開発チームB → 開発チームC... ある程度効果はあるが... 成果の可視化がしにくく、評価が難しい 効力が開発チームの活動に依存しすぎている 8 / 25 

© LY Corporation © LY Corporation Public 方向転換：Embedded + Enabling Train the Trainerは継続しつつも、チームの効力をそれだけに依存しないために 2つの取り組みをループさせる。 種類 期限 関わり方 コラボレーション (Embedded) 無期限 プロダクトチームに深く入り込む。 チーム文化・プロダクトの改善をしつつ、小さな成功事例を作る ファシリテーション (Enabling) 2-4週間 上記の小さな成功をパターン化し横展開。 同じイシューを抱える他チームの改善をサポート 9 / 25 

© LY Corporation © LY Corporation Public Embedded + Enabling -> Feedback to プラットフォーム 成功事例をパターン化する際、プラットフォームによる制約にぶつかることがある 自然とプラットフォームチームへのフィードバックも増える 成功事例の「パターン化&移植」によるチームのスケーラビリティの改善 より多くのサービスとの接点を確保 フィードバックの質向上 → プラットフォーム改善が加速 10 / 25 

© LY Corporation © LY Corporation Public プラットフォームへのフィードバックの例 複数の開発チームの具体的な課題と機能要望を伝える 開発者にとってわかりにくいドキュメントの修正や図の作成 プラットフォームのコードへのコントリビューション プラットフォームを中心としたエコシステムの開発 Terraform対応のためのTerraform Providerの開発 生成AI対応のためのMCPサーバーの開発 11 / 25 

© LY Corporation © LY Corporation Public この取り組みの理論的・体系的な位置づけ 12 / 25 

© LY Corporation © LY Corporation Public この取り組みの理論的・体系的な位置づけ Team Topologiesにおける組織的センシングの実装になっていた。 すばやく行動するには、環境に関するフィードバックセン サーが必要だ。(中略)このフィードバックセンサーの重要 な側面は、IT運用部門のチームを開発部門のチームのた めの高精度な入力センサーとして使用することだ。 （中 略)いわゆる「保守」作業のコストを最小限に抑えるため の最適化に取り組むのではなく、保守作業からのシグナル をソフトウェア開発稼働への入力として使用することが 重要だ。 引用: Chapter 8 組織的センシングでチーム構造を進化させる 13 / 25 

© LY Corporation © LY Corporation Public プラットフォームからEmbeddedへ このフィードバックが増えていくと、プラットフォームのPoCやドッグフーディングで協力できるよ うになる。 四方良し コラボレーション先:「チームに入って、実際に手を動かして改善してくれる」 ファシリテーション先:「課題解決のために他チームの成功事例を整理して支援してくれる」 プラットフォーム:「フィードバック&コントリビューションしてくれる」 私たち:「コラボレーションを強みにしつつ、スケーラビリティを確保できる」 14 / 25 

© LY Corporation © LY Corporation Public ここまでだと、 まるで良いことばかりのようだが… 15 / 25 

© LY Corporation © LY Corporation Public 実際には苦悩もいろいろ… プラットフォーム開発の誘惑 個人成果の評価の難しさ チーム活動の可視化とナレッジ継承 リーダー育成のジレンマ 長期休暇時のサポート体制 16 / 25 

© LY Corporation © LY Corporation Public 苦悩①: プラットフォーム開発の誘惑 目の前の課題を解決するために「プラットフォームを持ちたくなる」 しかし一度持つと、四方良しの根源であるフットワークの軽さを失う 移行・アップグレード・サポート・etcの運用負担が無視できなくなる 新しいツールを導入したくなった時は？ 以下のどちらかにする必要がある プロダクト開発チームがメンテナンスできる、サイロなツールとして導入 プラットフォームチームがXaaSとしてサービス化 日頃からプロダクト開発・プラットフォームとの期待値調整が重要 17 / 25 

© LY Corporation © LY Corporation Public 苦悩②: 個人成果の評価 チームを持続するためには貢献と成果を説明する必要がある Embedded + Enablingは個人技中心 → 成果が見えにくい 工夫 ステークホルダーからのフィードバックをもらう 半年に一度の360度評価 コラボレーション先のマネージャーと定期1on1 個人評価の評価軸を 「時間方向の改善 × 空間方向な改善」の二軸 で設定 Embedded先での貢献を 時間方向の改善 と定義 Enablingによる成功パターンの横展開を 空間方向の改善 と定義 18 / 25 

© LY Corporation © LY Corporation Public 二軸の定義 時間方向の改善（Embedded） 無期限で担当プロダクトに深く入り込み、時間とともに信頼性を改善 例: SLO導入、運用プロセス改善、リリース安定化 空間方向の改善（Enabling） 成功パターンを整理し、短期間で他チームに横展開 例: SLOワークショップを標準メニュー化して複数チームに提供 最低限満たすゴールは常に時間方向(Embedded)の改善、その先に空間方向(Enabling)。 実務に根ざした改善を確保し、机上の助言だけに終わらないようにする。 19 / 25 

© LY Corporation © LY Corporation Public 苦悩③: チーム内の業務可視化とオンボーディング 個人技故に「それぞれのメンバーが何をやっているのかわからない」問題 属人性が強く、新メンバーの習熟が難しい 工夫 必要経費として、チーム内共有に時間を割く 毎日1時間 sync-up meetingを行い、余った時間をmob code reviewに費やす 「ワークロードのあるプラットフォームを持たない」という制約を繰り返し強調 運用が必要なプラットフォームを持ち始めると、属人性の問題が致命的になる 新メンバーは必ず既存メンバーとBuddyを組む 私たちの活動哲学は独特なため、文化的に馴染むための時間が必要 20 / 25 

© LY Corporation © LY Corporation Public 苦悩④: リーダー育成のジレンマ メンバーは特定プロダクト内で深く狭い経験になりがち リーダーには、今回紹介したような構造を変えるための広い視点・越境経験が求められる = メンバーとリーダーで求められる知識・技能が大きく異なる 工夫 私たちの取り組みをメタ的なプラットフォームとして、XaaSの形で提供する それぞれのサービスをリーダー育成の場にする 21 / 25 

© LY Corporation © LY Corporation Public メタ的なプラットフォームとしてのSRE活動 XaaSとして提供するSREサービス 今までやっていたコラボレーションも一つのサービス ファシリテーションも短期提供のサービス 各Enablingサービスごとにオーナーを任命し、リーダー候補の育成 オーナー(次期リーダー)の主な仕事 Embedded(コラボレーション)先での小さな成功のパターン化 適用先のチームを見つけるための社内マーケティング そのパターンを他チームに適用するためのエヴァンジェリストとして活動 必要に応じてプラットフォームへフィードバック&コントリビューション 他SREメンバーをその分野のエヴァンジェリストとして教育 22 / 25 

© LY Corporation © LY Corporation Public SREプラットフォームのサービスメニュー例 サービス オーナー 期間 サービス内容 SRE Embedded Service Maru 無期限 SREがチームに参加して、信頼性の改善を行う CUJ/SLI/SLO Bootstrap Alice 4週間 CUJやSLIのワークショップ実施。 定期レビュー会議の設計と引き継ぎまで Infrastructure as Code Alice 4週間 インフラをコード管理するための準備。 ハンズオンセッションも開催 Alert Rules as Code Bob 4週間 アラートルールをコード管理するための準備。 ハンズオンセッションも開催 Kubernetes hands-on Bob 2時間 Kubernetesを学ぶセッションの開催 Terraform hands-on Bob 2時間 Terraformを学ぶセッションの開催 23 / 25 

© LY Corporation © LY Corporation Public 苦悩⑤: 長期休暇中のサポート継続 個人技への依存度が高いため、SRE一人が長期休暇に入った場合のサポートが課題になる Embedded(コラボレーション)先 原則：開発チーム側が自分たちで対応、足りない部分を他SREsが兼務的にサポート 日頃から、一緒に開発をすることでSRE依存を軽減するように注意している Enabling(ファシリテーション)先 Enablingサービスのオーナーが、サービスレベルに応じて考える これ自体がリーダー育成の一環 原則： SREチーム内教育・知識移転 によって、SREチーム内で誰かが代わりに行う 24 / 25 

© LY Corporation © LY Corporation Public 一言でまとめると Embedded → Enabling → プラットフォーム → Embeddedで四方良しを実現 Team Topologiesでいうところのセンサー組織の実装例 成功のパターン化と移植、そして評価と成果の可視化で継続可能に ワークロードがあるプラットフォームを持たない勇気が強みになることもある 「ワークロードを持たないから動ける。動けるから広げられる。 」 “ “ 25 / 25