建物管理システム開発の発注/外注/依頼/委託方法について

建物管理システムの発注は、対象業務とデータを整理し、発注形態と要件を決め、契約と見積を比べてから、小さく試す順に進めます。この順で進めると、現場に合う導入につながります。全体像は建物管理システム開発の完全ガイドにまとめています。

▼全体ガイドの記事
・建物管理システム開発の完全ガイド

建物管理システムを発注・外注する前に知っておきたい全体像

システムの範囲は会社によって異なります。BM会社の受発注・巡回・作業報告・請求が中心の場合と、オーナーやPM会社の物件・賃貸・修繕・オーナーレポートが中心の場合では、発注先の経験や見積も変わります。

対象業務の決定(BM・PM・オーナー・設備担当)

対象業務を選ぶと、発注先に求める経験や優先する機能が定まります。中心に据える業務は、次の4分野のどれかで先に決めておきます。

  • BM:契約単価から請求までの扱い
  • PM・オーナー:物件や賃貸、修繕、精算の管理
  • 設備・エネルギー:設備台帳、センサー、BAS・BEMSの扱い
  • 受付・入退館:認証、来訪予約、利用者情報の扱い

BMでは、契約単価、作業周期、巡回ルートを優先します。協力会社が関わる作業も含めて、写真付き報告から検収、請求までの流れを押さえます。

一方、PM・オーナーでは、物件・フロア・テナント・賃貸借契約の関係を確認します。修繕予算とオーナー精算、レポートの整合性も、あわせて確かめます。

設備・エネルギーでは、空調や受変電の台帳を確認し、センサー値やアラート、BAS・BEMS連携も対象に含めます。受付・入退館では、認証と来訪予約の仕組みを要件に含め、カードやスマートロック、利用者情報の扱いも先に決めておきます。

発注の目的はデータの連結

画面や帳票から決め始めると、物件コードや設備番号、契約番号が部署ごとに分かれたまま残ることがあります。このため、作業報告から請求への転記や、設備履歴の重複入力を防ぐ設計が必要になります。

  • 共通データ:物件・設備・契約の識別情報
  • 業務データ:作業実績から原価・請求へつなぐ

富士通が公開する星光ビル管理の事例では、GLOVIA smartの導入で重複作業や転記ミスを減らしたと紹介されています。現場業務は約3割効率化したとされています(出典: 富士通「GLOVIA smart ビルメンテナンス導入事例」、掲載資料)。ただし、この数字をそのまま自社に当てはめず、削減したい作業を事前に測っておきます。

建物管理システムの発注形態の選び方

BMに絞って早く使うなら、業界特化SaaSやパッケージが候補になります。PM・会計との統合を重視する場合は、パッケージを組み合わせるSIが合います。一方で、独自業務や設備連携が競争力になる場合は、ハイブリッドや個別開発が向いています。

最初からスクラッチ開発ありきで考えず、標準機能で吸収できる業務と、個別に作る業務を分けておきます。

業界特化SaaS・パッケージでの発注

業界共通の業務を短期間で導入したい場合に適しています。その場合は、標準機能に業務を合わせるFit to Standardを基本にして、例外要件を設定できるかを確認します。

  • 標準機能:物件台帳、契約、作業予定を使う
  • 個別設定:指定帳票や例外的な原価計算の可否
  • データ返却:終了時の返却条件やAPI・CSV出力の可否

点検表、写真報告、請求などの共通機能を利用できます。また、サービス終了時にデータを取り出せる条件も、契約前に確かめておきます。

SIerへの発注とハイブリッド開発

既存の会計や勤怠、販売管理、電子請求書は残し、物件・設備・現場報告を作ってAPI連携する方式です。既存資産を活かせるため、全社のシステムを一度に入れ替えるより、移行リスクを抑えやすくなります。

  • 既存資産:会計や勤怠など、活用できる仕組みの範囲
  • 連携範囲:作る領域と既存システムの境界

たとえば、東宝ビル管理では、見積データを契約処理や請求へ連携し、分散したシステムとマスタを統合した事例が公開されています(出典:大塚商会「東宝ビル管理株式会社 導入事例」、2025年)。

スクラッチ開発

複数の建物用途にまたがる独自業務や、特殊な顧客帳票が差別化要因になるなら、スクラッチ開発が候補です。独自の利益管理や、設備データの高度な分析が差別化要因である場合も、候補に入ります。

全機能を一度に作ると費用と期間が膨らむため、段階導入を検討します。図面・写真・契約書の版管理やオフライン利用、協力会社の権限、設備ネットワーク接続を、まとめて作ると負担が増えます。

  • 個別化の対象:建物用途をまたぐ業務や独自帳票
  • 初回範囲:作業報告から請求まで、1物件での試行
  • 拡張:効果を確かめたあとに広げるPM、IoT、テナント機能

ポイント

BMに絞るか、独自業務や設備連携が競争力になるかで、発注形態の候補が変わります。標準機能で足りる業務と個別に作る業務を分けると、候補を絞りやすくなります。

発注前の要件整理とRFPの作り込み範囲

RFPの事前整理項目として、規模、工程、優先度、移行対象を4枚のカードに示した図。
見積条件をそろえるには、対象範囲と進め方を先に整理します。

RFPは完成仕様書でなくても構いません。同じ条件で見積もれるよう、管理対象に加えて、誰がいつどの端末で何を登録し、次に誰が承認するかまで明らかにします。

As-IsとTo-Beの業務フロー整理

まず、物件数や建物用途、拠点を一覧にします。現場人数や協力会社数、月間の点検・修繕件数も、あわせてまとめます。

見積から入金消込までの流れは、現状のまま図にします。そのうえで、二重入力している担当者も記録します。

  • 規模:物件・拠点・人数・点検件数の一覧
  • 工程:見積から入金消込までの図
  • 優先度:MUSTは初回、WANTは第2段階以降

見積から入金消込までの各工程で、紙・Excel・既存システムの利用状況を記録します。工程は、受注や契約、作業割当から、巡回や点検、写真報告まで続きます。承認から入金消込までの段階でも、利用状況を残します。

マスタ・データ移行・セキュリティの要件

どの情報に管理コードを付けるかを先に決めておくと、部署ごとに番号が分かれたまま残る事態を防げます。過去の資料を移す範囲と、重複や欠損を直す担当もRFPに記載します。

スマートフォンを現場で使う場合は、通信の途絶や端末紛失への対応も定めておきます。

  • マスタ:物件・フロア・設備・契約・担当者のコード
  • 移行対象:点検表・竣工図・契約書・写真・修繕履歴
  • 端末・個人情報:一時保存・遠隔ロック・位置情報・保存期間

設備や入退館を連携させる場合は、ITネットワーク以外の経路も見ておく必要があります。経済産業省の第2版ガイドラインは、ネットワークや防災センター、機械室・制御盤を分けて扱います。配線経路と末端装置も、その対象に含まれます。

事前の対策に加えて、インシデント発生後の封じ込めや復旧も扱います(出典: 経済産業省「ビルシステムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」第2版)。

RFPには、ネットワーク分離と保守接続、操作ログを含めます。加えて、バックアップや復旧目標、設計書とデータの返却条件も入れます。

RFPで依頼する機能以外の提案

導入や移行、教育、運用の提案も比べ、機能一覧の充実度だけで高い点を付けず、提案全体を評価します。そのうえで、実際の点検報告から請求までを想定した操作デモで確かめます。

  • 進め方:要件定義、プロトタイプ、デモの範囲
  • 移行・運用:並行運用、教育、障害時の一次窓口
  • 受入・定着:検収基準と支援期間、現場ワークショップ

提案書には、標準機能と追加開発の境界を明示してもらい、ワークショップの回数や定着支援の月数も書いてもらいます。

ポイント

RFPは完成仕様書でなくても、同じ条件で見積もれる程度に、利用者や端末、承認の流れまで書いておきます。移行とセキュリティも要件に入れると、比べやすくなります。

建物管理システムの契約形態(請負と準委任)

契約形態は、要件がどこまで確定しているかと、発注者と受託者の役割分担で決めます。機能や納期、検収条件を明確にできる部分は請負が合い、要件を調べながら進める部分や、発注側と改善を進める部分は準委任が合います。

たとえば、要件定義は準委任、開発とテストは請負、稼働後の改善は準委任に分ける組み合わせもあります。

請負契約で固定する範囲

請負で固定するのは、先に決めた機能と納期、検収条件です。納品物と完成条件、検収方法は、契約書と仕様書に明記します。瑕疵対応や変更管理も、同じ書類に書いておきます。

  • 納品範囲:ソースコード、マスタ移行、帳票
  • 運用準備:マニュアル、管理者教育、バックアップ設定
  • 受入条件:検収方法と変更の扱いの明記

画面が動くだけでなく、データ移行や現場帳票も使える状態を、業務開始の条件として確かめます。

準委任契約の役割と時間の上限

要件を調べながら進める場合や、発注側と改善を重ねる場合に合います。受託者が専門性と作業時間を提供し、発注者と協力して作り上げます。

  • 稼働:月ごとの上限と未消化時間の扱い
  • 体制:担当者のスキル、会議、意思決定者
  • 報告:作業内容と費用が分かる形で示す

完成の責任は、受託者へ自動的に移るものではありません。そのため、役割と報告内容を契約で確かめておきます。

変更・追加開発のルール

開発中は現場から例外の要望が増えがちなので、受け付けたあとの扱いを前もって決めておきます。

  • 追加要望:業務効果・納期・費用、既存機能への影響を変更管理表に記録
  • 承認:記録をもとに承認者が判断
  • 変更リスク:見積もりを誰が負うかの確認

業務システム全般の費用に関するQ&Aでは、同じ範囲なら請負は準委任より1.3〜1.5倍程度高くなり得るとされています。ただし、費用差は契約条件や品質保証の範囲によって変わります。

ポイント

要件がどこまで決まっているかを見て、固定できる部分と、調べながら進める部分を分けて考えます。分けて契約を組むと、責任の範囲が見えやすくなります。

建物管理システムの発注・開発費用相場

BM業務に絞る場合、中規模統合、大規模統合の個別開発費用レンジを横棒で並べた図。
統合範囲が広がるにつれて、費用レンジも大きくなります。

既製SaaSの利用料と個別開発の費用は、別の相場として分けて見ます。

費用は、物件数や利用者数、データ移行の量によって変わります。帳票の個別性や会計連携、スマートフォン対応も影響します。さらに、設備・IoT連携と入退館機器の有無も、費用を左右します。

ここで挙げる数字は、公開価格と業務システム全般のQ&Aを合わせた目安です。建物管理システム全体の統計ではありません。

SaaS・パッケージの初期費用と月額費用

小規模なBM業務SaaSは、初期設定やデータ移行を含めて30万〜300万円程度です。導入期間は1〜3か月が一つの目安です。

  • 課金方式:利用者、物件、会社単位の定額など
  • 公開価格例:ビルメンHUBは初期3万円
  • 月額例:1〜5名は1名あたり月額4,980円(税込)

なお、それ以上の規模では月額2,980円からと案内しています。これは1サービスの価格例で、業界全体の平均ではありません。

出典: ビルメンHUB料金ページ、2026年確認。月額だけでなく5年分の総額を試算します。

個別開発・スクラッチ開発の費用レンジ

BM業務に絞り、物件・作業・写真報告・請求・会計連携を個別開発する場合、500万〜1,500万円程度が目安です。この場合の期間は3〜6か月です。

  • 中規模統合:1,500万〜4,000万円程度、期間6〜12か月
  • 大規模統合:3,000万〜8,000万円超、期間12〜24か月程度

中規模は、PMやBM、会計を統合する想定で、承認ワークフローやスマートフォン現場報告まで含みます。

大規模は、複数ビルの設備監視やIoTセンサー、BAS・BEMSまで含む想定です。入退館やテナントアプリも対象です。これらは、類似する業務・設備管理システムから推定したレンジで、機器や工事費を含まない場合があります。

5年総額で比較する費用項目

初期費用だけで決めず、継続利用や運用に伴う費用も含めて比べます。

  • サービス:月額利用料・追加ユーザー・物件追加・ストレージ・API
  • 設備:端末・センサー・通信・現地設置工事
  • 運用:データクレンジング・教育・保守・法改正・障害対応

保守運用費は、初期開発費の年5〜15%程度を別に置く考え方があります。一方で、クラウドやサポート契約に保守費が含まれる場合もあります。

見積には対象と除外項目を書き、単価や数量、更新時の値上げ条件も、あわせて記します。

省エネ管理では、制度変更も将来の費用に影響します。

  • 施行日:2025年4月1日
  • 対象:原則すべての新築住宅・非住宅

国土交通省が示した施行日です(出典:国土交通省「令和7年4月1日から省エネ基準適合の全面義務化」、2024年発表)。

設備台帳やエネルギー計測値を将来の報告や分析に使うなら、保存項目とエクスポート方式も考えておきます。

ポイント

数字は、公開価格と業務システム全般のQ&Aを合わせた目安として読み、自社の範囲で見積もり直します。月額だけでなく5年総額で比べると、初期費用の差に惑わされにくくなります。

建物管理システムの委託先選定と見積比較

委託先の導入範囲、実施規模、定着・成果、業務デモを4つのパネルに分けた図。
実績と提案内容を複数の観点で並べると、比較の抜けを見つけやすくなります。

知名度や提示価格だけで選ばず、業務への理解や現場アプリ、移行の進め方を評価します。さらに、既存連携や設備・OT、運用定着も見ます。

開発会社や既製品ベンダー、複数製品を組み合わせるSIerでは、得意領域が異なります。そこで、同じRFPを3社以上に渡します。

業務範囲と成果による実績の確認

実績は業務ごとに分けて確かめます。BMの契約・作業・請求と、PMやオーナー精算を中心に見ます。設備データや入退館の実績も、同じように確かめます。

  • 導入範囲:対象業務と物件・利用者数
  • 実施規模:移行データ量と導入期間
  • 定着・成果:二重入力、報告時間、障害対応

対象物件数や利用者数、移行データ量を、まず確かめます。導入期間と現場定着の方法も、あわせて聞いておきます。可能であれば、似た業態の担当者に、現場での使われ方や、トラブル時の動きを尋ねます。

機能別・工程別に分解した見積の比較

見積は、工程ごとに分けて比べます。中心になるのは、要件定義、基本設計、画面・API開発の工程です。

  • 工程:連携、移行、テスト、教育、導入支援、保守を含む
  • 提供内容:標準機能・設定・追加開発・外部サービス
  • 別費用:ハードウェアと現地工事の有無

たとえば、A社だけ移行費や教育費が見積に入っていないと、初期見積は安く見えても5年総額で逆転します。そのため、値引き率よりも除外項目を比べます。

デモと導入後の支援体制の評価

実在する一つの物件を想定し、設備登録から請求までの一連の流れをデモで操作してもらいます。

  • 業務デモ:点検や写真報告、承認、修繕、見積、検収、請求
  • 利用者:現場、管理者、経理、オーナーの画面
  • 運用支援:障害対応、復旧、更新、問い合わせ窓口

DK-CONNECT BMは、建物や契約、作業、設備の情報を扱うと案内しています。図面や点検表、権限に加えて、モバイルアプリや連携機能も含まれます。

2026年7月にはv1.6.0のリリースを公表しています(出典: ダイキン工業「DK-CONNECT BM」、2026年)。製品の更新頻度と連携方針も、比較の材料になります。

問い合わせ窓口と、重要度別の対応時間を契約に定めます。データ復旧、法改正・OS更新への対応、追加開発単価、引き継ぎも、同じ契約に含めておきます。

現場の改善要望を毎月の定例で優先順位付けできる体制は、導入効果を続けるうえで役立ちます。

ポイント

委託先は、同じRFPに対する業務範囲と成果、見積の除外項目をそろえて比べます。そうすると、初期見積の安さだけで選ぶ誤りを避けやすくなります。

建物管理システムの発注・外注でよくある質問

外注の判断で迷いやすいのは、発注先、予算、既存システムの活用、現場定着といった、外注判断に関わる疑問です。

建物管理システムはSaaSとスクラッチ開発のどちらがよいですか?

BMの標準業務を早くデジタル化したいならSaaSやパッケージが合い、独自業務や設備連携が強みならハイブリッドや個別開発が合います。

たとえば、物件や作業、報告、請求からSaaSで始め、会計やIoTはAPI連携で広げる方法もあります。標準業務に合わせる範囲と、個別開発の価値を比べて決めます。

建物管理システムの発注先から見積もりを取るとき何社に依頼すべきですか?

比べられる形のRFPを用意して、3社以上に依頼するのが実務上の目安です。その際は、異なるタイプの会社を含めて方式を比べます。

業界特化SaaS、パッケージに強いSIer、個別開発会社などを候補にします。評価の負担を抑えるため、要件に合わない会社は事前に絞り込みます。

建物管理システムの開発費以外に何を予算化すべきですか?

予算化の対象は、データ移行・整備や端末、センサー、通信です。さらに、設置や教育、並行運用、保守も含めます。クラウドや追加ユーザー、ストレージ、API利用も、予算に入れておきます。

設備や入退館を連携する場合は、現地調査やゲートウェイが別費用になり得ます。また、ネットワーク分離や機器更新も、別費用になり得ます。

5年総額と、更新しない場合の代替費用を比べます。

建物管理システムの導入で現場が使わない問題を防ぐにはどうしますか?

要件定義に現場担当者と協力会社の代表を加え、実際の点検や報告に沿ってデモします。そのうえで、1物件または1拠点で試行します。

入力や報告の時間、承認待ち、転記件数は、導入の前後で測ります。また、管理者や現場、経理に分けて教育し、定例会で稼働後の問い合わせと改善を扱います。

まとめ

発注時には、対象業務と、物件・設備・契約・作業・請求をつなぐデータの流れを決めます。標準サービスと個別開発を使い分けて、過剰な開発を避けます。

発注前に決める項目

物件数や利用者数、対象業務、既存システムは、一覧にしておきます。帳票や移行データ、設備連携、セキュリティ要件も、同じ一覧に加えます。

  1. 同じRFPを3社以上へ提示
  2. 移行・教育・機器・工事・保守・法改正対応を含む5年総額での比較
  3. 請負と準委任の責任分担を、契約に反映

小さく始めて成果を測りながら広げる進め方

全機能を一度に完成させる必要はありません。1物件で作業報告から請求までを試し、そこで得た改善を次の開発に反映します。

二重入力や報告時間、承認待ち、原価把握は、試行のなかで確かめます。こうした確認を重ねると、現場と経営が使い続けられる計画になり、費用に見合うシステムにつながります。

▼全体ガイドの記事
・建物管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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