チーム再始動から6ヶ月でデプロイ数を9倍にするまでの取り組み

2025-04-25 「UV Study: Platform Engineeringの始め方」のLT資料です。

Transcript

1. Shodai Suzuki @SoartecL UV STUDY: PLATFORM ENGINEERINGの始め方 2025.04.25 チーム再始動から6ヶ月 でデプロイ数を9倍にす るまでの取り組み
2. 鈴木翔大 X @SoartecL ソフトウェアエンジニア Productivityチーム( 技術 基盤チーム) 趣味 OSS Orvalメンテナ ダイビング
3. アジェンダ プロダクトと組織 チームをリビルドしてから、 デプロイ数9倍の成果を上げ るまでの取り組み デプロイ改善までの取 り組み 改善後の現在のチームの状況 と課題について 現在と今後の課題 1 2 3 チーム構築の背景として、プ ロダクトの構造と開発、組織 の構成
4. 今日話すこと プロダクトと組織 チームをリビルドしてから、 デプロイ数9倍の成果を上げ るまでの取り組み デプロイ改善までの取 り組み 改善後の現在のチームの状況 と課題について 現在と今後の課題 1 2 3 チーム構築の背景として、プ ロダクトの構造と開発、組織 の構成
5. オールインワンプロダクト
6. プロダクティビティーチーム 機能開発チームがドメインの問題解決 に集中できるように他全てをカバー 技術基盤 リアーキテクチャ デザインエンジニアリング/情シス/ コーポレート/セキュリティ/技術広 報 機能開発チーム ドメインの解像度を上げてドメインの 問題を技術で解決する 自律駆動する小さなチーム フルサイクル開発
7. プロダクティビティーチーム 機能開発チームがドメインの問題解決 に集中できるように他全てをカバー 技術基盤 リアーキテクチャ デザインエンジニアリング/情シス/ コーポレート/セキュリティ/技術広 報 機能開発チーム ドメインの解像度を上げてドメインの 問題を技術で解決する 自律駆動する小さなチーム フルサイクル開発 こっち☝️
8. チームミッション DevOps組織への進化の旗振り役 🚩 前任者から引き継ぎチームミッショ ンの定義からリビルド リビルドは2023年10月 初期メンバーは3人
9. アジェンダ プロダクトと組織 チームをリビルドしてから、 デプロイ数9倍の成果を上げ るまでの取り組み デプロイ改善までの取 り組み 改善後の現在のチームの状況 と課題について 現在と今後の課題 1 2 3 チーム構築の背景として、プ ロダクトの構造と開発、組織 の構成
10. デプロイ改善までの取 り組み ドキュメンテーション の仕組み作り デプロイ効率後の確認、検知 とシステム安定化 監視ツールの導入 CI/CD改善 1 2 3 大きな変更を加えるためチーム 間の情報伝達の効率化、議論の 活性化、将来の変更を見越した ドキュメント文化 デプロイ効率化
11. デプロイ改善までの取 り組み ドキュメンテーション の仕組み作り デプロイ効率後の確認、検知 とシステム安定化 監視ツールの導入 CI/CD改善 1 2 3 大きな変更を加えるためチーム 間の情報伝達の効率化、議論の 活性化、将来の変更を見越した ドキュメント文化 デプロイ効率化
12. ドキュメンテーションの抱 えていた課題 仕様、技術選定の背景が不明 背景を知っているメンバーに都度聞くしかない 学びを含めた意思決定の共有ができていなかった 情報の粒度が揃っておらずメモなのか決定なのか曖昧 レビューや議論の履歴が残っていない
13. DesignDoc 機能や設計に焦点を当てた検討内容 機能開発を通して実現したい成果 背景と制約 課題とソリューションの検討 ADR アーキテクチャに関わる意思決定 技術選定 開発プロセスの変更 実装方針の変更 ドキュメンテーションの仕組み作り
14. デプロイ改善までの取 り組み ドキュメンテーション の仕組み作り デプロイ効率後の確認、検知 とシステム安定化 監視ツールの導入 CI/CD改善 1 2 3 大きな変更を加えるためチーム 間の情報伝達の効率化、議論の 活性化、将来の変更を見越した ドキュメント文化 デプロイ効率化
15. 監視の抱えていた課題 継続的に利用している一元管理されたシステムモニタリ ングの基盤が無い Amazon CloudWatchにてシステムメトリクスとログ を確認している アラームの設定も一部行われている リリース後の異常検知及びリリースの成功判断が難しい 不具合検知が遅くなっている トラブルシューティングの属人化
16. システム運用効率化に備えオブザー バビリティの強化が必要
17. Datadogの導入 Lambda layerとしてDatadogを 導入 各種AWSサービスのベースとなる アラートを一気に作成 Lambda/DynamoDB/API Gateway/OpenSearch 「入門 監視」の輪読会で基礎的な 知見をインストール※1 サポート体制を、輪番制のから、 担当機能群の割当に変更 ※1 https://www.oreilly.co.jp/books/9784873118642/
18. アジェンダ ドキュメンテーション の仕組み作り デプロイ効率後の確認、検知 とシステム安定化 監視ツールの導入 CI/CD改善 1 2 3 大きな変更を加えるためチーム 間の情報伝達の効率化、議論の 活性化、将来の変更を見越した ドキュメント文化 デプロイ効率化
19. CI/CDの抱えていた課題 手動デプロイ 動作確認がステージングでしか行えない デプロイをするにはmainブランチにマー ジする必要がある
20. 手動デプロイの課題 パイプラインの依存関係を手作業 で中継 複数ファイルのリリースバー ジョンを更新してpushなど デプロイ手順書とチェックリスト 運用 作業全体で1時間かかる 週2回の固定曜日にリリース バックエンド フロントエンド
21. 動作確認の課題 ローカル開発環境での動作確認が 困難 stagingにデプロイできるのは mainブランチのみ 上記2つが相まって、動作確認のた めにPRを一度マージして動作確認 が終わったらrevertする運用に なっていた ①コミットログ例 ② 動作確認後のRevertするPRの例 ③RevertのRevertのRevertのRevert　
22. 動作確認の課題 PRをマージして動作確認が終わったらrevertする運用 コミットログが汚れ追跡が困難 作業効率が悪い 品質管理プロセスの機能不全 revert忘れでうっかりリリースが発生 手動デプロイ時に「このコミットはリリースして良いの か？」を目視で確認して開発担当者に連絡
23. CI/CDが開発全てのボトルネックに なっている
24. CI/CDの改善 CIプロセスの刷新 github actionでデプロイパイプラ イン構築しデプロイ自動化 githubからどのfeatureブランチで もデプロイ可能に tag pushをトリガーに本番環境デ プロイする事でtag管理が徹底 tagを対話式に作成できる簡易ツー ルを作成 バックエンド フロントエンド
25. After Before デプロイプロセスの改善 バックエンド フロントエンド バックエンド フロントエンド
26. CI/CD改善の成果 前年度比率でデプロイ回数が9倍に なった mainにマージする前にfeatureブ ランチで動作確認が可能になった クリーンなコミットログ うっかりリリースの撲滅 リリースタグ運用が可能になった リリース履歴が管理可能に 問題が発生した場合に履歴から 追跡が容易になった リリースの回数自体が計測可能 になった
27. アジェンダ プロダクトと組織 チームをリビルドしてから、 デプロイ数9倍の成果を上げ るまでの取り組み デプロイ改善までの取 り組み 改善後の現在のチームの状況 と課題について 現在と今後の課題 1 2 3 チーム構築の背景として、プ ロダクトの構造と開発、組織 の構成
28. 現在 事業は順調に拡大 メンバー: 3人 → 12人 フロントエンド、バックエンド共に リアーキテクチャが進行中 機能開発を含めたエンジニア組織全 体の人数も2倍程に成長
29. 変化するボトルネック デプロイ頻度が上がった事による ステージング環境の渋滞 不具合の増加 リリースの情報伝達不足 ローカル開発環境の改善 テストサイクルやデータ、アカウント整備 デプロイ頻度は増えたが顧客価値の提供量・スピード は・・・？
30. プロダクト価値も10倍へ！
31. おわり