カトウ

## プロジェクト概要 自社Webサービスの運用チームにおいて、お客様からの技術的な問い合わせ・依頼対応を実施し、安定したサービス運用を支えました。 ## 役割・体制 ### 自身のポジションと役割 - 運用チームのリーダーとして、問い合わせ対応の優先順位付けや進捗管理を担当しました。 - コードリーディングとデータベース調査を行い、不具合の原因特定と仕様確認に従事しました。 - SQLを用いたデータ修正業務を担当し、システムの安定稼働を支援しました。 ### チーム規模と構成 - 正社員エンジニア1名と業務委託エンジニア2～3名の計約3～4名規模のチームで運用業務を行いました。 ## 背景・課題 - カスタマーサポートで対応しきれない技術的な問い合わせや依頼が増加し、対応工数が膨大となっていました。 - 依頼量が物理的に処理しきれず、対応遅延や品質低下の懸念が常態化していました。 ## 実際の取り組み ### 開発環境 - バックエンドにRuby on Rails、フロントエンドにCoffeeScriptとjQueryを使用し、AWS環境上でサービスを運用しました。 ### 改善内容 - 対応期限のデフォルトを1週間に設定し、それより短い期限のある場合の例外ルールを明確化し、優先度の高い問い合わせに集中できる体制を構築しました。 ### その他アピールポイント - 問い合わせ対応業務と開発業務の役割分担を明確化し、開発チームの作業集中環境を実現しました。 ## 成果・価値 - 運用体制の見直しにより、対応漏れや遅延が減少し、サービスの安定稼働に貢献しました。 - 問い合わせの期限設定と優先対応の運用ルールにより、業務効率が向上し、チームの課題対応力が強化されました。 - 開発チームが集中して開発業務に取り組める環境を整え、プロダクト品質向上に寄与しました。

## プロジェクト概要 古くなったPostgreSQLデータベースとRuby on Railsフレームワークのバージョンアップ対応を実施し、システムのパフォーマンスとセキュリティを向上させました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、マイクロサービスのPostgreSQLクライアントおよびRuby on Railsのアップグレード作業を担当しました。 - 全体のアップグレード進捗管理を行いました。 - テスト環境のデータベースサーバアップグレードも担当し、環境整備と動作検証を行いました。 ### チーム規模と構成 - エンジニア約10名とQAエンジニア1名の計約11名のチームで、各担当が分かれてマイクロサービスのアップグレードを進める体制でした。 ## 背景・課題 - PostgreSQLやRuby on Railsのバージョンが古くなり、パフォーマンス低下やセキュリティリスクが懸念されていたため、最新バージョンへのアップグレードが必要でした。 - アップグレードに伴う互換性問題により、既存のテストケースが通らなくなり、修正作業が多発したことが最大の課題でした。 ## 実際の取り組み ### 開発環境 - AWS環境上に構築された複数のマイクロサービスを対象に、PostgreSQLのクライアントやサーバのバージョンアップを段階的に実施しました。 - マイクロサービスの依存関係を調査し、アップグレードに伴う影響範囲を明確化しました。 ### 設計・改善内容 - 各マイクロサービスで利用するライブラリのRails各バージョンへの対応状況を調査し、非互換なAPIや廃止された機能を特定して修正を行いました。 - アップグレードの状況を可視化することで、チーム全体の作業調整を行いました。 ### その他アピールポイント - アップグレードに伴うパフォーマンス改善効果を定量的に把握するため、効果測定を実施しました。 - システムの安定稼働を維持しつつアップグレードを推進し、サービス継続性の確保に貢献しました。 ## 成果・価値 - アップグレードによりシステムのパフォーマンスが向上しました。 - セキュリティリスク低減に寄与しました。

## プロジェクト概要 Webサービスのレスポンス改善を目的に、キャッシュ化や非同期処理導入、またデータベース負荷軽減のためのSQL最適化を実施しました。 ## 役割・体制 ### 自身のポジションと役割 - バックエンドエンジニアとして、コーディングおよびテストを担当しました。 - 負荷のボトルネック特定のためログ調査や計測用ログの追加実装を行い、問題箇所の可視化に貢献しました。 ### チーム規模と構成 - リーダー、SRE、私（エンジニア）の計3名チームで、負荷軽減施策を推進しました。 ## 背景・課題 - Webサービスのレスポンス遅延が顧客体験を損ね、根本原因となるサーバ負荷の軽減が急務でした。 - ボトルネックの特定が最大の課題であり、パフォーマンス計測とログ分析が必要でした。 ## 実際の取り組み ### 開発環境 - バックエンドはPerlとRuby on Railsを併用し、PostgreSQLをデータベースとして利用しました。 - 開発手法は社内独自のアジャイルに近い手法で、短期間のフィードバックループを重視しました。 ### 設計・改善内容 - SQLやアプリケーションのソースコードのパフォーマンスチューニングを実施し、インデックス最適化を中心に改善を行いました。 - システム全体の負荷分散を図るため、DBの分割を適用しました。 - 処理の一部を非同期化し、リアルタイム負荷の軽減に成功しました。 - 処理の一部をキャッシュ化し、負荷の軽減に成功しました。 - ボトルネック箇所特定のためにログを詳細化し、計測用ログを追加してリリースすることで、問題箇所の特定精度を高めました。 ### その他アピールポイント - 負荷軽減施策によりユーザーがアクセスしづらかった画面の改善に寄与し、ユーザビリティ向上に貢献しました。 ## 成果・価値 - プロジェクト全体としてAmazon RDSのCPU使用率が最大で約60%程度まで低減し、システムの安定稼働を実現しました。 - レスポンス遅延により利用が制限されていた画面を開けるようになり、ユーザー体験が大幅に改善されました。