賃貸管理システムの開発会社の選び方：見積り比較と要件定義で詰める点

賃貸管理システムの開発会社を探すと、比較サイトには社名と実績の一覧が並びます。ただ、一覧だけでは、その会社が家賃の入金消込やオーナー送金、賃貸住宅管理業法の帳簿まで理解しているかは分かりません。この記事では、賃貸管理システムを個別に開発する、または既製品に連携部分を足すと決めた会社に向けて、依頼先の種類、面談で聞く質問、要件定義で詰める項目、相見積もりの揃え方、契約の分け方を順に整理します。既製品で足りるかの判断が済んでいない場合は、先に親記事で全体像を確認してください。

まとめ：賃貸管理システムの開発会社は業務と法令の質問で選び、見積りは前提を揃える

開発会社を選ぶ前に、依頼の範囲を「既製品の改修」「既製品と他システムをつなぐ連携開発」「全面スクラッチ」のどれにするかを決めます。範囲が決まらないまま相見積もりを取ると、金額の差が範囲の差なのか単価の差なのか読めません。賃貸管理システムの定義と、既製品か自社開発かの判断がまだなら、そこから始めてください。

候補の比較では、実績の件数より、入金消込・解約精算・分別管理の帳簿について具体的に質問し、答えの解像度が、業務知識を見極める判断材料です。見積りは工程の範囲、移行データの件数、連携の本数を揃えて依頼し、要件定義だけを先に別契約で切り出すと、本開発の見積りがぶれにくくなります。契約では保守費の内訳と、契約終了時にソースコードとデータを持ち出せる条件を必ず確かめます。

賃貸管理システムを開発会社へ依頼する前に決める、本体か連携部分かの範囲

開発会社への依頼は、作る範囲によって相手も費用も変わります。最初に範囲を決め、その範囲を得意とする依頼先に絞ります。

依頼の3つの型：パッケージ改修・連携開発・全面スクラッチの違い

賃貸管理の分野で開発会社に頼む仕事は、次の3つに分かれます。どれを選ぶかで、比べるべき会社の顔ぶれが変わります。

実務で多いのは連携開発です。本体を既製品で回し、製品が持たない処理だけを外側に作る構成なら、製品の更新に引きずられずに済みます。管理戸数帯ごとの構成の選び方は中小企業向けの賃貸管理システムの選び方で整理しています。

依頼先の種類で変わる得意領域：製品ベンダーと受託開発会社の分担

製品ベンダーは自社製品の改修には強い一方、他社製品や自社の会計システムとの連携は請け負わない場合があります。改修の可否と費用は、製品の仕様と保守契約の範囲で決まるためです。

受託開発会社が作れるのは、製品をまたいだ連携です。その代わり、製品が外部に出せるデータの範囲（CSV出力の項目やAPIの有無）が、連携できる範囲の制約です。連携開発を頼むなら、使っている製品のデータ出力仕様を先に取り寄せ、開発会社に見せてから見積もってもらいます。この資料が無いまま出てくる見積りは、データの取り出し方を想定で置いているため、後から増額になりやすくなります。

賃貸管理システムの開発会社を比べる評価軸：業務知識・法令・移行・安全管理

比較サイトの「実績あり」は、賃貸管理のどの業務を作ったかまでは示しません。面談で次の4つを質問し、答えの具体さで比べます。

入金消込とオーナー送金を説明させて開発会社の業務知識を測る3つの質問

業務知識は、例外の扱いを聞くと差が出ます。面談では次の3つを聞き、標準の流れだけでなく例外の処理まで答えられるかを見ます。

1. 入居者の名義と振込名義が違う入金や、2か月分がまとめて入った入金を、どの画面でどう消し込む設計にするか
2. オーナー送金の前に、管理手数料・修繕費の立替・敷金の預かりをどの順で差し引き、送金明細にどう表示するか
3. 月の途中で解約した入居者の日割り家賃と原状回復費を、敷金とどう相殺し、精算書を誰に出すか

答えに「御社の運用に合わせます」しか出てこない会社は、要件定義でこちらが業務を一から説明することになります。逆に、名義の対応表や立替金の扱いを先に質問してくる会社は、移行と例外処理の工数を見積りに入れてくる傾向があります。

分別管理・帳簿・管理業務報告を開発要件に落とせるかの具体的な確認項目

管理戸数が200戸以上の会社は、賃貸住宅管理業法第3条と同法施行規則第3条により国土交通大臣の登録が要ります。登録事業者には、システムの作りに直結する義務が3つあります。

• 第16条の分別管理：家賃や敷金を自社の財産と分け、どの管理受託契約の金銭かを帳簿で直ちに判別できる状態にする（施行規則第36条）
• 第18条の帳簿：管理受託契約ごとに帳簿を備え、事業年度の末日で閉鎖して閉鎖後5年間保存する。電磁的記録で代えられる（施行規則第38条）
• 第20条の定期報告：契約日から1年を超えない期間ごとに管理業務報告書を作り、委託者に交付して説明する（施行規則第40条）

開発会社には、この3つをデータ項目と画面にどう落とすかを聞きます。たとえば「入金1件ごとに管理受託契約の番号を持たせるか」「報告書の対象期間を契約日起点で自動計算するか」です。条文を知らない会社でも作れますが、要件の説明を発注側がすべて担うことになります。

旧システムやExcelからのデータ移行を見積りに含めるかの確認

賃貸管理の開発で後から膨らみやすいのがデータ移行です。入金名義と契約の対応、オーナー別の口座区分、更新履歴は、旧システムやExcelの中で表記が揃っていないことが多く、変換の前に整理の作業が要ります。移行で詰まる典型は賃貸管理システムの導入事例の移行の章にまとめています。

見積り依頼では、移行の対象を「現行契約のみ」「退去済みを含む」のどちらにするか、件数はいくつか、本番前に移行リハーサルを何回行うかを明記します。移行を「別途見積り」とだけ書く会社は、総額の比較から外れてしまうため、概算でよいので金額を出してもらいます。

入居者とオーナーの個人データを預ける委託先として確かめる安全管理措置

開発や保守の過程で開発会社が扱うのは、入居者の氏名・口座・連絡先といった個人データです。個人情報保護委員会の通則ガイドライン（令和8年6月一部改正）の3-4-4は、委託元に、適切な委託先の選定、安全管理措置を盛り込んだ委託契約の締結、委託先での取扱状況の把握を求めています。再委託する場合は、再委託先と取扱方法の事前報告か承認を受けることが望ましいとされています。

面談では、テスト環境に本番の個人データを持ち込むか、持ち込むならマスキングするか、再委託先はどこかを確認します。移行リハーサルで本番データを使う場合は、作業端末と保管場所、作業後の消去方法まで契約に書きます。

賃貸管理システムの要件定義で詰める、例外処理・連携項目・保存期間の決め方

開発会社を絞った後、要件定義で固める対象は次の3点です。ここが曖昧なまま開発に入ると、テストの段階で「その処理は要件に無い」という追加費用が出ます。要件定義書の章立ては要件定義書の書き方を下敷きにできます。

業務フローの例外を洗い出す：滞納・解約精算・サブリースの精算

標準の流れは既製品の画面を見れば誰でも書けます。差が出るのは例外です。滞納が2か月を超えたときに督促状を出す条件、保証会社へ代位弁済を請求する時期、解約精算で敷金が足りないときの請求先を、1件ずつ業務フローに書き出します。

サブリースを扱う会社は、オーナーへの支払いが家賃の入金額でなく契約で決めた借上げ賃料になるため、精算の計算式が仲介型の管理と別になります。この計算式を開発会社に文章で渡せるかどうかで、見積りの精度が変わります。

連携先ごとに決めるデータ項目と受け渡しの頻度：銀行・保証会社・会計

連携開発では、相手ごとに「何を・どの形式で・どの頻度で」受け渡すかを表にして要件定義書に入れます。

表の各セルに、相手側の担当者と仕様書の有無も書き添えます。仕様書が手に入らない連携先は、開発会社が調査から始めることになり、その工数は見積りに上乗せされます。契約の期日管理を別システムで持つ場合の分け方は不動産の契約書管理システムと賃貸管理システムの分界を参照してください。

権限・操作履歴・帳簿の5年保存とバックアップで決める非機能要件の範囲

非機能要件は後回しにされがちですが、賃貸管理では法令の保存期間が基準になります。施行規則第38条の閉鎖後5年保存に合わせ、閉鎖した帳簿をどこに、どの形式で、何年残すかを決めます。

あわせて、担当者ごとの閲覧・編集の権限、送金データを作成した人と承認した人の操作履歴、バックアップの頻度と復旧までの時間を数字で書きます。「十分なセキュリティ」とだけ書いた要件定義書は、開発会社ごとに解釈が違い、見積りの比較ができません。

賃貸管理システムの開発見積りを比べるときに揃える前提と、契約の分け方

相見積もりを比較できるのは、各社の前提が揃っている場合です。金額の大小より、何が含まれているかを読みます。見積書の一般的な読み方はシステム開発の見積もりと相見積もりの比較で解説しています。

相見積もりで開発会社全社に同じ条件を渡す提案依頼書の具体的な5項目

開発会社ごとに説明を変えると、見積りの差の理由が分かりません。次の5項目を提案依頼書にまとめ、全社に同じ文書を渡します。

1. 依頼の型（改修・連携開発・全面スクラッチ）と、対象の業務の範囲
2. 管理戸数、オーナー数、月間の入金件数、担当者の人数
3. 連携先の一覧と、各連携先の仕様書の有無
4. 移行データの範囲と件数、移行リハーサルの回数
5. 稼働希望日と、避けたい月（更新の集中月や決算月）

提案依頼書の構成はRFPの記載項目と目次テンプレートが使えます。回答に「前提条件」「対象外」の欄を設けてもらうと、各社が何を外して金額を出したかが一目で分かります。

要件定義を先に切り出す多段階の発注と、IPAのモデル契約の使い方

要件が固まる前に開発全体の金額を確定させると、開発会社は不確定な部分にリスク分を上乗せします。要件定義だけを先に契約し、その成果物をもとに設計以降を見積もり直す多段階の発注にすると、上乗せ分を減らせます。要件定義は成果物の完成を約束しにくいため準委任、仕様が固まった後の開発は請負で結ぶ分け方が一般的です。契約形態の違いは受託開発と委託・請負・SESの違いを参照してください。

契約書のたたき台には、IPAが公開している情報システム・モデル取引・契約書（第二版）が使えます。2020年12月22日公開で、ページの最終更新は2026年9月11日です。第二版と追補版のひな型（2025年4月8日更新）のほか、追補版に付属する重要事項説明書、セキュリティ仕様の策定プロセスも同じページに掲載されています。ユーザー企業とベンダーのどちらにも偏らない中立の立場で作られているため、双方が修正点を話し合う起点にできます。

保守費の内訳と、契約終了時にソースコードとデータを持ち出せる条件

初期費用が安くても、保守費が月額固定で内容が曖昧な見積りは避けてください。保守費は、障害対応、法令改正に伴う改修、連携先の仕様変更への追随、OSやライブラリの更新に分けて内訳を出してもらいます。既製品の月額との比較は賃貸管理システムの費用と3年総額の試算で扱っています。

もう1つは出口の条件です。ソースコードの著作権をどちらが持つか、契約終了時にデータをどの形式で引き渡すか、引き渡しの費用は誰が負担するかを契約書に書きます。帳簿の保存義務は開発会社を替えても続くため、データを標準的な形式で出せない契約は結ばないでください。

賃貸管理システムを開発会社に頼まないほうがよい場面と、頼むべき場面

開発会社を探している段階でも、作らない判断が正しい会社はあります。条件を示して言い切ります。

全面スクラッチを勧める開発会社を見送るべき管理会社の規模と業務の条件

管理戸数が1,000戸未満で、精算の方式が一般的な管理受託だけなら、全面スクラッチは勧めません。既製品のクラウド型は、たとえばReDocSの料金ページが1,000区画以上を個別見積もりにしているように、規模に応じた料金体系を公開しています。この規模で本体を作ると、法令改正や銀行の仕様変更への追随をすべて自社の保守費で負担することになり、既製品の月額を上回りやすくなります。

その条件で全面スクラッチを提案してくる開発会社は、既製品との比較を示しているかを確認します。比較が無いまま「御社専用に作れます」とだけ言う会社は見送ってください。オンプレミスの旧システムを作り直すかどうかで迷っている場合は、オンプレミス型を続けるかクラウドへ移るかの判断を先に読んでください。

連携開発を外注すべき業務の条件と、受託開発会社に最初に渡す仕様資料

開発会社に頼むべきなのは、本体の既製品は使い続けつつ、銀行明細の取り込み、サブリースの精算計算、会計への仕訳連携、自社サイトの空室表示など、製品が持たない処理が業務の中核にある場合です。担当者が毎月Excelで加工している作業があれば、それが連携開発の候補になります。

依頼の初回には、使っている製品のデータ出力仕様、毎月の手作業の手順書、連携先の仕様書の3つを渡すと、話が早く進みます。自社物件の検索ページや問い合わせ受付を、管理している物件データとつないで作りたい場合は、一創の不動産ポータルサイトシステム開発で、物件データの取り込みや反響管理を含めて相談を受け付けています。

よくある質問

賃貸管理システムの開発会社を探している方から寄せられやすい質問をまとめました。

賃貸管理システムの開発会社はどうやって探せばよいですか？

開発会社を探す前に決めるのは、自社が依頼する開発の型です。使っている製品の改修なら、まず製品ベンダーに改修の可否を問い合わせます。製品をまたぐ連携や本体の開発なら、比較サイトやマッチングサービスで受託開発会社を3社ほどに絞り、同じ提案依頼書を渡して比べます。面談では、入金消込の例外や分別管理の帳簿について質問し、答えの具体さで業務知識を測ってください。

賃貸管理システムを個別開発するとどのくらいの期間がかかりますか？

期間は依頼の型で大きく変わります。連携開発は対象の連携の本数で決まり、全面スクラッチは要件定義だけでも数か月単位になります。期間を左右するのは、連携先の仕様書が手に入るか、移行データの整理にどれだけ時間がかかるかです。稼働日は、契約更新の集中月とオーナー送金の締めを避けて設定し、その日から逆算して要件定義の開始時期を決めます。

開発会社の見積り金額に大きな差が出るのはなぜですか？

多くは前提の差です。移行データの範囲、連携の本数、テストの範囲、保守の有無が会社ごとに違うと、金額の差は単価ではなく範囲の差になります。全社に同じ提案依頼書を渡し、回答に「前提条件」と「対象外」を書いてもらえば、差の理由を読み取ることが可能です。要件が固まっていない部分にリスク分を上乗せしている場合もあるため、要件定義を先に切り出すと差が縮まります。

不動産業界の開発実績がない会社に頼んでも大丈夫ですか？

連携開発なら、業界実績より、使っている製品のデータ出力仕様を読み、例外処理を質問してくるかを重視します。ただし全面スクラッチやサブリースの精算のように業務ロジックが中核になる開発では、業界の知識がない会社に頼むと、要件の説明をすべて発注側が担うことになります。その負担を受け止められる担当者がいるかで判断してください。

開発会社を途中で替えることはできますか？

契約でソースコードの権利と、データの引き渡し形式を決めていれば替えられます。決めていない場合、ソースコードを受け取れず、作り直しになることがあります。賃貸住宅管理業法の帳簿は閉鎖後5年の保存義務が続くため、開発会社が替わってもデータを読み出せる形式で受け取ることが条件です。契約前に、終了時の引き渡し方法と費用を書面で確認してください。

関連記事

• 賃貸管理システムとは？機能・種類と選び方、自社開発が必要になる判断まで解説：既製品で足りるか、自社開発が要るかの判断を先に確認できます。
• 賃貸管理システムの費用：公開料金で見る初期費用・月額と3年総額の増え方：既製品の月額と個別開発費を比べる材料です。
• 賃貸管理システムの導入事例：入金消込・更新・オーナー送金の変化と移行で詰まる点：データ移行で詰まる点を事例から確認できます。
• RFPとは？提案依頼書の意味・目的・記載項目と目次テンプレートを解説：相見積もりで全社に渡す提案依頼書の作り方です。
• 要件定義書の書き方：章立てサンプル・記載項目・レビュー観点を作業手順で解説：要件定義で例外処理と連携項目を書き出すときの下敷きです。