就労移行支援事業所向けの基幹システムにおける、通知機能の設計

この記事は、[ispec] 医療に向き合う技術者集団の戦録 Advent Calendar 2024 の3日目の記事です！
https://adventar.org/calendars/10776

はじめに

弊社ispecでは、業務管理一体型PHR^[1]サービスと、それを導入した就労移行支援事業所^[2]向けの基幹システムの開発を行いました。(詳細については、下記のプレスリリースをご確認ください。)
https://prtimes.jp/main/html/rd/p/000000041.000033917.html

このシステムは、事業所の利用者様に提供するスマホアプリと、支援員様が利用するWeb管理システムの2つで構成されています。今回は、その中の機能の一つ、プッシュ通知の設計について、開発当時に書いたADR (Architecture Decision Record) を元にご紹介します！

プッシュ通知は、複数の外部サービスが連携して提供されるため、とても複雑です。そのため、事前の調査や設計が重要になってきます。また、将来的に様々なユースケースでの利用が検討されていたため、長期的な運用にも耐えられ、かつ汎用性のある設計が求められました。

ユースケースの整理

まずは、どのような場面で通知が必要になるか、将来的に可能性のあるものも含めて整理を行いました。

個別支援計画の承認依頼通知

• 提供時期
  • 初期リリース
• 通知理由
  • 就労移行支援では、事業所の利用者様一人ひとりの特性や目標に合わせて個別支援計画というものを作成する。この計画は、利用者様やそのご家族に内容を説明し、承認をいただくことが義務付けられている。今回開発したシステムでは、その承認を利用者様のスマホアプリ上で行えるようになっている。忘れずに承認が行われるよう、通知を行い促す。
• 通知先
  • 事業所の各利用者様
• 通知タイミング
  • 支援員様がWeb管理システムで個別支援計画を作成し、承認依頼が行われたとき
    • 即時配信
• ユーザごとのメッセージのカスタマイズ
  • 無し

お知らせ通知

• 提供時期
  • 将来的に
• 通知理由
  • 事業所において定期、不定期でイベントを開催している。多くの利用者様に参加してもらうために、通知を行い促す。
  • 上記以外での利用の可能性もあり (汎用的なお知らせ)
• 通知先
  • 各事業所に所属する利用者様 (複数の事業所が存在する)
    • グループ分け等が必要になってくる
• 通知タイミング
  • Web管理システムで、お知らせの登録を行った際
    • 即時配信
  • イベントのX日前、当日
    • スケジュール配信
• ユーザごとのメッセージのカスタマイズ
  • 無し

送迎通知

• 提供時期
  • 将来的に
• 通知理由
  • 自宅 <> 事業所間の送迎を提供している。利用者様ごと、日ごとに利用の有無が異なるので、当日の送迎を忘れないよう通知を行う。
• 通知先
  • 送迎の利用登録がある各利用者様
• 通知タイミング
  • 毎日定刻 (全利用者同一時刻)
    • スケジュール配信
• ユーザごとのメッセージのカスタマイズ
  • (未定)

重要なポイントの整理

上記のユースケースやその他非機能要件などを踏まえ、通知機能の設計において重要なポイントを整理しました。

• 通知の種類
  しばらくはプッシュ通知のみの想定だが、将来的にメール通知が必要になる可能性は排除できない
• 通知のタイミング
  リリース当初はWeb管理システムでの操作がトリガーとなるが、後に時間をトリガーにした配信も追加になる
• 開発工数, スケジュール
  他機能の実装もあり、工数やスケジュールに余裕があるわけではない
  要件を満たしつつも、できるだけ工数は抑えられるようにしたい

アーキテクチャ

上記を踏まえ、最終的にはこのようなアーキテクチャになりました。

使用サービス

• Apple Push Notification Service (以下、APNs)
  • Appleデバイスへの通知に必須になる
• Firebase Cloud Messaging (以下、FCM)
  • Androidデバイスへの通知に必須になる
  • APNsへの中継もできる
• Amazon Simple Notification Service (以下、Amazon SNS)
  • メールやSMS、プッシュ通知等の配信が行える
  • APNsやFCMへの中継もできる

悩んだポイント

開発工数やスケジュールに余裕があるわけではないので、統一されたインターフェースで通知を行うことができるFCMやAmazon SNSを利用することは早い段階で決定しました。ただ、FCM単体で実装するのか、Amazon SNSと組み合わせて実装するかは悩みました。しかし最終的には、以下の理由から、Amazon SNSと組み合わせて通知を行うことにしました。

• 時間をトリガーとした通知を実装する際、EventBridgeとの連携が容易
• メールなど他の通知も、同じインターフェースで実装できる
• 通知関係のエラーログと、アプリケーションのエラーログを同じ場所で管理できる
• 既に別サービスでも使用しているMotoを使用して、モック開発ができる
  https://docs.getmoto.org/en/latest/docs/services/sns.html

その他考慮したポイント

その他、以下の考慮や設計も行いました。
この部分については、今回は割愛しますが、今後時間ができたタイミングで追記や別記事にしていきたいと思います。

• 各種料金
• フロントエンドでの処理のフロー
• バックエンドでの処理のフロー
• エッジケースの考慮

参考

https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/sns
https://repost.aws/ja/knowledge-center/sns-push-notification-endpoint-deactivated
https://zenn.dev/hori/scraps/e0e1847e255a90

脚注

1. Personal Health Recordの略。個人の健康・医療に関する情報を生涯にわたって記録・管理するシステム。健診データ、診療記録、服薬情報などの医療情報を個人が主体的に管理し、健康管理や医療機関との情報共有に活用する。

2. 障害や難病のある方が一般企業に就職できるようサポートする通所型の福祉サービス。職業訓練、就職活動支援、職場定着支援などを提供する。障害者総合支援法に基づいて運営されている。