メインコンテンツへ移動

シフト表を統一する前に、誰が・いつ・どこまで変更できるかを決める。

CASE STUDY ・ 小売業 ・ ShiftMate(仮称)

  • Next.js
  • Ant Design
  • NestJS
  • React Query
  • TypeScript

※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。

01CLIENTお客様について

多店舗では、共通の画面より確定ルールを先にそろえる

対象となった事業者では、スタッフが希望シフトや休暇を提出し、店長が店舗ごとのシフトを作成・承認し、本部が全店舗の状況とマスタを管理する必要がありました。三者が同じ情報を参照できても、誰がどの時点まで変更できるかが曖昧なら、確定後の修正が画面外で進みます。

そこで、提出、作成、承認、共有を単に一画面へ集めるのではなく、スタッフ、店長、本部の操作範囲を分けました。確定前と確定後で編集権限を切り替える前提を置くことで、最新版と判断責任を結び付けられる構成にしました。

02CHALLENGE解くべき設計課題

三者の業務を分けて設計した理由

操作を分けるだけでは不十分です。締め日を過ぎた希望、確定後の欠勤、他店舗からの応援、権限変更が発生したときに、誰が修正し、誰へ通知するかまで運用ルールとして決める必要があります。

  • スタッフ

    自分の確定シフトを確認し、希望シフトと休暇を提出する。ほかの店舗や従業員のマスタは変更しない。

  • 店長

    担当店舗の希望を確認し、日付とスタッフのグリッドでシフトを作成する。申請を確認し、月次シフトを確定する。

  • 本部

    全店舗の状況を参照し、店舗・従業員マスタと役職別の権限を管理する。店舗内の通常調整まで本部へ集約しない。

03ARCHITECTURE共に築いた構成

AMELAが担当した範囲と設計判断

AMELAは、多店舗向けシフト管理基盤の新規構築に参画しました。公開用ケース資料で確認できる構成は、フロントエンドがNext.js、Ant Design、React Query、バックエンドがNestJSとTypeScriptです。

実装対象として確認できる主な機能は、希望シフト提出、休暇申請、スタッフと日付のグリッドによるシフト作成、申請の確認・承認、全店舗の状況表示、店舗・従業員マスタ、役職と店舗に応じた権限管理です。

希望シフトと休暇を提出するShiftMateの公開用スタッフ画面
スタッフ画面。氏名、所属、日付、勤務区分は公開用モックであり、実績データではありません。
全店舗の提出状況と権限を確認するShiftMateの公開用本部画面
本部画面。店舗名、人数、件数、提出率、締め日は説明用のモックであり、実績値ではありません。
  • 領域 01提出と確認
    課題

    スタッフが自分の希望と休暇を登録

    解決策

    店長が担当店舗の申請を確認

  • 領域 02作成と確定
    課題

    店長がグリッドで勤務区分を編集

    解決策

    担当店舗の月次シフトを確定

  • 領域 03本部共有
    課題

    店舗ごとの提出・確定状況を確認

    解決策

    店舗・従業員マスタを管理

  • 領域 04権限分離
    課題

    閲覧・編集・承認・マスタ管理

    解決策

    役職と店舗の範囲に分ける

04IMPACT生み出す価値

この事例の根拠と読み方

  • 根拠:移行元のAMELA開発ストーリー、公開用デモ、画面資料、CMSに保存された案件情報を照合しました。
  • 対象期間:2026年8月18日時点で確認できる公開用ケース資料を対象としています。
  • 確認できること:AMELAが新規構築に参画したこと、スタッフ・店長・本部の利用範囲、実装対象の機能、技術構成、役職と店舗で権限を分ける設計方針を確認できます。
  • 確認できないこと:開発期間、開発工数、店舗数、従業員数、提出率、作成時間の削減、申請漏れの削減、シフトの充足率、労務規程への適合性、可用性、SLAは公開資料だけでは確認できません。
  • 公開上の扱い:守秘義務に基づき、企業名、プロジェクト名、システム画面は仮名またはモックに置き換えています。画面内の氏名、店舗名、日付、人数、件数、割合は説明用であり、実績値として使用していません。
05ARCHITECTURE共に築いた構成

読者が使える実践ツール

画面設計の前に、シフトが確定するまでの責任と例外処理を一枚にまとめます。次は複数店舗を運営する小売企業を想定した一般的な記入例であり、ShiftMateの実際の運用設定ではありません。

  • 対象単位:店舗ごとに翌月一か月分を作成/本部は全店舗の確定状況を参照する
  • 希望提出:スタッフが希望勤務と休暇を締め日までに登録/締め日までは本人が修正できる
  • 一次作成:店長が担当店舗の希望と必要人数を照合して案を作成/不足や重複は店長が確認する
  • 確定権限:店長が担当店舗の月次シフトを確定/本部は店舗をまたぐ応援や例外だけを確認する
  • 確定後の変更:スタッフは店長へ変更を申請/店長が理由と変更前後を記録して再確定する
  • 欠勤・応援:欠勤は当日運用として別に記録/他店舗からの応援は両店舗の責任者が確認する
  • 閲覧範囲:スタッフは自分、店長は担当店舗、本部は全店舗/マスタ変更は指定された本部担当者に限定する
  • 受入確認:未提出、締め日超過、確定後変更、他店舗応援、権限変更の五つをテストする

自社向けに書き換えるときは、各行に『実行者』『締め日』『編集可能な期間』『承認者』『通知先』『残す履歴』を設定してください。シフト作成権限と、店舗・従業員マスタの変更権限は分けて検討する必要があります。

06IMPACT生み出す価値

公開用デモで確認できることと、適用時の注意点

公開用デモでは、店長によるグリッド編集と申請確認、スタッフによる希望・休暇申請、本部による全店舗の状況・マスタ・権限の確認を、三つの画面で試せます。これは、利用者ごとに操作範囲を分ける構成を示します。

一方で、デモ画面だけでは、就業規則、法定労働時間、休憩・休日、資格者の配置要件、給与・勤怠システムとの連携、本人確認、監査ログの保管期間は確認できません。導入時には、勤務ルールをシステムへ組み込む範囲と、人が最終判断する例外を分けて受入条件に含める必要があります。

07IMPACT生み出す価値

導入判断で先に決めること

多店舗のシフト管理では、全店共通の画面を用意する前に、店舗内で完結する判断、本部が確認する例外、確定後の変更履歴を決めることが重要です。この三点を定義できれば、システム化する範囲と運用に残す判断を切り分けられます。

業務ルールと権限の整理から検討する場合は、AMELAのDXコンサルティング支援もご覧ください。

08 / DEMO

公開用デモで、三者の操作範囲を確認する

実際に動くデモを見る