イベントや会議の日程調整をするとき、「調整さん」のような日程調整サービスを使っている組織は多いと思います。
参加者が候補日に○・△・×を入力し、その結果を見ながら開催日を決める。
シンプルで分かりやすく、非常に便利な仕組みです。
今回、私が作成したのは、そうした既存の日程調整サービスを否定したり、使いづらいから別のものを作った、というものではありません。
きっかけはもっとシンプルでした。
「自分たちの組織の使い方に合わせて、あと少しだけこうできたら便利なのに」
そんな、既存サービスではなかなか対応できない「痒いところ」に手が届く仕組みを追加していった結果、組織専用のフルカスタマイズ型出席管理Webアプリが完成しました。
一番大きな課題は「複数イベントの日程がバッティングすること」でした
今回このアプリを作る大きなきっかけになったのが、複数イベントを並行して日程調整したときのバッティングです。
たとえば、
- イベントA：9月10日 14:00〜15:00
- イベントB：9月10日 14:30〜16:00
という2つの候補日時が、それぞれ別々に提示されていたとします。
イベントごとに回答していると、
「イベントAにも参加できる」
「イベントBにも参加できる」
と回答してしまうことがあります。
しかし、最終的に両方ともこの日時に決定してしまえば、当然ながら同じ人が両方へ参加することはできません。
実際の運用でも、複数イベントの日程が重なり、片方のイベントに出席できなくなるケースが頻発していました。
個々のイベントだけを見れば正しい回答でも、組織全体の予定として見ると矛盾してしまう。
そこで今回のアプリでは、単純な出欠入力だけではなく、イベントをまたいで候補日時の重複をチェックする機能を実装しました。
複数イベントを横断してバッティングをチェック
参加者が出席可能な日時を選択すると、別のイベントですでに回答している日時と重なっていないかを確認します。
単純に「開始時間が同じか」だけを見るのではありません。
イベントにはそれぞれ所要時間が設定されているため、
- 13:00〜14:00
- 13:30〜14:30
のように開始時間が違っていても、時間帯が重なっていればバッティングとして判断します。
これによって、
「回答したときには気付かなかったけれど、後から予定が重なっていた」
という問題を、日程調整の段階でできるだけ防げるようになりました。
複数の会議、打ち合わせ、イベントを並行して調整する組織では、かなり効果の大きい機能だと感じています。
出欠入力だけではなく「決定後」まで管理
もう一つ重視したのが、日程調整後の運用です。
日程調整サービスでは、
- 候補日を出す
- メンバーが回答する
- 管理者が日時を決める
ところまでは非常に便利です。
しかし、実際の組織運営では、その後にも仕事があります。
「開催日が決まりました」と連絡する。
Googleカレンダーへ登録する。
回答していない人に連絡する。
締切前にもう一度案内する。
つまり、日程調整そのものより、その周辺業務に管理者の手間が残っていました。
そこで今回のアプリでは、この部分もできるだけ自動化しています。
Googleカレンダーへ決定したイベントを登録
管理画面から開催日時を決定すると、そのイベントをGoogleカレンダーへ登録できるようにしました。
イベント名だけではなく、決定した日時やイベントに必要な情報を引き継いで登録します。
これまでは、
「日程を決める」
↓
「Googleカレンダーを開く」
↓
「同じ内容でもう一度予定を作る」
という作業が必要でした。
この二重入力をなくし、日程決定からカレンダー登録までを一つの流れにしています。
回答期限前にはリマインドメール
イベントを登録するときには「回答期限」を設定できます。
そして回答期限が近づくと、対象者へリマインドメールを送信します。
これによって管理者がイベントごとに、
「まだ回答していない人はいないかな？」
「そろそろ締切だから連絡しよう」
と確認して、一人ひとりに案内する必要を減らしました。
複数イベントが同時に動いていると、この確認作業は意外と大きな負担になります。
回答依頼を出した後のフォローまでシステム側で支援することを重視しました。
イベントごとではなく「組織全体」で管理する
今回のアプリで意識したのは、イベント単体ではなく、組織全体の運用を見ることです。
参加者側では、登録されている複数のイベントを確認し、それぞれの候補日時に対して回答できます。
イベントには、
- イベント名
- イベント内容
- 回答期限
- 候補日時
- イベントの所要時間
などを設定できます。
候補日時も複数登録できるため、通常の日程調整ツールと同じ感覚で利用できます。
そのうえで、イベントをまたいだ予定の重複まで確認する仕組みにしています。
○△×だけではない回答管理
出欠についても、単純な「参加／不参加」だけではありません。
運用に合わせて、
- 出席
- 未定
- 欠席
- 遅刻などを含む状態
- コメント
といった情報を扱えるようにしています。
参加者のコメントについても管理画面上で確認できるため、
「この時間なら途中参加になる」
「別件の予定次第」
といった、○△×だけでは表現しにくい事情も把握できます。
これも、実際の組織運営から生まれた細かなカスタマイズの一つです。
回答期限が終了したイベントも分かりやすく整理
イベントが増えてくると、現在回答が必要なイベントと、すでに回答期限が終了したイベントが混在してしまいます。
そこで画面上では、回答期限が終了したイベントが分かるように表示を切り替えています。
参加者画面では終了したイベントを折りたたんで表示するなど、いま回答すべきものを見つけやすくするUIにも調整を加えました。
また、イベントの並び順についても、
回答期限が早いイベントを優先して表示
することで、利用者が「どれから回答すればよいのか」を判断しやすくしています。
同じ回答期限の場合にはイベント名を基準に整理するなど、日常的に使ったときの細かな見やすさも調整しています。
不要なイベントには「参加しない」という選択肢
組織に所属しているからといって、すべてのイベントが自分に関係しているとは限りません。
そのため、自分が参加しないイベントについては、画面から非表示にできる仕組みも設けています。
自分に必要なイベントだけを確認できるため、イベント数が増えても画面が煩雑になりにくくなります。
こうした機能も、一般的なサービスを使っているだけではなかなか実現しにくい、組織独自の運用に合わせた部分です。
管理者画面からイベントをまとめて管理
管理者向けには専用画面を用意しています。
ここから、
- イベントの登録
- イベント内容の設定
- 回答期限の設定
- 所要時間の設定
- 候補日時の登録
- 出欠状況の確認
- コメントの確認
- 開催日時の決定
- Googleカレンダーへの登録
- イベント情報の更新・削除
などを行えます。
つまり、単なる出欠表ではなく、
イベント作成 → 日程調整 → 回答管理 → 日程決定 → カレンダー連携
までを一つのWebアプリで行う形です。
改善前と改善後で何が変わったのか
今回の開発で特に大きく変わったのは、次の2点です。
1．イベントのバッティングを事前に発見できる
改善前
複数のイベントを別々に日程調整していたため、同じ時間帯に複数のイベントへ「参加可能」と回答してしまうケースがありました。
それぞれの日程が決まった後になって、
「両方同じ時間になってしまった」
と判明し、どちらかのイベントに参加できなくなることがありました。
改善後
複数イベントの候補日時を横断して確認するため、回答段階でバッティングに気付きやすくなりました。
結果として、日程決定後の再調整を減らせるようになりました。
2．管理者からの個別連絡を減らせる
改善前
管理者が、
「回答期限が近づいています」
「開催日時が決まりました」
といった連絡を、イベントごとに行う必要がありました。
さらに決定後にはGoogleカレンダーへの登録も別途行っていました。
改善後
回答期限に合わせたリマインドやGoogleカレンダーとの連携を組み込んだことで、管理者が毎回手作業で案内・登録する作業を減らせるようになりました。
単に回答を集めるだけではなく、
その前後に発生していた管理業務そのものを減らした
ことが今回の改善の大きなポイントです。
「有名サービスを置き換える」のではなく「自分たち仕様にする」
今回の開発で改めて感じたのは、業務効率化では必ずしも既存サービスを否定する必要はないということです。
調整さんをはじめ、一般的なサービスには、多くの人が使いやすいように考え抜かれた良さがあります。
一方で、組織によって、
「この情報も管理したい」
「複数イベントをまとめて見たい」
「この作業だけ自動化したい」
「自分たち独自のルールに合わせたい」
というニーズは必ず出てきます。
市販・クラウドサービスを組織側が無理に合わせて使うのではなく、
組織の仕事の流れに合わせてシステム側を変える。
今回のアプリは、その一例です。
GASだから、組織に合わせて細かく変更できる
今回のシステムは、Google Apps Script（GAS）とGoogleスプレッドシートを中心に構築しています。
そのため、
「候補日時をもっと増やしたい」
「回答項目を変えたい」
「表示方法を変えたい」
「別のGoogleサービスと連携したい」
「自分たち独自の業務ルールを追加したい」
といった変更にも対応しやすい構成です。
実際、今回のアプリも最初からすべての機能を決めて作ったわけではありません。
実際に運用しながら、
「ここが少し使いにくい」
「この作業も自動化できないか」
「この情報も一緒に見たい」
という要望を一つずつ追加し、現在の形になっています。
これこそが、フルカスタマイズで業務アプリを作るメリットだと思っています。
小さな「面倒」を積み重ねない仕組みへ
1回数分の作業だけを見れば、
「わざわざシステム化するほどではない」
と思うかもしれません。
しかし、
- 毎月何件もイベントがある
- 参加者が何十人もいる
- 回答状況を何度も確認する
- リマインドを送る
- 日程決定を案内する
- カレンダーへ転記する
- バッティングが起きれば再調整する
という作業が積み重なれば、管理者にとってかなりの負担になります。
業務効率化では、大きな仕事を一気に自動化するだけでなく、
毎回発生している小さな手作業を少しずつなくしていくこと
も非常に重要です。
今回の出席管理アプリは、まさにそうした考え方から生まれました。
「今使っているサービスに、あと少し機能があれば」を形にできます
今回紹介した出席管理アプリとまったく同じものが、すべての組織に必要なわけではありません。
大切なのは、
「自分たちの組織では、どこに手間が発生しているのか」
を見つけることです。
既存サービスで十分なところは、そのまま使う。
足りない部分だけ別の仕組みで補う。
あるいは、今回のようにGoogle Apps Scriptなどを利用して、自分たちの業務に合わせたWebアプリを作る。
生成AIやローコード・ノーコード、GASなどを組み合わせることで、以前よりもこうした小規模な業務システムを作りやすくなっています。
「今のやり方でも仕事はできる。でも、毎回ここだけ面倒」
そんな部分こそ、業務効率化を考える良いスタート地点かもしれません。