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

修繕管理システムの発注は、業務範囲とつなぐデータを整理し、発注形態と契約を比べ、現場での試行で確かめる順に進めます。この順序で進めると、過剰投資を防ぎ、定着にもつながります。

全体像は、修繕管理システム開発の完全ガイドでも扱っています。

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

修繕管理システムを外注する前に押さえる全体像

建物保有企業、ビルメンテナンス会社、工場で異なる修繕管理対象を3枚のパネルで示した図。
同じ修繕管理でも、施設の種類によって見る対象が変わります。

外注前に決めるのは、つなぐ業務とデータです。製品名や開発言語は、その後に比べます。施設の種類によって必要な機能は変わるため、対象を分けずに進めると、使わない機能に費用をかけたり、必要な機能が後回しになったりします。

建物・ビルメンテナンス・工場保全の区分

施設の種類によって管理対象は異なるため、次のように整理します。

  • 建物保有企業:物件、棟、フロア、部屋、設備、工事を階層で持つ
  • ビルメンテナンス会社:契約、点検、作業員、協力会社、報告、請求を扱う
  • 工場・プラント:設備停止の影響、部品、故障原因、保全周期、費用を重視

建物保有企業では、長期修繕計画や予算も結び付けます。ビルメンテナンス会社では、顧客や建物ごとの契約から、定期点検や作業員の割り当て、請求までを短時間で処理します。

三つの業務は重なる部分もあります。ただし、同じ要件として扱うべきではありません。たとえば、工場の設備IDや製造ライン停止時間が必要な企業には、建物計画が中心の製品では不足します。

RFPには、誰が何をどの頻度で扱い、どの判断に使うかを書き込みます。そうすると、候補会社の提案を同じ前提で比べられます。

台帳から中長期計画までのデータのつながり

修繕管理の価値は、台帳から検収までをつなぎ、次回の修繕判断に使える情報を残すところにあります。

  • 設備台帳:型式、設置場所、保証期限、メーカー、写真、図面を登録します。
  • 修繕履歴:不具合と点検を設備単位で結び、見積から検収までの費用を残します。

国土交通省は、保全台帳に建物概要や点検・確認結果、修繕履歴などを記録し、中長期計画に活用する考え方を示しています(出典:国土交通省「記録の整備」、2026年確認)。

発注時には、問い合わせ管理に加えて、設備廃止後の履歴参照と施設統合時のコード変更も決めておきます。写真や図面の保存年数もあわせて決めます。親子関係と履歴の保持方法を確認しておくと、導入後の作り直しを抑えられます。

発注形態の選び方

標準業務向けのSaaSや専門パッケージと、独自業務や基幹連携向けのカスタム開発を左右で比べた図。
標準機能で足りる範囲と個別開発が必要な差分を分けて考えます。

標準業務が多い場合は、SaaSや専門パッケージを優先します。一方で、独自業務や基幹連携が競争力に直結するなら、カスタム開発を検討します。

そのうえで、標準機能で満たせる範囲と開発する差分を分けると、費用と導入期間の両方に効きます。フルスクラッチは最初の候補にせず、差分が大きい場合に検討します。

SaaS・専門パッケージが向くケース

複数拠点の台帳や点検予定、修繕依頼を早く電子化するなら、SaaSや専門パッケージが候補です。作業報告や承認なども、電子化の対象に入ります。まず一施設か一事業部で試し、その後に展開できます。

  • 運用負担:サーバー構築や基本アップデートを自社で抱えずに済みます。
  • 現場入力:写真やチェックリスト、通信不安定時の一時保存をデモで必ず確認します。

設備HUBは公開料金として、6名以上で税込み月額2,980円、1〜5名は1名あたり月額4,980円を掲載しています(出典:設備HUB公式料金、2026年8月確認)。

初期費用は30,000円で、6名で1年間使う単純計算では、初期費用込みで244,560円です。これは一製品の公開料金で、データ移行、個別帳票、連携開発の相場を示すものではありません。

部分カスタム・フルスクラッチが向くケース

独自階層が複雑で、会計・購買・契約との連携や顧客ポータルが必要なら、部分カスタムやスクラッチが候補です。

  • 個別帳票:協力会社ごとの報告書を自動生成します。
  • 独自連携:オーナー別の承認と予算を連動させます。
  • 連携対象:IoTセンサー、BIM、CADも要件に応じて検討します。

標準設定だけでは対応しにくい個別要件は、個別開発の候補になります。ただし、独自仕様が増えると、初期費用に加えて保守やテストの負担が増えます。法令や帳票の変更、教育の負担も増えます。

標準機能、設定変更、個別開発に分けたうえで、業務上の差別化や入力・転記の削減に直結するものから開発対象を選びます。

ポイント

発注形態は、標準業務が中心ならSaaSや専門パッケージ、独自業務や基幹連携が競争力に直結するならカスタム開発で考えます。標準機能で足りる範囲と開発が要る差分を分けるのが判断の目安です。

RFPと要件整理の進め方

現状業務、要件の優先度、現場入力や権限などを3つのチェックカードにまとめた図。
提案を同じ条件で比べるための準備を並べています。

RFPは、希望を伝える資料であると同時に、自社業務を整理する資料でもあります。課題、利用者、業務フローを一つの文書にまとめ、データと非機能要件、納期と予算の考え方も書き込みます。

機能名だけを並べると、提案を比べにくくなります。また、未確定事項も明記しておくと、提案会社から確認の質問を受けやすくなります。

受付から請求までの現状業務の洗い出し

現場の流れは、受付から次回計画までの工程を順に並べて洗い出します。

  1. 受付と優先度判定
  2. 現地確認、見積依頼、承認、発注
  3. 作業、検収、請求、履歴登録、次回計画

各工程について、担当部署と承認者、期限を記録します。帳票や参照情報、例外処理も併せて残します。さらに、メール依頼のExcel転記や完了報告の別フォルダ保存も洗い出します。

要件は、MUST、SHOULD、WANTの三つに分けます。MUSTには、設備台帳と写真付き受付を置きます。そのほか、期限アラートと見積承認、作業報告、履歴検索などもMUSTに含めます。

一方で、WANTにIoTや高度な予測分析を詰め込むと、基本入力が習慣になる前にプロジェクトが複雑になります。

現場入力・権限・データ移行の要件

RFPでは、現場の入力環境、権限、移行データを合わせて確認します。

  • 現場入力:写真と位置、時刻に加えて、チェックとメモも扱います。
  • 通信対応:オフライン入力と写真圧縮、同期時の重複処理を確認します。
  • 端末管理:紛失時の遠隔ログアウトの可否

DK-CONNECT BMは、建物、契約、設備を扱います。そのほか、図面と作業結果、権限、モバイルにも対応します(出典:ダイキン工業「DK-CONNECT BM機能紹介」、2026年確認)。

権限は、会社や支店、物件の単位に加えて、建物、工事、役割ごとに設計します。協力会社には担当案件の情報だけを見せ、他社見積や個人情報、鍵・入退館情報は制限します。

ExcelとCSVの移行対象を決めます。画像、PDF、紙の移行対象も、同じ範囲で決めます。設備コードの重複や表記ゆれを直し、業務側が正とするマスタを承認します。

移行後に確認する担当者も定めておきます。データ移行を開発会社に任せきりにせず、社内で体制を組むことが必要です。

ポイント

RFPには、現状業務と要件の優先度、現場入力や権限、移行データを書きます。未確定事項も明記すると、提案会社からの確認質問を受けやすくなります。

契約形態(請負・準委任)の使い分け

要件が固まった開発は請負、検証しながら進める要件定義や改善は準委任と分けて組み合わせると、実務に合います。

請負は、成果物と完成責任を合意しやすい一方で、仕様変更を追加費用や納期の変更として扱います。準委任は、専門人材の作業や助言を得やすい契約です。完成を当然に保証するものではないため、範囲と評価方法を明確にしておく必要があります。

請負契約で確定させる項目

請負の完成条件を確かめられるように、契約書や仕様書に結び付ける項目をそろえます。

  • 仕様:要件定義書、画面・帳票、データ項目、連携仕様
  • 受入:テスト計画、受入条件、納品物、検収期限

完成を判定するには、「修繕管理を効率化する」より具体的な条件が要ります。たとえば、通知時間、Excel形式の報告書、権限別の閲覧範囲を確認条件にします。

変更要求が出たときは、画面やデータ、テストへの影響を評価します。費用と納期への影響も見て、承認者もあらかじめ決めておきます。

特に、帳票の細かな差分、例外的な承認、過去データの全件移行は、後から加わりやすく、開発の終盤では大きな追加作業になります。

準委任・保守契約で継続運用を決める項目

準委任や保守では、稼働条件と本番後に支援する範囲を先に決めておきます。

  • 準委任:月の稼働時間、スキル、定例会、成果物、課題表、意思決定者
  • 保守:障害、クラウド料、バックアップ、監視、脆弱性対応、追加改修

優先順位や業務ルールを決める責任は、発注側に残ります。業務責任者が会議に参加できないと、時間を確保しても判断が進みません。

データの所有権と、API・CSV出力の範囲を決めます。設計書や設定情報の引き渡し、解約時の返却も決めておきます。

SLA、復旧目標、再委託先の管理も契約に含めると、将来のベンダーロックインを抑えられます。

ポイント

要件が固まった開発は請負、検証しながら進める要件定義や改善は準委任が目安です。どちらも、完成条件や稼働条件、評価方法を契約書に書き込みます。

修繕管理システムの費用相場と見積内訳

価格は、利用人数と拠点数、台帳件数で変わります。移行、現場アプリ、帳票の範囲でも差が出ます。さらに、連携や権限の設定、セキュリティやサポート範囲も価格に影響します。

修繕工事費と管理システムの導入・開発費は別物です。見積が工事を含む業務委託なのか、システム費だけなのかを確かめます。

方式別の初期費用レンジ

方式ごとの概算は、公開料金と一般的な業務システム情報をもとにしています。

  • 汎用SaaS:標準利用なら初期0〜30万円程度、月額1人あたり3,000〜8,000円程度、期間2〜8週間が目安
  • 専門パッケージ:初期設定・移行込みで100〜500万円程度、期間2〜4か月程度が目安
  • 部分カスタム:クラウド業務システムで300〜1,500万円程度、期間4〜8か月程度
  • フルスクラッチ・大規模SI:1,500〜4,000万円以上、期間6〜18か月程度まで広がります

この数字は、NotebookLMの一般業務システム相場と公開料金を、機能範囲に合わせて推定したものです。修繕管理システムの公的な市場統計ではありません。実際の金額は、RFPと提案内容を照合して判断します。

見積書の開発費以外のコスト

見積書は、工程費と稼働後の費用を分けて、各社の範囲を比較できる形にします。

  • 開発工程:要件定義、基本設計、画面・帳票・連携開発、テスト、移行、教育、管理、リリース支援
  • 運用費:クラウド利用料、ユーザー課金、保守、バックアップ、監視、問い合わせ、追加改修

一式表記では、移行や帳票が後から追加請求になることがあります。そのため、月額・年額と追加改修も明記してもらいます。

費用が増えやすい項目は、データ名寄せや写真・PDF移行、階層の再設計です。さらに、個別帳票や協力会社ポータル、オフライン対応も費用が膨らみやすい項目です。

会計・購買との連携、IoT・BIM、SSO・多要素認証の対応状況も確認します。監査ログや24時間サポートについても、有無を確かめます。各項目は、標準と設定、開発、対象外に分けてもらいます。

ランニングコストと費用対効果の試算

月額利用料のほか、アカウントや容量の費用を見積もります。帳票やAPI、保守、端末の費用も試算に入れます。通信や教育、社内工数も、試算に含めます。

  • 作業時間:報告書作成が月80時間から40時間になるか測ります。
  • 検索時間:過去履歴の検索が一件あたり10分短くなるか確認します。
  • 業務指標:期限超過など自社で測れるKPIを定めます。

「DXで効率化する」という表現を、測れる指標に置き換えると、投資回収を判断しやすくなります。

初期費用が安くても、全拠点展開時のユーザー課金や管理者ライセンスで総額が上がることがあります。そのため、1年目、3年目、5年目の総保有コストを比べます。利用者増加、解約、他社移行時の費用も確認します。

ポイント

費用は、利用人数や拠点数、移行、帳票、連携の範囲で変わります。見積は開発費と運用費を分けて、各社の範囲をそろえて比べます。

委託先選定と見積比較のポイント

知名度や総額だけでなく、業務理解や定着支援を含めて比べます。移行や連携、保守、契約の透明性も、同じ基準でそろえます。

製品会社と業務システム設計会社、基幹連携に強い会社では、提案の強みが異なります。必要な役割ごとに分けて、候補を選びます。

修繕・保全に近い導入経験の確認

導入社数だけでなく、自社業務に近い実績の対象と規模を尋ねます。

  • 建物FM・ビルメンテナンス:階層、点検周期、履歴、協力会社、予算承認、現場報告の範囲
  • 工場保全:補修データや履歴を計画保全に使う方法

FMシステムは、富国生命保険相互会社の200棟を超える長期修繕計画事例を紹介しています(出典:株式会社FMシステム「導入事例」、2026年確認)。

株式会社TMEICは、部門ごとにExcelや伝票へ分散していた補修・修繕データを整理し、履歴から周期や必要コストを分析する設備保全事例を公開しています。

事例を評価するときは、同じ移行量や利用者構成で再現できるかを確かめます。社名で判断しないためです。

デモと提案書の同じ業務シナリオでの評価

自社に近いシナリオを使い、現場から履歴反映まで一続きで実演してもらいます。

  • 現場:写真付きで漏水を登録します。
  • 承認・発注:優先度決定、見積、承認、発注を進めます。
  • 完了後:報告、検収、履歴反映まで確認します。

スマートフォン入力や本部検索に加えて、承認通知と帳票出力も、同じ流れで見ます。

評価表には、機能適合と使いやすさ、移行、連携を入れます。権限、監査ログ、障害対応も加えます。支援、価格、納期も同じ表に並べます。

回答は、標準と設定、追加開発、対象外に分類してもらいます。後付けの費用と期間を確かめ、前提や将来の変更費用が明確な提案を評価します。

セキュリティと委託先管理の見積比較

図面や鍵・入退館情報、個人情報を扱うため、対策を確認します。契約金額や設備の弱点につながる記録も、扱う情報に入ります。

  • アクセス管理:多要素認証、権限分離、退職者アカウント無効化
  • 保護と復旧:監査ログ、暗号化、バックアップ、復旧訓練
  • 委託先管理:脆弱性対応と再委託先の管理方法

IPAの「情報セキュリティ10大脅威2026」は、外部委託先やサプライチェーンを含む脅威管理の視点を示しています(出典:IPA「情報セキュリティ10大脅威2026」、2026年確認)。

見積の項目名から対応範囲を読み取るのは難しいため、バックアップ世代数、復旧目標時間、復旧テスト時期を確認します。

クラウドでは、保管場所とログ保存期間を契約に記します。障害連絡や脆弱性の通知、修正の責任分担も記します。

ポイント

委託先は、修繕や保全に近い導入経験、同じシナリオでのデモ、後付け費用をそろえて比べます。社名だけで決めず、同じ移行量で再現できるかを確かめます。

外注後の導入・運用を成功させるポイント

納品のあとも運用を続け、現場入力から本部判断、協力会社の報告、計画への反映までを回します。パイロットで入力負荷とデータ品質を確かめ、改善してから全社へ段階展開します。

一施設・一事業部からのパイロット導入

業務量が多すぎず、現場と本部が協力しやすい施設や事業部を選び、実際の案件で試します。

  • 試す業務:台帳、受付、写真、見積承認、作業報告、検収
  • 並行運用:紙やExcelを併用する期間を設けます。
  • 初期目標:期限超過と転記の削減に集中します。

効果測定では、導入前後で報告書作成時間や未処理件数、期限超過件数を比べます。修繕依頼から初回対応までの時間と再訪率も、同じ条件で比べます。さらに、修繕費の予実差と過去履歴の検索時間も、導入前後で確かめます。

入力率だけをKPIにすると、形式的な登録が増えるおそれがあります。登録したデータが承認や予算計画に使われたかも追います。

運用ルールと教育の発注範囲

入力ルールが人によって違うと、データを比べられません。操作研修に加えて、運用支援も発注範囲に含めます。

  • 運用資料:マニュアル、入力ルール、権限申請
  • 管理手順:異動・退職時の処理、問い合わせ、障害連絡

設備名や優先度の付け方、写真の扱いを揃えます。完了の定義や見積承認者も揃えておかないと、記録を比べられません。

役割は、業務責任者とシステム管理者、現場リーダーに分けます。会計・購買や情報セキュリティの担当も、別に決めます。

要望窓口と優先順位の決定者も分けておくと、追加要望が膨らみにくくなります。月次では、KPIと課題を確認し、保守範囲内の修正と追加開発を切り分けながら、委託先と改善を続けます。

よくある質問(FAQ)

方式と期間、見積、データに関する疑問をまとめます。自社の条件で答えが変わる質問は、候補会社への確認にも使えます。

修繕管理システムはSaaSと開発のどちらがよいですか?

台帳や点検、受付が中心で、報告や履歴も含むなら、まずSaaSや専門パッケージを比べます。

独自階層や承認が不可欠で、帳票や会計・購買連携も必要なら、部分カスタムを検討します。差分が大きければ、スクラッチを選びます。

修繕管理システムの発注から稼働まで何か月かかりますか?

標準SaaSは2〜8週間、専門パッケージの設定・移行は2〜4か月、部分カスタムは4〜8か月が概算です。

フルスクラッチや多数拠点・複数連携では、6〜18か月以上になることもあります。

要件整理や移行、現場テスト、承認者の確認が遅れると、開発期間の短縮では埋めきれません。また、社内の意思決定日程も最初に確保しておきます。

複数社の見積はどのように比較すればよいですか?

同じRFPと業務シナリオを渡し、標準と設定、追加開発、対象外を揃えて比べます。

移行や教育、保守を含めて、1年目・3年目・5年目の総額を見ます。さらに、追加ユーザーや帳票変更、連携、解約時の返却も総額に含めます。

金額差が大きい場合は、安い提案の前提と、高い提案に含まれる作業を先に確認します。

過去のExcelや紙の修繕履歴も移行できますか?

移行できる場合もありますが、元の形式のまま取り込めるとは限りません。

設備コードや物件名、業者名を整理し、費用科目や日付、写真の紐付けも整えます。そのうえで、重複や表記ゆれを直します。

まず、検索の対象にする年数を決めます。紙の履歴は、全件をスキャンするか、重要な履歴だけにするかも決めておきます。そのうえで、サンプル移行で検索と表示を確かめてから、本移行に進みます。

まとめ

まず対象業務を決め、受付から請求、中長期計画までの流れを洗い出します。そのうえで、台帳、点検、履歴をRFPに書き込みます。承認や報告、権限に加えて、移行と連携もRFPに記しておきます。

発注時の方式・契約・費用の判断

標準業務ならSaaSや専門パッケージ、独自業務や連携が大きければ部分カスタム、固有要件が広ければスクラッチを検討します。

請負と準委任は、開発内容に応じて組み合わせます。受入や変更管理、保守の条件は契約で明確にします。データ所有権と解約時の返却も、同じ契約に書き込みます。

公開料金、相場推定、要見積を区別し、初期費用だけでなく5年間の総保有コストで比べます。

最初の一歩となる現場シナリオと比較表の作成

実案件のデモでは、現場入力や承認、協力会社の報告を確認します。帳票や履歴検索も、同じデモで見ます。試行は、一施設か一事業部で行います。

報告書作成時間や期限超過、未処理件数のKPIを測り、検索時間や予算実績も確かめてから展開します。発注側が判断を持ち、委託先と運用を改善します。

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

会社紹介

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

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

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

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

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

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