建設業のシステム開発を外部委託｜現場モバイルアプリとIoT発注の設計手順

建設業の現場 DX を進めようとして「SaaS では現場の実態に合わない」と気づき、カスタム開発の外部委託に踏み出そうとしている経営企画・DX 推進の担当者は少なくありません。とくに 2024 年に始まった時間外労働の上限規制が経営課題として定着した 2026 年は、現場業務の抜本的な効率化を避けて通れない局面に入りました（国土交通省「直面する課題」）。

ところが、いざ「現場モバイルアプリと IoT センサーをセットで開発委託したい」と動き始めると、要件の固め方が分からず、複数ベンダーから比較可能な見積を取ることすらできない、という壁にぶつかります。基幹系（会計・人事）の調達経験はあっても、現場制約とモバイル・IoT・クラウドを束ねた発注は別物だからです。

さらに難しいのは、建設現場特有の制約です。電波の届かない地下や高層階、工期 1〜2 年で機器を撤去する前提、職人の IT 慣れ不足など、一般的な業務システム発注では遭遇しない論点が並びます。ここを押さえずに発注すると、納品物が「使われないアプリ」になりかねません。

本記事では、中堅建設会社が現場モバイルアプリと IoT センサーの開発を外部委託する際に、要件定義からベンダー選定、契約形態、段階導入の予算レンジまでを一気通貫で設計する手順を解説します。経営層への稟議に落とし込めるレベルで、社内で固めるべき項目をフレーム化していきます。

建設業が「現場モバイル × IoT」を外部委託すべき背景

なぜ今、建設業が SaaS 型の施工管理アプリだけでは足りず、カスタム開発の外部委託にまで踏み込む必要があるのか。背景には、規制対応と国の政策、そして現場業務の固有性という三つの圧力が重なっています。

2024 年問題が現場業務に突きつけた具体的課題

建設業には 2024 年 4 月から時間外労働の上限規制が適用され、原則として月 45 時間・年 360 時間が上限となりました。特別条項を結んでも年間 720 時間、月 100 時間未満、2〜6 か月平均 80 時間以内の制約は外せません（国土交通省「直面する課題」）。

これまで建設業は、工期の遅れや突発対応を残業で吸収してきました。しかし上限規制が実務に効き始めると、その前提が崩れます。とくに現場では、移動時間・書類業務・職人ごとの作業記録が時間外労働を生む主要因として浮上しています。書類のために事務所に戻る往復、写真整理・日報作成の夜間作業、現場ごとに異なる帳票への転記といった「現場でない場所でやらざるを得ない業務」を、現場で完結させる手段が経営課題になっているのです。

SaaS 型施工管理アプリの守備範囲と限界

施工管理 SaaS は、写真管理・図面共有・日報・チャットといった汎用機能を低コストで提供してくれます。1 現場・1 社で完結する標準業務には十分な解です。

一方で、中堅建設会社が複数現場を並行運用すると、SaaS だけではカバーしきれない領域が出てきます。たとえば、現場ごとに異なる帳票フォーマット、原価管理システム（自社の基幹系）とのリアルタイム連携、職人別の稼働時間集計と給与・外注費精算の連動、現場特有の検査記録（独自のチェック項目）などです。

SaaS のカスタマイズで対応できる範囲を超えたとき、選択肢は二つに絞られます。業務を SaaS に合わせて変えるか、自社業務に合わせたシステムを外部委託でカスタム開発するか。後者を選ぶ判断が現実的になるのは、現場の業務独自性が競争力に直結する、あるいは複数の SaaS を組み合わせても二重入力が解消できない、といった状況です。SaaS とカスタム開発の使い分けや、建設業全般のシステム開発の進め方については、建設業のシステム開発ガイドも併せてご覧ください。

現場モバイル × IoT の外部委託が選択肢になる 3 つの条件

カスタム開発の外部委託を本格検討すべき条件を、発注者目線で 3 点に絞って整理します。

第一に、複数現場で帳票・業務フロー・基幹システム連携の独自要件が SaaS では吸収できないこと。第二に、現場でセンサー（位置・温湿度・重機稼働・バイタル）から取得したデータを業務システムと一体で扱いたいこと。第三に、3 年以上の継続利用と段階的な機能拡張を想定しており、サブスク型 SaaS の累計コストを上回らない投資回収の見立てが立つことです。

国が掲げる「i-Construction 2.0」では、2040 年度までに 3 割の省人化と生産性 1.5 倍を目標として、ICT 施工・データ連携・現場管理の自動化を進めるロードマップが示されています（i-Construction 2.0（国土交通省））。中堅建設会社にとって、現場モバイルアプリと IoT をセットで内製寄りに整備する判断は、規制対応と政策追随の両面で合理性が高まっているといえます。

ターゲットとなる「建設業 システム開発 外部委託」は、こうした文脈で検索される段階に達しており、発注者側の準備度合いで成果が大きく変わります。

発注前に固めるべき 5 つの要件

ベンダーに渡せる要件を社内で固めることが、見積比較可能な発注の出発点です。「現場 DX を依頼したい」では各社が思い思いの提案を返してくるため、コスト・スコープ・期間のいずれでも横並び比較ができません。

ここでは、業務スコープ・現場制約・性能要件・運用範囲・予算レンジの 5 軸で整理する方法を提示します。

業務スコープ（対象業務の取捨選択）

最初に決めるのは「どの業務を対象にするか」です。建設現場で現場モバイル化の候補となる業務は、写真管理、日報・作業報告、検査記録、原価入力、受発注・出来高、職人別労務管理、安全管理（KY 活動・ヒヤリハット）、図面・施工要領書の閲覧など多岐にわたります。

すべてを一度に取り込もうとすると、要件定義は半年、開発は 1 年を超える規模になります。最初のリリースに含める業務は 3〜4 つに絞り、社内で「この業務を現場で完結させたら、残業時間がどれだけ減るか」を試算した結果に基づいて優先順位を決めるのが現実的です。

現場制約（物理環境の前提条件）

建設現場固有の制約をベンダーに渡せる形で言語化します。少なくとも次の項目は社内で前提を固めておくべきです。

• オフライン稼働の必要性（地下・高層階・山間部での電波状況、何時間オフラインで使えるべきか）
• 同期方式（オフラインで蓄積したデータの送信タイミング、コンフリクト時の優先ルール）
• 端末の耐久性(粉塵・防滴・落下、手袋操作の必要性、画面サイズ）
• 電源確保（充電可能なタイミング、モバイルバッテリー前提の動作時間）

これらは「現場の写真を撮影した時点ではオフラインで、夕方に事務所近辺でまとめて同期する」といった具体的な運用シナリオに落として書くと、ベンダーの提案精度が大きく上がります。

性能要件（システムが捌くべき量）

性能要件は数字で書きます。同時アクセスする現場端末数、1 日あたりの写真アップロード件数と総容量、データ保持期間（撮影元写真は何年保管するか、検査記録は法定保存期間に合わせるか）、ピーク時間帯（朝礼後 1 時間に登録が集中するなど）、基幹システム連携の頻度（リアルタイム / 日次バッチ）といった項目です。

「ふだん 50 現場・300 端末、繁忙期は 80 現場・450 端末、写真は 1 日 1 万枚・3GB 程度」といった粒度で書ければ、AWS や GCP のどのサービスを使うか、データベースをどう設計するかをベンダーが現実的に提案できます。

運用範囲（社内とベンダーの分担）

運用フェーズで誰が何をやるかは、保守費用の見積りに直結します。社内の情シスが一次対応する障害の範囲、ベンダーに二次切り分けを依頼する範囲、現場端末の管理（MDM・キッティング）、職人向けのヘルプデスクは誰が担うか、を発注前に決めておきます。

加えて、障害対応 SLA（平日日中の応答時間、夜間・休日の対応、復旧目標時間）も社内で許容範囲を決めておくと、見積比較の軸が増えます。

予算レンジと段階投資

最後に予算レンジを 3 段階で構えます。PoC（数百万円規模）、1 現場本格運用（500〜2,000 万円規模）、横展開（追加で 2,000〜5,000 万円規模）の 3 ステップを前提に、各段階で何を確かめるかを定義します。

一般的な目安として、建設・建築業向けの業務管理システムは、対象端末数や対応業務の範囲、基幹システム連携の有無で大きく変動します。小規模なら数百万円、中規模で 500〜1,000 万円といったレンジを社内の予算検討の出発点に置くと議論しやすくなります。IoT 連携や複数現場展開を含めると上振れする前提で見積もる必要があります。

現場モバイルアプリの設計で押さえる技術観点

発注者として技術選定の主導権を握る必要はありませんが、ベンダーの提案書を読み解き、見積根拠を質問できる程度の理解は欠かせません。ここでは現場モバイルアプリ特有の論点を整理します。

クロスプラットフォーム開発の選択基準

iOS と Android の両方で動かす場合、ネイティブ開発（Swift / Kotlin で別々に作る）、React Native、Flutter、PWA（ブラウザベース）の選択肢があります。

ネイティブはパフォーマンスと OS 標準 UI の追随に優れますが、開発工数が二重になります。React Native と Flutter は単一コードで両 OS に対応でき、開発・保守コストを抑えやすい一方、カメラ・GPS・ブルートゥース連携といったネイティブ機能の追従に時差が出ることがあります。

現場アプリで重視されるのは、カメラ起動の速度、写真への位置情報埋め込み、オフライン保存、低スペック端末での安定動作です。これらの要件を満たせるかを、ベンダーの過去事例で確認するのが実務的なアプローチになります。

オフライン同期とコンフリクト解決の設計

オフラインで蓄積したデータをサーバーに同期する際、複数端末で同じレコードを編集していると衝突（コンフリクト）が起きます。「最後の書き込みで上書き」「現場ごとに優先端末を決める」「人手で衝突解消する」など、複数の方針があります。

ここはベンダー任せにせず、業務ルールとして発注者が決める論点です。たとえば「日報は職長の入力を優先」「写真は重複しても残す」「検査記録は競合したら通知して人手で確定」といった業務ルールが、システム仕様の前提になります。

写真・図面・位置情報のデータ設計

写真は容量が大きく、保管コストとアップロード時間に直結します。「原寸保存と圧縮版保存を分ける」「3 年経過したら低頻度アクセスストレージに移す」「撮影位置情報を埋め込む」「図面と紐づけて表示する」といった設計判断を、業務上の必要性に基づいて発注者が方針決定します。

法的に保管が義務付けられる帳票（建設業法・労働安全衛生法など）の保存期間と、業務上の閲覧頻度を分けて整理しておくと、ストレージコストの肥大化を抑えられます。

職人の IT リテラシーを前提とした UX

「マニュアルを読まずに使える」が現場アプリの最低条件です。タップ数を減らす、入力欄を少なくする、選択肢から選ばせる、ラジオボタンより大きなタイル UI を使う、手袋でも操作できるサイズにする、といった工夫が求められます。

UX は仕様書だけで決まらない領域なので、PoC フェーズで実際の職長・現場代理人に触ってもらい、フィードバックを反映するサイクルを契約に組み込むのが現実的です。

IoT センサー導入の発注設計

IoT は「入れる」こと自体を目的にすると、現場で運用されないまま終わります。発注者として大切なのは「どの業務課題を、どのセンサーで、どの精度で解決するか」を起点に据えることです。建設業全体の AI・データ活用の流れと、IoT センサーの位置づけについては建設業のAI活用とは？もあわせて参考にしてください。

建設現場で使われる IoT 用途別マップ

代表的な用途は次の通りです。

• 安全管理: 作業員のバイタル（体温・心拍）モニタ、熱中症アラート、転倒検知
• 進捗管理: 重機の位置・稼働時間、出来高の自動計測、コンクリート温度
• 労務管理: ICタグ入退場、エリア滞在時間、作業員の動線分析
• 環境管理: 騒音・振動、粉塵、温湿度

導入する際は、現場の課題から一つだけ用途を選び、「課題 → 計測対象 → センサー → データ活用」の流れを 1 ページで描けるかを発注前に確認します。

通信規格の選定

センサーをサーバーまでつなぐ通信規格は、距離・消費電力・データ量の組合せで選びます。

• BLE（Bluetooth Low Energy）: 数十〜数百メートル、超低消費電力。ICタグや近接センサー向け。ゲートウェイ経由でクラウドに送る前提
• Wi-Fi: 高速・大容量だが消費電力が大きい。事務所付近・カメラの映像送信向け
• LTE-M / NB-IoT: キャリア網経由、広域・低消費電力。屋外の分散センサー、移動するデバイス向け
• LPWA（Sigfox / LoRaWAN など）: 数 km の長距離、超低消費電力、小データ。固定設置の長期運用センサー向け

これらは公共・産業向けの IoT 通信として整理されています（LPWA とは？ 通信規格と特徴比較（リョーサン菱洋テクラボ）、IoT 向け無線規格・周波数の種類と違い・選び方（OKI））。建設現場では、屋外で広域・移動を伴うものに LTE-M、固定の長期計測に LPWA、近接の入退場やタグに BLE という組み合わせが典型例です。

工期内撤去前提のハードウェア調達と再利用設計

建設現場の IoT が一般的な工場 IoT と異なるのは、工期終了でデバイスが撤去される前提があることです。1〜2 年使ったセンサーを次の現場で再利用する設計にしておかないと、現場ごとに費用が積み上がります。

「センサーは現場ごとにキッティングし、回収して洗浄・再校正・再使用する」「ゲートウェイは現場プレハブから取り外して持ち回る」「通信契約は最小単位で休止・再開できるものを選ぶ」といった運用前提を、発注仕様の段階でベンダーと擦り合わせておきます。

1 現場・1 用途のスモールスタートを発注仕様に落とす

最初のリリースは「1 現場・1 用途」に絞ることをおすすめします。たとえば「夏季の熱中症対策として、作業員のバイタル計測を 1 現場 30 名で 3 か月運用」といった単位です。

これを発注仕様にする際は、計測対象・センサー仕様・通信方式・データ閲覧手段（ダッシュボードか、現場モバイルアプリと統合するか）・アラート条件・撤去後のデータ保管方針を、1 ページに収まる粒度で書きます。スモールスタートのスコープが明確であれば、ベンダーは精度の高い見積を返せます。

開発会社の選び方｜現場理解と保守体制を見抜く 4 観点

中堅建設会社の発注では、「建設業の業務を理解しているか」だけでなく、現場常駐型の保守・職人サポート・複数現場展開への対応力までを見極める必要があります。質問リストと確認資料を 4 観点で整理します。

建設業の業務理解度を見抜く質問例

提案前のヒアリング段階で、ベンダーに「現場代理人の 1 日の流れを描いてください」「写真整理の業務フローを聞いた範囲で書き出してください」と依頼します。建設業の業務を理解しているベンダーは、朝礼・KY 活動・午前作業・昼礼・午後作業・夕礼・書類整理という流れを具体的に描き、写真にどの段階で位置情報・工程・撮影者がメタデータとして紐づくべきかを語れます。

逆に、汎用業務アプリの経験しかないベンダーは「写真を撮ってアップロードする」レベルで止まります。この差は提案書の細部に表れます。建設業向けの開発実績や業務理解度を比較する際の観点については、建設業のシステム開発ガイドも補助資料として活用できます。

現場常駐・遠隔保守の体制

カスタム開発した現場システムは、稼働後の保守こそが利用継続を左右します。導入直後の現場立会い、夜間・休日障害の一次対応、繁忙期（年度末・大型連休前）の増員、職人向けヘルプデスク窓口の有無を確認します。

特に、中堅建設会社の現場は地理的に分散しがちなので、「現地立会いが必要な障害」と「遠隔で完結する障害」の切り分けと、それぞれの対応時間が見積条件にどう反映されているかを確認します。

過去実績の読み方

実績は件数より中身です。「業界（建設業の中でも土木・建築・設備など細分化される）」「規模（売上・現場数・端末数）」「期間（PoC 何か月、本番運用何年）」「公開可否（社名公開できる実績か、匿名事例しかないか）」を聞きます。

公開可能な実績がない場合でも、匿名で構わないので「成果指標（残業時間 X% 削減、写真整理時間 Y 時間/週削減）」が語れるかが、発注後の効果測定までベンダーが伴走できるかの判断材料になります。

自社規模に合うベンダーのレンジ判定

中堅建設会社（売上 30〜200 億円）の発注先候補は、大きく 4 つの層に分かれます。

• 大手 SIer: 体制は厚いが単価が高く、中堅向けに小回りが利かないことがある
• 中堅開発会社: 建設業特化のベンダー、または DX 全般を扱う規模 30〜200 名程度の会社
• 専業ベンダー: 施工管理アプリや IoT に特化した小規模専門集団
• フリーランスチーム: PM・エンジニアが個人事業主として組むチーム、PoC や小規模案件で機動力が高い

PoC や 1 現場規模の初期投資（数百万円〜 2,000 万円）であれば、中堅開発会社や専業ベンダー、フリーランスチームの選択肢が現実的です。横展開で全社規模（5,000 万円超）に育てる段階で、複数ベンダーを組み合わせる、または主契約を大手にスイッチする判断も視野に入れます。

契約形態と偽装請負リスクの回避

カスタム開発の外部委託では「請負」「準委任」のいずれが妥当かを業務範囲別に判断する必要があります。とくに現場常駐や職人指導を伴うフェーズでは、指揮命令関係が曖昧になり、偽装請負リスクが発生します。

請負契約と準委任契約の使い分け基準

請負契約は「成果物の完成」を目的とし、受注者は成果物を完成させて納品する義務を負います。準委任契約は「業務の遂行」を目的とし、受注者は専門家として誠実に業務を行う義務を負いますが、原則として成果物の完成義務は負いません（偽装請負について（東京労働局））。

システム開発に当てはめると、要件定義・基本設計のように「成果物の範囲が事前に決めにくく、対話しながら進める」フェーズは準委任、詳細設計以降の「仕様書に基づいて作る」フェーズは請負、というのが一つの目安です。

現場常駐・職人指導が発生する場合の偽装請負リスク

建設現場でのテスト・運用フェーズでは、ベンダーのエンジニアが現場常駐したり、職人に直接アプリの使い方を指導したりする場面が発生します。

ここで発注者側の社員が、ベンダーの個別エンジニアに直接「明日はこの現場に行ってください」「この機能を急ぎ修正してください」と指示すると、偽装請負と判定されるリスクが高まります。請負契約形式を採りながら、実態として発注者が受注者の労働者を指揮命令していると見なされるためです（偽装請負について（東京労働局））。

回避策は、ベンダー側に常駐責任者（PM）を必ず配置し、発注者からの指示はその責任者経由で行うこと、現場常駐スタッフへの直接指示を避けること、業務範囲と裁量をベンダー側に明確に切り分けることです。

契約書に盛り込むべき項目

契約書では少なくとも以下を明文化します。

• 成果物の定義と受入基準（請負部分）
• 業務範囲と裁量（準委任部分）
• 知的財産権(ソースコードの著作権・利用権、第三者ライブラリの扱い）
• SLA（応答時間・復旧目標時間・対応時間帯）
• 保守範囲（バグ修正・機能追加・OS バージョンアップ追随の費用区分）
• 損害賠償の上限と免責範囲

これらは雛形に頼らず、本件のスコープに合わせて社内法務とベンダー法務で擦り合わせるべき領域です。

段階契約でリスクを抑える設計

PoC → 1 現場本番 → 横展開という 3 段階を、それぞれ別契約として段階的に締結する設計をおすすめします。

PoC は準委任で短期（1〜3 か月）で締結し、成果が出ない場合に小さな損失で撤退できるようにします。1 現場本番は要件と成果物がある程度固まった段階で請負と準委任を組み合わせ、横展開フェーズで保守と機能拡張を年度契約に切り替える、という流れが現実的です。

予算レンジと段階導入のモデルケース

中堅建設会社向けに、PoC → 1 現場本格運用 → 横展開の 3 段階モデルを示します。あくまでも参考値で、業務スコープと IoT 連携の有無により大きく変動します。

PoC フェーズの予算感と成功指標

PoC は数百万円規模で 1〜3 か月、目的は「業務効果が出るかを確かめる」ことに絞ります。たとえば、写真管理・日報の 2 機能のみ、対象現場 1 か所、端末 10〜20 台といったスコープです。

成功指標は数字で固定します。「写真整理時間を週 5 時間 → 2 時間に短縮」「日報入力の所要時間を 1 日 30 分 → 10 分に短縮」「現場代理人の事務所滞在時間を週 8 時間削減」など、効果が経営層に説明できる KPI を 2〜3 個用意します。

1 現場本格運用の予算感と回収シナリオ

1 現場本格運用は、一般的な目安として 500〜2,000 万円規模で、6〜12 か月の開発を経て本番リリースするケースが多くなります。IoT 連携やオフライン同期、基幹システム連携などを含めると上振れする前提です。

回収シナリオは、現場代理人の労働時間削減効果を金額換算します。「1 現場で年 500 時間の事務作業削減 × 人件費単価 5,000 円 = 250 万円/年」といった粒度で社内試算しておくと、回収期間 3 年などの目安が示せます。

横展開フェーズで増える費用項目

横展開は追加で 2,000〜5,000 万円規模になることがあります。横展開で増えるのは、主に次の費用です。

• 同時アクセス端末数増加に伴うインフラ費（クラウド料金、データベース増強）
• 多現場運用のための機能追加（権限管理、現場別ダッシュボード、横断レポート）
• 保守費（年間 15〜20% が一般的、開発会社により差あり）
• 職人向け教育コスト（マニュアル整備、現場研修）

横展開の見積は、1 現場本格運用が安定稼働した時点で、運用データに基づいて再見積するのが現実的です。

補助金活用の判断軸と社内推進体制への影響

IT 導入補助金・ものづくり補助金・事業再構築補助金など、製造業・建設業向けに活用できる補助金は複数あります。ただし、要件・公募時期・採択率は毎年変動するため、最新の公募要領を必ず確認してください。

補助金を前提に予算組みすると、不採択時のリカバリプランが必要になります。「補助金が出ない前提で予算化し、採択されたら次フェーズ前倒し」とするか、「補助金前提のスケジュールにしてリスクを取る」かは、経営判断として明示しておくべき論点です。

発注設計のチェックリストと次のアクション

ここまでの観点を、発注前に社内で固めるチェックリスト形式で再整理します。社内会議で 1 つずつ「決まっている / 決まっていない」を確認し、未決事項を残さないようにしてください。

発注前に社内で固める 10 項目

1. 業務スコープ（対象業務を 3〜4 個に絞ったか）
2. 現場制約（オフライン稼働・同期方式・端末耐久性の前提）
3. 性能要件（同時アクセス・データ量・保持期間）
4. 基幹システム連携の範囲（リアルタイム / 日次バッチ / 連携しない）
5. 運用範囲（社内対応 / ベンダー対応の分担、SLA 許容範囲）
6. 予算レンジ（PoC・本番・横展開の 3 段階）
7. 成功指標（残業時間削減・所要時間短縮の KPI を数値で）
8. 契約形態の方針（フェーズ別に請負 / 準委任を整理）
9. 偽装請負回避策（指揮命令系統の文書化）
10. 推進体制（社内 PM、ベンダー PM、現場側の窓口）

ベンダー比較ヒアリングシートの構成例

3〜5 社のベンダーに同じ質問を投げ、横並び比較できる形式で記録します。

• 建設業の業務理解度（具体的事例の有無、業務フローを描けるか）
• 提案アーキテクチャ（モバイル技術選定、オフライン同期、IoT 連携）
• 体制（PM 経験、現場常駐の可否、夜間障害対応）
• 過去実績（業界・規模・期間・公開可否）
• 見積（フェーズ別の金額、人月単価、保守費の比率）
• 契約形態（請負 / 準委任の組み合わせ提案）

PoC スコープを 1 ページにまとめるフォーマット

PoC を始める前に、以下の項目を 1 ページに収めます。

• 解決したい業務課題（1 文）
• 対象現場と期間（1 現場、3 か月など）
• 対象業務（写真管理・日報など 1〜2 機能）
• 利用者（職長 X 名、現場代理人 Y 名）
• 成功指標（数値 KPI を 2〜3 個）
• 契約形態と費用上限
• 撤退判断基準（成功指標に満たない場合の対応）

このフォーマットが完成すれば、複数ベンダーに同じ条件で見積依頼でき、提案の差を冷静に見比べられます。

なお、ここで挙げた 10 項目チェックリスト・ヒアリングシート・PoC シートを、発注前・発注中・完了後の 3 フェーズで網羅的に確認したい場合は、お役立ち資料「システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集」が現場 DX 発注の社内ドキュメントとして活用できます。発注プロセスの抜け漏れを社内で点検する素材としてご活用ください。

社内で固める作業は地味ですが、ここを丁寧に進めるほど、ベンダーから出てくる提案の質と精度が向上し、結果として「発注して終わり」ではない、運用フェーズまで効く投資になります。建設業のシステム開発を外部委託する成否は、発注前のこの設計工程で 7〜8 割が決まると言って差し支えありません。