Zenn
🐷

[システム設計]業務システムにおける通知機能のベストプラクティスとは？

2024/10/13に公開
Slack
業務システム
tech

背景

通知機能の改修を依頼されたので、ユーザーに改めて要件をヒアリングすることに。
ヒアリングした結果、ひとつの通知機能に対しての改修要望はユーザーによって異なることがわかりました。
メール通知が欲しい人、Slack通知が欲しい人、はたまた通知自体不要な人などさまざま...(°_°)
その理由を明確にするとともに、通知機能のベストプラクティスを整理したいと思います。
(今回の対応で感じたことのまとめでしかないので、今後も更新していきたい所存)

今回起きたことの整理

  • まずは業務フロー

  • 大前提

    • メール通知はステータスに限らずすべてのユーザーに送られている

  • ユーザーA

    • メールでの通知でデータ変更を検知
    • 次のアクションは別システムでのタスク化

  • ユーザーB

    • Slackでの通知でデータ変更を検知
    • 次のアクションは顧客へのヒアリング

  • ユーザーC

    • 通知は来ているが検知できていない
    • 定期チェックで検知
    • 次のアクションはfugeデータの作成

各ユーザーにヒアリングしたところ、以下の理由でそれぞれの通知種類が異なることが判明

  • 次のアクションがタスク作成のため、ユーザーAはメールで検知したい(メール転送によるタスク自動作成機能を使いたい)
  • ステータス1への変更頻度が低いため、ユーザーBはSlackで検知したい
  • ステータス4,5への変更頻度が多く通知が埋もれるため通知は不要(通知は来ているが見ていない状態)

なるほどそれぞれ事情があるのか🤔
今は全員にメールを送っているので不要なものもありそう。
ではどういう通知設計にすべきなのか...
一般論も含めて見直してみる👀

通知機能のあるべき姿

まずは通知機能の理想の状態を整理する( ◠‿◠ )(以下に限らず)

  • 必要なユーザーだけに通知されている
  • 通知を受けた後のアクションが明確になっている
  • ユーザー、通知内容に合わせた適切な手法で通知されている

通知の種類とメリットデメリット

システムにおける通知機能の種類と、そのメリットデメリットをあげていきます(すべて網羅しているわけではない)

プッシュ系

  • メール
    • メリット
      • 履歴がしっかり残るため(送信後の取り消しができない)、公式的な連絡に適している
      • 外部のユーザーとも連携可能
    • デメリット
      • 通知が埋もれやすい
      • リアルタイム性が低い
  • Slackやteamsなどのチャットツール
    • メリット
      • リアルタイムで通知を受け取れる
      • 他ユーザーと連携が容易
    • デメリット
      • 通知が多いと情報が埋もれやすい
  • スマホアプリへのプッシュ通知
    • メリット
      • リアルタイムで通知を受け取れる
      • 個人をターゲットにした場合に効果的
    • デメリット
      • 通知が多いとユーザーに不快感を与えてしまう

プル系

  • ダッシュボード通知
    • メリット
      • システムを開いた際に検知できるので、無駄な通知でユーザーの作業を止めることがない
    • デメリット
      • システムを開かないユーザーには検知されない

などなど
用途や目的によって使い分けたい👀

実際に通知機能を設計していく

通知機能の設計時に整理しておきたい情報を集める

通知機能の具体的な手法を決める前に、ユーザーの状況、要望を整理しておきます

  • 通知機能に関する業務のフロー
  • 通知を受け取りたい人
  • 通知を受け取った後のアクション
  • 通知のトリガー
    • ユーザーの操作
    • データの状態
    • 定時(毎月初日9:00に通知、毎日16時に通知、など)
  • 通知の即時性
    などなど

今回の事例で言うと以下でした

  • 通知の受け取りたい人
    • ユーザーA、B(Cに通知が不要と判断すべきかは別問題かもしれない)
  • 通知を受け取った後のアクション
    • ユーザーA：タスク作成(タスクの内容は様々、社内共有や顧客対応やデータ作成など)
    • ユーザーB：顧客ヒアリング
  • 通知のトリガー
    • データの状態変更
  • 通知の即時性
    • ユーザーA、B、C：即時対応が必要

通知の詳細を決める

上記で整理した内容から、以下を決定していく

  • 通知発信の条件
    • いつだれが何をどうしたときに...など
  • 通知の手法
    • メールなのかSMSなのかSlackなのか...など
  • 通知の宛先
    • 通知を受けとる人だけで良いのか、チーム全体に必要か、システムアカウントも含むか、メールだとccは必要か...など
  • 通知内容
    • 特定の文字列だけなのか、データの情報も含むのか...など

通知機能を設計する上での注意点

あるべき姿になっているか？

通知をむやみに増やしていないか？
一部のユーザーの要望を鵜呑みにして、通知が不要なユーザーまで通知が送信されるようになっていないか？
など、理想から離れていないかを確認しながら進めた方が良さそう。

通知自体が目的にになっていないか？

通知を検知した後のユーザーのアクションも踏まえて通知の目的を見直しましょう。
今回の事例で言うと、ユーザーAの次のアクションはタスク化です。
タスク化が自動化できるかもしれませんし、タスク化後のさらに次のアクションも自動化できるものもあるかもしれません。
そうなるとユーザーに通知せずにタスク化も含めてシステムが担った方が良いかもしれないです。
逆にユーザーBのように次のアクションが人間にしかできないものだと、通知機能が効果的と言えます。
(ただしヒアリングという作業をもっと細かく分けると日程調整、ヒアリング実施、ヒアリング内容登録などに分けられるので、日程調整を自動化するなどはできるかもしれない)

通知数が増えすぎないか？

すべての情報を即時で取り入れられるのが理想ですが、それにも限界があります。
通知の頻度を確認して、情報を受動的に得るべきか能動的に得るべきかを判断すべきです。
通知頻度が高くなりそうなものは、通知を受け取るよりも定期的にデータをチェックしにいった方が効率的です。
事例で言うとユーザーCのパターンですね。
逆に通知頻度が低いものは受動的に得る方が良さそうです。
もちろん業務内容によっては通知機能ではなくほか要因の改善が必要になるかもしれませんが...
(ユーザーCの場合、即時対応が必要にも関わらず通知を追えていない状態なので別のところで修正が必要かもしれない)

通知機能の運用

ユーザーの業務内容が変われば通知のあるべき姿も変わります。
通知を追加してほしいという要望は上がりやすいですが、不要な通知を無くして欲しいという要望は上がりにくいように思えます。
定期的に通知機能を見直しても良いかもしれないですね。

感想

通知機能はサブ機能になりがちだけど、業務の対応の速度に大きく影響するのでユーザーからするとシステムの要になり得るものだなと思いました。
特に営業さんは速さが勝負なところがあるし。
システムの通知設計が売上に大きく影響を及ぼすかもしれない。

参考

Discussion