## 前提と課題
新品商品のお気に入り機能、通知機能は実装済みで、中古商品の購入機能は別PJTで実装済みでした。
中古購入機能リリース後のマーケティング施策の効果もあり、新品商品と同等程度に中古商品も購入されるようになっていました。
そんな中、購入される件数は伸びているものの、中古商品のお気に入り機能が存在しなく、購入体験が悪い状態でした。
## プロジェクト概要
CtoCアプリの中古商品お気に入り、および、通知機能を実装し、購入体験を向上させる。
## 要件
- お気に入り登録したら、一覧に表示できること
- 中古商品値下げ時に、お気に入りしているユーザーに値下げの通知をpush、email、マイページで通知する
- 上記2つの要件を全ての中古商品カテゴリに対応する
## チーム構成
- エンジニア
- 2名
- PdM
- 1名
## チーム内の自身の役割
■前提
エンジニア組織は全体で12名ほど在籍し、1teamあたり4人に分かれ、3teamそれぞれ別のPJT及び機能開発を進めています。
その中の1チームのリーダーとして開発をリードしつつ、このPJTのリーダーも担当していました。
このPJTには自分とチームメンバーのもう1名で担当し、同時に同チームの2名は他PJTで別の機能を開発していました。
■役割
PJTにアサインできるエンジニアが自分含めて2名しかいなかったので、
PJT進行に必要な下記タスクをすべて担当しています。
- PdMとの各種調整
- 仕様、タスク分解、リリーススコープの調整
- 中古お気に入りテーブル設計
- API設計、実装
- 中古お気に入り登録
- 中古お気に入り登録済みかどうか
- 中古お気に入り削除
- 値下げ通知Workerの実装
- バッチ処理(お気に入りテーブルの商品ID更新)
- フロントエンド実装
- 運用保守
- メンバーのタスク割り振り、スケジュール、進捗管理
- 他PJTの担当メンバーの進捗管理
同時に他PJTを担当していたチームメンバーのスケジュール、進捗管理もしています。
## PJT進行で工夫した点
#### お気に入り登録機能と値下げ通知のリリースタイミングを分けるよう交渉、実行しました。
下記が理由です。
- お気に入り一覧に登録し、マイページで一覧を確認するだけでも、UXは向上する
- 細かくリリースすることでリリース後のバグ発生確率を下げることができると考え、発生したとしても原因特定しやすくするため
また、要望としては、下記の機能も含まれていましたが、上記と同様の理由でリリースするフェーズを分けました。
- 売り手が出品した中古商品がお気に入り登録される度にプッシュ、メール、マイページで通知
- お気に入り登録したユーザーに中古商品に新規のコメントされる度にプッシュ、メール、お知らせで通知
## 設計、実装で工夫したところ
■前提として、中古商品はカテゴリ毎に出品テーブルが分かれていて、それぞれのテーブル毎に登録、通知機能を実装しました。
理由は将来の拡張性を考慮したためです。
お気に入りテーブルも一つだけ、通知用のworkerも一つだけにすることが工数としては削減できました。
ですが、4,5年後まで見据えたときに、workerのビジネスロジックがカテゴリごとに別になる可能性は十二分にあると考えていました。
ビジネスロジックにカテゴリごとの条件分岐が発生すると、将来的に多くのバグを生んでしまうと考え、それぞれのカテゴリごとに登録、通知機能を実装しました。
■workerのビジネスロジックのパフォーマンスを考慮して実装しました。
「前提と課題」で記載した通り、新品商品のお気に入り機能は存在していました。
ただ、n+1なクエリが多々あり、1商品のお気に入りユーザー数が増えれば増えるほど、パフォーマンスが悪くなる状態でした。
そこで中古を実装するときは、n+1が発生しないように、joinしてクエリを実行するようにしました。