報告書の提出忘れを防止！kintone出張申請アプリにおける「データ自動作成」構築事例

チームで出張に行くことが多い場合、kintoneの出張申請アプリを「1人1申請」で行う形ではなく、「代表者がまとめて1申請」する形で構築しているケースがあります。代表者が申請を行うことでチーム内の他メンバーは申請を行う必要がなくなるため手間が減り、かつ、申請を受けて手配する側もスムーズになることが期待されますが、ここで一つ大きな課題が生まれます。それは、「申請は1つでも、報告書は人数分必要になる」という点です。

自分が申請していない分、メンバーはつい報告書の作成を忘れてしまいがちですし、管理者も誰が提出していないのかを把握するのにデータ自体が登録されていないため苦労します。結果として、個別のリマインド連絡に多くの時間を取られてしまうこともあるのではないでしょうか。

そこで本記事では、「代表者申請」と「報告書データの自動作成」を組み合わせた出張申請アプリ・出張報告書アプリの構築事例を紹介します。

この事例の一番のポイントは、出張申請承認のタイミングでシステム側で人数分の報告書データを自動的に作るという点です。 あらかじめシステム側で報告するためのレコードを用意することで、kintoneの標準機能である「リマインダー通知」を活用できるようにしました。

もし同じような構成のアプリを運用しており、なんとか現場の手間・管理の手間を改善したいと悩んでいるなら、この事例は間違いなく解決のヒントになるはずです。

【課題背景】紙ベースの運用が引き起こしていた3つの課題

このお客様では、出張時の申請と報告書の提出を紙ベースで行っていました。出張は複数人のチームで行くことが多いため、その中の一人が申請を行い、それを受けて総務が宿泊や新幹線などの手配を行います。出張後はチームの全員が出張報告書の提出を行い、出張としての一連の業務が完了します。

この出張申請・出張報告において、チーム単位での動きが多い組織ならではの、「連携ミス」や「管理コストの増大」がありました。その3つの具体的な課題は次の3つに集約されます。

チーム内の連携ミスによる重複申請と総務の突合負担

1つ目の課題は、申請段階における混乱です。 チームで出張に行く際、本来であれば誰か1人が代表して申請を行えば済みます。しかし、紙の運用、かつ、明確なルールが徹底されていない部分もあったため、チーム内でのコミュニケーション不足が発生することが度々ありました。

例えば、「誰かがやってくれているだろう」と思って誰も申請していなかったり、逆に「自分がやらなければ」と気を利かせた複数のメンバーが、それぞれ同じ内容の申請書を提出してしまったりするようなことです。

このしわ寄せがいくのが、手配を担当する総務担当者です。 回ってきた申請書の内容を見て、「これとこれは同じ出張の件ではないか？」「二重手配になっていないか？」と、紙を並べて突合確認・申請者への再確認を行うという手間が発生していました。

現場の報告書提出忘れと常態化

2つ目の課題は、出張後の報告書提出における問題です。

出張申請自体は代表者が行ったとしても、業務報告書は参加したメンバー全員が提出する必要があります。しかし、出張から戻るとすぐに次の業務に追われ、あとで書こうと思っているうちに提出すること自体を忘れてしまうケースが発生していました。

悪気があるわけではないものの、忘れても特に何も言われないという状況が続くと、提出忘れが組織全体の悪しき習慣として常態化してしまいます。

提出漏れは把握できても物理的に追いつかない督促

3つ目は、管理者側のアクションにおける限界です。

管理者は、承認された「出張申請」と提出された「報告書」を突き合わせることで、理屈の上では誰が出していないかを特定することは可能です。しかし、それをアナログで行うのは膨大な手間がかかります。さらに、未提出者を特定できたとしても、その一人ひとりに対して督促をするのは、時間的にも大きな負担となります。

「出していない人がいるが個別の督促の手が回らない」という状況で、人の手による管理ではなくシステムによる自動的なフォローの仕組みが求めらていました。

【kintoneアプリ実例】チーム出張における「代表者申請」と「報告書データ自動作成」の全体像

これらの課題を解決するために、出張申請（＋出張手配）アプリ、出張報告書アプリの2つをkintoneアプリで構築しました。

アプリの構築にあたり、申請系のアプリではよく見受けられる「1人1レコード申請」や「各自がゼロから報告書を作成する」というプロセスは廃止し、課題や業務実態に合わせたフローを実現しました。出張申請アプリの1レコードに対して、出張報告書アプリは複数レコード紐づくようなイメージです。

具体的にどのような業務フローを実現したのか、その全体像を2つのポイントに分けて解説します。

代表者申請による申請の一本化

まず1つ目のポイントは、申請プロセスを「代表者による代理申請」に一本化したことです。

一般的な申請系のアプリの運用では、例えば5人で出張に行く場合、5人全員がそれぞれ申請を行う必要があります。しかし、これでは同じ内容の申請が5件並ぶことになり、承認者も5回承認ボタンを押す必要があります。また、申請プロセス上で総務担当者がホテルや交通手段の手配も行っているため、同じ出張なのにバラバラの申請データを確認して手配するのはミスの温床となります。

そこで本事例では、チームの代表者のみが申請アプリに登録・申請する運用に変更しました。

1. 代表者が「出張申請アプリ」を開く
2. 日程や行き先、目的などの共通情報を入力する
3. 「同行者」フィールド（ユーザー選択）で、一緒に行くメンバー全員を選択する
4. 必要に応じて、手配が必要もの（宿泊、飛行機、新幹線 等）の希望条件を入力し、申請する

このような形のアプリにすることで、これまで紙でバラバラに上がってくることもあった申請が1つのレコードに集約されるようになりました。 これにより、申請の手間が減るだけでなく、承認者の負担も軽減されます。また、手配担当者にとっても「1つのレコードを見れば、誰と誰がどこに行くのか」がひと目で分かるため、手配漏れやミスを防ぐ確実な運用が可能になりました。

報告書レコードの自動作成

2つ目のポイントが報告書データの自動作成です。

通常、出張から戻ったメンバーは自ら出張報告書を提出します。しかし、この報告書の提出は必須とはいえ、担当者が忙しくて忘れてしまうということが多発していました。そのため、「出張報告書アプリ」を作成したとしても、「忘れる」という点は解決されずに残ってしまうことが懸念されていました。

この課題を解決するために、以下のカスタマイズを行いました。

こうすることで、出張から帰ってきたメンバーがkintoneを開くと、自分の名前が入った報告書（中身は空の状態）が用意されている状態となるようにしました。メンバーは、ポータル画面の「未処理」から自分のレコードを開き、報告内容を埋めて保存＆提出するだけで業務が完了します。ゼロからデータを作るのではなく「用意された枠を埋める」という形に変えることで、心理的なハードルを下げつつ、ポータルトップに未処理として表示されるようになるため、自分がやるべき作業が明確になります。

そして一番のポイントは、kintone標準機能の「リマインダー通知」がつかえることです。報告書用のレコードが存在しているため、「帰着後3日経っても未提出の場合は通知する」ということが可能になります。これにより、管理者がわざわざ未提出者を探し出して連絡する手間はなくなります。

【実装のポイント】出張申請業務に合わせたカスタマイズ

報告書データの自動作成について、カスタマイズの概要は次の通りです。

同行者情報を元に承認トリガーで複数レコードを生成

今回実装したカスタマイズの動きは、非常にシンプルです。 kintoneの標準機能である「プロセス管理（ステータス変更）」の動きに合わせて、プログラムが自動的に作動するようしました。

具体的な処理の流れは以下の通りです。

1. 申請アプリ側で、ステータスが「承認」に変更された瞬間をプログラムが検知。
2. 承認されたレコードから、「出張の日程」「行き先」「同行者フィールドに入っているメンバーの情報」を取得。
3. 同行者フィールドに入っているメンバーの数だけ、以下の処理を繰り返し処理。
   • 「Aさんの名前」と「日程・行き先」が入った報告書レコードを作成
   • 「Bさんの名前」と「日程・行き先」が入った報告書レコードを作成
   • 「Cさんの名前」と「日程・行き先」が入った報告書レコードを作成

この処理はほぼ一瞬で行われるため、承認ボタンを押した直後には、すでに報告書アプリに人数分のレコードが登録されています。

報告書レコードの自動作成により「リマインダー通知」が活用できる

出張報告書アプリへのレコード自動作成を組み込んだのは、「リマインダー通知」を活用するためです。

kintoneのリマインダー通知は「レコード内の日付」を基準に通知を送る機能ですので、レコードが存在していることが通知を送るための絶対条件となります。

• 各自が登録する場合：
  ⇒レコードがまだ作られていないため、「出していない人」に対してシステムから通知を送ることができない。
• 今回の場合（自動作成）：
  ⇒すでに「日付」と「担当者」が入ったレコードが存在しているため、リマインダー通知が可能。例えば、帰着日の3日後になってもステータスが未提出なら通知する」といったことが可能。

レコードを先に用意するだけで、これまで管理者が手動で行っていた督促を、kintoneの標準機能にすべて任せることができるようになります。

なぜカスタマイズを選択したのか

「kintoneの標準機能や、市販のプラグインで実現できなかったのか？」という疑問を持たれるかもしれませんので、最後に技術的な選定理由について触れておきます。

結論から言えば、今回の要件である「1つの申請レコードから、ユーザー選択フィールドの人数分だけ、別のアプリにレコードを分割して登録する（1対Nのデータ作成）」という処理は、標準機能できなかったためです。また、承認後にアクションから人数分ボタンクリックで承認者が登録する、という運用も考えられますが、本来これは承認者がやるべき作業ではないため、この方法は提案しませんでした。

【導入効果】現場と管理部門双方の業務負担を削減

この仕組みを導入したことで、現場のメンバー、そして管理部門の双方の業務負担を見込んでいます。

申請者・承認者：入力作業の集約と手続きの簡素化

まず、申請者側のメリットは「手間の削減」です。 チームメンバー全員が個別に申請するのではなく、代表者1名が入力する形になりました。入力する代表者にとっても、自分の申請ついでにメンバーを選ぶだけなので、大きな負担増にはなりません。承認者にとっても承認作業が1回で済むので、決裁スピードの向上にもつながります。

管理部門（総務）：突合不要の手配フローと自動化された督促

まず、申請データが「チーム単位」で1レコードにまとまっているため、ホテルや交通機関の手配に必要な情報が集約されました。以前のように、バラバラに届く申請書を並べて「これは同じグループか？」と推測しながら突合する必要はありません。また、申請内容がデータとして残るため、重複した申請が仮にあってもすぐに確認することができるようになります。総務の手配担当者も記録として残るため、総務内での分担も見える化が実現できます。

そして、 未提出者にはシステムが自動的にリマインドを送ってくれるため、管理者は「提出状況を目視確認して個別に連絡する」という業務から解放されました。結果として、本来注力すべきコア業務に時間を使えるようになっています。

まとめ

kintoneの標準機能は非常に優秀ですが、すべての業務フローをカバーできるわけではありません。 特に今回のような「チーム単位での動き」や「申請と報告の紐づけ」といった要件は、標準機能だけで実現しようとすると、かえって現場の運用を複雑にしてしまうことがあります。

「kintoneに業務を合わせる」ことも大切ですが、どうしても譲れない業務の流れがある場合は、今回のように必要なカスタマイズを取り入れることが、結果として現場の定着と管理コストの削減につながります。

当社では、お客様の業務を深くヒアリングした上で、標準機能でできること、プラグインでできること、そしてカスタマイズすべきことを整理し、最適なプランをご提案しています。

「今のkintoneアプリ、もう少しなんとかならないか」とお悩みの方は、ぜひ一度ご相談ください。現在の課題を一緒に整理し、最適な解決策を見つけていきましょう。