先週の出勤希望を確認しようとして、スタンプと雑談を親指で延々と遡る。「たぶんこのへんで誰かが出してた」というところまでは分かるのに、目的のメッセージには届かない。途中に入る「おつかれさまです」や店の連絡が邪魔をして、どこまで確認したかも見失う——LINEグループでシフトを回している店の、毎週の光景です。
LINEグループだけでシフトを管理すると、出勤希望が雑談に埋もれ、未提出者・変更履歴・最新版を一覧で確認できなくなります。LINEは今この瞬間のやりとりを速く回すためのツールで、過去の一件を正確に取り出す用途には向いていません。通知と、参照し続ける原本を分けるのが基本です。
破綻の典型パターンから、原本を一つに決めたときに何が変わるかまで、遡り確認と二重転記が消える理由を見ていきましょう。
LINEは「流れる」ように作られている
チャットは、新しい発言がいちばん上に来るツールです。今この瞬間のやりとりを速く回すために作られている。だから盛り上がっている会話には強い。反面、過去の一件を正確に取り出す用途には向いていません。
シフト希望はその逆で、「先週の水曜に誰が何時上がり希望だったか」を、あとから何度でも引く情報です。性質が正反対のものを一つのグループに流し込むと、必要な情報ほど雑談の下に沈んでいきます。
大きな課題は、未提出者を一覧で確認しにくいことです。17人のキャストに希望を出してもらった場合、グループ投稿だけでは履歴をさかのぼって発言者を照合する必要があります。人数が増えるほど確認工数が増え、見落としやすくなります。
この作業は、毎週かかる固定費のようなものです。1回の締切ごとに名簿とトーク履歴を突き合わせ、未提出者に個別で催促する。10人を超えたあたりから、この照合と催促だけで30分や1時間が飛びます。しかも締切の直前に集中するので、いちばん忙しい時間帯に発生する。作業が減らないまま人が増えれば、シフト担当が一人でこれを抱えきれなくなるのは時間の問題です。
破綻の典型パターン
店の規模や人によらず、詰まる場所はだいたい同じです。
一つ目は見落とし。ある子が金曜の夜に希望を送ったが、ちょうど別の話題が流れていて、店長が既読をつけないまま下に流れた。確定シフトを組む段になって本人が「金曜、出したはずですけど」。店長は「見てない」。ここから始まるのが、証拠の残らない水掛け論です。送った側のトーク画面には確かに残っているのに、集約する側の頭からは抜けている。どちらも嘘はついていないのに、話が噛み合いません。
二つ目は、確定後の変更が矛盾したまま残ること。日曜のシフトを一度流したあと、「土曜、やっぱり出られます」「じゃあ日曜と入れ替えで」と口頭とLINEで何度か直す。すると同じ週について、3つも4つも別々のメッセージが履歴に散らばります。どれが最新版なのか、当日にならないと誰も断言できない。出勤して初めて「え、今日入ってました？」が発覚する。
三つ目が、いちばん静かに効いてくる分散です。グループに出す子もいれば、店長の個人LINEに直接送る子もいる。体調の相談は個人、希望はグループ、変更はまた個人。結果として、店全体のシフトの全体像は、集約している店長一人の頭の中にしか存在しなくなります。その店長が体調を崩した日、誰もシフトを引き継げません。
それでもLINEを使うなら役割を限定する
とはいえ、明日からLINEをやめろという話ではありません。キャストは使い続けるし、通知が届くのはLINEの強みです。やるべきは、LINEに何をやらせて、何をやらせないかを線引きすることです。
原則は一つ。LINEは「通知」に使い、「原本」は別に持つ。締切のお知らせ、リマインド、確定版が出たことの一報。こうした「読んで流れていい情報」はLINEで構いません。一方で、誰がいつ何を希望したかという参照され続けるデータは、スプレッドシートでも紙でも、1箇所に集約された場所に置きます。ツールが高機能である必要はなく、「原本はここだけ」が全員に共有されていることが重要です。
希望の提出も、チャットの本文に書かせるのをやめます。日付ごとに可否と時間を入力する構造化された入口——フォームや共有シートのような形——に寄せ、締切を固定する。自由文で「来週わりと入れます」と送られると集計できませんが、日付単位の入力なら未提出者もその場で分かります。
確定版を流すときも、毎回同じフォーマット、同じ曜日にする。「水曜の朝に、この形式で最新版が来る」と決まっていれば、キャストは過去の断片を探しません。最新はいつも決まった場所にある、という状態を作ることが、水掛け論を減らします。
線引きを一言でいえば、LINEには「知らせる」役だけを残し、「覚えておく」役から外す、ということです。LINEに覚えさせようとするから流れて消える。覚える場所を別に用意すれば、LINEは本来得意な通知だけに専念できます。
シフトの原本を持つと何が変わるか
原本を1箇所に持つと決めた瞬間に、いくつかのことが自動的に片づきます。まず、出していない人が一目で分かる。提出済みを数える作業から、未提出を確認する作業に変わります。次に、変更の履歴が残る。「日曜と土曜を入れ替えた」という事実が、いつ・誰の申請で起きたかごと残るので、当日の「入ってました？」が起きません。そして、確定したシフトと実際の出勤・給与計算を突き合わせられる。LINEの履歴からは決して作れなかった突合が可能になります。さらに、担当者が休んだ日でも別の人が同じ画面を開けば全体像を把握できる。属人化していたシフトが、店の共有物になります。
回収から確定までの具体的な進め方——提出期間の固定のしかた、未提出者の出し方、希望と確定の分け方——は、出勤希望を回収して確定シフトを共有する方法で手順として整理しています。ただ、この手順を毎週人力で回し続けると、照合と催促にかかる時間も、担当者への引き継ぎも、そのまま店のコストとして積み上がります。その毎週の照合のために、私たちはシフト管理システムを作っています。提出フォーム、未提出者の確認、確定シフトの共有を一つにまとめ、原本が流れていかない状態を最初から用意する。いま親指スクロールと催促にかけている時間と見比べて、任せる価値があるかを確かめてもらえればと思います。
LINEで回すのをやめる必要はありません。ただ、店のシフトの「原本」は、流れていかない場所に移します。通知と原本を分けることで、履歴を遡る確認や最新版を巡る認識違いを減らせます。
よくある質問
LINEのグループを完全にやめる必要がありますか？
やめる必要はありません。通知やリマインドにはLINEを使い続けて構いませんが、誰がいつ何を希望したかという原本は、流れていかない別の場所（表やシステム）に分けて持つことが重要です。
出勤希望をLINEの個人メッセージで受け取るのはダメですか？
個人LINEへの分散は、店全体のシフト情報が担当者一人の頭の中にしか残らない状態を生みます。担当者が休むと誰も引き継げなくなるため、希望の提出先は個人ではなく一つの窓口・原本に統一するのが安全です。
シフトの原本は紙とスプレッドシート、どちらがいいですか？
どちらでも構いません。重要なのはツールの高機能さではなく、「原本はここだけ」と全員が共有できていることです。人数が増え、照合や催促の手間が負担になってきたら、専用のシステムへの移行を検討する目安になります。
この記事の課題を、システムで解決するなら
その毎週の照合を、原本ひとつに移す
お店専用のシフト管理システムなら、出勤希望の回収、未提出者の確認、確定シフトの共有を一つの画面にまとめられます。毎週の親指スクロールと、締切前の催促にかかっていた時間がなくなります。相談は無料で、導入前提でなくても大丈夫です。
画面も項目も、お店の運用に合わせて一から設計します。何をシステムにするか決まっていない段階のご相談も無料で承ります。
※ 画像は過去の開発例で、実際に開発する画面とは異なります。
画面は開発例です。項目・機能・デザインは、お店の運用に合わせて一から設計します。
出勤希望の回収から確定共有までを一つの原本にまとめ、転記と催促を減らします。
- 1キャストが希望日を提出
- 2不足日と未提出者を自動表示
- 3確定シフトを全員へ共有