受付システムのRFP/要件定義書/提案依頼書について

受付システムのRFP(提案依頼書)や要件定義書は、業務フローを描くところから始めて、ハードと工事、外部連携の順に整理すると、現場で使えるシステムにつながります。

加えて、次の二つも要件として書いておきます。

  • 非機能要件:稼働率や応答速度など、システムの品質基準
  • 選定と移行:ベンダー選定の基準と、導入後の移行計画

各段階でRFPに何を書いておくかを、業務フローから順に見ていきます。全体像は受付システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・受付システムの完全ガイド

要件定義の出発点となる業務フローの可視化

受付システムの要件定義は、現状の受付業務を見える形にするところから始めます。機能を並べる前に、誰が、いつ、どんな来訪者を、どう受け付けているかを洗い出します。

システムで置き換える作業と、残す例外対応を分けるには、現場の業務フローが欠かせません。また、RFPの説得力は、業務フローをどれだけ精緻に描けるかで決まります。

AsIs(現状)とToBe(あるべき姿)の整理

現状の業務フロー(AsIs)と、システム導入後の姿(ToBe)を並べて比べます。両方の流れを描いておくと、どこまでを自動化するのかがはっきりします。

たとえば、現状は、来訪者が受付で声をかけ、担当者が内線で取り次ぎ、応接室を確保してから迎えに行く流れです。ToBeでは、来訪者がタブレットで受け付け、担当者にチャットで通知が届いてから、担当者が直接迎えに行きます。

AsIsの整理では、定型業務に加えて例外パターンも漏れなく拾います。例外をRFPに明記しないと、ベンダーは標準ケースだけだと解釈し、リリース後に手戻りが起きることがあります。

  • 飛び込み来訪:アポイントのない来訪者への受付方法
  • 複数人の来訪:一度に複数人が来た場合の受付方法
  • 配送業者・緊急時:それぞれの対応方法

現場ヒアリングで例外まで洗い出すことが、使われる受付システムへの第一歩です。

対象範囲(スコープ)と目的・KPIの明文化

RFPの冒頭では、導入目的とプロジェクトの対象範囲をはっきり書いておきます。目的が曖昧なまま機能を並べると、提案がちぐはぐになります。

  • 人件費削減:受付の無人化
  • 予約対応:内見予約の取りこぼし防止
  • 来訪者体験:インバウンド来訪者の受付体験の向上

達成したいKPI(指標)は、具体的な数字で示すのが効果的です。たとえば、受付担当2名分にあたる年約576万円相当の人件費削減や、無断キャンセル30%以上の削減を目標にします。

スコープでは、予約機能や入退室管理を含めるかどうか、既存システムとどこまで連携するかを明記します。目的・KPI・対象範囲をRFPの中心に置くと、ベンダーは目的に沿った機能を提案しやすくなります。

ポイント

迷ったときは、例外パターンまで現場の担当者と確認できているかを基準にします。現状と導入後の流れを両方描けていれば、自動化する範囲も見極めやすくなります。

ハードウェアと設置工事を含むRFPの作り方

受付端末、周辺機器、入退室設備、監視機器の4種類を並べたハード要件の図解
機器の種類をそろえて書き出すと、調達漏れを見つけやすくなります。

受付システムのRFPには、ソフトウェア以外の機器や物理工事も定義しておきます。タブレットや自動ドアなどと連動するため、どれか一つでも漏れると総コストが大きく変わります。ハード・工事の領域は競合の解説が手薄なだけに、丁寧に要件化する価値があります。

端末・自動ドア・電子錠などのハード要件

必要なハードウェアはRFPに一覧にし、ベンダーが用意するのか、発注者が調達するのかも明記します。分担が曖昧なままだと、後になって対象外だったと分かるおそれがあります。

  • 受付端末:タブレットの台数・機種と設置スタンドの仕様
  • 周辺機器:来訪者証を発行するプリンタ
  • 入退室設備:電子錠やフラッパーゲート
  • 監視機器:無人運用のための監視カメラ

無人で運用する場合は、タブレットの盗難防止策と、常時給電の仕組みも要件に含めます。屋外や半屋外に置くなら、防塵・防水・耐候性の仕様も定める必要があります。

機器は相応の設備投資になります。そのため、総数と仕様を洗い出しておきます。受付システムをソフト料金だけで捉えず、ハードも含めて費用を見ると、後の予算超過を防ぐことにつながります。

設置工事・配線・電源工事の費用要件

ハードウェアの調達と並んで、設置・配線・電源工事の要件も欠かせません。電子錠やフラッパーゲートの設置には配線と電源工事が伴い、自動ドアと連動させる場合は制御盤の改修が必要になることもあります。

これらの工事費は見積もりに含めるよう、RFPで明示して依頼します。工事案件では、図面だけで分からない既存設備や配線ルートの制約を確認しておく必要があります。そのため、現地調査(サイトサーベイ)を選定プロセスに組み込みます。

工事をシステムベンダーが一括で請けるのか、発注者が電気工事業者を手配するのかも決めておきます。ハードと工事を含めたTCO(総保有コスト)で比べると、ソフト料金は安くても工事込みで高くつくケースが見えてきます。

ポイント

機器や工事で迷ったときは、ソフト料金だけでなく、ハードと工事を含めた総コストで比べられるかを基準にします。分担が決まっていない機器や工事は、RFPに書き加えてから見積もりを依頼します。

RFPにおける外部連携と責任分界の定義

CRM連携の初期費用5万〜30万円と独自の連携開発の初期費用20万〜100万円以上を左右で比べた図解
連携方式の違いが、初期費用の見積もり幅にも表れます。

受付システムは、カレンダーやPMSと連携します。さらに、POSや電子カルテ、スマートロックなどとも連携します。

連携内容はRFPで定義し、障害時の責任範囲は契約で定めておきます。連携は便利ですが、障害原因の切り分けは難しいため、契約段階の取り決めが運用時の安心を左右します。

連携先・API仕様・データ項目の要件定義

連携要件では、相手のシステムと、データの方向・内容・頻度を具体的に決めます。連携先のAPIが公開済みか、独自開発が必要かによって、費用は大きく変わります。

  • 予約データ:PMSから15分ごとに受付システムへ取り込む
  • 受付完了情報:入退室管理への即時連携

一次データによれば、CRM連携の初期費用は5万〜30万円です。一方で、独自の連携開発では、初期費用が20万〜100万円以上かかるとされます。

連携先のAPIドキュメントは事前に入手し、技術的に実現できるかをベンダーに確認してもらいます。要望が曖昧なままだと、見積もりが過大になったり、後から追加費用が生じたりします。

連携は、受付システムの費用が膨らみやすい最大の要因です。そのため、要件定義の段階で連携範囲を絞り込みます。

責任分界点と保守体制の取り決め

受付システムそのものが正常でも、PMSやスマートロック側の障害で受付が止まることがあります。原因の切り分けは難しく、責任分界点が曖昧だと、ベンダー間の調整に時間がかかって復旧が遅れるおそれがあります。

RFPには、連携部分の保守担当、一次切り分けの窓口、連携先の更新に伴う追従改修費の負担側を記します。

受付システムのベンダーが連携部分まで一次受けすると、責任を一本化できます。さらに、要件定義の時点で責任分界を決め、契約でも担保しておくことが、現場停止を防ぐ最大の備えです。

バージョンアップ追従と費用負担の取り決め

連携要件では、連携先システムのバージョンアップへの追従が見落とされがちです。PMSやスマートロック、電子カルテなどの仕様やAPIは、提供元の都合で変わることがあります。

変更によって受付システム側の改修が必要になる場合、その費用負担を決めておかないと、トラブルの原因になります。

追従改修が発生する前提で、保守契約の範囲と費用負担をはっきり書いておきます。そのうえで、軽微な追従と大規模な仕様変更の扱いを分けて定めます。

  • 軽微な追従:年に何回まで保守費に含めるかの取り決め
  • 大規模な仕様変更:別途見積もりにするなど、費用負担の取り決め

導入後も、連携先の変化に追従する保守が欠かせません。この前提を要件定義の段階から契約に含めておくと、長期利用への備えになります。

ポイント

連携や責任の範囲で迷ったときは、障害時の一次対応の窓口と、連携先の更新時の費用負担を契約で決めているかを基準にします。

非機能要件・SLA・多言語UD要件の定義

稼働率99.9%、ISMS(ISO 27001)認証、3タップ以内、2秒以内を非機能要件の例として示したハブ図
数値と認証の形にそろえると、品質基準を確認しやすくなります。

機能要件に加えて、非機能要件もRFPで定義します。非機能要件は、稼働率や応答速度など、システムの品質基準を定める要件です。セキュリティや保守体制も、ここに含まれます。

受付は来訪者が最初に触れる接点です。停止すると業務全体に影響するため、品質基準を甘く設定すると、後悔につながりかねません。

稼働率・対応時間SLAとセキュリティ要件

SLA(サービス品質保証)として、稼働率と障害時の対応時間を要件に含めます。受付システムは、氏名や会社名、訪問目的などの個人情報も扱います。

  • 稼働率:99.9%などの目標値
  • 障害対応:復旧までの目標時間
  • サポート時間:無人施設では夜間・休日の対応体制も記す
  • セキュリティ:個人情報の保護方法とISMS(ISO 27001)認証、データ保管場所、アクセス権限

受付が止まれば、来訪者を受け入れられなくなります。だからこそ、上の項目も含めた非機能要件をRFPで示しておくと、機能だけでなく長く使い続けられる品質を担保できます。

多言語・高齢者UD・アクセシビリティ要件

来訪者に合わせて、多言語対応とユニバーサルデザインの要件をRFPに含めます。施設の利用者に応じて、必要な言語や操作の支援を指定しておきます。

  • 多言語対応:英語・中国語・韓国語などの対応言語や海外決済
  • 高齢者・障害者対応:文字拡大、音声ガイド、簡潔な画面遷移

多言語UIや高齢者向けUDは、後から加えると大きな改修になるため、初期のRFPに含めておきます。さらに、競合の解説が手薄な分野のため、ベンダーの対応力を見極める材料にもなります。

誰もが迷わず使える受付を目標にすると、来訪者体験まで含めた提案を引き出せます。要件を網羅したRFPが、選定と開発の設計図になります。

非機能要件は、定量的に測れる形で書きます。たとえば、「使いやすい」と書く代わりに、来訪者が3タップ以内で受付を完了できることを基準にします。

「速い」とだけ書くより、画面遷移を2秒以内と定める方法もあります。曖昧な表現は品質認識のずれを招くため、測定できる基準があると検収が円滑に進みます。

ポイント

品質の基準で迷ったときは、検収時に判定できる数字や操作で書けているかを基準にします。稼働率や応答速度は、検収時に判定できる形にそろえておくと、認識のずれを防げます。

ベンダー選定と移行計画のRFPへの盛り込み

機能・ハード・連携・非機能の要件を固めたら、選定方法と導入後の移行計画もRFPに盛り込みます。先に示しておくと、ベンダーは現実的な日程と体制を提案でき、発注者も比較しやすくなります。

要件定義書は、作成して終わりにせず、ベンダー選定と移行を導く設計図として使います。

選定基準・予算・補助金活用の明記

RFPには選定基準も明記します。評価軸には、機能に加えて、ハードと工事を含めたTCOやサポートを入れます。ISMS認証や類似業種の導入実績も、評価の対象にします。

評価軸を横並びで比べると、価格だけに引きずられた選定を避けられます。さらに、評価の重み付けを事前に決めておくと、社内の合意も得やすくなります。

予算はRFPで開示するか、少なくとも社内で共有しておきます。受付システムの相場は方式や規模によって幅があり、予算によって提案の方向性が変わります。

  • SaaS:初期0〜50万円、月額数千〜数万円
  • 自社開発・小規模:約30万円
  • 自社開発・中〜大規模:300万〜2,000万円以上

IT導入補助金を使う場合は、ベンダーに前提を伝えたうえで、対象ツールと支援事業者かどうかを確認します。補助率は最大1/2〜4/5、通常枠の上限は450万円です。

申請にはgBizID取得などの事前準備が必要です。そのため、要件定義の段階から動き出し、スケジュールに余裕を持たせておきます。

移行計画・データ移行・教育の要件

導入後の移行計画も、RFPで要件として示すべき重要項目です。

  1. 移行対象のデータ項目と変換ルール
  2. テスト移行の実施
  3. 本番切り替えの手順

賃貸管理やPMSのように長年のデータを抱える業態では、移行に失敗すると運用開始直後のトラブルにつながるため、慎重な計画が必要です。

現場の教育と定着の支援も、RFPに盛り込みます。操作研修やマニュアル整備に加えて、移行期間中の併行運用ルールとサポート窓口も要件に含めます。

要件定義の段階で移行や教育まで見据えておくことが、使われる受付システムの実現につながります。RFPで支援を明記したうえで、現場ヒアリングを含む提案を受けます。

ポイント

選定と移行で迷ったときは、評価軸に機能だけでなく、ハードや工事、サポートを含めているかを基準にします。移行は、データ移行とテスト移行、本番切り替えまでの流れを要件に含めているかで見ます。

まとめ

受付システムのRFP・要件定義書は、業務フローから非機能までの四つの柱で構成します。

ハードと工事込みのTCOで比べ、連携費用と障害時の責任分界を確認します。なお、CRM連携の初期費用は5万〜30万円、独自連携の初期費用は20万〜100万円以上とされます。

現場の業務からToBeを描き、ハード・連携・非機能まで定義します。曖昧なRFPは見積もりのずれや手戻りを招きますが、具体的なRFPなら、適切な提案と納得できる契約につながります。

riplaは、フルスクラッチ受託と国内開発の立場から、現場ヒアリングに基づく要件整理と、ハード・連携・非機能まで含むRFP策定を一貫して支援しています。

全体像を確認したい場合は、あらためて完全ガイドをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。