CLEANSHIFT / FULL SPECIFICATION

統合仕様書 Draft

原本の要件、現在の実装との差分、未決事項を収録しています。回答ページへ戻る

Feature Specification: 民泊清掃管理アプリ CleanShift 統合仕様

Feature Directory: specs/001-cleanshift-rebaseline

Lane: L2

Status: Draft

Promoted From: 既存assistbnbの随時改修を停止し、仕様を確認してから再実装する作業

Created: 2026-09-28

Input: 依頼要約: 現行assistbnbの既存実装を活かし、添付要件とTomoya要件を統合した仕様を作成する。改修を止めて仕様を確認してから再実装する。

目的と読み方

現行assistbnbの既存機能とデータを保ち、民泊の予約から清掃予定、担当調整、打刻、完了報告までの意図を一つの確認可能な仕様に集約する。要件の追跡、権限・状態の確認、未決事項への回答に使う。

この文書はL2のDraftで、仕様承認も実装も未着手。MUSTは添付表の優先度原文であり、承認済みを意味しない。関連D論点の具体値はv0.9提案として扱い、人が決めるまで受入条件として確定しない。今回Stageはspecify/clarify準備。plan/tasks/実装/承認は行わない。

この版で確認する5点

  1. 新規予約の回答受付・確定方法（D-01）と、管理者が回答前に担当を確定する経路。
  2. 物件担当外スタッフへの直接割当時のアクセス範囲（PRP-03 / ADM-07）。
  3. 予約取消・日程変更・連続予約と、作業中/完了後の状態・記録保全。
  4. 通知チャネル、送信失敗時の扱い、24時間の起点（D-03、D-08、D-13）。
  5. 月次シフト、チェックリスト、在庫、報酬、オーナー編集など既存機能の継続範囲。

読む順

  1. User Scenarios、状態モデル、権限と未決事項を確認する。
  2. FRと追跡表で添付47要件の変換漏れを確認する。
  3. 既存実装差分、feedback、T-01〜40、追加受入提案を確認する。
  4. Clarificationsに回答し、決まった内容だけを人がApprovedへ進める。

資料の優先関係

ユーザーの今回の依頼と確定した直接決定を優先する。会話は日時付き要約だけ使い、後発資料が「未決」を示す値を会話の方向支持だけでResolvedにしない。添付xlsxはv0.9提案と優先度の出典。現行コードは「いまあるもの」の静的証拠で意図や本番稼働の証拠ではない。公開AssistBnBマニュアルは参考元サービスの説明で、クローンの要求・現状と混同しない。追加ATは推論提案。

利用者と用語

EARSの読み方: 各FRはWHEN（イベント）、WHILE（状態中）、IF/THEN（条件）、またはTHE SYSTEM SHALL（常時）で始まる1行要件。各行はSHALLを1つだけ持つ。

User Scenarios & Testing *(mandatory)*

User Story 1 - 予約から担当決定まで (Priority: P1)

管理者は物件ごとに予約元とスタッフを設定し、新規予約から生じた清掃タスクと回答状況を確認する。物件担当スタッフは通知から予定を開いて可否を回答し、管理者は必要に応じて担当を確定する。自動確定と手動確定の優先関係はD-01回答待ち。

なぜこの優先度か: 清掃日と担当を確定できないと、後続の打刻・完了報告が始まらない。

独立したテスト方法: 予約を1件取り込み、重複タスクがなく、対象スタッフの回答と管理者割当の状態が追えることを確認する。通知の実配信はチャネル決定後に確認する。

受入シナリオ:

  1. Given 有効な物件に予約元が設定されている、When 新規予約を取得する、Then 同予約の清掃タスクが1件だけ作成される。
  2. Given タスクと複数の物件担当スタッフが存在する、When スタッフが回答する、Then 回答者・値・時刻が管理者に表示され、確定時は選ばれた担当が示される。

User Story 2 - 清掃の打刻と報告 (Priority: P2)

確定担当スタッフは許可された時間に作業開始・完了を記録し、写真とコメントを登録する。管理者は勤怠記録を確認・訂正できる。打刻日、報告の境界値、チェックリストとの関係は承認待ち。

なぜこの優先度か: 担当決定後の作業証跡と勤務時間が運用の基礎になる。

独立したテスト方法: 確定タスクの開始・完了・写真/コメント・勤怠の再読込結果を確認する。

受入シナリオ:

  1. Given 本人が確定担当でタスクが作業可能、When 開始・完了を操作する、Then 開始/完了時刻と完了報告が保存される。
  2. Given オーナーが自分の物件を閲覧する、When 完了報告を開く、Then 写真・コメント・時刻が見え、他物件・ゲスト情報・担当者名は見えない。

User Story 3 - 月次勤務確認と既存運用継続 (Priority: P3)

管理者はスタッフ別・月別の清掃件数と勤務時間を確認してCSVを出力する。既存の月次シフト公開、募集、チェックリスト、在庫、支払、経費、オーナー管理等は、個別に廃止を決めるまで利用可能な状態に保つ。

なぜこの優先度か: 手作業集計と既存機能の喪失を防ぎ、現行利用者が継続できるようにする。

独立したテスト方法: 保存済み勤怠と一覧/CSVを照合し、機能保全表の確認を行う。

受入シナリオ:

  1. Given スタッフに当月の勤怠が保存されている、When 管理者が一覧とCSVを開く、Then 件数・合計時間が同じ値で再読込後も保持される。
  2. Given 実装済み既存機能がある、When 新仕様を導入する、Then 明示承認なしに機能・データ・権限が削除されない。

Edge Cases *(L2 のみ)*

Requirements *(mandatory)*

Functional Requirements

通知契約の共通注記

NTFの分類はLINE通知で、スタッフ/管理者へのLINEはv0.9提案としてFR-019/022〜027に記載する。owner完了通知だけはD-08でLINE/メールが未決。現行コードの通知行保存はLINE配信ではなく、コード上LINE/Chatwork配信経路を確認していないため要件充足とは扱わない。配信失敗、部分成功、再送、二重防止はQ-05/Q-09/Q-22で決める。task状態「完了」と外部通知の配信結果をどう関係付けるかは別の未決Q-28にし、delivery statusを追加する場合も提案として扱う。

要件追跡・受入条件

元ID、FR、原文、全フィールドの出典セル、元優先度、背景、actor、前提/例外、受入条件、決定者を1行で追う。全行の元優先度はMUST（添付原文）。D論点の具体値は承認待ち。D欄なしでも本書自体はDraftで、受入レビュー前。

元ID FR 要件原文 出典セル A:F 元優先度 背景 actor 前提 例外/未決 受入テスト 決定者
PRP-01 FR-001 管理者は物件を登録・編集・無効化できる。 機能要件!A2, 機能要件!B2, 機能要件!C2, 機能要件!D2, 機能要件!E2, 機能要件!F2 MUST 物件とアクセス対象を管理する。 管理者 管理者として認証される。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-01 Tomoya / 陸
PRP-02 FR-002 物件ごとに清掃マニュアルURLを登録でき、スタッフはタスク画面からワンタップで開ける。 機能要件!A3, 機能要件!B3, 機能要件!C3, 機能要件!D3, 機能要件!E3, 機能要件!F3 MUST 物件とアクセス対象を管理する。 管理者 管理者として認証される。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-02 Tomoya / 陸
PRP-03 FR-003 物件ごとに担当スタッフを複数登録できる。通知・回答・タスク表示の対象は担当スタッフだけ。 機能要件!A4, 機能要件!B4, 機能要件!C4, 機能要件!D4, 機能要件!E4, 機能要件!F4 MUST 物件とアクセス対象を管理する。 管理者 管理者として認証される。 物件への複数スタッフ登録とtaskの単一確定担当を区別。0人でもtask作成。担当外直接割当の権限はQ-01未決。 T-03, T-40 Tomoya / 陸
PRP-04 FR-004 オーナーは複数の物件を持てる。1物件のオーナーは1人。 機能要件!A5, 機能要件!B5, 機能要件!C5, 機能要件!D5, 機能要件!E5, 機能要件!F5 MUST 物件とアクセス対象を管理する。 管理者 管理者として認証される。 1 property:1 owner、1 owner:複数property。既存owner teamとの互換未決。 AT-01 Tomoya / 陸
SYN-01 FR-005 物件ごとに iCal か Beds24 API のどちらかで予約を取得する。 機能要件!A6, 機能要件!B6, 機能要件!C6, 機能要件!D6, 機能要件!E6, 機能要件!F6 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 AT-02 Tomoya / 陸
SYN-02 FR-006 30分ごとに自動取得する。管理者は「今すぐ取得」も押せる。 機能要件!A7, 機能要件!B7, 機能要件!C7, 機能要件!D7, 機能要件!E7, 機能要件!F7 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 D-12 未決。30分/D-12値は承認待ち。 AT-03 Tomoya / 陸
SYN-03 FR-007 新しい予約を見つけたら、チェックアウト日を清掃日とする清掃タスクを1件作る。同じ予約から2件以上作らない。 機能要件!A8, 機能要件!B8, 機能要件!C8, 機能要件!D8, 機能要件!E8, 機能要件!F8 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 iCal UIDまたはBeds24予約ID。 T-04, T-05, T-06 Tomoya / 陸
SYN-04 FR-008 予約のキャンセルを検知したらタスクを「取消」にする。確定済みなら担当スタッフと管理者に通知する。 機能要件!A9, 機能要件!B9, 機能要件!C9, 機能要件!D9, 機能要件!E9, 機能要件!F9 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 D-06 未決。event消失を取消扱いするD-06は未決。取得失敗との識別も未決。 T-07, T-08 Tomoya / 陸
SYN-05 FR-009 予約の日程変更を検知したら清掃日を更新する。確定済みなら担当はそのままにして、担当スタッフと管理者に通知する。 機能要件!A10, 機能要件!B10, 機能要件!C10, 機能要件!D10, 機能要件!E10, 機能要件!F10 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 D-05 未決。担当保持/通知はD-05未決。取消・完了後の変更も未決。 T-09 Tomoya / 陸
SYN-06 FR-010 予約ではないブロック（オーナー利用・メンテナンス等）からはタスクを作らない。 機能要件!A11, 機能要件!B11, 機能要件!C11, 機能要件!D11, 機能要件!E11, 機能要件!F11 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 D-07 未決。非予約ブロック除外はD-07未決。 T-10 Tomoya / 陸
SYN-07 FR-011 同じ物件の取得が3回続けて失敗したら、管理者画面に警告を出す。 機能要件!A12, 機能要件!B12, 機能要件!C12, 機能要件!D12, 機能要件!E12, 機能要件!F12 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 連続失敗3回。復旧通知と検知間隔は未決。 T-11 Tomoya / 陸
SYN-08 FR-012 各予約を最初に検知した日時を記録する（「新規」表示の判定に使う）。 機能要件!A13, 機能要件!B13, 機能要件!C13, 機能要件!D13, 機能要件!E13, 機能要件!F13 MUST 予約イベントを重複なく清掃タスクへ反映する。 システム、管理者 有効物件に取得元が設定されている。 D-02 未決。v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-12 Tomoya / 陸
ADM-01 FR-013 全物件の清掃タスクを清掃日順に一覧表示する。物件・期間・ステータスで絞り込める。カレンダー表示と一覧表示を切り替えられる。 機能要件!A14, 機能要件!B14, 機能要件!C14, 機能要件!D14, 機能要件!E14, 機能要件!F14 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 AT-04 Tomoya / 陸
ADM-02 FR-014 各タスクに 清掃日、物件、チェックアウト時刻、次のチェックイン日時、連続予約の有無、ステータス、担当、回答数 を表示する。 機能要件!A15, 機能要件!B15, 機能要件!C15, 機能要件!D15, 機能要件!E15, 機能要件!F15 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 AT-05 Tomoya / 陸
ADM-03 FR-015 検知から7日以内のタスクは濃い青の背景で表示する。 機能要件!A16, 機能要件!B16, 機能要件!C16, 機能要件!D16, 機能要件!E16, 機能要件!F16 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 D-02 未決。v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-12, T-13, T-17 Tomoya / 陸
ADM-04 FR-016 担当が決まっていないタスク（確認中・要調整）は赤枠で表示する。 機能要件!A17, 機能要件!B17, 機能要件!C17, 機能要件!D17, 機能要件!E17, 機能要件!F17 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-14, T-17 Tomoya / 陸
ADM-05 FR-017 通知から24時間たっても未割当のタスクは、太い赤枠＋赤背景＋「24h超」ラベルで表示し、一覧の最上部に出す。 機能要件!A18, 機能要件!B18, 機能要件!C18, 機能要件!D18, 機能要件!E18, 機能要件!F18 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 D-03 未決。24h起点はD-03未決。 T-15, T-16 Tomoya / 陸
ADM-06 FR-018 タスク詳細で、担当スタッフ全員の回答（◯／×／保留／翌日なら可／未回答）と回答日時を見られる。 機能要件!A19, 機能要件!B19, 機能要件!C19, 機能要件!D19, 機能要件!E19, 機能要件!F19 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-21 Tomoya / 陸
ADM-07 FR-019 管理者は取消・完了以外のタスクに、スタッフの回答に関係なく担当を割り当てて確定できる。割り当てたスタッフにLINEで通知する。 機能要件!A20, 機能要件!B20, 機能要件!C20, 機能要件!D20, 機能要件!E20, 機能要件!F20 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 取消/完了除外。property外スタッフ割当のアクセス範囲はQ-01未決。 T-25 Tomoya / 陸
ADM-08 FR-020 確定後も担当を変更できる。前の担当と新しい担当の両方に通知する。 機能要件!A21, 機能要件!B21, 機能要件!C21, 機能要件!D21, 機能要件!E21, 機能要件!F21 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-26 Tomoya / 陸
ADM-09 FR-021 管理者は打刻時刻を修正できる。修正前の値と修正者を履歴に残す。 機能要件!A22, 機能要件!B22, 機能要件!C22, 機能要件!D22, 機能要件!E22, 機能要件!F22 MUST 管理者が期限・回答・進捗から担当と調整を判断する。 管理者 管理者として認証されタスクが存在する。 旧時刻と訂正者の監査が必要。コードの直接訂正経路は履歴なし。 T-39 Tomoya / 陸
NTF-01 FR-022 タスク作成時、その物件の担当スタッフ全員に通知する（物件名・清掃日・作業可能時間・回答画面へのリンク）。 機能要件!A23, 機能要件!B23, 機能要件!C23, 機能要件!D23, 機能要件!E23, 機能要件!F23 MUST 業務イベントを担当者へ伝える。 システム、通知対象者 通知イベントが成立する。配信先/経路の稼働は未確認。 LINEはv0.9提案。コードのDB通知行はLINE配信ではない。 T-03 Tomoya / 陸
NTF-02 FR-023 確定時、確定したスタッフに通知する。回答していた他の担当スタッフには「締め切り」を通知する。 機能要件!A24, 機能要件!B24, 機能要件!C24, 機能要件!D24, 機能要件!E24, 機能要件!F24 MUST 業務イベントを担当者へ伝える。 システム、通知対象者 通知イベントが成立する。配信先/経路の稼働は未確認。 確定通知と他回答者への締切通知。チャネル/部分失敗は未決。 T-18 Tomoya / 陸
NTF-03 FR-024 通知から24時間たっても未割当のタスクがあれば、管理者に通知する。 機能要件!A25, 機能要件!B25, 機能要件!C25, 機能要件!D25, 機能要件!E25, 機能要件!F25 MUST 業務イベントを担当者へ伝える。 システム、通知対象者 通知イベントが成立する。配信先/経路の稼働は未確認。 24h起点はD-03未決。 T-15 Tomoya / 陸
NTF-04 FR-025 要調整が発生したら管理者に通知し、該当スタッフに「日程調整中」と通知する。 機能要件!A26, 機能要件!B26, 機能要件!C26, 機能要件!D26, 機能要件!E26, 機能要件!F26 MUST 業務イベントを担当者へ伝える。 システム、通知対象者 通知イベントが成立する。配信先/経路の稼働は未確認。 要調整通知。失敗/再送は未決。 T-28 Tomoya / 陸
NTF-05 FR-026 完了打刻時、管理者とオーナーに完了報告を通知する（物件・完了時刻・写真へのリンク）。 機能要件!A27, 機能要件!B27, 機能要件!C27, 機能要件!D27, 機能要件!E27, 機能要件!F27 MUST 業務イベントを担当者へ伝える。 システム、通知対象者 通知イベントが成立する。配信先/経路の稼働は未確認。 D-08 未決。完了通知。ownerへのチャネルはD-08未決。 T-33 Tomoya / 陸
NTF-06 FR-027 清掃日の前日18時に、担当スタッフへリマインドを送る。 機能要件!A28, 機能要件!B28, 機能要件!C28, 機能要件!D28, 機能要件!E28, 機能要件!F28 MUST 業務イベントを担当者へ伝える。 システム、通知対象者 通知イベントが成立する。配信先/経路の稼働は未確認。 D-13 未決。前日18時はD-13未決。 AT-06 Tomoya / 陸
ANS-01 FR-028 スタッフは担当物件のタスクに ◯（入れる）／ ×（入れない）／ 保留 ／ 翌日なら可 で回答する。 機能要件!A29, 機能要件!B29, 機能要件!C29, 機能要件!D29, 機能要件!E29, 機能要件!F29 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-21 Tomoya / 陸
ANS-02 FR-029 回答期限は通知から24時間。期限を過ぎても確認中のタスクには回答できる（管理者はアラートで把握）。 機能要件!A30, 機能要件!B30, 機能要件!C30, 機能要件!D30, 機能要件!E30, 機能要件!F30 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 D-03 未決。期限後回答と24h通知起点はD-03未決。 AT-07 Tomoya / 陸
ANS-03 FR-030 早い者勝ち：最初に ◯ を押したスタッフで自動確定する。確定後、他のスタッフは回答できず「締切済み」と表示される。 機能要件!A31, 機能要件!B31, 機能要件!C31, 機能要件!D31, 機能要件!E31, 機能要件!F31 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 D-01 未決。最初の◯自動確定はD-01未決。9/28 00:02要約は方向支持だが00:18版xlsxは未決。 T-18, T-19 Tomoya / 陸
ANS-04 FR-031 ほぼ同時に ◯ が押された場合、先にサーバーが受け付けた1人だけが確定し、もう1人には「他のスタッフで確定しました」と表示する。 機能要件!A32, 機能要件!B32, 機能要件!C32, 機能要件!D32, 機能要件!E32, 機能要件!F32 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 先着はserver受付順。 T-20 Tomoya / 陸
ANS-05 FR-032 回答を後から変えられるのは「保留」だけ。◯・×・翌日なら可 を選んだ後の変更は別ツールで管理者に連絡する。 機能要件!A33, 機能要件!B33, 機能要件!C33, 機能要件!D33, 機能要件!E33, 機能要件!F33 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 D-04 未決。保留だけ変更可能はD-04未決。 T-22, T-23 Tomoya / 陸
ANS-06 FR-033 「保留」は未回答と同じ扱い（24時間の期限は止まらない）。管理者画面では未回答と区別して表示する。 機能要件!A34, 機能要件!B34, 機能要件!C34, 機能要件!D34, 機能要件!E34, 機能要件!F34 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 D-04 未決。保留の期限/表示はD-04未決。 T-22 Tomoya / 陸
ANS-07 FR-034 「翌日なら可」は自動確定しない。管理者が割り当てるかどうかを判断する。 機能要件!A35, 機能要件!B35, 機能要件!C35, 機能要件!D35, 機能要件!E35, 機能要件!F35 MUST 担当スタッフの可否と確定順を扱う。 担当スタッフ、管理者 回答者が物件担当者である。回答可能状態はD-01等の承認待ち。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-24 Tomoya / 陸
ALT-01 FR-035 「翌日なら可」のスタッフを割り当てると、清掃日がチェックアウト翌日になり、ステータスは確定になる。 機能要件!A36, 機能要件!B36, 機能要件!C36, 機能要件!D36, 機能要件!E36, 機能要件!F36 MUST 翌日作業と次予約の清掃可否を判断する。 管理者、システム、担当スタッフ 予約日時と物件のチェックイン/アウト時刻が取得済み。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-27 Tomoya / 陸
ALT-02 FR-036 翌日割当の後に、同じ物件でチェックアウト日にチェックインする予約（連続予約）を検知したら、ステータスを「要調整」に戻し、赤枠で表示して管理者に通知する。 機能要件!A37, 機能要件!B37, 機能要件!C37, 機能要件!D37, 機能要件!E37, 機能要件!F37 MUST 翌日作業と次予約の清掃可否を判断する。 管理者、システム、担当スタッフ 予約日時と物件のチェックイン/アウト時刻が取得済み。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-28 Tomoya / 陸
ALT-03 FR-037 すでに連続予約があるタスクに翌日割当をしようとすると、画面上で警告を出し、確認したときだけ割り当てる。 機能要件!A38, 機能要件!B38, 機能要件!C38, 機能要件!D38, 機能要件!E38, 機能要件!F38 MUST 翌日作業と次予約の清掃可否を判断する。 管理者、システム、担当スタッフ 予約日時と物件のチェックイン/アウト時刻が取得済み。 原文は警告後に確認すれば割当可能。ハード拒否へ変更しない。確認後に残る衝突はQ-07。 T-29 Tomoya / 陸
WRK-01 FR-038 確定した担当スタッフだけが、清掃日の当日に「清掃開始」を打刻できる。 機能要件!A39, 機能要件!B39, 機能要件!C39, 機能要件!D39, 機能要件!E39, 機能要件!F39 MUST 現場作業時間と完了の証跡を保存する。 確定担当スタッフ、管理者 本人が確定担当者として認証される。 D-11 未決。当日制限はD-11未決。現行コードは日付/status未判定。 T-30, T-31 Tomoya / 陸
WRK-02 FR-039 開始打刻の後に「清掃完了」を打刻できる。完了時に写真（1枚以上必須・最大20枚）とコメント（任意・1000字まで）を登録する。 機能要件!A40, 機能要件!B40, 機能要件!C40, 機能要件!D40, 機能要件!E40, 機能要件!F40 MUST 現場作業時間と完了の証跡を保存する。 確定担当スタッフ、管理者 本人が確定担当者として認証される。 D-10 未決。1〜20枚/1000字はD-10未決。既存checklist完了条件との関係はQ-16。 T-32, T-33 Tomoya / 陸
WRK-03 FR-040 完了打刻でステータスが「完了」になり、管理者とオーナーに通知される。 機能要件!A41, 機能要件!B41, 機能要件!C41, 機能要件!D41, 機能要件!E41, 機能要件!F41 MUST 現場作業時間と完了の証跡を保存する。 確定担当スタッフ、管理者 本人が確定担当者として認証される。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-33 Tomoya / 陸
WRK-04 FR-041 完了後24時間は、本人が写真とコメントを追加・修正できる。 機能要件!A42, 機能要件!B42, 機能要件!C42, 機能要件!D42, 機能要件!E42, 機能要件!F42 MUST 現場作業時間と完了の証跡を保存する。 確定担当スタッフ、管理者 本人が確定担当者として認証される。 D-14 未決。本人24h、管理者いつでも、owner再通知なしはD-14未決。 T-34 Tomoya / 陸
OWN-01 FR-042 オーナーは専用URLから、自分の物件だけを見られる。 機能要件!A43, 機能要件!B43, 機能要件!C43, 機能要件!D43, 機能要件!E43, 機能要件!F43 MUST オーナーが自分の物件の作業状況を確認する。 オーナー、システム ownerの認証または専用URLが有効。個別設定は未確認。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-35 Tomoya / 陸
OWN-02 FR-043 清掃予定（清掃日・ステータス）と完了報告（写真・コメント・開始／完了時刻）を見られる。 機能要件!A44, 機能要件!B44, 機能要件!C44, 機能要件!D44, 機能要件!E44, 機能要件!F44 MUST オーナーが自分の物件の作業状況を確認する。 オーナー、システム ownerの認証または専用URLが有効。個別設定は未確認。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-36 Tomoya / 陸
OWN-03 FR-044 ゲストの氏名・連絡先などの予約情報と、担当スタッフの名前は表示しない。 機能要件!A45, 機能要件!B45, 機能要件!C45, 機能要件!D45, 機能要件!E45, 機能要件!F45 MUST オーナーが自分の物件の作業状況を確認する。 オーナー、システム ownerの認証または専用URLが有効。個別設定は未確認。 D-09 未決。ownerにスタッフ名を表示しないD-09未決。 T-37 Tomoya / 陸
OWN-04 FR-045 オーナーは閲覧のみで、何も変更できない。 機能要件!A46, 機能要件!B46, 機能要件!C46, 機能要件!D46, 機能要件!E46, 機能要件!F46 MUST オーナーが自分の物件の作業状況を確認する。 オーナー、システム ownerの認証または専用URLが有効。個別設定は未確認。 閲覧専用の範囲と既存owner編集は未決。 T-35 Tomoya / 陸
ATT-01 FR-046 開始〜完了の打刻を、スタッフの勤務記録として保存する。 機能要件!A47, 機能要件!B47, 機能要件!C47, 機能要件!D47, 機能要件!E47, 機能要件!F47 MUST スタッフ別の勤務記録を集計する。 管理者、スタッフ 勤務記録が保存されている。 v0.9原文条件を提案として保持。追加例外/失敗時挙動は必要に応じClarificationsで決める。 T-38 Tomoya / 陸
ATT-02 FR-047 管理者は スタッフ別・月別 に清掃件数と合計時間を一覧でき、CSVで出力できる。 機能要件!A48, 機能要件!B48, 機能要件!C48, 機能要件!D48, 機能要件!E48, 機能要件!F48 MUST スタッフ別の勤務記録を集計する。 管理者、スタッフ 勤務記録が保存されている。 件数/時間/CSV要件。報酬計算はD-15未決。 T-38 Tomoya / 陸

状態モデル

タスク状態とスタッフ個人の回答は別軸。図はv0.9の提案遷移で、D論点の承認結果ではない。未記載の遷移を許可/禁止と決めない。

stateDiagram-v2
  [*] --> 確認中: 新規予約検知
  確認中 --> 確定: 最初の◯ / 管理者割当 [D-01未決]
  確認中 --> 取消: 予約取消 [D-06未決]
  確定 --> 清掃中: 清掃日当日に確定担当が開始打刻 [D-11未決]
  確定 --> 要調整: 翌日割当後の連続予約
  確定 --> 取消: 予約取消 [D-06未決]
  要調整 --> 確定: 管理者の再割当・日程調整
  要調整 --> 取消: 予約取消 [D-06未決]
  清掃中 --> 完了: 完了打刻・報告
タスク状態 意味/到達元 原文の次状態 未決境界
確認中 予約検知後、担当スタッフの回答待ち。担当未決。 確定、取消 全員×、期限後、担当追加、消失と取得失敗（D-01/03/06）。
確定 担当と清掃日が決定。 清掃中、要調整、取消 管理者が回答前に割当した場合の個人回答履歴、予約日変更（D-01/05）。
清掃中 開始打刻済み。 完了 取消/日程変更、二重打刻、担当交代。
完了 完了打刻と報告を済ませ、管理者/ownerへ通知済みという原文。 原文に次状態なし タスク完了遷移が通知配信成功を待つかはQ-28未決。提案は作業/報告保存と通知結果を分けて記録するが未承認。完了後の予約変更/取消、報告修正/再通知（D-14）も未決。
取消 元予約がキャンセルされた。 原文に次状態なし 清掃中/完了後の取消、復帰、勤怠/報告保持。
要調整 翌日割当後に連続予約が入り、管理者調整が必要。 管理者が再割当/日程調整し確定、取消 担当が残る場合があり担当=nullと同義ではない。スタッフ回答受付可否は未決。

回答軸: 未回答 → ◯ / × / 保留 / 翌日なら可。v0.9の保留変更/期限挙動はD-04未決。最初の◯でタスク確定はD-01未決。管理者が回答前に割当しても個人回答履歴を保持し、タスクだけ確定にする案は提案でありD-01の結論ではない。

管理者一覧の表示ルール

表示 条件 見た目 補足/出典
通常 確定・清掃中など 通常背景/枠線 表示ルール!A2:D2
新規 初回検知から7日以内（D-02未決） 濃い青背景 未割当と重なる場合は青背景と赤枠を両方表示。表示ルール!A3:D3
未割当 確認中/要調整、または担当スタッフ0人の物件 赤枠 表示ルール!A4:D4
未割当24h超 通知から24時間経過して未割当（D-03未決） 太い赤枠、赤背景、「24h超」ラベル、一覧最上部 管理者LINE通知案。表示ルール!A5:D5
要調整 翌日割当後に連続予約 赤の破線枠、「連続予約」ラベル 管理者LINE通知案。表示ルール!A6:D6

画面と URL 構造 *(L2 のみ)*

画面/入口 現行URL（clone-app.tsx route list） 利用者 操作/状態
管理calendar /clean/cleaner/calendar; /clean/cleaner/today; /clean/cleaner/calendar/2026-07-13; /clean/cleaner/calendar/assign/2026-07 管理者 全物件予定、日別担当、月間割当。
月次shift /clean/cleaner/calendar/shift 管理者 月次公開/管理。現行経路。
メンバー/物件 /clean/cleaner/member; /clean/cleaner/listing 管理者 staff・property管理。
staff予定/回答 /clean/cleaner/calendar; /clean/cleaner/today; /clean/cleaner/calendar/shift-preference/schedule; /clean/cleaner/calendar/shift-preference/daily スタッフ 担当予定と現行回答経路。v0.9の専用URL/LINE回答は新規URL含め未決。
現場task/report /clean/cleaner/today; /clean/cleaner/cleanSchedules/demo-schedule スタッフ/管理者 現場操作と清掃report。demo routeのDB接続は未確認。
勤務時間分析 /clean/cleaner/analytics/staff-times; /clean/cleaner/payout 管理者 staff時間分析/支払関連。専用attendance画面の有無はコードで未確認。
owner calendar/listing /clean/owner/calendar; /clean/owner/listing; /clean/owner/member owner 現行route。v0.9では専用URL閲覧のみ案だが、既存機能との範囲未決。
admin feedback /clean/cleaner/feedback 管理者 現行feedback一覧。詳細取得sourceはQ&A資料節。
API dispatcher /api/* → worker/index.ts roleごと UI非表示を認可の代用にしない。API詳細はplanへ。

パスは現行コードへの参照で、新規URLの確定ではない。個人URL、token失効、Google OAuthとの共存はClarificationsで決める。

Key Entities *(L2 のみ)*

現行実装との照合（静的読解、runtime未検証）

調査したlocal mainとremote mainはともに b2ae167d643421fdb74a94f0adeaa156aead41f2。本番revision、DB状態、外部通知到達、QA testは未確認。以下は現状のコード証拠で、要求承認の代わりではない。

領域 現行コードの事実 仕様との差分/必要確認 コード出典
予約・task iCal/Beds24、手動同期、upsert、手動予定、状態/時刻/担当変更。 予約消失を取消とみなす条件と取得失敗の区別は未決。 worker/jobs.ts:121-137,377-423,723-776; worker/beds24.ts:106-173; worker/ical.ts
即時通知 新規予約通知行は対象月が公開済みのときだけ作られる。DB行作成はLINE送信でない。コード上LINE/Chatwork送信経路なし。 NTF-01即時全員通知と差分。チャネル/部分失敗を決める。 worker/shift.ts:470-479; notification row 425付近
現行シフト 月次公開、翌月cron、3択 ok/open_no/ng、管理者編集、募集枠と先着claim。1 taskのassigneeは単一。 物件に複数スタッフを紐付けることとtask確定担当1名は別概念。既存月次/手動募集の3 routeを保ち、新規予約回答へ接続する方法は未決。 worker/shift.ts:498-625; worker/cron.ts:103-150; admin-portal.tsx:2419-2420
開始・完了 開始は本人担当/未取消を確認するが日付/statusを判定しない。完了は開始済みを要求しない。未開始なら開始=完了=nowで保存。再完了は終了時刻を更新。 WRK-01/02と差分。二重操作、取消/完了後、既存履歴保持を確認。 worker/field-work.ts:85-93,105-129
checklist/写真 完了時に全check項目が必須。写真は1要求1枚、5MiB以下。全体枚数上限/下限はコード上見当たらない。 v0.9の写真1〜20枚、checklist v1除外案と衝突。既存機能は廃止決定まで保持。 worker/field-work.ts:31-82,105-117,208-221; field-work-rules.mjs:6-9
admin訂正 直接訂正は時刻整合を検査するが、該当関数は旧時刻/訂正者を履歴保存せず、actor列をNULL/既存値で上書き。 ADM-09の監査要件に不足。別訂正経路を実装時に確認。 worker/field-work.ts:120-129
認証/権限 Google OAuth、署名付き30日session、招待制、利用停止チェック。API側role認可あり。 個人URL/owner URLとの共存と担当外直接割当のAPI境界未決。 worker/auth.ts:1-35; worker/index.ts:150-178,208-279,858-875
既存データ property, job, shift, attendance, photo/check, expenses/inventory, billing/payouts, guest registry, owner, notification, feedback, history等。 明示承認なしに削除しない。migration/保持/restoreはplanで決定。 db/schema.ts; drizzle/0000...0020; worker/index.ts:123-143
owner画面 owner/team管理、owner data、画像/旅券読取、物件共有メモ。 owner閲覧専用/スタッフ名非表示との範囲を決定。 worker/owners.ts; worker/index.ts:394-436; owner-portal.tsx
給与/請求 時給/訪問手当、支払作成/発行、owner請求。 D-15未決。新規v1除外案は現行機能撤去の承認でない。 worker/billing.ts:135-360; worker/index.ts:388-410,491-565
その他画面 routeとextended portalにローカル表示/デモ構成がある。 routeだけでDB接続済と見なさず画面ごと確認。 clone-app.tsx:114-148; extended-portal.tsx

既存機能の保全表

既存領域 添付との関係 暫定扱い
月次シフト/3択/管理者編集/募集枠先着 新規予約即時回答/自動確定案と競合 維持。共存/置換は決定待ち。
propertyの複数スタッフ登録/自動割当/feed 1 taskの確定担当は現行単一。物件スタッフ範囲と割当範囲を分けて扱う。 維持。二重管理の関係をplanで明確化。
checklist/写真 v0.9は新規v1の拡張を除外、写真1〜20案 現行実装を保持。撤去/完了条件の変更は人の決定後。
inventory/expenses v0.9備品管理は新規v1範囲外 既存機能を保持。
payroll/payout/invoice D-15未決 現行支払/請求を保持。方式をD-15で決める。
owner team/共有メモ/編集 v0.9閲覧のみ案 既存操作を保持。owner閲覧範囲と合わせ決定。
guest registry/予約情報 ownerにゲスト情報非表示案 role/API読取を棚卸し。個人情報を無断移行・削除しない。
現場報告/添付/履歴/feedback 新しい完了報告と接続要確認 保持し、統合方針を決めてから変更。

Constraints *(mandatory)*

ID 区分 制約 影響 検証方法
CON-001 既存資産 人の明示廃止決定なしに現行機能・データ・権限・履歴を削除/無効化しない。 現行運用停止、データ損失 保全表とコード、migration、route/API/UIを照合。
CON-002 認可 権限はAPI境界でも検査し、UI非表示だけを拒否策にしない。owner物件境界とゲスト情報非表示を守る。 他物件/個人情報漏えい role/owner/propertyの許可・拒否をAPI受入確認。
CON-003 状態・履歴 担当、回答、タスク状態、勤怠、報告は別の事実。変更時に旧値/回答/時刻/担当/報告を黙って上書きしない。 状態矛盾、監査不能 二重操作、訂正、取消後変更を履歴付きで確認。保持仕様は未決。
CON-004 通知 承認された条件・宛先・停止条件に従って通知する。失敗/部分成功/重複の扱いを定義する。 誤連絡、通知漏れ テスト宛先で送信先・イベント・再試行・抑止を確認。
CON-005 認証情報 推測困難token、期限/失効/再発行/既存sessionを定義し、個別認可なしに認証済としない。具体値は未承認。 不正閲覧/操作 期限切れ、無効化後session、別owner/member、再発行を確認。
CON-006 個人情報 owner API応答からゲスト氏名・連絡先等を除外する要件を適用する。 個人情報漏えい API responseと画面で確認。
CON-007 SDD 現況の正本はコード、意図の正本はこのspec。仕様変更を決める前にコードだけ先行改修しない。 判断根拠消失 承認後planに反映し、適合差を検出。
CON-008 人間ゲート 開発AIが金銭、外部送信、データ削除、本番deployを人の確認なしに実行しない。 不可逆な事故 planで操作・確認者・停止手順を明記。
CON-009 外部依存 iCal/Beds24内容、障害と取消の区別、通知到達性はコードから本番稼働を断定しない。 誤取消、通知漏れ QA/実機の証拠を取得して確認。

Out of Scope *(mandatory)*

ID 今回新たに行わないこと 理由 将来/既存の扱い
OOS-001 この作業で実装、DB migration、API変更、本番deploy、通知送信を行う。 今回StageはL2 specify/clarify準備、Status Draft。 承認後別Stageで判断。
OOS-002 checklist/備品管理を新規v1機能として拡張する。 v0.9はデータ構造準備までの案。 現行機能の撤去承認ではない。
OOS-003 報酬計算（物件単価/時給）を新規v1要件と確定する。 D-15未決。 既存支払・請求機能は保持。方式と範囲をD-15で決定。
OOS-004 回答後のシフト変更申請をアプリに追加する。 v0.9の新規v1対象外案。 別ツール連絡/管理者変更案は未承認。既存管理者編集は保持。
OOS-005 ゲストとのやり取り機能を追加する。 v0.9のv1対象外。 既存名簿等の削除はしない。
OOS-006 ricecream-attendanceのClean Shift勤怠にこの仕様を適用する。 assistbnbとは別製品。 本feature対象外。
OOS-007 根拠のない性能SLO、稼働率、同時数、RTO/RPO、保持期間を決める。 数値の原資料がない。 利用量/停止許容/保持期間を確認後に決める。
OOS-008 公開AssistBnBマニュアルをassistbnbクローンの現況/要求とみなす。 参考元の別サービス。 比較用に限る。
OOS-009 9/3と9/27のfeedback6件を同じ集合として扱う。 異なる投稿群。 今回のFB-01〜06は9/27分。9/3本文は未確認。

テスト観点 *(mandatory)*

区分 観点 対応FR / CON
正常系 予約1件1task、担当回答/確定、開始/完了、報告、勤怠CSVを照合する。 FR-005〜FR-012, FR-027〜FR-047
例外系（禁止事項） 重複予約/回答、通知部分失敗、取消/変更、未開始完了、完了後再打刻、時間境界を確認する。 FR-007〜FR-012, FR-030〜FR-041, CON-003/004/009
権限別の差分 admin/member/owner、担当外割当、別物件、無効token、直接APIでの認可を確認する。 FR-001〜FR-004, FR-019〜FR-020, FR-043〜FR-046, CON-002/005/006
既存機能への影響 月次シフト/募集、checklist/写真、在庫/経費、支払/請求、owner team/メモ、名簿/履歴を個別確認する。 CON-001, OOS-002〜OOS-005

Success Criteria *(mandatory)*

Measurable Outcomes

Assumptions *(L2 のみ)*

Clarifications

[NEEDS CLARIFICATION: D-01〜D-15およびQ-01〜Q-22、Q-24、Q-27〜Q-28の業務判断が未回答。Q-23/Q-25は実装調査、Q-26は任意資料であり本人承認ゲートではない]

先に確認する5点

  1. 回答/権限/状態: D-01、Q-01〜04、Q-06、Q-11/Q-24、Q-13〜15（Q-15はQ-01への重複確認をしない）。
  2. 予約と記録保全: D-05〜07、Q-05〜08（消失/取得失敗、取消/変更、完了後履歴）。
  3. 通知: D-03、D-08、D-13、Q-09〜10（チャネル、24h起点、部分/全失敗、宛先変更）。
  4. 現場/既存機能: D-10、D-11、D-14、D-15、Q-16〜19（Q-14とQ-19はシフト以外の既存機能範囲だけ確認）。
  5. 非機能/feedback: Q-17〜18、Q-20〜22（宿泊人数、時間概念、非機能、保持、監視）。

添付xlsx D-01〜D-15（全件未決）

ID 論点 v0.9推奨案（未承認） 別案（未承認） 決定欄 決定内容欄 出典セル 決定者
D-01 最初の ◯ で自動確定する？ それとも管理者が確定ボタンを押す？ 自動確定。「早い者勝ち」と「自動化」の目的に合う。管理者は後から担当を変えられる。 ◯は「希望」として集め、管理者が選んで確定（手間は増えるが人を選べる）。 未決 未記入 論点!A2, 論点!B2, 論点!C2, 論点!D2, 論点!E2, 論点!F2 Tomoya / 陸
D-02 「1週間以内の新規予約」は何から数えて1週間？ システムが予約を初めて検知してから7日間。iCalには「予約が入った日時」が含まれないため、どの取得方法でも同じ基準にできる。 清掃日が今日から7日以内（＝直前の予約を目立たせる）。目的が「急ぎの把握」ならこちら。 未決 未記入 論点!A3, 論点!B3, 論点!C3, 論点!D3, 論点!E3, 論点!F3 Tomoya / 陸
D-03 24時間はいつから数える？ 担当スタッフへ通知を送った時刻から。 予約を検知した時刻から（ほぼ同じだが、担当0人の物件などで差が出る）。 未決 未記入 論点!A4, 論点!B4, 論点!C4, 論点!D4, 論点!E4, 論点!F4 Tomoya / 陸
D-04 「保留」を選んだ人はどう扱う？ 未回答と同じ扱いで、後から ◯／× に変えられる。24時間の期限は止まらない。 保留は回答済みとみなし、24時間アラートを出さない。 未決 未記入 論点!A5, 論点!B5, 論点!C5, 論点!D5, 論点!E5, 論点!F5 Tomoya / 陸
D-05 確定後に予約の日程が変わったら？ 担当はそのまま、清掃日だけ変えて本人と管理者に通知。入れなければ本人が別ツールで連絡。 確認中に戻して回答を取り直す。 未決 未記入 論点!A6, 論点!B6, 論点!C6, 論点!D6, 論点!E6, 論点!F6 Tomoya / 陸
D-06 確定後にキャンセルされたら？ 取消にして担当と管理者に通知。キャンセル料の扱いはアプリの外。 — 未決 未記入 論点!A7, 論点!B7, 論点!C7, 論点!D7, 論点!E7, 論点!F7 Tomoya / 陸
D-07 オーナー利用・メンテ等のブロック日も清掃する？ タスクを作らない。必要なら管理者が手動でタスクを追加できるようにする。 ブロックも清掃対象にする（オーナー利用後に清掃が必要な物件がある場合）。 未決 未記入 論点!A8, 論点!B8, 論点!C8, 論点!D8, 論点!E8, 論点!F8 Tomoya / 陸
D-08 オーナーへの完了通知は何で送る？ LINE。オーナーにも公式アカウントを友だち追加してもらう。 メール（LINEを使わないオーナー向けに物件ごとに選択）。 未決 未記入 論点!A9, 論点!B9, 論点!C9, 論点!D9, 論点!E9, 論点!F9 Tomoya / 陸
D-09 オーナー画面に担当スタッフ名を出す？ 出さない。スタッフへの直接連絡を防ぎ、窓口を管理者に一本化する。 下の名前だけ表示。 未決 未記入 論点!A10, 論点!B10, 論点!C10, 論点!D10, 論点!E10, 論点!F10 Tomoya / 陸
D-10 完了時の写真は必須？ 何枚？ 1枚以上必須、最大20枚。 物件ごとに必須枚数を設定（v2のチェックリストと合わせて）。 未決 未記入 論点!A11, 論点!B11, 論点!C11, 論点!D11, 論点!E11, 論点!F11 Tomoya / 陸
D-11 開始打刻は清掃日当日以外にもできる？ 当日のみ。打刻忘れ・日付違いは管理者が修正する。 前日夕方から可（前日入りの運用がある場合）。 未決 未記入 論点!A12, 論点!B12, 論点!C12, 論点!D12, 論点!E12, 論点!F12 Tomoya / 陸
D-12 予約の取得間隔は？ 30分ごと。Airbnb側のiCal更新自体が数時間おきのため、これより短くしても効果は小さい。 15分（Beds24 APIの物件だけ短くする）。 未決 未記入 論点!A13, 論点!B13, 論点!C13, 論点!D13, 論点!E13, 論点!F13 Tomoya / 陸
D-13 前日リマインドは必要？ 前日18時に担当へ送る。 送らない。 未決 未記入 論点!A14, 論点!B14, 論点!C14, 論点!D14, 論点!E14, 論点!F14 Tomoya / 陸
D-14 完了後の報告修正は誰がいつまでできる？ 本人は完了から24時間以内、管理者はいつでも。オーナーへの再通知はしない。 — 未決 未記入 論点!A15, 論点!B15, 論点!C15, 論点!D15, 論点!E15, 論点!F15 Tomoya / 陸
D-15 勤怠からの報酬計算をv1に入れる？ v1は件数と時間の集計＋CSV出力まで。計算方式（物件単価 or 時給）が決まったらv2で対応。 物件ごとの単価を登録し、月次の支払額まで出す。 未決 未記入 論点!A16, 論点!B16, 論点!C16, 論点!D16, 論点!E16, 論点!F16 Tomoya / 陸

追加の確認事項（推論提案、未承認）

元表にない境界条件。制約提案も最終ポリシーはTomoya/陸が決める。

| ID | 重要度 | 未決質問/フォロー | 比較案/期待値 | 出典・推論 | 決定者 | 実装/調査担当 | 判断区分・対応 | |---|---|---|---|---|---|---| | Q-01 | P0 | PRP-03の物件担当範囲とADM-07の担当外スタッフ割当をどう両立するか。 | 提案:担当外は割当タスクだけを閲覧し物件全体権限は付けない。 | PRP-03/ADM-07、API認可境界 | Tomoya / 陸 | Tomoya / 陸 | 業務権限判断。Approved前に要決定。Q-15は同じ回答を参照。 | | Q-02 | P0 | 全員×のときタスク状態は何か。 | 元表に定義なし。確認中継続/別状態を選択。 | ANS-01/02 | Tomoya / 陸 | Tomoya / 陸 | 状態/運用判断。Approved前に要決定。 | | Q-03 | P0 | 担当0人から後でスタッフを追加した場合、既存taskを誰に通知するか。 | 後から通知するか未承認。 | PRP-03 | Tomoya / 陸 | Tomoya / 陸 | 通知対象の業務判断。該当通知の実装前に要決定。 | | Q-04 | P0 | 要調整中にスタッフ回答を受け付けるか。 | 確認中の回答ルールを延長しない。 | ALT-02 | Tomoya / 陸 | Tomoya / 陸 | 回答受付の業務判断。Approved前に要決定。 | | Q-05 | P0 | 24時間の起点は最初の成功、全員成功、送信試行のどれか。全失敗時はどうするか。 | 部分成功者/未達者の再送と管理者警告を決める。 | D-03、NTF-01/03、配信失敗推論 | Tomoya / 陸 | Tomoya / 陸 + 実装担当 | 24h起点は業務判断。再試行/送信状態はplan設計。 | | Q-06 | P0 | 同じスタッフの別タスク時間が重複する場合に割当/自動確定してよいか。 | 作業時間・所要時間が未決。 | ADM-02/NTF-01 | Tomoya / 陸 | Tomoya / 陸 | 重複割当の業務ルール。Approved前に要決定。 | | Q-07 | P0 | 翌日作業は次のチェックインまで何時から何時を作業窓とするか。 | 移動/所要時間なしに成立可否を決めない。ALT-03の確認後割当を禁止へ変えない。 | 概要、ALT-01〜03 | Tomoya / 陸 | Tomoya / 陸 | 作業可能時間の業務判断。翌日割当受入前に要決定。 | | Q-08 | P0 | 取消/日程変更が取消済/清掃中/完了済へ届いた時の状態と勤怠/報告履歴はどうするか。 | 上書き/削除せず状態遷移を人が決める。 | SYN-04/05、CON-003 | Tomoya / 陸 | Tomoya / 陸 | 状態/記録保全の業務判断。Approved前に要決定。 | | Q-11 | P0 | 管理者が回答前に手動確定した場合、個人回答をどう記録するか。 | 提案:本人回答履歴とtask確定状態を別軸に保持。D-01を決める回答ではない。 | ADM-07、9/28 00:02会話要約 | Tomoya / 陸 | Tomoya / 陸 | Q-24と同じ判断を一度だけ行う。回答履歴保持の業務意味を決める。 | | Q-13 | P0 | スタッフ/owner URL失効・再発行時、既存セッションも即時失効するか。 | 現Google OAuthの30日sessionとの関係を決める。 | NFR-04、現行worker/auth.ts | Tomoya / 陸 | Tomoya / 陸 | 失効/既存sessionのセキュリティ方針。Approved前に要決定。 | | Q-16 | P0 | 既存checklistを完了条件として残すか、写真必須完了報告とどう共存させるか。 | v1対象外は既存削除承認ではない。 | 概要!B8、WRK-02、現行field-work.ts | Tomoya / 陸 | Tomoya / 陸 | 既存checklistを変更/廃止する場合のみ明示承認。既定は保全。 | | Q-09 | P1 | 通知チャネルはLINEかメールか。ownerがLINEを使わない時はどうするか。 | D-08にメール案。現コードは通知行でLINE実送信なし。 | D-08、NTF-01/05 | Tomoya / 陸 | Tomoya / 陸 | owner通知チャネルの業務判断。D-08と同じ論点。 | | Q-10 | P1 | 物件担当の追加/無効化を既存task・通知先・tokenへいつ反映するか。 | 過去予約への遡及通知や再割当を決める。 | PRP-03、NFR-04 | Tomoya / 陸 | Tomoya / 陸 | 担当変更後の通知/権限という業務判断。外部送信前に要決定。 | | Q-12 | P1 | 要調整後の再確定で前担当/回答/変更理由をどう見せるか。 | 担当上書きだけでは履歴が消える。 | ALT-02、ADM-08/09 | Tomoya / 陸 | Tomoya / 陸 | 監査情報の業務要件。詳細方式はplanへ。 | | Q-14 | P1 | 月次公開3択と新規予約単位4択を併存させるか。 | 既存データ、cron、運用の正本を決める。 | 9/1 16:35要約、現行worker/shift.ts | Tomoya / 陸 | Tomoya / 陸 | 月次/予約単位シフトの共存判断。Q-19と同じ回答を重ねない。 | | Q-15 | P1 | 担当外へ直接割当したtaskを物件カレンダー/owner表示にどう出すか。 | Q-01のアクセス範囲と合わせる。 | PRP-03/ADM-07 | Tomoya / 陸 | Q-01の回答を参照 | 追加の決定は不要。表示への反映方法はplan。 | | Q-17 | P1 | 宿泊人数の自動取得元と取得不能時の表示/手入力はどうするか。 | Beds24等の取得範囲を決める。 | FB-01、Beds24導入はキコバのみとの9/27回答 | Tomoya / 陸 | Tomoya / 陸 | 宿泊人数機能を本featureに追加するかの業務範囲判断。 | | Q-18 | P1 | 「清掃の予定時刻」「作業可能時間」は開始予定/所要時間/開始可能窓のどれか。 | ラベルと割当衝突判定に関わる。 | FB-03、ADM-02/NTF-01 | Tomoya / 陸 | Tomoya / 陸 | 画面用語/時間概念の業務定義。FR承認前に決定。 | | Q-19 | P1 | 月次シフト/checklist/在庫/報酬/owner編集のどれを長期維持するか。 | 保持制約は適用。画面/データ/保守範囲は明示決定。 | 既存機能保全表、概要!B8、D-15 | Tomoya / 陸 | Tomoya / 陸（廃止時のみ） | Q-14はシフト共存、Q-19はそれ以外の既存機能。既定は保全、削除時のみ明示承認。 | | Q-21 | P1 | 写真/コメント/勤怠/監査/予約データの保持・削除・復元期限は何か。 | 既存写真183日期限の対象も確認。 | 現行field-work.ts、保持方針未取得 | Tomoya / 陸 | Tomoya / 陸 + 技術担当 | 保持/削除期間と復旧要求は業務判断、保存方式はplan。 | | Q-22 | P1 | 同期/通知/履歴の失敗を誰がどこで検知し、どう復旧するか。 | 一部の警告/Slack経路があるが稼働未確認。 | SYN-07、現行cron/notification | Tomoya / 陸 | Tomoya / 陸 + 運用/実装担当 | 監視の責任者/復旧方針を決め、技術方式はplan。 | | Q-23 | P1 | カレンダー入力がシフト担当欄へ反映されない時、予定/担当の正本と同期時点は何か。 | 原因を特定せず一般化しない。 | FB-02、投稿時刻 9/27 16:26:39 | Tomoya / 陸 | 実装担当 | feedbackの再現/同期原因を調査。要件内容を変える判断が必要な時だけ起票。 | | Q-24 | P1 | 管理者割当後、個人回答欄は未回答のままか、管理者割当という記録を別に作るか。 | task確定と個人回答は別軸。 | FB-06、ANS-01/06、ADM-07 | Tomoya / 陸 | Tomoya / 陸 | Q-11の同一判断。管理者確定と個人回答履歴の意味を一度だけ決定。 | | Q-25 | P1 | 実装/QA確認: 未割当または本人がtaskの確定担当でない、取消済み、完了済み、当日外の状態で開始/完了UI/APIが拒否されるか。 | 期待値はAT-14に記載。拒否方法/HTTPコードはplanで設計し、人の業務判断は求めない。 | FB-04/05、WRK-01/03 | — | 実装担当（再現・API/UI受入） | AT-14の期待挙動を実装/QA確認。plan設計事項で本人承認ゲートではない。 | | Q-26 | P3 | 補足資料: Main.pdf/画像または9/1 16:59スタッフ画面/chatbotメモが後日届いた場合に参考にする。 | 現Draftは既存資料だけで確認でき、追加資料を承認条件にしない。 | 未添付/未取得の参考資料 | — | 仕様担当（任意） | 任意補足。資料不足は承認ゲートでない。 | | Q-27 | P1 | 「新規」の青背景と24h超の赤背景が同じタスクに当たる場合、背景色の優先順をどうするか。 | 両方の表示条件を残し、色の優先は決定まで確定しない。 | 表示ルール!A3:D5、ADM-03/05 | Tomoya / 陸 | 仕様担当 | 表示優先順の業務/UI判断。Approved前に要決定。 | | Q-28 | P1 | 清掃完了と通知配信結果をどう関係付け、部分/全失敗時の再送をどう扱うか。 | 完了状態とdelivery状態を分ける案は提案で未承認。 | ステータス!B6、NTF-05、通知失敗境界 | Tomoya / 陸 | 実装/運用担当 | 完了と配信結果の業務上の関係を決定し、再送/状態表示の技術方式はplan。 | | Q-20 | P2 | 必要な性能/可用性/同時数、ピークデータ量、RTO/RPOはいくつか。 | 根拠なく数値を置かない。 | 利用量未取得 | Tomoya / 陸 | Tomoya / 陸 + 技術担当 | 必要な数値がある場合のみ決定。根拠取得/設計を分離し、未承認値は書かない。 |

9/27利用者feedback（FB-01〜06は本書内ID）

取得は既存ログイン済み管理者UIのread-only表示。UIにfeedback IDは表示されず、以下IDは投稿時刻を結びに使う本書のID。9/3の別feedback6件と混同しない。全件「未対応」。

本書ID 投稿時刻 JST 種別 報告要約 対応FR/論点/受入 状態・出典
FB-01 2026-09-27 16:30:58 機能要望 カレンダーの宿泊人数は未入力が多い。手入力ではなくデータから自動取得したい。 Q-17、SYN-01。取得元と取得不能時の手入力保持を決めて受入。 未対応。投稿時刻識別。
FB-02 2026-09-27 16:26:39 不具合 カレンダーで入力した情報がシフトに反映されない例。9/23の予約を9/25に清掃したが、シフト担当欄に反映されなかったとの報告。 Q-23、ADM-07/08。予定/担当の正本、再読込後表示を確認。 未対応。原因再現未確認。
FB-03 2026-09-27 16:21:45 文言 「清掃の予定時刻」が清掃所要時間か作業開始予定時刻か分からない。 Q-18、ADM-02/NTF-01。ラベルと通知で意味を一致。 未対応。
FB-04 2026-09-27 16:20:48 不具合 担当者未定でも開始・終了・完了操作を押せる。 Q-25、WRK-01〜03、CON-002。UI/API双方の拒否境界を確認。 未対応。コードとの差は現行照合表。
FB-05 2026-09-27 16:17:05 不具合 清掃完了後も「清掃を始める」ボタンが表示される。 Q-25、WRK-01/03。完了後再読込で開始表示/操作の条件を確認。 未対応。実UI再現未確認。
FB-06 2026-09-27 16:09:24 不具合 管理者がシフトから担当者を指定しても回答状態が「未回答」のまま。 Q-24、ADM-07/ANS-01。task確定と回答履歴の表示を決める。 未対応。

取得元: 管理者feedback画面（2026-09-28確認、ログイン済み画面をread-only閲覧）。Wrangler D1 remote SELECTは認可エラー、feedback更新操作なし。本文は個人名・物件名を避けて要約。9/3投稿群は別集合で本文未確認。

追加受入条件案（元表にない推論、すべて未承認）

ID 確認案 対応先/出典 状態
AT-01 1 ownerが複数物件を持ち、各物件ownerは1人。owner別に自分の物件だけ閲覧。 PRP-04/OWN-01、TCなし 提案、未承認
AT-02 物件ごとにiCal/Beds24片方を選び、その取得元からtaskを生成。 SYN-01、TCなし 提案、未承認
AT-03 取得間隔/今すぐ取得を区別し、並行取得/再送でも予約IDごとにtask1件。 SYN-02/03、D-12、TCなし 提案、未承認
AT-04 管理一覧の全物件、期間/property/status filter、calendar/list切替を確認。 ADM-01、TCなし 提案、未承認
AT-05 ADM-02の全表示項目と回答数を照合。次予約なし/空値を誤表示しない。 ADM-02、TCなし 提案、未承認
AT-06 JST前日18:00の通知境界と宛先を確認。 NTF-06/D-13、TCなし 提案、未承認
AT-07 24h後も確認中なら回答受付を継続し、通知/強調表示が承認起点で発生。 ANS-02/D-03、TCなし 提案、未承認
AT-08 認証なし/別role/別propertyの直API読取・更新を拒否し他物件の存在も漏らさない。 CON-002/005/006、認可推論 提案、未承認
AT-09 同一予約の二重/並行取得、回答二重click/同時◯で一件/一人だけを確定。 SYN-03/ANS-04、NFR-05 提案、未承認
AT-10 通知の一部成功/全失敗/遅延/再試行で未達と重複が分かる。 NTF-01〜06、Q-05 提案、未承認
AT-11 予約event消失とfeed取得失敗を別々に発生させ、失敗のみで取消にしない案を確認。 SYN-04/07、D-06、Q-08 提案、未承認
AT-12 予約日変更/取消が取消済・清掃中・完了済に届く境界で状態と勤怠/報告履歴を確認。 SYN-04/05、Q-08 提案、未承認
AT-13 連続予約時に翌日割当警告を出し、確認後に割当できる原文を保つ。次check-inまでの作業窓不足を提示する案を確認。 ALT-03、Q-07 提案、未承認
AT-14 未割当、本人が当該taskの確定担当でない（property担当外を含む）、取消済み、完了済み、当日外では開始/完了をUIから実行できずAPIも拒否する。操作後もtask状態、保存済み打刻時刻、通知記録を変えない。完了済みtaskの再開は別操作で、本featureでは扱わない。HTTP code等の方法はplanへ。 WRK-01〜03、FB-04/05、Q-25 期待条件を反映。API/UI実装確認は未実施
AT-15 staff無効化後の専用URL、token再発行前後、既存sessionの継続/失効を確認。 NFR-04、Q-13 提案、未承認
AT-16 写真0/1/20/21枚を試し、0/21拒否、1/20許可の案を確認。形式/サイズ上限も確認。 WRK-02/D-10、現行5MiB/要求ファイル形式 提案、未承認
AT-17 コメント1000/1001字を試し境界と全角/絵文字/改行の文字数定義を確認。 WRK-02/D-10 提案、未承認
AT-18 JST 23:59開始/00:00完了、前日18時通知を異なる端末TZで確認。 NFR-02/NTF-06 提案、未承認
AT-19 勤怠/訂正保存後に再読込し、時刻、訂正前値/実行者、月次件数/時間/CSVが一致。 ATT-01/02、ADM-09、9/2勤怠会話要約 提案、未承認
AT-20 全員×、担当0人から追加、要調整中回答、担当外割当の各状態を人の決定値で確認。 Q-01〜04/Q-11 提案、未承認

非機能要件

ID 原文 出典 受入条件/未決
NFR-01 スタッフ画面はスマホ・LINE内ブラウザで全操作できる。 非機能・将来!B2 実端末/内ブラウザで主要操作。対応OS/viewportは未決。
NFR-02 時刻はすべて日本時間（JST）で表示・判定する。 非機能・将来!B3 表示、保存、cron、通知境界をAT-18で確認。
NFR-03 写真はアップロード時に長辺1600px程度へ縮小して保存。 非機能・将来!B4 許容範囲、画質、原本保持、形式未決。
NFR-04 スタッフ/owner URLは推測できないtokenにし、管理者が再発行できる。 非機能・将来!B5 token長/期限/失効/session境界はQ-13未決。
NFR-05 回答の確定処理は同時押しでも1人だけが確定。 非機能・将来!B6 T-20/AT-09で最終状態と応答を確認。
NFR-06 すべての状態変更に「誰が・いつ」を記録する。 非機能・将来!B7 actor/時刻/変更前後/保持期間/自動処理主体を決定し監査。
将来ID 原文 出典 今回の境界
FUT-01 checklist:物件ごとに項目設定、完了打刻時に全項目必須。 非機能・将来!B8 新規v1拡張の対象外案。既存checklistはQ-16/Q-19で扱い決定。
FUT-02 備品:物件別品目/基準数、清掃時に残数、下回れば管理者通知。 非機能・将来!B9 新規v1拡張の対象外案。既存在庫を削除しない。
FUT-03 v1で物件ごとの設定を持てるデータ構造を用意。 非機能・将来!B10 意図として保持、具体構造はplan。
FUT-04 スタッフ報酬計算（物件単価または時給）。 非機能・将来!B11 D-15未決。既存支払機能を撤去しない。

テストケース（T-01〜T-40、全件未実施）

添付結果欄は40件すべて「未実施」。以下は入力転記と要求対応で、合格証拠を示さない。実施日・実施者・備考の原セルは全件空欄。

TC 元要件ID 対応FR 前提 操作 期待結果 結果・実施記録 出典セル A:I
T-01 PRP-01 FR-001 管理者でログインしている 物件を全項目入力して保存し、再度開く 入力した値がすべて保存されている。無効化した物件は予約取得・通知の対象から外れる 未実施; 実施日—; 実施者—; 備考— テストケース!A5, テストケース!B5, テストケース!C5, テストケース!D5, テストケース!E5, テストケース!F5, テストケース!G5, テストケース!H5, テストケース!I5
T-02 PRP-02 FR-002 物件にマニュアルURLが登録され、スタッフAが担当 スタッフAがタスク画面でマニュアルを開く 登録したURLが開く 未実施; 実施日—; 実施者—; 備考— テストケース!A6, テストケース!B6, テストケース!C6, テストケース!D6, テストケース!E6, テストケース!F6, テストケース!G6, テストケース!H6, テストケース!I6
T-03 PRP-03, NTF-01 FR-003, FR-022 物件XはスタッフA・Bの担当、Cは担当外 物件Xに新規予約を入れる A・BにLINE通知が届き、Cには届かない。Cの画面にそのタスクは出ない 未実施; 実施日—; 実施者—; 備考— テストケース!A7, テストケース!B7, テストケース!C7, テストケース!D7, テストケース!E7, テストケース!F7, テストケース!G7, テストケース!H7, テストケース!I7
T-04 SYN-03 FR-007 物件がiCal連携 iCalに 10/10 IN・10/12 OUT の予約を追加し、取得を実行 清掃日10/12のタスクが1件、確認中で作成される 未実施; 実施日—; 実施者—; 備考— テストケース!A8, テストケース!B8, テストケース!C8, テストケース!D8, テストケース!E8, テストケース!F8, テストケース!G8, テストケース!H8, テストケース!I8
T-05 SYN-03 FR-007 物件がBeds24連携 Beds24に予約を作成し、取得を実行 T-04と同じ結果になる 未実施; 実施日—; 実施者—; 備考— テストケース!A9, テストケース!B9, テストケース!C9, テストケース!D9, テストケース!E9, テストケース!F9, テストケース!G9, テストケース!H9, テストケース!I9
T-06 SYN-03 FR-007 T-04のタスクが作成済み もう一度取得を実行する タスクは1件のまま増えない 未実施; 実施日—; 実施者—; 備考— テストケース!A10, テストケース!B10, テストケース!C10, テストケース!D10, テストケース!E10, テストケース!F10, テストケース!G10, テストケース!H10, テストケース!I10
T-07 SYN-04 FR-008 確認中のタスクがある 元の予約をキャンセルし、取得を実行 タスクが取消になり、未割当アラートが消える 未実施; 実施日—; 実施者—; 備考— テストケース!A11, テストケース!B11, テストケース!C11, テストケース!D11, テストケース!E11, テストケース!F11, テストケース!G11, テストケース!H11, テストケース!I11
T-08 SYN-04 FR-008 確定済み（担当A）のタスクがある 元の予約をキャンセルし、取得を実行 取消になり、Aと管理者に通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A12, テストケース!B12, テストケース!C12, テストケース!D12, テストケース!E12, テストケース!F12, テストケース!G12, テストケース!H12, テストケース!I12
T-09 SYN-05 FR-009 確定済み（担当A）のタスクがある 予約のチェックアウトを1日後ろにずらし、取得を実行 清掃日が1日後ろに変わり、担当はAのまま。Aと管理者に通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A13, テストケース!B13, テストケース!C13, テストケース!D13, テストケース!E13, テストケース!F13, テストケース!G13, テストケース!H13, テストケース!I13
T-10 SYN-06 FR-010 iCal連携の物件 オーナー利用のブロックを入れ、取得を実行 タスクは作成されない 未実施; 実施日—; 実施者—; 備考— テストケース!A14, テストケース!B14, テストケース!C14, テストケース!D14, テストケース!E14, テストケース!F14, テストケース!G14, テストケース!H14, テストケース!I14
T-11 SYN-07 FR-011 iCal URLを無効なものに変更 取得を3回実行 管理者画面にその物件の取得エラー警告が出る 未実施; 実施日—; 実施者—; 備考— テストケース!A15, テストケース!B15, テストケース!C15, テストケース!D15, テストケース!E15, テストケース!F15, テストケース!G15, テストケース!H15, テストケース!I15
T-12 ADM-03, SYN-08 FR-015, FR-012 タスクを今日検知した 管理者一覧を開く そのタスクが濃い青の背景で表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A16, テストケース!B16, テストケース!C16, テストケース!D16, テストケース!E16, テストケース!F16, テストケース!G16, テストケース!H16, テストケース!I16
T-13 ADM-03 FR-015 検知から7日と1分たったタスク（検知日時をテストデータで調整） 管理者一覧を開く 通常の背景色で表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A17, テストケース!B17, テストケース!C17, テストケース!D17, テストケース!E17, テストケース!F17, テストケース!G17, テストケース!H17, テストケース!I17
T-14 ADM-04 FR-016 確認中のタスクがある 管理者一覧を開く 赤枠で表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A18, テストケース!B18, テストケース!C18, テストケース!D18, テストケース!E18, テストケース!F18, テストケース!G18, テストケース!H18, テストケース!I18
T-15 ADM-05, NTF-03 FR-017, FR-024 通知から24時間たった確認中のタスク 管理者一覧を開く 太い赤枠＋赤背景＋「24h超」ラベルで最上部に出る。管理者にLINE通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A19, テストケース!B19, テストケース!C19, テストケース!D19, テストケース!E19, テストケース!F19, テストケース!G19, テストケース!H19, テストケース!I19
T-16 ADM-05 FR-017 通知から23時間59分の確認中タスク 管理者一覧を開く 赤枠のみ（24h超の強調はまだ出ない） 未実施; 実施日—; 実施者—; 備考— テストケース!A20, テストケース!B20, テストケース!C20, テストケース!D20, テストケース!E20, テストケース!F20, テストケース!G20, テストケース!H20, テストケース!I20
T-17 ADM-03, ADM-04 FR-015, FR-016 今日検知して未割当のタスク 管理者一覧を開く 青背景と赤枠が両方表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A21, テストケース!B21, テストケース!C21, テストケース!D21, テストケース!E21, テストケース!F21, テストケース!G21, テストケース!H21, テストケース!I21
T-18 ANS-03, NTF-02 FR-030, FR-023 担当A・Bに通知済みの確認中タスク Aが ◯ を押す タスクが確定（担当A）になる。Aに確定通知、Bに締め切り通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A22, テストケース!B22, テストケース!C22, テストケース!D22, テストケース!E22, テストケース!F22, テストケース!G22, テストケース!H22, テストケース!I22
T-19 ANS-03 FR-030 T-18の続き Bが回答画面を開く 「締切済み」と表示され、どの回答も押せない 未実施; 実施日—; 実施者—; 備考— テストケース!A23, テストケース!B23, テストケース!C23, テストケース!D23, テストケース!E23, テストケース!F23, テストケース!G23, テストケース!H23, テストケース!I23
T-20 ANS-04 FR-031 担当A・Bに通知済みの確認中タスク A・Bが1秒以内に続けて ◯ を押す 確定は1人だけ。もう1人には「他のスタッフで確定しました」と表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A24, テストケース!B24, テストケース!C24, テストケース!D24, テストケース!E24, テストケース!F24, テストケース!G24, テストケース!H24, テストケース!I24
T-21 ANS-01, ADM-06 FR-028, FR-018 確認中タスク Aが × を押す ステータスは確認中のまま。管理者のタスク詳細でAが × と回答日時付きで見える 未実施; 実施日—; 実施者—; 備考— テストケース!A25, テストケース!B25, テストケース!C25, テストケース!D25, テストケース!E25, テストケース!F25, テストケース!G25, テストケース!H25, テストケース!I25
T-22 ANS-05, ANS-06 FR-032, FR-033 確認中タスク Aが 保留 を押し、あとで ◯ に変更する 保留の間は管理者画面に「保留」と出て、24時間の期限は進む。◯ に変えた時点で確定する 未実施; 実施日—; 実施者—; 備考— テストケース!A26, テストケース!B26, テストケース!C26, テストケース!D26, テストケース!E26, テストケース!F26, テストケース!G26, テストケース!H26, テストケース!I26
T-23 ANS-05 FR-032 Aが × と回答済み Aが回答を変更しようとする 変更できない（ボタンが押せない） 未実施; 実施日—; 実施者—; 備考— テストケース!A27, テストケース!B27, テストケース!C27, テストケース!D27, テストケース!E27, テストケース!F27, テストケース!G27, テストケース!H27, テストケース!I27
T-24 ANS-07 FR-034 確認中タスク Aが「翌日なら可」を押す 自動確定されず、確認中・赤枠のまま。管理者詳細に「翌日なら可」と出る 未実施; 実施日—; 実施者—; 備考— テストケース!A28, テストケース!B28, テストケース!C28, テストケース!D28, テストケース!E28, テストケース!F28, テストケース!G28, テストケース!H28, テストケース!I28
T-25 ADM-07 FR-019 A・Bとも未回答の確認中タスク 管理者がCを割り当てる 回答なしで確定（担当C）になり、Cに通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A29, テストケース!B29, テストケース!C29, テストケース!D29, テストケース!E29, テストケース!F29, テストケース!G29, テストケース!H29, テストケース!I29
T-26 ADM-08 FR-020 確定（担当A）のタスク 管理者が担当をBに変更する 担当がBになり、AとBの両方に通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A30, テストケース!B30, テストケース!C30, テストケース!D30, テストケース!E30, テストケース!F30, テストケース!G30, テストケース!H30, テストケース!I30
T-27 ALT-01 FR-035 10/12 OUTのタスクでAが「翌日なら可」 管理者がAを翌日で割り当てる 確定（担当A）、清掃日が10/13になる 未実施; 実施日—; 実施者—; 備考— テストケース!A31, テストケース!B31, テストケース!C31, テストケース!D31, テストケース!E31, テストケース!F31, テストケース!G31, テストケース!H31, テストケース!I31
T-28 ALT-02, NTF-04 FR-036, FR-025 T-27の状態 同じ物件に 10/12 IN の予約を追加し、取得を実行 ステータスが要調整になり、赤枠で表示される。管理者に通知、Aに「日程調整中」通知が届く 未実施; 実施日—; 実施者—; 備考— テストケース!A32, テストケース!B32, テストケース!C32, テストケース!D32, テストケース!E32, テストケース!F32, テストケース!G32, テストケース!H32, テストケース!I32
T-29 ALT-03 FR-037 10/12 OUT と 10/12 IN の連続予約がある物件 管理者が「翌日なら可」のスタッフを割り当てようとする 警告が出て、確認するまで割り当てられない 未実施; 実施日—; 実施者—; 備考— テストケース!A33, テストケース!B33, テストケース!C33, テストケース!D33, テストケース!E33, テストケース!F33, テストケース!G33, テストケース!H33, テストケース!I33
T-30 WRK-01 FR-038 確定（担当A）、清掃日が今日 Aが開始を押す 清掃中になり、開始時刻が記録される 未実施; 実施日—; 実施者—; 備考— テストケース!A34, テストケース!B34, テストケース!C34, テストケース!D34, テストケース!E34, テストケース!F34, テストケース!G34, テストケース!H34, テストケース!I34
T-31 WRK-01 FR-038 確定（担当A）、清掃日が明日 Aが開始を押す／Bが同じタスクを開く Aは押せない（当日のみ）。Bには開始ボタンが出ない 未実施; 実施日—; 実施者—; 備考— テストケース!A35, テストケース!B35, テストケース!C35, テストケース!D35, テストケース!E35, テストケース!F35, テストケース!G35, テストケース!H35, テストケース!I35
T-32 WRK-02 FR-039 清掃中のタスク 写真0枚で完了を押す 完了できず、写真が必要と表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A36, テストケース!B36, テストケース!C36, テストケース!D36, テストケース!E36, テストケース!F36, テストケース!G36, テストケース!H36, テストケース!I36
T-33 WRK-02, WRK-03, NTF-05 FR-039, FR-040, FR-026 清掃中のタスク 写真3枚とコメントを付けて完了を押す 完了になり、管理者とオーナーに通知が届く。報告に写真3枚とコメントが付いている 未実施; 実施日—; 実施者—; 備考— テストケース!A37, テストケース!B37, テストケース!C37, テストケース!D37, テストケース!E37, テストケース!F37, テストケース!G37, テストケース!H37, テストケース!I37
T-34 WRK-04 FR-041 完了から1時間のタスク Aが写真を1枚追加する 追加できる。25時間後には追加ボタンが出ない 未実施; 実施日—; 実施者—; 備考— テストケース!A38, テストケース!B38, テストケース!C38, テストケース!D38, テストケース!E38, テストケース!F38, テストケース!G38, テストケース!H38, テストケース!I38
T-35 OWN-01, OWN-04 FR-042, FR-045 オーナーPは物件X、オーナーQは物件Yを所有 PのURLで開く 物件Xだけが見え、Yは見えない。編集ボタンは一つもない 未実施; 実施日—; 実施者—; 備考— テストケース!A39, テストケース!B39, テストケース!C39, テストケース!D39, テストケース!E39, テストケース!F39, テストケース!G39, テストケース!H39, テストケース!I39
T-36 OWN-02 FR-043 物件Xに完了タスクがある オーナーPが完了報告を開く 写真・コメント・開始／完了時刻が見える 未実施; 実施日—; 実施者—; 備考— テストケース!A40, テストケース!B40, テストケース!C40, テストケース!D40, テストケース!E40, テストケース!F40, テストケース!G40, テストケース!H40, テストケース!I40
T-37 OWN-03 FR-044 物件Xに確定タスクがある オーナーPが清掃予定を開く ゲスト名・連絡先・担当スタッフ名が表示されない 未実施; 実施日—; 実施者—; 備考— テストケース!A41, テストケース!B41, テストケース!C41, テストケース!D41, テストケース!E41, テストケース!F41, テストケース!G41, テストケース!H41, テストケース!I41
T-38 ATT-01, ATT-02 FR-046, FR-047 Aが今月3件完了している 管理者が勤怠画面でAの今月を開き、CSVを出力 件数3件と合計時間が表示され、CSVにも同じ内容が出る 未実施; 実施日—; 実施者—; 備考— テストケース!A42, テストケース!B42, テストケース!C42, テストケース!D42, テストケース!E42, テストケース!F42, テストケース!G42, テストケース!H42, テストケース!I42
T-39 ADM-09 FR-021 完了済みタスク 管理者が開始時刻を修正する 勤怠の時間が変わり、修正前の値と修正者が履歴に残る 未実施; 実施日—; 実施者—; 備考— テストケース!A43, テストケース!B43, テストケース!C43, テストケース!D43, テストケース!E43, テストケース!F43, テストケース!G43, テストケース!H43, テストケース!I43
T-40 PRP-03 FR-003 担当スタッフが0人の物件 その物件に新規予約を入れる 誰にも通知されず、タスクは作成時点から赤枠で表示される 未実施; 実施日—; 実施者—; 備考— テストケース!A44, テストケース!B44, テストケース!C44, テストケース!D44, テストケース!E44, テストケース!F44, テストケース!G44, テストケース!H44, テストケース!I44

Sources

Clarifications Log

本作成時点で人の回答なし。D-01〜D-15および人の業務判断を要するQは未承認。Q-23/Q-25は実装調査、Q-26は任意資料。9/28 00:02会話要約は方向性の参考で、後発00:18版xlsxの未決を覆さない。修正時は日付付きで追記する。