プラットフォームを「作る」、チームに「入り込む」

by SansanTech

Embed

Start on current slide

Slide 1

Slide 1 text

Platform Engineering Kaigi プラットフォームを「作る」、チームに「⼊り込む」 —両輪を⽀える「なぜやるのか」という問い— Sansan株式会社技術本部 Platform Engineering Unit 増⽥圭佑

Slide 2

Slide 2 text

増⽥圭佑（Keisuke Masuda）技術本部 Platform Engineering Unit Application Platformグループ 2023年に新卒で⼈材系の事業会社に⼊社。toC向けのアプリケーションの開発〜運⽤までを経験。 2026年1⽉にSansan株式会社へ⼊社。内部開発者プラットフォームを「作る」とチームに「⼊り込む」の両輪のアプローチでプロダクトチームの運⽤負荷最⼩化を⽬指している。

Slide 3

Slide 3 text

本⽇お話しすること 1. 背景と課題 — 運⽤負荷における2つの側⾯ 2. 解決策とAI時代のあり⽅ — プラットフォームを「作る」とチームに「⼊り込む」 3. 事例でみる — 「作る」‧「⼊り込む」‧両輪の3パターンのアプローチ 4. まとめ

Slide 4

Slide 4 text

背景と課題

Slide 5

Slide 5 text

背景: 事業の急成⻑と運⽤負荷の集中 You Build It, You Run It 事業の急成⻑各プロダクトチームが、開発から運⽤までを担うクラウド‧CI/CD‧監視‧セキュリティなど向き合う領域が拡⼤本来の価値創出に、集中しづらくなっていた⽬指すべき状態各プロダクトチームが、負荷を最⼩化しながら、⾃分たちで運⽤を回せる状態

Slide 6

Slide 6 text

課題: 「運⽤負荷」には、2つの側⾯があるハードスキル⾯の負荷ソフトスキル⾯の負荷クラウド‧IaC‧CI/CDなど → 仕組みの複雑さに向き合う負荷 SREの⽂化‧実践 → プロダクトの信頼性を定義‧向き合う負荷どちらか⼀⽅への打ち⼿では⾜りない

Slide 7

Slide 7 text

解決策とAI時代のあり⽅

Slide 8

Slide 8 text

解決策: 「作る」と「⼊り込む」の両輪プラットフォームチームが担う作るプロダクトチームは価値創出に向き合う時間が増える仕組み化をする Platform as a Product プラットフォームとして何を作るべきかが⾒えてくるプロダクトチームに伴走⼊り込む⽂化醸成‧作った仕組みを使えるようにする Embedded SRE この循環が運⽤負荷の本質的な最⼩化を⽣む

Slide 9

Slide 9 text

作る: 内部開発者プラットフォームOrbit Orbit が引き受ける複雑さ抽象化された設定プロダクトチーム Skills で利⽤を開始 values.yaml に設定を書く実⾏基盤 GKE上に構築を⾏い、 Namespace 単位で分離デプロイ GitOps + Helm Chart で複雑なリソースを隠蔽セットアップ Google Cloud PJ / RBAC を Skills から払い出し Orbitが複雑さを引き受けることで、プロダクトチームは価値創出に集中できる

Slide 10

Slide 10 text

⼊り込む: Embedded SRE やることやらないこと各プロダクトチームが⾃分たちで信頼性を維持できるよう巻き込み、⽂化を根付かせる ‧なんでも屋になること ‧Embedded SRE ⼀⼈で問題を解決すること部署としてEmbedded SREの役割を明確に定義している

Slide 11

Slide 11 text

AI時代に「作る」と「⼊り込む」の両輪をどう実⾏するか AIでアウトプットは速くなった。速くなったからこそ、「なぜやるのか」を⾶ばして、それっぽいことができてしまう。 AI は活⽤する前提 ── 「なぜやるのか」を起点に、プロダクトチームとどう向き合ったか

Slide 12

Slide 12 text

事例1: 「作る」 Argo Rolloutsの導⼊

Slide 13

Slide 13 text

要求: 段階的なリリースをしたい Helm Chart 段階的なリリースをしたい複雑なリソースはChartの中に隠蔽プロダクトチーム Deployment Service HTTPRoute HPA ServiceAccount Rollout values.yaml プロダクトチームは抽象化された設定を書くだけ抽象化したRollout 設定を追加 Rolloutリソースを追加 Argo Rollouts アウトプットは速くなった──機能が"もりもり" の Chart を提供することもできる

Slide 14

Slide 14 text

なぜやるのか Argo Rolloutsによる段階的リリースは⼿段。実現したいことは、安全にリリースしたいこと。つまり、使いこなせなければ意味がない。

Slide 15

Slide 15 text

やったこと: 「使いこなせるか」を確かめてから作るプラットフォームチーム最適な⼿段を考え、要求を元に実際のユースケースを再現プロダクトチーム利⽤者視点でFBを⾏う画⾯を共有しながら「本当に使いこなせるか」をインタビュー UXリサーチャーのように要求へ向き合う

Slide 16

Slide 16 text

結果と学びなぜやるのか起点そのまま愚直にやる「本当に使いこなせるか」を確かめてから、ミニマム構成で作った → 最⼩限の構成で最短に価値提供し、利⽤者が⾃律的に運⽤可能に「もりもり構成」を作る → 繰り返すと認知負荷が上がり、複雑化してしまうリスク学び：作れる速さと、使いこなせる速さは別物

Slide 17

Slide 17 text

事例2: 「⼊り込む」アラート対応とSLO

Slide 18

Slide 18 text

プロダクトチームに Embedded SRE として⼊る⽉間数百万リクエストのAPIで503エラーが頻発プロダクトチームが再現性を持って対応できるように、原因調査‧改善を推進 503 エラー率 0.1％ → 0.0008％数字は、動いた。けれど──

Slide 19

Slide 19 text

なぜやるのか「0.0008％」は、本当に必要なのか。このプロダクトはどの⽔準で信頼性を維持するのか。誰も、答えられなかった。

Slide 20

Slide 20 text

やったこと: 信頼性に対する共通⾔語を持つ Embedded SRE きっかけづくり SLO策定を提案し、特に守りたいユーザー体験を⾔語化するワークを実施プロダクトチーム Embedded SRE 決定レビュー SLIの選定‧計測はメンバーが決めるレビューに⼊りガードレールになる全てを肩代わりしない ── チームが⾃律的に扱えるようにする

Slide 21

Slide 21 text

⼊り込むで⼤切なこと課題と紐付けて、全員を巻き込み推進する 503エラーという⽬の前の課題を、「何を守るべきか」という問いに変換してプロダクトチームが⾃分ゴトとして捉えやすい形にする「書籍に書いてあるからやる」ではないプラクティスを参考にしつつも「今の⾃分たちの技術‧組織‧事業にとって何が最適か」を思考するこの勘所は、AI にはわからない

Slide 22

Slide 22 text

そして、「⼊り込む」はExitする⼊り込む Embedded SRE として伴⾛質問カバレッジ状態保持者初動対応を実⾏できるカバー済み A さん、C さん Cloud Logging で原因特定できるカバー済み B さんメトリクスで異常検知できるカバー済み C さん OpenTelemetry を理解している部分カバー D さん Pod のログを確認できるカバー済み A さん、B さん⼊り込みは、終わらせて次の価値創出へ向かうもの参考：SRE Kaigi 2026「Embedded SREの終わりを設計する」 Exit また次の価値創出へ

Slide 23

Slide 23 text

結果と学びなぜやるのか起点そのまま愚直にやる「誰のための数字か」を問い直し、 SLO という共通⾔語を策定 → プロダクトチームが信頼性について⾃分ゴトとして捉えるように 503エラー率を下げるという指⽰をそのまま遂⾏ → 数字は動いたとしても、誰にどう繋がるのかわからない学び：1⼈で数字は動かせても、守るべき⽔準は、チームでしか決められない

Slide 24

Slide 24 text

事例3: 「作る」と「⼊り込む」の両輪アラート調査エージェント

Slide 25

Slide 25 text

⼊り込んで得た、違和感暗黙知 A さんアラート調査のコツを持っているアラートが発⽣ B さんわからない C さんわからないこのままでは、アラート調査が組織としてスケールしない

Slide 26

Slide 26 text

なぜやるのかこの違和感は、⼊り込んでいるプロダクトの中だけの問題か。⽬の前で解くのではなく、プラットフォームとして「作る」で解くべきではないか。

Slide 27

Slide 27 text

やったこと: 個別課題か、共通課題かを⾒極める仮説を立てるインタビュープラットフォームで解くべきではないか解決策のコンセプトを添えて複数チームへ課題を確認同様の課題が他チームにも作るプラットフォームとして提供を決断重要なのは「暗黙知」を扱えるか ── 汎⽤的な調査だけなら、提供価値は少ない

Slide 28

Slide 28 text

作る: Slack のスレッド上で調査が完結する仕組みアラート発報 ① アラート調査エージェントをメンション ② MCP経由で調査アラート調査エージェントプロダクトチーム側で設定カスタムSkill（暗黙知の注⼊） Cloud Monitoring アラート Slack スレッド参照先の権限 Google Cloud プラットフォーム側で⽤意 Session Model 標準調査 Skill MCP ③ Slackスレッドに調査結果を報告（以降同⼀スレッドで深掘り可能）プロダクトチームが注ぐのは、暗黙知と参照先の閲覧権限だけ共通部分はプラットフォームが引き受ける

Slide 29

Slide 29 text

アラート調査エージェントは銀の弾丸ではないエージェントが担うこと⼈にしかできないこと ‧原因の当たりを、すぐにつける ‧そもそも、アラートにすべきことか ‧調査を⾼速化する ‧どういった時に、ユーザー‧事業に影響があるか⼈が思考するからこそ、エージェントは活躍できるだからこそ、「⼊り込む」存在が重要であり続ける

Slide 30

Slide 30 text

結果と学びなぜやるのか起点そのまま愚直にやる⼊り込んで得た解像度から、プラットフォームとして提供する意思決定 → 2件のプロダクトで先⾏提供中⽬の前のチームにだけ個別最適 → 同様の課題を⾒逃してしまい、組織としてスケールしない学び:⼊り込んで得た解像度が、何を作るべきかの意思決定を⽀える

Slide 31

Slide 31 text

まとめ

Slide 32

Slide 32 text

3つの事例は、すべて同じ問いを起点にしていた事例1「作る」なぜ、やるのか？誰のための機能か事例2「⼊り込む」なぜ、やるのか？どの⽔準で維持するのか事例3「両輪」なぜ、やるのか？どこで解くべき課題か

Slide 33

Slide 33 text

両輪を回した結果、いまどこにいるか作る⼊り込む 2⽇以内 15チーム 5チーム Orbit利⽤までの時間利⽤チーム数⼊り込んだチーム数 Exit 済み従来⽐ -50% 前年⽐約7倍累計⾃⾛へ移⾏両輪の結果 7.9件 70% １ヶ⽉の管理者への平均問い合わせ件数 NPS 推奨者率前年⽐16%増 n=10 ※ 本セッションの事例を含む、Platform Engineering Unit としての取り組みの結果 2チーム

Slide 34

Slide 34 text

まとめ「作る」と「⼊り込む」の両輪でアプローチするプロダクトチームが、運⽤負荷を最⼩化しながら、⾃分たちで運⽤を回せる状態をつくるためその⼿前で、「なぜやるのか」を起点に置く要求や指⽰をそのまま実⾏する前に⼀度⽴ち⽌まり、その先に誰がいて、何を守りたいのかを確認する