シフト作成から勤怠集計・給与計算・明細発行までを一つのアプリに。

シフト作成が担当者の手作業で、希望の収集から調整まで毎月時間がかかっている。

勤怠の集計と給与計算が別々の作業になっており、その間に転記が発生している。

工数の多くは、シフトを「作る」時間ではありませんでした。希望を集めて調整する往復に費やされていたことが本質です。

勤怠と給与が別作業なのは、間に人の転記が入る設計だったためです。転記が残る限り、どちらの作業を速くしても全体は縮まりません。

したがって解くべきは「シフト作成を自動化する」ことではなく、希望提出から給与明細まで、人の転記が1回も入らない一本の流れにすることだと整理しました。

さらにヒアリングを進める中で、全員がアプリに入れる状態を作ること自体が最大の関門だと分かりました。機能をどれだけ作っても、スタッフが入口で止まれば1件も動きません。仕組みより先に、アカウントと認証の設計が必要でした。

シフト希望の提出・自動生成・調整・打刻・勤怠集計・給与計算・給与明細の発行までを、1つのアプリに統合しました。

シフトの自動生成に条件マスタ（人員・法定休日・時間帯）を持たせ、生成前の事前チェックと生成後の検証を1つの処理に固定しています。

自動生成したシフトが条件を守れているかを本番データで検証し、違反0件を確認しました。

打刻漏れの検出と通知、店長による承認、打刻履歴からの確定時刻入力に対応しました。

本部・店長・スタッフで、見える範囲を役割ごとに分けています。

既存の勤怠サービスと並行運用しながら、段階的に切り替える方針としました。

まず1店舗をモデル店舗として、打刻から順に移行しています。

うまくいかなかったことが5つありました。

1つ目は、スタッフがアプリにログインできない事象です。原因は業務システムではなくGoogle側でした。チャットアプリ内のブラウザからの認証と、2段階認証が未設定の新規アカウントという条件が重なり、不審と判定されて同意操作だけが拒否されていました。

2つ目は、管理コンソールで「信頼できるアプリ」に登録しても解決しなかったことです。消えるのは同意画面だけで、リスク判定は別の仕組みでした。設定では防げず、ご案内の手順そのものを変える必要がありました。

3つ目は、認証コードが届かない原因が、Googleアカウントの「復元情報」が空欄だったことです。メールの転送設定は正しく、まったく別の場所に原因がありました。

4つ目は、未認証のままだとアプリの入口で認証画面へ飛ばされ、提出画面に到達できないことです。催促しても提出できない状態でした。

5つ目は、アドレスを修正すると認証がリセットされる仕様があり、一括で済ませた認証が巻き戻っていたことです。根本の要因は、全員が共通のパスワードを使っていたことでした。

スタッフ全員分のアカウントを発行・管理できる体制。ここが最大の関門になります。

2段階認証とパスワードの個別化を、導入前に決めておくこと。

既存の勤怠サービスと並行運用できる期間を確保できること。