設備工事業向け工事案件管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

設備工事業向けの工事案件管理システム開発は、要件整理から始め、方式選定、設計・開発、テストを経て、段階稼働と定着へ進みます。この順に進めると、現場と経営の判断を早められます。

全体像については、設備工事業向け工事案件管理システム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・設備工事業向け工事案件管理システム開発の完全ガイド

設備工事業向け工事案件管理システムの全体像

案件番号を中央に置き、案件・営業、工事管理、収支・完工、設備工事固有の情報をつないだ図。
案件番号が各業務の記録を結ぶ起点になります。

設備工事業向けの案件管理システムは、空調、給排水衛生、電気の案件を管理します。

消防、通信、機械器具設置の案件も、同じ仕組みで扱います。

案件番号を起点に、見積から保守履歴まで、資材、協力会社、技術者の情報を含む各業務の記録をつなぎます。さらに、受注前の見積と受注後の実行予算も、切れ目なく連続させます。

一つのIDで案件ライフサイクルをつなぐ方法

情報が分かれると、見積変更が実行予算に反映されず、追加工事の請求も漏れます。さらに、工事別の粗利が月末まで見えないという問題も起きます。

  • 情報の分散:見積書、工程表、現場写真、請求書が部門ごとに別ファイルになりがちです。
  • 案件IDの共通化:各記録に共通IDを付けて転記を減らし、誰がいつ更新したかを追えるようにします。
  • 案件・営業:案件台帳、営業進捗、見積履歴、受注・変更契約の機能を検討します。
  • 工事管理:工程・担当者、日報・写真・図面、発注・仕入・実行予算の機能を検討します。
  • 収支・完工:原価・出来高と請求・入金・粗利に加え、完工検査、引き渡し、保守履歴、権限・操作ログの機能が対象です。

すべてを初回リリースに含める必要はありません。

将来つなぐデータ項目は、最初に決めておきます。

設備工事固有の情報の標準項目

建築工事全般の項目だけでは、設備工事の実務を十分に表せません。そのため、設備固有の情報を案件や設備マスターに紐づけます。

  • 機器情報:設備種別、型番、メーカーを記録します。加えて、設置場所、系統、能力、納入予定も残します。
  • 運転・保守:試運転結果、点検周期、保証期限を管理します。納入図、竣工図、保守契約も、あわせて扱います。
  • 工種固有の記録:空調は室外機と室内機、給排水は系統とバルブ、電気は盤・回路・試験記録を残します。

記録がそろっていると、完工後の問い合わせや修繕依頼に対応できます。

項目が多すぎると現場の入力が滞るため、安全・請求・品質に直結する項目に絞ります。

機器詳細や写真は後から加えて、スマートフォンで片手入力できるかを確かめます。

通信が弱い場所でも写真を一時保存して再送できるか、協力会社が担当案件だけを見られるかを、実画面で確かめます。

ポイント

案件番号で見積から保守までの記録をつなげられるかが、システムの範囲を考える起点になります。初回に入れる項目は、現場の入力負担と請求・品質への影響で絞ると扱いやすいです。

設備工事業向け工事案件管理システムの進め方

開発は六つのフェーズに分け、成果物と次へ進む条件を定めておくと、判断の抜け漏れを防げます。

経営者に加え、営業と工事部、現場の代表者を参加させます。さらに、購買と経理、協力会社の代表者も加えます。

各段階では、実データと現場の使いやすさを確かめます。

はじめは1工種・1拠点のPoCで効果を測り、そのあとで対象を広げます。

フェーズ1:要件整理による業務の起点と終点の確定

要件整理では、引き合いから見積、受注、着工、資材発注までを書き出します。施工、検査、引き渡し、請求、保守の流れも、同じように書き出します。

各イベントについて、入力者と承認者、期限を確認します。あわせて、必要書類、例外処理、後工程で使うデータも確認します。

空調、電気、給排水で共通する項目と異なる項目を分けます。そのうえで、共通マスターと工種固有項目を決めます。

成果物は、業務フロー、画面一覧、データ項目一覧です。加えて、権限表、連携一覧、非機能要件、優先順位表も作ります。

課題は、「Excelをなくす」といった表現を、測定できるKPIに置き換えます。

  • 見積:提出までの日数を短くする目標。
  • 工程:遅れを翌日までに把握する目標。
  • 粗利:工事ごとの差異を月次で確認する目標。

PoCでは、案件登録から工程、写真、粗利の確認までを一つの案件IDで追えることを、合格条件にできます。

フェーズ2:選定での実業務デモと総額の比較

方式は、要件の重要度と許容できる運用変更から絞ります。先に一つを決め打ちしない形で進めます。

  • 既製SaaS:早く安く始めたい場合の候補です。
  • 設備業向けパッケージ:標準業務と原価管理を重視する場合に合います。
  • ローコード:既存Excelや独自承認フローを短期間で試す場合に使えます。
  • スクラッチ開発:特殊な積算や基幹連携を競争力にしたい場合に検討します。

デモでは、実際の案件を担当者に操作してもらいます。

見積変更、材料欠品、工程遅延、協力会社の報告を試し、完工写真、追加請求、保証期限も確かめます。

協力会社アカウントの費用や写真・図面の容量、オフライン対応について質問します。

API・CSVや会計、販売、CAD、積算との連携も確かめます。さらに、契約終了時のデータ返却方法と障害時の復旧時間は、同じ質問票で比べます。

フェーズ3:設計開発での入力負担とデータ連携の設計

要件は、画面と権限、データベースに落とし込みます。さらに、帳票やAPI、運用ルールまで設計します。

  • 利用者別の画面:現場担当者には担当案件と当日の作業を、管理者には案件横断の工程・原価・請求を表示します。
  • 協力会社の権限:必要な工程や写真登録だけを公開し、契約金額や他社の原価は見せない最小権限にします。
  • 基本構成:Web、API、リレーショナルデータベースの組み合わせを検討します。写真・図面用ストレージ、帳票生成、検索、SSO、多要素認証も検討します。
  • 現場運用と安全性:日報・写真の一時保存と再送、重複登録や同時編集の競合、端末紛失時の遠隔ログアウトを設計します。

フェーズ4:テストでの例外処理と現場の再現性の確認

開発会社の機能テストだけでなく、営業、工事部、現場、経理が受け入れテストを行います。また、実データに近い案件を使い、正常処理と例外の両方を試します。

  • 契約・見積:失注案件の復活や契約後の金額変更を試します。
  • 工程・資材:資材未納や雨天による工程延期。
  • 協力会社・請求:報告の差し戻しや完工後の追加請求。

スマートフォンの入力時間や写真の圧縮と表示、権限別の閲覧範囲を確かめます。さらに、帳票の印字とCSVの文字化けを確認します。

API連携の失敗やバックアップ復旧、操作ログの追跡も、テスト項目です。

受け入れ条件は、現場担当者が3分以内に日報を登録できる状態などで明文化します。また、変更契約の承認前に請求へ進めない条件も定めます。

フェーズ5:稼働での段階移行とデータ移行の管理

全社一斉の切り替えよりも、工種・拠点・案件を限定した段階移行が適しています。

  1. 空調工事を担当する1支店で新規の進行案件だけを登録し、2か月程度運用します。
  2. 入力率、報告時間、工程遅延の把握、請求漏れを測ったうえで、紙やExcelとの照合期間と帳票の廃止時期を決めます。
  3. 進行中案件と保守契約中の設備は詳細に移し、完了済み案件は、検索用の概要と証憑の保管場所を移す方法もあります。
  4. 顧客名、工事番号、機器型番、金額、日付、協力会社の表記ゆれを整えたうえで、移行後に件数と合計金額を照合します。
  5. 移行責任者、凍結日時、戻し方を決めて、切り替え時の混乱を抑えます。

フェーズ6:定着での利用率と業務ルールの改善

稼働後1か月、3か月、6か月に見直し会を開き、利用状況と業務指標を確認します。

  • 利用状況:案件登録率、日報提出率、写真の紐づけ率。
  • 業務時間:見積提出日数と工程遅延の把握時間。
  • 収支:実行予算と実績原価の差異、請求漏れ件数。

利用率が低いときは、原因を業務側とシステム側に分けて改善します。たとえば、入力項目が多い、画面が探しにくい、権限が足りない、協力会社が使えないといった原因があります。

現場向けには、操作マニュアルに加えて、案件登録、見積変更、写真報告、追加請求の短い動画や手順書を用意します。

各拠点に推進担当者を置き、問い合わせ窓口と改善要望の優先順位を決めます。

入力ルールを増やすときは、既存の紙やExcelを同時に残さないようにします。二重入力が続くと、現場がシステムを正式な台帳と認識しにくくなります。

ポイント

各フェーズで次へ進む条件を、実データと現場の使いやすさで満たしているかを見るのが基本です。最初は1工種・1拠点のPoCで効果を測り、その結果をもとに対象を広げます。

設備工事業向け工事案件管理システムの費用相場

既製SaaS、既製サービスの追加、設備業向けパッケージのカスタマイズ、スクラッチ開発の初期費用レンジを横棒で比べた図。
方式が個別開発に近づくほど、初期費用の幅も広がります。

費用は、初期設定、データ移行、帳票、連携、教育、保守を含む初年度総額で比べます。

対象キーワードに完全一致する公的価格統計は確認できません。そのため、ここに示す数字は、公開SaaS価格と一般的な開発相場の目安です。

費用は、案件数や利用者数、拠点数で大きく変わります。工種や写真容量、連携数、オフライン対応の有無も費用を左右します。そのため、特定の金額ではなく、レンジとして利用します。

導入方式別の費用と期間

導入方式ごとの初期費用、月額費用、期間を比べます。ただし、以下の価格は目安や一製品の公開情報です。

  • 既製SaaSをそのまま導入:初期0万〜50万円、月額1万〜50万円程度、期間2週間〜3か月です。
  • サクミル:30アカウント込み月額9,800円、初期費用0円、2か月無料トライアル。
  • 既製サービスの追加:帳票・権限・API連携を加える場合、初期50万〜300万円、月額5万〜100万円程度、期間2〜6か月です。
  • KojiNEOクラウド:建設業向け原価管理。基本月額30,000円、1クライアント月額3,500円、5クライアント時は月額47,500円です。
  • KojiNEOの初期費:初期費用20万円、基本指導料20万円です(出典:KojiNEO公式価格ページ、2026年8月確認)。

サクミルは、案件管理や見積、原価、請求に加えて、スケジュールや日報も案内しています(出典:サクミル公式サイト、2026年8月確認)。

サクミルの価格は一製品の公開価格であり、設備工事業全体の平均を示すものではありません。また、公開価格に含まれないカスタマイズ費や移行費は、別途確認が必要です。

個別開発の範囲と保守費の予算化

kintoneなどのローコード拡張は、初期100万〜600万円、月額3万〜30万円程度に利用料を加えて考えます。開始までの期間は2〜6か月程度のケースがあります。

設備業向けパッケージのカスタマイズは、初期300万〜1,000万円程度です。

パッケージの期間は4〜10か月程度です。さらに、案件、原価、保守を含むスクラッチ開発は初期800万〜3,000万円程度です。

スクラッチ開発の期間は8〜18か月程度が目安です。

この数字は、対象システムの公開統計ではなく、一般的な業務システム開発相場をまとめたリサーチノートと公開SaaS価格に基づく推定です。

スクラッチ開発では、クラウド、監視、バックアップ、セキュリティ更新、問い合わせ、追加開発の保守費も見積もります。

保守費の目安は年額100万〜600万円程度です。また、PoCは50万〜300万円、1〜3か月程度で実施できます。

PoCの結果をもとに、段階的に展開する方法もあります。見積書では、初期費用と運用費を分けて確認します。

  • 初期費用:開発、移行、教育、連携の費用。
  • 運用費:ライセンス、月額費、保守費。
  • 変更費:将来の変更単価。

各項目を分けて記載してもらうと、方式ごとの総額を比べやすくなります。

ポイント

費用は初年度総額で比べ、特定の金額ではなくレンジとして扱うのが目安です。公開価格に含まれない移行費や保守費は、見積の内訳で別に見る必要があります。

見積もりを取る際のポイント

見積比較で確認する要件範囲、共通シナリオ、法令書類、情報保護の4項目をカードで示した図。
同じ条件を各社に渡すと、提案内容の差を見比べやすくなります。

見積の差は、開発会社の単価だけでなく、前提条件の違いから生まれます。画面数だけで比べると、移行、現場アプリ、権限、帳票が抜ける恐れがあります。連携、テスト、教育、保守も、抜けやすい項目です。

不足分は契約後の追加費用になり得るため、見積依頼の前に対象範囲をまとめておきます。

  • 対象:工種、利用者、拠点、案件数。
  • 既存環境:既存システム、必須帳票、連携先。
  • 導入条件:移行範囲、希望時期、運用体制。

同じ資料での要件と見積範囲の整理

RFPには、案件登録から請求・保守までの業務フローと、画面ごとの利用者を書きます。そのうえで、必須機能と設備固有項目を、同じ資料で具体的に指定します。

  • 基本機能:案件台帳、見積履歴、変更契約、工程、日報・写真・図面。
  • 収支・完工:発注・実行予算、原価・出来高、請求を含めます。加えて、検査、保守、権限、ログも対象にします。
  • 設備項目:工種、系統、型番、設置場所を含めます。納入図、試運転、点検周期、保証期限も挙げておきます。

機能は、必須、できれば必要、将来検討の三段階に分けます。初回は、案件登録、工程、写真・報告、粗利確認を必須にします。CAD連携やAIによるOCRは、将来検討にできます。各機能について、標準対応、設定対応、カスタマイズ、別システム連携のどれかを回答してもらいます。

同じ業務シナリオによる複数社の比較

価格に加え、設備工事の導入事例や原価管理、現場入力を比べます。さらに、協力会社の負担と移行、支援、API、セキュリティ、サポートも比べます。

設備業特化パッケージは、工種固有の項目がそろいやすい傾向があります。これに対して、現場共有型SaaSは、スマートフォンや協力会社との連携を始めやすい傾向があります。ローコードやスクラッチは独自の業務に合わせやすい一方で、要件管理と保守体制が重要です。

各社には同じサンプル案件を渡し、共通シナリオで操作を確かめます。

  • 収支・資材:見積変更で粗利がどう変わるか、発注残が工程にどう出るか。
  • 現場記録:写真に設備番号を付けられるか。
  • 保守:完工後に点検予定へつなげられるか。

評価は、営業担当に加えて現場と経理も操作し、入力時間と確認のしやすさで行います。

見積に含める法令・セキュリティ・運用リスク

国土交通省のICT指針は、元請・下請間の書類のやり取りの合理化、CCUS、建退共電子申請、電子契約、下請連携を示しています(出典:国土交通省「建設業におけるICTの導入・活用に向けた施策」、令和7年3月改訂版)。

法令対応では、帳票を出力できることに加えて、自社の契約形態と提出先の確認が必要です。

  • 法令書類:公共工事や一定規模の工事では、施工体制台帳、施工体系図、作業員名簿、契約書、証憑の扱いを確認します。
  • 情報保護:顧客情報、契約金額、図面、設備仕様を扱います。そのため、権限、暗号化、バックアップ、脆弱性対応を見積条件に含めます。
  • 委託・障害対応:委託先管理、障害時の連絡、監査ログを確認します。

IPAの中小企業向け情報セキュリティ対策ガイドライン第4.0版は、従来の5か条にバックアップを加え、6か条としています(出典:IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」、2026年3月公開)。生成AIやOCRを使う場合は、入力データの学習利用や保管地域を確認します。マスキングや承認者も、あわせて確認します。

ポイント

見積を比べる前に、対象範囲と要件を同じ資料にそろえ、法令やセキュリティの条件も見積条件に含めておくと、前提の違いによる差を見分けやすくなります。

よくある質問

設備工事業の担当者から相談されやすい質問を、最後にまとめます。

費用や期間は、会社の規模と対象範囲で変わります。判断の起点を決めておくと、ベンダーへの質問や社内合意を進めやすくなります。

設備工事業ではSaaSと個別開発のどちらがよいですか?

自社の業務特性に合わせて方式を選び、迷う場合は小規模な検証で判断します。

  • SaaS:案件、工程、写真、日報を早く整えたい会社に向きます。
  • 個別開発:独自の積算、複雑な原価計算、既存基幹との深い連携が競争力になる会社が検討します。
  • PoC:1工種・1拠点で実データを扱い、入力率と業務時間の変化を確認してから、全社展開やカスタマイズを決めます。

初期予算が少ない会社はどこから始めればよいですか?

まず既製SaaSの無料トライアルや小規模プランで、案件登録、工程、日報・写真、請求前の確認をつなぎます。

  • 公開価格の例:サクミルは月額9,800円、初期費用0円を案内しています。
  • 製品ごとの差:利用人数、容量、追加機能、支援費は異なります。
  • 初年度総額:初期設定、教育、データ整備、運用担当者の工数も含めて比べます。

協力会社や職人がシステムを使わない場合はどうしますか?

協力会社には、現場で必要な小さな範囲から使い始めてもらいます。

  • 利用範囲:担当案件の工程確認、写真、作業報告、検査記録から始めます。
  • 利用条件:招待方法、アカウント料金、スマートフォン対応、弱い通信環境での入力方法を決めます。
  • 支援体制:代行入力の責任者を明確にし、元請の推進担当者が初期説明と問い合わせに対応します。

入力項目を減らしながら、利用範囲を広げます。

法令対応とセキュリティは、書類の扱いから委託先まで、四つの面で確かめます。

  • 法令書類:施工体制台帳や体系図などを、工事区分と提出先に照らして確認します。
  • 帳票の扱い:出力形式、更新履歴、保管期間、承認者も見ておきます。
  • セキュリティ:権限分離や多要素認証、暗号化を確認し、バックアップと復旧テスト、操作ログも確かめます。
  • 委託先:脆弱性対応と委託先の事故連絡も確認します。

指針は判断材料であり、導入後も自社の法的・運用責任は残ります。

まとめ

設備工事業向け案件管理システムは、見積、受注、工程を一つの流れで管理します。残りの業務は、案件番号で次のようにつながります。

  • 資材・協力会社:資材の発注と協力会社の情報を、案件番号の記録に含めます。
  • 写真・原価:現場写真と原価の記録を、同じ案件番号でつなぎます。
  • 請求・保守:請求と完工後の保守履歴を、同じ案件の流れで管理します。

機器型番、系統、設置場所、竣工図、試運転、点検周期などを、現場が入力できる範囲で標準化すると、差別化につながります。

六つのフェーズによる小さな検証と段階的な展開

六つの段階は、要件整理で決めた業務とKPIを軸に、区切りごとに確かめながら進みます。

  1. 要件整理で業務とKPIを決めます。
  2. 選定では実業務のデモと総額を比べます。
  3. 設計開発で権限・データ・連携・オフライン対応を定めます。
  4. テストで例外と現場操作を検証します。
  5. 段階的に稼働します。
  6. 利用率とKPIを見ながら定着させます。

1工種・1拠点のPoCで案件IDの一貫性と現場の入力しやすさを確かめると、投資判断の精度を高められます。

業務フローとサンプル案件の準備

代表案件を一つ選び、引き合いから保守までの業務フローを整理します。あわせて、帳票や既存Excel、工種固有項目、関係者、困っている時間もまとめます。

  1. 整理した資料を使い、複数社のデモを同じ条件で比べます。
  2. 初期費用、月額費用、移行、教育、連携、保守を含む初年度総額を合意します。
  3. 導入後に測るKPIを決め、設備工事の実務に合うシステムを育てます。

▼全体ガイドの記事
・設備工事業向け工事案件管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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