不動産システム開発を外注する前に知っておきたいこと──RFP作成からベンダー選定、検収までの流れ

はじめに

物件検索サイトのリニューアル、社内業務システムの刷新、顧客向けマイページの新規構築──。不動産会社がシステム開発を検討する機会は、ここ数年で大きく増えてきました。

その背景の一つが、不動産テック市場の拡大です。矢野経済研究所の調査によれば、2022年度の国内不動産テック市場規模は前年度比21.1%増の9,402億円と推計されています。さらに2030年度には約2兆3,780億円（2022年度比約2.5倍）にまで拡大するとの予測です（出典：矢野経済研究所「2024年版 不動産テック市場の実態と展望」、2024年4月発表）。2022年5月の宅建業法改正による書面の電子化解禁も追い風となり、電子契約やクラウド型管理システムなど、業界全体でデジタル投資が加速しています。

ITR（アイ・ティ・アール）が2025年11月に発刊した「国内IT投資動向調査報告書2026」でも、2026年度のIT投資インデックスは「建設・不動産」が4.92と、「金融・保険」（4.97）に次いで高い水準です（出典：ITR「国内IT投資動向調査報告書2025」、2025年11月発表）。不動産業界のIT投資は、今後さらに拡大していく見通しです。

一方で、投資規模が大きくなるほど気になるのが「どの開発会社（ベンダー）に頼むか」という問題です。ベンダー選定は、単に見積もり金額を比べる作業ではありません。プロジェクト全体の品質・費用・納期を左右する、非常に大きな意思決定です。

この記事では、大手不動産会社のIT担当者やプロジェクト責任者の方に向けて、システム開発を外注する際の全体の流れを、RFP（提案依頼書）の作成からベンダー選定、そして検収まで一つひとつ丁寧に解説していきます。

不動産システム開発の外注はどんな流れで進む？──全体像をつかむ

システム開発の外注は、大きく分けて7つのステップで進みます。まずは全体の流れをざっくり把握しておきましょう。

ステップ	やること	発注者側のおもな役割
1. 社内準備	目的・課題の整理、予算確保、推進体制づくり	経営層の合意形成、プロジェクトオーナーの決定
2. RFI発行	候補ベンダーに情報提供を依頼	候補リストの作成、RFIの送付・回収
3. RFP作成・発行	要件と評価基準をまとめた提案依頼書をつくる	社内要件の取りまとめ、RFPの発行
4. ベンダー評価・選定	提案書の比較、プレゼン・デモ、最終選定	評価委員会の運営、最終的な意思決定
5. 契約・要件定義	契約締結、業務要件・機能要件の詳細化	業務フロー・データ仕様の提供、仕様の確認・承認
6. 設計・開発・テスト	画面設計、システム実装、各種テスト	設計レビュー、中間確認、受入テストへの参加
7. 検収・運用移行	納品物の検収、運用体制への引き渡し	受入テストの実施、運用チームへの引き継ぎ

ステップ5（契約・要件定義）とステップ6（設計・開発・テスト）を分けているのは、要件定義は「何をつくるかを決めるフェーズ」であり、設計・開発は「決めたものを形にするフェーズ」だからです。この2つは性質が大きく異なるため、契約形態を分けるケースも少なくありません（詳しくはステップ5で解説します）。

それでは、各ステップを順番に見ていきましょう。

ステップ1：社内準備──「何のために作るのか」を固める

ベンダーに声をかける前に、まず社内で整理しておきたいことがあります。ここが曖昧なまま進んでしまうと、あとから「そもそも何を作りたかったんだっけ？」と方向性がブレて、追加費用や納期遅延につながりやすくなります。

最初に整理しておきたい4つの項目

① プロジェクトの目的とゴール
「物件検索サイトをリニューアルしたい」だけだと、少し漠然としています。たとえば「自社サイト経由の反響数を、月200件から月350件に増やしたい」のように、できるだけ数値を含めてゴールを設定しておくと、ベンダーからの提案も的を射たものになりやすくなります。

② 予算のおおまかな目安
正確な金額が決まっていなくても大丈夫です。「500万〜1,000万円くらい」「2,000万円前後」など、大まかな規模感を社内で共有しておきましょう。予算の桁が変われば、実現できることの範囲もまったく異なります。

③ スケジュールの制約
「来年度の繁忙期（1〜3月）までに公開したい」「法改正に間に合わせる必要がある」など、動かせない期日があるかどうかを確認しておきます。

④ 推進体制
プロジェクトオーナー（最終意思決定者）と、日々の窓口となるプロジェクト担当者を決めておくことが大切です。不動産会社の場合、IT部門だけでなく営業部門や管理部門など複数の部署が関わることが多いので、「誰がどの範囲の判断を下せるか」を最初にはっきりさせておくと、その後のやり取りがスムーズになります。

ステップ2：RFI（情報提供依頼書）で候補を絞る

RFI（Request for Information）は、ベンダー候補に「御社の概要や実績、対応できる範囲を教えてください」とお願いするための書類です。RFPの前段階にあたるプロセスです。

なぜRFIが必要なのか

RFPをしっかり作って送るにはそれなりの労力がかかります。最初からすべてのベンダーにRFPを送るのではなく、まずRFIで候補を5〜8社ほどに絞り込み、そこからRFPの送付先を3〜5社に選ぶのが一般的な進め方です。

不動産システム開発ならではのRFI質問例

RFIに盛り込むと効果的な質問の例をいくつかご紹介します。

• 不動産業界のシステム開発実績はあるか（業態・規模・担当範囲）
• 類似プロジェクトの開発期間・費用の目安（予算・期間・チーム体制）
• 不動産業務への理解度（賃貸・売買・管理など、どの業態の経験があるか）
• セキュリティ要件への対応方針
• 納品後の運用・保守サポートの体制

RFIの回答を比べてみるだけでも、「この会社は不動産業界のことをちゃんとわかっているな」「ここは実績が少なそうだな」といった判断がしやすくなります。

ステップ3：RFP（提案依頼書）をつくる──ベンダー選定の質はここで決まる

RFP（Request for Proposal）は、ベンダーに対して「こういう要件で提案をください」と正式にお願いする書類です。

少し大げさに聞こえるかもしれませんが、ベンダー選定の質はRFPの質で決まると言っても過言ではありません。RFPが曖昧だと、各社からの提案にバラつきが出て、正確な比較ができなくなってしまいます。

RFPに盛り込みたい項目

大項目	記載する内容	不動産システムならではの注意点
プロジェクト概要	背景・目的・期待する効果	自社の業態（賃貸仲介、売買、管理など）や課題を具体的に
現状の課題	既存システムの問題点、業務上の困りごと	基幹システムとの連携状況、レガシーシステムの有無
機能要件	必要な機能の一覧と優先度	物件検索条件、地図連携、帳票出力、ポータル連携など
非機能要件	性能、セキュリティ、可用性、拡張性	個人情報保護法への対応、宅建業法関連のコンプライアンス
予算・スケジュール	予算の上限目安、希望納期	繁忙期を避けたリリース計画
評価基準	何を重視して選定するかの基準	不動産業界の実績・業務理解度を評価軸に入れる
契約条件	契約形態、知的財産権、秘密保持	ソースコードの帰属、運用・保守の条件

RFP作成でありがちな3つの失敗

失敗①：要件が抽象的すぎる
たとえば「使いやすい物件検索機能がほしい」とだけ書くと、ベンダーごとに解釈が異なってしまいます。「絞り込み条件はエリア・価格帯・間取り・築年数・駅徒歩分数の5項目を必須とし、地図上のピン表示と連動すること」──ここまで具体的に書いておくと、各社の提案を正確に比較しやすくなります。

失敗②：評価基準を書かない
「何を重視して選ぶか」を伏せたままRFPを出すと、ベンダー側も力の入れどころが分かりません。結果として、本来最も得意な領域を持つベンダーが、その強みを活かせない提案を出してしまうことがあります。

失敗③：社内の意見がまとまっていない
営業部門は「検索機能の充実」を求め、管理部門は「業務効率化」を重視し、IT部門は「既存システムとの連携」を優先したい──。こうした優先順位のズレが解消されないままRFPを発行してしまうと、ベンダー選定の段階で社内の議論が紛糾し、プロジェクト全体が停滞しがちです。

ステップ4：ベンダーの評価・選定──「安さ」だけで選んではいけない理由

各社から提案書が届いたら、いよいよ評価・選定のフェーズです。

評価はこんな流れで進める

1. 書類評価：RFPの評価基準に沿って、各社の提案書を採点する
2. プレゼン・デモ：候補を2〜3社に絞り、対面やオンラインでプレゼンテーションと質疑応答を行う
3. 最終選定：総合評価をもとに、パートナーとなる1社を決定する

評価基準の具体例

参考として、不動産システム開発における評価基準の一例をご紹介します。

評価項目	配点例	確認したいポイント
不動産業界の理解度・実績	25点	業務フロー、法規制、商習慣を理解しているか
技術力・提案の具体性	25点	要件に対する解決策が具体的か、技術選定に根拠があるか
プロジェクト管理体制	20点	PMの経験、体制図、コミュニケーション方針
費用の妥当性	15点	単に安いかではなく、見積もり内訳の透明性と根拠
運用・保守の対応力	15点	納品後のサポート体制、障害対応のSLA（サービス品質保証）

ここで特にお伝えしたいのは、見積もり金額の安さだけで選ぶのは危険ということです。

システム開発の見積もりには定価がないため、同じ要件でもベンダーによって金額は大きく変わります。その差は「見落としている作業がある（あとから追加費用になる）」「技術力の差」「リスクの見込み方の違い」など、さまざまな原因から生じます。

とくに不動産業界のシステム開発では、業務理解の深さがそのまま見積もりの精度に直結します。業界の実情を知らないベンダーは、RFPに書かれていない「不動産業界では当たり前」の要件を見落としがちです。結果として安い見積もりが出てきたものの、いざ開発を始めると「そこまでの機能は想定していなかった」「追加費用が必要です」という話になるケースは珍しくありません。

ステップ5：契約・要件定義──プロジェクトの土台をつくるフェーズ

ベンダーが決まったら、まず契約を結び、要件定義に入ります。要件定義は「何をつくるかを具体的に決める」工程であり、プロジェクト全体の土台となる重要なフェーズです。

知っておきたい2つの契約形態

システム開発でよく使われる契約形態には「請負」と「準委任」の2種類があります。

契約形態	特徴	向いているケース
請負契約	成果物の完成を約束する。未完成なら報酬は発生しない	要件がしっかり固まっている開発
準委任契約	作業の遂行を約束する。完成義務はない	要件定義や設計など、ゴールが流動的な工程

大規模な不動産システム開発では、この要件定義フェーズを準委任契約で進め、その後の設計・開発フェーズを請負契約に切り替える「フェーズごとの契約分割」が採用されることもあります。IPAが公開する「情報システム・モデル取引・契約書」（2025年更新版）でも、工程に応じた契約形態の選択が推奨されています。

要件定義で発注者が果たす役割

要件定義は、ベンダーだけで完結できる工程ではありません。「自社の業務がどう回っているか」「データはどこからどう来るか」「現場が本当に困っていることは何か」──こうした情報は、発注者側からしか出てきません。

不動産業界のシステムでは、とくに以下のような情報がベンダーにとって不可欠です。

• 物件情報のデータ構造：物件データの項目、保存先、更新のタイミングと方法
• 業務フロー：物件登録→公開→成約→掲載終了の流れ、各ステップでの判断基準
• 既存システムとの関係：基幹システムや物件管理システムとの連携要件

ベンダーからの質問にはできるだけ早く回答し、仕様の認識にズレがないかをこまめに確認していくことが、このフェーズのポイントです。

ステップ6：設計・開発・テスト──「お任せ」にしてはいけないこと

要件が固まったら、設計・開発・テストのフェーズに進みます。

設計フェーズ：「これ、現場で使えるかな？」の視点で確認する

画面の設計図（ワイヤーフレーム）や画面遷移図が出来上がったら、「実際の業務で使えるか」という目でレビューします。この段階で「ちょっと違うかも」と気づいて修正するのと、開発が進んでからやり直すのとでは、かかるコストに大きな差が出ます。

開発・テストフェーズ：進捗を見守り、受入テストに備える

開発が始まったら、定例ミーティングに参加して進捗を把握しましょう。「任せたから大丈夫」と放置してしまうと、完成間際に大きなギャップが見つかるリスクがあります。

テストフェーズでは、ベンダー側の内部テストとは別に、発注者自身による「受入テスト」が待っています（詳しくは次のステップで解説します）。テストに必要なデータや検証シナリオの準備は、このフェーズのうちから進めておくとスムーズです。

ステップ7：検収と運用移行──「納品されたら終わり」ではない

開発が完了し、ベンダーから成果物が納品されたら検収です。

検収で確認しておきたいポイント

• 機能要件：RFPで定義した機能がすべて入っているか
• 非機能要件：表示速度やセキュリティなど、性能面の要件を満たしているか
• テスト報告：ベンダー側で行ったテストの結果がきちんと報告されているか
• ドキュメント：設計書、操作マニュアル、運用手順書が揃っているか
• ソースコード：契約で定めた範囲のソースコードが納品されているか

受入テストは「自分たちの目で確かめる」プロセス

検収で最も重要なのが「受入テスト」です。これはベンダー側のテストとは別に、発注者自身が実際の業務シナリオに沿ってシステムを操作し、問題ないことを確認するプロセスです。

不動産システムの場合、たとえば次のようなシナリオで検証します。

• 新規物件の登録から公開までの一連の操作がスムーズに行えるか
• 物件検索の各絞り込み条件が正しく機能するか
• 管理画面で更新した情報が、公開サイトにすぐ反映されるか
• アクセスが集中したときの表示速度に問題がないか

受入テストで見つかった不具合はベンダーに修正を依頼し、再テストを経て検収完了となります。

運用移行で押さえておくこと

検収が終わったら、運用フェーズに移ります。ここで大切なのは次の2点です。

① 運用・保守の契約を結ぶ：開発契約とは別に、公開後の運用・保守について取り決めます。障害発生時の対応フロー、サーバー監視の範囲、セキュリティアップデートの頻度などを明確にしておきましょう。

② ナレッジを引き継ぐ：開発中にベンダーと共有した業務知識やシステム仕様を、社内の運用チームに引き継ぎます。担当者が替わっても困らないよう、ドキュメントとして残しておくことが安心です。

なぜ不動産システム開発では「業界特化」のベンダーが選ばれるのか

ここまでの各ステップで繰り返し「不動産業界ならでは」という話が出てきましたが、それには理由があります。

Web制作会社は「不動産業の業務」を理解しているわけではない

一般的なWeb制作会社やシステム開発会社は、Webサイトやシステムを「つくる」技術は持っています。しかし、不動産業界の業務そのものに精通しているかというと、それは別の話です。

不動産業界には、業態ごとに異なる業務フローやデータの扱い方があります。たとえば以下のような点は、業界経験のないベンダーには想像しにくい部分です。

業態ごとに異なる業務の進め方

「賃貸仲介」「売買仲介」「マンションデベロッパー」「管理会社」「不動産ポータルサイト」──同じ不動産業界でも、業態によって物件データの持ち方、更新のタイミング、成約時の処理フローはまったく異なります。この違いを理解していないベンダーに依頼すると、「データを掲載するだけのサイト」になってしまい、現場の業務改善にはつながりません。

物件データの特殊性

不動産の物件はすべて「一品もの」です。ECサイトのように同じ商品を何度も売るのとは根本的に異なり、数百〜数千件の物件情報を日々登録・更新・掲載終了していく運用が前提になります。物件のステータス管理（公開中・申込あり・成約済みなど）、データ登録の効率化、検索条件の設計──これらはすべて業務理解がなければ適切に設計できない領域です。

基幹システムや物件管理システムとの連携

多くの不動産会社は、自社の基幹システムや物件管理システムを持っています。Webサイトやシステムを新たに構築する際、これらとのデータ連携が必要になるケースが大半ですが、業界経験のないベンダーは、そもそもこうしたシステムの存在自体を知らない場合もあります。

ポータルサイトとの関係

SUUMO、HOME'S、at homeなどの不動産ポータルサイトとの連携も、不動産Webサイトではよくある要件の一つです。各ポータルごとにデータ仕様や入稿ルールが異なり、しかも定期的に変更されるため、最新の状況を把握しているかどうかで対応の精度が変わってきます。

不動産広告のルール

不動産公正取引協議会連合会が定める広告の規約や、景品表示法に基づくルールは、Webサイト上の物件掲載にも適用されます。こうした規制を理解した上でシステムを設計しないと、意図せず規約違反になってしまうリスクがあります。

「業界の当たり前」を知っているかどうかで、プロジェクトの効率が変わる

不動産業界に詳しいベンダーであれば、こうした前提知識を持った上でプロジェクトを進められます。発注者が「イチから説明しなくても話が通じる」状態でスタートできるため、要件定義の精度が上がり、手戻りや追加費用のリスクも減らせます。

逆に、業界の事情を知らないベンダーの場合、RFPに細かく書いていない「当然含まれているはず」の要件を見落とすことがあります。その結果、発注後に「そこまでは想定していなかった」「追加費用が必要です」というやり取りが発生し、プロジェクトが想定どおりに進まなくなるケースが見られます。

ベンダー選定チェックリスト──社内検討にお使いください

ベンダーを選ぶ際、社内で確認しておきたいポイントをチェックリストにまとめました。選定会議や稟議書作成の際にご活用ください。

	確認項目	チェックの観点
1	不動産業界の開発実績があるか	同業他社での事例、どの業態（賃貸・売買・管理など）の経験があるか
2	業務を理解したヒアリングができるか	RFIやRFPへの回答から、業界の商習慣やデータの扱いを知っているかを確認
3	曖昧な要望を具体化する力があるか	「こんな感じにしたい」を画面設計や仕様に変換できるか
4	見積もりの中身が透明か	「一式」ばかりでなく、何にいくらかかるか明示されているか
5	プロジェクト管理の体制が明確か	PMの経験、進捗報告の頻度と方法
6	一貫した体制で対応してくれるか	要件定義〜開発〜運用保守まで同じチームかどうか
7	契約条件がわかりやすいか	請負 or 準委任の使い分け、ソースコードの帰属、追加費用の条件
8	運用・保守のサポート体制があるか	納品後の対応内容、障害時のフロー、SLA

よくある質問（FAQ）

Q. RFPは必ず作らなければいけませんか？

法的な義務はありませんが、作成することを強くおすすめします。RFPがないと、ベンダーごとに提案の前提条件が異なり、正確な比較が難しくなります。また、RFPを作る過程で社内の要件が整理される効果もあります。とくに予算が1,000万円を超えるプロジェクトでは、RFPなしで進めるのはリスクが大きいと考えてください。

Q. 不動産業界の実績がないベンダーは避けるべきですか？

実績がないから一律にNGとは限りません。ただし、不動産業務の理解度は必ず確認しましょう。業態ごとの物件データの扱い方、基幹システムとの連携、不動産広告のルールなど、業界固有の知識があるかどうかをRFIやヒアリングで見極めることをおすすめします。

Q. 開発期間の目安はどのくらいですか？

プロジェクトの規模や複雑さによって大きく異なります。物件検索サイトの構築であれば3〜6か月程度、業務システムの刷新であれば6か月〜1年以上かかるケースもあります。要件定義にどれだけ時間をかけるか、フェーズを分割するかによっても変動します。

まとめ

不動産システム開発の外注を成功させるためには、「ベンダーにお任せ」ではなく、発注者自身がプロジェクトに主体的に関わることがとても大切です。

この記事でお伝えしたかったポイントを3つにまとめると、次のとおりです。

① 社内準備をしっかり行う ── 目的・予算・体制を固めてからベンダーに声をかける
② RFPの質を高める ── 具体的な要件と評価基準をベンダーに提示する
③ 業務を理解しているベンダーを選ぶ ── 不動産業界の業務フロー・データの扱い・法規制をわかっているパートナーを選ぶ

サービシンクは、不動産業界に特化したWeb制作・システム開発を手がけている会社です。制作・開発実績の8〜9割が不動産関連で、物件検索サイト、業務システム、仲介業者向けCMSなど、さまざまなシステム開発を経験してきました。RFP作成の段階からのご相談にも対応しています。

「まだ要件が固まっていない」「RFPの書き方に自信がない」──そんな段階からでも大丈夫です。まずはお気軽にご相談ください。