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

by Shodai Suzuki

Slide 1

Slide 1 text

Shodai Suzuki @SoartecL UV STUDY: PLATFORM ENGINEERINGの始め方 2025.04.25 チーム再始動から6ヶ月でデプロイ数を9倍にするまでの取り組み

Slide 2

Slide 2 text

鈴木翔大 X @SoartecL ソフトウェアエンジニア Productivityチーム( 技術基盤チーム) 趣味 OSS Orvalメンテナダイビング

Slide 3

Slide 3 text

アジェンダプロダクトと組織チームをリビルドしてから、デプロイ数9倍の成果を上げるまでの取り組みデプロイ改善までの取り組み改善後の現在のチームの状況と課題について現在と今後の課題 1 2 3 チーム構築の背景として、プロダクトの構造と開発、組織の構成

Slide 4

Slide 4 text

今日話すことプロダクトと組織チームをリビルドしてから、デプロイ数9倍の成果を上げるまでの取り組みデプロイ改善までの取り組み改善後の現在のチームの状況と課題について現在と今後の課題 1 2 3 チーム構築の背景として、プロダクトの構造と開発、組織の構成

Slide 5

Slide 5 text

オールインワンプロダクト

Slide 6

Slide 6 text

プロダクティビティーチーム機能開発チームがドメインの問題解決に集中できるように他全てをカバー技術基盤リアーキテクチャデザインエンジニアリング/情シス/ コーポレート/セキュリティ/技術広報機能開発チームドメインの解像度を上げてドメインの問題を技術で解決する自律駆動する小さなチームフルサイクル開発

Slide 7

Slide 7 text

プロダクティビティーチーム機能開発チームがドメインの問題解決に集中できるように他全てをカバー技術基盤リアーキテクチャデザインエンジニアリング/情シス/ コーポレート/セキュリティ/技術広報機能開発チームドメインの解像度を上げてドメインの問題を技術で解決する自律駆動する小さなチームフルサイクル開発こっち☝️

Slide 8

Slide 8 text

チームミッション DevOps組織への進化の旗振り役 🚩 前任者から引き継ぎチームミッションの定義からリビルドリビルドは2023年10月初期メンバーは3人

Slide 9

Slide 9 text

Slide 10

Slide 10 text

デプロイ改善までの取り組みドキュメンテーションの仕組み作りデプロイ効率後の確認、検知とシステム安定化監視ツールの導入 CI/CD改善 1 2 3 大きな変更を加えるためチーム間の情報伝達の効率化、議論の活性化、将来の変更を見越したドキュメント文化デプロイ効率化

Slide 11

Slide 11 text

Slide 12

Slide 12 text

ドキュメンテーションの抱えていた課題仕様、技術選定の背景が不明背景を知っているメンバーに都度聞くしかない学びを含めた意思決定の共有ができていなかった情報の粒度が揃っておらずメモなのか決定なのか曖昧レビューや議論の履歴が残っていない

Slide 13

Slide 13 text

DesignDoc 機能や設計に焦点を当てた検討内容機能開発を通して実現したい成果背景と制約課題とソリューションの検討 ADR アーキテクチャに関わる意思決定技術選定開発プロセスの変更実装方針の変更ドキュメンテーションの仕組み作り

Slide 14

Slide 14 text

Slide 15

Slide 15 text

監視の抱えていた課題継続的に利用している一元管理されたシステムモニタリングの基盤が無い Amazon CloudWatchにてシステムメトリクスとログを確認しているアラームの設定も一部行われているリリース後の異常検知及びリリースの成功判断が難しい不具合検知が遅くなっているトラブルシューティングの属人化

Slide 16

Slide 16 text

システム運用効率化に備えオブザーバビリティの強化が必要

Slide 17

Slide 17 text

Datadogの導入 Lambda layerとしてDatadogを導入各種AWSサービスのベースとなるアラートを一気に作成 Lambda/DynamoDB/API Gateway/OpenSearch 「入門監視」の輪読会で基礎的な知見をインストール※1 サポート体制を、輪番制のから、担当機能群の割当に変更 ※1 https://www.oreilly.co.jp/books/9784873118642/

Slide 18

Slide 18 text

アジェンダドキュメンテーションの仕組み作りデプロイ効率後の確認、検知とシステム安定化監視ツールの導入 CI/CD改善 1 2 3 大きな変更を加えるためチーム間の情報伝達の効率化、議論の活性化、将来の変更を見越したドキュメント文化デプロイ効率化

Slide 19

Slide 19 text

CI/CDの抱えていた課題手動デプロイ動作確認がステージングでしか行えないデプロイをするにはmainブランチにマージする必要がある

Slide 20

Slide 20 text

手動デプロイの課題パイプラインの依存関係を手作業で中継複数ファイルのリリースバージョンを更新してpushなどデプロイ手順書とチェックリスト運用作業全体で1時間かかる週2回の固定曜日にリリースバックエンドフロントエンド

Slide 21

Slide 21 text

動作確認の課題ローカル開発環境での動作確認が困難 stagingにデプロイできるのは mainブランチのみ上記2つが相まって、動作確認のためにPRを一度マージして動作確認が終わったらrevertする運用になっていた ①コミットログ例 ② 動作確認後のRevertするPRの例 ③RevertのRevertのRevertのRevert　

Slide 22

Slide 22 text

動作確認の課題 PRをマージして動作確認が終わったらrevertする運用コミットログが汚れ追跡が困難作業効率が悪い品質管理プロセスの機能不全 revert忘れでうっかりリリースが発生手動デプロイ時に「このコミットはリリースして良いのか？」を目視で確認して開発担当者に連絡

Slide 23

Slide 23 text

CI/CDが開発全てのボトルネックになっている

Slide 24

Slide 24 text

CI/CDの改善 CIプロセスの刷新 github actionでデプロイパイプライン構築しデプロイ自動化 githubからどのfeatureブランチでもデプロイ可能に tag pushをトリガーに本番環境デプロイする事でtag管理が徹底 tagを対話式に作成できる簡易ツールを作成バックエンドフロントエンド

Slide 25

Slide 25 text

After Before デプロイプロセスの改善バックエンドフロントエンドバックエンドフロントエンド

Slide 26

Slide 26 text

CI/CD改善の成果前年度比率でデプロイ回数が9倍になった mainにマージする前にfeatureブランチで動作確認が可能になったクリーンなコミットログうっかりリリースの撲滅リリースタグ運用が可能になったリリース履歴が管理可能に問題が発生した場合に履歴から追跡が容易になったリリースの回数自体が計測可能になった

Slide 27

Slide 27 text

Slide 28

Slide 28 text

現在事業は順調に拡大メンバー: 3人 → 12人フロントエンド、バックエンド共にリアーキテクチャが進行中機能開発を含めたエンジニア組織全体の人数も2倍程に成長

Slide 29

Slide 29 text

変化するボトルネックデプロイ頻度が上がった事によるステージング環境の渋滞不具合の増加リリースの情報伝達不足ローカル開発環境の改善テストサイクルやデータ、アカウント整備デプロイ頻度は増えたが顧客価値の提供量・スピードは・・・？