JobQTownの通知機能開発の振り返り　#Developer＆Designer Advent Calendar 2024

alt

本記事はDeveloper＆Designer Advent Calendar 2024の12月25日の記事です。

はじめに
通知設計のプロセスと考慮ポイント
JobQTownの通知のこれから
おわりに

はじめに

こんにちは。はたらく未来図構想統括部 JobQ部、エンジニアの川村です。
我々が開発に携わる「JobQTown」は、キャリアや転職に関する相談や情報交換を支援するサービスです。
多くのユーザーが利用する中で、情報を適切なタイミングで届ける「通知機能」は、ユーザーのアクションを促し、サービスの価値を最大化する重要な役割を担っています。
今回、ユーザーがフォローしている企業に関連する新着情報（Q&Aや口コミ）をタイムリーに届ける通知機能を開発し、メール通知の開封率が約30%向上、クリック率も大幅に改善されるという具体的な成果を残しました。この経験を活かし、現在ではさまざまな通知施策を展開することができています。

本記事では、この通知機能の開発における設計プロセスや考慮したポイント、実際に行った開発の内容について振り返っていきます。

通知設計のプロセスと考慮ポイント

1. 通知の目的と要件の整理

通知設計の第一歩として、通知の目的を明確にし、それに基づいて要件を整理することが重要です。

通知の目的（Why）

通知を通じてユーザーがどのような情報を受け取り、どのような行動を促したいのかを明確に定義します。
理想的には、ユーザーヒアリングを通じてニーズや課題を深く理解し、それを設計に反映させることが望ましいです。一方で、過剰な通知や無関係な通知はユーザーにとってノイズとなり、サービス離れのリスクを高めるため、通知を送ること自体が目的化しないよう注意しました。

今回、プロダクトオーナー（以下、PO）からは、以下のような背景・目的があることを確認しました。

ユーザーエンゲージメントの向上

・ユーザーが関心のある最新情報を迅速に届け、サービス内での行動を促進する。
・必要な情報を適切なタイミングで届けることで、ユーザー体験を向上させる。
企業フォロー機能の活性化

・これまで企業フォロー機能はあったものの、特に通知などを展開していなかったため、これを有効活用しサービス価値を高める。

実際のPRD（プロダクト要件付箋書）には、ここに数値的な根拠が入ります。
我々のチームでは、PRDの作成をPOが担当し、エンジニアもPRDのレビューを行うことで、工数や実装の優先順位を検討しています。このプロセスを通じて、POとエンジニアが連携し、両者が納得した上で開発を進めています。

要件の整理

目的が明確になった後は、以下の観点で整理しました。

いつ（When）：通知のトリガーとタイミング

トリガー：特定の時間になったら、特定の処理が完了したら（データが作成された、更新された、公開された）、特定のデータが存在したら
タイミング：即時か、定時か
頻度：通知が過剰にならないよう、適切な間隔で実施

誰に / 誰から（Who）：通知を受け取る対象ユーザー / 通知の送信者

誰に：個別のユーザーか、全ユーザーか。人数上限は必要か
誰から: 通知の発信者としてどの運営局やサービス名を明記するのか

何を（What）：通知にはどのような情報を盛り込みたいのか

通知を受け取った際に期待するアクションに移れるか否かが重要です。
メール通知と仮定すると、必要な項目は以下となります。

タイトル：簡潔でわかりやすく、興味を引く表現
概要：内容を補足する要約
リンク先：アクションを促すための具体的なリンク

どのように（How）：通知のチャネルを選定

チャネル：サービス内のweb通知、メール通知、スマホアプリのプッシュ通知など、適切なチャネルを選定
デザイン：各チャネルに適したフォーマットやレイアウト

2. サーバー負荷を考慮した設計

多くの通知リクエストを一度に処理しようとすると、サーバーリソースを圧迫し、サービス全体のパフォーマンス低下を引き起こしかねません。
そこで今回は、Sidekiqを使ってバックグラウンドで処理し、メインのサーバー負荷を軽減。さらに、定期的に通知をまとめて送信するバッチ処理を採用しました。通知件数を予測してバッチの周期を設定することで、リアルタイム性と効率性を両立する設計を実現しています。

スケーラビリティの確保

一般的に、システムのスケーラビリティ（拡張性）は重要な設計要素ですが、今回の開発では強く意識していなかった部分もあり、再検討が必要だと感じています。例えば、今後企業フォロー数やユーザー数が増加した際に、システムがその負荷に耐えられるか、また通知条件が複雑化した場合に柔軟に対応できるかは重要な課題です。
現状ではロジックのモジュール化をある程度進めていますが、システム全体の拡張性や保守性をさらに高めるためには、さらなる改善が必要だと考えています。

3. 例外処理と冪等性の担保

例外処理の設計

通知処理において、以下のように例外が発生するケースが多く見受けられます。

通知先ユーザーが存在しない場合
必要な通知内容が欠けている、または非公開情報を含む場合
重複した通知データが存在する場合

これらのエラーは要件段階で洗い出してはいますが、すべてを網羅することは難しく、漏れが発生する可能性があります。また、バッチ処理を採用しているため、何かしらのエラーが発生するリスクは避けられません。そのため、例外処理を設けることが不可欠です。
実運用では、ログを適切に出力し可観測性を確保するようにしています。さらに、Datadogのエラートラッキングを活用して障害通知をリアルタイムでキャッチすることで、発生した問題を特定し対応しています。

冪等性の担保

冪等性とは、同一の処理を何度繰り返しても結果が変わらないことを保証することです。
バッチやワーカーの不具合などがあった場合、全く通知されないものがあったり、複数回通知される可能性があります。
すでに処理が完了したものをリトライ時に処理しない方法と、処理済みのものも含めてやり直す方法がありますが、今回の設計では後者を採用しました。
通知レコードにステータスを持たせることで、何度実行しても同じ結果が得られることを保証しています。

テストの注力

通知はユーザーに直接影響を与えてしまうため、ここまでの実装を厳密にテストする必要があります。
今回は上記の例外処理と冪等性のロジックを検証するため、ユニットテストを作り検証しました。
さらに、POと連携し、ステージング環境にて様々なケースを想定した受け入れテストを実施しました。このテストでは、異常系や境界値などの多様なシナリオをシミュレーションし、実運用に近い形での確認を行いました。

4. ユーザー体験の向上

通知はサービスとユーザーをつなぐ大切な接点であり、細部への配慮が欠かせません。
ユーザーが自身の利用状況に応じて通知を管理できるよう、マイページで通知フラグのオン・オフを切り替えられるようにするのはもちろんのこと、Gmailのスパムメール対策を考慮し、ワンクリックでメール配信先の登録を解除できる仕組みを提供することで、ユーザーに安心して通知を受け取ってもらえるようにしています。

さらに、SendGridのActivity機能と連携させることで、通知の開封率やクリック率を測定し、そのデータを活用して改善を繰り返しています。こうした取り組みによって、通知の効果を高め、ユーザーが適切なタイミングで価値ある情報を受け取れるよう工夫しています。

JobQTownの通知のこれから

今回の通知機能の開発後も、JobQTownでは、企業フォローのメリットを分かりやすく示すボタンの設置や、レンダリングを伴わないフォロー機能の改善など、ユーザー体験向上に向けた取り組みを続けています。

今後は、バッチ処理に依存しないリアルタイム通知やイベントに基づいた通知手法の導入も視野に入れ、通知機能のさらなる最適化を模索していきます。また、現在のバッチ処理についても効率化を図り、スケーラビリティや実行パフォーマンスの改善に取り組んでいきます。

我々の開発チームは、実装だけにとどまらず、プロダクト要件の整理や機能提案にも積極的に関わり、全てのメンバーが連携しながら改善を進められる環境が整っています。他チームとの情報交換も活発で、メールデザインの知見を持つチームと協力しながら通知のデザインを改善することで、より効果的な通知体験を提供していきたいとも考えています。