建設・建築業界のシステム開発の発注/外注/依頼/委託方法について

建設・建築業界でシステム開発を外部に発注する流れは、まず発注前の準備から始まります。そのあと、開発会社を選び、提案依頼書(RFP)を作成して、契約形態を決めます。発注後はプロジェクトを管理し、受入検査を経て本番へ移行します。

▼全体ガイドの記事
・建設・建築業界のシステム開発の完全ガイド

発注前の準備:建設業界特有の確認事項

発注前に整理する課題、既存システムと業務フロー、社内合意の3項目をカードで示した図。
3つの準備領域を揃えると、発注後の相談に進みやすくなります。

プロジェクトゴールと解決すべき課題の明確化

発注前の最初のステップは、何を解決するためにシステムを開発するのかを明確にすることです。たとえば「工程管理のExcel作業を削減したい」「現場からの施工写真報告をリアルタイム化したい」「原価実績を月次でなく週次で把握したい」のような具体的な業務課題を挙げ、KPI(目標指標)を設定します。

建設業界では、「2024年問題対応のための労働時間管理」「建設業法改正に伴う電子帳簿保存対応」といった法令対応が出発点になるケースも多くあります。

既存システム・業務フローの洗い出し

発注前に、自社で使っているシステム(会計ソフト・積算ソフト・入退場管理システム等)を一覧にし、システム同士のデータの流れも洗い出しておきます。また、Excelや紙で管理している業務の流れも書き出し、どの業務をシステム化の対象にするかを決めます。こうしておくと、開発会社へのヒアリングにかかる時間が短くなり、より正確な見積もりを得られます。

予算・スケジュールの社内合意形成

外部に発注する前に、社内で予算とスケジュールの合意を得ておく必要があります。経営層・IT部門・現場部門・経理部門など、プロジェクトに関わる人へ事前に説明し、「なぜ今このシステムが必要か」「どれだけの投資対効果が見込めるか」を数字で示せるように準備します。

特に建設業界の基幹システム開発は、数百万〜数千万円規模の投資となることが多く、経営の承認を得るために投資対効果資料(ROI分析)を作成する必要があります。

ポイント

発注前に、解決したい課題と既存システムの流れを社内で説明できるかが、以降の判断の土台になります。予算とスケジュールの社内合意も、同じ時期に済ませておきます。

発注先(開発会社)の選定プロセス

開発会社の評価スコアカードに含まれる5項目を、30点から10点までの配点と横棒で比較した図。
開発実績が最も高い配点で、管理体制まで評価項目に含まれます。

候補会社のリストアップ(ロングリスト作成)

候補会社を集めるには、Web検索で「建設業 システム開発 会社」などのキーワードを調べる方法があります。業界団体や展示会(建設テック展・Japan Building Week等)で情報を集めたり、同業他社からの紹介や口コミを頼ったりできます。IT系マッチングプラットフォーム(クラウドワークス・比較ビズ等)も活用できます。

発注側は、集めた候補からまず10〜15社程度のロングリストを作り、初回ヒアリングの結果や書類審査をもとに、3〜5社のショートリストへ絞り込みます。

選定基準と評価スコアカードの活用

複数の開発会社を客観的に比べるには、評価基準(スコアカード)を事前に作っておくことをおすすめします。評価項目の例は、建設業界の開発実績(30点)、提案内容の質・要件理解度(25点)、開発費用(20点)などです。

ほかに、保守体制・サポート品質(15点)、プロジェクト管理体制(10点)も入れ、それぞれに重み付けを設定します。そうすると、各社の提案を同じ基準で点数化でき、感覚的な判断に左右されない公正な選定が可能になります。

ポイント

候補を絞る前に評価基準を決めておけるかどうかが、開発会社を公正に比べられるかの分かれ目になります。各社の提案を同じ基準で点数化しているかも、あわせて確かめます。

RFP作成と提案依頼のポイント

建設業界向けRFPに記載する会社と目的、業務範囲、連携と利用条件、予算と運用の4領域を示す図。
提案依頼の内容を4領域に分けて整理できます。

建設業界向けRFPに盛り込むべき内容

建設・建築業界向けのRFP(提案依頼書)には、まず会社概要(事業内容・規模・工事種別)と、プロジェクトの背景と目的を書きます。次に、工程管理・原価管理・施工管理等の具体的な業務フローを含めて開発対象の業務範囲を示し、機能要件は必須機能と要望機能を分けて一覧にします。

また、連携が必要な外部システムは、一覧と連携要件を挙げておきます。想定ユーザー数・同時接続数・対応デバイスを示し、予算規模(上限金額の目安)も書きます。

さらに、希望納期とマイルストーン、保守・運用体制の要望も伝えます。内容を詳しく書くことで、質の高い提案が集まります。

提案プレゼンテーションの実施と評価

ショートリストに残った候補会社には、対面またはオンラインで提案プレゼンテーションを行います。その場では、提案内容の説明に加えて、過去の建設業界での開発事例の詳細を必ず含めてください。

あわせて、プロジェクトに参画する担当チームの紹介と、建設業界固有の課題への対応方針の質疑も含めておきましょう。この場を、担当者の業界知識、コミュニケーション能力、問題解決力を直接確認する機会として使います。

ポイント

迷ったときは、RFPに業務範囲と機能要件、予算規模が具体的に書けているかを見直してください。内容を詳しく書くほど、質の高い提案が集まります。

契約形態の選び方と注意事項

請負契約(固定価格)の特徴と向き不向き

請負契約(固定価格契約)は、「〇〇の機能を△△円で開発する」というように、成果物と価格を事前に合意する契約形態です。発注者側は予算を管理しやすい利点がある一方で、要件変更が生じると費用の交渉が煩雑になりやすい点がデメリットです。

建設業界では、要件が比較的明確な場合に適しています。たとえば、施工写真管理アプリの単機能開発などが該当します。

契約書には、次の項目を明確に記載することが大切です。

  • 納品物の定義
  • 検収基準
  • 瑕疵担保責任の期間・範囲
  • 変更管理手続き

準委任契約(タイム&マテリアル)の特徴と向き不向き

準委任契約は、開発者の稼働時間(工数)に対して費用を払う契約形態です。費用は、月額人月単価×稼働人月で決まります。

アジャイル開発、要件が変わりやすいプロジェクト、要件定義フェーズだけの部分委託などに適しています。月額コストは予測しやすく、要件変更にも柔軟に対応できます。ただし、総費用が当初の見積もりを超えるリスクがあります。

発注側は、月次で進捗と費用を確認し、スコープ管理を徹底する必要があります。

知的財産権・ソースコード帰属の取り決め

システム開発の契約では、見落とされやすい項目として「知的財産権の帰属」があります。開発したソースコードの著作権が発注者(自社)と開発会社のどちらに帰属するのかを、契約書に明記しておく必要があります。

原則としては発注者に帰属させることをおすすめします。ただし、開発会社が保有する汎用フレームワーク・ライブラリの部分は、開発会社に帰属させたうえで、発注者には利用ライセンスを付与する形が一般的です。将来的に開発会社を変える可能性もあるため、ソースコードの開示と移管に関する取り決めも、事前に確認しておきましょう。

ポイント

請負と準委任のどちらを選ぶかは、要件がどこまで固まっているかで決まります。固まっていない部分は、変更の手続きを契約書で決めておくことが必要です。

発注後のプロジェクト管理

発注者側のプロジェクト体制とガバナンス

発注後は、開発会社に任せきりにせず、自社でも体制を組んで関わることが欠かせません。発注者側では、「プロジェクトオーナー(経営層)」「プロジェクトマネージャー(推進担当者)」「業務担当者(各部門のキーユーザー)」の役割分担を明確にします。

そのうえで、定例会議(週次または隔週)で進捗を確認し、課題を継続して管理します。特に建設業界では、現場の実際の業務フローを熟知した業務担当者が、開発会社とのやりとりに積極的に関わることが、システム品質を高める鍵になります。

要件変更・スコープ管理の方法

開発中には、「やっぱりこの機能も追加したい」「業務フローが変わったので仕様を変更したい」といった要件変更が起きることも珍しくありません。

変更管理手続きは、次の流れで事前に合意しておきます。

  • 変更依頼書の提出
  • 影響調査
  • 費用・スケジュール見積もり
  • 承認
  • 実施

「口頭で依頼した変更が費用に計上されていた」「変更を断られた」といったトラブルを防ぐため、すべての変更依頼を書面(メール・課題管理ツール)に残す習慣をつけましょう。

開発完了後の受入検査と本番移行

受入検査(UAT)の進め方と合格基準

開発が終わったら、発注者側でユーザー受入テスト(UAT)を行います。UATでは、RFPで定めた全機能要件を、実際の業務の流れに沿って確かめます。

建設業界のUATでは、実際の工事データ(工事番号・作業員情報・原価データ等)を使い、日常業務の流れを再現したテストシナリオを用意することが大切です。合格基準は、「必須機能の全項目が正常に動くこと」と「重大な不具合(業務が継続できない障害)がゼロであること」を、事前に合意しておきます。

本番移行計画と切り替えリスクの最小化

本番移行は、開発プロジェクトのなかでリスクが最も集中するフェーズです。移行リスクを抑えるため、移行計画書には「並行稼働期間の設定(旧システムと新システムを同時運用する期間)」と「段階的移行(拠点ごと・機能ごとの順次切り替え)」を明記します。

さらに、「移行判断基準の事前合意(どの条件が整ったら切り替えを実施するか)」と「ロールバック計画(移行後に重大な問題が発生した場合の旧システムへの戻し手順)」も書いておきます。建設業界では、年度末の竣工ラッシュ等の工事の繁閑も考慮し、移行時期を慎重に選びましょう。

ポイント

移行の前に、受入テストの合格基準とロールバックの手順が揃っているかを確かめます。切り替えの時期は、工事の繁閑も見て決めます。

まとめ

外部発注では、一連の流れを一段ずつ丁寧に進めることが成功の鍵です。その流れは、発注前の課題・要件の明確化→開発会社の選定→RFP作成→適切な契約形態の選択→発注後のプロジェクト管理→受入検査・本番移行です。

発注者側も主体的に関わり、業界知識を持つ信頼できる開発会社と良好なパートナーシップを築くことで、現場で本当に使われるシステムを実現できます。

会社紹介

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

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

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

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

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

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