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

soartec-lab
2025/05/20に公開
 はじめにVPoTの鈴木です。
プロダクティビティーチームは私がチームリーダーを引き継いだ2023年10月に複数チームを統廃合して結成しました。

そして結成半年でデプロイ回数を9倍に増加させる成果を出す事ができました。

本記事では、「プラットフォームチームの始め方」の一つの事例として当時の状況、直面した課題、それに対する取り組みについて紹介します。
内容はこちらのスライドにもまとめているので合わせてご一読ください。

 プロダクトの性質とエンジニア組織の構成技術的な解決策の背景情報となるプロダクトの性質とエンジニア組織の構成について簡単に紹介します。

MOSHプロダクトはクリエイターエコノミー市場に対し、オールインワン型のプロダクトでユーザーへ価値を提供しています。

多角的なドメイン・機能を取り扱うため機能開発においてはドメインを深く理解して価値作りに向き合う必要があります。
そのため、MOSHのエンジニア組織は以下の2つのチームで構成しています。
解像度を上げてドメインの問題を技術で解決する機能開発チーム
機能開発チームがドメインの問題解決に集中できるように他全てをカバーするプロダクティビティーチーム
機能開発チームは以下のポリシーで構成しています。
3 ~ 5人の小規模で自律駆動する開発ユニットとして区切る
開発ユニットはシステムコンポーネントが割り当てられる
ドメインの解像度を上げるインタビューや分析活動から、機能開発、担当サービス運用までフルサイクルで開発する
価値のあるプロダクトを作るためにはドメインの解像度を上げフルサイクルで開発する必要があると考えていますが物理的な時間の制約や認知負荷や効率の課題があります。

そのため、機能開発チームがドメインの問題領域に集中できるように他全てをカバーするプロダクティビティーチームがいます。

 プロダクティビティーチームについて
キャプチャは実際に運用しているチームドキュメントのトップページに配置されているチームミッションです。チーム結成に伴い「DevOps組織への進化の旗振り役」というチームミッションを定義しました。
MOSHは現在、PMF直後のフェーズにあり、事業の成長をさらに加速させるためには、持続的に素早く価値を提供する力と、堅牢で信頼性のあるシステムの両立が求められています。

これまでは目の前の開発に集中していましたが、今後は中長期的な視点での継続的な開発・運用が必要です。
私たちはこの両立を、「LeanとDevOps」「質とスピード」「探索と深化」といった軸で捉え、DevOpsの概念を取り入れ、実践しています。
DevOpsの実行の当事者は組織全員ですが、一貫した方針を示し全体を推進する役割が不可欠です。

プロダクティビティーチームはその旗振り役としてあらゆる問題を解決するチームになるためこのミッションを定義しました。

 具体的な管掌範囲具体的には以下の様な領域を管掌しています。
技術基盤
リアーキテクチャ
情報システム
セキュリティ
コーポレート(法務)
技術広報
デザインエンジニアリング

 デプロイ改善までの取り組み背景情報が長くなりましたが、ここから本題のデプロイ改善についての取り組みについて紹介します。
初期メンバー3人からのスタートで、実際にはすぐに課題解決に着手できるメンバーは私ともう1人という状況でした。
限られたリソースの中で最大限のインパクトを出すために、開発組織、プロセス、ソースコードなどを分析した結果、CI/CDが開発全てのボトルネックになっていると判断し、そのための前段階として

ドキュメンテーション整備、監視環境の導入と段階的に改善を行いました。

 1. ドキュメンテーション抜本的な改善を効率的に進めるためにまずはドキュメンテーションの仕組み化を行いました。

 抱えていた課題技術選定や仕様の背景が口頭ベースでしか伝達されておらず属人化が進んでいた
どこまでが決定事項か、どこまでがメモかの区別が曖昧で、記録も断片的だった
レビューや議論の記録が残っておらず、技術的な判断、学びの蓄積がなかった

 対応内容DesignDocとADRの運用ガイドラインと雛形を用意しました。詳細はこちらの記事にも書いているのでご興味があればご一読ください。

DesignDoc: 機能開発の背景や制約、検討過程を文書化

ADR: アーキテクチャに関する意思決定や技術選定を明示
運用方針としては、文化として浸透させたいため運用をルール化したり必須化はしていません。

苦手なメンバーや不慣れなメンバーもいるため、ガイドラインとして整備やフォロー体制を構築した上で、強い推奨とチームメイトとしてのリクエストに留めており、成功体験を積む中で自然と文化になるようなアプローチをしています。

直近だと開発時のAIへのコンテキストの1つとして活用できる恩恵もあります。

 2. 監視ツールの導入CI/CD改善の一環として監視ツールの導入を行いました。

 抱えていた課題一元管理されたモニタリングツールが存在しない

Amazon CloudWatch、Amazon CloudWatch Logsで部分的なモニタリングはしていた

アプリケーションのテストコードが乏しい事も相まって異常検知が遅延
リリースがの成功判定が困難だった
トラブル対応が属人化し情報の共有や再現性に課題があった

 対応内容
Datadogを導入し、主要AWSリソース（Lambda、DynamoDB、API Gateway、OpenSearch）に対応
レイテンシはステータスコードなど基礎的なアラート設定を一気に作成
監視設計と運用体制の見直しを行い、属人性を排除
監視に関する知識の底上げのため、「入門 監視」の輪読会を実施
技術顧問のsongmuさんにもオブザーバーとして参加いただき、理解を深めたい箇所の質問や関連するエピソードをお話ししていただきました。

ベースとなるアラート設定は一気に作成しましたが機能によって細かく設定したいケースもあり運用の中でチューニングしています。
また、このタイミングでテクニカルサポート体制も変更しています。以前は全てのお問い合わせを全員でカバーする輪番制でテクニカルサポートを受け付けていましたが、ナレッジ蓄積、当番の負荷、運用効率化、抜本的な改善など課題が大きかったため、システムコンポーネント群を定義してチームに割り当て、該当するシステムコンポーネントの担当チームが対応するように変更しました。

 3. CI/CD改善本丸のCI/CD改善です。大きな課題があったので仕組みや開発プロセスを再構築しました。

 抱えていた課題抱えていた問題は大きく以下の2つあるので細かく紹介します。
手動デプロイに伴う課題
動作確認の課題

 手動デプロイに伴う課題
以前は手動でデプロイを行っており以下の課題を抱えていました。

キャプチャは実際に運用していた手動デプロイのフローチャートです。
デプロイするには複数のファイルのバージョンを更新する必要がある
アプリケーション内で使用するシークレット情報がGithub内で管理されておりGithub Actionで注入するステップがある
それらのパイプラインの依存関係を手作業コピペして次のステップに渡す必要がある
これらの仕組みにより作業全体が完了するまで1時間かかっていました。

そのため作業自体のコストが高いので週2回曜日を固定してリリース日を設け運用していました。

 動作確認の課題
ローカル開発環境が乏しくステージング環境でしかフロントエンドとバックエンドを結合した動作確認ができない
ステージング環境へのデプロイはmainブランチへのマージが前提
動作確認のためだけに一度マージし終わったらrevertする運用が常態化(上記キャプチャ②③の状態)
という状態でした。

何度も動作確認をするような開発ではRevertのRevertのRevertのRevertの様な事になります。

運用の実態としては以下の様な問題が顕在化しており、開発プロセスの非効率化、品質管理のプロセスの機能不全に陥っていました。

revertを何度も繰り返すことでコミットログが汚れ履歴の追跡が困難(上記キャプチャ①の状態)

revert漏れにより誤って本番リリースされる事故も発生
事故防止のために手動デプロイの際に「このコミットはリリースして良いのか？」を目視で確認して開発担当者に確認する運用

 対応内容
CI/CDを見直しして仕組みや開発プロセスを再構築しました。

キャプチャは改善後の現在も運用しているデプロイのフローチャートです。

GitHub Actionsを用いたCIプロセスの刷新、自動デプロイのパイプライン構築

featureブランチ単位での動作確認とデプロイを可能にしmainにマージ前の検証ができるようにした

tag pushをトリガーに本番デプロイを実行する仕組みを導入
対話形式でtagを作成できるCLIツールを開発し、誰でも安全にデプロイできるように整備

 デプロイ数が9倍になった成果
キャプチャはデプロイ数の遷移です。

赤い点線はデプロイ方式を切り替えた時期を示しています。以降、デプロイ数が大幅に増加していることがわかります。この改善により次の様な成果を得る事ができました。
デプロイ数は前年度比で9倍となりリリース頻度が大幅に向上
リリースタグの運用が可能になったことでリリースの履歴、デプロイ回数も容易に計測可能になった
クリーンなコミットログを手に入れた
意図しないリリース事故防止を仕組みで徹底

 現在地と変化するボトルネックCI/CDの自動化によってデプロイの回数が飛躍的に向上した一方で次なる課題も顕在化してきました。

デプロイ頻度は上がりましたが、ローカル開発環境が整備されていないため、ステージング環境でしか動作確認ができない開発が多く、ステージング環境における渋滞が発生しています。
また、テスト用データ・アカウントの標準化といった開発の課題も大きくなっています。
さらに、リリースが増えたことに比例して不具合の増加や、リリースに関する情報の社内伝達が不足するなど新たな運用課題も見えてきました。

不具合の検知と影響範囲の最小化は事前にモニタリングツールを導入したことで影響範囲の最小化に寄与しております。

 その他の活動この記事ではCI/CDの改善に留まりますが、冒頭に紹介した通りプロダクティビティーチームは幅広く管掌しており、同時期に以下のような改善も並行していました。
開発チームの考え方と体制の変更

OpenAPIの整備
自動テスト拡充

IAMアカウントの整備

AWSコストの最適化により15%のコストカット
脆弱性テストの対応と管理
SaaS請求書管理の社内運用整理
メール送信の信頼性向上
これらも機会があれば共有していきたいと考えています。

 おわりにデプロイの頻度は9倍に増え、細かくリリース可能になった事でよりアジャイルな開発ができるようになったり、仕組みを構築した事でより本質的な事に時間を使えるようになりました。
しかし、顧客価値は9倍に増加している訳ではありません。顧客価値を最大化するにはこの仕組みを使ってさらなる改善を積み重ねていくことが重要です。
技術基盤としても移動したボトルネックや新しく発生している課題も引き続き解消しています。

現在はフロントエンド、バックエンドともにリアーキテクチャを進めており更に大規模な技術基盤の整備を進めている最中ですが この記事で紹介した初期の取り組みの効果を日々実感しています。
私たちの取り組みが「プラットフォームチームの始め方」の1つの事例としてお役に立てれば幸いです。