シフト運用の月次振り返り｜修正・未提出・不足を次月の改善へつなぐ

未提出、曖昧な回答、確定後変更、不足枠を別々に数えます。不足枠は何分単位か、変更は一件をどう数えるかを先に決めます。定義が変わると前月との比較ができません。

配布時に間違いが見つかっても、原因が希望の転記か、配置の判断か、古い版の配布かで対策が違います。変更履歴や受付記録を見て、発生元を確認します。

Googleスプレッドシートの変更履歴では、以前の版や変更内容を確認できます。ただし履歴だけで本人との確認内容まで分かるわけではないため、受付・合意の記録と合わせて見ます。

「気をつける」では実施したか分かりません。「来月の依頼文に終了時刻の例を追加する」のように、変更する物を明記します。

想定例の時刻再確認5件を調べ、うち4件が終了時刻の空欄だったとします。この場合は催促の回数を増やすより、提出案内へ開始と終了をセットで書く例を追加する方が原因に対応しています。「17時から」ではなく「17〜20時は勤務可」と示し、入力時に何が不足か分かるようにします。

次月も時刻再確認を同じ定義で数えます。対象人数が20人のままで、終了時刻の不足が4件から1件へ減ったなら、説明変更が役立った可能性があります。ただし他の条件も変わっていないか確認し、すべての改善を一つの変更の効果と断定しないようにします。新しい例で別の質問が増えた場合も記録します。

結果が変わらなければ、説明を読める場所へ置けていたか、時間欄が入力しやすいかを確かめます。注意書きをさらに増やす前に、実際の回答手順を一人に試してもらい、どこで省略が起きるかを見ます。振り返りを人への注意で終えず、使う案内や表を具体的に直すところへつなげます。

振り返りの最後には、変更するもの、担当者、実施日、結果を確認する日を一行にします。例えば「依頼文に終了時刻の例を追加、回収担当が次回案内前に更新、締切後に不足件数を確認」と書けば、実施したかと効果を別々に確認できます。「改善する」だけでは完了の判断ができません。

不足枠は30分単位など同じ区切りで数えます。ある月は人数不足、別の月は技能不足を同じ欄へ入れると比較しにくいため、必要なら種類を分けます。確定後変更も、一人の一日を一件とするのか、連絡一通を一件とするのかを決めて継続します。

対策を同時に増やしすぎず、まず一つを次月に試します。改善が定着したら手順書へ反映し、毎月の議題から外せます。残った問題を次の対象へ選ぶことで、振り返りの時間そのものが大きくなりすぎるのを防げます。

回収方法、締切、勤務コードを同時に変えると、何が改善に効いたか分かりにくくなります。影響の大きい一つを選び、次月に同じ項目を見ます。新しい方法でスタッフの負担が増えた場合も記録してください。

振り返りは個人を責める場ではなく、手順を直すために使います。件数が増えた月は、繁忙や対象人数の変化も見て、増加だけで運用が悪化したと判断しないようにします。