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

施設管理システム開発は、現場業務の整理から始め、方式の選定、設計・開発、テストを経て、稼働と定着へ進みます。段階を踏むと、手戻りを抑えながら現場に定着させやすくなります。全体像は、施設管理システム開発の完全ガイドでも確認できます。

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

施設管理システム開発の出発点|全体像

施設管理システムの要件を整理する5つの観点を示した図
施設と運用の条件を同じ観点で見渡せます。

施設管理システム開発では、施設ごとの業務とデータを、製品を選ぶ前に洗い出します。先に洗い出しておくと、後の選定や設計で手戻りを抑えられます。

施設管理には、予約、保全、資産台帳といった業務が含まれます。契約・修繕やエネルギー管理も、同じ施設管理の一部です。そのため、業務ごとに必要な機能も変わります。

施設管理の対象の3タイプ

対象施設によって中心となる業務は異なります。主な違いを押さえておくと、必要な機能を整理しやすくなります。

  • 公共施設・学校・文化施設:予約、抽選、利用料金、減免、承認、団体管理、帳票出力
  • ビル・不動産・企業施設:建物・設備台帳、図面・仕様書、点検、不具合、修繕、委託先、契約、長期修繕計画
  • 工場・病院・大学など:多拠点管理に加え、資産、入退室、防災、エネルギー、BMS・IoT・ERP連携

公共施設では、空き状況を公開して利用者がWebから申し込めるようにし、窓口の承認から会計や請求までつなげます。一方で、多拠点施設では、設備管理に加えて他システムとの連携も検討します。

5つの軸による機能の絞り込み

施設と運用の条件を同じ軸で整理すると、要件を絞り込めます。特に現場の人数と既存システムとの関係は、機能の選定に影響します。

  • 施設の種類:予約、保全など、中心となる業務
  • 管理棟数・設備点数:台帳と集計の範囲
  • 現場人数:入力方法と権限
  • 法定点検:記録と報告に必要な要件
  • 既存・将来の連携:接続先と連携範囲

たとえば、1棟の事務所で点検報告が課題なら、モバイル入力と写真・帳票管理を優先します。これに対して、複数拠点で修繕予算を比べる企業は、共通コード、契約・発注、LCC分析まで見据えます。

共通機能には、施設や設備の台帳、点検の予定と実績、故障と修繕の履歴があります。写真や図面、報告書の管理も含まれます。加えて、権限、操作ログ、通知も要件に含めます。

特に法定点検では、点検日や測定値、担当者を後から検索できるようにします。是正内容と報告書も、検索できる状態で残します。

ポイント

どの施設タイプに近いかで中心となる業務が決まり、そこから必要な機能を絞り込めます。法定点検や既存システムとの連携は、絞り込みの段階で条件を洗い出しておくと、手戻りを抑えられます。

施設管理システム開発の進め方|6つのフェーズ

要件整理、選定、設計・開発、テストの順に進む開発前半の工程図
現場業務の確認が後続工程の出発点になります。

開発では、まず現場の入力負担と過去データの品質を確かめます。続けて、施設ごとの例外や既存システムとの境界も順に見ます。判断を記録し、対象の施設や業務を区切って検証すると、手戻りを抑えやすくなります。

1. 要件整理:現場業務とデータの把握

担当者へのヒアリングに加えて、巡回や予約受付、故障連絡の流れを観察します。修繕発注と月次報告の流れも、同じ観点で見ます。紙の点検表をExcelへ転記している場合は、入力項目以外も確認します。

  • 現場の手順:写真を撮る場所や異常時の連絡先
  • 承認と例外:承認者、再点検、設備不明、予約重複、緊急修繕
  • 業務とデータ:業務一覧、施設・設備項目、権限、連携先
  • 優先順位:法令対応、台帳、点検、報告、バックアップなど業務停止に直結するものをMUSTに設定

業務フロー図には、通常時の流れに加えて、設備が見つからない場合や予約が重複する場合も記載します。緊急修繕の発生も、例外として扱います。

AI予測やBIM、スマートロックなどはWANTに分けます。詳細分析もWANTとして扱います。MUSTは初回リリースに集め、WANTは第2段階以降に回すと、予算と納期を守れます。

2. 選定:パッケージ、クラウド、スクラッチの比較

方式によって、導入の速さや運用負担、自由度は異なります。そこで、自社の業務やネットワーク条件に合わせて比べます。

  • パッケージ・SaaS:標準機能で早く始められ、更新や脆弱性対応も受けやすい
  • クラウド:多拠点、モバイル、リモート保守に向く
  • オンプレミス・専用環境:ネットワーク分離が必要な工場などで候補になる
  • 受託・スクラッチ:独自予約、複雑な保全、深い統合、制御系連携に向く

クラウドでは、ユーザー課金か棟数課金かを確かめます。加えて、データ出力、障害時の連絡、バックアップの保持期間も見ておきます。

オンプレミスでは、サーバーの更新やパッチ、BCPは、運用要員と合わせて自社の責任範囲になります。

自由度の高い開発は要件が膨らみやすいため、標準機能と追加開発の境界も確認しておきます。

ベンダーには、実画面のデモや類似施設の導入事例を求めます。API仕様と、契約終了時のデータ返却条件も質問します。価格だけでなく、現場が1日で習得できるかも評価します。

3. 設計・開発:入力と履歴をつなぐデータ構造

設計では、施設情報と現場の入力、履歴がつながるデータ構造を決めます。

  • 管理対象:施設、棟、フロア、部屋、設備、点検、作業、契約、業者、文書の関係
  • 設備コード:共通コードと旧番号の対応表
  • 写真・PDF:設備ID、撮影日、作業種別、担当者で検索できる属性
  • 現場入力:スマートフォン・タブレットで片手操作でき、通信が不安定な場所でも入力途中のデータを失わない仕組みを検討
  • 異常時の流れ:写真添付、一次対応、上長承認、業者依頼、完了確認

BMS・IoT・会計・入退室との連携では、頻度とエラー時の再送を設計書に明記します。あわせて、責任部署、個人情報、制御ネットワークの分離も決め、連携先ごとの運用責任を明確にします。

4. テスト:現場の例外を含めた検証

画面の表示だけでなく、実業務のシナリオで検証します。たとえば、施設の追加・統合・廃止や設備の移設を試します。点検期限の超過と緊急修繕も、シナリオに含めます。

  • 予約業務:取消や減免の扱い
  • 権限と記録:図面・個人情報の閲覧制限と操作ログ
  • 復旧:バックアップからのデータ復元の可否
  • 受入テスト:関係部門と代表者による合格条件と課題の確認

受入テストには、現場作業者、予約窓口、経理の担当が参加します。情報システムと委託業者の代表者も加わります。ケースごとに担当者、期限、未解決の課題を記録し、重要度を分けます。

移行後は、旧台帳との突合件数を決めてから、設備点数や点検履歴の数字を承認します。契約期限と帳票の数字も、同じ手順で扱います。

5. 稼働:並行運用と切り替え条件の決定

本稼働へ進む前に、試験稼働の時期と期間を決めます。切り替えの準備も、あわせて整えておきます。

  • 稼働準備:初期データ、アカウント、権限、問い合わせ窓口、障害時の連絡網の用意
  • 先行稼働:紙やExcelから全施設を一度に切り替えるのが不安なら、1施設または1業務で試し、旧運用と一定期間並行して比較
  • 切り替え時期:月末、年度末、大規模イベント、法定点検の繁忙期を避け、停止可否を整理
  • 標準設定:導入期間は1〜3か月が目安
  • 複数施設のクラウド導入:連携とデータ移行を含めて3〜6か月が目安

カスタマイズを含む施設向け構築は6〜12か月が目安です。

ニッセイコムは、GrowOne 施設について最短6か月、カスタマイズ時は12か月程度の場合があると案内しています(出典:株式会社ニッセイコム公式FAQ、2026年確認)。

この期間は、要件確定や移行、テスト、教育を含めた計画として見積もります。製品の納期とは分けて考えます。

6. 定着:KPIと改善会議の運用への組み込み

稼働後は、ログイン数だけでなく業務の成果をKPIにします。導入前の1か月を基準値として残しておくと、1・3・6か月後と比べて変化が分かります。

  • 点検:実施率と期限超過件数
  • 修繕:受付から完了までの日数
  • 報告:報告書の作成時間
  • データ:紙からの転記件数と設備情報の未登録件数

数値が改善しない場合も、機能が足りないと決めつける前に、入力項目や権限、現場の通信環境に原因がないかを確かめます。

月1回の改善会議では、要望を「法令・安全」「業務停止」「効率化」「便利機能」に分類し、改修の優先順位を決めます。

管理者が異動・退職したあとも運用が続けられるよう、操作手順やデータ更新、権限申請を文書にしておきます。障害時の手動手順も、あわせて残します。そのうえで、短い動画や操作カードを用意し、新任者が基本操作を一人で完了できる状態を目指します。

ポイント

要件整理でMUSTとWANTを分け、稼働前に切り替え条件を決めておくと、後の工程で判断に迷いにくくなります。定着の段階では、導入前の基準値を残しておく必要があります。

施設管理システム開発の費用相場とコストの内訳

初期開発費における要件定義・現地調査、設計、開発、テストの割合を並べた図
開発の比率が他の工程より大きい目安を読み取れます。

費用は、施設数や設備点数だけでなく、業務範囲やデータ品質、連携数、現地作業の有無で変わります。また、予約、保全、契約、会計、IoTのどこまで扱うかも影響します。

施設管理に特化した公的な費用統計は確認できていません。そのため、以下の数字は、公開価格、近い業務システムの相場、導入事例から組み立てた目安として読んでください。発注時は、同じ条件で複数社から見積もりを取ります。

構築パターン別の費用レンジ

構築規模とカスタマイズの範囲によって、費用と期間は変わります。まずは、自社の対象業務に近いレンジを比較の起点にします。

  • 小規模SaaS・標準パッケージ:初期0〜100万円程度、月額数千円〜数十万円、1〜3か月
  • クラウド+設定・連携・移行:初期100万〜1,000万円程度、3〜6か月
  • 中規模カスタマイズ:1,500万〜4,000万円程度、6〜12か月
  • 大規模スクラッチ・設備連携:4,000万円超の場合があり、1年以上の計画になることもある

小規模の目安は、1〜数施設で予約、台帳、報告書など標準機能を使う場合です。ただし、初期費用が低くても、ユーザー追加や帳票、移行、研修が別料金になる場合があります。

中規模では、予約や設備保全、契約・予算、会計を統合します。複数拠点の管理も、同じ仕組みに含めます。さらに大規模では、BMSやIoT、BIM、入退室、防災との連携が加わる場合があります。

価格構造の実例として、ダイキン工業は2022年のDK-CONNECT BM発売時に料金を公表しました。初期環境構築料金は40万円(税抜)、年額ユーザーライセンス料金は36万円(税抜)です(出典:ダイキン工業ニュースリリース、2022年)。

この金額は、現行の個別見積を保証するものではありません。初期設定費と年額ライセンスを分ける例として読みます。現行の公式ページでは、2025年のv1.5.0リリースや2026年の情報も確認できるため、機能と料金は最新の条件で確かめます。

初期費用以外に発生するコスト

初期開発費の内訳と保守費の範囲を分けて見ると、見積もりを比べやすくなります。なお、以下は施設管理専用ではなく、業務システム全般の目安です。

  • 工程配分:要件定義・現地調査は全体の10%前後、設計は10〜20%と説明されることがある
  • 開発・テスト:開発40〜60%、テスト10〜20%
  • 人月単価:エンジニアは月額80万〜120万円程度
  • 保守運用:初期開発費の5〜15%程度

契約期間や対応時間、月額・年額の表記によって、費用の意味は変わります。したがって、これらの数字は概算の比較材料として扱います。

見落とされやすい費用には、現地調査、台帳の名寄せ、帳票の作り直しがあります。紙やExcel、CAD、PDFからの移行も、費用として見込んでおく必要があります。

そのほか、研修やタブレット、IoT機器にかかる費用も確認します。ネットワークの整備や脆弱性診断、24時間対応についても、費用の範囲を尋ねておきます。

保守費は、問い合わせ時間や障害の初動時間、更新の範囲を項目ごとに記載してもらいます。バックアップやデータ返却の扱いも、別の項目で示してもらいます。5年間の総保有コストで比べると、初期費用だけでは見えない差が分かります。

ポイント

費用は業務範囲や連携数、現地作業の有無で変わるため、構築パターンの目安は比較の起点として使います。初期費用に加えて、保守やライセンス、追加開発の費用まで含めて比べます。

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

見積もりの精度は、依頼書に書く前提条件で決まります。「施設管理をデジタル化したい」とだけ伝えると、各社の見積もりの範囲がそろわず、比較できなくなります。

依頼書には、施設数や設備点数、利用者数を書きます。現場人数や既存データの形式、連携先も、同じ資料に入れておきます。導入希望時期は、帳票や法定点検、権限と並べて示します。

1枚の依頼書への要件の集約

依頼書は一枚にまとめ、課題と対象範囲、利用者を先に書きます。続いて、データと連携、非機能要件を記し、導入後の支援も加えます。機能名を並べるより、業務シナリオで書くと、提案を比べやすくなります。

  • 背景と範囲:解決したい課題、対象施設・業務
  • 利用とデータ:MUST・WANT、役割、移行、外部連携
  • 運用要件:非機能要件、導入後の支援範囲

たとえば、「巡回中にスマートフォンで異常と写真を登録し、帰社後に転記せず上長へ通知する」のように、業務の流れで書きます。

非機能要件には、稼働時間、同時利用者数、応答時間を含めます。バックアップと復旧目標も、書いておきます。認証は多要素認証を含め、操作ログも記載します。

データ保存場所、脆弱性対応、障害通知も明記します。設備をネット接続する場合は、業務クラウドと制御ネットワークを分けます。IoT機器については、セキュリティ評価やラベルも調達条件に含めます。

経済産業省は、2025年3月版のJC-STAR制度活用ガイドでビルシステムを例示しています。機器連携のある案件では、この資料が確認材料になります(出典:経済産業省、2025年)。

複数社の同条件での比較

各社の費目、料金条件、導入支援を同じ比較表で見ます。価格の対象範囲を分けると、見積もりのどこに差があるかが分かります。

  • 費用項目:初期費用、ライセンス、保守、追加開発
  • 導入費用:移行、教育、機器、現地作業
  • クラウド課金:ユーザー数、棟数、容量、API利用数
  • 開発条件:工程別工数、前提、除外項目、変更単価

開発会社には、標準機能と追加開発を色分けした機能一覧も出してもらいます。料金が変わる条件をそろえてから比べます。

施設の種類が近い事例を確かめます。公共施設の予約なら、予約から料金消込までをデモしてもらいます。ビル管理では点検、不具合、報告書、設備保全では設備点数と写真・図面の管理を実演してもらいます。

開発後の担当者が保守にも関わるのか、導入支援の責任者は誰なのかを確かめます。契約終了時の設計書とデータ返却も、価格と同じ重さで評価します。

追加費用と契約上のリスクの事前確認

見積もりから除外された作業があると、後から費用が増える場合があります。特に、現地調査とデータ整備、帳票は範囲を確かめます。テストや研修についても、範囲を確かめます。

  • 移行・稼働:休日切り替え、旧システムとの並行運用
  • 一式表記:対象件数、納品物、担当者、回数、完了条件
  • 変更管理:承認手順と追加費用なしの軽微修正

請負と準委任では、成果物と変更リスクの分け方が異なります。要件が固まっていない段階では、初期調査を別工程にして、段階的にリリースする方法もあります。

契約には、検収条件と瑕疵対応、サービスレベルを明記します。障害時の責任分界と再委託の扱いも、書いておきます。さらに、データの所有権や、ソースコードと設計書の取り扱い、契約終了時の移行支援も定めます。

ポイント

見積もりを比べる前に、施設数や設備点数、現場人数などの前提条件を同じ依頼書でそろえておきます。前提条件がそろっていないと、各社の見積もりの範囲が異なり、比較できなくなります。

よくある質問(FAQ)

施設管理システムの選び方は、対象業務と施設の条件によって変わります。ここでは、開発期間や方式の選び方、法定点検、セキュリティに関する疑問に答えます。

施設管理システムの開発期間はどれくらいですか?

標準設定中心なら1〜3か月、連携・移行を含むクラウド導入なら3〜6か月、カスタマイズ開発なら6〜12か月が目安です。

期間は、施設数やデータ整備の状況によって変わります。法定点検の周期や現場教育、並行運用も影響します。そのため、製品の導入だけでなく、要件整理から定着までを一つの計画として立てます。

パッケージとスクラッチ開発はどちらがよいですか?

標準的な機能に業務を合わせられるなら、パッケージやSaaSが適しています。予約や台帳、点検のほか、報告書も対象になります。

独自の予約や複雑な保全が競争力に直結するなら、カスタマイズやスクラッチを検討します。基幹システムとの深い統合や制御系連携が安全性に関わる場合も、同じ考え方です。

最初から全機能を作り込まず、共通業務は標準機能で始めて、差別化の部分を段階的に追加する方法も有効です。

システムは法令適合を自動で保証しませんが、点検情報を記録・検索する基盤として使えます。

  • 記録する情報:測定結果、点検日、担当者、是正内容、報告書

厚生労働省は、特定建築物の所有者などに、建築物環境衛生管理基準に沿った維持管理を求めています。基準の対象は、空気環境と給水・排水です。清掃や、ねずみ・昆虫などの防除も含まれます(出典:厚生労働省「建築物環境衛生管理基準について」、2026年確認)。

対象法令や測定項目は、専門の担当者と確かめて要件にします。保存期間と報告者も、同じ手順で要件に入れます。

クラウド型の施設管理システムは安全ですか?

安全性を左右するのは、対策を誰が担うかです。そこで、サービス提供者と自社の担当を分けて確認します。

  • アクセス管理:多要素認証と最小権限
  • データ保護:通信・保存時の暗号化とバックアップ
  • 運用対策:操作ログ、復旧テスト、脆弱性対応
  • 事故対応:インシデント通知と委託先管理

IPAは、クラウドサービスには事業者に委ねる対策があると説明しています。このため、利用前に安全利用の確認項目を整理しておく必要があります(出典:独立行政法人情報処理推進機構、2025年確認)。

まとめ|施設管理システム開発を成功させる進め方

施設管理システム開発は、要件整理から定着まで6段階で進みます。まず、施設タイプや棟数・設備点数、現場人数を整理し、法定点検や既存・将来の連携も確かめます。

MUSTとWANTを分けておくと、過剰なカスタマイズや予算超過を防ぎやすくなります。

成功のための最終チェックリスト

確認項目は、発注前と稼働前で分けておきます。対象範囲、データ、運用準備の見落としを防ぐためです。

  • 発注前:対象業務・施設、例外処理、移行件数と品質
  • 方式と費用:標準機能と追加開発、ライセンスと保守条件の区別
  • 稼働前:権限、ログ、バックアップ、復旧、受入テストの状況
  • 運用準備:並行運用、教育、障害時の手動手順の準備

1施設・1業務からの現状整理

対象を小さく決めたうえで、現状の整理から導入後の改善までを一つの流れとして考えます。

  • 対象を選ぶ:全施設を一度に切り替えず、課題が明確で効果を測りやすい1施設・1業務から始める
  • 現状を整理する:現状フロー、台帳、帳票、権限、連携を確認する
  • 複数社を比べる:同じ条件でデモ、移行方針、5年間の総コスト、稼働後の支援体制を比較する
  • データを活用する:導入時よりも、点検・修繕・予約・報告の記録が継続して蓄積され、次の判断に使われると価値が高まる
  • 運用を改善する:完成をゴールにせず、入力負担を減らしながらKPIと改善会議を続ける

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

会社紹介

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

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

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

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

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

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