Upgrade to Pro — share decks privately, control downloads, hide ads and more …

実録・Platform Engineering 失敗から学び、AI時代の波を乗りこなす技術

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.
Avatar for SansanTech SansanTech PRO
February 25, 2026

実録・Platform Engineering 失敗から学び、AI時代の波を乗りこなす技術

■ イベント
Sansan Tech Talk @関西 〜大阪からプロダクトを牽引する!技術とカルチャーのリアル〜
https://sansan.connpass.com/event/381322/

■ 発表者
技術本部 Platform Engineering Unit
辻田 美咲

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

Avatar for SansanTech

SansanTech PRO

February 25, 2026
Tweet

More Decks by SansanTech

Other Decks in Technology

Transcript

  1. 辻⽥ 美咲 Sansan株式会社 Platform Engineering Unit Application Platform Group 新卒でバックエンドエンジニアとしてキャリアをスタート。

    フロントエンド、クラウドインフラ領域などの経験を積み、 2021年にSansanに⼊社。 現在は関⻄⽀店でPlatformエンジニアとして全社横断 Platform Orbitの開発およびプロダクトマネジメントに 従事している。
  2. Orbitとは? 開発者が本質的な課題(エンドユーザーに 価値を提供するための開発作業)に 取り組む時間を最⼤化することを⽬的として 構築された、コンテナアプリケーションの 実⾏基盤。 Google Kubernetes Engine (GKE)

    Autopilot を中核技術として採⽤しており、CI/CD、 監視、セキュリティ、ネットワーク設定などを 「Golden Path(舗装された道路)」として 統合的に提供する。
  3. 「インフラ専任エンジニアの不在」が招いた運⽤の限界 幅広い領域の専⾨知識が必要となり、認知負荷が増⼤ Orbit誕⽣の背景 ✕ 乖離 実環境と Terraform の定義に乖離 ✕ 意識の希薄化

    セキュリティやコストへの意識不⾜ ✕ 管理不⾜ 監視ダッシュボードが疎かになる ✕ 属⼈化 CI/CD パイプラインの ブラックボックス化 詳細:「その開発、認知負荷⾼すぎませんか?」Platform Engineering で始める開発者体験カイゼン術
  4. これまでのタイムライン 2024/08 2024/09 2025/01 2025/02 2024 2025/01 2026 Platform Engineering

    Jump Start に参加 Platform 開発開始 実運⽤開始 利⽤チーム数 1→7へ成⻑
  5. Success 1: 抽象化とテンプレート Webアプリ Template K8sのベストプラクティス を内包したHelm Chart。 複雑なマニフェスト管理 を隠蔽。

    10個ほどのマニフェスト ファイル 1つのvalues.yaml CI/CD Template セキュリティスキャン、 ビルド、デプロイの フローをGitHub Actions のReusable workflowsで 共通化。 Terraform Modules IAMやアラート設定を抽象 化。数百⾏のHCL 数⼗⾏のmodule呼び 出し 成果: デプロイ頻度の向上、リードタイムの削減、セキュリティレベルの均⼀化
  6. “社内エンジニアを「顧客」として定義する” 1. ユーザの声を聞く a. インタビュー、アンケート、オフィスアワーの徹底 b. Embedded SRE i. 個別チームに深く⼊り込んで直接⽀援

    2. 論理的な優先順位 a. 専任 PdM を置き、全体最適に基づいたロードマップ策定 b. ビジョンステートメントの策定 3. エンゲージメント強化 a. ランチ会やフォローアップ定例による信頼関係 Success 2: Platform as a Product 3.5 X 利⽤チーム数の伸び(FY18 -> FY19) Google Cloud 利⽤時の デファクトスタンダード化を 推進
  7. Failure 1: 技術的制約 Autopilot 特有の制限 特権コンテナ(privileged: true)が 利⽤できない、動的リソース割り当て (DRA)が使えない、など Googleがノード管理を完全に引き受ける

    が、その引き換えに様々な制約が存在。 対策: 1. 特権モードが必要な特殊ワークロードはGKE 外で実⾏。GKE 上で動作しているかどうかは、 ユーザの関⼼事ではない。 2. MIG(multi-instance GPUs)でGPUを効率的に 使⽤し、カスタムComputeClassでSpot インスタンスの優先利⽤することでコスト効率 的を最適化 Gateway Controllerでの IAP 権限設定が不便 IAPの有効化⾃体はマニフェストで 可能だが、Backend Serviceの名前が ⽣成されるまで不明なため、IAM権限を 事前に定義できない。これにより、 リソース作成後にIAM設定を⾏う必要が ⽣じ、作業のタイムラグが発⽣。 対策: Google Cloud さんに機能リクエストは出しつつ、 ⾃分たちでカスタムコントローラーを実装すること を検討中。
  8. Failure 2: 初期構築の複雑さ ⾼度な機能統合により、 設定が複数リポジトリに分散 - Google Cloud プロジェクト管理 -

    リポジトリ管理 - Argo CD Application 管理 - アプリケーション⽤ k8s マニフェスト管理 開発者の声 Q. Orbitは使いやすいですか? 50%以上 :「どちらともいえない」
  9. Platform Engineering × AI AI Agent による “⾃⼰解決” → セルフサービスの推進

    開発チーム Orbit ⼤量のドキュメント&⼿作業 やりたいこと / 知りたいこと を伝えるだけ Orbit AI Agent 開発チーム Orbit