入退室管理システムのRFP/要件定義書/提案依頼書について

入退室管理システムの導入を外部に発注するとき、成否を左右するのがRFP（提案依頼書）と要件定義書の質です。入退室管理は、ソフトウェアだけで完結する一般的なシステムとは異なり、電気錠・カードリーダー・自動ドア・フラッパーゲートといったハードウェアと、その設置・配線工事を伴います。そのため、ソフトの機能要件だけを書いたRFPでは、後からハード費用や工事費が膨らみ、ベンダー間の見積もりも比較できない、という事態に陥りがちです。発注側がどこまでを要件として明文化できるかが、適正な見積もりと現場に合うシステムを引き出す鍵になります。

本記事は、入退室管理システムのRFP・要件定義書・提案依頼書の作り方を、発注側の視点で体系的に解説する「要件定義特化」の記事です。ハードウェアと工事費を含めた総コストの要件化、認証方式とエリア設計の落とし込み、外部システム連携の責任分界条項、多言語・高齢者対応などの非機能要件、稼働率や障害対応のSLAまで、RFPに盛り込むべき項目を具体的に解説します。読み終えるころには、ベンダーから比較可能な提案を引き出すRFPの骨子が描けるはずです。なお、費用相場や選び方を含む全体像をまだ把握していない方は、まず入退室管理システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・入退室管理システムの完全ガイド

ハードウェアと工事費を含む総コストの要件化

入退室管理のRFPで最初に押さえるべきは、ハードウェアと設置工事を含めた総コスト（TCO）の要件化です。ソフトウェアの月額料金だけを比較しても、実際の導入費用は見えてきません。リサーチでも、自動ドア・フラッパーゲート・電子錠との連携配線や設置工事費、タブレット盗難防止や常時給電の設備投資への言及が手薄であることが、競合解説の弱点として指摘されています。RFPにこれらを明記しなければ、見積もりの前提がベンダーごとにばらつき、後から追加費用が発生します。

RFPには、対象となるドアや出入口を一つひとつ列挙し、それぞれに必要な機器を明示します。電気錠の種類（電気錠・電磁ロック・サムターン後付け型）、カードリーダーや顔認証端末の設置場所、自動ドアやフラッパーゲートの有無、それらをつなぐ配線工事の範囲です。既存ドアに後付けするのか、新設するのかでも費用は大きく変わります。図面や現地写真を添付し、どこに何台設置するかを具体的に示すことで、ベンダーは正確な見積もりを出せるようになります。

あわせて、給電方式や通信環境の要件も明記すべきです。認証端末を常時給電にするのか、電池式にするのか、ネットワークは有線か無線かによって、配線工事の規模が変わります。無人施設やタブレットを設置する受付では、端末の盗難防止対策や、停電・通信障害時の動作も要件に含める必要があります。これらハードと工事の前提をRFPで揃えることで、初めてベンダー間の見積もりが横並びで比較できるようになります。ソフトの機能だけでなく、物理的な設備までを要件の射程に入れることが、入退室管理RFPの第一歩です。

総コストの要件化では、初期費用とランニング費用を分けて見積もるようベンダーに求めることが重要です。初期費用には機器代・工事費・初期設定費が、ランニング費用にはクラウド利用料・保守費・カード再発行などの変動費が含まれます。これらを切り分けて提示させることで、数年単位のTCOで各社を比較できます。月額だけ安くても保守費が高ければ、トータルでは割高になることもあるため、内訳の明示は必須要件として書き込むべきです。

あわせて、補助金の活用可否も要件に含めておくとよいでしょう。リサーチによれば、IT導入補助金（デジタル化・AI導入補助金）の活用で、対象経費の最大2分の1から5分の4の補助が受けられ、初期費用が大きく圧縮できるケースがあります。入退室管理はハード費用が大きいため、補助金の対象になるかどうかでTCOが大きく変わります。RFPの段階で「補助金申請の対象となる構成か」「申請のサポートを提供できるか」をベンダーに確認しておくことで、実質的な投資額を抑える道が開けます。総コストは、補助金を織り込んだ実質負担額で判断することが大切です。

総コストの要件化では、提案の前提条件を揃える工夫も重要です。各ベンダーが異なる前提で見積もると、金額だけ見ても比較になりません。RFPに「対象ドア数」「想定利用者数」「導入スケジュール」「既存設備の流用可否」といった共通の前提を明記し、その前提に沿った内訳付きの見積もりを求めることで、初めて横並びの比較が成立します。あわせて、追加開発が発生した場合の単価や、将来の拡張時の費用感も提案に含めるよう求めておくと、導入後の予算計画が立てやすくなります。前提を揃えるという一手間が、見積もり比較の精度を大きく高めます。

認証方式とエリア設計の要件定義

RFPの機能要件の中核が、認証方式とエリア設計です。どのエリアを、どの認証方式で、誰の権限で守るかを要件として明文化することで、ベンダーは過不足のない構成を提案できます。ここを曖昧にすると、すべてのドアを最高強度の認証にした過剰な見積もりが出てきたり、逆に重要エリアの保護が手薄な構成になったりします。エリアの重要度に応じて要件を書き分けることが、コストと安全のバランスを取る鍵です。

要件定義では、建物内のエリアをセキュリティレベルで分類します。誰でも入れるエントランス、社員のみの執務エリア、特定部署のみの書類保管室、最高機密のサーバルーム、というように、守るべき強度を段階的に整理します。そのうえで、各レベルに適した認証方式を割り当てます。一般エリアはICカード、機密エリアはカードと顔認証の二要素認証、というように、レベルごとに方式を要件化することで、過不足のない構成が見積もれます。

あわせて、権限の付与ルールと運用フローも要件に含めます。入社・退社・異動のたびに、誰が権限を付与・剥奪するのか、その承認は誰が行うのかを定義しておくことで、運用後の権限管理が破綻しません。来訪者や一時利用者への権限発行のフロー、緊急時の一斉解錠（火災時の避難経路確保など）の要件も忘れてはいけません。火災報知器と連動して避難経路を自動解錠する仕組みは、人命に関わる重要要件であり、RFPに明記すべき項目です。エリア設計と権限フローを文書化することが、現場で破綻しないシステムの土台になります。

要件定義で見落とされがちなのが、現場の実際の動線を踏まえることです。机上でエリアを区切るだけでなく、現場が日々どう出入りしているか（AsIs）を観察し、そこに認証を組み込んでも業務が滞らないかを検証する必要があります。両手がふさがる搬入口、来客が頻繁に出入りする受付、深夜に出入りする清掃スタッフなど、動線ごとの実態を要件に反映しなければ、導入後に現場が認証を迂回してしまいます。

このAsIsの可視化とToBeの設計は、入退室管理が現場に定着するかどうかを分ける決定的な工程です。riplaはフルスクラッチ受託と国内開発の立場から、要件定義の前段で現場の動線をヒアリングし、認証を必須にすべきエリアと利便性を優先すべきエリアを切り分けたうえで、ToBeの運用を設計することを重視しています。RFPには、こうした現場ヒアリングと業務フロー設計の工程を提案に含めるよう求める一文を入れておくとよいでしょう。要件を機器の仕様だけでなく、業務フローのレベルで定義することが、迂回されないシステムを生みます。

外部システム連携と責任分界の条項

入退室管理を予約・PMS・受付・勤怠・防犯カメラといった外部システムと連携させる場合、RFPで必ず詰めておくべきが、連携の責任分界です。複数のシステムが絡む連携では、トラブルが起きたときに「どちらのシステムが原因か」を切り分けられないと、対応が宙に浮きます。リサーチでも、高度なAPI連携の保守リスクと責任分界、すなわち連携後トラブルの原因切り分けと保守体制を契約でどう担保するかが、競合の解説で深掘り不足の論点として挙げられています。

連携要件では、つなぐ相手のシステム名、連携の方向（どちらからどちらへデータが流れるか）、同期のタイミング（リアルタイムかバッチか）、連携するデータ項目を具体的に書きます。たとえば予約システムと連携するなら、予約確定時に解錠権限を発行し、予約終了時に失効させる、という処理のタイミングまで定義します。連携先のAPI仕様書が既にあれば添付し、なければ「連携先のAPI調査を提案に含めること」を要件として求めます。

連携が複雑になるほど、想定外の挙動が起きるリスクが高まります。連携先のシステムが仕様変更したときに入退室側がどう追従するか、連携が一時的に途切れたときに解錠をどう扱うか（フェイルセーフかフェイルセキュアか）といった例外時の振る舞いも、要件として定義しておくべきです。これらを曖昧にしたまま開発に進むと、リリース後に「予約したのに解錠できない」「退会者の権限が残っている」といったトラブルが発生します。連携の正常系だけでなく、異常系まで要件化することが重要です。

連携トラブルでもっとも厄介なのが、責任の押し付け合いです。入退室側のベンダーは「連携先が原因」と言い、連携先は「入退室側の問題」と言う。この状態に陥ると、発注側が板挟みになり、復旧が遅れます。これを防ぐため、RFPには「トラブル発生時の一次対応窓口をどちらが担うか」「原因切り分けの手順と責任範囲」「復旧までの目標時間」を条項として盛り込みます。理想は、入退室側のベンダーが一次窓口となり、連携先との切り分けまで担う体制です。

riplaはフルスクラッチ受託の立場から、こうした連携の責任分界を契約段階で明確にし、複数システムが絡む構成でも一次対応の窓口を引き受ける体制を重視しています。入退室管理は、解錠できなければ業務や事業が止まる、可用性の高さが求められるシステムです。だからこそ、平常時の機能だけでなく、トラブル時に誰が・どう動くかを要件と契約で担保しておくことが、発注側のリスクを大きく減らします。連携の責任分界は、RFPで最も差がつく項目の一つだと言えます。

非機能要件とSLA・保守体制の定義

機能要件と並んで重要なのが、非機能要件とSLA（サービス品質保証）です。入退室管理は、解錠できなければ人が建物に入れない、止まると業務が完全にストップするシステムです。だからこそ、稼働率・障害時の対応時間・データの保全といった非機能要件を、RFPで明確に定義する必要があります。機能の華やかさより、止まらないこと・止まっても早く復旧することが、入退室管理では本質的な価値になります。

SLAでは、システムの稼働率の目標値、障害発生時の連絡から復旧着手までの時間、復旧までの目標時間を定義します。24時間営業の無人施設や宿泊施設では、深夜・休日のサポート体制が必須要件になります。「平日日中のみ対応」では、深夜に解錠できなくなったときに宿泊客が締め出される、という事態に対応できません。自社の運用時間に合わせて、必要なサポート時間帯を要件として明示することが重要です。

非機能要件で特に重要なのが、停電・通信障害・機器故障時の動作です。電気錠が停電したとき、開く側に倒すのか（フェイルセーフ）、閉じる側に倒すのか（フェイルセキュア）は、エリアの性質によって設計を変えるべき重要要件です。避難経路は開く側に、機密エリアは閉じる側に倒すのが基本ですが、これを要件で明示しなければ、ベンダーの判断任せになり、いざというときに想定と逆の挙動をする危険があります。非常時の動作は人命にも関わるため、RFPで必ず定義してください。

非機能要件には、ユーザビリティ（使いやすさ）も含まれます。リサーチでも、多言語UIや海外決済の連携、高齢者向けのユニバーサルデザイン（UD）設計が、競合解説で深掘り不足の論点として挙げられています。インバウンド客の多い宿泊施設では、解錠アプリや案内を英語・中国語・韓国語などに対応させる多言語要件が欠かせません。デジタルに不慣れな利用者が多い施設では、操作を極力シンプルにし、文字を大きくするなどのUD要件も重要です。

これらのユーザビリティ要件は、機能の有無ではなく品質の問題であるため、RFPで明示しないと見落とされがちです。「対応言語」「想定する利用者層と操作習熟度」「アクセシビリティの基準」を要件として書くことで、ベンダーは現場の利用者に合わせた設計を提案できます。汎用のオフィス向けシステムでは、多言語やUDへの対応が標準で十分でないことも多く、業態によっては作り込みが必要です。riplaはフルスクラッチ受託と国内開発の立場から、こうした非機能要件まで含めた要件定義を支援し、現場の利用者が無理なく使える入退室管理の実現を重視しています。機能・非機能・SLAを揃えたRFPが、比較可能で精度の高い提案を引き出します。

入退室管理の非機能要件で忘れてはならないのが、個人情報とログの取り扱いです。入退室管理は、誰が・いつ・どこに出入りしたかという個人の行動履歴を記録するため、個人情報保護の観点から慎重な設計が求められます。特に顔認証や指紋・静脈といった生体認証を採用する場合、生体情報は要配慮個人情報に近い性質を持つため、取得・保存・廃棄の方法、本人同意の取り方、データの暗号化を要件として定義する必要があります。これを曖昧にすると、導入後にコンプライアンス上の問題が表面化します。

あわせて、入退室ログの保存期間と保全方法も要件化します。認証取得や監査のために何年分のログを保持するのか、ログの改ざんをどう防ぐのか、退職者や退去者の個人データをいつ・どう削除するのかを明文化します。クラウド型を選ぶ場合は、データがどこのサーバに保管され、どんなセキュリティ認証を取得しているか（ISMSやプライバシーマークなど）も確認すべき要件です。riplaはフルスクラッチ受託と国内開発の立場から、個人情報・生体情報の適切な取り扱いとログ保全までを含めた要件定義を支援しています。守るための仕組みが、別の情報リスクを生まないよう、データの取り扱いまで要件の射程に入れることが大切です。

まとめ

入退室管理システムのRFP・要件定義書は、ソフトの機能だけでなく、ハードウェアと工事費を含む総コスト、認証方式とエリア設計、外部連携の責任分界、そして稼働率・停電時動作・多言語UDといった非機能要件とSLAまでを射程に入れて初めて、比較可能で精度の高い提案を引き出せます。機器と工事の範囲を図面で明示し、補助金を織り込んだ実質負担で判断し、現場の動線を反映してエリアを設計し、連携トラブルの一次窓口を契約で定め、非常時の動作と利用者のユーザビリティまで要件化する。この網羅性が、導入後の追加費用やトラブルを防ぎます。

RFPを作るときに大切なのは、「機器の仕様」だけでなく「現場の業務フローと非常時の振る舞い」まで言語化することです。特に、競合の解説が手薄なハード総コスト・連携の責任分界・多言語UDといった論点を要件に盛り込めば、提案の質が大きく変わります。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからToBe設計、ハードと連携を含む要件定義までを一貫して支援します。要件項目の全体像と費用感の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。