Sansanが実践する Platform EngineeringとSREの協創

■ イベント
Platform Engineeringの進め方とコミュニケーション ～組織の壁への向き合い方～
https://findy.connpass.com/event/375302/

■ 発表者
技術本部 Platform Engineering Unit
水谷 高朗

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

Transcript

1. Sansan株式会社 技術本部 Platform Engineering Unit ⽔⾕⾼朗 Sansanが実践する Platform EngineeringとSREの協創 ag-ui adk [Error [SocketError]: other side closed]
2. ⽔⾕ ⾼朗 Platform Engineering Unit Application Platform Group 2014年 Sansan株式会社⼊社 名刺データ化部⾨のインフラエンジニアとして オンプレミスからPublic Cloudへの移⾏、RDBMS、 全⽂検索エンジンの最適化に従事しながら、 新規事業のインフラエンジニアを担当 2024年Platform Engineering Unitの⺟体となる部⾨で SRE組織の起ち上げを担当 2025年6⽉より現職
3. © Sansan, Inc. Sansanについて 本社 神山ラボ 経理DXサービス 取引管理サービス 名刺アプリ ビジネスデータベース
4. © Sansan, Inc. Platform Engineering Unit アプリケーション基盤 App Platform Group 認証基盤 Identity Platform Group 今⽇は こっちの 話
5. © Sansan, Inc. - Sansanのサービスが急成⻑ - エンジニア組織は急には成⻑しない - 結果として1名のインフラエンジニアが5つの新規事業の基盤構築を担うが 実質的な運⽤は開発者がおこなっていた しんどい⽅向にいった「You Build It, You Run It」 認知負荷が⾼まりすぎて、 機能開発に集中できない。
6. © Sansan, Inc. そこで Platform Engineering Platform Engineeringとは？ 開発者がセルフサービスで利⽤できる、 信頼性の⾼いプラットフォームを 提供する取り組み ⽬的 開発者の認知負荷を下げ、 開発者体験 (DX) を向上させる Point ツール導⼊が⽬的ではない。
7. 機能豊富なツールを並べただけでは、Platformではない。 - 使い⽅が難しい（学習コストが⾼い） - ドキュメントが古い、読みにくい - 「これを使え」という強制感が強い よくある失敗 Platformは「社内向けプロダクト」として扱う必要がある
8. 社内向けプロダクトとしてOrbitが誕⽣ Thinnest Viable Platform (TVP) 最初から全部盛りにしない。最⼩限の価値から。
9. - 予算の確保 - まずはPoCということで始めた - Platform Engineering知らない状態 - Google CloudさんのPlatform Engineering Jump Startという ワークショップに参加しPlatform Engineeringのベストプラクティス を学びました 誕⽣の前にしたこと
10. - 同じ部署の既存プロジェクトを巻き込んだ - 開発メンバーの認知負荷が⾼かった - 名刺メーカーというプロジェクトにSREとして課題に向き合っていた - 社内での認知向上を⽬指した - 事ある毎に社内の開発者にOrbitの説明をした - Google Cloudのプロジェクト作成をするTerraformのリポジトリの READMEにOrbitの説明を書いた - 社内LTやBlogでOrbitの話を何度もした PoCで終わらせない為に
11. 2つのチーム体制 Platform Engineering Embedded SRE
12. 主な活動: - GKEを中⼼とした基盤開発・運⽤ > CI/CD > Terraform module, CLIツール > Docs > AI Agent - Feedback > ユーザアンケート > ユーザインタビュー > Office hour スタンス: - Platformをプロダクトとして捉え、 開発者（顧客）に提供する > HEARTフレームワークを利⽤した開発者体験の測定 > RICEスコアによる優先度付け Platform Engineering Team Platform Engineering
13. ミッション: - アプリ開発チームのセルフサービス化を「伴⾛」し 最終的にSREが必要の無い組織にする 主な活動: - Embed: アプリチームのMTGに参加、⽂脈を理解する。 - Enablement: 代わりに作業するのではなく、 プラットフォームの使い⽅を教え、⾃⾛できるようにする。 - Feedback: 現場の声を拾う スタンス: - 代⾏ではなく出来るようになるのを⽀援する Embedded SRE Team Embedded SRE
14. Platformを数値でみてみる（2024/4Q → 2025/1Q） 44 Merge数 リードタイム(時) 利⽤プロジェクト数 2 3 52 140 31
15. まとめ - ⼩さいことから⼤きくしていこう - 知らない事はプロに頼ろう 導⼊するために - 社内営業は⼤事 そもそもPlatformを 社内で認知してもらわないと 始まらない - Platform Engineeringの⽬的は認知負荷の低減 > 「Product」として扱わないと使われない > 「作るチーム」と「伴⾛するチーム」の 両輪が成功の鍵 ⽬的を忘れない - HEARTフレームワーク - RICEスコア 客観的に評価できる仕組み
16. 今後どうしたい？ Embedded SREがOrbitのFeedback Loopに 深く関われるようにしたい そのためにはチームの強化が必要 AI Agent 「そのくらい覚えればイイじゃん」を覚えなくても良い世界に Sansanのプロダクトを全部Orbitへ
17. - 「その開発、認知負荷⾼すぎませんか？」Platform Engineeringで 始める開発者体験カイゼン術 - SREが実現する開発者体験の⾰新 - Platform Engineering Jump Startに参加して学んだこと - Sansanの技術基盤を関⻄から築く。新設組織で未来を創る、 エンジニアの挑戦 - 全社横断のプラットフォーム組織。ゼロイチの魅⼒がここに 参考資料