PMS（Property Management System／宿泊施設管理システム）を新規開発したり、既存システムから入れ替えたりするとき、プロジェクトの成否を左右するのが要件定義とRFP（提案依頼書）の質です。宿泊運営は、予約・フロント・客室・清掃・会計・各OTA連携・スマートロックといった多数の業務とシステムが鎖のように連なって回っています。この複雑な業務を曖昧なまま発注すると、出来上がったPMSが現場の運用と噛み合わず、誰も使わないシステムになってしまいます。RFPは、自施設の業務をベンダーへ正確に伝え、適切な見積りと提案を引き出すための設計図です。
本記事は、PMS開発・導入の要件定義書とRFPの作り方を、発注側の視点から実務的に解説する「要件定義特化」の解説です。現状業務（AsIs）の可視化からあるべき姿（ToBe）の設計、宿泊業特有の在庫一元化・名簿・連携の要件化、ハードウェアや工事費を含む費用範囲の明記、稼働率や対応時間といった非機能要件、そしてRFPに盛り込むべき必須項目と見積り妥当性の判断軸までを順に整理します。なお、PMS導入の全体像をまだ把握していない方は、まずPMSの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・PMSの完全ガイド
宿泊業務を要件に落とすAsIs可視化とToBe設計
要件定義の出発点は、機能の一覧づくりではなく、自施設が今どう運営されているか（AsIs）を可視化することです。予約がどのチャネルから入り、誰がどう客室を割り当て、清掃をどう回し、会計をどう締めているか。この現状フローを正確に描かないまま理想だけでシステムを設計すると、現場の実務と乖離したPMSになります。AsIsの徹底こそが、現場に使われるPMSの土台です。
フロント・清掃・予約の現状フローを可視化するヒアリング
AsIs可視化では、フロント、清掃、予約管理、会計の各担当者に、日々の業務を具体的にヒアリングします。「どのOTAから何件くらい予約が入るか」「電話予約をどう台帳に書いているか」「オーバーブッキングが起きたとき誰がどう対応するか」「清掃の段取りを誰がどう指示するか」といった、現場の生々しい手順を洗い出します。とくに、システム化されておらず人の経験や口頭連絡で回っている工程ほど、要件定義で見落とされやすく、リリース後の手戻りの原因になります。
ヒアリングでは、担当者ごとに見えている景色が違う点にも注意が必要です。フロントは予約とチェックインの流れを、清掃は客室の回転を、経理は売上と入金の締めを中心に語るため、それぞれの視点を突き合わせて初めて業務の全体像が立ち上がります。部門をまたぐ引き継ぎの瞬間（チェックアウトから清掃へ、清掃から販売再開へ）に、情報の断絶やミスが潜んでいることが多く、ここを丁寧に拾うことが、現場に効く要件定義の質を決めます。
このヒアリングでは、各工程の所要時間や発生頻度、ミスの起きやすいポイントも記録します。たとえば各OTAの在庫調整に1日どれだけ時間を割いているか、ノーショーが月に何件あるかといった数字は、後でROIを試算する根拠になります。AsIsを定量的に可視化しておくと、ToBe設計で「どの工程を自動化すれば効果が大きいか」を優先順位づけでき、限られた予算を最も効く部分に集中投下できます。
ToBeモデルで「あるべき宿泊オペレーション」を設計する
AsIsを可視化したら、次はあるべき姿（ToBe）を描きます。ToBe設計では、現状の業務をそのままシステム化するのではなく、「どの工程を自動化し、どの工程を統合し、どの作業をなくすか」という業務改善の視点で再設計します。たとえば、各OTAの在庫を手作業で調整している現状に対して、サイトコントローラー連携で在庫を一元同期するToBeを描けば、その作業自体を消せます。要件定義は、現状の追認ではなく業務変革の機会です。
ToBeを描くときに注意すべきは、現場が無理なく移行できる現実的な姿にすることです。理想を追い求めすぎて現場の運用能力を超えたToBeを設計すると、結局は使われません。フロントの人員体制、スタッフのITリテラシー、繁忙期の負荷を踏まえ、段階的に到達できるToBeを描くことが大切です。riplaはフルスクラッチ受託の立場から、AsIsの徹底ヒアリングと、現場が定着できるToBe設計を要件定義の核に据えています。AsIsとToBeの差分こそが、PMSに実装すべき要件の正体です。
対象範囲と優先順位を要件として明確にする
AsIsとToBeを描いたら、今回のプロジェクトでどこまでを対象範囲（スコープ）とするかを要件として明確にします。予約・フロント・客室管理・清掃・会計・各種連携のうち、第一フェーズで実装する範囲と、将来フェーズに回す範囲を切り分けるのです。すべてを一度に作ろうとすると、開発が長期化・高額化し、リリース前に要件が陳腐化するリスクが高まります。スコープを明確にすることが、現実的な予算と期間でPMSを稼働させる前提になります。
優先順位づけでは、機能を「必須（これがないと業務が回らない）」「優先（効果が大きく早期に欲しい）」「将来（あると便利だが後回し可能）」の三段階に分類すると整理しやすくなります。たとえば在庫一元化と宿泊者名簿は必須、レベニューマネジメントは優先、CRM連携は将来、といった具合です。この優先順位を要件定義書に明記しておくと、開発の途中で予算や期間の制約が生じても、何を残し何を削るかの判断がぶれません。スコープと優先順位の明確化は、要件定義の実務で最も実利のある作業です。
宿泊業特有の要件（在庫・名簿・連携・ハード）の整理
AsIsとToBeを描いたら、それを宿泊業特有の要件として具体化します。PMSの要件定義が一般的なシステムと異なるのは、在庫の一元同期、法令対応の名簿管理、多数の外部連携、そしてスマートロックなどのハードウェアまで要件範囲に含む点です。これらを漏れなくRFPに書き込むことが、適切な見積りと手戻りのない開発につながります。
在庫一元化・宿泊者名簿・多言語の要件化
在庫一元化の要件では、連携するOTAやサイトコントローラーを具体的に列挙し、在庫・料金・販売停止をどの粒度で、どれくらいのリアルタイム性で同期するかを定めます。「在庫はリアルタイム同期、料金は1日数回更新」など、許容できる更新頻度を明記しないと、ベンダー間で前提がずれ、見積りの比較ができなくなります。宿泊者名簿の要件では、旅館業法が求める記録項目、外国人の旅券番号・国籍の記録と本人確認の方式、保存期間と出力形式を要件化します。
インバウンド対応を重視する施設では、多言語UIの対応言語、海外決済（WeChat Pay・Alipayなど）への対応、さらに高齢のゲストにも使いやすいユニバーサルデザイン（UD）の配慮を要件に含めます。これらは予約・受付分野で競合が深掘りできていない領域であり、要件として明確に言語化しておくことで、現場で本当に使えるPMSへ近づきます。曖昧に「多言語対応」とだけ書くのではなく、対象言語と画面範囲まで踏み込んで要件化することが大切です。
連携の責任分界とハード・工事費を含む要件化
PMSの要件定義で見落とされがちなのが、外部連携の責任分界とハードウェア・工事費です。スマートロック、決済、サイトコントローラー、会計といった複数システムを連携させる場合、連携後にトラブルが起きたとき「どちらのシステムが原因か」の切り分けと、その復旧責任を誰が負うかを契約で定めておく必要があります。この責任分界を曖昧にすると、障害発生時にベンダー同士が責任を押し付け合い、施設だけが復旧の負担を負う事態になりかねません。
また、無人チェックインを実現するスマートロックや自動チェックイン機（キオスク端末）は、機器本体だけでなく、設置・配線・常時給電といった物理工事費が発生します。タブレット端末の盗難防止対策も含め、ハードウェアと工事を要件範囲に明記しないと、ソフトだけの見積りで予算を組み、後から想定外の設備投資が膨らみます。CRMや独自連携は初期20万〜100万円以上かかる場合もあるとされ（予約・受付分野の費用データ）、連携ごとの費用を要件段階で把握しておくことが、現実的な予算編成につながります。
非機能要件（稼働率・セキュリティ・サポート）の定義
機能要件と並んで重要なのが、性能・セキュリティ・可用性・サポートといった非機能要件です。PMSは24時間365日、ゲストの予約とチェックインを受け続ける施設の生命線であり、止まれば即座に営業に影響します。非機能要件を疎かにすると、繁忙期にシステムが落ちて予約が受けられない、といった致命的な事態を招きます。
稼働率・障害時対応・SLAの要件化
可用性の要件では、目標稼働率（たとえば99.9%以上）と、障害発生時の連絡体制・復旧目標時間を定めます。深夜にチェックインしようとしたゲストがシステム障害で入室できない、という事態は宿泊業では致命的です。とくに無人運用の施設では、24時間の障害対応窓口があるか、夜間にスマートロックが開かなくなったときの代替手段（緊急連絡先や物理鍵のバックアップ）をどう確保するかを、SLA（サービス品質保証）として要件化しておく必要があります。
サポート体制の要件では、問い合わせの対応時間帯、対応言語、繁忙期の優先対応の有無を確認します。連携を多用するPMSでは、前述の責任分界とあわせて「障害の一次受付をどのベンダーが担うか」を決めておくと、トラブル時の初動が速くなります。SLAは契約書に紐づく重要な要件であり、提案各社の対応水準を横並びで比較できるよう、RFPの段階で具体的な数値と条件を提示することが望まれます。
個人情報・決済セキュリティと認証の要件
セキュリティの要件では、宿泊者名簿という機微な個人情報や、クレジットカード決済を扱うことを踏まえた対策を定めます。通信の暗号化、アクセス権限の管理、決済情報を自社で保持しない設計（決済代行への委譲）、個人情報の保存期間と廃棄ルールを要件化します。とくに外国人ゲストの旅券情報を扱う以上、情報漏えいは施設の信用を大きく毀損するため、セキュリティは妥協できない非機能要件です。なお、繁忙期の同時アクセスに耐える性能要件（ピーク時の予約処理性能やレスポンス速度）も、稼働率と並んで明記しておくべき項目です。
ベンダー選定の観点では、ISMS（情報セキュリティマネジメントシステム）認証の取得状況や、過去のセキュリティ対応実績を確認すると安心です。クラウド型PMSを選ぶ場合は、データの保管場所、バックアップ体制、災害時の事業継続計画もあわせて要件化します。これらの非機能要件をRFPに明記することで、機能の見た目だけでなく、長期に安心して使えるPMSかどうかを見極められます。非機能要件は地味ですが、施設を守る最後の砦だと理解しておくことが大切です。
RFPの必須項目と見積りの妥当性を判断する軸
要件を整理したら、それをRFP（提案依頼書）という文書にまとめ、複数ベンダーから提案と見積りを引き出します。RFPの完成度が、提案の質と見積り精度を左右します。必要な項目が抜けたRFPでは、各社が前提を勝手に補完してしまい、見積りを横並びで比較できなくなります。
RFPに必ず盛り込むべき項目
PMSのRFPに最低限盛り込むべき項目は、プロジェクトの背景と目的、施設の概要（客室数・業態・OTA構成・インバウンド比率）、対象業務の範囲、機能要件（必須・優先・将来の分類つき）、連携要件と責任分界、ハード・工事の範囲、非機能要件（稼働率・セキュリティ・SLA）、想定スケジュール、予算感、そして提案してほしい体制図と保守内容です。とくに連携先とハードの範囲は、見積りのブレが大きい領域なので、具体的に列挙します。
RFPには、データ移行や既存システムからの切り替え方法、繁忙期を避けた稼働開始時期、現場スタッフへのトレーニング支援も明記しておくと、提案の網羅性が上がります。これらを書き込むことで、ベンダーは「言われていなかった」という後出しの追加費用を出しにくくなり、発注側の予算管理が安定します。RFPは単なる発注書ではなく、プロジェクト全体の前提をベンダーと共有する合意文書だと位置づけることが大切です。
RFPを配布する際は、評価基準と選定スケジュールもあわせて提示すると、各社が要点を押さえた提案をしやすくなります。価格・機能適合度・実績・保守体制・宿泊業の理解度といった評価軸を事前に共有しておけば、提案の比較がしやすく、社内の合意形成もスムーズになります。質問受付期間を設けてベンダーからの問い合わせに回答することで、前提のズレをさらに減らせます。丁寧なRFPプロセスは、結果として手戻りの少ない開発と、納得感のあるベンダー選定をもたらします。
見積りの妥当性を判断する軸
複数社から提案が集まったら、見積りの妥当性を判断します。判断の軸は、金額の総額だけでなく、その内訳が要件と対応しているか、保守・運用の継続費用が現実的か、ハードと工事が含まれているか、データ移行や追加連携といった隠れコストが見込まれているかです。極端に安い見積りは、要件の一部が抜けている可能性があり、後から追加費用で膨らむ危険があります。逆に高い見積りも、何にコストがかかっているかを説明できなければ妥当とは言えません。
とくに注意したいのが、初期費用だけでなくランニングコストです。クラウド型PMSは月額課金が続き、利用アカウント数や客室数に応じた従量課金、各種連携の月額利用料、決済手数料、SMS送信料などが積み上がります。初期が安くても運用費が高いと、数年スパンの総保有コスト（TCO）では逆転することがあります。riplaはフルスクラッチ受託の立場から、要件と見積りの突き合わせ、隠れコストの洗い出し、TCOでの比較といった、発注側に立った妥当性判断を支援しています。RFPと見積り精査の丁寧さが、PMS導入の失敗を未然に防ぎます。
体制図と保守内容で開発力を見抜く
見積り金額の妥当性とあわせて確認したいのが、提案されたプロジェクト体制と保守内容です。RFPで体制図の提出を求め、誰がプロジェクトを管理（PM）し、どの工程を自社で開発し、どの部分を再委託するのかを把握します。営業担当のプレゼンが巧みでも、実際の開発を担う体制が手薄だったり、宿泊業の業務理解が乏しかったりすると、リリース後に障害が多発するリスクがあります。可能であれば、提案段階でPMや主要な開発担当と直接面談し、宿泊業務への理解度を確かめるとよいでしょう。
保守内容の確認も欠かせません。リリース後の障害対応、機能追加、各OTAの仕様変更への追従、繁忙期のサポート体制が、保守契約にどこまで含まれるかを要件として明確にします。宿泊業は各OTAの仕様変更が頻繁に起こるため、それへの追従が保守に含まれていないと、その都度の追加費用が発生します。開発力と保守体制を見抜くことは、稼働後に長く安心して使えるPMSかどうかを見極める、要件定義とRFPの最終関門です。
まとめ
PMSの要件定義とRFPは、現状業務（AsIs）の徹底可視化から始まり、あるべき姿（ToBe）の設計、宿泊業特有の在庫一元化・名簿・多言語・連携・ハードの要件化、稼働率やセキュリティといった非機能要件の定義、そしてRFPの必須項目と見積り妥当性の判断軸までが一連の流れになります。とりわけ、外部連携の責任分界とハード・工事費を要件範囲に含めること、初期費用だけでなくTCOで見積りを評価することが、宿泊PMS特有の要点です。
要件定義で大切なのは、機能の一覧を集めることではなく、現場の業務から逆算してToBeを描き、それを漏れなくRFPに言語化することです。曖昧な要件は、見積りのブレと導入後の手戻りを招きます。riplaはフルスクラッチ受託と国内開発を組み合わせ、AsIsヒアリングからToBe設計、RFP作成、見積り精査までを発注側の立場で一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。