ユーザーや顧客の要望に応え、kintoneに通知設定を追加する。最初は便利になったと喜ばれたものの、数ヶ月後に状況を確認してみると、きちんと通知を見て活用しているユーザーがいる一方で、一部のユーザーは通知を全く見ずにアイコンが「99+」・・・。
よかれと思って実装した機能が通知を受け取るユーザにとっては見ないものとなってしまっており、通知がうまく活用されていない。結果、本当に重要な通知まで見逃されてしまう。ユーザーと伴走する管理者として、この通知の形骸化は非常に悩ましい問題です。
この問題の根本原因は、kintoneの活用が進んだことによる通知の肥大化にあると想定されます。
私たち自身も、必要な通知を都度追加していったことで、一部ユーザーに通知疲れを招いてしまった経験があります。その反省から言える結論は、通知は追加し続けるのではなく、見直しステージで最適化する必要があるということです。
この記事では、その実体験から得た、kintone通知を活用に変えるための3つの視点を解説します。
- 【設定】 必要な通知への見直し
- 【運用】 再発を防ぐガバナンス
- 【文化】 現場を巻き込む人的フォロー
読了後は、現状を分析して通知を邪魔なものからアクションを促すステップが明確になります。
【視点1】通知設定の見直し
通知問題を解決する最初の視点は「設定」です。 まずはkintoneの標準機能を最大限に見直し、不要な通知を排除し、本当に必要な通知だけを届けるための具体的な最適化ステップを確認していきましょう。
通知がたまる原因：情報共有（FYI）と行動要請（Action）の混同
まず認識すべき原因として、通知の性質を区別せずに設定している点が挙げられます。
多くの現場ではこの2つの通知が混在しています。結果、大量の情報共有用通知に埋もれ、本当に対応すべきAction通知を見逃してしまうことに繋がります。一番厄介なのは、同じ通知でも人によってはActionにもなるし、FYIにもなるケースがある、という点かなと思います。
※kintoneの設定としてこの2つを分離できないため、混同は仕方ない部分もあります。
ここでのゴールは、この2つを明確に分けることにあります。
まずは現状把握：通知見直しチェックリスト
どこから手をつけるべきか判断するために、まずは現状の通知設定を棚卸しを行います。
以下のチェックリストを使い、自社（または顧客）の主要なアプリが通知過多の発生源になっていないか診断してみましょう。
このチェックリストで1つでもチェックが付いた項目は、ノイズの発生源となっている可能性が高いと言えます。
解決策(1)：情報共有用通知を可能な限り削る
当初は入れておいたほうが良いと思い設定した通知が、運用していく中で特に要らなかったということは多々あります。このような不要な情報共有用通知がないかを見直し、削除していくことがまずは必要です。通知の頻度が多いようなアプリから着手していくことで、通知数自体を効果的に下げることができます。
解決策(2)：本当に必要な人・必要なタイミングにだけ届ける（通知先フィールドの活用）
これは、通知先をアプリ設定で固定（特定の組織、グループ、ユーザーで固定）とするのではなく、レコード内のデータに応じて動的に変更させる方法です。すべてのアプリに対して有効な方法ではありませんが、通知先を自分で指定したい場合や、デフォルトは特定の人にしておいて必要な場合のみ追加・変更する、といった使い方が考えられます。レコードを作成・編集した担当者が、その案件の実態に即して本当に通知が必要な人員（例：主担当、上長）を指定するため、情報共有用としての通知が大幅に減少することが期待できます。
実装の手順：
- アプリのフォームに、「通知先担当者」や「確認者」といった［ユーザー選択］フィールドを設置。（必要に応じて初期値を設定する。）
- アプリの通知設定（アプリ条件通知、レコードの条件通知、リマインダーの条件通知）では、通知先として特定のユーザーを選ぶのではなく、［フォームのフィールドを追加］から、先ほど設置した「通知先担当者」フィールドを選択する。
あわせて、リマインダー通知も本当に通知対象としたい条件となっているか、改めて見直しをするとよいです。
解決策(3)：外部サービスへの一部移管（情報共有用とActionの分離）
kintoneの通知機能は便利ですが、、普段利用するビジネスチャットに一部の通知を移管するようなことが有効な場合もあります。 例えば、特に緊急性の高いAction通知は、Slack、Teams、Chatworkといった別サービスへ通知するというものです。
- Slack/Teams連携： プラグインやiPaaS（Makeなど）を利用し、kintoneの特定条件（例：クレーム登録）をトリガーに、指定したチャネルへ即時通知する。
- Chatwork連携： Chatwork連携の強みは、通知を「メッセージ」として送るだけでなく、「タスク」として自動作成できる点です。 これにより、通知が「情報共有用」から「実行すべきタスク（To-Do）」へと明確に変換され、実行漏れを強力に防止することに繋がります。
https://www.focus-u.jp/kintone/plugin/chatwork-task/
【視点2】再発を防ぐ通知ガバナンスの確立
設定の見直しを通じて改善を実施したとしても、根本的な解決に至らないケースも多いです。時間と共に再び不要な通知が増え始め、同じ問題が再発してしまうことも考えられます。
そこで必要になってくるのが、第2の視点である運用の最適化の仕組みづくりです。
なぜ通知は増え続けるのか？：必要な設定の積み重ねが招く通知多すぎ問題
社内でのkintoneの活用が進むと、特定の管理者だけではなく、各部門の担当者など利用者自身がそれぞれアプリを作り、運用していくことも多くなります。その際、各部門や担当者が業務に合わせて「この通知が必要だ」と判断し都度通知設定を追加していきますので、通知設定自体がどんどん増えていきます。
これ自体は業務を円滑に進めるために必要な対応であり、決して悪いことではありません。
しかし、アプリの数・管理者の数も増えたような状態で組織全体でルールが定義・共有されないままになると、一つひとつは必要だったはずの設定がいつしか「不要な通知が多い」といった感想を持たれる事態に陥ります。
こうした設定の積み重ねが、意図せず組織全体の通知の肥大化を招き、通知が多すぎて見なくなる、といった事象へと繋がっていきます。
解決策(1)：ガイドラインの策定（ルールによる共通認識）
この再発を防ぐには、組織としての共通ルール（ガイドライン）の策定が一つの方法となります。管理者としては、アプリ構築ルールと合わせて通知に関しても最低限のルールを現場と合意形成していくことが理想です。たとえば次のようなものです。
例１）「通知先フィールド」の義務化
アプリからの通知を行う場合、通知先として組織・グループ・ユーザーを固定で設定するのではなく、「通知先フィールド」を用意し、このフィールドを通知先として設定することをアプリ作成時の基本ルールとする。これにより、通知先が広くなってしまうという設定を防ぐ。
例２）「＠メンション」ルールの徹底
アプリの通知設定で「コメント書き込み」は無効化して、「本当に行動を促したい相手がいる場合のみ、＠メンションを使う」ことを基本運用とする。 これにより、コメント欄はログ（情報共有用）として機能しつつ、＠メンションが行動促進用（Action用）として明確に区別される。
解決策(2)：定期的な現場ヒアリングによる見直しプロセスの導入
ガイドラインを作っても、それが守られているか、あるいは現状に即しているかを監視する仕組みがなければ形骸化してしまいます。
「アプリ管理台帳」を作ってそこに通知設定を記録し管理していく、という方法が考えられますが、これは台帳のメンテナンス負荷が高くなる可能性が大きいです。そこでもっと手軽なアプローチとしては、3か月に1回などと時期を決め、的を絞った現場ヒアリングをプロセスとして導入することをお勧めします。
進め方の一例：
- ヒアリング対象の部署を決める。（部署はヒアリングタイミング毎にローテーションする）
- ヒアリング対象者として、「アプリをよく使っていそうなユーザー」、「承認者として利用が多いユーザー」、「通知をあまり見ていなさそうなユーザー」などを選定する。
- 各ユーザーには「どの通知が業務上本当に不可欠か」を、通知を見ていないユーザーには「なぜ見ないのか、何がネックになっているか」を具体的にヒアリングする。
期待される効果：
- 「うまく使えている人」だけの意見に偏ることを防げる。
- ユーザーから通知の本来の目的を再確認し、「通知を見ない人」から形骸化の本当の理由を直接吸い上げることで、精度の高い改善が可能になる。
- 現場の運用実態の変化（例：通知が増えてあまり見なくなった、等）に合わせて、都度最適な対応を取ることができる。
設定面の最適化とこうした運用ルール・現場との対話を両輪で回していくことで、通知の健全な状態を維持しやすくなります。
【視点3】現場の通知疲れを解消するアプローチ
設定の見直しと運用ルールの整備だけでは、まだ不十分な場合があります。
「通知を見ない人」は、ルールを作っただけでは依然として通知を見ないままかもしれません。 設定と運用を整えた上で、最後の視点となるのが、現場のユーザーと向き合う人的フォローと、通知に頼りすぎない形の模索です。
解決すべきは「業務を停滞させる人」への人的アプローチ
通知を見ない（未読が多い）こと＝悪いこと、というわけではありません。「通知を見ない人全員」に対してアプローチするのではなく、まず見極めるべきポイントは、その人が通知を見ないことで業務が停滞しているかどうかです。
優先度 低：未読が多くても、その人がボトルネックにならず業務が回っている。
この場合、通知を見なくても大きな問題は発生していません。フォローの優先度は下げ、次で紹介する「プル型文化」や「未読0運動」の案内程度に留めるのが現実的です。
優先度 高：承認、確認、タスクの実行がその人で止まり、業務全体のボトルネックになっている。
このような場合、設定やルールとあわせて、人的アプローチで解決すべき最優先課題です。
管理者が設定して終わりではなく、このボトルネックになっている人を特定し、なぜ行動が止まっているのか（通知に気づかないのか、使い方がわからないのか、単に忙しいのか、めんどくさがっているだけなのか）をヒアリングし、伴走することこそが本当の通知活用に繋がります。
解決策(1)：不要な通知を無くす「プル型」への移行
そもそも、すべての情報共有用通知をプッシュ通知で送る必要はありません。 ユーザーからは何でも通知させたい要望が出てくるかもしれませんが、緊急性の低い情報はユーザーが必要な時に見に行く「プル型」へ移行することを検討するのも一つの手です。
例えば、「スペース」と「フォロー」機能の活用があります。 部門からのお知らせや日報、議事録など、即時対応が不要な情報は、アプリの通知ではなく「スペース」のスレッドに集約します。 ユーザーは、自分に関係のあるスレッドだけを「フォロー」すれば、そのスレッドに書き込みがあった時だけ通知を受け取れます。 関係者全員への通知を減らして、必要な人だけが情報を取りに行くことで、通知を「Action（行動要請）」なものだけにすることができます。
解決策(2)：アプリを開いた際に通知メッセージを表示
メンションによる通知設定は極力減らし、各アプリを開いた際に、そのアプリでアクションが必要なレコードに対して通知メッセージを都度表示させる、という方法も一つの手です。通知サポートプラグイン for kintoneを使用することで、必要なメッセージを必要なときのみ表示することができます。
解決策(3)：ユーザー自身ができる「未読0（ゼロ）運動」の推進
管理者側の努力と並行して、ユーザー自身が通知を見過ごさないための習慣を周知・意識付けすることも有効です。それが未読0運動です。
この運動は単純で、ポータル上部の通知アイコンを「99+」など数字が表示されている状態のまま放置せず、常に「0」の状態を保つ習慣をつけることです。 これにより、次に来る新しい通知（本当に重要なAction通知）に気づきやすくなり、見過ごしを減らすことに繋がります。
まとめ：通知を活用し、業務改善を促進
kintoneの通知が「99+」でたまってしまう問題は、kintoneの活用度が増えることに伴う設定増加の問題と、それを受け取る利用者一人一人の通知に対する意識の問題、この両面が原因となっているケースがほとんどです。
この問題を解決し、通知を活用できる形へと変えるためには、3つの視点からのアプローチが欠かせません。
- 【設定】：「情報共有用」と「Action」を分ける：
まずは現状の通知設定を棚卸しします。通知先フィールドの動的指定や通知条件の見直しを行い、本当に必要な人へ、本当に必要な時だけ通知が届くよう最適化を行います。 - 【運用】：再発を防ぐ仕組みを作る：
必要な設定の積み重ねが将来の肥大化を招かないよう、自社に合わせたガイドラインを整備します。さらに、定期的な現場ヒアリングを通じて、運用実態に合わせた見直しプロセスを定着させます。 - 【フォロー】：現場のボトルネックを解消する：
ルールだけでは行動を変えない人もいます。特に、業務を停滞させるボトルネックとなっているユーザーは通知をうまく活用できていない場合が多く、個別の人的フォローが必要です。同時に、「プル型」へ移行したり「未読0運動」の推進で利用者の意識改革も促します。
通知は、設定して終わりではありません。 これら3つの視点を持ち、kintoneの活用度に応じて継続的に最適化を図ることこそが大切ですね。
