ID:72273さん

# プロジェクト概要 複数のEC・物流サービスと連携する物流プロダクトにおいて、注文・在庫管理・配送設定などの外部サービス連携機能の開発・運用を担当しています。 顧客要望や外部サービスの仕様変更に伴う機能開発に加え、本番障害、注文・在庫データの不整合、外部API連携失敗などの調査・復旧・恒久対応まで幅広く担当しています。 ## チーム情報 運用改善を担当する開発チームにエンジニアとして所属しています。 PdMや顧客対応部門などと連携して要件や優先度を整理し、自身は仕様調査、設計、実装、テスト、リリース、障害対応までを担当しています。 ## 本番障害・データ不整合への対応 ### 課題 外部APIの失敗や注文・在庫データの不整合など、複数システムをまたぐ問題が発生するため、単一のログやコードだけでは原因を特定できないケースがありました。 ### 工夫したこと 既存コード、アプリケーションログ、DBのデータ、外部サービスの仕様、過去の問い合わせ履歴を横断して確認し、事象を再現できる条件や影響範囲を整理しました。 単に原因を特定するだけではなく、復旧方法、必要なデータ補正、恒久修正、再発防止までを一連の対応として整理し、関係者と優先度を合わせながらリリースまで進めています。 ### 成果 入社2〜3か月後から、本番不具合や注文・在庫不整合など複数の事象について主担当として対応できるようになりました。 未知の物流ドメインや既存システムに短期間でキャッチアップし、調査から実装・リリースまで自立して対応しています。 ## 顧客要望・外部仕様変更に伴う機能改善 ### 課題 外部サービスの仕様変更や顧客の業務要望に対応する際、既存の注文・在庫処理への影響を考慮しながら変更する必要がありました。 ### 工夫したこと PdMや顧客対応部門から得た要望をそのまま実装するのではなく、既存仕様との整合性や影響範囲を確認したうえで、必要な変更を整理しました。 PHP / Laravel / SQLを中心に実装し、テストからリリースまで一貫して担当しています。 ### 成果 入社後、6件以上の機能改善をリリースし、重大な不具合を発生させることなく継続的な機能変更に対応しました。 ## 定期運用の廃止 ### 課題 外部サイトの情報を確認するための手動作業とスクレイピング処理が残っており、継続的な作業工数と保守コストが発生していました。 ### 工夫したこと 処理そのものを自動化するのではなく、まず作業目的と依存関係を調査しました。 その結果、別の方法で目的を満たせることを確認し、スクレイピングや手順そのものを不要にする方向で整理しました。 ### 成果 定期的に発生していた手動作業を完全に廃止し、継続的な運用工数と保守対象を削減しました。 ## 使用技術 PHP / Laravel / SQL / AWS / Docker

# プロジェクト概要 SaaS型マーケティングツール「Rtoaster action+」の機能維持管理・継続改善を担当しました。 月間約60億件のトラッキング・レコメンドリクエストを処理する、17年以上運用されてきたプロダクトで、管理画面、トラッキング、レコメンド、データ基盤など複数のシステムで構成されています。 定期リリース、機能開発、問い合わせ対応、障害対応、ドキュメント整備、開発プロセス改善などを行い、既存機能の品質と安定性を維持しながら継続的な改善に取り組みました。 # チーム情報 開発チームのメンバーとして参加し、2025年5月からはチームリーダーを担当しました。 - チーム規模：4名程度（最大8名） - 役割：エンジニア、チームリーダー - 担当領域：管理画面、トラッキング、レコメンド、データ基盤 - 担当工程：要件整理、設計、実装、テスト、リリース、運用、障害対応 チームリーダーとしては進捗や担当の調整を行いつつ、自身も実装や技術的な調査を継続しました。 # 長期運用プロダクトの安定運用・改善 ## 課題 長期間運用されているため、複数世代の技術スタックや既存仕様が混在しており、変更による影響範囲が広いプロダクトでした。 また、大量のリクエストを処理するサービスであるため、機能追加だけではなく既存機能を安定して動かし続けることも重要でした。 ## 工夫したこと 機能変更や障害対応では、対象コードだけではなく、関連するデータ、周辺システム、既存仕様まで確認して影響範囲を整理しました。 問題が発生した際には、原因調査だけでなく、恒久対応、関係部署との調整、リリースまで一貫して担当しました。 また、一時的な対応で終わらせず、ドキュメント整備やテスト、自動化などを通じて、同じ問題を繰り返しにくい状態へ改善することを意識しました。 ## 成果 長期間運用されるプロダクトにおいて、大きな品質問題を発生させず、継続的な機能改善と安定運用を両立しました。 こうした取り組みを含むチームの活動が評価され、部署内イベントでチームとして表彰された経験もあります。 # オンボーディングの改善 ## 課題 システム数や技術スタックが多く、新しく参加したメンバーがプロダクト全体を把握するまでのコストが高い状態でした。 特に、個別のコードやシステムについての情報は存在していても、それぞれがどのように関連しているかを理解しづらいことが課題でした。 ## 工夫したこと チームでC4モデルを用いてシステム構成を整理しました。 自身はトラッキング・レコメンドとデータ基盤を中心に、システム間の関係や責務を可視化しました。 また、ドキュメントを一度作成して終わりにせず、新規メンバーの受け入れ手順に更新作業を組み込み、継続的にメンテナンスされる仕組みにしました。 ## 成果 新規メンバーがプロダクトへ参画しづらい状態を改善し、毎年2名以上のメンバーが開発へ参加できる状態を作りました。 # プロダクト利用状況の可視化 ## 課題 新機能や画面ごとの利用状況を確認する共通の手順がなく、リリース後の効果確認を行うたびに個別の調査が必要でした。 ## 工夫したこと プロダクト内の行動計測データをBigQueryで集計し、ページ訪問数や新機能の利用状況をLooker Studioで可視化しました。 また、個人だけが分析できる状態にならないよう、再利用可能な集計・確認手順として整備しました。 ## 成果 企画や開発の関係者が継続的に利用状況を確認できる環境を構築し、リリース内容の検討や効果確認に利用できるようにしました。 # 使用技術 TypeScript / Java / Python / C++ / Vue.js / Nuxt.js / Spring / Flask / PostgreSQL / BigQuery / GKE / Dataflow / Airflow

# プロジェクト概要 Rtoaster action+で蓄積されるユーザー行動・購買履歴を処理するデータ基盤の開発・運用を担当しました。 月間約60億件のトラッキング・レコメンドリクエストから得られるデータを対象に、ETLパイプライン、日次・月次の集計バッチ、データ提供用ビューなどを運用・改善しました。 BigQuery、Cloud Composer、Dataflowなどを利用し、既存処理の障害対応や性能改善にも取り組みました。 # チーム情報 Rtoaster action+の開発チームの一員として、データ基盤領域を担当しました。 自身は、既存処理の調査、原因分析、改善案の検討、関係者への説明、実装、検証、リリースまでを担当しました。 # BigQueryクエリの性能改善 ## 課題 特定顧客が保有する大量かつ特殊なデータパターンによって、BigQuery上の再帰的なJOIN処理で組み合わせ数が急増し、クエリが完了しない問題が発生していました。 同一プロジェクト上で複数顧客の処理を行っていたため、単一顧客の問題に留まらず、他顧客の処理にも影響する状態でした。 ## 工夫したこと 単純にクエリを書き換えるのではなく、BigQueryの実行グラフと実データのパターンを確認し、どの処理でデータ量が増加しているかを調査しました。 その結果、JOIN対象に重複データが多く含まれていることで、後続の再帰的なJOINにおいて組み合わせが爆発していることを特定しました。 対策として、JOIN処理そのものを大きく変更するのではなく、JOIN前に不要な重複データを除外する方法を提案しました。 変更による影響範囲や他の選択肢も整理して関係部署へ説明し、合意形成後は自身で実装、検証、リリースまで担当しました。 ## 成果 完了しなかったクエリを正常に完了できる状態まで改善しました。 また、一時的なリソース増強などではなく、問題を発生させていたデータ構造と処理の関係を特定して恒久対応を行ったことで、リリース後は同様の問題が再発していません。 # データ基盤の開発・運用 ## 担当内容 以下のようなデータ処理の開発・運用に携わりました。 - ユーザー行動・購買履歴を処理するETLパイプライン - 日次・月次の集計バッチ - 他機能へデータを提供するBigQueryビュー - 既存データ処理の障害調査・性能改善 個別の処理だけを見るのではなく、入力データ、データ変換、集計処理、利用側までを追いながら問題を調査する経験を積みました。 # 使用技術 BigQuery / Cloud Composer / Dataflow / Python / SQL / GCP

# プロジェクト概要 Rtoaster action+の効果測定機能について、従来よりも詳細に施策効果を確認できるよう改善するプロジェクトを担当しました。 従来は確認できる指標が限られており、レコメンド施策の費用対効果を把握しづらい状態でした。 そこで、レコメンド有無の比較や金額ベースの効果を確認できるよう、画面・API・集計処理・データ構造を横断した機能改善を行いました。 # チーム情報 - チーム規模：6名 - 役割：プロジェクトリーダー - 担当工程：要件定義、基本設計、詳細設計、デザインレビュー、実装、テスト、リリース、マニュアル作成 プロジェクト全体のタスク分解、担当・工数・依存関係の整理、進捗管理、仕様調整を担当しました。 また、管理だけではなく、自身もフロントエンド、バックエンド、BigQueryの集計処理を実装しました。 # 効果測定機能の設計・開発 ## 課題 新しい指標を追加するためには、画面だけではなく、集計ロジック、API、BigQueryのスキーマなど複数レイヤーを整合させる必要がありました。 また、関係部署との仕様調整やリリース計画も必要だったため、技術的な実装とプロジェクト推進を並行して進める必要がありました。 ## 工夫したこと まず、必要な機能をタスク単位に分解し、担当者、工数、依存関係を整理しました。 そのうえで、集計指標、API、画面、データスキーマの整合性を確認しながら仕様を決定しました。 自身も実装に入り、フロントエンド、バックエンド、BigQueryの集計クエリを横断して開発しました。 また、関係者との認識差が後工程で問題にならないよう、仕様やリリース計画について随時認識を合わせながら進行しました。 ## 成果 要件定義からリリースまでを計画どおりに完遂しました。 従来よりも詳細な効果測定が可能になり、顧客がレコメンド施策の効果を金額ベースで確認できる機能を提供しました。 # 大量データを扱う集計処理の設計 ## 課題 大量データを画面表示のたびに集計すると、クエリ負荷が高くなり、表示速度にも影響します。 一方で、集計ロジックが複雑になるほど、手動テストだけではテスト工数や見落としのリスクが高くなる問題もありました。 ## 工夫したこと 過去データについては事前にバッチ集計し、直近データのみを都度集計したうえで統合する構成を採用しました。 これにより、画面表示時に処理するデータ量を抑えつつ、最新のデータも反映できる構成にしました。 また、BigQueryの集計ロジックについて、入力データと期待値をセットで定義し、集計結果を自動で検証できるテスト環境を構築しました。 ## 成果 画面表示時のクエリ負荷を抑えながら、必要な効果測定結果を提供できるようになりました。 また、複雑な集計ロジックについても自動テストで継続的に検証できるようになり、変更時の品質を担保しやすい開発基盤を整備しました。 # 使用技術 Python / Java / TypeScript / Vue.js / Nuxt.js / Spring / Flask / PostgreSQL / BigQuery

# プロジェクト概要 Rtoaster action+の管理画面について、JavaScript / Riot.jsで実装されていた約300ページを、TypeScript / Vue.js / Nuxt.jsへ段階的に移行するプロジェクトに参加しました。 長期間運用されてきたプロダクトであり、一括での全面移行では開発期間の長期化やデグレードのリスクが高かったため、旧実装と新実装を共存させながら、ページ単位で段階的に刷新しました。 # チーム情報 - チーム規模：4名程度（最大7名） - 役割：エンジニア - 担当工程：技術選定、設計、実装、テスト、レビュー、リリース、運用 チーム全体で移行方針や共通基盤を検討し、自身は個別機能の設計・実装・テストに加え、移行しやすい実装パターンの整備にも関わりました。 # 旧実装と共存する段階移行 ## 課題 約300ページを一括で書き換えると、リリースまでの期間が長くなり、変更量の増大によってデグレードリスクも高くなる状態でした。 また、長期間運用されてきたため、画面ごとにデータ構造の世代差や過去の仕様経緯が残っており、特に利用頻度の高い重要機能ほど単純な置き換えが難しい状況でした。 ## 工夫したこと 旧ライブラリと新ライブラリを共存できる構成を採用し、ページ単位で移行できるようにしました。 自身の実装では、旧コードをそのまま置き換えるのではなく、TypeScriptでデータ構造を明示し、責務を分割したうえで、Vue.js / Nuxt.jsの構成に合わせて再設計しました。 また、主要な画面についてはJestを用いた振る舞いベースの自動テストを整備し、段階的なリファクタリングや機能追加を安全に行えるようにしました。 ## 成果 ページ単位でQAとリリースを行える状態を作り、一括移行に伴うリスクを抑えながら段階的な刷新を実現しました。 特に重要度の高い機能についても安全に移行し、リリース後に当該機能を原因とする不具合は発生しませんでした。 # コードレビュープロセスの改善 ## 課題 大規模なPRやレビュワーの属人化によって、レビュー待ちが開発全体のボトルネックになっていました。 PRが長期間滞留すると、変更差分がさらに大きくなり、レビュー負荷も増える悪循環が発生していました。 ## 工夫したこと チームでレビューの進め方を見直し、以下を導入しました。 - 1PRあたりの変更行数に上限を設定 - 大きな変更を小さなPRへ分割 - レビュワーをランダムに割り当て、特定メンバーへの集中を防止 - Lintやフォーマット確認をCIへ集約 自身も改善案の検討と運用に関わり、レビューそのものだけではなく、レビューしやすい変更単位を作ることを重視しました。 ## 成果 週あたりのPR数は20件以下から50件以上へ増加し、平均クローズ時間は12日超から2日以下へ短縮しました。 レビューを個人の頑張りに依存させず、チーム全体で継続的に回せる開発プロセスへ改善しました。 # 使用技術 TypeScript / JavaScript / Vue.js / Nuxt.js / Riot.js / Jest / Java / CI