HospitaLink RequirementsIndexへ戻る
要件定義から単体テストまで、提案範囲を明確にする。
導入診断の後に、何を作るか、どこまで自動化するか、誰が承認するか、何をもって完了とするかを整理するための要件定義ページです。
範囲予約 / 返信 / 清掃 / 価格 / CRM / 帳票
成果物要件定義書 / 基本設計 / テスト観点
確認点個人情報 / 価格反映 / 外部送信 / 権限
完了条件受入基準と人間承認ポイントの合意
導入フェーズ
HospitaLinkは「作って終わり」ではなく、診断から運用改善までを分けて合意します。
01現状診断
使用SaaS、業務フロー、台帳、Slack、現場判断、個人情報の流れを棚卸し。
02要件定義
対象業務、除外範囲、承認条件、データ項目、通知先、KPIを定義。
03基本設計
Slack構成、データ構造、権限、ログ、エラー時の手順を設計。
04単体テスト
通知、承認、CSV、フォーム、帳票、マスキングを小さく検証。
05受入テスト
実運用に近いケースで、現場担当が見て判断できるかを確認。
06運用開始
初期SOP、担当者、障害時連絡、月次レビューの進め方を固定。
07改善運用
レビュー、売上、対応時間、CRM反応を見てルールを更新。
08追加開発判断
API、Web承認、宿泊税、請求書、CRMなどを追加見積へ分ける。
要件定義で決めること
領域
決める内容
受入基準
業務範囲
予約通知、ゲスト返信、清掃、価格、帳票、CRMのどこまで含めるか。
対象外業務が明記され、見積とスケジュールに反映されている。
データ
施設ID、予約ID、宿泊者名簿、価格、レビュー、配信同意などの項目。
個人情報は最小化され、Slackには必要情報だけ出る。
承認
価格、返金、鍵、クレーム、配信、外部送信の停止条件。
自動処理と人間確認の境界がテストケースで確認できる。
権限
管理者、現場、清掃、外部委託先、閲覧のみの権限。
不要な個人情報や価格判断を見せない構成になっている。
テスト
正常系、例外系、エラー、未入力、重複、削除、配信停止。
単体テスト表と受入チェックが残っている。
初回ヒアリング項目
商談で聞いた内容を、要件定義にそのまま流し込める形にします。個人情報や価格反映に関わる項目は、必ず「未確認」として残せるようにします。
施設・販売
- 施設数、部屋数、地域、宿タイプ
- Airbnb / Booking.com / 楽天 / 一休 / 自社予約の利用状況
- 価格更新の頻度、最低宿泊数、キャンセル条件
- 繁忙期、閑散期、地域イベント、直前予約の比率
現場・清掃
- 清掃担当、自社/外注、写真確認の有無
- 忘れ物、修繕、備品、宿直連絡の流れ
- 清掃遅延・未完了時の通知先
- 現場が見ている連絡手段と時間帯
ゲスト対応
- 問い合わせの多い内容、返信テンプレの有無
- クレーム、返金、鍵、事故、近隣苦情の停止条件
- 多言語対応と人間確認の必要範囲
- レビュー依頼、改善案、CRMへの接続
帳票・税務
- 領収証、請求書、インボイスの発行方法
- 宿泊者名簿の電子管理状況
- 地方別宿泊税の算出・徴収・集計
- 国税庁対応や証憑保存の現状
データ・権限
- 誰が何を見てよいか
- Slackに出してよい情報、出してはいけない情報
- 保存期間、削除、退職/解約時の扱い
- 管理者、現場、外注先の権限差
グロース/CRM
- 直予約導線、LINE/メール、Google導線
- 配信同意、配信停止、再訪候補の管理
- 法人/長期滞在/紹介の見込み管理
- レビューを次の改善と販促に使う流れ
優先度と責任分界
分類
入れるもの
判断基準
Must
予約通知、重要メッセージ停止、価格上限停止、清掃通知、承認ログ。
これがないと運用リスクが下がらない。
Should
AI返信案、地域別テンプレ、レビュー改善ToDo、月次レポート。
現場負荷と改善スピードに効く。
Could
CRM配信、宿泊税自動算出、請求書/領収証、Web承認画面。
見積を分けて追加提案しやすい。
Won't
完全自動返信、無承認の価格反映、個人情報の無期限保存。
リスクが高く、現段階では扱わない。
人間承認
返金、鍵、クレーム、価格大幅変更、外部送信、契約/規約判断。
責任者の判断が必要なものは自動化しない。
RACIのたたき台
業務
主担当
確認/承認
予約・問い合わせ通知
運営担当 / 現場担当
重要メッセージは施設責任者が確認
価格変更
Revenue担当 / 運営責任者
閾値超過、イベント週、返金影響は責任者承認
清掃・点検
清掃担当 / 外注先
未完了、写真不足、備品異常は運営担当へ
CRM/配信
グロース担当
同意管理、配信停止、個人情報は管理者確認
帳票・税務
BackOffice / 運営担当
国税庁対応、宿泊税、請求書要件は専門確認候補
テスト観点
単体テスト
- フォーム入力が保存される
- Slack通知が想定チャンネルに出る
- 必須項目と重複を検知する
- CSV/帳票の文字化けがない
例外テスト
- 価格上限超過で止まる
- クレーム/返金/鍵で人間確認へ回る
- API未接続時に手動運用へ戻せる
- 配信停止者へ送らない
受入テスト
- 現場担当が判断できる画面か
- 通知が多すぎないか
- ログから誰が判断したか追えるか
- 初期SOPで運用できるか
非機能要件
セキュリティ個人情報の最小表示、権限分離、認証情報の非表示、ログの閲覧制限。
可用性外部連携が止まっても、Slack/Sheets/手動確認へ戻せること。
保守性地域変数、通知文、承認条件をコード直書きではなく設定として管理。
監査性誰が、いつ、何を承認/却下/保留したかを追えること。
運用負荷通知が多すぎず、日次5分/週次30分で確認できる画面にすること。
拡張性CRM、帳票、宿泊税、Web承認を後から追加できる構成にすること。
見積に分ける単位
要件定義の出口は、実装範囲を「標準構築」と「追加オプション」に分け、見積前提を曖昧にしないことです。
CORESlack OS
予約、ゲスト対応、清掃、価格の通知と承認。標準構築の中心。
OPS宿泊事業側
清掃SOP、現場レクチャー、開業/運営代行は別商品として整理。
GROWTHCRM・直予約
顧客関係管理、レビュー資産化、LINE/メール、Google導線は追加提案。
BACKOFFICE帳票・宿泊税
領収証、請求書、宿泊者名簿、地方別宿泊税は要件整理後に別見積。
完了条件
要件定義が完了した状態
対象業務、対象外業務、承認条件、データ項目、テスト観点、未確認事項、見積前提が1つの資料にまとまっている。
見積に進める状態
標準構築、追加オプション、専門家確認、月次伴走の区分が分かれ、相手が「何にお金を払うか」を説明できる。
成果物
要件定義メモ対象業務、除外範囲、前提、未確認事項、承認者。
基本設計Slack構成、データ項目、権限、通知、ログ、保守方針。
テスト観点表正常系、例外系、個人情報、配信停止、価格停止、帳票出力。
初期SOP日次確認、週次改善、障害時、解約/削除時の作業手順。
注意: このページは要件整理用です。価格反映、ゲスト返信、個人情報送信、外部共有、契約確定は人間承認後に実施します。