Sansan株式会社 技術本部 Platform Engineering Unit ⽔⾕⾼朗 Sansanが実践する Platform EngineeringとSREの協創 ag-ui adk [Error [SocketError]: other side closed] 

⽔⾕ ⾼朗 Platform Engineering Unit Application Platform Group 2014年 Sansan株式会社⼊社 名刺データ化部⾨のインフラエンジニアとして オンプレミスからPublic Cloudへの移⾏、RDBMS、 全⽂検索エンジンの最適化に従事しながら、 新規事業のインフラエンジニアを担当 2024年Platform Engineering Unitの⺟体となる部⾨で SRE組織の起ち上げを担当 2025年6⽉より現職 

© Sansan, Inc. Sansanについて 本社 神山ラボ 経理DXサービス 取引管理サービス 名刺アプリ ビジネスデータベース 

© Sansan, Inc. Platform Engineering Unit アプリケーション基盤 App Platform Group 認証基盤 Identity Platform Group 今⽇は こっちの 話 

© Sansan, Inc. - Sansanのサービスが急成⻑ - エンジニア組織は急には成⻑しない - 結果として1名のインフラエンジニアが5つの新規事業の基盤構築を担うが 実質的な運⽤は開発者がおこなっていた しんどい⽅向にいった「You Build It, You Run It」 認知負荷が⾼まりすぎて、 機能開発に集中できない。 

© Sansan, Inc. そこで Platform Engineering Platform Engineeringとは？ 開発者がセルフサービスで利⽤できる、 信頼性の⾼いプラットフォームを 提供する取り組み ⽬的 開発者の認知負荷を下げ、 開発者体験 (DX) を向上させる Point ツール導⼊が⽬的ではない。 

機能豊富なツールを並べただけでは、Platformではない。 - 使い⽅が難しい（学習コストが⾼い） - ドキュメントが古い、読みにくい - 「これを使え」という強制感が強い よくある失敗 Platformは「社内向けプロダクト」として扱う必要がある 

社内向けプロダクトとしてOrbitが誕⽣ Thinnest Viable Platform (TVP) 最初から全部盛りにしない。最⼩限の価値から。 

- 予算の確保 - まずはPoCということで始めた - Platform Engineering知らない状態 - Google CloudさんのPlatform Engineering Jump Startという ワークショップに参加しPlatform Engineeringのベストプラクティス を学びました 誕⽣の前にしたこと 

- 同じ部署の既存プロジェクトを巻き込んだ - 開発メンバーの認知負荷が⾼かった - 名刺メーカーというプロジェクトにSREとして課題に向き合っていた - 社内での認知向上を⽬指した - 事ある毎に社内の開発者にOrbitの説明をした - Google Cloudのプロジェクト作成をするTerraformのリポジトリの READMEにOrbitの説明を書いた - 社内LTやBlogでOrbitの話を何度もした PoCで終わらせない為に 

2つのチーム体制 Platform Engineering Embedded SRE 

主な活動: - GKEを中⼼とした基盤開発・運⽤ > CI/CD > Terraform module, CLIツール > Docs > AI Agent - Feedback > ユーザアンケート > ユーザインタビュー > Office hour スタンス: - Platformをプロダクトとして捉え、 開発者（顧客）に提供する > HEARTフレームワークを利⽤した開発者体験の測定 > RICEスコアによる優先度付け Platform Engineering Team Platform Engineering 

ミッション: - アプリ開発チームのセルフサービス化を「伴⾛」し 最終的にSREが必要の無い組織にする 主な活動: - Embed: アプリチームのMTGに参加、⽂脈を理解する。 - Enablement: 代わりに作業するのではなく、 プラットフォームの使い⽅を教え、⾃⾛できるようにする。 - Feedback: 現場の声を拾う スタンス: - 代⾏ではなく出来るようになるのを⽀援する Embedded SRE Team Embedded SRE 

Platformを数値でみてみる（2024/4Q → 2025/1Q） 44 Merge数 リードタイム(時) 利⽤プロジェクト数 2 3 52 140 31 

まとめ - ⼩さいことから⼤きくしていこう - 知らない事はプロに頼ろう 導⼊するために - 社内営業は⼤事 そもそもPlatformを 社内で認知してもらわないと 始まらない - Platform Engineeringの⽬的は認知負荷の低減 > 「Product」として扱わないと使われない > 「作るチーム」と「伴⾛するチーム」の 両輪が成功の鍵 ⽬的を忘れない - HEARTフレームワーク - RICEスコア 客観的に評価できる仕組み 

今後どうしたい？ Embedded SREがOrbitのFeedback Loopに 深く関われるようにしたい そのためにはチームの強化が必要 AI Agent 「そのくらい覚えればイイじゃん」を覚えなくても良い世界に Sansanのプロダクトを全部Orbitへ 

- 「その開発、認知負荷⾼すぎませんか？」Platform Engineeringで 始める開発者体験カイゼン術 - SREが実現する開発者体験の⾰新 - Platform Engineering Jump Startに参加して学んだこと - Sansanの技術基盤を関⻄から築く。新設組織で未来を創る、 エンジニアの挑戦 - 全社横断のプラットフォーム組織。ゼロイチの魅⼒がここに 参考資料 

No content