「その開発、認知負荷高すぎませんか？」Platform Engineeringで始める開発者体験カイゼン術

■ イベント
Developers Summit KANSAI
https://event.shoeisha.jp/devsumi/20250917

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

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

Transcript

1. Sansan株式会社 部署 名前 「その開発、認知負荷⾼すぎませんか？」 技術本部 Platform Engineering Unit Application Platformグループ 辻⽥ 美咲 Platform Engineeringで始める開発者体験カイゼン術
2. 辻⽥ 美咲 技術本部 Platform Engineering Unit Application Platformグループ
3. アジェンダ 1. 私たちの開発現場が抱えていた「痛み」 2. Platform Engineering 実践ジャーニー 3. 得られた成果と、次なる学び 4. 明⽇から始めるためのヒント
4. この発表でお伝えしたいこと • これから Platform Engineering を 始めたい⽅ • Platform Engineering に 取り組んでいる⽅ • 現場のエンジニア • EM • PdM 対象となる⽅ • Platform Engineering の 具体的な始め⽅と進め⽅がわかる • ツール導⼊だけでなく 開発者と「共創」する重要性を 理解する 今⽇のゴール
5. 私たちの開発現場が抱えていた「痛み」
6. よくある開発現場の⾵景
7. 認知負荷が引き起こすこと 認知 負荷 開発 速度 の 低下 品質 の 低下 イノベー ション の 停滞 開発者は本来の価値創造（= 顧客への価値提供）に集中できない。 結果として、ビジネススピードが鈍化する。
8. 具体的な課題 - Terraform と実環境の不⼀致 - CI/CD パイプラインの属⼈化 - ダッシュボード管理不⾜ - セキュリティ・コストへの意識不⾜
9. そこで Platform Engineering Platform Engineeringとは？ 開発者がセルフサービスで利⽤できる、 信頼性の⾼いプラットフォームを提供する取り組み ⽬的 開発者の認知負荷を下げ、 開発者体験 (DX) を向上させる Point ツール導⼊が⽬的ではない。成果で測る。
10. プラットフォームOrbitの誕⽣ - 開発者の「痛み」を取り除く ニーズに沿った、最薄のプラットフォーム（TVP）
11. わたしたちの Platform Engineering ジャーニー ~ 技術による課題解決 ~
12. ⽬指す姿は、 開発者が本来の価値提供に 集中できる環境
13. 課題にどう向き合ったか？ - Terraform と実環境の不⼀致 - CI/CD パイプラインの属⼈化 - ダッシュボード管理不⾜ - セキュリティ・コストへの意識不⾜ ゴールデンパスを提供
14. Helm × Terraform Moduleによる"抽象化" Before 10個ほどの manifest ファイル + 数百⾏のHCL After 1ファイル + 10⾏程度の Module 呼び出し 複雑さを隠蔽し、セルフサービスを実現 module "orbit_core" { source = "git@github.com:sansan/module-name.git//modules/orbit" project_id = var.project_id orbit_environment = "dev" k8s_namespace = "demo" log_bucket_retention_days = 365 } resource "google_storage_bucket" "default" { name = "bucket-name" location = var.region storage_class = "COLDLINE" uniform_bucket_level_access = true lifecycle_rule { condition { age = var.log_bucket_retention_days } action { type = "Delete" } } # … 延々と続く設定 …
15. CLI による必要ファイルの⾃動⽣成 開発者は Orbit CLI を実⾏するだけで、アプリケーション開発に必要な k8s manifest と terraform ファイルが⾃動⽣成される。 👩💻 開発チーム $ orbit cli add namespace ファイルを⾃動⽣成 k8s Manifests Namespace, Gateway, NetworkPolicy … Terraform Files GCS Bucket, IAM, Alert … Orbit CLI
16. CI/CD パイプラインのテンプレート化① - copier を活⽤した GitHub Actions のテンプレート > Reusable Workflows, Composite Actions の活⽤ - Argo CD による GitOps
17. CI/CD パイプラインのテンプレート化② - マニフェスト変更や、Helm Charts バージョン更新時の差分表⽰ https://github.com/hirosassa/ksnotify
18. ガードレールによる信頼性と安全性の確保 ガードレール例 - Conftest によるポリシーチェック - Kubescape による脆弱性スキャン 提供方法 - テンプレートに組み込む - CI に⾃動チェックを組み込む “守るべきこと”は⼈ではなく仕組みに任せる
19. ダッシュボードの共有とコスト削減施策の⾃動適⽤ - Metrics Scope を使って、GKE ダッシュボードを開発チームに公開 - 検証環境では Spot インスタンスを活⽤ & 夜間と⼟⽇の⾃動停⽌ - コスト按分 - GKE のコストを namespace 単位でプロジェクトに按分し、 共通リソース費⽤は namespace ⽐率で算出
20. AI による⽀援 - GKE Interactive Troubleshooting Playbook、Gemini のログ説明機能、Gemini Cloud Assist を活⽤した迅速なトラブルシューティング
21. Orbit のアーキテクチャ
22. わたしたちの Platform Engineering ジャーニー ~ 開発チームとの共創 ~
23. 我々のスタート地点とアプローチ • PE ほぼ経験なし • インフラ構築は属⼈化 • ツールもバラバラ Before • 発⾒ → 施策 → 定着 • 最薄のプラットフォーム（TVP） Approach: ⼩さく始めて共創する Mindset: Platform Team は “内製プロダクトチーム” 。 開発チームはユーザーでありパートナー。
24. 外部協⼒でブースト、迅速な基盤⽴ち上げ How? 開発チームと共に、Platform Engineering Jump Start というワークショップに参加 Google Cloud のスペシャリストによる初期⽴ち上げのサポートを受けた Benefit - ベストプラクティスを迅速にキャッチアップ - ⾞輪の再発明を避ける ⽬的は単なる「サポート」ではなく、チームへの「知識転移」
26. チーム間の協働 やったこと - ペアプロで同期的な問題解決 - ユーザチーム毎の定例会を開催 - ⽉に 1 回、Office Hours の開催 による、問題の早期解決と信頼関係の構築 Platform Team は「提供者」ではなく、開発チームの「パートナー」
27. ユーザ中⼼主義 開発チームの認知負荷を取り除くための Platform。 開発者のために開発されていなければならない。 しかし、基盤は⼗分薄くあるべきである。
28. 薄い Platform とは、 Platform 側の⼯数増加より、 利⽤者の⼯数削減が 多くなる施策のみで 基盤が構成されていること。
29. 得られた成果と、次なる学び
30. 数字で⾒る成果 111% にデプロイ頻度 が増加 41% リードタイム の短縮
31. 開発者の声 - 「アプリの構築からデプロイまでが本当に⾼速道路でした」 - 「Argo CD が⽤意されていたので、デプロイパイプラインの構築が爆速でした」 - 「環境固有の専⽤処理がなく認知負荷の軽減につながっています」 - 「ロードバランサや NEG の設定を意識しなくて済むので、 新規サービス構築時の⼿間が少なくて済みます」
32. うまくいかなかったこと／いま向き合ってること - ゴールデンパスのジレンマ：共通化と⾃由度のバランス - 新たなボトルネック化：プラットフォームチームへの問い合わせの増加 - ドキュメントの陳腐化：ドキュメントを⼿動更新し続ける限界 - 想定外のコスト増加： リソース最適化の難しさ、GKE以外の費⽤でnamespaceにかかわらず 共通で利⽤するリソース（Cloud Monitoring, Networking）のコスト増
33. ビジョンの⾔語化、⻑期的な⽅向性を定める 現在【プロダクト開発チーム】が【アプリケーション開発を通じて顧客に事業価値を迅速かつ継続的に提供すること】を望むとき、彼・彼⼥ らは【標準化されたプロセスを持たず、サーバやネットワークのプロビジョニング、CI/CDパイプラインの設計と実装、監視システムの導⼊ とアラート設定などを都度独⾃に構築】しなければならない。 この状況は【多岐にわたる専⾨知識が求められることで認知負荷を増⼤させ、品質・セキュリティ・安定性の担保が属⼈化することで、開発 者が本来集中すべき創造的な価値提供を妨げている】ため、受け⼊れられない。 我々は【最⾼の開発者体験が提供され、すべての開発者がインフラの複雑さから解放され、⾃信とスピードをもってアプリケーション開発そ のものに没頭できる】世界を夢⾒ている。 我々は【Platform Engineeringのアプローチに基づき、複雑な設定を⼀切不要にし、開発者が本来の業務に即座に集中できる、以下の価値を備 えたセルフサービス型の『ゴールデンパス』を提供すること： - ⾼品質： Kubernetesのベストプラクティスを組み込んだテンプレート - セキュア： Sansan社のセキュリティポリシーに準拠したガードレール - 安定性： 標準装備された可観測性と、強⼒な⾃動復旧・ロールバック機能 】を通じて、そのような世界を実現するつもりである。
34. 明⽇から始めるためのヒント
35. 基盤作りだけが Platform Engineering ではない ⾊々な始め⽅がある - ドキュメントの整備 - アプリケーションや CI/CD パイプラインのテンプレート作成 - 共通ライブラリや CLI の開発 ⼤切なのは「開発者のペインは何か？」を常に問い続けること
36. 社内外の専⾨家を巻き込む すべてを⾃分たちだけで解決しようとしない。 社内外の専⾨家は、プロジェクト成功の確率を⼤きく⾼めてくれる存在。 ✓ 客観的な視点を取り⼊れ、思い込みを排除する ✓ ありがちな落とし⽳を事前に回避する ✓ チームの学習速度を加速させる ✓ 社内のステークホルダーへの説得材料になる
37. まとめ - 開発者の認知負荷は、静かにビジネスを蝕む。 まずは課題を可視化しよう。 - 完璧なプラットフォームを⽬指さない。 開発者と対話し、“共創” するプロセスが価値を⽣む。 - 始め⽅は⼀つじゃない。 まずは⾝近な “痛み” を解消する⼩さな⼀歩から始めてみる。