シフト希望の集約をシステム化する｜提出・確定・変更の管理

シフト希望を管理するシステムでは、希望の提出と勤務の確定を別データとして扱い、確定後に変更したときは対象者が確認したかまで追えるようにします。希望欄を確定勤務で上書きすると、本人の希望どおりなのか、管理者が調整した結果なのかが分からなくなるからです。

もう一つ分けたいのが「未提出」と「希望なし」です。「希望なし」も、勤務できる日時がないのか、特定の日時に希望がないのかで意味が変わります。提出状態とは別に本人の意思を記録し、催促する相手と勤務案へ進める相手を選べるようにします。

製品仕様は2026年10月5日に公式情報で確認しました。台帳と判断表は自社向けの架空の設計例であり、cotomuの標準機能や導入実績を示すものではありません。

希望・調整中・確定を分ける台帳

希望回収の画面に確定勤務まで書き込めれば、表は簡潔に見えます。ただし、管理者が勤務日時を変えた瞬間、元の希望が消えます。一枚の表に収める場合も、意味の異なる状態を識別できるデータ構造が必要です。

架空の設計例では、対象者と対象日で関連付けながら、次の三つを分けます。一日に複数の勤務がある場合は、勤務ごとに確定IDを付けて変更対象を区別します。

三つを分けると、「希望どおりではない確定」が誤りなのか、必要な調整なのかを元データに戻って確認できます。希望は判断材料、確定は勤務予定であり、同じ日時を持つ場合でも役割は同じではありません。

本人が希望を出し直した場合も、前の希望を消さず、新しい版として受け付けます。調整中と確定がどの版の希望を参照したかを残せば、再提出の前後で管理者の判断材料が入れ替わっても経緯をたどれます。

Airシフトでスタッフが希望を提出するには、招待とスタッフ用アプリの利用が前提です。同製品では、スタッフが提出した勤務希望または休み希望をシフト表へ反映する処理と、確定シフトをスタッフ用アプリで共有する処理が分かれています。下書きシフトを確定すると、勤務・休み日時が通知されます。Airシフトのシフト管理機能とAirシフト公式手順書で、希望・下書き・確定の扱いを確認できます。手順書の掲載情報は2025年11月現在で、その後の更新により内容が異なる場合があると明記されています。

「未提出」と「希望なし」を分ける判断表

空欄を休み扱いにすれば、集計は早く終わるかもしれません。ところが、未入力の人まで意思表示済みになり、催促すべき対象が消えてしまいます。提出状態を独立させれば、この混同を避けられます。

判断の要点は、「希望なし」を空欄や一つの選択肢にまとめないことです。勤務不可と日時の希望条件なしを分け、提出済みという状態と提出日時を残します。日時の希望がなくても、いつでも勤務できるとは扱いません。

催促も、単に一斉通知を送る処理にはしません。対象は未提出者に絞り、送信日時と対象を記録します。公式の提供例では、Airシフトは希望シフトの提出依頼をスタッフへ自動通知します。らくしふのシフト管理機能も、未提出を独立した対象として扱う例です。

締切を過ぎても、未提出はその状態のまま保持し、再提出を認めるかを管理者が決めます。らくしふでは、期限内は従業員が希望を変更でき、期限後は従業員自身では変更できない一方、管理者の設定で再提出を可能にできます。欠員や提出率が低い場合に、提出期間後の再提出を依頼できることも公式ページに記載されています。締切後の扱いまで状態にすれば、例外対応が口頭連絡だけに残りません。

確定シフトの変更は、承認と通知を分けて判断する

確定後の変更をすべて同じ処理にすると、二つの異なる業務が混ざります。本人の同意を得て初めて確定させる変更と、すでに決まった内容を知らせる変更です。処理は、自社の運用ルールで定めた「承認を要する条件」によって選びます。変更の理由や大きさだけを条件にすると、担当者ごとに判定が揺れます。

架空の設計例として、変更登録時に次の判断表を使います。

「通知を送った」は、「本人が見た」と同じではありません。公式情報が通知や共有までしか説明していない場合、閲覧確認までできると読み替えず、通知日時と本人確認を別欄にします。確認方法がシステム外になる運用でも、確認済みへ更新する担当者と条件は決めておけます。

製品ごとの処理にも、この分岐を考える手掛かりがあります。Airシフトの公式手順では、確定シフトの時間変更について、スタッフへ変更を依頼して承諾・辞退を選んでもらう方法と、確定事項として変更後の時間を通知する方法を分けています。前者は承諾するとシフトが確定します。らくしふでは、確定後のシフトを変更し、対象スタッフだけへ再度の確定通知を送れると案内しています。これらの説明から確認できるのは依頼・通知の処理までであり、本人の閲覧確認とは分けて扱います。

確定後変更の承認・本人通知確認表

判断表が「どの処理に進めるか」を決めるのに対し、確認表は変更案件がどこで止まっているかを示します。架空の設計例では、変更1件につき次の列を持たせます。

一覧の抽出条件は、「確定勤務に対する変更案件が作成済み」かつ「完了日時がない」とします。確定勤務へまだ反映していない承認待ちも対象です。変更IDごとに未完了を判定すれば、後の変更で前の未確認が隠れません。

同じ勤務の変更が重なったら、反映直前に元の確定版と現在の版が一致するかを確認します。版の照合と更新は、別の変更が途中で割り込まない一連の処理にします。一致しない変更は保留し、管理者が最新の勤務に合わせて変更案を作り直します。以前の案への承諾を流用せず、作り直した案で承認依頼か変更通知を行います。

辞退された案は勤務へ反映せず、管理者が辞退結果を記録して終了します。無応答を承諾とみなすことはせず、期限後は確認担当の管理者が連絡・再調整を引き取ります。回答期限と通知後の確認期限は、勤務開始前に再調整する時間を確保できるように設定します。

新しい案で置き換えるため旧案を取り下げる場合は、管理者が理由と引継ぎ先の変更IDを残し、対象者へ旧案が無効になったことを連絡して終了します。取下げ済みの案への返答は履歴に残し、勤務には反映しません。旧通知の未確認は確認済みに書き換えず、新しい変更案件で最新の勤務を確認できるまで追います。

運用手順は次の順序になります。

1. 変更前の確定勤務と版を残したまま、新しい変更案件として変更案、理由、確認担当、期限を登録する。
2. 自社ルールに照らし、承認依頼・変更通知・管理者確認のいずれかを選ぶ。
3. 承認依頼では承諾・辞退を記録する。承諾後、元の確定版が現在の版と一致するときだけ反映し、一致しなければ保留する。
4. 変更通知でも元の確定版を照合してから勤務を更新し、対象者と通知日時を記録する。
5. 本人確認が必要な運用では確認済みになるまで未完了一覧に残す。

この順序なら、承認が必要な変更を先に確定してしまう逆転を避けられます。辞退された変更案は現在の確定勤務を変えずに履歴へ残し、通知しただけの案件は未確認として追えます。

導入前に決めるシステムの境界

入力画面を作る前に、状態を変える権限と完了条件を決めます。少なくとも、次の問いに答えられる必要があります。

• 本人は提出期限の前後で、どのデータを変更できるか。
• 管理者は未提出者をどの条件で抽出し、再提出を誰に許可するか。
• 調整中から確定へ進められる担当者は誰か。
• 確定後変更を承認依頼と変更通知へ分ける社内基準は何か。
• 本人確認を何で判定し、誰が確認済みに更新するか。
• 辞退・無応答・古い版への返答を、誰がいつ確認するか。
• 変更前後の記録をどこまで保持し、どの権限で参照できるようにするか。

選択肢が定型製品の設定範囲に収まるか、個別の業務アプリが必要かを考える際は、SaaS・kintone・オーダーメイド開発の比較が判断軸になります。現在の表計算からデータを移す範囲や移行順を整理する場合は、Excel管理からシステムへ移行する判断基準も参照できます。

試作では、未提出・勤務不可・日時の希望条件なしを別々に登録し、提出の催促対象が未提出者だけになるかを確かめます。確定後の変更では、先の案への承諾が遅れて届いても最新の勤務を上書きしないか、未処理の辞退と期限超過が確認担当の一覧に残るかを試します。通知後の未確認も含めて、次に誰へ連絡するかを選べることが合格条件です。

cotomuでは、困っている業務一つからWebアプリの設計・開発を相談できます。初期開発と運用保守は個別見積もりで、連携、移行、権限、データ出力の範囲は契約前に確認します。業務アプリの相談からお問い合わせください。相談に向けて、現在の希望回収方法と、確定後変更で困っている場面を整理しておくと話を進めやすくなります。