外注と内製のメリット・デメリット
外注と内製の強みと弱みは、裏返しの関係にあります。
外注
メリット
立ち上げが速い（即戦力の専門家） 採用・育成の負担がない 必要な期間だけ使える変動費 デメリット
客先単価で割高に見える ノウハウが社内に残りにくい 丸投げだとブラックボックス化 内製
メリット
仕様変更を柔軟に・直接調整 ノウハウが社内に蓄積される 長期の改修コストを抑えやすい デメリット
データ人材の採用・育成が難しい 属人化のリスク 片手間では進まない 外注と内製は、それぞれ強みと弱みが裏返しの関係にある 外注の強みと弱み 外注の一番の強みは、立ち上げの速さ です。データ基盤を作れる専門家をすぐに確保でき、採用や育成の時間をかけずに着手できます。必要な期間だけ使える変動費である点も、身軽です。
弱みは、客先提示の単価で割高に見える こと、そして丸投げするとノウハウが社内に残らない ことです。ドキュメントのないまま構築すると、担当ベンダーから離れられず、改修のたびに費用がかさむブラックボックス状態に陥ります。
内製の強みと弱み 内製の強みは、柔軟さとノウハウの蓄積 です。業務を理解した社員が作るので自社に最適化しやすく、仕様変更も直接コントロールできます。社内に技術が残れば、長期の改修コストも抑えやすくなります。
弱みは、はっきりしています。データエンジニアの採用・育成が難しい ことです。IT技術者全体で採用難が続く市場で、経験者の中途採用は6〜12ヶ月かかることも珍しくありません。特定の人に依存する属人化のリスクもあり、片手間では進みません。
内製と外注を分ける4つの判断軸 「結局どっち」を決めるために、4つの軸で考えます。この4軸は完全に独立ではなく、人材を確保できるか が他の3軸の前提になります。重視する軸によって、結論は変わります。
スピード ：早く立ち上げたいなら外注。採用から始める内製は時間がかかるノウハウ ：技術を社内に残し、競争力にしたいなら内製寄り人材 ：データエンジニアを採用・維持できるか。できないなら外注か、外注で伴走を受けながらの内製コスト ：外注は初期にまとまった支出、内製は人件費という固定費が乗り続けるコスト面をもう少し補足します。データエンジニアを1人雇うと、社会保険や採用コストを含めて年1,000万〜1,200万円規模の固定費 がかかります。一方、外注費は高く見えても、必要な期間だけの支出です。ただし、どちらが安いかはコスト単独では決まりません。次章で3年TCOの試算を出しますが、時間軸を伸ばすと内製と外注の損得は逆転します。費用の詳しい内訳はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説 で解説しています。
「外注は立ち上げが速い」と言いましたが、どれくらい速いのかはデータ基盤構築の期間はどのくらい？規模別・工程別スケジュールの目安 で工程別に解説しています。
自社はどちらか、フローで確認する 4つの軸を自社にあてはめて順にたどると、向かうべき方向が絞れます。人材・スピード・長期性の3つの問いで切り分けるのが簡単です。
Q1. データエンジニアを採用・維持できる体制があるか？
3つの問いで、自社が内製・外注・ハイブリッドのどれに向くかを切り分ける ほとんどの企業は、いちばん上の「データエンジニアを採用・維持できるか」でつまずきます。そこが整っていないなら、まずは外注、あるいは外注で立ち上げて運用を内製へ移すハイブリッドが現実的な答えになります。
3年TCOで比較する：内製・外注・ハイブリッドの総コスト 「結局どれが安いのか」を経営会議で議論するために、3年間の総コスト（TCO）を試算してみます。データエンジニア年収中央値900万円、社会保険企業負担15%、採用コスト200万円、クラウド費用月20万円という2026年の相場を組み込んだ数字です。
項目 内製（DE専任1名） 外注（フルスコープ） ハイブリッド 初期構築（1年目） 1,400万人件費＋採用 1,200万設計〜PoC〜本番 1,000万外注構築＋社内0.5名 運用（2年目） 1,150万DE1名＋クラウド 900万運用委託＋改修 750万並走→内製移行 運用（3年目） 1,150万DE1名＋クラウド 900万運用委託＋改修 650万内製主導＋スポット外注 3年TCO合計 3,700万 3,000万 2,400万 立ち上げスピード △ 採用に6〜12ヶ月 ◎ 3〜6ヶ月 ○ 4〜7ヶ月 ノウハウ蓄積 ◎ 全て社内 × 契約依存 ○ 段階的に移転 頓挫リスク 高（採用失敗） 中（ブラックボックス） 低
※ データエンジニア年収中央値900万円（2026年市場相場）、社会保険企業負担15%、採用コスト200万円で試算。クラウド費用は月20万円想定。実際の金額はスコープと採用単価で変動します。
データ基盤の3年TCO試算（データエンジニア年収900万＋社会保険＋採用コスト200万を前提） 数字を見ると、設計と初期構築を外注し、運用フェーズで段階的に内製へ移すハイブリッドが3年TCOで最も安く収まる 、というのが多くのケースで成り立ちます。理由は3つあります。
立ち上げの空白期間（採用待ちの半年〜1年）を発生させない 2〜3年目に外注比率を下げられるため、固定人件費の増分が緩やか ノウハウが社内に貯まるので、内製比重が上がってからの改修が速い 逆に、完全内製が有利になるのは4年目以降まで運用が続き、かつ採用が計画通り進んだ場合に限られます。採用に1年ずれ込むだけで、内製の3年TCOは容易に4,500万円を超えます 。決裁者は「内製は安い」と直感で判断しがちですが、時間軸と採用リスクを織り込むとTCOは逆転します。
なお、この表はあくまで標準ケースの目安です。スコープ・採用単価・既存人材の有無で数字は動くので、実際の意思決定では自社の条件で置き換えてください。データ活用の無料診断 では、この3年TCOを自社のスコープに合わせて試算する形でもご相談を受けています。
契約形態で変わる外注の使い方（請負・準委任・ラボ型・常駐型） 「外注する」と一言で言っても、契約形態によって使い方も費用感もかなり違います。ここを混同したまま見積もりを取ると、比較軸がずれた提案書が並ぶことになります。
契約形態 月額相場（DE1名） 成果責任 自社の主導度 向くフェーズ 請負 スコープ一括500〜3,000万 ベンダー 低 要件が固まった初期構築 準委任 80〜130万 自社 中 要件変動する開発期 ラボ型 90〜150万／名 自社 高 PoC後〜内製移行の橋渡し 常駐型 100〜160万 自社 高 機密データの現地開発
※ 東京圏・シニアクラス（経験5年以上）を想定。ラボ型は同一チームを長期継続する前提で相対的にコストパフォーマンスが上がります。
外注の契約形態4種を、費用相場・自社主導度・向くフェーズで比較 請負：スコープが固まった初期構築向き 成果物の完成に責任を持つ契約です。要件が明確に固まっていて、途中で仕様を大きく変えない前提であれば、総額が読みやすい メリットがあります。一方、要件が動くとその都度追加見積もりが必要になり、機動力は落ちます。データ基盤の初期構築（設計→開発→本番リリースまで）で一括発注するケースで採用されやすい形態です。
準委任（SES型）：要件が動く開発フェーズ向き 作業時間に対して対価を支払う契約で、成果責任は自社側にあります。要件が動く前提の開発期に向き、指示系統を自社で握ったまま外部の技術力だけを借りたい 場面に合います。人月80〜130万円 が相場です。
ラボ型：内製移行の橋渡しに最適 準委任の一種で、同じチームを長期継続する のが特徴です。人月90〜150万円と請負より高く見えますが、ドメイン知識が蓄積されるため、2年目以降のスピードと品質は他形態を上回ることが多いです。「PoC後、本番運用に移してから徐々に内製化したい」という中間解として、いま最も伸びている契約形態です。ラボ型のチームに社内エンジニアを1〜2名混ぜて並走させると、そのまま内製移行の育成期間として機能します。
常駐型：機密データを社外に出せない場合 自社オフィスに常駐して開発する形態で、機密データや個人情報を扱う金融・医療系で選ばれます。月100〜160万円 と単価は高めですが、物理的なデータ移動が発生しないため、セキュリティ要件が厳しい業界では実質これ以外の選択肢がないこともあります。医療・介護分野に特化した3省2ガイドライン準拠でのスモールスタートの進め方は医療・介護のデータ活用とデータ基盤の作り方｜2026年版 で整理しています。
契約形態の選び方は、フェーズと機密性の掛け合わせで決まります。「初期構築＝請負 → 運用移行期＝ラボ型 → 内製主導＋スポット準委任」という時間軸での組み替えが実務では多いです。提案依頼書に落とし込むときの書き方はデータ基盤構築のRFP（提案依頼書）の書き方と項目サンプル にまとめています。
2026年、内製ハードルは3点で下がった 「データ基盤の内製は無理」と半ば前提になっていた2023〜2024年から、この2年で状況は大きく変わりました。
モダンデータスタックがSQL中心になった dbt、BigQuery、Snowflake、Fivetranといったツールの組み合わせが定着し、データパイプラインの多くがSQLとYAMLで書けるようになりました。以前はScalaやPythonでSparkジョブを書く必要があったETL処理も、いまはdbtモデルとELTツールの設定で完結することが多いです。SQLが書ける人材のプールは、データエンジニアのそれより桁違いに大きい ため、この違いは決定的です。
dbt単体でどこまで内製化できるかはdbt導入・構築支援の費用と進め方｜何を依頼できる？ で整理しています。
生成AIがコーディングを7〜8割巻き取る Claude CodeやGitHub Copilotに「このテーブルからLTVを月次で集計するdbtモデルを書いて」と指示すれば、7〜8割のドラフトはその場で出てきます。命名規則やテスト定義まで含めて出力させれば、レビューだけエンジニアに回すという分業が現実的です。生成AIは万能ではありませんが、「専任エンジニアがいないから内製できない」という前提を崩す インパクトがありました。
非エンジニアが担える範囲が広がった 以前は「BIツールでダッシュボードを作る」までが非エンジニアの領域でしたが、いまは「dbtで簡単な集計モデルを作る」「Fivetranで新しいデータソースを繋ぐ」あたりまで、業務担当が手を動かせるようになっています。エンジニアは設計判断とレビューに集中し、実装のかなりの部分を業務側が担う分業モデルが機能し始めました。
もちろん、データモデリング、権限設計、障害時のトラブルシュートといった判断領域は、いまも人の専門性が必要です。実務で機能するのは「AIで底上げされた社内チーム＋要所を握る専門家」という組み合わせです。
フェーズで役割を分けるハイブリッド
3年TCOでも示した通り、実務でうまくいっている企業の多くは、フェーズごとに役割を分けるハイブリッド を選んでいます。工程によって主導役を変えるのがポイントです。
要件整理・改善案何を実現したいか
内製が主導
業務を知る自社にしかできない
→
設計・初期構築ETL・DWH・BI
外注が主導
専門性とスピードを買う
→
運用・改善日々の手入れ
内製へ移行
外注の伴走で引き継ぐ
設計と初期構築は外注、運用と改善を内製に寄せると、コストと自走力のバランスが取りやすい
現実解は、フェーズごとに内製と外注の役割を分けるハイブリッド 要件整理・改善アイデア（内製が主導）：「どの業務の、どの判断を、データで速くしたいか」を決める工程。業務を知る自社にしかできず、外部に丸投げできない領域です 設計・初期構築（外注が主導）：ETL・DWH・BIを実際に作る工程。専門性とスピードを買って外注に任せます 運用・改善（内製へ移行）：日々の手入れは、外注の伴走を受けながら徐々に内製へ移していきます この分け方なら、立ち上げのスピードと品質は外注で確保しつつ、運用しながらノウハウを社内に貯めていけます。外注する場合も、ドキュメント共有や運用引き継ぎを契約に含め、ノウハウが社内に残る形にしておきます。データの整備や社内定着まで含めた伴走は、データマネジメント支援 のような形で受けることもできます。
Evastの現場でも、外食チェーン（数十店舗規模）のPOS売上集計基盤で、設計と初期構築を当社が担い、その後6ヶ月ほど週次で並走したあとに社内チームへ移管したケースがあります。引き継ぎ用のドキュメント（構成図・データディクショナリ・運用手順書）の整備を最初から契約に入れ、移管前3ヶ月はペアプロで並走したことで、内製移行後もパイプラインが止まらずに運用が続いています。
段階的な内製化の進め方 「いずれは内製で回したい」という企業も、一気に内製へ切り替えると失敗します。人材がそろわないまま背伸びすると、属人化や頓挫を招くためです。
現実的なのは、外部パートナーと並走しながら、少しずつ内製の比重を上げていく進め方です。順序としては、
運用の一部から：監視、軽微な改修、データ品質チェックといった定型作業を社内で巻き取る 改修の主導：既存パイプラインの修正や小さな機能追加を、社内でリードし外注はレビュー役に 新規構築の主導：新しいデータマートやダッシュボードを社内で設計・構築、外注はスポット支援 内製主導＋スポット外注：日常運用と改善は完全に社内、繁忙期や高度案件だけ外注を呼ぶ の4段階で進めます。目安として、PoC完了から3〜6ヶ月の並走で内製比重50%を超えたら、次のステップへ 、というリズムです。小さく試して効果を確かめる進め方はデータ基盤のPoCの進め方｜5ステップと成功基準・費用の目安 にまとめています。業種別の実務イメージが必要な方は、外食チェーンの売上集計をExcelから自動化するには｜2026年版 で、多店舗×POSの本部集計を外部パートナーと組んで立ち上げるときの手順を紹介しています。
外注先を選ぶ段階では、「作って渡して終わり」ではなく、ノウハウの移転や運用の引き継ぎに前向きなパートナーか を見極めることが大切です。そもそもどんなタイプの会社に頼むかという比較はデータ基盤構築の会社の選び方・比較｜失敗しない発注先 にまとめています。
機密データを外注に触らせるときの設計 外注で必ず論点になるのが、機密データや個人情報の取り扱いです。「NDAを結んでおけばOK」で済ませてしまうと、実運用で穴が出ます。契約と技術設計の両面で押さえておく項目を挙げます。
契約面：NDAと責任範囲の明文化 NDA（秘密保持契約） ：委託先社員個人にも及ぶ形で締結。退職後の情報保持期間を明記再委託の可否 ：ベンダーが下請けに再委託する場合の事前承認と、下請け先へのNDA延長を明記インシデント発生時の通知義務 ：24時間以内の一次報告など、SLAレベルで具体化契約終了時のデータ処理 ：委託先環境のデータ削除と削除証跡の提出を義務化技術設計面：見せない・触らせない・記録する マスキング／匿名化 ：本番の個人情報そのものを渡さず、氏名・電話番号・メールなどを開発用にマスキング。統計的に近い代替値（合成データ）を使う手もあります最小権限（Least Privilege） ：委託先アカウントには必要なテーブル・カラムだけを許可。BigQueryなら列レベル・行レベルのセキュリティで絞り込みます監査ログ ：誰が・いつ・どのデータにアクセスしたかを全て記録し、社内で定期レビューVPN／IP制限 ：委託先からのアクセス元IPを固定し、社内オフィス以外からのアクセスを遮断開発環境の分離 ：本番DWHと開発用DWHを物理的に分け、開発用にはマスク済みデータのみ配置RFPに書く非機能要件のサンプル文言 提案依頼書には、以下のような文言で明記しておくとベンダー側の対応が揃います。
委託先は、本番環境の個人情報を含むデータを直接参照しないものとし、開発・検証環境ではマスキング済みデータを使用すること。 委託先アカウントの権限は、担当業務に必要な最小範囲に限定し、権限付与・変更は監査ログに記録すること。 データアクセスは指定VPN経由に限定し、アクセス元IPを固定すること。 契約終了時、委託先環境から本プロジェクトに関わるデータ・派生物を削除し、削除完了報告書を提出すること。 RFP全体の書き方はデータ基盤構築のRFP（提案依頼書）の書き方と項目サンプル を参照してください。
内製化・外注でよくある失敗5パターンと回避策 内製と外注の判断そのものより、選んだ後の進め方 で頓挫するケースが多いです。Evastが見てきた失敗を類型化しました。
1. 採用が読めず内製プロジェクトが半年止まる 「今期中にデータエンジニアを採用して内製で立ち上げる」と決めたものの、6〜12ヶ月かけても採用できず、プロジェクト自体が塩漬けに。回避策：採用と並行して外注で立ち上げを開始し、採用できた時点で徐々に移管する二段構えにする。採用リスクを単一シナリオで背負わないのが鉄則です。
2. 丸投げでノウハウが1文字も残らない 要件を口頭で伝え、成果物のダッシュボードだけ受け取る形にした結果、ETLの中身が完全にブラックボックス化。改修依頼のたびに月100万円以上の追加見積もりが飛んでくる状態に。回避策：ドキュメント（構成図・データディクショナリ・運用手順書）の納品を契約要件に入れ、社内メンバーが構築レビューに毎週参加する体制を最初から作る。
3. 引き継ぎドキュメントが不在で内製移行に失敗 外注から内製への切り替え日を決めて臨んだが、渡されたドキュメントが「ソースコードだけ」で、なぜそう作ったかの背景が一切なし。社内チームが読み解けず、結局外注に戻す。回避策：引き継ぎフェーズを契約段階から明示し、「ADR（アーキテクチャ決定記録）」形式で判断の背景まで残す。移行前3ヶ月はペアプロで並走する。
4. 属人化で担当者が辞めて全停止 内製化に成功したものの、キーマンのデータエンジニアが1人に集中し、その人が退職した瞬間にパイプラインが誰にも触れない状態に。回避策：最低2名体制、コードレビュー必須、ドキュメント更新をタスクの一部として工数計上する。生成AIによるコード解説を活用して、属人的な暗黙知を減らす。
5. PoCから本番運用に橋渡しできず立ち消え PoCで良い結果が出たのに、本番運用の体制設計を後回しにして、そのまま尻すぼみに終わる。回避策：PoCの成功基準に「本番移行後の運用体制と担当が決まっていること」を含める。PoC完了と同時に運用フェーズの契約（ラボ型など）に切り替える段取りを最初から組む。
より網羅的な失敗パターンはデータ基盤構築でよくある失敗と発注前チェックリスト にまとめています。
まとめ：内製と外注は役割分担で考える データ基盤の内製と外注について、要点を整理します。
内製と外注に「どちらが正解」はない。選び方を誤ることが失敗につながる 外注は立ち上げが速いが、丸投げするとノウハウが残らない 内製は柔軟でノウハウが残るが、データ人材の採用・育成が難しい（IT技術者全体で採用難が継続） 判断はスピード・ノウハウ・人材・コストの4軸で。3年TCOではハイブリッドが最安になるケースが多い 契約形態は請負・準委任・ラボ型・常駐型を、フェーズと機密性で使い分ける 実務での落とし所は、設計と初期構築は外注、運用と改善は内製に寄せるハイブリッド 2026年は生成AIとモダンデータスタックで、内製で担える範囲が拡大した 「内製か外注か」を一度きりの二択で決めようとすると、どちらを選んでも無理が出ます。フェーズで役割を分け、外注で立ち上げてノウハウを社内に貯めていく。この発想に切り替えれば、自社に合った進め方の道筋は明確になります。
データ基盤の内製・外注の相談はEvastへ 株式会社Evastでは、データ戦略の立案からデータ基盤の設計・構築、運用定着まで を一貫して支援しています。
「内製と外注、自社はどちらで進めるべきか相談したい」 「外注で立ち上げつつ、将来は内製に移したい」 「データ人材の採用・育成と並行して基盤を作りたい」 将来の内製化を見据えた、ノウハウの残る進め方からご提案します。
意思決定を数値で支援：3年TCO無料診断 「内製・外注・ハイブリッドで、自社の3年間の総コストはどう変わるか」を数値で見たい方向けに、データ活用の無料診断
→ データ基盤構築サービスを見る 無料相談を申し込む
