ID:80760さん

## プロジェクト概要 大手広告配信プラットフォーム（DSP）の管理画面において、広告のExcel一括入稿機能を個人主導で設計から本番リリースまでフルスタックで実装し、運用工数の大幅削減を達成しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドチーム所属のフルスタックエンジニアとして、設計・実装・テスト・本番リリースまで一貫して担当し、コードレビュー対応や品質管理も主導しました。 - 広告運用ビジネスチームと直接仕様調整を行い、入稿フォーマットの統一とAPI設計をリードしました。 - データ分析およびQAも兼任し、テーブル駆動テストや動作検証を通じて品質向上に貢献しました。 ### チーム規模と構成 - バックエンドエンジニア3名（うち自分が主担当）、シニアエンジニア1名、同僚1名のコードレビュー体制で開発を進めました。 ## 背景・課題 - 広告入稿業務は管理画面で1件ずつ手入力する運用が主流であり、『100件規模の大量入稿では手作業が現実的でなく、転記ミスや作業負荷の増大が顕著でした』。 - 入稿時に「キャンペーン名」「広告グループ名」「画像名」からDBのIDを人手で引き当てる必要があり、作業負担が大きくエラー発生の温床となっていました。 - 広告主ごとに入稿フォーマットが異なり、表記ゆれによる入稿エラーが多発していたため、運用の効率化とミス削減が急務でした。 ## 実際の取り組み ### 開発環境 - バックエンドはTypeScriptのNestJSフレームワークとPrisma ORMを用いてAPIを設計・実装し、Amazon Aurora（MySQL）をデータベースとして利用しました。 - フロントエンドはNext.jsを用い、ユーザーがExcelファイルをアップロードしプレビュー確認後に一括登録できるUIを構築しました。 - Excelファイルの解析にはexceljsとZodを採用し、代替候補の脆弱性やメモリ効率を比較検討した上で安全性と性能を確保しました。 - テストはJestを用い、社内規約に準拠したテーブル駆動テストを実施し、品質を保ちました。 - CI/CDはGitHub ActionsとPipeCDを活用し、ECSへのcanaryデプロイを実現しました。 ### 設計・改善内容 - 広告入稿の照合方式を「画像名（表記ゆれあり）」から「アセットIDの完全一致」に変更し、表記ゆれによる入稿エラーを原理的に排除しました。 - バックエンドでExcelファイルを解析し、各行のDB ID解決と登録可否判定を行うpreview APIと、確認済みの広告を停止状態（is_active=0）で一括登録するregister APIを実装しました。 - TOCTOU問題に対応するため、登録直前にサーバー側で再照合を実施し、クライアントから渡されるIDの信頼を排除して権限昇格を防止しました。 - fast-followとして、画像名とアセットIDの対応表をExcel形式で出力し、VLOOKUPを利用した一括記入を支援するエクスポート機能も設計しました。 ### その他アピールポイント - 本番リリースではGitHub Actionsでビルドし、PipeCDによるcanaryデプロイを実施。さらに本番DBの権限seed投入や運用ロールへの権限付与まで担当しました。 - 複数の役割（設計・実装・テスト・データ分析・QA）を兼任し、短期間かつ高品質なリリースを実現しました。 ## 成果・価値 - 手作業による1件ずつの広告入稿業務をExcelアップロードによる一括入稿に自動化し、100件規模の入稿作業が効率的かつ正確に行える基盤を構築しました。 - 表記ゆれ由来の入稿ミスを構造的に排除し、案件数増加に伴う入稿工数の増加を抑制しました。 - オペレーションチームから高評価を得て、事業部のMVPにノミネートされるなど、工数削減施策として事業部内での評価を獲得しました。

## スロークエリ改善によるレスポンス速度40%向上とピークタイム安定化 ### プロジェクト概要 建設業界に特化したSaaSにおいて、ユーザー数やデータ量の増加に伴い特定画面でのレスポンス遅延が顕著になり業務に支障が出始めていた課題に対し、Datadogを活用した可視化・分析から始め、データベースクエリの最適化とN+1問題の解消を中心とした包括的なパフォーマンスチューニングを実施しました。 ### チーム情報 - 担当: バックエンドエンジニア(個人) - 期間: 2025年/半年以内 ### 背景・課題 **ビジネス課題:** - ユーザー数とデータ量の増加に伴い、特定画面のレスポンスが著しく遅延 - ピークアクセス時に業務に支障が出るレベルのパフォーマンス劣化 - ユーザー体験の悪化によるチャーンリスク **技術課題:** - どのクエリがボトルネックになっているか特定できていない状況 - テーブル結合が多い検索系クエリの処理時間が増大 - WHERE句でインデックスが効いていない箇所の存在 - N+1クエリ問題の発生 ### 実装内容 **1. Datadogダッシュボードによる可視化・分析** - APM(Application Performance Monitoring)を活用し、リクエストごとの処理時間を詳細に可視化 - スロークエリの自動検出とトレース機能により、ボトルネックとなっているクエリを特定 - データベースクエリの実行時間、頻度、エンドポイントとの紐付けを分析 - 使用技術: Datadog APM、カスタムダッシュボード **2. データベースクエリの最適化** **インデックス追加・最適化:** - スロークエリ分析の結果、テーブル結合が多い検索系クエリを特定 - WHERE句で頻繁に使用されるカラムにインデックスが欠落している箇所を発見 - 適切なインデックス設計を行い、複合インデックスも含めて追加 - EXPLAIN文を使用してクエリ実行計画を確認し、インデックスの効果を検証 **クエリの書き換え:** - 不要なJOINやサブクエリを削減 - データアクセスパターンを見直し、取得するカラムを必要最小限に絞り込み - 使用技術: Ruby on Rails(ActiveRecord)、MySQL、EXPLAIN分析 **3. N+1クエリ問題の解消** - コードリーディングにより、ループ内で発生していたN+1クエリの発生箇所を洗い出し - `includes`メソッドや`joins`メソッドを適切に使用し、Eager Loadingを実装 - 1リクエストあたりのクエリ数を大幅に削減 - 使用技術: Ruby on Rails(ActiveRecord)、Bullet gem(N+1検出) ### 使用技術 - **言語・フレームワーク:** Ruby on Rails、TypeScript、Vue.js - **データベース:** MySQL - **インフラ:** AWS(RDS) - **監視・分析:** Datadog APM、Datadog Database Monitoring - **開発ツール:** Bullet(N+1検出)、EXPLAIN(クエリ分析) ### 成果 - **レスポンス速度の改善:** 平均レスポンスタイムを40%以上短縮(例: 平均3秒→1.8秒) - **ピークタイム安定化:** ユーザー数が多い時間帯でも安定したパフォーマンスを維持できるように - **データベース負荷軽減:** クエリ実行時間の削減により、DBサーバーのCPU使用率が低下 - **ユーザー体験の向上:** ページ遷移やデータ取得のストレスが大幅に軽減 - **開発効率向上:** Datadogダッシュボードにより、今後のパフォーマンス劣化を早期発見できる体制を構築 ### 工夫した点・学び - まずDatadogで可視化することで、勘に頼らずデータドリブンに改善箇所を特定 - インデックス追加による書き込み性能への影響も考慮し、読み取り・書き込みのバランスを検証 - 改善後もDatadogで継続的にモニタリングし、効果測定と新たなボトルネックの早期発見を実現