kintoneの通知がたまるを解決!通知を活用に変える3つの視点

ユーザーや顧客の要望に応え、kintoneに通知設定を追加する。最初は便利になったと喜ばれたものの、数ヶ月後に状況を確認してみると、きちんと通知を処理しているユーザーがいる一方で、一部のユーザーは通知を全く見ずにアイコンが「99+」で赤く染まっている・・・。

よかれと思って実装した機能が通知を受け取るユーザにとっては見ないものとなってしまっており、通知がうまく活用されていない。結果、本当に重要な通知まで見逃されてしまう。ユーザーと伴走する管理者として、この通知の形骸化は非常に悩ましい問題です。

この問題の根本原因は、個々の設定ミスではなく、kintoneの活用が進んだことによる通知の肥大化にあると想定されます。

実は私たち自身も、必要な通知を都度追加していったことで、一部ユーザーに通知疲れを招いてしまった経験があります。その反省から言える結論は、通知は追加し続けるのではなく、『見直しステージ』で最適化する必要があるということです。

この記事では、その実体験から得た、kintone通知を「活用」に変えるための「3つの視点」を解説します。

  1. 【設定】 必要な通知への見直し
  2. 【運用】 再発を防ぐガバナンス
  3. 【文化】 現場を巻き込む人的フォロー

読了後、自社(または顧客)の現状を分析し、通知を「ノイズ」から「アクションを促すシグナル」へと変える具体的なステップが明確になります。

【視点1】技術的最適化:通知を「ノイズ」から「シグナル」に“分ける”見直しステップ

通知問題を解決する最初の視点は「設定」です。 まずはkintoneの標準機能を最大限に見直し、不要な通知を排除し、本当に必要な通知だけを届けるための具体的な最適化ステップを確認していきましょう。

通知がたまる原因:情報共有(FYI)と行動要請(Action)の混同

まず認識すべき原因として、通知の性質を区別せずに設定している点が挙げられます。

主な通知の性質

情報共有用通知(FYI: For Your Information)
FYIは、単なる情報共有です。受信者に即時の行動を求めません(例:日報の登録、議事録の共有)。

Action通知(Action Required):
Actionは、タスクの実行を要求する通知です(例:承認依頼、差し戻し対応)。

多くの現場ではこの2つの通知が混在しています。結果、大量の情報共有用通知に埋もれ、本当に対応すべきAction通知を見逃してしまうことに繋がります。一番厄介なのは、同じ通知でも人によってはActionにもなるし、FYIにもなるケースがある、という点かなと思います。

ここでのゴールは、この2つを明確に分けることにあります。

まずは現状把握:通知見直しチェックリスト

どこから手をつけるべきか判断するために、まずは現状の通知設定を棚卸しを行います。
以下のチェックリストを使い、自社(または顧客)の主要なアプリが通知過多の発生源になっていないか診断してみましょう。

通知見直しチェックリスト

1. FY通知(参考情報)とAction通知(行動要請が分離されているか?

  • 「レコード追加/編集時」など、広範すぎるトリガーで通知を設定していないか。
  • 「コメント書き込み」で一律に通知する設定になっていないか。
  • ステータスが「完了」のレコードに対してもリマインダーが飛ぶ設定になっていないか。

2. 通知先は「本当に必要な人」だけに絞られているか?

  • 通知先が「全員」や特定の「組織」に固定(ハードコーディング)されていないか。
  • アプリのフォーム内に、通知先を動的に指定できる「ユーザー選択フィールド」が用意されているか。

3. 通知チャネルは最適か?

  • 緊急性の高い「Action」通知(例:クレーム対応)を見逃す可能性があるか。
  • すべての通知をkintoneだけで処理しようとしていないか。

このチェックリストで1つでもチェックが付いた項目は、ノイズの発生源となっている可能性が高いと言えます。

解決策(1):情報共有用通知を可能な限り削る

当初は入れておいたほうが良いと思い設定した通知が、運用していく中で特に要らなかったということは多々あります。このような不要な情報共有用通知がないかを見直し、削除していくことがまずは必要です。通知の頻度が多いようなアプリから着手していくことで、通知数自体を効果的に下げることができます。

解決策(2):本当に必要な人にだけ届ける「通知先フィールド」の活用

これは、通知先をアプリ設定で固定(特定の組織、グループ、ユーザーで固定)とするのではなく、レコード内のデータに応じて動的に変更させる方法です。すべてのアプリに対して有効な方法ではありませんが、通知先を自分で指定したい場合や、デフォルトは特定の人にしておいて必要な場合のみ追加・変更する、といった使い方が考えられます。レコードを作成・編集した担当者が、その案件の実態に即して本当に通知が必要な人員(例:主担当、上長)を指定するため、情報共有用としての通知が劇的に減少することが期待できます。

実装の手順

  1. アプリのフォームに、「通知先担当者」や「確認者」といった[ユーザー選択]フィールドを設置。(必要に応じて初期値を設定する。)
  2. アプリの通知設定(アプリ条件通知、レコードの条件通知、リマインダーの条件通知)では、通知先として特定のユーザーを選ぶのではなく、[フォームのフィールドを追加]から、先ほど設置した「通知先担当者」フィールドを選択する。

解決策(3):本当に必要な時だけ通知する「ステータス連動リマインダー」

リマインダー通知は対応漏れを防ぐためにとても有効な手段ですが、不要な通知の発生源にもなり得ます。 例えば、「締切日3日前」という条件としたい場合、この条件だけではすでに完了したタスクにも不要な通知が飛んでしまうことが考えられます。そのため、本当に通知対象としたい条件となっているか、改めて見直しをするとよいです。

実装の手順

  1. リマインダー通知の[通知の条件]に、日付の条件(例:「締切日」の「3日前」)を設定する。
  2. さらに条件を追加し、「ステータス」が「次のいずれかを含む」[処理中](または「完了ではない」など)という条件を加える。

解決策(4):外部チャネルへの移管(情報共有用とActionの分離)

kintoneの通知機能は便利ですが、、普段利用するビジネスチャットに一部の通知を移管するようなことが有効な場合もあります。 例えば、特に緊急性の高いAction通知を、Slack、Teams、Chatworkなどへ通知するというものです。

  • Slack/Teams連携: プラグインやiPaaS(Makeなど)を利用し、kintoneの特定条件(例:クレーム登録)をトリガーに、指定したチャネルへ即時通知する。
  • Chatwork連携: Chatwork連携の強みは、通知を「メッセージ」として送るだけでなく、「タスク」として自動作成できる点です。 これにより、通知が「情報共有用」から「実行すべきタスク(To-Do)」へと明確に変換され、実行漏れを強力に防止することに繋がります。
    https://www.focus-u.jp/kintone/plugin/chatwork-task/

例えば、kintoneの通知は情報共有用を中心に運用し、緊急の「Action」通知は外部チャネルに任せるようにする。こうすることで、kintoneを開いたときの「99+」の圧迫感の軽減が期待できます。

【視点2】運用の最適化:再発を防ぐ「通知ガバナンス」の確立

設定の見直しを通じて改善を実施したとしても、根本的な解決に至らないケースも多いのではないでしょうか。時間と共に再び不要な通知が増え始め、同じ問題が再発してしまうことも考えられます。

そこで必要になってくるのが、第2の視点である「運用の最適化」の仕組みづくりです。

なぜ通知は増え続けるのか?:必要な設定の積み重ねが招く通知多すぎ問題

kintoneの活用が進むと、特定の管理者だけではなく、各部門の担当者など利用者自身がそれぞれアプリを作り、運用していくことも多くなります。その際、各部門や担当者が業務に合わせて「このタスクには通知が必要だ」と判断し都度通知設定を追加していきますので、通知設定自体がどんどん増えていきます。

これ自体は業務を円滑に進めるために必要な対応であり、決して悪いことではありません。

しかし、アプリの数・管理者の数も増えたような状態で組織全体でルールが定義・共有されないままになると、一つひとつは必要だったはずの設定がいつしか「不要な通知が多い」といった感想を持たれる事態に陥ります。

こうした設定の積み重ねが、意図せず組織全体の通知の肥大化を招き、通知が多すぎて見なくなる、といった原因となっていきます。

解決策(1):ガイドラインの策定(ルールによる共通認識)

この再発を防ぐには、組織としての共通ルール(ガイドライン)の策定が一つの方法となります。管理者としては、顧客(または自社)のアプリ構築ルールと合わせて通知に関しても最低限のルールを現場と合意形成していくことが理想です。たとえば次のようなものです。

例1)「通知先フィールド」の義務化
アプリからの通知を行う場合、通知先として組織・グループ・ユーザーを固定で設定するのではなく、「通知先フィールド」を用意し、このフィールドを通知先として設定することをアプリ作成時の基本ルールとする。これにより、「全員に通知」といった安易な設定を防ぐ。

例2)「@メンション」ルールの徹底
アプリの通知設定で「コメント書き込み」は無効化して、「本当に行動を促したい相手がいる場合のみ、@メンションを使う」ことを基本運用とする。 これにより、コメント欄はログ(情報共有用)として機能しつつ、@メンションが行動促進用(Action用)として明確に区別される。

解決策(2):定期的な「現場ヒアリング」による見直しプロセスの導入

ガイドラインを作っても、それが守られているか、あるいは現状に即しているかを監視する仕組みがなければ形骸化してしまいます。

「アプリ管理台帳」を作ってそこに通知設定を記録し管理していく、という方法が考えられますが、これは台帳のメンテナンス負荷が高くなる可能性が大きいです。そこでもっと手軽なアプローチとしては、3か月に1回などと時期を決め、的を絞った現場ヒアリングをプロセスとして導入することをお勧めします。

進め方の一例

  1. ヒアリング対象の部署を決める。(部署はヒアリングタイミング毎にローテーションする)
  2. ヒアリング対象者として、「アプリをよく使っていそうなユーザー」、「承認者として利用が多いユーザー」、「通知をあまり見ていなさそうなユーザー」などを選定する。
  3. 各ユーザーには「どの通知が業務上本当に不可欠か」を、通知を見ていないユーザーには「なぜ見ないのか、何がネックになっているか」を具体的にヒアリングする。

期待される効果

  • 「うまく使えている人」だけの意見に偏ることを防げる。
  • ユーザーから通知の本来の目的を再確認し、「通知を見ない人」から形骸化の本当の理由を直接吸い上げることで、精度の高い改善が可能になる。
  • 現場の運用実態の変化(例:通知が増えてあまり見なくなった、等)に合わせて、都度最適な対応を取ることができる。

設定面の最適化とこうした運用ルール・現場との対話を両輪で回していくことで、通知の健全な状態を維持しやすくなります。

【視点3】人的フォロー:現場の通知疲れを解消するアプローチ

これまでに設定の見直しと運用ルールの整備について確認してきました。しかし、これだけではまだ不十分な場合があります。

「通知を見ない人」は、ルールを作っただけでは依然として通知を見ないままかもしれません。 設定と運用を整えた上で、最後の視点となるのが、現場のユーザーと向き合う人的フォローと、通知に頼りすぎない形の模索です。

解決すべきは「業務を停滞させる人」への人的アプローチ

通知を見ない(未読が多い)こと=悪いこと、というわけではありません。「通知を見ない人全員」に対してアプローチするのではなく、まず見極めるべきポイントは、その人が通知を見ないことで業務が停滞しているかどうかです。

優先度 低:未読が多くても、その人がボトルネックにならず業務が回っている。
この場合、その人にとっては見なくても大きな問題は発生していません。フォローの優先度は下げ、次で紹介する「プル型文化」や「未読0運動」の案内程度に留めるのが現実的です。

優先度 高:承認、確認、タスクの実行がその人で止まり、業務全体のボトルネックになっている。
これこそが、設定やルールとは別次元の「人的アプローチ」で解決すべき最優先課題です。

管理者が設定して終わりではなく、このボトルネックになっている人を特定し、なぜ行動が止まっているのか(通知に気づかないのか、使い方がわからないのか、単に忙しいのか、めんどくさがっているだけなのか)をヒアリングし、伴走することこそが本当の通知活用に繋がります。

重要

また、ここで重要なのは、いくらアプローチしても通知への向き合い方を変えない人は一定数いるいう現実を忘れないことです。管理者(またはパートナー)の労力は有限なので、力の入れどころは見極めていく必要があります。

解決策(1):不要な通知を無くす「プル型」への移行

そもそも、すべての「情報共有用通知」をプッシュ通知で送る必要はありません。 ユーザーからは何でも通知させたい要望が出てくるかもしれませんが、緊急性の低い情報はユーザーが必要な時に見に行く「プル型」へ移行することを検討するのも一つの手です。

例えば、「スペース」と「フォロー」機能の活用があります。 部門からのお知らせや日報、議事録など、即時対応が不要な情報は、アプリの通知ではなく「スペース」のスレッドに集約します。 ユーザーは、自分に関係のあるスレッドだけを「フォロー」すれば、そのスレッドに書き込みがあった時だけ通知を受け取れます。 関係者全員への通知を減らして、必要な人だけが情報を取りに行くことで、通知を「Action(行動要請)」なものだけにすることができます。

解決策(2):ユーザー自身ができる「未読0(ゼロ)運動」の推進

管理者側の努力と並行して、ユーザー自身が「通知を見過ごさない」ための習慣を周知・意識付けすることも有効です。それが未読0運動です。

この運動は単純で、ポータル上部の通知アイコンを「99+」など数字が表示されている状態のまま放置せず、常に「0」の状態を保つ習慣をつけることです。 これにより、次に来る新しい通知(本当に重要なAction通知)に気づきやすくなり、見過ごしを減らすことに繋がります。

未読0運動のポイント

「未読を0にする」=「すべての通知を熟読する」という意味ではありません。
「Action」通知は当然対応するものとして、「情報共有用」通知に対しては流し読みでもOK。
通知が来たらまず見るという意識改革をすることが、この運動の一番の目的です。

まとめ:通知を活用し、業務改善を促進

kintoneの通知が「99+」でたまってしまう問題は、活用度が増えることに伴う「通知の肥大化」という仕組みの問題と、それを受け取る「利用者一人一人の通知に対する意識」の問題、この両面が根本原因となっているケースがほとんどです。

この問題を解決し、通知を活用できるシグナルへと変えるためには、3つの視点からのアプローチが欠かせません。

  1. 【設定】:「情報共有用」と「Action」を分ける
    まずは現状の通知設定を棚卸しします。通知先フィールドの動的指定や通知条件の見直しを行い、本当に必要な人へ、本当に必要な時だけ通知が届くよう最適化を行います。
  2. 【運用(ガバナンス)】:再発を防ぐ仕組みを作る
    「必要な設定」の積み重ねが将来の肥大化を招かないよう、自社に合わせたガイドラインを整備します。さらに、定期的な現場ヒアリングを通じて、運用実態に合わせた見直しプロセスを定着させます。
  3. 【文化(人的フォロー)】:現場のボトルネックを解消する
    ルールだけでは行動を変えない人もいます。特に、業務を停滞させるボトルネックとなっているユーザーは通知をうまく活用できていない場合が多く、個別の人的フォローが必要です。同時に、「プル型」へ移行したり「未読0運動」の推進で利用者の意識改革も促します。

通知は、設定して終わりではありません。 これら3つの視点を持ち、現場に伴走しながら継続的に最適化を図ることこそが大切ですね。