シフト交換と可用性のモバイルアプリを作る

問題定義と成功指標の設定

シフト交換アプリが機能するには、実際のスケジューリングの痛点を解決する必要があります：突然の欠勤で生じる穴、誰がカバーできるか分からないグループテキスト、公平性やルールを破る交換。まずは現在の勤怠・シフト管理で具体的にどこが遅れるか、どこでミスが起きるか、誰が不満を持っているかを書き出しましょう。

利用者とそのニーズ

従業員は、可用性の設定、休暇申請、マネージャーを追いかけずにシフトを交換できる仕組みを求めます。

シフトリードは、少ないやり取りで素早くカバーを得たい。

マネージャーは、ポリシーに従ったシフト交換承認と、残業の驚きを避けたいと考えます。

人事／給与担当は、タイムトラッキングや給与と一致するクリーンな記録を重視します。

これらのグループを早期に揃えないと、ある役割には「簡単」でも別の役割には負担となるモバイルスケジューリングアプリが出来上がります。

目標とする成果

コスト、時間、公平性につながる成果を定義します：

• シフトを埋めるためのテキスト／電話が減る（週次で測定）
• 空席シフトのカバーが速くなる（投稿→承認までの時間）
• 承認が速くなる（リクエスト→承認/却下の時間）
• カレンダーと可用性の整合性が高くなる（可用性／休暇ルールに適合する交換の割合）

開発前に成功基準を決める

スタッフ向けMVPのために少数の成功指標を選び、今の値をベースライン化します。例：オープンシフト充足率を20%改善、承認時間を6時間→1時間に短縮、未カバーシフトを30%削減など。

これらの目標はプロダクト判断を導き、プッシュ通知などの優先順位付けに貢献します。ローンチが有効かどうかを示す指標にもなります。

サポートすべきユースケースとルールの選定

画面設計や機能構築の前に、アプリの対象と「有効な交換」の定義を決めます。表面的にはシンプルでも、業界によりルールは大きく異なります。

主要ユーザーを選ぶ（早期に混ぜない）

まずは一つの明確な対象から始めます：

• 時間給の小売：パート多数、直前変更が頻繁、スキルはシンプル
• 飲食：役割別の人員（サーバー／バーテンダー／調理）、チップの影響、迅速な承認が必要
• 医療：厳格な資格、年功序列ルール、残業制約
• 物流：カバレッジ要件、安全ルール、法定の休息期間

この選択は、収集するデータ、必要な承認、ワークフローの柔軟性に影響します。

シフトの作成方法を定義する

勤務スケジュールモデルは通常いずれか：

• 固定テンプレート（繰り返しパターン）：交換検証が簡単で予測しやすい
• 週次／日次スケジュール（マネージャー作成）：変動が多くエッジケースが増える

また、交換に関わる属性（勤務地、役割、給与コード、開始/終了時刻）も定義します。

交換承認スタイルを決める

誰が最終決定権を持つか明示します：

• ピア・トゥ・ピア：従業員同士で直接交換。リスクの低い業務に向く。
• マネージャー承認（シフト交換承認）：コンプライアンス重視のチームで一般的。
• 自動承認：システムでルールを信頼して検証できる場合のみ。

サポートすべき制約を列挙する

ローンチ後ではなく今ルールを書き出します：

• 労働組合や契約のルール（年功、入札システム、割増賃金）
• 資格／スキル（RN vs CNA、フォークリフト免許など）
• シフト間の最低休息時間
• 残業・最大勤務時間の制限

強いモバイルスケジューリングは、無効な交換を事後処理で直すのではなく、そもそも発生させないことで信頼を得ます。

ユーザー役割と権限

役割は誰が何をできるかを定義します。明確な権限は、意図しないスケジュール変更を防ぎ、承認のボトルネックを減らし、後で監査を容易にします。

サポートすべきコア役割

従業員

従業員には自己完結できるツールにガードレールを付けます：可用性（および休暇）の設定、交換リクエスト、オファーの承認/拒否、スケジュール閲覧。自分のロケーション/チームに関連する情報のみ表示し、公開済みシフトを直接編集できないようにします。

マネージャー

マネージャーは交換の承認/却下、競合（残業、スキル要件、人手不足）の解決、シフトの作成・編集、カバレッジの監視を行います。多くの業種で、マネージャーは「週当たり時間を超える」などのルール警告を確認し、誰がリクエストや承認を行ったかの履歴を必要とします。

管理者（Admin）

管理者はシステム設定を管理します：ロケーション、部門、役割/スキル、給与ルール、交換適格ルール、権限の設定。マネージャーをチームに割り当て、従業員が見られるものを制御し、セキュリティポリシーを強制できます。

摩擦を減らすオプション役割

シフトリードは限定的な範囲で承認できる（例：同一役割・同一日の承認）権限を持ち、フルマネージャー権限は不要。

スケジューラーは複数チームのスケジュール作成が可能だが給与設定にはアクセスしない。

人事／給与閲覧者はスケジュールと変更履歴を閲覧できるが、シフト編集は不可。

権限設計のコツ

ロールベースのアクセス制御にスコープ（ロケーション／チーム）を組み合わせます。「表示」と「編集」を分離し、残業や勤務地跨りなど影響の大きい操作は承認を必須にします。

可用性：必要なデータと収集方法

可用性は従業員可用性アプリの基盤です。曖昧・古い・更新が面倒だと、シフト交換は推測作業になります。目標は「働けること（ハード制約）」と「働きたいこと（ソフトな希望）」を捉え、手間を最小化して最新状態を保つことです。

サポートすべき可用性の種類

多くのチームでは三層が必要です：

• 週次の繰り返し可用性（例：「月〜金 9:00–15:00」）
• 一回限りの例外（例：「次の火曜は13時以降勤務不可」）
• 休暇リクエスト（終日または部分、承認ステータス付きが望ましい）

実用的なモデルは、週パターンをデフォルトとし、例外で上書き、休暇を「不可用」ブロックとして扱うことです（承認が必要な場合あり）。

希望（Preferences）とハード制約の区別

UIとデータ両方で明確に区別します：

• Unavailable（ハード制約）：従業員は勤務不可
• Available（ニュートラル）：勤務可能
• Preferred（希望）：この時間帯を希望するが必須ではない

この区別は後のスケジューリングや承認ロジックで、何を必ずブロックし何を推奨するかを決める際に重要です。

悪い交換を防ぐ検証ルール

MVP段階でもガードレールを追加し、可用性がポリシーと矛盾しないようにします：

• 通知期間：変更はX時間／X日前までに行う必要がある
• ブラックアウト日：可用性変更ができない日（祝日、繁忙期）
• 週当たり最大時間：結果として上限を超える場合は警告またはブロック

可用性保存時と交換適用時の両方で検証を行います。

UXのコツ：30秒以内で更新できること

週表示グリッドとクイックアクションを持つ単一の「可用性」画面を設計します：

• 日をタップ→Unavailable/Available/Preferredを選択
• 「全ての平日にコピー」「毎週繰り返す」トグル
• カレンダーからワンタップで例外を追加

ユーザーが素早く更新できなければ使われなくなるので、v1では詳細設定より速度を優先します。

シフト交換ワークフロー

シフト交換アプリはワークフローの細部で成功が決まります。従業員にとって簡単に感じられ、マネージャーがスケジュールを信頼できる厳密さを保つことが重要です。

コアな交換フロー

多くのチームが必要とする予測可能な流れ：

1. リクエスト：従業員がシフトを選び「交換」または「シフトを放棄」をタップ
2. オファー／承諾：交換は適格な同僚にオファーされる、または特定の同僚を招待
3. 承認（必要な場合）：マネージャーや監督がレビュー
4. スケジュール更新：承認後、割当が変更され即時に全員に反映

やり取りを減らすため、「アレックスの応答待ち」→「マネージャー承認待ち」→「交換完了」のように、リクエスターに次に何が起きるかを見せます。

完全交換、部分交換、分割

すべてが1対1交換とは限りません：

• 完全交換：AとBがシフト全体を交換
• ドロップ＋ピックアップ：Aがシフトを放棄し、Bがそれを引き受ける（時間給の仕事で一般的）
• 部分交換／分割シフト：Aがシフトの一部を残し残りを譲渡

分割をサポートするなら、最小セグメント長と明確な引継ぎ時間を強制してカバレッジが途切れないようにします。

誰かが承認する前の競合チェック

「承認されたが不可能」な交換を避けるために、早い段階で自動チェックを実行します：

• 重複シフト（移動時間／バッファを含む）
• 役割不一致（従業員に必要な資格がない）
• ロケーション不一致（その店舗／部門に割り当てられていない）

失敗した場合は平易な言葉で理由を説明し、修正案を示します（例：「このシフトはバースキル保持者のみ受けられます」）。

監査ログと責任追跡

すべての交換は監査ログを作成すべきです：誰が開始したか、誰が承諾したか、誰が承認/却下したか、タイムスタンプ、メモ。この履歴は給与、出勤、ポリシー適用で後から問われたときに双方を守ります。

モバイルUX：画面とユーザーフロー

シフト交換アプリは明快さが生死を分けます。人々は作業の合間に片手で開き、「何を働くか」「自分のリクエストはどうなっているか」を数秒で理解したいと考えます。

異なる問いに答えるスケジュールビュー

一つの過剰なカレンダーより、用途別の絞ったビューを提供します：

• パーソナルアジェンダ：近々のシフトをリスト表示（今日／今週）、開始／終了、ロケーション、役割を表示
• チームグリッド：役割や部門ごとのカバレッジを素早く確認（リードやマネージャー向け）
• ロケーションカレンダー：特定店舗のカレンダー表示で穴や繁忙期を発見

フィルタは固定（ロケーション、役割、日付範囲）にして、毎回設定をやり直す手間を減らします。

摩擦を低く保つ主要画面

主要アクション中心に設計し、スケジュールへ戻るパスを一貫させます：

• シフト詳細：誰が、どこで、いつ、役割、メモ、ポリシーヒント（例：「この交換はマネージャー承認が必要」）
• 交換リクエスト：対象シフトまたは適格な同僚を選び、メッセージ追加、送信前にルールチェックを表示
• 可用性エディタ：勤務可/不可トグル、繰り返しパターン、特定日の例外追加が高速に行えること
• 受信箱（Inbox）：承認、質問、更新の単一の場所。ユーザーがタブを探し回らないように

誤解を防ぐステータス表現

小さく一貫したステータスセットをプレーンな言葉とタイムスタンプで表示：

• Pending（保留）
• Accepted（承諾）
• Approved（承認）
• Denied（却下）

リクエストが表示される場所（シフトカード、詳細、受信箱）すべてに現在のステータスを出します。

アクセシビリティの基本

読みやすいフォント、強いカラ―コントラスト、大きなタップ目標を採用。色だけで状態を伝えずラベルやアイコンを併用。エラーメッセージと、スケジュールを変更する重要な操作には確認画面を設けます。

通知とメッセージング

通知は、交換リクエストが数分で処理されるか放置されるかを分ける要素です。メッセージングはワークフローの一部として扱います。

通知が必要な重要な瞬間

勤務日に直接影響するイベントに集中します：

• 新しいシフトが投稿／割当された（特に直前のカバー）
• 交換リクエストが届いた（対象者へ）
• 承認結果（マネージャーまたは自動ルールによる承認/却下）
• リマインダー（期限切れ間近、シフト開始X時間前、未応答）

各通知は「何が起きたか？何をすべきか？いつまで？」に答え、該当画面へのディープリンクを含めます（例：「交換リクエストを確認」）。

ユーザーがチャネルを選べるが制御を失わない設計

デフォルトでプッシュを提供し、メールと（対応するなら）SMSをオプションで選べるようにします。人によって好みは違います：現場の看護師はプッシュを頼りにする一方、パートタイムはメールを好むことがあります。

設定はシンプルに：

• イベント毎のトグル（交換リクエスト、承認、リマインダー）
• サイレント時間帯（例：22:00–7:00は通知しない）
• エスカレーション（30分反応がなければSMSも送る等）

スパム化と通知疲れを避ける

可能な場合はまとめて送る：「今週末のオープンシフト3件」など。リマインダーは必要最低限にし、ユーザーがアクションを取ったら直ちに停止します。

オフライン時やプッシュ無効時のフォールバック

プッシュが失敗する前提で設計します。未読件数を示すアプリ内受信箱を明確にし、緊急な項目はホーム画面で目立たせます。ユーザーがプッシュを無効にした場合は、一度だけメール/SMS選択を促して、時間敏感なリクエストが滞らないようにします。

バックエンドとデータモデルの基本

モバイル上は単純に見えても、バックエンドは「誰がどこでいつ働けるか」を厳密に扱う必要があります。クリーンなデータモデルが多くのスケジューリングバグを事前に防ぎます。

保存すべきコアエンティティ

最低限これらの要素を想定します：

• Users：従業員とマネージャー（プロフィール、連絡先、ステータス）
• Locations：店舗、クリニック、サイト（タイムゾーンが重要）
• Roles：キャッシャー、看護師、ラインクック（スキル／資格）
• Shifts：日時、ロケーション、必要ロール、割当ユーザー
• Availability：勤務可／不可ウィンドウ、休暇ブロック
• Swap requests：提案された交換の記録、決定情報含む

関係性（要素の接続）

実用的な出発点：

• 1人のユーザーは多くのシフトを持つ（過去・未来の割当）
• 各シフトは1つのロケーションに属し、1つのロールを要求する
• SwapRequestは（リクエスター + 対象）という2人のユーザーと、スワップタイプによって1つまたは2つのシフトを紐づける

例（簡略）：

Shift(id, location_id, role_id, starts_at, ends_at, assigned_user_id)
SwapRequest(id, offered_shift_id, requested_shift_id?, from_user_id, to_user_id, status)

※ 上記コードブロックは変更しないでください。

交換リクエストの状態（アプリの「真実」）

スワップは小さなステートマシンとして扱います：

• pending → accepted または declined
• accepted → approved（マネージャー承認が必要な場合）
• いつでも canceled（リクエスターによるキャンセル）、expired（期限切れ）

ダブルブッキングの防止

ダブルブッキングは同時に二つの操作が行われると発生します（2件のスワップ、またはスワップ＋マネージャー編集）。承認時に両方のシフト割当を1つのトランザクションで更新し、どちらかが変わっていたら拒否することで解決します。

高トラフィック環境では軽量ロッキング（例：シフトにバージョン番号）を追加し、競合を確実に検出します。

API、同期、パフォーマンス

スケジュールが最新に感じられるかどうかがアプリの成否を分けます。明確なAPI、予測可能な同期、いくつかのパフォーマンス指針が必要です。MVP段階で過剰設計は避けます。

計画すべき主要APIエンドポイント

最初のバージョンは小さくタスク指向に：

• Schedule：チームスケジュール取得（ロケーション／チーム／日付範囲）、シフト詳細取得
• Availability：可用性ブロックの設定／更新、ユーザーの可用性一覧取得
• Swap actions：スワップリクエスト作成、承諾／拒否、キャンセル、ステータス確認
• Approvals：マネージャーの保留承認一覧、承認／却下（理由付き）

レスポンスはモバイル側が素早く描画できるよう、表示に必要な最小限の従業員情報を含めます。

リアルタイム更新：シンプルなMVP同期

MVPではスマートなポーリングを基本にします（アプリ起動時、プル・トゥ・リフレッシュ、スケジュール画面表示中は数分ごと等）。サーバ側の updated_at タイムスタンプを活用し、増分フェッチを行います。

ソケットやWebhookは秒単位の更新が本当に必要でない限り後回しに。将来ソケットを導入するなら、まずはスワップステータス変更だけを対象に始めるとよいです。

タイムゾーンとサマータイム

シフト開始／終了は標準的な形式（UTC）で保存し、勤務ロケーションのタイムゾーンも保持します。表示は常にそのロケーションのタイムゾーンで計算します。

DST移行時は“浮動”する時刻を避け、正確なタイムスタンプを保存して同じゾーンルールで重複チェックを行います。

ストレージの選択

ルール重視のクエリ（可用性の競合、適格性、承認条件）にはリレーショナルDBが適しています。カレンダービューを高速化するためにチーム単位のキャッシュ（日付範囲）を置き、シフト編集や交換承認時にキャッシュを失効させます。

セキュリティ、プライバシー、コンプライアンス

シフト交換と可用性は名前、連絡先、勤務パターン、時には休暇理由などの機微情報に触れます。セキュリティとプライバシーは単なる技術作業ではなくプロダクト機能と考えます。

認証とセッション安全性

顧客の状況に応じたサインイン方式を選びます：

• メール／パスワード：シンプルな導入
• SSO（Google/Microsoft/Okta）：大規模組織向け
• 招待コード／マジックリンク：パスワード管理を減らす

いずれを選ぶにしてもセッション管理は慎重に：短寿命のアクセストークン、リフレッシュトークン、疑わしい挙動（離れた場所からのトークン使用など）で自動ログアウトする仕組みを入れます。

すべてのリクエストでの認可

UIが操作を隠すだけに頼らず、すべてのAPIコールで権限を検証します。典型的なルール：

• 従業員は自分の可用性編集と交換リクエストを行える
• マネージャーはチームの保留承認一覧を見て承認／却下できる
• 管理者はロケーション／ポリシー／エクスポートを管理できる

これでユーザーが承認APIを直接叩いて不正に承認することを防ぎます。

最小限の個人データの収集と保護

スケジュールに必要な最小データだけを収集。データは転送中（TLS）と保存時に暗号化。電話番号などの敏感情報は分離・アクセス制御を強化します。

可用性や休暇のメモは任意にし、ユーザーが過剰に共有しないよう明示します。

監査ログとエクスポート制御

主要イベント（交換リクエスト、承認、スケジュール編集、ロール変更、エクスポート）について監査ログを保持します。

エクスポート機能には制限をかけ、誰がエクスポートできるかを制御し、CSV/PDFに透かしを入れる、エクスポートを監査ログに記録するなどの対策を講じます。内部ポリシーやコンプライアンスレビューに不可欠です。

統合：給与、勤怠、カレンダー

統合は運用チームにとってアプリを“本物”にします—交換は給与や勤務時間が正しく反映されて初めて意味を持ちます。最初は必要なデータだけに絞り、後から他システムを追加しやすく設計します。

給与・勤怠に同期する項目

多くの給与システムは「実際に働いた時間」と「シフト開始時に割り当てられていた人」を重視します。最低限エクスポート／同期すべき項目：

• 従業員識別子（内部ID＋外部給与／勤怠ID）
• ロケーション／部署／ジョブコード（レートやルール適用のため）
• シフト開始／終了時刻と休憩ルール
• 最終割当者と監査参照（swap ID、承認タイムスタンプ）

プレミアム（残業トリガー、差額、ボーナス）をサポートする場合、計算を給与側に任せる（推奨）か、アプリ側で行うかを早期に決めます。迷う場合はクリーンな勤務時間を送り、給与側で支払ルールを適用してもらうのが安全です。

カレンダー同期（プライバシー配慮）

読み取り専用の個人カレンダーアクセスは、交換の際に衝突を警告する用途で有益です。

プライバシーに配慮して「忙しい／空き」のブロックのみを扱い（タイトルや参加者は保存しない）、衝突表示はローカルで行い、ユーザーごとにオプトインにします。

Webhook、エクスポート、後付け拡張設計

一部の顧客はリアルタイム更新を望み、他は夜間のファイルで良い場合もあります。統合レイヤーは次をサポートするように作ります：

• Webhooks（例：shift.updated、swap.approved）
• スケジュールされたエクスポート（CSV/SFTP）

後で書き換えを避けるため、統合は安定した内部イベントモデルとマッピングテーブル（内部ID ↔ 外部ID）の背後に隠します。新しいプロバイダの追加は設定と翻訳だけで済むようにします。

MVPの範囲とプロダクトロードマップ

シフト交換・可用性アプリのMVPは一つのことを証明するべきです：チームがカバレッジルールを壊さずに変更を確実に調整できること。最初のリリースは狭く、測定可能で、パイロットが容易であるべきです。

MVP：価値を提供する最小機能セット

日常ループを支える機能群から始めます：

• スケジュール閲覧（週／日、役割、ロケーション別）
• 可用性設定（希望時間、ハードな不可用ブロック）
• 交換リクエスト（シフト選択、同僚指定、メモ追加）
• 承認／却下フロー（マネージャー承認やピア承認をルールに応じて）
• 通知（新規リクエスト、承認、直前の変更）

MVPには基本的なガードレールも含めます：役割要件、最低休息時間、残業閾値を違反させる交換は防ぐ（最初はルールを単純にしておく）。

素早く進めたい場合、Koder.aiのようなvibe-codingプラットフォームはワークフローのプロトタイプ（モバイルUI＋バックエンド＋DB）をチャット仕様から作るのに役立ちます。チームは交換のステートマシン、権限、通知トリガーを早期に検証し、その後ソースコードをエクスポートして深いカスタマイズに進むことが多いです。

後で追加したい機能（MVP安定後）

コアワークフローが信頼されれば、充足率を上げてマネージャー負担を減らす機能を追加します：

• 可用性と資格に基づく自動候補提案
• オープンシフト掲示板（スタッフが未割当シフトを直接取得）
• シフト入札（需要の高いシフトに対する競争だが、明確なルールが必要）

リスクを下げるロードマップ

まずは1ロケーションまたは1チームでパイロット。ルールを一貫させ、エッジケースを減らし、サポートを管理しやすくします。

成功指標（時間での充足、未カバーシフト減少、メッセージ量減少）を追跡し、スケール前に調整します。

必要に応じて「準備完了」のチェックリスト（権限、ルール、通知、監査ログ等）を用意します。参考が必要なら /blog/scheduling-mvp-checklist を参照してください。

テスト、パイロット、ローンチ

シフト交換アプリのテストは「ボタンが動くか」だけではなく、実運用でスケジュールが正しく保たれるかを証明することが目的です。信頼を壊すワークフローに注力してテストします。

影響が大きいテストシナリオ

現実的なデータ（複数ロケーション、役割、ルール）でエンドツーエンドのテストを行い、最終スケジュールが毎回正しいことを確認します：

• 重複シフト：ほぼ同時発生の交換でも同一従業員のダブルブッキングが起きない
• 期限切れリクエスト：交換リクエストが明確なカットオフで自動期限切れになる（例：シフト開始2時間前）
• マネージャーのオーバーライド：カットオフ後の承認／強制割当があっても監査履歴が正しく残る
• タイムゾーン端点：サマータイム、出張中の従業員、別タイムゾーンの承認などで表示と保存が一貫する

正直なフィードバックを得るためのパイロット計画

先に述べたように小さなグループ（1チーム／1ロケーション）で1〜2週間のパイロットを行い、短いフィードバックループを保ちます：毎日のチェックインと週1回15分のレビュー。専用サポートチャネル（専用メールエイリアスや /support ページ）を用意し、応答時間を約束してユーザーがテキストや別会話に戻らないようにします。

採用と成果の測定

価値を反映する指標を追います：

• アクティブユーザー（週次）：従業員とマネージャーの実利用数
• 交換完了時間：リクエストから最終決定までの中央値
• スケジュール変更率：掲出後の変更頻度（混乱か柔軟性かを判断）

ローンチチェックリスト

全員に公開する前に：

• オンボーディング：60秒のウォークスルーと初回プロンプト
• ヘルプドキュメント：「交換方法」「承認の仕組み」等の簡潔なページ
• アプリ内ヒント：締切や必要承認のリマインダー
• ロールバック計画：問題時に交換リクエストを一時的に無効化し、最終の良好なスケジュールに戻せる機能