ビルメンテナンス管理システム開発の発注/外注/依頼/委託方法について

ビルメンテナンス管理システムの発注は、現状業務を整理して方式と要件を決め、実データで提案を比べてから契約し、試験導入を経て本番に展開する流れで進みます。

段階契約と試験導入を取り入れると、請求漏れや二重入力を防ぎやすくなります。

▼全体ガイドの記事
・ビルメンテナンス管理システム開発の完全ガイド

ビルメンテナンス管理システムの発注・外注の進め方

現状業務の棚卸しから方式選択、RFP、実データ比較、契約を経て本番展開へ進む工程図。
条件を揃えて進むほど、提案と見積を比べやすくなります。

基本手順は、現状業務の棚卸し、方式選択、RFPと要件整理、提案依頼の順です。そのあと、実データでの比較、契約、検証を経て、本番展開へ進みます。条件を揃えないまま依頼すると、金額や納品範囲を比べられません。

契約から請求までを対象とする範囲

年間契約や定期作業から始まる処理は、月次計画を立て、担当者や協力会社を手配して現場を確認するところへ続きます。写真付きで報告したあと、承認、顧客への提出、検収を経て、請求へ進みます。

発注の時点で、どの業務を同じシステムでつなぐかを決めておく必要があります。現場報告だけを電子化して管理側がExcelへ再入力すると、請求漏れや二重入力の問題が残ります。

1拠点・1業務で行う実データによる試験

いきなり全物件を置き換えず、代表的な範囲から試験します。

  • 試験範囲:代表的な1物件、1契約、1協力会社を使い、予定作成から請求対象の確定まで
  • 現場入力:現場の高齢者や協力会社が入力できるかどうか
  • 帳票出力:顧客指定のExcel様式を出力できるかを確かめる
  • 通信不安定時:地下や機械室で通信が途切れた際の記録方法の検証

たとえば、ダイキン工業のDK-CONNECT BMは、作業結果を端末に一時保存し、通信回復後にクラウドへ保存する仕組みを案内しています(出典: ダイキン工業、2026年)。

発注形態(SaaS・パッケージ・個別開発)の選び方

方式は、既存の業務のまま早く使うか、自社向けに業務を再設計するかで決まります。料金だけで選ぶと、帳票や請求ルールに合わず、追加開発や運用変更が増えます。そのため、導入後の総費用と現場負担を合わせて見ます。

定型業務が中心の場合の業界特化SaaS

物件や顧客、契約、請求などの定型業務を早く始めるなら、業界特化SaaSが候補になります。自社でサーバーや大規模な保守体制を持たなくても、更新を受けられるのが特徴です。

  • 料金範囲:ユーザー数や物件数、写真容量、帳票変更、移行、会計連携の扱いを確かめます
  • 解約時の扱い:データの返却が料金に含まれるかどうか

たとえば、ビルメンHUBは初期3万円、1〜5名は1名あたり月額4,980円、6名以上は同2,980円からと案内しています(出典: ビルメンHUB公式料金ページ、2026年)。

また、ビルメン女子には、初期10万円・月額2万5,000円、または初期30万円・月額6万円の公開例があります(出典: 株式会社ダイナックス、2026年時点の公開情報)。ただし、いずれも個別サービスの料金で、市場全体の相場ではありません。

既存の会計や販売管理を活かす場合のパッケージ・ノーコード

既存の会計や販売管理、給与・勤怠を残す前提で考えるなら、業界特化パッケージやkintoneなどのノーコード・ローコードを比べます。その際は、契約台帳や作業実績、報告書を整えられるかを見ます。

  • 期間・費用:標準機能と設定で対応し、独自の請求計算や承認だけを追加する形になります
  • 設定の限界:顧客別の締め日や帳票、協力会社の割当、物件別の予算・粗利、設備台帳、BMS・IoT連携が、設定でどこまで対応できるか
  • 業務適合:標準機能で足りず、Excelへ戻る処理が残らないかどうか

標準機能を土台にすると、ゼロから作るより期間と費用を抑えやすくなります。ただし、例外処理まで含めて業務に合うかを見極める必要があります。

独自の収益管理や連携が競争力になる場合の個別開発

独自の契約単価や臨時作業の見積、実行予算が競争力に直結するなら、個別開発や既製サービスへの追加開発を検討します。外注費や粗利、顧客ポータルも、自社の強みに関わるなら対象になります。

  • 開発範囲:標準機能で不足する理由を、業務効果で説明できる機能に絞ること
  • AIの準備:点検履歴や設備台帳を整えたうえで、要約や予知保全を検討する順番
  • AIの利用:人が確認する前提で、発注や安全判断を補う機能

完全スクラッチは自由度が高い一方で、要件定義、移行、テスト、教育、保守の責任も発注者が負うことになります。契約、設備、作業結果の記録を先にそろえ、写真や是正履歴も同じ形式にしておくと進めやすくなります。

ポイント

既存業務をそのまま早く使うか、業務を自社向けに再設計するかを先に決めます。料金の安さだけで選ぶと、追加開発や運用変更が増えるため、導入後の総費用と現場負担で比べます。

RFPと要件整理で決めておく事項

RFPの要件整理を、現状業務、必須機能と将来機能、非機能要件、実データの4項目に分けた図。
帳票や例外処理も含めると、提案時の確認が具体的になります。

RFPは、同じ条件で提案と見積を比べるための基準です。完成仕様書である必要はありません。対象業務、利用者、データを揃えたうえで、制約、優先順位、検収条件、予算と時期も示します。

資料の厚さよりも、現場の帳票と例外処理を隠さず示すことが大切です。また、実際に使う帳票類も、ベンダーに提示します。

契約から請求までの現状業務の流れ

まず現状業務の範囲をつかみ、各工程を業務フローとして並べます。

  • 契約・定期業務:年間契約、定期清掃、設備と法定点検
  • 臨時業務:突発故障、修繕、見積、外注の流れ
  • 完了・精算:報告から検収、請求、入金確認まで
  • 工程情報:担当者、時期、入力、帳票、承認者、次の処理を記録する項目
  • 導入前KPI:締め日数、報告時間、請求漏れ、遅延、電話確認回数、粗利把握日数という導入前の数字

作業日誌や物件台帳、顧客指定の様式、電話やメールの指示も、資料に添付しておきます。現状の数値がないと導入後の効果を説明できないため、比較の基準を記録しておきます。

必須機能と将来機能の優先順位付け

利用者と業務の場面ごとに要件を整理しておくと、ベンダーからの質問が具体的になります。機能要件は、次のようなまとまりで記載します。

  • 管理情報:建物、フロア、設備、顧客、担当者、契約のマスタ
  • 作業運用:年次・月次・日次計画、シフト、協力会社の割当
  • 現場記録:スマートフォン入力、写真、位置・時刻、異常、是正依頼
  • 承認と報告:承認・差戻し、報告書出力、設備履歴
  • 収支と統制:見積、実行予算、外注費、粗利、請求、権限、監査ログ

非機能要件には、対応機種、通信が不安定なときの動作、写真の保存期間と容量、バックアップを記載します。そのほか、復旧目標や稼働時間、認証と権限の分離を定めておきます。ログや暗号化、個人情報、サポート時間についても決めておきます。

図面や入館手順を扱う場合は、退職者や契約が終わった協力会社のアカウントを、いつ無効にするかも決めておきます。

実データを使ったデモと現場の一連の操作の確認

現場の一連の操作を確かめるため、デモは実際の業務の流れに沿って進めます。

  • 持ち込むデータ:実物件の契約や予定、点検項目、写真、報告様式、請求締め日
  • 通しで試す操作:割当、現場記録、差戻し・承認、報告書・請求データの出力
  • 提案の比較:標準機能と設定、追加開発、連携、運用代替を、費用と前提に分けて示してもらう

画面の見た目より、二重入力と例外処理を誰が受け持つかを重視します。サンプル物件では現場の課題が見えにくいため、実物件のデータで確かめます。

回答には、初期費用と月額費用、前提と除外項目、導入後の支援体制も含めてもらいます。条件がそろうと、重要な作業の別料金を見つけやすくなります。

ポイント

提案と見積を同じ条件で比べられるかが、RFPの基準になります。現場の帳票や例外処理を隠さずに示せているかで、RFPの出来を判断できます。

システム開発の契約形態(請負と準委任)の使い分け

請負契約には「仕様が固まった製造」、準委任契約には「探索や支援」を対応させた2列の比較図。
工程ごとに契約を分けると、成果と役割を定めやすくなります。

完成責任を明確にする工程と、発注者とベンダーが一緒に要件を探る工程は、分けて考えます。契約名だけでは中身が分からないため、範囲、成果物、検収、変更の条件を個別に確かめます。報酬や責任、知的財産の扱いから、再委託、保守、返却条件まで確認しておきます。

仕様が固まった製造の請負と、探索や支援の準委任

請負契約は、合意したシステムや成果物を完成させて検収を受ける工程に向いています。一方、準委任契約は、要件定義や現行業務の調査、プロトタイプの作成に使われることがあります。アジャイルな改善や運用支援に用いられる場合もあります。

  • 請負:画面、帳票、連携、テスト、納期、検収基準が定まった製造を対象にします
  • 準委任:探索や支援を進める役割と時間、会議・レビューの頻度を定めておく

請負は、画面などの仕様が明確なら固定価格で予算を管理しやすい一方、機能を追加すると仕様や納期、金額の調整が必要になります。そのため、変更の承認手順をあらかじめ定めておきます。

一般に、準委任は成果物の完成責任の範囲が請負と異なります。このため、何を作るかに加えて、何人月や何時間の作業量、どの役割が、どの頻度の会議やレビューを行うのかを明記します。

IPAのアジャイル開発版モデル契約でも、機能追加や優先順位の変更が起こりやすいことから、準委任を基礎とする考え方が示されています(出典: IPA「情報システム・モデル取引・契約書」、2025年更新)。

要件定義・開発・保守を分けた段階契約

顧客指定の帳票や物件ごとの例外が多く、初期の段階ですべての仕様を確定しにくいため、工程を分けて契約します。

  1. 現行調査と要件定義
  2. PoC
  3. 製造・設定
  4. 移行・教育
  5. 保守運用

各段階で何を成果とし、どの条件で次へ進むかを決めておきます。要件定義の成果には、業務フローや画面・帳票の一覧、データ項目、権限表が入ります。さらに、連携方式、非機能要件、受入テスト案も含めます。

ソースコードや設定、データ、画面・帳票の著作権と利用権を明確にします。第三者ライセンスや終了時のアカウント処理も、あわせて決めておきます。特に解約時は、データの形式や返却費用、移行支援、バックアップ期間を確かめておきます。

SLAでは、障害の受付時間や復旧目標、保守通知、セキュリティ事故の連絡期限を合意しておきます。こうしておくと、運用後の認識違いを防げます。

2026年の委託におけるサプライチェーンの安全性

このシステムは、顧客情報や図面、設備の情報を扱います。入館手順や写真、従業員・協力会社の情報も含まれます。そのため、委託先と再委託先の安全管理を契約前に確かめておく必要があります。

  • アクセス管理:多要素認証や最小権限、テナント分離を求めます
  • 運用対策:脆弱性対応、ログ監視、バックアップ、事故報告の取り決め
  • 開発データ:本番データを開発環境へ持ち込まないという条件

経済産業省と国家サイバー統括室は2026年3月、ソフトウェア開発・供給・運用事業者と顧客の役割を整理したガイドラインを策定しました。

このガイドラインは専用規格ではありませんが、脆弱性管理や供給網の責任を確認する材料になります(出典: 経済産業省・国家サイバー統括室、2026年)。

ISMAPへの掲載も参考情報の一つです。ただし、民間企業での導入の安全性を自動的に保証するものではありません。

ポイント

完成責任を負う工程は請負、一緒に要件を探る工程は準委任と、工程ごとに分けて考えます。契約名だけでなく、範囲や検収、変更の条件まで確かめられているかが目安になります。

ビルメンテナンス管理システムの費用相場

費用は、SaaSや設定・移行、個別開発などの費目に分けて見積もります。連携・帳票、教育・保守も、費目として分けて見ます。テーマ固有の公的な市場統計は確認できないため、示す数字は公開料金と類似業務システムの目安です。

実額は、人数や物件数、データ量で大きく変わります。ほかにも、次の点で金額が変わります。

  • 帳票:顧客指定の様式や出力の範囲
  • 連携:会計など既存システムとのつなぎ込み
  • セキュリティ:アクセス管理や運用対策の範囲
  • 導入支援:教育や移行などの支援の範囲

そのため、費目ごとに前提を揃えて比べます。

既製SaaSの初期数万円から数十万円、月額数万円からの目安

小規模SaaSの料金と、中堅以上で必要になる費用は、分けて考えます。

  • 小規模SaaS:初期費用3万円から30万円程度、月額2万5,000円から10万円程度が検討レンジです。
  • 公開料金例:初期3万円、1名あたり月額4,980円からの例や、初期10万円・月額2万5,000円の例があります。ユーザー数やプランによって変わります。
  • 中堅以上:複数拠点や帳票、移行、連携、教育を含む場合は、初期設定・移行が数十万〜数百万円、月額が数万〜数十万円になることがあります。
  • 総額の確認:追加料金が、利用者や写真容量、帳票、CSV、会計、サポート、移行、解約時の返却にかかる場合、3年程度の総額が変わります。
  • 比較範囲:利用人数や物件の増加、端末、通信、教育、運用担当者の工数も含めて比べる

個別開発の段階別の予算(PoCから全社展開まで)

小さく試す段階から全社展開まで、費用と期間は次のように広がります。

  • PoC:1拠点・1業務を試す小規模PoCで50万〜300万円、1〜3か月程度
  • パイロット本番:複数物件で300万〜1,500万円、4〜12か月程度
  • 中規模開発:1,000万〜3,000万円程度、9〜18か月程度を仮置きする場合があります
  • 全社展開:1,500万〜5,000万円以上、13〜36か月程度のレンジも想定します

パイロット本番では、複数の物件を対象に、契約や作業報告、承認を扱います。さらに、請求や権限、データ移行まで行います。

中規模開発は、契約、見積、作業の管理を一つにまとめる想定です。さらに、設備台帳、請求、会計連携、顧客ポータルも含めます。

ここに示した各レンジは、類似する建設・設備系の業務システムを基にした一般的な目安です。このテーマ固有の公的統計ではなく、要件や体制によって変わる推定です。

全社展開には、複数拠点やBMS・IoT、会計・勤怠、協力会社ポータルが含まれることがあります。加えて、教育と移行も入る場合があります。

金額は一つに断定せず、機能、拠点、データ、連携、導入支援の内訳に分けてもらいます。

初期費用と分けて見る保守運用費と社内工数

保守費と社内工数は、初期費用とは分けて、次の条件を確かめます。

  • 保守費の目安:初期開発費の年15〜25%程度を仮置きすることがあり、見積開始時の目安になります。
  • 別建ての費用:クラウド利用料、監視、バックアップ、問い合わせ対応、端末、通信、法改正や帳票変更、脆弱性対応、追加開発。
  • 月額保守の範囲:含まれる時間と作業、障害と改善の区分、休日対応、バージョンアップ費
  • 社内工数:現場説明会、マスタ整備、紙帳票のデータ化、テスト、問い合わせ窓口、旧システムとの並行稼働。
  • 予算申請:初期費用と、3年分の利用・保守費、端末・通信費、社内プロジェクト工数を分けて示す

システム費用だけで投資を判断すると、導入担当者に業務が集中し、現場展開が遅れます。

ポイント

実額は人数や物件数、データ量で変わるため、費目ごとに前提を揃えて比べます。初期費用と月額・保守費を分けて見ると、判断しやすくなります。

委託先の選定と見積比較

知名度や安さだけでなく、ビルメンテナンスの業務理解と現場モバイルへの対応を確かめて選びます。そのうえで、契約から請求までのつながり、データ移行、既存システム連携、導入後の定着支援も見ます。

候補を3〜5社程度に絞り、同じRFPと同じ実データで提案してもらうと、機能の有無や提案力を比べやすくなります。

業界実績の確認(業務の深さ)

導入実績は、次のとおり確かめます。

  • 導入規模:拠点や利用者、物件数を尋ねる
  • 対象範囲:業務や帳票、連携内容の範囲
  • 利用状況:利用率や報告時間、請求締め、問合せ、追加費用、障害連絡

たとえば、東計電算のBillyは、見積や月次集計、作業予定・実績を扱います。建物別・業種別の損益も扱い、公開情報では約200社の導入実績を示しています。

ダイキン工業は、計画立案や作業管理、現場支援を業務範囲として示しています。また、査収、書類作成、集計も含めています(出典: 各社公式情報、2026年確認)。

参照先の導入企業の担当者に、初期データの整備量や現場の利用率、報告書の作成時間を尋ねます。さらに、請求の締めや問い合わせ対応、追加費用、障害時の連絡について、確認できるかも聞きます。

事例を紹介できない場合は、同じ業務を想定したデモやPoCの評価方法を示せるかで補います。業界特化の機能が多くても、現場で使われなければ投資効果は出ないためです。

見積の前提・範囲・除外項目の比較

要件定義から保守まで、工程ごとの行に分けて比べます。前半は、要件定義、設計、設定・開発、連携の行です。後半は、移行、テスト、教育、PM、保守の行です。

各行では、次の点を明記してもらいます。

  • 対象範囲:対象の画面や帳票、データ件数、拠点数
  • レビューと納品:レビューの回数、納品物、検収条件

標準機能と設定、追加開発、発注者の作業が分かれていれば、価格差の理由を説明できます。また、要件定義と移行が発注者の作業になっていないかも確かめます。

見積の範囲を比べるときは、次の作業が別作業として扱われていないかを確かめます。

  • データ整理:Excelの整理、物件の統合、設備番号の採番
  • 移行と帳票:写真の移行、帳票の調整

見積書と契約書で確かめるのは、次の項目です。

  • 追加要件:単価と変更承認
  • 期間と再委託:納期延長、再委託費
  • 継続費用:クラウド、保守、終了時の費用

価格以外の定着支援と撤退条件

定着支援は、次のとおり確かめます。

  • 現場支援:操作説明と、紙の運用や後日入力のルールを用意してもらう
  • 管理支援:管理者研修や問合せ窓口、利用状況の確認、改善会議
  • 契約終了:データ返却や移行、縮小・移行の条件を決めておく

稼働後の改善や、担当が替わるときの資料の引き継ぎも確かめます。支援の範囲と期間は、具体的に決めておきます。

クラウドの場合は、停止時の連絡や復旧の方法、バックアップを確かめます。解約後の保存期間やCSVなどでの返却、移行支援も確認します。一方、個別開発では、担当の交代、コードや設定の引き渡し、第三者保守、脆弱性修正の範囲を確かめます。

開始条件と撤退条件の両方を定めておくと、外注リスクを抑えられます。

ポイント

価格の安さより、業務理解、データ移行、定着支援を比べられるかで選びます。撤退条件まで定めておくと、外注リスクを抑えられます。

よくある質問(FAQ)

よくある質問を、RFPや社内の意思決定資料を作る際の確認項目として取り上げます。最適な答えは、業務量や契約形態によって変わります。

ビルメンテナンス管理システムの発注前に予算はいくら用意すべきですか?

小規模なSaaSなら、公開料金の例として初期数万円から30万円程度、月額数万円から検討できます。

個別開発なら、1業務のPoCで50万〜300万円、複数物件を含むパイロットで300万〜1,500万円程度を仮置きできます。

いずれも一般的な目安で、対象範囲と要件によって変わります。そのため、まずRFPで必須機能と対象拠点を定め、初期費用・運用費・社内工数を分けて、複数社から見積を取ります。

要件が曖昧なままでもシステム開発を外注できますか?

外注できますが、いきなり完成品の固定価格契約を結ぶより、現行業務調査や要件定義を先に委託する方法が安全です。

準委任で調査やプロトタイプを行い、仕様と検収条件が固まった機能から、請負や個別の契約へ移していきます。

発注者側も、現場の担当者をレビューに参加させ、期限までに判断できる体制を用意します。確定している部分と変更の多い部分は、分けて進めます。

既製のビルメンテナンス管理システムと個別開発はどちらがよいですか?

定型的な契約や作業、報告、請求を早く始めたいなら、業界特化SaaSやパッケージが向いています。独自の料金や承認、顧客ポータル、既存連携が差別化になるなら、追加開発や個別開発を検討します。

実データで予定から請求まで試して、現場の入力率と3年総額を確かめます。そうすれば、機能数だけで選ぶことを避けられます。

システムを導入すれば建築物衛生法への対応も完了しますか?

システムを導入した後も、法令に基づく維持管理は必要です。厚生労働省は、特定建築物の所有者や占有者などに、基準に沿った維持管理を求めています(出典: 厚生労働省「建築物環境衛生管理基準について」、2026年確認)。

空気環境や給排水、清掃、ねずみ等の防除も管理の対象です。システムは、計画や測定・点検、是正の記録を支えます。承認や報告、履歴検索の記録も支えます。

対象となる法令と自社の管理責任を確かめ、必要な項目と保存期間を要件に含めます。

まとめ

発注では、紙やExcel、電話、顧客帳票を洗い出し、契約、作業、報告、検収、請求から粗利までの流れを一本にまとめます。定型業務ならSaaSやパッケージ、独自の収益管理や連携が重要になるなら、追加開発や個別開発を選びます。

RFPで条件を揃え、段階契約と実データを使って、提案と見積を比べます。費用だけでなく、現場の負担や保守、移行、定着支援も確かめます。

発注前の確認項目の一覧

発注前には、確認項目を一つの資料にまとめます。対象物件や利用者、業務範囲、必須機能と将来機能を、資料の最初に並べます。

そのあとで、既存システムや移行、帳票の条件を書きます。権限やセキュリティ、KPI、予算、納期、検収条件も、同じ資料に入れます。

見積は、初期費用に加えて、月額や保守、端末、教育まで含めた総額で比べます。社内工数や追加開発、データ返却も、その総額に入れます。また、請負と準委任は、工程ごとに使い分けます。変更と責任の範囲は、契約に残します。

1拠点の実データによる効果と現場定着の確認

最初から全社のすべてを作り込まず、1物件・1契約・1協力会社で、予定作成から請求までを試します。そうすると、通信や写真、入力の負担といった現場の課題が見えてきます。顧客帳票や承認、データ移行の課題も、同じ試験で明らかになります。

  • 効果測定:請求漏れや報告書の作成時間、月末締め日数、粗利把握までの時間を、導入前後で比べる
  • 展開判断:効果を確かめた機能から拠点を広げていく

現場で記録が続き、管理者が判断でき、顧客へ正確に報告できる仕組みを定着させることが、機能を増やすことより大切です。

▼全体ガイドの記事
・ビルメンテナンス管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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