はじめに

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

DeNAでは物品購入や各種システムの利用申請などを「kintoneアプリ」を通じて行っています。
各種申請はアプリのワークフローにより承認や作業が実施され、約300の申請手続きが運用されています。
kintoneの全社利用は2014年2月から開始し、今年で10年を迎えました。
最初は数件だった申請アプリが増えていくことに比例し、以下の課題が大きくなってきました。

• 申請の承認が進まず、思うように進まない。
• 申請者や承認者の「対応待ち」が多く発生し、受付担当者のチェックが大変。
• 入力不備の修正など、申請者への対応依頼が放置されてしまう。
• 結果として申請から対応完了まで時間がかかってしまう。

課題解決のため、「申請に伴う作業の自動化」を拡大してきましたが、「承認」や「内容のチェック」など「人による確認作業」はゼロにすることができません。
今回はkintone申請にかかる「待ち時間」を改善し、全社業務の効率化に寄与した施策を紹介します。

この記事の流れ

• DeNAグループにおける「kintone」の活用
• kintone申請の課題
• 課題解決に向けた検討
• 「承認者リマインダー機能」の開発
• 「自動差し戻し機能」の開発
• まとめ
• 最後に

DeNAグループにおける「kintone」の活用

DeNAグループにおける「社内申請」業務は原則としてkintoneアプリのワークフロー機能で運用しています。
具体的には物品購入等の庶務事務、システムやPC等の社内IT関連、人事/労務関連といった定常的に発生する業務申請が稼働しています。
申請は以下のイラストのようにワークフローを流れていきます。

kintone申請の課題

申請の内容により、前述のとおり「承認」のプロセスを設定しています。
承認者は内容を確認し、内容の修正依頼や差し戻し対応を行います。
運用はルール化され、全体としてはスムーズに業務が進んでいますが、どうしても以下の課題が発生します。
【申請者の感じる課題】

• 申請が承認待ちで止まってしまい、後続の作業が進められない。
• 承認者から質問や修正依頼が入ることもあり、申請完了まで案件をウォッチしないといけない。
• 承認者である上司に「承認してください」と声をかけないとなかなか承認してもらえない。

【承認者の感じる課題】

• 毎日たくさんの承認依頼が届くので、見逃してしまう案件がある。
• 承認依頼はメールで通知されるが、メールが大量に届くので負担感が大きい。
• 申請者に内容の質問をしたがなかなか返事が来ない。

【kintone申請の運用課題】

• 全体で1日に500件を越える申請があり、「kintone申請の体験」が従業員に与える影響が大きい。
• 「申請から完了までの所要時間」を調査したところ、「数十営業日」かかっている案件がある。
• 申請についてkintoneのコメント機能やメール通知が見逃されるため、ユーザーによるSlackでの声がけが多く発生しており、効率的でない。
• 過去の申請案件が未完了で放置されているものが多くあり、「正確な申請から完了までの所要時間」が測定できない。

課題解決に向けた検討

IT戦略部の上位組織であるIT本部では「QCDの鼎立（ていりつ）」というミッションを掲げ、クオリティの高いITサービスを、低コストで速やかに提供する組織を目指しています。
kintone申請の課題は「デリバリー観点での機会損失が大きい」と認識し、改善に向けた検討を開始しました。
【課題の調査】
検討に先立ち、全社で利用されている主要な申請の「申請から完了までにかかる所要時間」を調査しました。
調査の中で特に経過時間の長い案件を調べていくと、以下の理由が特定できました。

• 「承認」にかかる待ち時間が長い。
  • 仮説：承認者が案件に気づいていない/承認件数が多くて見逃している。kintoneの「承認画面」を見ていない場合がある。
• kintone申請アプリ上でのコミュニケーション（質問や修正依頼）に時間がかかっている。
  • 仮説：kintone上のコメントに気づかない。申請者が申請したまま放置している場合がある。

【改善策の検討】
調査結果と仮説をもとに「改善策」を考えていきます。
解決すべき課題に対するアプローチを検討しました。

• 「承認者」に対して適切なタイミングで承認を促す（＝気づかせる）
• 「申請者」に対しするアクションを明確化する（＝働きかける）

次に具体的な仕組みを考えます。

• 承認者への通知機能を構築し、「確実に認識できる方法で承認依頼を通知する」
• 申請者により案件が放置された場合、「自動的に差し戻しをして気づかせる」

結果として上記2点が従業員の利便性（Quality）、開発の工数（Cost/Delivery）ともに満足のいく施策であると認識し、実際の設計/開発に進みました。

機能1：承認者リマインダー機能

「承認者リマインダー」機能は承認者への通知を行います。
【機能要件】
機能要件は以下の通り設定しました。

• 汎用性を持たせる。
  • 全ての「承認プロセスがあるkintoneアプリ」に適用できるようにする。
• 従業員が気づきやすい（リーチしやすい）通知方法とする。
  • 社内でのコミュニケーションはSlackが主流であるため、「Slackのメンション」で通知する。
• リマインドを繰り返し実施し、見逃しを防ぐ。
  • Slack通知も見逃される可能性があるため、承認が完了するまで通知を実施する。

【設計のポイント】
リマインド通知の条件設計は「汎用性」と「設定の自由度」を考慮して実施しました。

• 通知する申請の「ステータス」を指定することができる。
• 申請の「最終更新」からの経過日数を指定できる。
• kintoneアプリ個別にリマインドのタイミングを設定できる。
• 詳細な設定ができるように「任意のクエリ」でリマインド対象/タイミングを指定できる。
• リマインドメッセージには自由にテキストを設定できる。
  • 設定しない場合は既定の文面でリマインドできる。
• 直感的に設定できるインターフェイスとする。

kintone環境への実装

上記要件及び設計を反映し、以下の機能を実装しました。
【設定画面】
コンフィグファイルの作成やコマンドの入力は一切不要とし、「kintoneの標準画面（フォーム入力画面）」で設定できるように実装しました。
具体的には以下の項目に設定を入れていきます。

• kintoneアプリID
  • リマインダーを設定するkintoneアプリのIDを特定します。
• 設定ON/OFF
  • 機能動作のON/OFF切替に使用します。
• 「更新日時」のフィールドコード
  • どの項目を「リマインダー通知」の日数トリガーとするか指定します。
• ステータス
  • どのステータスを「リマインダー通知」対象とするか指定します。
• 経過日数
  • 更新日時からの日数をトリガーとして指定します。
• 追加クエリ（※）
  • 追加の動作条件を自由に設定できます。（詳細は後述します）
• リマインド用の任意のテキスト
  • Slackメッセージを指定します。（指定がない場合、既定文で送られます）

機能2：自動差し戻し機能

承認者からの質問や修正依頼が放置されている場合、承認者が差し戻すことも可能ですが、内容の確認や声がけなど承認者の負担が大きいことが難点です。
そこで、「放置された案件をシステムが自動的に差し戻すことで、滞ってしまった案件を一度リセットする」機能を考案しました。
「差し戻し」はネガティブな自動化とも見えますが、放置された案件をそのままにすることは望ましくありません。また、常に「有効な」申請だけが案件一覧に表示されるため、承認者・作業者ともに「今何をするべきか」明確になるメリットもあります。
【機能要件】
機能要件は以下の通り設定しました。

• 汎用性を持たせる。
  • 全ての「承認プロセスがあるkintoneアプリ」に適用できるようにする。
• 従業員が差し戻しに気づきやすい（リーチしやすい）通知方法とする。
  • 社内でのコミュニケーションはSlackが主流であるため、「Slackのメンション」で通知する。
• 申請案件が「動いている」場合は差し戻ししない。
  • 申請内容のが更新やkintoneコメントのやり取りなど、動きがある場合は差し戻ししない。
• 承認者リマインダー機能との組み合わせを考慮する
  • 「承認されずに放置」された案件も差し戻しできるようにする。

【設計のポイント】
承認者リマインド機能と同様に、「汎用性」と「設定の自由度」を考慮して実施しました。

• 差し戻し対象とする申請の「ステータス」を指定することができる。
• 申請の「最終更新」または「最終のコメント投稿」からの経過日数を指定できる。
• kintoneアプリ個別にリマインドのタイミングを設定できる。
• 詳細な設定ができるように「任意のクエリ」でリマインド対象/タイミングを指定できる。
• 差し戻しコメントには自由にテキストを設定できる。
  • 設定しない場合は既定の文面でリマインドできる。
• 直感的に設定できるインターフェイスとする。

kintone環境への実装

上記要件及び設計を反映し、以下の機能を実装しました。
【設定画面】
コンフィグファイルの作成やコマンドの入力は一切不要とし、「kintoneの標準画面（フォーム入力画面）」で設定できるように実装しました。 具体的には以下の項目に設定を入れていきます。

• kintoneアプリID
  • 機能を設定するkintoneアプリのIDを特定します。
• 差し戻しアクション名
  • kintoneアプリの「プロセス管理」と連動し、申請の処理内容を決定します。
  • kintoneの基本機能を呼び出す設計とし、機能の開発ボリュームを低減しました。
  • （例）プロセス管理に「差し戻し」というルールを作り、「申請待ち状態に戻す」というアクションを設定する。
• 経過日数
  • 更新日時（申請の更新またはコメント投稿）からの日数をトリガーとして指定します。
• 追加クエリ（※）
  • 追加条件を自由に設定できます。（詳細は後述します）
• コメント
  • 機能の設定を備考として記録できます。

【追加クエリの設定例】

• 申請内容による設定
  • 例として申請時のプルダウン選択で「sample2」の選択肢を選んだものを対象にするなど、申請内容による対象の指定ができます。
• 更新期間での設定
  • 特定の期間内に更新された申請のみ自動差し戻しの対象にできます。
• レコード番号での設定
  • 申請IDが一定以上、一定範囲内など柔軟に設定できます。

導入効果

「承認者リマインダー機能」と「自動差し戻し機能」の併用により、機能リリース後1か月で1つの申請あたり約20時間の待ち時間短縮効果を発揮しました。
仮説通り、承認者に伝わる形で速やかに通知することで申請の待ち時間を大幅に改善することができました。
承認者リマインダー機能は多い日には50回/日程度実行されています。
また、自動差し戻し機能を設定したアプリでは承認者リマインダーの実行後、2~3日営業日ほどで差し戻されるように設定されています。
自動差し戻し機能のリリース前は3年以上も放置されていた申請がありましたが、現在では申請が滞ることがなくなりました。

まとめ

kintoneを活用し、各種申請をシステム化しても申請者や承認者の「注意力」や「対応意識」に依存した運用が残ってしまうことを今回の対応を通じて認識しました。
全社員が出社している状況では「この申請お願いします」とか「これ直してくださいね」など直接の声掛けでカバーされていたものが、リモート勤務の拡大によりテキストベースのやり取りになったことで、効き目が薄くなったのではないか？とも感じています。
今回の取り組みでは「通知」と「差し戻し」の組み合わせによる業務効率化を実施しました。
しかしDeNAグループ全体で運用中のkintoneアプリは800を越えており、まだまだ効率化の余地があります。
業務の効率化の終わりは無く、できることも無限にあります。
我々のミッションとしてQCDを常に意識し「効き目がある」施策を実施し続けるため、これからも活動を続けていきます。

最後に

私の所属するテクニカルオペレーショングループでは新しい仲間を募集しています。
当グループでは、今回紹介した取組のように、「業務改善や効率化・省力化」を目的としたなチャレンジを行っています。
ご興味がある方はぜひ下記リンクから内容をご覧ください。