土木工事業向け工事管理システム開発の発注/外注/依頼/委託方法について

土木工事業向け工事管理システムの発注は、業務課題の整理、方式と要件の比較、1現場での検証を順に進めるのが基本です。この順で進めると、現場に定着する仕組みにつながります。

発注形態は、業務課題を整理したあとに決めます。既製品で足りるか、個別開発が要るかで、後の契約や費用の見方が変わります。

▼全体ガイドの記事
・土木工事業向け工事管理システム開発の完全ガイド

土木工事業向け工事管理システムの発注方法

工事管理システムは、案件・工事台帳、工程、作業員、重機を工事ごとに管理します。現場の写真や出来形、品質、安全の記録も、同じ工事の情報として扱います。さらに、原価や請求、電子納品も、同じ仕組みの中で扱います。

発注では、まず現場と本社の情報断絶が大きい業務から対象を絞ります。導入効果を確かめた後に、範囲を広げます。

発注前に解決したい業務の明確化

まずは、システムが欲しいと思ったきっかけを、業務上の困りごとに置き換えます。たとえば、現場監督が事務所へ戻って日報を作る、写真整理の残業が多い、といった課題を挙げます。

さらに、実行予算と発注・出来高がつながらず粗利の確定が遅い、山間部で通信が切れると入力をやり直す、といった課題もあります。課題を具体化すると、必要な機能と、導入後に測るKPIも定まります。

建築向けシステムとの違いと要件への反映

道路、河川、上下水道、造成、舗装では管理項目が異なります。そのため、公共工事の写真、出来形、品質試験、安全パトロール、施工体制台帳、電子納品の形式も確認します。

発注者や工種に合った帳票が要るうえ、オフライン入力と後同期、測量値の取り込み、図面・写真・帳票の紐付け、協力会社ごとの権限も要件に含めます。

発注形態の選び方(既製SaaS・部分開発・スクラッチ)

既製SaaS・土木専用パッケージ、部分開発・ローコード、スクラッチ開発を並べた発注形態の図。
既製サービスから個別開発まで、選択肢の幅が見渡せます。

発注形態は、工種のばらつき、公共工事の帳票、現場数、協力会社の参加範囲で変わります。また、積算・会計システムとの連携も判断材料です。

発注側は、最初からスクラッチ開発に決めず、既製サービスで満たせる範囲と、独自業務として残す範囲を先に分けます。

既製SaaS・土木専用パッケージの発注ケース

複数現場の工程、写真、図面、日報、報告を早く統一したい場合は、既製SaaSや土木専用パッケージが候補です。

土木専用製品は、電子納品、写真、出来形、測量、積算の業務知識を備えています。ただし、独自の原価計算や承認経路、古いExcelの完全再現には、追加設定や開発が必要な場合があります。

部分開発・ローコードの組み合わせ

既製SaaSで不足する日報、点検、写真台帳、申請ワークフローだけを加える場合は、部分開発やローコードが適しています。

既存サービスを残したまま自社の画面や帳票を作れるため、全体を作り直すより、初期費用と期間を抑えやすくなります。一方で、オフライン同期、大量写真、出来形計算、会計連携は難易度が上がります。そのため、提案段階で実データを使った技術検証を依頼します。

スクラッチ開発を選ぶケース

積算・実行予算・発注・出来高・請求・会計を一つの業務フローにしたい場合は、スクラッチ開発を検討します。

複数支店・現場・協力会社で独自承認を運用する場合も候補です。加えて、要件定義からマスタ整備、データ移行、教育、保守まで、各段階で発注者の意思決定が必要です。

業務をそのまま再現するのか、残すルールと見直すルールを分けるのかを、経営と現場の双方で決めます。

ポイント

既製品で足りる範囲と個別に作る範囲を先に分けると、個別開発を必要以上に広げずに済みます。工種や現場数、協力会社の参加範囲の違いが、その線引きを左右します。

発注・外注の進め方(RFPと小さな検証)

現場・本社・協力会社の現状把握からRFP、1現場のPoCへ進む流れ図。
要件整理を経てから現場での適合確認へ進む順序です。

外注では、提案を受ける前に、発注者と開発会社で言葉の意味をそろえておきます。たとえば「リアルタイムで管理したい」という希望は、担当者、時期、端末、入力内容、出力帳票に分けて考えます。そのうえで、要件をRFPにまとめ、同じ前提で複数社から提案と見積を受けます。

現場・本社・協力会社の現状の聞き取り

聞き取りには、現場監督、工事部、積算担当、経理に参加してもらいます。さらに、協力会社、情報システム、経営者にも参加してもらいます。次に、受注前から竣工・請求までの帳票を誰が作り、どの内容を転記しているかを、業務フローにまとめます。

紙の日報、Excelの実行予算、写真フォルダ、チャット、会計ソフトの仕訳など、実際のサンプルを集めて確認します。サンプルを見ると、例外的な処理も分かります。

RFPの要件の区分(必須・希望・対象外)

RFPには、次の要件を整理して書きます。

  • 背景・対象:目的、工事・支店・利用者の範囲、現行業務
  • システム要件:必要機能、データ移行、外部連携、非機能要件
  • 機能の区分・詳細:必須・希望・対象外に分け、オフライン入力、写真保存期間、帳票形式、承認者、権限、操作履歴を明記
  • 終了時と障害時:解約時のデータ返却、復旧目標
  • 提案条件:導入スケジュール、予算の考え方、提案書の回答形式

要件を後から追加すると、費用と納期に影響が出る場合があります。そのため、事前に整理しておきます。

1現場のPoCによる現場適合性の確認

候補を絞ったら、実際の工種と通信環境で1現場または1業務のPoCを行います。導入前後に測れる指標で評価します。

  • 作業時間:日報作成と写真整理にかかる時間
  • 連絡・確定業務:電話や移動の回数、原価確定までの日数
  • 現場定着:入力率と承認の手戻り件数

判断の材料には、機能説明会に加えて、現場監督や協力会社が自分の端末で入力できるか、電波の弱い場所で保存できるかを含めます。

ポイント

RFPは、現場の聞き取りをもとに必須・希望・対象外を分けて書き、同じ条件で複数社に提案を求めます。候補を絞ったら、1現場のPoCで現場への合い方を確かめてから決めます。

契約形態の選び方(要件の確度と変更量)

要件定義で不明点が残ると、開発中に帳票や承認が変わることがあります。その場合に価格だけで選んでいると、変更時の責任や追加費用が曖昧なままになります。

要件定義、開発、保守を分け、成果物と判断の時期を明確にする方法も有効です。

請負契約(成果物と完成条件を固定できる場合)

請負契約は、合意した機能、画面、帳票などの成果物を完成させる契約です。要件が固まり、受入テストの条件を明確にできるなら、この契約が合います。

RFPが曖昧なまま固定価格を求めると、見積が高くなるか、変更費用が積み上がる可能性があります。そのため、対象ブラウザや同時利用者数も完成条件に含めます。

契約では、写真容量、性能、障害対応も条件に含めます。

準委任契約(要件探索・継続改善)

準委任契約は、一定期間の業務や専門作業を委託する契約です。要件定義、設計支援、アジャイル開発、運用改善などに使われます。

現場の声を聞きながら優先順位を変えていく場合に適しています。そのうえで、作業内容、稼働時間、成果確認、報告頻度を契約書や個別発注書に明記します。

発注側は、成果物の著作権、ソースコード、設計書、データの利用権も確認します。

多段階契約による発注者側の判断の確保

不確実性が高い案件では、要件定義・PoC、開発、追加展開、保守の4段階に分けて契約する方法があります。まず、業務フロー、画面試作、移行の難所、現場利用を確認します。

次に、成果をもとに本開発を発注します。また、各段階の終了条件と中止・縮小条件を決めておくと、合わない製品に予算を全額投じるリスクを下げられます。

ポイント

契約形態は、要件がどこまで固まっているかと、開発中に変わりそうな範囲で選びます。要件が固まっていれば請負、不確かな部分が多ければ準委任や多段階契約が候補になります。

費用相場の方式別レンジと見積項目の分解

費用は、利用者数や現場数、写真容量、帳票数、既存システムとの連携、移行、教育の範囲で変わります。

以下の数値は、建設・不動産・設備分野の一般的な業務システムの目安を土木向けに読み替えた概算で、土木工事業だけの統計ではありません。そのため、発注予算の確定値ではなく、初期相談で比べる目安として使ってください。

方式別の概算レンジと期間

月額サービスの利用から全社展開まで、導入範囲によって費用と期間は大きく異なります。

  • 月額利用:小規模な機能限定SaaSやOCRは毎月3万円から50万円程度、複数現場を扱う一般的な業務クラウドは毎月10万円から100万円程度が目安
  • PoC・パイロット:1現場での検証は50万円から300万円程度、数現場での本番化は300万円から1,500万円程度
  • スクラッチ開発:積算・原価・帳票・基幹連携を含む場合は300万円から2,000万円程度
  • 全社展開:支店や協力会社まで含む場合は1,500万円から5,000万円程度
  • 導入期間:PoCは3か月から6か月、パイロットは4か月から12か月、スクラッチは6か月から18か月程度

公開価格の例として、CST「土木BASE NOAH」は、一般ユーザー5ライセンス合計で年額13万2,000円です。さらに、追加ライセンスは1件あたり月額2,200円で、最低契約期間は1年間です(出典:株式会社コンピュータシステム研究所「土木BASE NOAH 料金プラン」、2026年8月確認)。

初期費用、アカウント、ストレージ、帳票、API、サポートは別料金の場合があります。そのため、月額の数字に加えて、別料金になる項目も比べます。

費用と期間は、いずれも目安です。データ整備と意思決定の速さで変わります。

見積書の内訳(工程・成果物・除外項目)

要件定義、画面設計、デザインの各工程を、分けて記載してもらいます。開発、外部連携、帳票、テストも、工程ごとに分けてもらいます。移行、教育、管理、保守も別の工程として書かれていないと、「開発一式」とまとめられた場合に含まれる内容を比べられません。

初期費用に含むユーザー数、容量、サポート時間、追加改修の単価も確認します。さらに、クラウド利用料、バックアップ、セキュリティ診断の費用も対象になります。

ランニングコストと保守範囲

運用後は、ユーザーや現場の追加、写真や図面の容量への対応が発生します。サポートや障害対応、OS・ブラウザ対応も続き、さらに法令や帳票改定への追随も必要です。

保守費用は初期開発費の15%から25%程度を仮置きすることがあります。なお、これはリサーチノートに基づく実務上の概算で、契約金額を断定するものではありません。

受付時間、一次回答、復旧目標、バックアップ、脆弱性対応、解約時のデータ返却を保守条件として確認します。

ポイント

費用は、方式別のレンジで大まかな幅をつかみ、見積は工程ごとの内訳で比べます。月額だけで判断せず、別料金の項目と保守範囲も含めて見ます。

委託先の選定の観点(土木適合性・体制・見積の透明性)

同規模・同工種の導入事例、オフライン・データ移行・帳票、情報と権限、導入後支援の4項目を示す図。
現場適合性から導入後の支援まで確認点が広がります。

委託先は、知名度や価格だけでなく、土木業務を理解し現場に定着させられるかで選びます。

国土交通省は、規模や工種に応じたICT化と人材育成を、ICT指針の主な点として示しています。さらに、元請・下請間の書類合理化、CCUS・建退共電子申請・電子契約の活用も挙げています(出典:国土交通省「建設業におけるICTの導入・活用に向けた施策について」、2026年8月確認)。そこで、この内容を評価項目にします。

同規模・同工種の導入事例

導入社数だけでなく、似た工種、現場数、公共工事の比率、元請・下請関係、協力会社の参加方法を確認します。

可能であれば、導入後の現場責任者に、入力率が上がるまでの期間、教育方法、追加費用、通信障害時の運用を聞きます。

土木専用ソフト、現場共有クラウド、ERP、建機・測量連携では、得意な領域が異なります。そのため、1社ですべてを満たす前提で選ばないことも大切です。

オフライン・データ移行・帳票のデモ確認

提案デモでは、自社の工事台帳、写真、図面、実行予算、日報のサンプルを使ってもらいます。きれいに整えられた見本だけで判断せず、自社のサンプルで確かめます。

弱電波の場所で日報と写真を保存できるか、同期後に重複や欠落がないか、発注者指定の帳票を出せるかを確かめます。さらに、写真と出来形が工事・測点単位で追えるかも見ます。

既存Excelをそのまま移せるかを問うよりも、マスタ化する項目と移行する過去データを、提案書に記載してもらいます。

セキュリティと導入後の支援

委託先の評価では、情報へのアクセス、セキュリティ運用、協力会社への支援を確認します。発注側は、金額の確定や安全の判断を、人が承認する設計にします。

  • 情報と権限:契約金額、発注者・協力会社の情報、作業員名簿、図面、写真をどこまで扱うか、会社・支店・現場・協力会社の単位で制限を設定できるか
  • 安全管理:承認・操作履歴、通信の暗号化、バックアップ、脆弱性対応、再委託の管理
  • 導入後支援:協力会社向けの説明会と問い合わせ窓口

国土交通省のICT指針でも、発注者や下請業者を含む連携・協働が示されています。加えて、機能だけでなく、協力会社への支援体制も評価します。

なお、2025年度のi-Construction 2.0では、自動施工が9件、遠隔施工が41件でした。また、2026年度は、AI活用、企業規模を問わない普及、試行から本格運用への移行が掲げられています(出典:国土交通省「i-Construction 2.0の2年目の取組成果」、2026年4月28日公表)。

AI・3次元測量・建機連携を見据えるなら、工事・作業員・協力会社・材料のマスタと入力ルールを先に整えておきます。

ポイント

委託先は、土木業務を理解し現場に定着させられるかで選びます。導入事例は似た工種と現場数で見て、デモは自社の実データを使って確かめます。

よくある質問(FAQ)

発注・外注で多い疑問に答えます。費用や契約は、工種、現場数、帳票、連携範囲を踏まえて判断してください。

既製SaaSと個別開発はどちらを選べばよいですか?

工程・写真・日報など標準化しやすい業務を早く始めるなら、既製SaaSや土木専用パッケージが向いています。一方、積算・原価・会計連携、独自帳票、複雑な承認が重要なら、個別開発も検討します。

既製サービスに部分開発を加える方法もあります。1現場のPoCで不足機能と現場定着を確認してから決めます。

土木工事業向け工事管理システムの発注費用はいくらですか?

公開料金のあるSaaSは、ライセンスや容量を含めて月額・年額を確認します。一方、個別開発のPoCは50万円から300万円程度、本番化は300万円から1,500万円程度です。

スクラッチは300万円から2,000万円程度の概算レンジです。なお、これは土木業界全体の統計ではありません。そこで、要件定義、連携、移行、教育、保守の範囲をそろえて、複数の見積を比べます。

RFPには何を書けばよいですか?

RFPには、背景・目的、対象工事、利用者、現行業務を書きます。さらに、必須・希望機能と対象外の区分、帳票、通信環境を書きます。そのうえで、移行や外部連携、権限、セキュリティを書き、日程と保守条件も含めます。

提案書の形式、費用内訳、前提条件、追加費用の単価、導入事例の提示方法も指定します。こうすると、同じ条件で候補会社が回答できます。

契約前にデータとソースコードの扱いを確認できますか?

確認できます。具体的には、クラウドの工事情報を解約時にどの形式で返却するか、移行費用やバックアップの担当を契約前に確認します。

個別開発では、ソースコードや設計書、API仕様を明文化します。テスト仕様、利用ライセンス、第三者部品、再委託先の権利関係も、あわせて明文化します。そのうえで、保守会社の変更や内製化を妨げない条件にしておきます。

まとめ

発注時は、現場・本社・協力会社の業務を洗い出し、工種、公共工事の帳票、写真・出来形の要件を整理します。さらに、原価、通信、権限、移行の要件も整理します。そのうえで、既製SaaS、土木専用パッケージ、部分開発、スクラッチ開発を同じ観点で比べます。

RFPと1現場PoCの準備

見積を依頼するときは、要件定義から保守までを分けてもらい、開発費やライセンス、容量を比べます。さらに、移行、教育、連携、障害対応、データ返却も、項目ごとに見比べます。次に、実データと現場の通信環境を使うPoCを行い、日報時間、写真整理時間、入力率、原価確定日数などを導入前後で測ります。

契約と定着の一体設計

成否を分けるのは、機能数や初期価格よりも、現場に定着するかどうかです。そのためには、土木業務を理解する委託先、迷わない画面、協力会社も参加しやすい運用、段階的な教育、継続改善できる契約をそろえることが大切です。

発注者側に業務責任者を置き、現場の最終承認とデータ管理の責任を明確にします。こうした体制は、将来のAI・測量・建機連携につながる基盤になります。

▼全体ガイドの記事
・土木工事業向け工事管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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