データ基盤構築の外注｜フェーズ別発注設計と契約形態の選び方

「経営層からデータ活用を求められたが、大手 SIer に見積を依頼したら 3,000 万円超の提案書が返ってきた」——このような状況で、稟議を出す前に手が止まっている DX 推進担当者は少なくありません。金額の重さもさることながら、「一括で丸投げすると社内に知見が残らない」「要件が固まっていない段階で請負契約は怖い」といった経営層の懸念にも応える必要があります。

一方で、社内には専任のデータエンジニアがおらず、情シスや社内 SE の兼務体制でデータレイク・データ基盤を一から構築するのも現実的ではありません。「フリーランスや業務委託の外部エンジニアに任せる」という選択肢は頭にあっても、どこまで任せられるのか、どう発注設計すれば失敗しないのかの設計図がないまま、決断を先送りにしてしまうケースが多いのが実情です。

近年は Snowflake・BigQuery・dbt・Fivetran といったモダンデータスタックの普及により、大規模なフルスクラッチ開発を伴わずにデータ基盤を構築できる領域が広がりました。この変化を追い風に、大規模ベンダーに一括発注する以外に「フェーズを分割し、外部エンジニアと組んで段階的に構築する」発注設計が実現可能になっています。

本記事では、データ基盤構築を外注する際に「どこまで任せられるか」「どのフェーズをどの契約形態で発注するか」「費用感はどれくらいか」「社内でどのような準備が必要か」を、稟議で説明できる粒度で整理します。データレイク構築を業務委託で実現する進め方も含め、大規模ベンダー丸投げを回避しつつ知見を社内に残す発注設計の設計図を提示します。

データ基盤構築の外注で「稟議が通らない」典型パターン

データ活用プロジェクトを立ち上げる際、多くの企業がまず大手 SIer やデータ基盤ベンダーに相談します。しかし戻ってきた提案書を前に、稟議書の作成段階で手が止まる——この状況には、金額以外にも構造的な理由があります。

稟議で止まる 3 つの理由（金額規模・要件変動・知見が社内に残らない）

大規模ベンダーへの一括発注が稟議で止まる理由は、主に次の 3 点に整理できます。

第 1 に、金額規模のインパクトです。データレイク・データウェアハウスを含む基盤構築の初期費用は、大手 SIer の一括提案では 3,000 万円〜1 億円のレンジになることが珍しくありません。中堅企業にとっては年度予算の枠を超え、取締役会承認が必要な水準に達します。

第 2 に、要件変動リスクです。データ活用は「何を可視化したいか」「どの意思決定に使うか」が走りながら明確化される性質を持ちます。しかし請負契約で一括発注すると、要件変更のたびに追加見積・追加契約が発生し、当初予算を大幅に超過するリスクを抱えます。

第 3 に、知見が社内に残らない懸念です。一括で丸投げすると、開発中の技術判断・設計思想が発注先のブラックボックスに閉じ、運用フェーズで発注者側が主体的に改善できない状況が生まれます。経営層が「データ活用を内製化していきたい」と考えるほど、この懸念は稟議通過の大きな障害になります。

外部エンジニア活用が現実解になった 2 つの追い風

こうした稟議の壁に対し、フリーランス・業務委託を含む外部エンジニアを組み合わせる発注設計が現実的な選択肢として浮上しています。背景には 2 つの追い風があります。

1 つ目は、データ人材不足の常態化です。中堅企業が正社員としてデータエンジニアを採用しようとしても、市場競合が激しく、採用期間が半年以上に及ぶケースは珍しくありません。プロジェクトを止めずに進めるには、業務委託でスキルを補完する選択肢が現実的になります。

2 つ目は、モダンデータスタックの普及です。Snowflake、BigQuery、Amazon Redshift といったクラウド DWH に加え、Fivetran / Airbyte（データ連携）、dbt（データ変換）、Looker / Tableau（可視化）といった SaaS 型ツールを組み合わせることで、フルスクラッチ開発を伴わずにデータ基盤を構築できる領域が大幅に広がりました。これらは 1 人の熟練データエンジニアでも 2〜3 ヶ月で最小構成を立ち上げられるため、フリーランス活用と相性が良い技術構成です。

「大規模ベンダー vs 外部エンジニア」で選び分ける判断軸

大規模ベンダー一括発注と外部エンジニア分割発注は、どちらが優れているかではなく、プロジェクトの性質で使い分けるものです。判断軸を整理すると次のようになります。

自社の状況がどのケースに近いかを整理することが、発注設計の起点になります。

データ基盤構築の外注で任せられる作業範囲

「外部エンジニアにどこまで任せられるか」を判断するには、まずデータ基盤の技術構成を発注者視点で分解し、それぞれの層で委託可能な作業と社内側で意思決定すべきポイントを見える化する必要があります。

データ基盤の 5 つの技術レイヤ（収集・蓄積・変換・可視化・運用）

データ基盤は大きく次の 5 つの層で構成されます。

1. 収集レイヤ: 業務システム（基幹・SFA・広告・Web ログなど）からデータを取得する層。Fivetran / Airbyte などの SaaS 型 ETL ツール、API 連携、CDC（変更データキャプチャ）などが該当します。
2. 蓄積レイヤ: 収集したデータを格納する層。データレイク（Amazon S3、Google Cloud Storage）、データウェアハウス（Snowflake、BigQuery、Redshift）、レイクハウス構成（Databricks）などが該当します。
3. 変換レイヤ: 蓄積した生データを分析用に加工する層。dbt によるモデリング、SQL による集計、データマート設計などが該当します。
4. 可視化レイヤ: 加工したデータをダッシュボード・レポートとして提示する層。Looker、Tableau、Power BI、Metabase などが該当します。
5. 運用レイヤ: 上記全体を安定運用する層。ジョブ監視、データ品質チェック、アクセス権管理、コスト最適化などが該当します。

データレイクという概念自体の位置づけや DWH との違いについて整理したい場合は、データレイクとは？DWH との違いと自社導入が必要か判断する 3 つの問いも併せて参照してください。

各レイヤで外部エンジニアに任せられる作業と社内側の役割

5 つのレイヤそれぞれで、外部エンジニアに任せられる技術作業と、社内側が主体的に担うべき役割を整理します。

社内側が担うべきなのは「業務ロジック」「意思決定」「対外調整」であり、「技術実装」ではない、という切り分けが基本原則です。

データレイク構築を業務委託で実現できる時代になった技術背景

かつてデータレイクの構築は、Hadoop エコシステムを自前で組み立てる大規模プロジェクトで、専門ベンダーの一括受注が主流でした。しかし現在は、以下の技術要素の組み合わせにより、少人数の外部エンジニアで構築できる領域が広がっています。

• クラウドストレージのマネージド化: Amazon S3、Google Cloud Storage が既に業界標準として成熟し、インフラ構築コストが極小化された
• クラウド DWH の登場: Snowflake / BigQuery が「レイクハウス」的にデータレイクの上に載る形で普及し、SQL でデータレイクを操作できるようになった
• ELT ツールの SaaS 化: Fivetran / Airbyte が主要 SaaS（Salesforce、HubSpot、Google 広告など）へのコネクタを標準提供し、接続実装工数を大幅に削減した
• dbt の普及: SQL ベースの変換モデリングが標準化され、属人化しにくいコード管理が可能になった

この結果、データレイク構築を業務委託で実現するプロジェクトは、5〜8 人月規模で最小構成の立ち上げが可能なケースが増えています。データエンジニアの業務委託を役割ベースで活用する方法については、データエンジニアを業務委託で活用する方法も参考にしてください。

フェーズ別・データ基盤構築の外注パターン設計

大規模ベンダーへの一括発注を避け、外部エンジニアを組み合わせる場合、プロジェクトを 4 つのフェーズに分割し、フェーズごとに委託範囲・契約形態・想定期間を設計するのが実務的なアプローチです。

フェーズ1 構想・要件定義（PoC 設計・データソース調査・RFP 骨子作成）

目的: データ活用の目的を明確化し、対象データソース・技術構成の当たりをつけ、次フェーズ以降の RFP 骨子を作る。

このフェーズでは、経営層・現場ヒアリングを通じて「何を意思決定したいか」「そのために必要なデータは何か」を言語化します。外部エンジニアの役割は、要件を技術的に翻訳し、技術選定の選択肢を提示することです。成果物は「要件定義書」「技術構成の初期案」「フェーズ 2 以降の見積根拠となる RFP 骨子」となります。

• 想定期間: 1〜2 ヶ月
• 委託範囲: データエンジニアリング経験者 1 名を準委任で 0.5〜1 人月
• 社内側の役割: 経営層・現場との合意形成、対象データソースの管理部門調整

フェーズ2 基盤構築（ETL/ELT 実装・データマート設計・アクセス制御）

目的: フェーズ 1 で設計した最小構成を実装し、ダッシュボード上で意思決定に使えるデータを流し始める。

このフェーズは要件が固まった状態で入るため、成果物ベースの請負契約か、成果物と工数を組み合わせた準委任契約が選択肢になります。外部エンジニアは ETL/ELT ツールの接続実装、DWH のスキーマ設計、dbt モデルの実装、BI ダッシュボードの初期構築を担います。

• 想定期間: 3〜6 ヶ月
• 委託範囲: データエンジニア 1〜2 名 + BI エンジニア 0.5 名（総計 5〜10 人月）
• 社内側の役割: 業務ロジック（KPI 定義・売上計上ルール等）の意思決定、ユーザー受入テスト

フェーズ3 運用改善（監視設計・データ品質モニタリング・追加要件対応）

目的: 稼働開始した基盤を安定運用しつつ、現場からの追加要件・データマート拡張に対応する。

このフェーズは要件が随時発生するため、準委任契約で継続的に工数を確保するのが現実的です。監視設計・データ品質モニタリング・障害対応の一次切り分け・追加ダッシュボード開発が主な業務範囲になります。

• 想定期間: 稼働開始後 3〜12 ヶ月継続
• 委託範囲: データエンジニア 1 名を準委任で 0.3〜0.7 人月／月
• 社内側の役割: 現場からの要件優先順位づけ、SLA・障害対応フロー整備

フェーズ4 内製化移行（ナレッジ移管・社内エンジニア育成・引き継ぎ）

目的: 外部エンジニア依存を段階的に減らし、社内エンジニアが主体的に基盤を運用できる状態に移行する。

このフェーズでは、ドキュメント整備・ペアプログラミング・レビュー体制の構築などを外部エンジニアに依頼します。社内エンジニアを新規採用・育成する場合、外部エンジニアはメンター的な役割を担うこともあります。契約は準委任がフィットしますが、稼働時間を徐々に減らしていく「テーパリング契約」を検討する余地もあります。

• 想定期間: 6〜12 ヶ月
• 委託範囲: データエンジニア 1 名を準委任で 0.2〜0.5 人月／月（漸減）
• 社内側の役割: 社内エンジニアの採用・アサイン、ナレッジ吸収に必要な時間確保

フェーズ × 委託範囲マトリクスまとめ表

上記 4 フェーズを一覧にすると次のとおりです。

このマトリクスをベースに、自社の予算・スケジュール制約に合わせてカスタマイズすることで、稟議書に「なぜ丸投げではなく分割発注なのか」を根拠付きで説明できる発注計画が組み立てられます。

契約形態の選び方（請負契約・準委任契約）

データ基盤構築の外注で失敗を避けるには、フェーズごとに適切な契約形態を選ぶ判断力が欠かせません。請負契約と準委任契約の違いを理解し、フェーズ特性に合わせて使い分ける設計が重要です。

請負契約が向くケースと注意点（成果物完成責任・追加要件の扱い）

請負契約は、受託者が「特定の成果物を完成させる責任」を負う契約形態です。成果物基準で対価が支払われるため、発注者にとっては予算が読みやすいメリットがあります。

一方で、要件が途中で変わると追加見積・追加契約が発生し、契約管理コストが跳ね上がります。データ活用プロジェクトのフェーズ 1（要件定義）や、要件が固まっていないフェーズ 3（運用改善）では、請負契約は不向きです。

請負契約が特に有効なのは、フェーズ 2 の基盤構築で要件が明確に固まっている場合です。「最初のダッシュボード 3 本を〇月末までに納品」といった具体的な成果物単位で契約すると、受託者側も工数見積が立てやすくなり、双方にメリットが生まれます。

準委任契約が向くケースと注意点（善管注意義務・成果物ではなく業務遂行）

準委任契約は、受託者が「善良な管理者の注意義務」をもって業務を遂行することを約束する契約形態です。成果物完成義務ではなく、時間・工数ベースで対価が支払われます。

要件が走りながら明確化される探索型のフェーズ（フェーズ 1・3・4）に適しています。発注者側の指示のもと、柔軟にタスクを変更しながら進められるため、要件変動リスクを吸収できます。

注意点は、発注者側が業務範囲・優先順位を主体的に管理する必要があることです。「準委任だから任せておけばよい」ではなく、週次のスコープ確認・成果レビューを発注者側が主導する体制を組む必要があります。

フェーズ別に契約形態を切り替える設計

先ほど整理したフェーズごとに契約形態を切り替える設計を、判断基準とともに整理します。

「フェーズ 2 だけ請負に切り替え、他は準委任で通す」という設計も現実的です。発注者側で契約管理コストを最小化しつつ、成果物ベースの規律を必要な場面だけ導入する形になります。

業務委託の指揮命令範囲・フリーランス新法上の実務注意点

業務委託でフリーランスを活用する際、発注者が特に気をつけるべき法的観点が 2 点あります。

第 1 に、指揮命令の範囲です。準委任・請負のいずれでも、発注者は業務委託先に対して「就業時間・就業場所を細かく指示する」「他の業務を随時割り振る」といった、雇用関係に類似する指揮命令を行うことができません。これを行うと偽装請負と見なされ、労働者派遣法違反となるリスクがあります。技術的な指示は「タスク・成果物単位」で行い、労務管理的な指示は避けるのが基本です。

第 2 に、フリーランス新法の 30 日前予告義務です。2024 年 11 月 1 日に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）では、6 ヶ月以上継続する業務委託契約を解除または不更新する場合、30 日前までの予告が義務付けられています（政府広報オンライン）。データ基盤の運用改善フェーズ（フェーズ 3）や内製化移行フェーズ（フェーズ 4）では契約期間が長期化しやすく、この義務の対象になるケースが多いため、契約書面での取り決めと社内の契約管理フローに組み込む必要があります。

データ基盤構築の外注にかかる費用の目安

稟議書に費用感を示すには、大まかなレンジと根拠を持つことが不可欠です。ここではプロジェクト全体の費用レンジ、業務委託人月単価、大規模ベンダー一括発注との構造的な差を整理します。

プロジェクト全体の費用レンジ（初期構築費・運用費）

外部エンジニアを組み合わせた分割発注の場合、費用レンジは規模によって次のように整理できます。

これに加えて、Snowflake・BigQuery などの DWH 利用料、Fivetran・dbt Cloud などの SaaS 利用料が別途発生します。ツール利用料は月額数十万〜数百万円のレンジで、データ量とワークロードに比例します。

業務委託人月単価の目安

2026 年時点でのフリーランス・業務委託のデータエンジニア単価は、経験・スキルレベルに応じて次のような分布になっています（複数のフリーランスエージェント公開情報から集計）。

データ基盤の初期構築を担うシニア級のデータエンジニアは、業界水準として月額 100〜150 万円程度がボリュームゾーンになります。データエンジニアリング領域でも生成 AI 活用の広がりを背景に上振れの傾向があり、単価は継続的に上昇基調にあります（Beyond works 単価相場まとめ）。

大規模ベンダー一括発注との費用構造の違い

同等の技術構成を大規模ベンダーに一括発注した場合と、外部エンジニアを分割発注した場合で、なぜ費用差が生まれるのかを理解しておくと稟議時の説明がしやすくなります。

主な差の要因は次のとおりです。

• オーバーヘッド費用: 大規模ベンダーはプロジェクトマネジャー・営業・品質管理・オフィス費用などの間接コストが単価に上乗せされます
• 二次請け構造: 大規模ベンダーが実装を協力会社に再委託する多層構造では、各層で 20〜30% のマージンが発生します
• リスクバッファ: 請負契約で成果物完成責任を負う場合、要件変動リスクを織り込んだバッファが見積に上乗せされます

外部エンジニアの直接発注では、これらの上乗せが極小化されるため、同等の作業量でも 30〜50% の費用差が生まれます。ただしその分、発注者側で PM・要件整理・意思決定を主体的に担う必要があり、「予算削減の分は自社工数で補う」構造であることを稟議書で明示しておくことが重要です。

発注前に社内で整えるべき準備事項

「丸投げしないと決めた瞬間から、発注者側の準備タスクが始まる」——この認識がないまま外部エンジニアを引き受けると、プロジェクトは走り出せません。ここでは発注前に整えるべき準備事項を 4 点整理します。

データ活用の目的・KPI の明文化

最も重要な準備は、「何のためにデータを活用するのか」を経営層・現場と合意し、成果指標（KPI）を明文化することです。

「データドリブンにしたい」という抽象的な指示のままでは、外部エンジニアは技術判断ができません。「営業部が案件ごとの受注確度を毎週追いたい」「マーケが施策別の LTV を月次で見たい」といったユースケースまで具体化することで、必要なデータソース・更新頻度・粒度が定まります。

このステップを飛ばして発注すると、フェーズ 1 の要件定義に半年以上かかることも珍しくありません。逆に、ここが 2〜3 ページの Word 文書で整理されているだけで、外部エンジニアは即座に技術構成の提案を始められます。

既存データソースと業務プロセスの棚卸し

次に、社内に存在するデータソースを棚卸しします。少なくとも次の情報を一覧化してください。

• システム名（基幹・SFA・広告・Web ログ・Excel など）
• 管理部門
• API 提供の有無・接続方式
• データ更新頻度
• 機密レベル（個人情報・機密情報の有無）

このリストがないと、外部エンジニアはヒアリングだけで数週間を消費します。発注前に発注者側で棚卸ししておくことで、フェーズ 1 の期間を半分に短縮できるケースもあります。

発注者側の意思決定・受入体制の設計

外部エンジニアが技術判断を進めるには、発注者側の意思決定担当者を明確にする必要があります。次の役割を誰が担うかを事前に決めておきましょう。

• プロジェクトオーナー: 予算・スコープ・優先順位の最終意思決定者（部長〜役員クラス）
• プロジェクト窓口: 週次進捗確認・要件調整の実務担当（課長〜主任クラス）
• 業務ドメイン担当: KPI 定義・売上計上ルール等の業務ロジックを整理する現場責任者
• システム管理担当: 対象システムへのアクセス権付与・接続許可を管理する情シス担当

これらの役割が曖昧なまま発注すると、外部エンジニアが「誰に聞けば意思決定が進むか分からない」状態に陥り、プロジェクトが停滞します。

RFP・要件定義の粒度と最低限記載すべき項目

発注前に RFP（提案依頼書）を作成するのが理想ですが、フェーズ 1 の準委任契約で外部エンジニアと一緒に作り込む前提でも構いません。ただし、最低限次の項目は発注者側で整理しておく必要があります。

• プロジェクトの目的: 何を意思決定に使うためのデータ基盤か
• 対象ユースケース: 誰が・どのタイミングで・どのダッシュボードを見るか
• 対象データソース: 棚卸し結果からフェーズ 1 の対象を絞ったリスト
• 制約条件: 予算上限、スケジュール、既存クラウド契約（AWS / GCP / Azure）
• 成功指標: プロジェクト完了時にどうなっていればよいか

粒度が粗くても構いません。「発注者側が主体的に整理した文書」が存在するだけで、外部エンジニアは提案の質と速度を大幅に上げられます。

外部エンジニアと成功させるプロジェクト運営のポイント

発注設計が固まっても、発注後のプロジェクト運営に失敗すると成果は出ません。ここでは、外部エンジニアと組んで成功するために押さえるべき 3 つのポイントを整理します。

スモールスタート原則（PoC → 段階的拡張）

データ基盤構築で最も避けるべきは、「全社統合を最初から目指す」大規模プロジェクトです。優先度の高い単一事業部・単一ユースケースに絞って PoC を立ち上げ、そこで技術構成・運用フローを検証してから段階的に拡張するアプローチが、外部エンジニア活用と最も相性が良い進め方です。

PoC の段階で「ダッシュボード 1 枚が動く」「1 つの意思決定に使える」状態を作ることで、経営層への追加投資の説明がしやすくなり、稟議のハードルも下がります。逆に、最初から全社統合を目指すと、要件調整だけで半年以上を消費し、プロジェクト自体の存続が危うくなります。

ナレッジ移管を契約と運用に組み込む

「知見が社内に残らない」失敗を回避するには、ナレッジ移管を契約書と日々の運用に明示的に組み込む必要があります。契約書の業務範囲に次の項目を含めることを推奨します。

• 設計ドキュメントの成果物化: アーキテクチャ図・スキーマ定義・データフロー図を成果物として明示
• コードの社内リポジトリ管理: 発注者側の Git リポジトリで全ソースコードを管理し、レビュー権を発注者が持つ
• 週次進捗レビューでの技術判断共有: 単なる進捗報告ではなく、なぜその技術選定をしたかの共有を含める
• エンドフェーズでの引き継ぎドキュメント作成: 契約終了時のナレッジ移管パッケージを成果物として定義

これらは追加コストではなく、契約前提として組み込むことで、外部エンジニアも意識的にドキュメント整備を進められます。

内製化ロードマップの設計と社内育成の並走

フェーズ 4 の内製化移行を確実に進めるには、プロジェクト開始時点で「いつ・誰が・どの範囲を内製化するか」のロードマップを描いておく必要があります。

• 12 ヶ月目: フェーズ 2 完了、フェーズ 3 運用開始（外部エンジニア主導）
• 18 ヶ月目: 社内エンジニア採用・アサイン、外部と併走運用開始
• 24 ヶ月目: 社内エンジニアが日常運用を担う、外部は改善・アドバイザリー
• 30 ヶ月目: 外部工数を最小化、内製化完了

このロードマップは経営層への説明資料としても機能します。「今は外部エンジニアに依存しているが、24 ヶ月後には社内で運用できる」という道筋を示すことで、投資判断が通りやすくなります。並行して社内エンジニアの採用・育成計画を進めることも欠かせません。

まとめ｜データ基盤構築の外注は発注設計で成否が決まる

データ基盤構築の外注は、「大規模ベンダーに一括発注するか、社内で内製するか」の二択ではありません。フェーズを分割し、外部エンジニアと組み合わせる発注設計を持つことで、稟議通過のハードルを下げつつ、社内に知見を残す道筋を描けます。

本記事で提示した設計図を振り返ると、要点は次のとおりです。

• フェーズ分割: 構想／基盤構築／運用改善／内製化移行の 4 フェーズに分け、フェーズごとに委託範囲を設計する
• 契約形態の使い分け: 要件が探索的なフェーズ（1・3・4）は準委任、要件が固まるフェーズ（2）は請負を選択肢に入れる
• 費用感の把握: 最小構成 300〜800 万円、標準 800〜3,000 万円のレンジと、業務委託人月単価（80〜150 万円が中心）を稟議書に反映する
• 社内準備の徹底: 目的・KPI 明文化、データソース棚卸し、意思決定体制、RFP 粒度の 4 点を発注前に整える
• プロジェクト運営: スモールスタート、ナレッジ移管の契約組込、内製化ロードマップの並走で「知見が社内に残らない」を回避する

次のアクションとして、まずは自社の「データ活用の目的・KPI」を経営層と現場のヒアリングを通じて 2〜3 ページに言語化し、既存データソースの棚卸しリストを作ることから始めてください。この 2 つが整うだけで、フェーズ 1 の要件定義を外部エンジニアと共に始める準備が整います。稟議書には「なぜ丸投げではなく分割発注なのか」「フェーズごとに何をどう委託するか」を今回整理した設計図で説明することで、経営層の懸念に応える形で承認を得やすくなります。