はじめに

こんにちは、IT本部IT戦略部テクニカルオペレーショングループの大和田です。
DeNAグループにおけるITシステム・ツール運用の業務改善を担当しています。

今回のブログでは前回の記事に引き続き、kintoneの改善活動について紹介します。
【前回の記事はこちら】

この記事の流れ

• DeNAグループにおける「kintone」の利用状況
• kintoneの標準機能と「作業者アサイン通知」の違い
• 機能開発の背景
• 開発において考慮したポイント
• まとめ

DeNAグループにおける「kintone」の利用状況

DeNAの社内ではkintone上に作成した各種申請アプリを利用しています。
運用中のアプリは500個を越え、全社向けの申請のみならず、小規模な業務の個別申請を含む広範囲をカバーしています。
各アプリはkintoneの「プロセス管理機能」で申請者の上長やシステム管理者による「承認」を設けているものが多くあります。

kintoneの標準機能と「作業者アサイン通知」の違い

kintoneを利用されている方は「kintoneには標準でSlack通知機能があるはずでは？」とお気づきかもしれません。
kintoneには標準機能として「Slack連携」機能が備わっています。
標準機能では「申請のステータス変更時、アサインされた作業者全員へSlack DMを送信」します。
そのため、「すべてのステータス更新時、担当者全員にもれなく通知する」場合に有効です。

しかしながら「特定のステータスのみ通知したい」場合や「特定の担当者にのみ通知したい」場合は標準機能では機能が不足します。
通知機能の検討において、通知方法の調整/カスタマイズに対するニーズが高い判断し、今回紹介する「作業者アサイン通知」を開発しました。

まずは「作業者アサイン通知」と「kintone標準のSlack連携」の差を見ていきましょう。

このように「SlackにDMで通知する」という基本機能は同等ですが、細かいところに差があります。

ユーザーへの影響が大きい要素が「通知タイミング」です。
kintone標準機能では、申請レコードのステータスが変わった瞬間に通知されます。
24時間365日、常に即時通知が必要な場合は有効ですが、「営業時間内に通知を出したい」場合や「特定のステータスで通知は不要」などの要件に対応できず、ユーザーからすると不便が生じることがあります。
また、kintoneの設定で多くの人を作業者に指定している場合、「Slack APIの上限」に抵触してしまい、メッセージの送信エラーが発生する場合があります。
経理関係の処理などで、「組織の全員を作業者」にアサインしている場合に制限に抵触する可能性があります。

機能開発の背景

ここまでは機能の差を紹介しました。
続いては「なぜこの機能を開発したのか？」の背景を紹介します。

私が所属するIT戦略部では「デリバリーの向上」に力を入れ、kintone申請における「待ち時間」をKPI目標として設定しています。
前回の記事で紹介した「承認者リマインダー」は待ち時間改善の第一弾として開発しました。
上記機能リリース後の効果検証において「承認以外でも通知を行うことで、よりデリバリーが改善するのではないか。」との意見が出たことをきっかけに、メンバー内で検討が始まりました。

開発において考慮したポイント

開発においては以下の【4つのポイント】を考慮して設計を実施しました。
1.SlackAPI上限を回避する
1点目は「SlackAPI上限の回避」です。SlackAPIの利用経験がある方はご存知と思いますが、API経由でSlackメッセージ送信する場合に「API送信数上限」が適用されます。
この上限は「利用しているSlack環境全体で共通」の上限であり、1つの送信機能が上限に抵触した場合でも「環境全体に影響が発生」し、他機能のメッセージ送信も止めてしまいます。
そのため、機能開発時には以下の点を考慮しました。

• 個人宛にメッセージを大量送信しない。
  • kintoneの作業者アサインが「部署やグループ」で設定されている場合、1人ずつ個別送信するとメッセージ量が膨大になり、API上限に抵触する可能性が増加する。
  • 実装ポイント：送信は「個人あて」ではなく「DMグループ」に送信する。

※DMを使用することで1回の送信で「最大8名に同報」できます。Slackチャンネルを作成することも検討しましたが、通知は「一過性」のためチャンネルではなくDMグループを選択しました。仮説：承認者が案件に気づいていない/承認件数が多くて見逃している。kintoneの「承認画面」を見ていない場合がある。

• 即時通知としない。
  • 通知メッセージは「1時間に1回の定期送信」とします。
  • レコードが1時間以内に2回更新された場合、「即時送信」だとメッセージが2回送信されますが、定期送信であれば1回の送信で済みます。
  • 上記で「通知されなかった1回目の更新」は「1時間以内にすでに誰かが処理した」ものなので、通知も不要ですね。

2.アプリやレコードごとの細かい通知制御を提供する。
2点目はkintoneの各アプリやアプリレコードに対する細かな通知制御の提供です。
通知したい内容はアプリごとに異なりますし、内容によっては「このレコードは通知しなくて良い」ものもあります。

今回の実装では各アプリに文字列形式の「通知制御フィールド」を設定し、アサイン通知機能の「トリガー」とすることで、直感的に設定しやすい仕様としました。

• 通知を実施する場合の設定
  • 共通のトリガーとして「通知制御フィールドが空欄」のレコードを「未通知」と認識します。
  • 作業者アサイン通知機能での通知実施後、通知制御フィールドに「レコードのステータス」を設定します。
• 再通知したい場合の設定
  • 「通知制御フィールド」を空欄にすると、未通知とみなされることを使用します。
  • 任意のタイミング（kintoneレコード更新から「3日後」等）で通知制御フィールドを空にする設定をkintone側ですることで再通知が可能です。
• 通知を回避する場合の設定
  • 作業者アサイン通知を設定しているアプリにおいて「このステータスでは通知不要」な条件がある場合は、レコード更新時（ステータス変更時）に「通知制御フィールド」を埋めるようにkintone側で設定します。
  • 通知したいステータスに変更した際に「通知制御フィールド」をクリアすることで通知対象になります。

3.通知メッセージをカスタマイズ可能にする。
機能の「汎用性」と「設定の自由度」のため、「追加の条件クエリ」と「通知用の任意テキスト」」設定を用意しました。

• 追加の条件クエリ
  • 例として「◯月◯日以降の申請のみ通知対象にしたい」場合や「テスト用のレコードは通知対象外にしたい」などのニーズに応えるため、機能動作のON/OFFをアプリごとに設定できるようにしています。
  • 下記の画像では「レコードIDが46番以降」でのみ通知機能がONになるように設定しています。
• 通知用の任意テキスト
  • デフォルトのメッセージの他、通知メッセージをカスタマイズ可能です。
  • 作業者向けの手順案内や作業時の注意を記載したい場合に活用できます。

まとめ

機能のリリースにより「kintoneの作業者がタスクに気づいてくれる」ようになり、結果として「各種申請の待ち時間が短く」なるメリットに繋がります。
一方で「作業者」目線では通知タイミングを設定することで、「即日通知で夜間・休日に通知が飛んでくる」ことが無くなります。
今回の取組は「kintone待ち時間の改善」を目的に開始しましたが、結果は「申請者と作業者の両方にメリットを生む」良い事例となりました。
今後も改善活動を継続するため、効果が高い施策についてブログで紹介したいと思います。