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

■ イベント
Platform Engineering Kaigi 2026
https://www.cnia.io/pek2026/

■登壇概要
タイトル：プラットフォームを「作る」、 チームに「入り込む」
登壇者：技術本部 Platform Engineering Unit 増田圭佑

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Platform Engineering Kaigi プラットフォームを「作る」、 チームに「⼊り込む」 —両輪を⽀える「なぜやるのか」という問い— Sansan株式会社 技術本部 Platform Engineering Unit 増⽥圭佑
2. 増⽥ 圭佑（Keisuke Masuda） 技術本部 Platform Engineering Unit Application Platformグループ 2023年に新卒で⼈材系の事業会社に⼊社。toC向けのアプリケーション の開発〜運⽤までを経験。 2026年1⽉にSansan株式会社へ⼊社。内部開発者プラットフォームを 「作る」とチームに「⼊り込む」の両輪のアプローチでプロダクトチー ムの運⽤負荷最⼩化を⽬指している。
3. 本⽇お話しすること 1. 背景と課題 — 運⽤負荷における2つの側⾯ 2. 解決策とAI時代のあり⽅ — プラットフォームを「作る」とチームに「⼊り込む」 3. 事例でみる — 「作る」‧「⼊り込む」‧両輪の3パターンのアプローチ 4. まとめ
4. 背景と課題
5. 背景: 事業の急成⻑と運⽤負荷の集中 You Build It, You Run It 事業の急成⻑ 各プロダクトチームが、 開発から運⽤までを担う クラウド‧CI/CD‧監視‧セキュリ ティなど向き合う領域が拡⼤ 本来の価値創出に、集中しづらく なっていた ⽬指すべき状態 各プロダクトチームが、負荷を最⼩化しながら、⾃分たちで運⽤を回せる状態
6. 課題: 「運⽤負荷」には、2つの側⾯がある ハードスキル⾯の負荷 ソフトスキル⾯の負荷 クラウド‧IaC‧CI/CDなど → 仕組みの複雑さに向き合う負荷 SREの⽂化‧実践 → プロダクトの信頼性を 定義‧向き合う負荷 どちらか⼀⽅への打ち⼿では⾜りない
7. 解決策とAI時代のあり⽅
8. 解決策: 「作る」と「⼊り込む」の両輪 プラットフォームチームが担う 作る プロダクトチームは 価値創出に 向き合う時間が増える 仕組み化をする Platform as a Product プラットフォームとして 何を作るべきかが⾒えてくる プロダクトチームに伴走 ⼊り込む ⽂化醸成‧作った仕組みを 使えるようにする Embedded SRE この循環が運⽤負荷の本質的な最⼩化を⽣む
9. 作る: 内部開発者プラットフォームOrbit Orbit が引き受ける複雑さ 抽象化された設定 プロダクト チーム Skills で利⽤を開始 values.yaml に設定を書く 実⾏基盤 GKE上に構築を⾏い、 Namespace 単位で分離 デプロイ GitOps + Helm Chart で 複雑なリソースを隠蔽 セットアップ Google Cloud PJ / RBAC を Skills から払い出し Orbitが複雑さを引き受けることで、 プロダクトチームは価値創出に集中できる
10. ⼊り込む: Embedded SRE やること やらないこと 各プロダクトチームが⾃分たちで信頼性を 維持できるよう巻き込み、⽂化を根付かせる ‧なんでも屋になること ‧Embedded SRE ⼀⼈で問題を解決すること 部署としてEmbedded SREの役割を明確に定義している
11. AI時代に「作る」と「⼊り込む」の両輪をどう実⾏するか AIでアウトプットは速くなった。 速くなったからこそ、 「なぜやるのか」を⾶ばして、 それっぽいことができてしまう。 AI は活⽤する前提 ── 「なぜやるのか」を起点に、 プロダクトチームとどう向き合ったか
12. 事例1: 「作る」 Argo Rolloutsの導⼊
13. 要求: 段階的なリリースをしたい Helm Chart 段階的なリリースをしたい 複雑なリソースはChartの中に隠蔽 プロダクト チーム Deployment Service HTTPRoute HPA ServiceAccount Rollout values.yaml プロダクトチームは抽象化された 設定を書くだけ 抽象化したRollout 設定を追加 Rolloutリソースを追加 Argo Rollouts アウトプットは速くなった──機能が"もりもり" の Chart を提供することもできる
14. なぜやるのか Argo Rolloutsによる段階的リリースは⼿段。 実現したいことは、安全にリリースしたいこと。 つまり、使いこなせなければ意味がない。
15. やったこと: 「使いこなせるか」を確かめてから作る プラットフォームチーム 最適な⼿段を考え、 要求を元に実際のユースケースを再現 プロダクトチーム 利⽤者視点でFBを⾏う 画⾯を共有しながら「本当に使いこなせるか」をインタビュー UXリサーチャーのように要求へ向き合う
16. 結果と学び なぜやるのか起点 そのまま愚直にやる 「本当に使いこなせるか」を確かめて から、ミニマム構成で作った → 最⼩限の構成で最短に価値提供し、 利⽤者が⾃律的に運⽤可能に 「もりもり構成」を作る → 繰り返すと認知負荷が上がり、 複雑化してしまうリスク 学び：作れる速さと、使いこなせる速さは別物
17. 事例2: 「⼊り込む」 アラート対応とSLO
18. プロダクトチームに Embedded SRE として⼊る ⽉間数百万リクエストのAPIで503エラーが頻発 プロダクトチームが再現性を持って対応できるように、原因調査‧改善を推進 503 エラー率 0.1％ → 0.0008％ 数字は、動いた。けれど──
19. なぜやるのか 「0.0008％」は、本当に必要なのか。 このプロダクトはどの⽔準で信頼性を維持するのか。 誰も、答えられなかった。
20. やったこと: 信頼性に対する共通⾔語を持つ Embedded SRE きっかけづくり SLO策定を提案し、 特に守りたいユーザー体験を ⾔語化するワークを実施 プロダクトチーム Embedded SRE 決定 レビュー SLIの選定‧計測はメンバーが 決める レビューに⼊り ガードレールになる 全てを肩代わりしない ── チームが⾃律的に扱えるようにする
21. ⼊り込むで⼤切なこと 課題と紐付けて、全員を巻き込み推進する 503エラーという⽬の前の課題を、「何を守るべきか」という問いに変換して プロダクトチームが⾃分ゴトとして捉えやすい形にする 「書籍に書いてあるからやる」ではない プラクティスを参考にしつつも「今の⾃分たちの技術‧組織‧事業にとって何が最適か」を思考する この勘所は、AI にはわからない
22. そして、「⼊り込む」はExitする ⼊り込む Embedded SRE として伴⾛ 質問 カバレッジ状態 保持者 初動対応を実⾏できる カバー済み A さん、C さん Cloud Logging で原因特定できる カバー済み B さん メトリクスで異常検知できる カバー済み C さん OpenTelemetry を理解している 部分カバー D さん Pod のログを確認できる カバー済み A さん、B さん ⼊り込みは、終わらせて次の価値創出へ向かうもの 参考：SRE Kaigi 2026「Embedded SREの終わりを設計する」 Exit また次の 価値創出へ
23. 結果と学び なぜやるのか起点 そのまま愚直にやる 「誰のための数字か」を問い直し、 SLO という共通⾔語を策定 → プロダクトチームが信頼性について ⾃分ゴトとして捉えるように 503エラー率を下げるという指⽰を そのまま遂⾏ → 数字は動いたとしても、 誰にどう繋がるのかわからない 学び：1⼈で数字は動かせても、守るべき⽔準は、チームでしか決められない
24. 事例3: 「作る」と「⼊り込む」の両輪 アラート調査エージェント
25. ⼊り込んで得た、違和感 暗黙知 A さん アラート調査のコツを持っている アラートが発⽣ B さん わからない C さん わからない このままでは、アラート調査が組織としてスケールしない
26. なぜやるのか この違和感は、⼊り込んでいる プロダクトの中だけの問題か。 ⽬の前で解くのではなく、プラットフォームとして 「作る」で解くべきではないか。
27. やったこと: 個別課題か、共通課題かを⾒極める 仮説を立てる インタビュー プラットフォームで 解くべきではないか 解決策のコンセプトを 添えて複数チームへ 課題を確認 同様の課題が他チームにも 作る プラットフォームとして 提供を決断 重要なのは「暗黙知」を扱えるか ── 汎⽤的な調査だけなら、提供価値は少ない
28. 作る: Slack のスレッド上で調査が完結する仕組み アラート発報 ① アラート調査エージェント をメンション ② MCP経由で調査 アラート調査エージェント プロダクトチーム側で設定 カスタムSkill（暗黙知の注⼊） Cloud Monitoring アラート Slack スレッド 参照先の権限 Google Cloud プラットフォーム側で⽤意 Session Model 標準調査 Skill MCP ③ Slackスレッドに調査結果を報告 （以降同⼀スレッドで深掘り可能） プロダクトチームが注ぐのは、暗黙知と参照先の閲覧権限だけ 共通部分はプラットフォームが引き受ける
29. アラート調査エージェントは銀の弾丸ではない エージェントが担うこと ⼈にしかできないこと ‧原因の当たりを、すぐにつける ‧そもそも、アラートにすべきことか ‧調査を⾼速化する ‧どういった時に、ユーザー‧事業に 影響があるか ⼈が思考するからこそ、エージェントは活躍できる だからこそ、「⼊り込む」存在が重要であり続ける
30. 結果と学び なぜやるのか起点 そのまま愚直にやる ⼊り込んで得た解像度から、 プラットフォームとして提供する 意思決定 → 2件のプロダクトで先⾏提供中 ⽬の前のチームにだけ個別最適 → 同様の課題を⾒逃してしまい、 組織としてスケールしない 学び:⼊り込んで得た解像度が、何を作るべきかの意思決定を⽀える
31. まとめ
32. 3つの事例は、すべて同じ問いを起点にしていた 事例1「作る」 なぜ、やるのか？ 誰のための機能か 事例2「⼊り込む」 なぜ、やるのか？ どの⽔準で 維持するのか 事例3「両輪」 なぜ、やるのか？ どこで解くべき課題か
33. 両輪を回した結果、いまどこにいるか 作る ⼊り込む 2⽇以内 15チーム 5チーム Orbit利⽤までの時間 利⽤チーム数 ⼊り込んだチーム数 Exit 済み 従来⽐ -50% 前年⽐ 約7倍 累計 ⾃⾛へ移⾏ 両輪の結果 7.9件 70% １ヶ⽉の管理者への平均問い合わせ件数 NPS 推奨者率 前年⽐16%増 n=10 ※ 本セッションの事例を含む、Platform Engineering Unit としての取り組みの結果 2チーム
34. まとめ 「作る」と「⼊り込む」の両輪でアプローチする プロダクトチームが、運⽤負荷を最⼩化しながら、⾃分たちで運⽤を回せる状態をつくるため その⼿前で、「なぜやるのか」を起点に置く 要求や指⽰をそのまま実⾏する前に⼀度⽴ち⽌まり、その先に誰がいて、何を守りたいのかを確認する
35. Sansan 技術本部 採⽤情報 https://media.sansan-engineering.com/