ID:68789さん

## サービス概要 医師向けのプラットフォームサイトのうち、製薬企業が医師向けに開催する、薬剤に関する講演会を支援するサービスです。講演会開催に関する情報配信・申込管理・運営支援などを提供しており、主に製薬企業からの開催費用を収益源としています。 ## チーム体制 組織構造の再編が何度かあり、時期によってサーバーサイドエンジニア3〜7名程のチーム体制で開発をしていました。 ## サービスの特徴と技術的な難しさ 長年運用されており、仕様やデータ構造が複雑化している部分が多く、改修時の影響調査に工数を要する傾向がありました。 また、講演会が一斉に始まる時間帯にはアクセスが集中し、ピーク時の負荷対策が重要な課題となっていました。 ## 役割・担当業務 サーバーサイドエンジニアとして、以下の業務を担当しました - 既存機能の改修・保守 - 不具合調査およびインシデント対応 - アクセス集中時のパフォーマンス改善施策の設計・実施 - Datadogなどを活用した監視基盤の整備 - 負荷試験基盤の構築 ## 経験した仕事：パフォーマンス改善（2025年2月〜4月） ### 背景・概要 製薬企業が医師向けに開催する講演会の管理サービスにおいて、講演会の開催時刻にアクセスが集中する特性がありました。 年々講演会の開催規模は増加していたのですが、特に規模の大きい講演会を開催した場合、システムにかかる負荷がかなり限界に近いことが分かったため、パフォーマンス改善の取り組みを行いました。 ### 1. 各API個別のパフォーマンス改善 【課題】 システム全体のレイテンシがピーク時に大きく上昇し、特に一部の重いAPIがボトルネックとなっていました。 また、レイテンシ改善のためにはどのAPIから優先的に手を入れるべきか、明確な基準がない状態でした。 【対応】 まず、DatadogのAPMやログを活用して以下の観点からボトルネックとなるAPIを可視化しました： - p50, p95パーセンタイルのレイテンシ - リクエスト回数 特に影響の大きいものから優先順位をつけ、以下のような対応を行いました - DBインデックスの最適化：クエリ実行計画を分析し、必要なインデックスを追加 - キャッシュの導入：RedisやHTTPキャッシュを活用し、APIのレイテンシやアクセス回数を低減 - 仕様変更による削減：APIが提供する情報の特性に応じて、ビジネス観点で許容できる範囲内で時間単位のキャッシュを導入 【成果】 - 一部のAPIのレスポンスタイムを50ms以上の改善 - 一部のAPIのリクエスト数を数分の1未満まで削減 リリース後はその効果検証まで行い、実際にたしかにパフォーマンスが改善されたことまで確認をしていました。 ### 2. リリース後の性能劣化を防ぐ監視体制の整備 【課題】 別チームのエンジニアを含む同一リポジトリを触る他のメンバーによる改修で、リリース後に思わぬAPIのパフォーマンス悪化が起きていたとき、それに気づくことなくアクセスピーク時刻を迎えてしまうリスクがあり、仕組みとして改善したいという課題がありました。 【対応】 DatadogのMonitor機能を使い、リリース後2時間のAPIレイテンシを先週の同時間帯と比較して監視し、大幅に悪化していた場合はアラートを出す監視を構築しました。 【成果】 性能劣化の早期検知が可能になり、改修によるパフォーマンス悪化をいち早く察知・対処できる体制を整備しました。 ## 経験した仕事：負荷試験基盤の構築（2025年6月〜2025年9月） ### 背景・概要 先述のパフォーマンス改善により、現状のシステムにおいて負荷の限界が迫ることを予防することはできました。 ですが他の課題として、そもそもシステムに負荷の上限が設けられていることにより、同時間帯に開催できる講演会数を制限しなければならないというビジネス上の課題もありました。 根拠をもって上限を引き上げるために、システムの負荷の上限を精度高く計測するための仕組みとして、負荷試験基盤を構築することになりました。 ### 1. 負荷試験基盤のリード 負荷試験基盤を構築するにあたって、そのプロジェクトのリードを務めました。 下記のチーム構成で進め、アーキテクチャの策定から、構築完了後の完了報告までを完了させました。 - プロジェクト管理・設計・メインの実装：私 - 一部の実装：チーム内の別のエンジニア1名 - 設計等のアドバイス・コードレビュー：SREや技術顧問を含む数名のエンジニア また、リードを務めるにあたっては、はじめに下記の開発の指針を定め、プロジェクト進行中に判断に迷ったときの指針とするようにしました。 - 誰でも安全に負荷試験をできる環境が用意されていること - 計測したい負荷 (講演会の同時開催時の大量アクセス) を正しくかけることができ、その負荷を計測できるようになっていること - まずは最低限動く状態を目指して作ること マネジメントについての詳細は「マネージメント能力」欄の2個目の欄に記載しています。 ### 2. 負荷試験基盤の設計 負荷試験基盤を作るにあたって、まずは他社のテックブログ等をよく読み、負荷試験の事例を集めました。 続いて、本プロジェクトの目的や現状のシステム構成等を鑑みて、負荷試験基盤の大方針である「既存の Staging 環境を、負荷試験実施時のみ本番相当の性能に上げ、その Staging 環境宛に負荷試験ツール (k6) から負荷をかける」をまずは定めました。 それをもとに、「負荷がかかる環境 (Staging環境)」「負荷をかける方法とその環境」「負荷試験のワークフロー」ごとに、その設計や実装のタスクに切り出し、それぞれ進めていきました。 ### 2. 負荷試験基盤の実装 主に下記の実装を行いました。 - Staging環境の terraform ファイルの修正 - terraform変数を用いて、Staging環境の性能を簡単に変更できるように修正 - 負荷試験ツール (k6) を動かすため環境の構築 - k6が入ったDockerコンテナを動かす ECS 環境の構築 - シナリオファイルの実装 - 予め調べていたリクエストパターンを模したリクエストが送られるようにシナリオ定義を作成 - 試験のワークフローの実装 - GitHub Actions によりインフラ性能の変更や負荷試験が自動で行われるワークフローを作成 - モニタリング手段の用意 - Datadog のダッシュボードを作成 ## 成果 結果としては、プロジェクトの目的に対して必要十分な成果物を作成できたと自負しています。 負荷試験基盤を活用した具体的な成果としても、下記の成果を上げています。 - 受け入れ可能な負荷上限の引き上げ - 実際に負荷試験を実施することで、以前は安全側に倒して設定していた受け入れ上限を根拠を持って引き上げることができました - インフラ性能の調整によるコスト削減 - 負荷試験の結果、データベースのCPU使用率には十分な余裕があることが判明し、データベースのスケールダウンを行う計画が立案されました ## その他 また負荷試験基盤の構築後、テックブログを執筆しました。 上記取り組みの詳細を書いており、ぜひ読んでいただけますと幸いです。 [MedPeer で負荷試験基盤を構築しました - 定量的な計測のための精度の担保と自動化のコツ - メドピア開発者ブログ](https://tech.medpeer.co.jp/entry/2025/10/01/175835) またその後、上記の記事をきっかけに Findy Tools 様の方からお声がかかり、Findy Tools のサイトに k6 のツールレビューの記事を寄稿しました。 [Grafana k6 を利用した負荷試験基盤の構築](https://findy-tools.io/products/grafana-k6/359/813)

## サービス概要 歩数計機能を中心に、健康情報の配信やクイズ機能を備えたtoC向け健康アプリです。ユーザーの健康状態に応じたセグメント配信や、健康関連企業と連携した広告・アンケート施策により、高単価な広告収入を主軸にマネタイズしていました。 アクティブユーザーはDAU約50万人、総ユーザー数300万人規模のサービスでしたが、残念ながら全社の方針により、2024年11月をもってサービスはクローズしました。 ## チーム体制 - サーバーサイドエンジニア：3〜4名 - モバイルエンジニア（iOS/Android）：3名 - プロダクトマネージャー：1名 - インフラエンジニア（全社横断）：1名 - その他業種のメンバー：若干名 すべての開発メンバーは自社所属で構成されており、資金は協力会社との共同出資型のサービスとして運営されていました。 ## サービスの特徴 - バックエンド：Ruby on Rails - フロントエンド：Swift（iOS）、Kotlin（Android） - 特徴 - DAU50万人規模のtoCサービス - 一部テーブルは2億レコード超の規模で、クエリ最適化やインデックス設計などパフォーマンに注意が必要 - 協力会社の外部会員基盤とのOAuth連携を含むシステム構成で、認証まわりを含むユーザー関連の改修の際には他社との調整が発生 ## 役割・担当業務 サーバーサイドエンジニアとして、以下を担当しました - 新機能の開発および運用保守 - 不具合調査・対応 - 軽微なインフラ設定の修正（監視設定・アラート調整など） 後半からはサーバーサイドチームのリーダーを担当し、以下も対応しました - タスクの優先度管理・進行調整 - サービスクローズに向けた対応計画と機能停止処理の実装 ## 経験した仕事：会員情報項目追加に伴う3者連携リリースの調整と実装（2023年7月〜2023年8月） 【課題】 ユーザーの基本情報（生年月日・性別など）に新たな項目を追加するにあたり、アプリ・サーバー・協力会社の会員基盤の3システムを同時に切り替える必要がありました。 それぞれのリリースタイミングや仕様に制約があり、システム間の整合性を保ったうえで安全にリリースする難しさがありました。 【工夫】 スムーズなリリースに向けて、技術面・調整面の両方で工夫を行いました。 - 各システム間の依存関係やQAに必要な組み合わせパターンを整理し、クリティカルパス図でリリーススケジュールを可視化しました - サーバーサイドが中継点にあたる構成だったため、仕様設計・実装だけでなく全体調整のハブ役としてリリースを主導しました - 実装ではフィーチャーフラグを活用し、QAのために他のリリースを滞らせない方法をとりました 【成果】 各チームと連携を取りながら調整・実装を進めた結果、3システムを跨ぐ変更にもかかわらず大きな混乱なく本番移行を完了できました。 また、クリティカルパス図による整理がチーム内の認識共有に役立ち、リリース全体の品質とスピードの両立に貢献していたと思います。 ## 経験した仕事：目標歩数機能の開発（2023年12月〜2024年1月） 【課題】 ユーザーが毎月の目標歩数を設定・記録できるようにするにあたり、履歴管理が必要でした。 履歴データをRDBでどう持たせるかは一般的な定石がなく、パフォーマンスや保守性に配慮した設計が求められました。 【工夫】 履歴テーブルの構成案を複数検討し、それぞれの「パフォーマンス」「複雑さ」「正規化の程度」といった観点で比較しました。 チームとも相談しながら構成を決定し、リリース後の負荷計測も実施することで、理論と実測の両面から設計の妥当性を検証しました。 【成果】 シンプルかつ拡張性の高いテーブル設計を実現し、過去データを安全かつ効率的に扱える仕組みを導入しました。 リリース後の負荷も想定範囲内に収まり、安定した運用につながりました。 ## 経験した仕事：夜間JOBのパフォーマンス改善（2024年4月） 【課題】 毎晩実行されるバッチ処理（夜間JOB）の実行時間が長く、サーバーや他処理への影響が懸念されていました。 停止を伴うDBメンテナンスが難しい状況での対応が求められました。 【工夫】 重いテーブルへの適切なインデックスの追加と、該当JOBのロジックの修正を行いました。 - インデックス追加については、MySQLのオンラインDDL機能を活用し、メンテナンス停止を避けながら実行しました。 - マイグレーション実施時には、正常パスに加えて不具合時の対応フローまで含んだ詳細な手順書を作成しました。 - JOBロジックの修正時には、万一の不具合を考慮し、ダークローンチ（裏で新旧両方の処理を走らせて結果を比較し、問題ないと判断後に完全に切り替え）を提案・実施しました。 【成果】 JOBの実行時間が大幅に短縮され、夜間処理の安定性が向上しました。 停止なしでのインデックス追加や、安全性を担保したデプロイにより、リスクの高い変更もスムーズに完了させることができました。 ## 経験した仕事：サーバーサイドのタスク管理（2024年7月〜2024年11月） 【課題】 サービスクローズが決定し、その頃からサービスのサーバーサイドのリーダーを担当することになりました。クローズに際して期日のある開発タスク（指定時刻に指定の機能の仕様を変更する、など）が急増したことで、従来のタスク管理手法では進捗の把握や担当の割り振りが困難になっていました。 【工夫】 まずは現状のタスク管理方法を分析し、以下のような課題を洗い出しました： - 他サービスと開発を兼任しているメンバーがおり、担当者を決めにくい（各メンバーの忙しさが不明） - 着手時期・進行状態が視覚的に把握できない - 締切が迫ったタスクの事前検知が困難 この課題に対し、以下のようなタスク管理の仕組み化を行いました： - 既存のタスク管理ツール（Github Projects）上の「待ち」ステータスを更に細分化（例：「リリース待ち」「他の人待ち」「着手時期待ち」） - タスクに「着手開始日」「終了予定日」の属性を追加し、ガントチャートで可視化 - 各メンバーの稼働状況を毎週記入してもらう運用を導入し、担当決めを円滑化 - タスク整理の定例ミーティングを設定し、仕組みとして定着 - リリース予定をチームで共有する仕組みを導入し、リリース忘れを防止 【成果】 タスクの可視化と管理手法の改善により、締切のある複数タスクをスムーズに進行でき、トラブルなくサービスを終了させることができました。 ## 経験した仕事：データ連携を行う並列システムの開発（2024年5月〜2024年11月） 【課題】 サービス終了に伴い、DB内の各種ユーザーデータ（歩数、ポイント、アンケート履歴など）を、指定フォーマットのTSV形式で協力会社側S3へ連携する必要がありました。 ユーザー数・データ量ともに多く、限られたスケジュール・インフラリソースの中で、信頼性や高い性能が求められるデータ送信基盤を構築する必要がありました。 データ連携の実施自体はクローズの早い段階から決まっており、仕様策定のみは他タスクと並行して早めに進めていました。9月頃から11月頃にかけて、時には先輩エンジニアからの助言も借りつつ、設計と実装、連携本番までを完遂させました。 【工夫】 - **連携する内容の交渉** 初期の要件ではすべてのユーザーデータを送る想定でしたが、テーブル数の多さから開発コストが膨らむ懸念がありました。 内容を精査し、ビジネス上不要と思われるテーブルを送信対象から外すことを提案・交渉し、連携対象テーブル数を当初の半分以下に削減しました。 - **連携タイミングの分割** サービスクローズ後にAWS環境を1週間程で閉じたいというビジネス要件があったため、連携データすべてを終了後に初めて送るのはリスクが高い状況でした。 ほとんどのデータが過去データが更新されないログ系・履歴系のデータであることに着目し、それらのデータはクローズ前にその日の分までのデータは予め連携する方法を提案し、大半のデータはクローズ前に送信完了できる方法で連携を行いました。 - **並列実行可能な連携システムの設計** とはいえデータ量が膨大なため、単一の処理で現実的な時間内に連携ができる見込みは到底ありませんでした。 複数の連携処理を同時に走られることができる並列システムを設計し、性能調整と耐障害性を意識したシステム構成にしました。 「日付 × テーブル」単位でJOBを分割し、各JOBが次のJOBをキューに入れる仕組みの、スーパーバイザー相当のJOBが存在しない設計で並列システムを設計しました。 並列実行数Nは管理画面で動的に変更可能とし、途中で並列数の調整や処理の中断・再開ができるような設計を行いました。 - **パイプライン・ミドルウェアアーキテクチャの導入** JOBの内部処理は「データ取得 → 加工 → 書き込み → アップロード」と段階を分け、各処理単位を「タスク」として同一のインターフェースでクラス化し、シェルのパイプラインのようなアーキテクチャで実装しました。 JOBは必要なタスクを組み合わせて動作する仕組みとし、柔軟性や保守性の高い構成としました。 また、JOB間のデータの受け渡しは、戻り値としてではなく引数のクロージャ（Rubyではブロック）に対して渡すような、ミドルウェアアーキテクチャのような継続渡しスタイルの書き方で実装し、本処理後の後処理のようなものも自然に記述できるようにしました。 【成果】 処理対象のスケールに耐えうる堅牢な仕組みを期間で構築し、サービスクローズ直後のタイミングで、トラブル無くデータ連携を完了させることができました。 また、対象範囲の見直しによる開発効率の向上や、システムの汎用性・見通しの良さにもこだわり、自身にとっても集大成といえる設計や実装を行うことができました。

## サービス内容 toB向けの労務管理SaaSを提供しているサービスです。 大学時代に長期インターンとして働いていました。 ## 仕事内容 開発メンバーとして、サーバーサイドにRuby on Rails、フロントエンドにReactを用いて開発していました。 主に機能開発や細かな改修を行いつつ、Ruby(2.7から3.0へ)やRails(6.1から7.0へ)のバージョンアップのタスク等も担当しました。 サーバーサイドではマイクロサービスに切り出さていた機能もあり、マイクロサービス間の通信にはgPRCを、フロントエンドとの通信にはGraphQLを採用している箇所もありました。フロントエンドではRedux, RxJSなどのフレームワークを利用している箇所もあり、様々な思想のライブラリに触れることができた環境でした。 ユーザーが機能を自社向けにカスタマイズできるようなUI/UXを提供していることや、労務関係というドメインの広さも複雑さも大きい分野のサービスということもあり、フロントエンド・サーバーサイド両方の面でアルゴリズム的な難しさのある機能開発に携わることが多かったと思います。

## サービス内容 toB向けに、様々なサイトから広告情報をクローリングし、その集めたデータを提供するWeb画面を提供しているサービスです。 ## 仕事内容 大学生時代にアルバイトとして働いていた会社です。 Webクローラーの開発には素のRubyを使用し、Web画面にはRuby on Railsを使用していました。 Webクローラーの開発では、HTTPプロトコルレベルのアプローチから、Webブラウザ上でJavaScriptを実行するアプローチまで、各種知識を総合的に用いた開発を行っていました。 Web画面の開発では、機能開発の他、画面のパフォーマンスの改善等のタスクを担当していました。 他には、収集したデータの加工の分野の開発も一部行っており、PDFファイル内の表データを画像解析を組み合わせて抽出するような機能の開発等も行っていました。 会社の技術ブログの執筆もしており、下記の記事などを書いてきました。 - [PDFに埋め込まれたテーブルを、画像処理でパースする](https://rooter.jp/web-crawling/parse_table_from_pdf/) - [クローリングする際に調整したいHTTPリクエストパラメータ](https://rooter.jp/web-crawling/http-request-parameter-for-crawling/)