建物管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

建物管理システムの開発は、6つのフェーズを順に進めます。はじめに要件整理から始め、製品と開発会社を選んで、設計開発に進みます。設計開発のあとは、現場で使える状態にする作業が続きます。

  • テスト:画面の表示だけでなく、現場で起きる例外や受け入れ条件まで確かめます。
  • 稼働:小さく始めて、切り替えを管理します。
  • 定着:利用率とデータ品質を高めていきます。

まず利用者ごとの業務を分け、データの流れで範囲を決めます。

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

建物管理システムの全体像

見積・契約から請求、点検から報告、故障受付から修繕へつながる3つの業務シナリオを並べた図。
業務の入口が違っても、情報の受け渡しを一連で捉えられます。

建物管理システムは、建物の維持・運営に関する情報と業務をまとめて管理するシステムです。

利用者がビルメンテナンス会社か、オーナーやプロパティマネージャーかによって、中心となる業務が変わります。開発の過不足を防ぐには、最初に利用者と目的を分けて整理します。

誰のためのシステムかの最初の切り分け

利用者ごとに必要な業務を分けて整理すると、機能の過不足を防げます。

  • BM業務:物件・設備台帳、年間・月間点検計画、巡回ルート、作業員割当を扱います。写真付き現場報告、協力会社実績、見積・契約・請求まで含みます。
  • PM業務:賃貸借契約、賃料・共益費、テナント依頼、修繕履歴、オーナー精算やレポートが対象です。
  • オーナー・設備担当:エネルギー計測・設備の稼働状況、異常通知、修繕計画、資産台帳、投資判断に使う集計です。

要件整理では、利用者ごとに入力する人、承認する人、結果を見る人を分けて書き出します。

特に、建物名や設備名を部署ごとに登録している場合は、機能追加より先にマスタ統合を検討します。

データの流れで決める開発範囲

範囲を決めるときは、情報が誰から誰へ渡るかを業務シナリオとして描きます。

建物管理システムは、見積や契約から作業実績、請求、原価・利益率の経営管理まで、情報をつなぐ役割を持ちます。

  • 見積・契約から請求へ:営業情報と作業実績を請求へつなぎ、原価・利益率を経営管理へ渡します。
  • 点検から報告へ:点検結果を、報告書の提出までつなぎます。
  • 故障受付から修繕へ:受付後の対応を、修繕完了までつなぐ流れです。

大塚商会の公開事例では、東宝ビル管理株式会社が2025年1月に統合パッケージへ移行しました。同社は統合パッケージで、見積・契約・販売・会計をつなぎ、さらに人事給与・文書管理・ワークフローも連携しました。この連携は2025年1月の移行時に強化されています(出典:大塚商会「東宝ビル管理株式会社 導入事例」、2026年8月確認)。

3つの業務シナリオを描くと、二重入力や承認漏れを見つけやすくなります。

ポイント

利用者ごとの業務を分けたうえで、見積から請求、点検から報告、故障受付から修繕までの流れを見ると、どこまでを開発範囲に入れるかを判断しやすくなります。

建物管理システムの進め方

導入は6フェーズで進みます。まず要件整理で業務とデータを洗い出し、最後は稼働後の定着まで段階を追って進めます。各段階で何を作り、誰が承認するかを先に決めておきます。また、未解決課題を次工程へ持ち越す条件も明確にすると、判断のぶれを抑えられます。

フェーズ1:要件整理による業務とデータの洗い出し

要件整理では、現状を把握するために、物件の規模から業務環境、設備データまで調べます。

  • 規模:物件数、建物用途、拠点数、現場人数、協力会社数。
  • 業務環境:端末、既存システム、帳票、図面、契約書。
  • データ:設備データの保存場所。

「点検結果を入力したい」という要望の裏には、顧客向け報告書への転記、異常時の責任者への通知、請求対象作業の集計などの目的があります。そのため、入力の先にある業務成果まで確認します。

この段階では、業務一覧、現行フロー、課題一覧を作ります。

あわせて、画面・帳票サンプルを用意し、データ項目一覧と権限案、MUST・WANTの優先順位を整理します。

現場担当者がスマートフォンやタブレットで入力できるか、物件・設備・契約のIDが一貫しているかを確かめます。

法定点検や顧客指定帳票に漏れがないかも、あわせて見ておきます。なお、対象業務を広げすぎると、後工程の費用と期間が膨らみやすくなります。

フェーズ2:同じ条件での製品・開発会社の選定

業務範囲と設備連携の有無に合わせて、導入方式と対応できる体制を選びます。

  • 既製パッケージ:業界向けの標準機能を使います。
  • クラウドSaaS:提供されるサービスを利用します。
  • 専用環境:利用環境を個別に用意します。
  • スクラッチ開発:個別要件に合わせて作り込みます。
  • ハイブリッド:複数のサービスを組み合わせます。

BM業務だけに絞るなら、業界パッケージやSaaSを優先します。一方、PM・会計まで統合するなら、SIerや基幹連携に強い会社を検討します。

設備制御やエネルギー管理も含む場合は、BAS・BEMSやIoTゲートウェイ、現地工事に対応できる体制が必要です。

提案依頼書には、物件数、利用者数、通信環境を書きます。さらに、既存マスタと移行対象も入れます。そのうえで、連携の範囲と支援の条件も示します。

  • 会計・帳票・設備連携
  • サポート時間・障害時の復旧目標

最低3社へ同じ資料を渡します。

そのうえで、要件定義の範囲、追加開発単価、移行責任を比べます。加えて、教育回数・保守窓口・解約時のデータ返却条件も比べます。

標準機能で対応できる範囲と、個別開発になる範囲を分けて説明できる会社が候補になります。

フェーズ3:設計開発での標準化と個別対応の切り分け

設計開発では、標準の部分と個別に作る部分をどこで分けるかを、先に決めます。

  • 基本設計:画面を作る前に、マスタ、権限、承認を決めます。さらに、状態遷移、外部連携、保存、監査ログも決めます。
  • データ連携:物件・設備マスタを共通にし、写真や点検結果を設備・契約・作業員に紐づけて、検索や引き継ぎをしやすくします。
  • 例外対応:顧客別の帳票や例外処理を際限なく増やさず、標準フローと例外フローに分けます。

現場アプリは、通信が不安定な地下機械室や屋上でも入力できるか、写真の容量を制御できるか、修正履歴が残るかを確かめます。

設備データを連携する場合、情報系と制御系のネットワークを同じ扱いにしません。なお、経済産業省の第2版ガイドラインは、ライフサイクル全体で確認する考え方を示しています。対象は、構成情報・バックアップ、ネットワーク、保守業者の接続・インシデント対応です(出典:経済産業省「ビルシステムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」、2026年8月確認)。

フェーズ4:テストでの現場の例外の再現

画面の表示だけでなく、現場で起きる例外や受け入れ条件まで確かめます。

  • テストの順序:単体、連携、業務シナリオ、権限、移行データ・性能・障害復旧の順に確かめます。
  • 例外ケース:見積変更や契約更新、作業の差し戻し、協力会社の入力、請求締め・設備異常の再通知を試します。
  • 受け入れ:現場責任者・事務・経理・設備・経営管理の代表者が、実データに近いサンプルを操作します。
  • 合格基準:報告書作成時間、二重入力回数、入力漏れ、承認時間、請求データ一致率を、導入前と比べます。
  • 不具合管理:重要度と期限を記録し、稼働を止める問題と、稼働後に改善できる問題に分けます。

フェーズ5:小さく始める稼働と切り替えの管理

稼働は、パイロットから全社展開へ進みます。その前に、本番移行の手順を決めておきます。

  1. 代表性があり、協力を得やすい1物件または1拠点を、パイロットに選びます。
  2. 物件登録・設備台帳・点検計画・現場報告を通したうえで、承認、顧客提出、請求まで流します。
  3. 現場通信・写真・帳票・締め処理にかかる時間を確かめ、全社展開の前に設定を直します。
  4. 旧システムの参照期限、新システムの入力開始日、未完了の作業・契約の扱いを決めます。
  5. 並行稼働の対象業務と終了日を定め、二重入力の期間を長くしすぎないようにします。
  6. 切り替え当日の連絡先、障害時の手戻り方法、バックアップからの復旧手順を事前に配布します。

フェーズ6:定着に向けた利用率とデータ品質の向上

役割別の研修では、現場が作業開始から報告まで、管理者が差し戻しと承認を学びます。事務は契約と請求、経営層は集計とレポートを学びます。

  • 研修:操作研修を一度で終えず、繰り返し受けられるように用意します。
  • 質問対応:各拠点にスーパーユーザーを置き、寄せられた問い合わせをFAQや操作手順に反映します。

利用率は、ログイン人数よりも現場業務の指標で確かめます。月次では、当日中の作業報告率、写真付き報告率、台帳の更新遅れを確認します。あわせて、差し戻し件数、請求までの日数、紙帳票の残存数も見ます。

利用が進まない原因は、機能の不足のほかに、設計や運用上の問題である場合もあります。たとえば、入力項目が多い、通信できない、承認者が不明、旧運用が二重に残るといった原因を確かめます。

ポイント

各段階で、稼働を止める問題と稼働後に改善できる問題を分けて判断すると、どの工程で止めるべきかを迷いにくくなります。

建物管理システムの費用相場とコストの内訳

SaaS・パッケージ導入、BM業務の追加開発、中規模統合、大規模連携の4つの費用レンジを横棒で示した図。
連携範囲が広がるにつれて、見積もりの幅も大きくなります。

費用は、利用者数や物件数のほか、データ移行や帳票、会計連携で変わります。さらに、現場アプリや設備・IoT、入退館に加えて、教育や保守でも変わります。

平均的な一つの価格で見るより、公開価格の実例と、個別要件を含む開発・導入の推定レンジを分けて見積もります。

公開価格はサービスの一例としての読み方

公開価格は、市場全体の平均ではなく、個別サービスの一例です。そのため、条件をそろえて比べます。

  • ビルメンHUB:料金例です。
  • ビルメンッ:ビリーブは月額1万8,000円からと案内しています。
  • アクティブ・リテック:初期150万円から、連携50万円から、月額15万円からの例があります。

ビルメンHUBの料金は、初期費用3万円(税込)、1〜5名は月額4,980円/名、規模が大きい場合は月額2,980円から/名(税込)です。この料金は、ビルメンHUB公式料金ページ(2026年8月確認)を出典としています。

ビリーブの契約内容や最新の条件は、提供元へ確認します。特に、入退館やスマートロックを含む仕組みでは、ソフトウェア以外の費用も増えます。

アクティブ・リテックの金額は税別で、機器・設置工事・通信費などは別です。比べるときは、対象物件・利用者数、サポート範囲、ハードウェアの有無をそろえます。

工程別に分けた開発・導入の推定レンジ

初期設定から設備・テナント連携まで、開発範囲が広がるほど、費用と期間も変わります。

この目安は、リサーチノートと業務システム全般のQ&Aをもとにしています。

  • SaaS・パッケージ導入:初期設定、移行、帳票調整は30万〜300万円程度、1〜3か月。
  • BM業務の追加開発:500万〜1,500万円程度、3〜6か月。
  • 中規模統合:PM・BM・会計・ワークフロー・現場報告をまとめる範囲で、1,500万〜4,000万円程度、6〜12か月。
  • 大規模連携:設備監視、IoT、BAS・BEMS、入退館、テナントアプリを含め、3,000万〜8,000万円超、12〜24か月程度。

これらは、専用の公的平均統計ではなく、類似する受発注・販売・設備管理系システムから推定したレンジです。ただし、実際の額は、物件数、データ品質、連携方式を確定してから判断します。さらに、機器と工事の範囲も含めて見ます。

5年総額で比べる月額・保守・機器の費用

初期費用だけでなく、5年間に発生する費用と契約終了時の費用も、同じ条件で比べます。

  • 導入・設備:初期設定・個別開発・移行、端末・センサー・設置工事、通信、クラウド利用料。
  • 運用:アカウント・物件の追加、教育・保守、法改正対応、バックアップ・障害対応。
  • 保守料金:業務システム全般では、初期開発費の年5〜15%程度を見込む考え方があります。SaaSに含まれる範囲も確かめます。
  • 追加課金:物件・協力会社アカウント、帳票変更、API、データ出力、端末管理には別料金がかかる場合があります。
  • 5年総額:月額の内訳を確かめ、5年間の利用料・追加費用と終了時の移行費を並べます。

月額料金には、問い合わせやセキュリティ対応も含まれることがあります。

ポイント

費用は初期費用だけで比べず、5年間の月額・保守・機器・追加課金と、終了時の移行費まで同じ条件でそろえると、見積もりの差の理由が読み取りやすくなります。

建物管理システムの見積もりを取る際のポイント

業務シナリオとデータ例、現行帳票とデータ項目、追加費用の要因と見積条件を確認するチェックリスト。
共通の材料を渡すと、各社の提案条件を照らし合わせやすくなります。

良い見積もりは、開発範囲と準備する人、追加費用が発生する条件を、はっきり示しています。

各社に口頭で伝えると、前提が社ごとに異なり、比較しにくくなります。そこで、業務シナリオとデータ例を用意し、同じ前提で提案を受けます。

要件の明確化とサンプル資料の準備

提案依頼書には、見積もりに必要な業務の流れを示します。

  1. 年間点検の予定作成から、現場入力、写真付き報告、責任者承認、顧客提出まで。
  2. 見積作成・受注・契約登録、作業実績、原価、請求・入金確認まで。
  3. 故障受付・協力会社への依頼、修繕完了・履歴更新、オーナー報告まで。

各シナリオには、現行帳票とデータ項目を添付します。そのうえで、承認者や例外ケースも書き添えます。

機能一覧は、必須、できれば必要、将来検討の3段階に分けます。

移行対象は、物件・設備・契約を中心に分けます。そのほかに分けておく区分は2つあります。

  • 取引先・作業員
  • 過去の点検履歴・写真・請求履歴

また、移行しないデータの保管方法も記載します。Excelの表記揺れや設備名の重複、古い契約、住所の欠落は、移行前の整理作業にかかる工数に影響します。

価格以外の基準による複数社の比較

価格以外も含めて、候補の条件をそろえて比べます。

  • 機能・環境:対象業務、建物用途、クラウド・専用環境、スマートフォン、オフライン入力。
  • 連携・支援:会計・勤怠・電子請求書、設備・IoT、データ移行・公開価格、導入支援・保守窓口。
  • 提供体制:開発会社、既製品ベンダー、SIerごとに、標準機能と個別開発の担当を分けます。
  • 面談者:実案件のPM、要件定義、データ移行、保守の担当者が、打ち合わせに加わるかを確かめます。
  • 実績・体制変更:契約後に体制が変わるときの責任と引き継ぎ、二重入力・報告書・原価・BCP・教育の変化を確かめます。

見積書で確認するリスクと契約条件

追加費用と契約上の責任を明確にするため、見積書の中身を項目ごとに確かめます。

  • 追加費用の要因:要件変更・連携仕様、古いデータ・顧客帳票、通信・機器設置、権限変更。
  • 見積条件:範囲・対象外・前提、変更単価・検収・遅延、成果物を明記します。
  • 契約形態:請負は完成条件・変更手続き、準委任は月次成果物・稼働時間・優先順位・予算上限を定めます。
  • 終了時の取り決め:知的財産権、データ返却、移行支援を明記します。
  • 制御連携:ネットワーク分離・遠隔保守、期限付きアカウント、ログ・緊急連絡・復旧訓練を定めます。

設備制御との連携は、業務停止や建物利用者の安全に影響する可能性があるため、契約と運用の両面で対策を定めます。

ポイント

見積もりを比べるときは、同じ業務シナリオとデータ例を渡し、追加費用の要因と見積条件をそろえて読むと、社ごとの前提の違いが見えやすくなります。

よくある質問

製品の種類、費用、現場への定着、法令、セキュリティについて、導入前に判断したい点をまとめました。

建物管理システムはパッケージとスクラッチのどちらがよいですか?

BM業務の標準化を優先するなら、パッケージやSaaSを選ぶとよいでしょう。一方、独自の原価計算や顧客別帳票が競争力に直結するなら、スクラッチかハイブリッドを検討します。

標準機能を使い、差別化につながる業務だけAPI連携や追加開発で補うと、費用と定着のバランスを取りやすくなります。

建物管理システムは小規模に導入できますか?

導入できます。1物件または1拠点で、効果を測りやすい業務から始めます。物件・設備台帳、点検計画、現場報告・承認・顧客提出などが候補です。

パイロットでは、通信、入力負荷、帳票を確かめます。さらに、権限と請求連携も見ます。利用率と作業時間の改善を確かめてから対象を増やすと、全社展開のリスクを抑えられます。

対象建物に関係する基準とデータ要件は、要件整理の段階で確かめます。

  • 建築物衛生:特定建築物と学校の延べ面積基準を確かめます。
  • 省エネ:新築住宅・非住宅の着工時期に応じた適合要件を確認します。
  • 保存要件:保存対象となるデータの種類。

厚生労働省は、特定用途に使う延べ面積3,000平方メートル以上を特定建築物とし、専ら学校の場合は8,000平方メートル以上を基準としています(出典:厚生労働省「建築物衛生のページ」、2026年8月確認)。

国土交通省は、2025年4月以降に着工する原則すべての新築住宅・非住宅について、省エネ基準適合を義務化しています(出典:国土交通省、2026年8月確認)。

特に、設備台帳、エネルギー計測、点検・報告データについては、保存の決まりを確かめます。

設備やIoTを連携するときは何を確認しますか?

接続設備と取得データ、更新頻度、保存期間を確かめます。あわせて、異常通知先や、読み取りか制御かも押さえます。

空調・受変電・エレベーターなどの制御系を業務システムにつなぐ場合は、ネットワーク分離・資産台帳、権限・ログ、遠隔保守の接続管理を設計します。

障害時の手動運転と復旧手順も含めます。最初は読み取り中心で始め、制御範囲を段階的に広げる方法もあります。

まとめ

まとめると、開発・導入は要件整理から定着までの6フェーズで進みます。

最初に、BM、PM、オーナー、設備担当者の目的を分けます。そのうえで、物件や契約、作業、原価、請求のデータの流れを整理します。

目的に合う導入方式の選び方

BM業務を早く標準化するならSaaSや業界パッケージを、PM・会計の統合ならパッケージとSIの組み合わせを検討します。

設備制御や独自業務が競争力になる場合は、ハイブリッドやスクラッチが候補です。設備・機器・工事の有無で費用が変わるため、ソフトウェアの金額に加えて、機器や工事の範囲も含めて見ます。

見積もりから定着までの一つの計画

導入計画は、見積もりから定着までを一つの流れとして作ります。

  • 費用:初期費用・月額・利用者や物件の課金、機器・工事、移行・教育・保守に分け、5年総額と終了時のデータ返却を比較します。
  • 定着指標:作業報告率・二重入力・報告書作成時間・台帳更新・請求までの日数を確かめ、現場の声を改善につなげます。
  • 事前の準備:代表物件の業務シナリオとデータを整理し、複数の候補へ同じ条件で相談します。

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

会社紹介

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

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

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

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

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

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