不動産業界のシステム発注は、現場の業務を洗い出し、要件の優先順位を決め、変更の進め方を合意する順に進めると、現場で使われるシステムにつながります。
不動産会社の発注側に向けて、要件定義書とRFP（提案依頼書）の作り方を解説します。全体像は不動産業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・不動産業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングと業務標準化から始める要件定義
要件定義では、機能の希望を並べる前に、現場が実際に業務をどう進めているかを把握します。現場ヒアリングを省くと、不動産でもほぼ確実に使われないシステムになってしまいます。
AsIs業務フローの可視化とToBe設計
要件定義の出発点は、現状（AsIs）の業務フローを図にすることです。反響から入居後の管理までの流れを図にすると、手戻りや二重入力が起きている箇所が見えてきます。そのうえで、業務の担当、問題、あるべき姿を次の3点で整理します。
- 担当と手順：誰が、いつ、どのツールで何をしているかの記録
- 業務上の問題：無駄や手戻り、二重入力が起きている箇所を洗い出す
- あるべき業務（ToBe）：業務を見直し、標準化した姿を設計する
現状の把握では、営業や事務、経理など役割ごとにヒアリングします。この作業を経て初めて、システムで何を解決すべきかが見えてきます。
製造業・物流業でも、「DXが流行りだから」と曖昧な目的でトップダウンに高機能システムを入れると、現場に合わず反発を招く失敗が指摘されています。一方で、業務をシステムに合わせると過剰なカスタマイズを避けやすく、更新もしやすいとされています。
AsIsをToBeに変える設計は要件定義の中心で、ベンダーへ依頼する前に自社で固めておきます。
業務標準化と要件の優先順位付け
ヒアリングで集めた要望は、取捨選択が欠かせません。すべてを盛り込むと、要件も開発費も膨らみ、使いこなせないおそれがあります。
- 必須（Must）：反響の一元化や物件公開など、事業課題への効果が高い機能
- 推奨（Should）：必須の次に優先して実現したい機能
- あれば望ましい（Could）：高度な分析機能など、優先度を下げられる機能
分類した機能は、自社の事業課題への効き目をもとに順位を決めます。建設業界では、日報や写真管理など小さな機能から始め、成功体験を積んで定着率を高めた事例があります。
優先順位付けは、スモールスタートを選ぶ判断にも直結します。不動産でも、必須機能から始めて効果を確かめ、そのあとに拡張する進め方が有効です。
優先順位があれば、フェーズごとの計画を立てやすく、初期投資のリスクも抑えられます。業務標準化と優先順位付けは、現場ヒアリングと同じく要件定義で欠かせない作業です。
RFP（提案依頼書）に盛り込むべき項目
要件が固まったら、RFP（提案依頼書）に落とし込みます。RFPは、複数社に同じ条件で提案を依頼して比べるための文書です。前提が曖昧なままだと、提案も見積もりも比べられません。
物流業界では、現場を無視して250万円の最安システムを選んだ結果、在庫切れで月500万円の機会損失に至った事例があります。RFPの精度は、こうした「安物買いの銭失い」を防ぎます。
背景・目的・機能要件・非機能要件の記載
RFPでは、まず導入の背景と目的を示し、ベンダーが課題の解決策を提案できるようにします。
- 背景と目的：導入理由と、改善したい業務課題や指標
- 機能要件：必須・推奨機能と優先順位、対象業務の範囲
- 非機能要件：利用環境、性能、稼働率、セキュリティ、対応端末
機能要件では、物件管理や反響対応、契約など、求める範囲を業務ごとに具体的に書きます。非機能要件には、同時利用人数、物件・顧客データ量、応答速度を含めます。稼働率やセキュリティ要件も、あわせて書いておきます。
対応端末も、スマートフォンやタブレットなどを含めて明記します。
物流業界では、WMS（倉庫管理システム）の導入失敗率が60%を超えるとの指摘があります。こうした失敗を避けるには、機能に加えて利用環境や負荷、安全性も定めておくことが、運用後のトラブル防止につながります。
予算・スケジュール・SLA・サポート体制の明示
想定予算とスケジュールを示すと、ベンダーも現実的な提案を組み立てやすくなります。
- 費用の前提：初期費用に加えて、保守・運用費も含める
- SLA（サービス品質保証）：障害時の復旧目標時間と問い合わせへの応答時間
- 支援体制：導入後の伴走支援の有無
製造業の費用相場では、パッケージ型が100万〜500万円、フルスクラッチが1,000万円以上が目安です。保守費は開発費の15〜20%が目安で、3,000万円の開発なら年450〜600万円です。
発注側は、こうした相場を踏まえて、初期費用だけでなく保守・運用費まで含むTCO（総保有コスト）の前提をベンダーと共有します。
建設業界では、格安アプリの返信に3日かかる体制に耐えられなかった工務店が、1年未満で乗り換え、二重のコストを払った事例があります。
不動産でも、トラブル時にすぐ相談できる体制が、システムの定着を左右します。そのため、導入後の伴走の質もRFPで確かめておきます。
外部連携・データ移行の要件化
不動産システムでは、外部連携とデータ移行が技術上の難所になりやすく、見積もりや開発のトラブルにつながります。
連携の対象は、レインズやポータルサイト、会計システムのほか、電子契約サービスも含みます。既存のExcelや旧システムからの移行も、要件に入れておきます。
範囲を明確にしないまま進めると、開発終盤になって連携できない、移行データを使えないといった問題が起きます。
ポータル・会計連携と外部仕様の事前協議
外部サービスの仕様は早めに確かめ、関係先との協議も前倒しで進めます。
- 連携先：対象となる外部サービス名
- 方式と頻度：取り込み・書き出し・双方向、リアルタイム・日次
- 対象範囲：連携データと、自動化する範囲・手作業を残す箇所
物流業界では、EDI（電子データ交換）の仕様変更について、取引先と最低3ヶ月前に協議すべきだと指摘されています。また、不動産のポータルサイトや会計システムも、連携方式は相手側の都合に左右されます。
確認が遅れると、手戻りが大量に発生します。さらに、完璧な自動連携は費用が跳ね上がるため、優先順位に基づいて範囲を絞る判断も要件定義の一部です。
外部連携は、誰と何をいつまでに合意するかという段取りまで含めて要件にすると、トラブルを避けやすくなります。
データ移行とマスター整備（クレンジング）の要件
長年蓄積した物件・顧客・契約データには、重複や表記揺れ、古い情報が混在します。
- 移行対象：対象にするデータの範囲
- 整備基準：データを整理する際のクレンジング基準
- 責任分担：自社とベンダーが担う作業の境界
物流業界では、データを整えないままでは「ゴミデータを高速処理するだけ」になると警告されています。誰がいつまでに、どの基準で整えるかを決めておかないと、移行直前に手作業が膨らみ、日程が破綻するおそれがあります。
たとえば物流現場では、本番前に基幹・現場・実物の三在庫を一致させる調整が必要です。不動産でも、現役顧客と過去客の仕分けや、物件マスターの重複統合を計画的に進めます。
移行の工数と責任は、要件定義の段階で文書に残しておくことが、後の混乱を防ぎます。
ユーザー協力義務と要件凍結の法的ポイント
発注側が見落としやすい法的な落とし穴も、要件定義の最後に確認します。発注側（ユーザー）にも協力義務があり、これを軽視すると、開発が失敗したときに発注側が損害を負担する判決もあります。要件定義は、その協力義務を果たす出発点です。
判例に学ぶユーザーの協力義務
旭川医大病院とNTT東日本の控訴審（札幌高裁・平成29年8月31日）では、ユーザー側の協力義務違反が認定されました。
- 要件を伝える：必要な内容を明確に伝える
- 意思決定する：判断を遅らせず、社内の利害調整も進める
- 情報を提供する：必要な資料や情報を適時に渡す
発注側は次々と追加の要望を出し、169項目のうち124項目が当初の開発対象外でした。その要望を整理しないまま開発現場を混乱させた点が問題視され、発注側のみに約14億1,500万円の支払いが命じられました。
この判例は、発注側が協力を怠ると開発失敗の責任を負い得ることを示しています。現場ヒアリングを行って要望を整理することは、協力義務を果たす準備になります。
製造業のトクヤマとTISの事件（東京地判・平成28年4月28日）では、賠償額が3割相当に抑えられました。その背景には、責任の所在をめぐる判断があります。発注側にも責任がある前提で、要件定義に臨む必要があります。
要件凍結と変更管理プロセスの取り決め
協力義務を果たすうえでも、要件凍結と変更管理のルールが欠かせません。要件は一定の段階で確定し、その後の変更手順を契約で取り決めます。
- 決定期限：いつまでに何を決めるか
- 変更の影響：追加費用と納期に反映する方法
- 合意方法：影響範囲・費用・納期を評価したうえで決める
判例が示すとおり、仕様凍結後に大量の要望を追加すると、ユーザー側が責任を問われるおそれがあります。
要件凍結は、一定の段階で要件を固めることです。ただし、開発中には新たな気づきが生まれることもあり、変更を一切認めないわけではありません。変更は無秩序に受け入れず、影響を評価して合意する手順を持つことが求められます。
riplaはフルスクラッチ受託と国内開発の立場から、現場業務を起点に要件を整理し、発注側と開発側の責任を明確にした変更管理を重視します。
要件凍結と変更管理は、開発を進めながら双方を法的リスクから守る仕組みです。
提案評価とベンダー選定の進め方
要件定義で固めた優先順位を基準に、複数の観点から提案を比べると、選定の精度が高まります。一方で、価格だけで選ぶと、物流業界の失敗事例のように大きな代償を払うおそれがあります。
評価軸の設計と業界理解の確認
提案は、機能や費用だけでなく、体制と不動産業界への理解も含めて評価します。
- 機能の充足度：必須・推奨要件をどこまで満たすか
- 費用と体制：費用、開発体制、サポートの内容
- 業界理解：業務フローや商習慣に沿う解決策か
不動産特有の業務や商習慣をどこまで把握しているかを、物件、反響、契約といった場面ごとに確かめます。また、自社の課題に即した具体策があるかも見ます。
製造・物流の知見でも、業界特有の現場感やノウハウの理解が定着を左右すると指摘されています。
各社の提案は、評価軸ごとに点数をつけ、要件をチェックリストにして充足度を比べます。比較表にしておくと判断の根拠を示せるため、経営層や現場、経理の納得も得やすくなります。
評価軸は、要件定義の成果をベンダー選定に活かす役割を担います。
TCO比較と社内稟議の通し方
費用は、初期費用だけでなくTCO（総保有コスト）で比べます。
- 保守費：開発費の15〜20%を目安に含める
- 追加改修費：カスタマイズの発生見込みを確かめる
- 社内説明：部門ごとの評価基準に沿って示す
保守費は毎年積み上がります。さらに、製造業ではカスタマイズ追加が1件100万〜1,000万円とされています。
隠れコストを含めて数年間の総額で比べると、提案の有利不利を判断できます。
選定結果を稟議に通すには、現場・経理・経営それぞれの評価基準に合わせて説明します。たとえば、集計自動化で月100時間以上を削減できるといった効果は、自社の数字に置き換えて示します。
要件定義からRFP、提案評価、稟議まで一貫した筋道でつなぐと、適正な価格で現場に使われるシステムの導入に近づきます。
まとめ
AsIsからToBeへの業務設計を出発点に、標準化と優先順位付けを進めることが、成否を左右します。RFPには、背景と目的のほか、機能・非機能要件や予算、SLAを盛り込みます。外部連携とデータ移行は、責任分担まで定めます。
旭川医大の約14億1,500万円（14.1億円）の判決が示すユーザー協力義務を踏まえ、要件凍結と変更管理を契約で取り決めます。開発失敗と法的リスクを避けやすくなります。
要件定義は発注側の責任領域です。自社で内容を固めるほど提案を比べられ、見積もりのぶれも抑えられます。一方で、工程を省くと、高額な投資が誰も使わないシステムに消えるおそれがあります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、現場業務から逆算した要件整理と、責任関係を明確にした開発を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。