「このシステム、外注したほうがいいのか、それとも社内で人を採って内製でやるべきか」。社内でこの議論になったものの、結論が出ないまま手が止まっている。比較記事を何本か読んでみても、書いてあるのは「コスト・スピード・ノウハウのバランスで、状況によって判断しましょう」という当たり障りのない結論ばかり。読み終わったときに残るのは「で、うちはどっちなの?」という最初と同じモヤモヤだった——。もしそんな状態なら、この記事はあなたのために書いています。
判断が難しいのには理由があります。世の比較記事の多くは中立を装っていますが、書き手が外注を斡旋する立場だったり、フリーランス活用を勧める立場だったりすると、どうしても「外注のメリット」が大きく扱われがちです。かといって受託開発会社に直接相談すれば、当然「ぜひ弊社にお任せください」という方向に話が進みます。発注を受ける側が「やめておいたほうがいいですよ」とはなかなか言ってくれません。だからこそ判断材料が偏り、いつまでも決めきれないのです。
この記事は、システム開発の受託を実際に手がけている秋霜堂株式会社が、あえて発注を受ける側の本音を開示しながら書いています。「こういうケースはうちでも受注をお勧めしません」「受託会社のこの言い分には、こういう事情が隠れています」という、営業トークでは言わない部分まで踏み込みます。外注を売り込むためではなく、あなたが自社の状況を冷静に判断し、私たちのような受託会社と対等に話せるようになることを目的にしています。
先に結論の核心をお伝えします。外注か内製かは「どちらが安いか」では決まりません。決め手は 「この先そのシステムを、誰が・どれだけ変え続けるのか」 という一点です。本記事では、外注に向かないケース、それでも外注が合理的なケース、自社に当てはめる4つの問い、そして受託会社に騙されないための交渉視点までを順に解説します。読み終えるころには、自社の判断を自分の言葉で説明できるようになっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
「外注と内製、どちらが正解か」に受託開発会社が正直に答えると
まず、多くの方が感じている不満をそのまま言葉にします。「比較記事を読んでも結局決められない」。これは読み手の理解力の問題ではなく、記事の構造的な限界によるものです。
なぜ世の比較記事は「状況による」で終わるのか
外注と内製の比較記事は、ほぼ例外なく「メリット・デメリットの一覧表」と「コスト・スピード・ノウハウで判断しましょう」という枠組みで書かれています。これ自体は間違っていません。間違ってはいないのですが、最後まで読んでも判断できないのは、どの軸を優先すべきかという「重み付け」が書かれていないからです。
コストも大事、スピードも大事、ノウハウの蓄積も大事——全部大事だと言われれば、結局どれを優先すればいいのか分かりません。さらに、書き手の多くは外注を斡旋・支援する立場にあるため、無意識のうちに外注のメリットを厚く、デメリットを薄く書く傾向があります。中立を装っているだけで、実は構造的に中立ではないのです。
受託会社が営業トークでは言わない3つの前提
私たちのような受託開発会社が、商談の場ではあまり口にしない前提が3つあります。これを最初に開示しておきます。
- 受託会社にも「受注したくない案件」がある。 仕様が固まらず延々と作り直しが発生する案件や、発注側に判断できる人が一人もおらず後でトラブルになりそうな案件は、内心では受けたくありません。それでも売上のために受注することはあります。
- 「外注すべきでないシステム」は確実に存在する。 自社の競争力の核そのものを外に出してしまうと、その会社の強みが社外に流出します。受託会社として受注はできますが、お客様の事業を考えると勧められないケースがあります。
- 発注金額が膨らむ構造は、受託会社にとって悪い話ではない。 「まずは小さく始めましょう」という提案の裏に、追加発注で結果的に総額が膨らむ前提が含まれていることがあります。
この3つを頭の片隅に置いておくだけで、この先の判断の解像度が大きく変わります。次の章では、まず前提となる用語を整理します。
外注・内製・ハイブリッドとは何か（用語の整理）
判断に入る前に、最低限の言葉の整理をします。すでにご存じの方は読み飛ばしていただいて構いませんが、「各形態で受託会社の儲け方が違う」という観点だけは押さえておくと、後段の話が立体的に理解できます。
外注の3形態（請負・準委任・ラボ型）と、それぞれで受託会社が取るリスク
外注（外部の開発会社に委託すること)は、契約形態によって大きく3つに分かれます。
- 請負契約: 受託会社が「要件どおりの成果物を完成させ、納品すること」に責任を負う契約です。納品できなければ契約不適合責任を問われます（Workship ENTERPRISE「準委任と請負の違い」）。受託会社にとっては完成リスクをすべて自社で背負う形なので、仕様が固まっている案件でないと見積もりが過大になりがちです。逆に言えば、仕様が曖昧なまま請負で発注すると、後述する「追加費用で膨らむ」構造に直結します。
- 準委任契約: 成果物の完成責任はなく、業務を遂行すること（善管注意義務）に責任が生じる契約です。受託会社は完成リスクを負わない代わりに、稼働した分の対価を受け取ります。発注側から見ると「作業はしてくれるが、完成は保証されない」ため、進捗を自分たちで管理する力が問われます。
- ラボ型契約: 準委任の一種で、一定期間・一定数の人材を専属チームとして確保する形態です。要件や仕様を開発しながら詰めていきたい場合に適します（ラクスパートナーズ「ラボ契約とは」）。継続的に手を入れたいプロダクトに向きますが、人材を確保し続けるぶん固定費的なコストがかかります。
ポイントは、「仕様が固まっているなら請負、固まっていないなら準委任・ラボ型」 という大まかな住み分けがあることです。仕様が固まっていないのに請負で発注すると、受託会社は読めないリスクを見積もりに上乗せするか、後から追加費用を請求するかのどちらかになります。
内製とハイブリッド（領域ごとの配分が現実解）
内製は、自社の社員エンジニアでシステムを開発・運用することです。ノウハウが社内に蓄積し、仕様変更にも素早く対応できる一方、エンジニアの採用・育成・定着というハードルがあります。社内にエンジニアが0〜2名という状況では、内製だけで全部をまかなうのは現実的でないことがほとんどです。
そこで現実的な選択肢になるのが ハイブリッド です。「全部外注」か「全部内製」かの二択で考えるのではなく、システムを領域ごとに分けて、外注する部分と内製する部分を切り分けます。たとえば「事業の核となる部分は社内で持ち、定型的な機能や一時的に手が足りない部分は外注する」といった配分です。
実務の感覚として、社内にエンジニアを抱えている中堅企業でも、開発のすべてを内製でまかなっている会社はむしろ少数派です。多くは内製と外注を組み合わせ、自社のコア領域に社内リソースを集中させています。「外注か内製か」という問いは、実際には「どこを外注し、どこを内製するか」という配分の問題なのです。
受託開発会社が正直に言う「外注しないほうがいいケース」
ここが本記事の中心です。受託会社の立場から、「これは外注に向かない」「うちなら受注をお勧めしない」というケースを正直に挙げていきます。これらに当てはまる場合、外注を急ぐ前にいったん立ち止まることをお勧めします。
仕様が固まらない・頻繁に変わるシステム
「何を作るか」がまだ社内で固まっておらず、毎週のように方針が変わる——この状態での外注は、最もトラブルになりやすいパターンです。
理由はシンプルで、外注は「決めたものを作る」のが得意な一方、「決めながら作る」のは苦手だからです。仕様が曖昧なまま発注すると、途中の仕様変更が積み重なり、当初の予算を大幅に超過するケースも珍しくありません。「後から変更が重なれば予算の大幅超過は避けられない」という点は、受託側でも繰り返し指摘されています（ブライセン「外注を丸投げすると危険」）。そして変更のたびに「言った・言わない」の応酬が発生し、双方が疲弊します。
新規事業の立ち上げのように、作りながら仕様を固めていく性質のものは、外注するにしても請負ではなく準委任・ラボ型を選ぶか、あるいは仕様がある程度固まるまで内製や少人数の伴走支援で進めるほうが、結果的にうまくいきます。
自社の競争優位の核そのもの（外に出すと差別化が消える）
そのシステムが「自社が競合に勝っている理由そのもの」である場合、外注には慎重になるべきです。
たとえば、独自のアルゴリズムやデータの使い方、業務フローのノウハウが詰まった基幹部分——ここを丸ごと外注すると、その知見が社外の開発会社に蓄積されていきます。極端な話、同じ受託会社が競合に同種のシステムを提供する可能性もゼロではありません。受託会社としては受注できるので断る理由はないのですが、お客様の事業の将来を考えると、コアは社内に残すことをお勧めしたくなるのが本音です。
逆に、競争優位とは関係のない「どこの会社も似たような形で使う機能」（勤怠管理、定型的な社内申請、汎用的な管理画面など）は、外注して問題ありません。線引きの基準は「これが他社に渡って、自社の強みが薄れるか」です。
改修・運用が継続的に発生するシステム
作って終わりではなく、その後も頻繁に機能追加・改修を続けるシステムは、外注一辺倒だと長期的にコストと身動きの自由を失いがちです。
改修のたびに外注先に依頼し、見積もりを取り、発注し……というサイクルは、社内で直せる場合に比べてスピードもコストも不利になります。さらに、システムの中身を理解しているのが外注先だけという状態が続くと、後述する ベンダーロックイン（特定の業者に依存し、乗り換えが困難になる状態）に陥ります。
冒頭で触れた「誰が・どれだけ変え続けるか」という判断軸が効いてくるのはここです。この先何年も社内で頻繁に手を入れ続けるシステムなら、最初は外注でも、運用フェーズに向けて内製比率を上げていく設計にしておくのが賢明です。
社内に「品質を判断できる人」が誰もいない状態での発注
これが、受託会社として最も「危ういな」と感じるケースです。発注側に、納品物の良し悪しを判断できる人が一人もいない状態での発注です。
要件定義は本来、外注先に丸投げするものではなく、発注側が主体的に関わるべき工程です（イントラマート「外注で失敗しないために」）。ところが社内に判断できる人がいないと、受託会社が出してきた仕様や見積もりが妥当かどうかを検証できず、事実上の「丸投げ」になります。丸投げの行き着く先は、「完成したシステムが、思っていたものと違う」という最悪の結末です。
誠実な受託会社であれば発注側をリードしてくれますが、それはあくまで受託会社の善意に依存した状態です。発注側に最低限のチェック機能がないまま発注するのは、相手を信用するかどうかという賭けになってしまいます。この状態に心当たりがあるなら、まず社内に「窓口となって判断できる人」を一人立てることを、発注よりも先に検討してください。具体的な備え方は、のちほど解説します。
それでも外注が合理的なケース（受託会社が本当に役立つ場面）
ここまで「外注しないほうがいいケース」を正直に挙げてきましたが、「外注＝悪」という極論に振れてほしいわけではありません。正しく外注すれば、外注は大きな価値を生みます。受託会社の立場から見て「これは外注したほうが双方にとって良い」というケースを挙げます。
専門技術・短期集中・採用が間に合わないケース
次のような状況では、外注が合理的な選択になります。
- 特定の専門技術が一時的に必要: たとえばAIや特定の基盤技術など、社内に経験者がおらず、その案件のためだけに採用するのは割に合わない場合。専門性を持つ受託会社に任せたほうが速くて確実です。
- 短期間で一気に作りきりたい: リリース期限が決まっていて、社内リソースだけでは間に合わない場合。外注で開発力を一時的に増強できます。
- 採用のリードタイムを待てない: エンジニアの採用には数ヶ月単位の時間がかかります。今すぐ動かしたい案件に対して、採用を待っていられないなら外注が現実解です。
これらに共通するのは「一時的に・集中的に・専門性をもって」開発力が必要だという点です。こうしたニーズに対しては、私たちのような受託会社が本来の強みを発揮できます。
改修頻度が低く運用が安定するシステム
一度作ってしまえば、その後はほとんど手を入れずに安定して動かせばよいシステムも、外注に向いています。
定型的な業務システムや、仕様がほぼ固まっていて変化の少ない領域は、社内でエンジニアを抱え続けるより、必要なときだけ外注で対応するほうが効率的です。改修が年に数回程度なら、その都度依頼するコストのほうが、専任エンジニアを雇用し続ける固定費より軽く済みます。
「仕様が固まっている × 改修が少ない × 競争優位の核ではない」——この3つがそろうシステムは、外注の典型的な適所だと考えてよいでしょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
自社はどっち？外注vs内製を判断する4つの問い
ここまでの内容を、自社の状況に当てはめられる形に落とし込みます。次の4つの問いに答えてみてください。比較記事にありがちな「状況による」で終わらせず、自社の答えを出すための実践セクションです。
4つの問いとその意味
問い1: そのシステムは、自社の競争優位の核か? 他社に渡ったら自社の強みが薄れるような、事業の差別化そのものに関わる部分かどうか。Yesなら内製寄り、Noなら外注の検討余地ありです。
問い2: この先、何年・どれだけ変え続けるか? 作って終わりか、それとも継続的に機能追加・改修を続けるか。頻繁に変え続けるならノウハウを社内に持つ内製寄り、ほぼ変えないなら外注寄りです。冒頭でお伝えした「誰が・どれだけ変え続けるか」が、この問いに集約されます。
問い3: 社内に、品質を判断できる人がいるか? 納品物や仕様の妥当性をチェックできる人材が社内にいるか。いれば外注しても丸投げにならず安全に進められます。いないなら、外注する前にまず窓口役を立てる必要があります。
問い4: 採用・育成のリードタイムを待てるか? 内製するには人を採り、育てる時間がかかります。その時間を待てるなら内製も選択肢になりますが、今すぐ動かしたいなら外注が現実的です。
回答パターン別の推奨（外注/内製/ハイブリッド）
4つの問いの答えから、大まかな方向性が見えてきます。
- 内製寄りが妥当: 問い1がYes（競争優位の核）かつ問い2がYes（変え続ける）。さらに問い4で採用を待てるなら、社内に開発力を持つ価値が高いケースです。
- 外注が合理的: 問い1がNo（競争優位の核ではない）かつ問い2がNo（ほぼ変えない）。専門性や短期集中が必要で、問い3で判断できる人が社内にいるなら、安心して外注できます。
- ハイブリッドが現実解: コア（問い1がYes）は社内に残し、それ以外を外注する。あるいは「まず外注で立ち上げ、運用フェーズで内製比率を上げる」。多くの中小〜中堅企業にとって、これが最も現実的な落としどころになります。
注意したいのは、問い3が「No(判断できる人がいない)」の場合です。この場合はどの方向を選ぶにしても、まず社内に窓口・判断役を立てることが先決です。判断機能がないまま外注に進むと、丸投げによる失敗のリスクが一気に高まります。なお、こうした3軸・4軸の判断フレームワークをより中立的な視点で整理した内製化と外注の判断基準も併せて参照すると、自社への当てはめがしやすくなります。
受託会社の「この言い分」には注意（発注側が騙されないための視点）
ここからは、発注側として知っておくと交渉で有利になる視点です。受託会社が商談でよく使う言い回しと、その裏にある事情を正直に開示します。誤解のないように補足すると、これらの言い分は必ずしも悪意があるわけではありません。ただ、言葉どおりに受け取ると発注側が不利になりやすいので、受け止め方を知っておく価値があります。
よくある営業トークと裏にある事情
「まずは小さく作りましょう」 スモールスタート自体は健全な進め方です。ただし、この言葉の裏に「最初の見積もりを安く見せ、追加発注で総額を膨らませる」前提が含まれている場合があります。最初の金額だけで判断せず、「完成形までにトータルでいくらかかる見込みか」を必ず確認しましょう。
「保守も含めてお任せください」 保守をまとめて任せられるのは便利ですが、システムの中身を理解しているのが外注先だけという状態が続くと、ベンダーロックインに陥ります。技術的な知識や運用ノウハウが外注先に集中し、他社に乗り換えることが困難になるリスクです（イントラマート）。保守を任せる場合も、ドキュメントとソースコードの引き渡し条件を最初に取り決めておくべきです。
「要件はこちらで詰めますのでご安心ください」 一見親切ですが、要件定義を外注先に委ねきると、「言った・言わない」のトラブルの温床になります。要件定義は発注側が主体的に関わるべき工程です。「お任せ」に甘えず、決まった要件は必ず文書で双方が確認する形にしましょう。
「この技術はうちの得意分野です」 本当に得意なこともありますが、その受託会社が抱えているエンジニアの稼働を埋めたいという事情が混ざっていることもあります。技術選定は「受託会社が得意かどうか」だけでなく「自社が将来運用しやすいか（情報が多く、採用しやすい技術か）」も基準に入れてください。
発注前に受託会社へ必ず投げるべき質問
商談の場で次の質問を投げると、相手の誠実さと、隠れたリスクの両方が見えてきます。
- 「完成形までに、トータルでいくらかかる見込みですか? 追加費用が発生しうるのはどんな場合ですか?」 — 総額と追加リスクの透明性を確認します。
- 「ソースコードとドキュメントは、契約終了後に引き渡してもらえますか?」 — ベンダーロックインを避けるための最重要質問です。
- 「この技術を選ぶ理由は何ですか? 他社でも保守できる技術ですか?」 — 自社が将来困らないかを確認します。
- 「要件のうち、こちらが決めるべきことと御社が提案してくれることの線引きを教えてください」 — 「言った・言わない」を防ぎます。
これらの質問に対して、言葉を濁さず具体的に答えてくれる受託会社は、信頼できる可能性が高いです。逆に、はぐらかしたり「そこは進めながら」と曖昧にする相手には注意が必要です。
「丸投げ」で失敗しないために発注側が最低限やること
外注を選んだ場合、技術力がなくても最低限押さえておくべきことがあります。「丸投げして失敗した」という苦い経験を繰り返さないための、非エンジニア向けの実務ポイントです。
非エンジニアでも押さえるべき4点（仕様/受け入れ基準/窓口/引き継ぎ）
専門知識がなくても、次の4点は発注側の責任として押さえられます。
- 仕様（何を作るか）を文書化する: 完璧な仕様書である必要はありません。「このシステムで何を実現したいか」「絶対に外せない要件は何か」を文章と画面イメージで残すだけでも、認識のズレは大きく減ります。要件定義を外注先に丸投げせず、発注側が主体的に関わることが、失敗回避の起点です（イントラマート）。
- 受け入れ基準（何ができたら合格か）を決める: 「どういう状態になったら納品OKとするか」を発注前に決めておきます。これがないと、納品時に「思っていたものと違う」と揉めても、判断の基準がありません。
- 社内の窓口担当を一人決める: 外注先とのやり取りを一本化する担当者を立てます。窓口が複数いて言うことがバラバラだと、外注先も混乱し、責任の所在も曖昧になります。技術の専門家である必要はなく、「社内の意思決定をまとめて伝えられる人」で十分です。
- コードとドキュメントの引き継ぎ方針を最初に決める: 契約終了後にソースコードとドキュメントを受け取れるよう、最初の契約段階で取り決めておきます。これがベンダーロックインを防ぐ最大の備えです。
この4点は、特別な技術力がなくても発注側の意思だけで実行できます。「丸投げ」と「適切な発注」を分けるのは、技術力ではなく、この最低限の備えがあるかどうかです（ファクトリーシステム「外注管理とは」でも、丸投げではなく発注側が関わるべきポイントが整理されています）。
段階的に内製へ移行する現実的なパス
「今は社内にエンジニアがいないが、将来的には内製も視野に入れたい」という場合、いきなり全内製を目指す必要はありません。段階的なパスがあります。
- 第1段階: 外注で立ち上げる。 ただし最初から、ソースコードとドキュメントを社内に残す契約にしておきます。
- 第2段階: 窓口担当が運用知識を吸収する。 外注先とのやり取りを通じて、社内にシステムの理解者を育てます。
- 第3段階: 改修頻度の高い部分から内製化する。 まず変更が多い領域を社内で持てるようにし、徐々に内製比率を上げていきます。
このパスを取れば、最初は外注のスピードを活かしつつ、長期的にはベンダーロックインを避け、自社で変え続けられる体制に近づけます。外注と内製は二者択一ではなく、時間軸の中で配分を変えていけるものなのです。
まとめ — 外注vs内製は「コスト」ではなく「誰が変え続けるか」で決まる
最後に要点を整理します。外注か内製かの判断は、「どちらが安いか」では決まりません。決め手は 「この先そのシステムを、誰が・どれだけ変え続けるのか」 です。
- 仕様が固まらない／競争優位の核／改修が継続する／社内に判断できる人がいない——こうしたケースは、外注に慎重になるべきサインです。
- 専門技術が一時的に必要／短期集中で作りきりたい／改修が少なく運用が安定する——こうしたケースは、外注が合理的な選択になります。
- 多くの中小〜中堅企業にとっては、「全部外注」でも「全部内製」でもなく、領域ごとに配分するハイブリッドが現実解です。
そして、外注する場合は受託会社の言い分を鵜呑みにせず、総額・引き継ぎ条件・技術選定の理由を質問で確認し、仕様・受け入れ基準・窓口・引き継ぎの4点を発注側の責任として押さえてください。これだけで「丸投げによる失敗」の大半は避けられます。
自社の判断に迷ったら、この記事で挙げた4つの問い——「競争優位の核か」「どれだけ変え続けるか」「判断できる人がいるか」「採用を待てるか」——に立ち返ってみてください。より中立的な3軸フレームワークで自社の状況を整理したい場合は、内製化と外注の判断基準も判断材料になります。受託会社の営業トークではなく、自社の事業の論理から答えを出せば、誰かに誘導されることなく、自信を持って発注判断ができるはずです。
調査ソース:
- Workship ENTERPRISE「システム開発の業務委託｜準委任と請負の違い」
- ラクスパートナーズ「ラボ契約とは？準委任（SES）・請負との違い」
- ブライセン「システム開発の外注を丸投げすると危険？」
- イントラマート「システム開発の外注で失敗しないためには？」
- ファクトリーシステム「システム開発の外注管理とは？」
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 社内にエンジニアが1人もいなくても外注して大丈夫ですか？
技術者がいなくても、納品物の良し悪しを判断し意思決定をまとめて伝える「窓口役」を1人立てれば外注は可能です。判断役が誰もいないまま発注すると事実上の丸投げになり「思っていたものと違う」結果を招くため、発注より先に窓口を決めることをおすすめします。
- 受託会社が「やめたほうがいい」と正直に言ってくれないのはなぜですか？
受託会社は発注を受けて売上を得る立場なので、内心は受けたくない案件でも「お任せください」と話が進むのが構造的な前提です。だからこそ発注側が、総額・引き継ぎ条件・技術選定理由を質問で確認し、自社の事業の論理から判断することが必要になります。
- 「まずは小さく始めましょう」という提案は信用していいですか？
スモールスタート自体は健全ですが、最初の見積もりを安く見せて追加発注で総額が膨らむ前提が隠れている場合があります。最初の金額だけで判断せず「完成形までトータルでいくらかかる見込みか」「追加費用が発生するのはどんな場合か」を必ず確認してください。
- ベンダーロックインを避けるには、契約時に何を取り決めればいいですか？
契約終了後にソースコードとドキュメントを引き渡してもらう条件を、最初の契約段階で明文化しておくことが最大の備えです。保守をまとめて任せる場合でも、システムの中身が外注先だけに集中しないよう、引き渡し条件を先に取り決めておきましょう。
- 外注か内製か、結局どちらか一方に決めないといけませんか？
二択で決める必要はありません。多くの中小〜中堅企業では、競争優位の核は社内に残し、それ以外を外注する「ハイブリッド」が現実解です。まず外注で立ち上げ、運用フェーズで内製比率を上げるなど、時間軸の中で配分を変えていく進め方も有効です。
