工事管理システムの発注は、現場業務の把握と標準化、RFPでの要件提示、役割と変更ルールの合意の順に進めます。この順で進めると、現場に定着するシステムにつながります。
全体像は工事管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・工事管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
現場ヒアリングと業務標準化から始める要件定義
要件定義は、現場ヒアリングと業務標準化（AX）から始めます。目的が「DXが流行っているから」のように曖昧なまま導入を進めると、現場の実態と乖離して反発を招きます。
AsIs業務の可視化と目的の明確化
要件定義の出発点として、現状（AsIs）の業務フローを見える形に整理します。関係者へのヒアリングでは、実際の作業、無駄、手戻りを洗い出します。
- 関係者：現場監督、職人、積算担当、経理、経営層
- 業務の流れ：受注から施工、引き渡し、請求まで
- 確認対象：暗黙のルールや部署をまたぐ非効率
AsIsが曖昧なまま要件を固めると、システムが現場の実態を反映できません。次に、導入の目的をはっきりさせます。残業削減、利益率改善、技術継承のどれを目指すかによって、優先する機能が変わります。
工事管理アプリを導入した企業の約7割が効果を実感できていないという調査結果があります。多くの場合、目的の曖昧さが原因です。そこで、目的を一つか二つに絞り、直結する機能を要件の中心に置くと、過剰な多機能化を避けられます。
業務標準化（AX）を先に行う理由
AXはアナログ・トランスフォーメーションを指します。システム化の前に業務を標準化し、現場ごとのばらつきを減らします。
- やり方をそろえる：日報や写真の整理ルールの統一
- 工程を見直す：ムダな作業を省いたうえでのシステム化
- 独自要件を絞る：標準機能で対応できない部分に限った開発
ばらばらな業務をそのままシステムに写すと、仕組みが複雑になり、使いにくくなります。先に業務をそろえてから載せると、シンプルで定着するシステムにつながります。
現状のすべてを合わせ込むと、開発費が膨らみ、後のバージョンアップも難しくなります。そこで、パッケージの標準機能に業務を合わせられるかを検討します。
さらに、業務標準化を先に行うと、過剰なカスタマイズも避けられます。要件定義で独自要件を選別すれば、費用の高止まりとベンダーロックインを防げます。
riplaは、フルスクラッチ受託でも、標準化で省ける要件は省き、本当に必要な独自要件だけを開発対象にすることを重視しています。
RFP（提案依頼書）に盛り込むべき項目
RFP（提案依頼書）は、現場ヒアリングと業務標準化で固めた要件をベンダーに伝える文書です。RFPの出来が、提案と見積の質を左右します。
工事管理システムのRFPでは、背景と体制、機能と予算、評価基準までを盛り込みます。
背景・目的・対象業務・体制の記載
RFPには、導入の背景と目的、解決したい課題、目指す状態を、ベンダーに伝わる言葉で記します。あわせて、対象業務の範囲も明確にします。
- 業務範囲：工程管理だけか、原価までの範囲か
- 管理対象：複数現場を横断して管理する必要の有無
- 自社の状況：現場数、社員・職人数、既存システム
- 推進体制：意思決定者と現場側の窓口
対象とする範囲が曖昧なままだと、各社が異なる前提で見積もるため、比較ができません。想定ユーザーのITリテラシーも伝えておくと、現実的な提案につながります。
社内の推進体制を記載すれば、ベンダーはプロジェクトの進め方を具体的に提案できます。RFPは自社の状況と要望を伝える設計図です。情報を出し惜しむと、提案の精度が下がります。
機能要件・予算・スケジュール・評価基準
機能要件はRFPの中核です。必要な機能を並べ、重要度を分けておくと、予算に合わせた取捨選択や段階的な提案につなげられます。
- 機能例：工程管理、写真管理、日報、見積、原価管理
- 優先度：「必須」「あれば望ましい」「不要」の3区分
- 評価基準：機能適合度、費用、サポート体制、実績
すべてを必須にすると、見積が膨らみ、重要な機能が埋もれてしまいます。予算を示さないと、ベンダーは安全側に振った高めの見積を出すか、的外れな提案をすることがあります。そのため、予算とスケジュールの目安もRFPに示します。
建設・工事管理系クラウドは月4,000円〜20,000円、初期無料〜20万円程度です。一方で、スクラッチ開発は数百万円規模が一つの目安です。
自社の方向性に合う予算の幅を伝え、判断の基準も明記します。基準があれば、各社は要点を押さえて提案を組み立てられ、社内での比較もしやすくなります。
発注者の協力義務と要件凍結の取り決め
要件定義では見落とされがちですが、特に重要なのが、発注者であるユーザー側の協力義務です。開発には、発注側も主体的に関わる必要があります。トラブルを避けるうえで、RFPと契約で責任分担を明確にすることが欠かせません。
ユーザーの協力義務をめぐる判例の教訓
発注側の協力義務が問われた例として、旭川医科大学病院とNTT東日本のシステム開発をめぐる裁判があります。控訴審は、札幌高裁の平成29年8月31日判決です。
- 当初の要件：169項目
- 開発対象外：そのうち124項目
- 支払い命令：ユーザー側にのみ約14億1500万円
判決では、ユーザー側の協力義務違反が認定されました。「発注後はベンダーの責任」という姿勢では、開発が頓挫したときに発注側が重い責任を負うこともあります。
発注者には、要件を適時に確定し、必要な情報を提供し、決定を遅らせない協力義務があります。工事管理システムでも、現場情報を正確に伝え、確認依頼に速やかに応じる体制が必要になります。そのため、双方の役割と責任をRFPや契約に明記しておきます。
契約で定める要件凍結と追加要望の扱い
要件を確定（凍結）する時期と、その後の追加要望の扱いを、あらかじめ決めておきます。開発開始後に要望が続くと、日程が遅れ、費用も膨らみます。
- 発注側の責任者が要件定義書を承認し、要件を確定する。
- 確定後の変更は変更管理（チェンジコントロール）で扱う。
- 費用とスケジュールへの影響を合意して変更を取り込む。
仕様凍結後に大量の追加要望を出した発注者が敗訴した裁判例もあります。凍結の時期と変更管理のルールは、契約で定めておくことが重要です。
この運用があると、「言った・言わない」の争いや、際限のない追加開発を防げます。要件凍結は、双方が安心して進めるための約束事です。
RFPの段階で、要件確定と変更管理の進め方をベンダーに問い、その提案も評価の対象にします。
外部連携・データ移行・SLAの非機能要件
安定して使い続けられるかを見極めるには、機能要件に加えて非機能要件も確認する必要があります。外部連携、データ移行、SLA（サービス品質保証）が、安定利用を左右します。そのため、RFPと要件定義書で必ず押さえておきます。
外部連携とデータ移行・クレンジング要件
データ移行は要件定義で軽視されがちですが、手間のかかる作業です。会計システムや既存の基幹システムとの連携では、接続方法とデータの流れを定めます。グリーンサイトなど労務安全書類サービスとの連携も、対象に含めます。
- データの種類：原価、出来高、請求情報など
- 連携の方向：一方向か双方向かの別
- 連携の頻度：リアルタイムか日次バッチか
連携先の仕様によっては、相手側の改修や仕様変更について事前の協議が必要になります。そのため、関係者を早い段階から巻き込んでおきます。
データ移行では、既存の表計算ソフトや旧システムに入っている協力会社マスタ、単価マスタ、過去の工事データを確認します。重複や表記の揺れ、古い情報を放置すると、新システムが不要なデータを処理するだけになりかねません。
そこで、移行対象の範囲と、重複の統合、表記の統一、不要データの削除の方針を決めておきます。作業を担う人と時期もあらかじめ分け、本番稼働後の混乱を防ぎます。
移行費用とクレンジングの工数は、見積もりから漏れやすい隠れコストです。そのため、RFPで明示的に確認します。
SLA・保守体制と運用サポートの要件
SLAでは、稼働率の目標、障害時の復旧時間、問い合わせへの応答時間を定めます。現場で図面や写真がすぐ見られないと作業が止まるため、サポートの応答速度は死活問題です。格安サービスを使った工務店では、問い合わせの返信に3日かかり、1年未満で乗り換えて二重のコストを払った例があります。
- サービス水準：稼働率、復旧時間、応答時間
- 運用支援：操作研修と問い合わせ対応
- 継続費用：保守・運用を含む総保有コスト（TCO）
SLAとサポート体制は、契約で担保します。保守費用も要件定義の段階で見込んでおきます。一般に、開発費の15〜20%が相場です。
たとえば、3,000万円のシステムなら、年間450〜600万円が継続的にかかります。そのため、初期費用だけでなく保守・運用費も含むTCOで予算を組みます。現場の高齢化やITリテラシーの差を踏まえ、伴走支援も要件に含めます。
riplaは、フルスクラッチ受託と国内開発の立場から、非機能要件を整理し、稼働後も使い続けられるシステムづくりを支援しています。
ベンダー選定と提案評価の進め方
RFPと要件定義書がそろったら、ベンダーを選び、提案を評価します。工事管理システムの選定では、建設業の現場感の理解と、見積の妥当性の見極めが要点になります。選定を誤ると、せっかく整理した要件が活かされません。
建設業の現場感を理解したベンダー選び
建設・工事管理の現場感を理解しているかを重視します。一般的な開発実績があっても、現場で使えるシステムになるとは限りません。
- 課題理解：自社業務の中身を正確に汲み取る力
- 業界理解：工程や原価、職人の働き方への理解
- 導入支援：研修、問い合わせ、改善への伴走
専門用語が通じるかや、似た業態での導入実績の有無が、判断材料になります。提案が建設業の文脈に沿っているかも、あわせて確かめます。
建設現場にはITに不慣れな作業員が多く、稼働後のサポートが定着を左右します。ヘルプデスクや応答時間を確認します。さらに、操作研修と改善体制も見ておきます。
格安サービスを選び、サポートの遅れから乗り換えた工務店の例もあります。そのため、価格だけでなく、要件定義で整理した現場のITリテラシーを踏まえて、ベンダーのサポート提案を評価します。
見積の妥当性と隠れコストの見極め
複数ベンダーの提案と見積がそろったら、金額の妥当性を比べます。総額の安さだけで選ばず、まず各社の費用範囲をそろえ、含まれる費用と別費用を確認します。
- 導入時：データ移行費、初期設定費、操作研修費
- 運用時：稼働後の保守費
- 変更時：要件凍結後の追加開発単価
見積から項目が漏れていると、安く見えた金額が追加後に割高になることがあります。保守費は開発費の15〜20%が相場です。
たとえば、3,000万円のシステムなら、年間450〜600万円が継続的にかかります。そのため、保守費を含むTCOで各社を比較します。
さらに、将来の機能拡張への対応方針も確認すれば、稼働後の費用を予測できます。見積そのものは、費用の内訳と透明性で評価します。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義の時点で隠れコストを洗い出します。TCOを明確に示し、発注側が安心して投資判断できるよう支援します。
まとめ
工事管理システムの要件定義は、現場ヒアリングと業務標準化で目的を絞り、RFPで要件を伝える流れで進みます。そのうえで、役割と要件凍結を定め、連携・移行・SLAも確認します。
旭川医大病院の判例が示すとおり、発注側の主体的な関与は欠かせません。要件を絞り、双方の責任を文書に残しておくことが、成功の鍵になります。
ベンダーに丸投げせず、現場を知る発注側が業務情報をRFPにまとめます。riplaは、現場ヒアリング、要件整理、RFP作成の伴走、非機能要件の設計を一貫して支援します。
全体像は工事管理システムの完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。