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

修繕管理システムの発注・外注は、単に修繕依頼を登録する画面を作ることではなく、台帳、点検、見積、承認、発注、作業、検収、請求、履歴、次回計画までの流れを一つの業務設計にまとめる取り組みです。自社の業務範囲と現場の使い方を先に整理し、標準サービス、パッケージ、部分カスタム、フルスクラッチの順に適合性を比べることが、過剰投資を防ぐ基本となります。

「どの発注形態が自社に合うのか」「RFPには何を書けばよいのか」「請負と準委任のどちらにすべきか」「費用相場はどのくらいか」と迷う担当者は少なくありません。この記事では、施設保有者、不動産管理会社、ビルメンテナンス会社、工場・プラントの保全部門を想定し、発注前の要件整理から委託先の比較、契約、見積評価、導入後の定着までを順に解説します。

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

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

修繕管理システムの外注で最初に決めるべきことは、製品名や開発言語ではなく、どの業務とデータをつなぐかです。施設の種類によって必要な機能が変わるため、対象を切り分けずに発注すると、使わない機能に費用をかけたり、現場で必要な機能が後回しになったりします。

マンションや複数の建物を保有する企業では、物件、棟、フロア、部屋、設備、修繕工事を階層化し、長期修繕計画や予算と結び付けることが重要です。ビルメンテナンス会社では、顧客や建物ごとの契約、定期点検、作業員の割り当て、協力会社への依頼、報告書、請求までを短時間で処理する必要があります。工場やプラントでは、設備停止の影響、部品、故障原因、予防保全の周期、保全費用を重視します。

この三つは重なる部分もありますが、同じ要件として扱うべきではありません。たとえば、工場の設備IDと製造ラインの停止時間を管理したい企業に、建物の長期修繕計画だけを得意とする製品を導入しても不足します。RFPの冒頭で「誰が、どの対象を、どの頻度で、どの判断に使うのか」を明記すると、候補会社から比較しやすい提案が返りやすくなります。

修繕管理の価値は、受付件数を数えることだけではありません。設備台帳に型式、設置場所、保証期限、メーカー、写真、図面を登録し、不具合受付と点検結果を設備単位で結び付け、見積・発注・作業・検収の費用を履歴として残すことで、次回の修繕判断に使える情報になります。国土交通省も保全台帳に建築物の概要、点検結果、確認結果、修繕履歴などを記録し、中長期保全計画に活用する考え方を示しています（出典：国土交通省「記録の整備」、2026年確認）。

そのため、発注時には「問い合わせ管理」だけでなく、データの親子関係と履歴の保持方法を確認します。設備を廃止した後も過去の修繕履歴を参照できるのか、施設を統合したときにコードを変更できるのか、写真や図面を何年保存するのかまで決めておくと、導入後の作り直しを抑えられます。

発注形態はどれを選ぶべきですか？

結論から言えば、標準業務が多い場合はSaaSや専門パッケージを優先し、独自業務や既存基幹との深い連携が競争力に直結する場合にカスタム開発を検討します。最初からフルスクラッチを選ぶのではなく、標準機能で満たせる範囲と、外注して作るべき差分を分けることが費用と導入期間の両方に効きます。

複数拠点の台帳、点検予定、修繕依頼、作業報告、承認など、業界で共通する業務を早く電子化したいなら、SaaSや専門パッケージが候補です。サーバー構築や基本的なアップデートを自社で抱えずに済み、まず一施設または一事業部で試してから展開できます。現場がスマートフォンで写真やチェックリストを入力できるか、通信が不安定な場所で一時保存できるかは、デモで必ず確認します。

公開料金の例として、設備保守会社向けの設備HUBは、6名以上で税込み月額2,980円、1〜5名で1名あたり月額4,980円、初期費用30,000円を掲載しています（出典：設備HUB公式料金、2026年8月確認）。6名で1年間利用する単純計算では、初期費用を含めて244,560円です。ただし、これは一つの製品の公開料金であり、データ移行や個別帳票、連携開発の相場を示すものではありません。

物件・設備・工事の独自階層が複雑で、会計、購買、契約、顧客ポータル、IoTセンサー、BIMやCADと連携する必要がある場合は、クラウド業務システムの部分カスタムやスクラッチ開発が候補です。たとえば、協力会社ごとに異なる報告書を自動生成し、オーナー別の承認ルートと予算を連動させる要件は、標準設定だけでは対応しにくいことがあります。

一方で、独自仕様を増やすほど、初期費用だけでなく保守、テスト、将来の法令・帳票変更、担当者の教育負担も増えます。専門パッケージの標準機能を使う部分、設定変更で対応する部分、開発する部分を三つに分け、開発対象は「業務上の差別化」や「入力・転記の削減」に直結するものから選ぶことが現実的です。

RFPと要件整理はどのように進めますか？

RFPは、開発会社に希望を伝える資料であると同時に、自社の業務を整理するための資料です。機能名を並べるだけでは提案の比較が難しいため、現状の課題、利用者、業務フロー、データ、非機能要件、納期、予算の考え方を一つの文書にまとめます。すべてを確定できなくても、未確定事項を明示すれば、提案会社から確認質問を受けやすくなります。

まず、現場で起きている流れを、受付、優先度判定、現地確認、見積依頼、承認、発注、作業、検収、請求、履歴登録、次回計画の順に書き出します。それぞれについて、担当部署、入力する帳票、参照する情報、承認者、期限、例外処理を記録します。メールで受けた依頼をExcelに転記し、完了報告を別の共有フォルダに保存しているなら、その二重入力と検索時間がシステム化の対象です。

要件は、初期リリースに必須のMUST、できれば実現したいSHOULD、将来検討するWANTに分けます。MUSTには、設備台帳、写真付きの不具合受付、期限アラート、見積承認、作業報告、履歴検索など、業務を止めないための機能を置きます。WANTにIoTや高度な予測分析を詰め込みすぎると、現場が基本入力を習慣化する前にプロジェクトが複雑になります。

現場担当者がスマートフォンやタブレットで、写真、位置、時刻、チェック結果、作業メモを入力できることは重要です。ただし、現場の通信環境が安定しているとは限りません。オフライン入力の可否、写真の圧縮、後から同期した際の重複処理、端末紛失時の遠隔ログアウトをRFPで確認します。ダイキン工業のDK-CONNECT BMも、建物・契約・設備・図面・作業結果・権限・モバイルを業務・データ管理の対象として示しており、修繕管理では複数の情報を連続させる設計が一般的な期待になっています（出典：ダイキン工業「DK-CONNECT BM機能紹介」、2026年確認）。

権限は、会社、支店、物件、建物、工事、役割の単位で設計します。協力会社には担当案件の作業情報だけを見せ、他社の見積や個人情報、鍵・入退館情報を見せない運用が必要です。また、Excel、CSV、画像、PDF、紙から何を移行するのか、設備コードの重複や表記ゆれをどう直すのか、移行後に誰が確認するのかを決めます。データ移行は開発会社に丸投げせず、業務側が正とするマスタを承認する体制にします。

契約形態は請負と準委任のどちらを選びますか？

契約形態は、要件が固まっている開発部分を請負、検証しながら進める要件定義や改善部分を準委任とする組み合わせが実務に合いやすいです。請負は成果物と完成責任の範囲を合意しやすい一方、仕様変更を追加費用や納期変更として扱う必要があります。準委任は専門人材の作業や助言を得やすい一方、成果物の完成を当然に保証する契約ではないため、作業範囲と評価方法を明確にします。

請負契約を結ぶなら、要件定義書、画面・帳票一覧、データ項目、連携仕様、テスト計画、受入条件、納品物、検収期限を契約書や仕様書に紐付けます。「修繕管理を効率化する」といった抽象的な目的だけでは、完成の判定ができません。たとえば、受付登録から担当者通知までが何分以内か、写真付き報告書を指定のExcel形式で出せるか、権限ごとの閲覧範囲を満たすかなど、確認できる条件に落とします。

変更管理の手順も必須です。変更要求を受けたら、影響する画面、データ、テスト、費用、納期を評価し、誰が承認するかを決めます。特に、現場ヒアリングの後で追加されやすい「帳票の細かな差分」「例外的な承認ルート」「過去データの全件移行」は、開発の終盤に入ると大きな追加作業になります。

準委任で要件定義や改善を進める場合は、月ごとの稼働時間、担当者のスキル、定例会、成果物、課題管理表、意思決定者を明記します。外注先が作業していても、優先順位や業務ルールを決める責任は発注側に残ります。自社の業務責任者が会議に参加できない場合は、準委任契約で時間だけを確保しても判断が進みません。

本番稼働後は、保守の対象を開発費と分けます。障害対応、クラウド利用料、バックアップ、監視、脆弱性対応、OSやブラウザへの追随、軽微な設定変更、追加開発をそれぞれ確認します。データの所有権、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と提案内容を照合して判断します。

見積書は、要件定義、基本設計、画面・帳票開発、連携開発、テスト、データ移行、教育、プロジェクト管理、リリース支援に分けてもらいます。さらに、クラウド利用料、ユーザー課金、保守、バックアップ、監視、問い合わせ対応、追加改修を月額または年額で記載してもらいます。一式表記だけでは、安く見えていた移行や帳票が後から追加請求になることがあります。

費用が膨らみやすいのは、古いExcelの名寄せ、写真・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なら2〜8週間程度、専門パッケージの設定・移行なら2〜4か月程度、部分カスタムなら4〜8か月程度が概算の目安です。フルスクラッチや多数拠点・複数システム連携では6〜18か月以上になることもあります。要件整理、データ移行、現場テスト、承認者の確認が遅れると開発期間だけでは短縮できないため、社内の意思決定日程も最初に確保します。

同じRFPと業務シナリオを渡し、標準機能、設定、追加開発、対象外をそろえて比較します。初期費用だけでなく、データ移行、教育、保守、ユーザー追加、帳票変更、連携、解約時のデータ返却を含む1年目・3年目・5年目の総額を見ます。金額が大きく違う場合は、安い会社の前提条件と、高い会社が含めている作業を確認することが先です。

移行できる可能性はありますが、形式をそのまま取り込めるとは限りません。設備コード、物件名、業者名、費用科目、日付、写真の紐付けを整理し、重複や表記ゆれを直してから移行します。何年分を検索対象にするのか、紙を全件スキャンするのか、重要履歴だけを登録するのかを決め、サンプル移行で検索と表示を確認してから本移行します。

まとめ

修繕管理システムの発注・外注では、最初に建物、不動産管理、ビルメンテナンス、工場保全のどの業務を対象にするかを決めます。そのうえで、受付から請求、中長期計画までの業務フローを可視化し、設備台帳、点検、修繕履歴、見積・承認、作業報告、権限、データ移行、外部連携をRFPに落とします。

標準業務が中心ならSaaSや専門パッケージ、独自の業務差分や連携が大きいなら部分カスタム、固有要件が広範囲ならスクラッチという順に適合性を確認します。請負と準委任は開発の性質に応じて組み合わせ、受入条件、変更管理、保守、データ所有権、解約時の返却を契約で明確にします。価格は公開料金、類似業務システムからの推定、要見積を区別し、初期費用だけでなく5年間の総保有コストで比較します。

候補会社には、実際の修繕案件を使ったデモを依頼し、現場入力、本部承認、協力会社の報告、帳票出力、履歴検索までを確認します。一施設・一事業部でパイロット導入し、報告書作成時間、期限超過、未処理件数、検索時間、予算実績などのKPIを測定してから展開します。発注側が業務の判断を持ち、委託先と運用を共同で改善できる体制を作ることが、長く使える修繕管理システムにつながります。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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