「外注のほうが安いですよ」——システム開発の見積もりを取ると、ほぼ必ずこの言葉を聞きます。提示された初期開発費を見て「思ったより安いかもしれない」と感じた一方で、心のどこかに引っかかりが残っていないでしょうか。本当にこの金額で済むのか、3年後にトータルで損をしていないか、と。
引っかかりの正体は、見積書に「初期開発費」しか書かれていないことにあります。運用・保守・改修・社内の管理工数まで含めた「結局いくらかかるのか」が見えないまま、経営層に「3年でいくらです」と説明できず、稟議が止まってしまう。これは、外注を検討する多くの予算責任者が共通して抱える悩みです。
実は、システムのコストで本当に大きいのは初期開発費ではなく、その後に続く運用・保守のコストです。TCO（総保有コスト）という考え方を提唱したガートナーは、システムのコストには導入時の費用だけでなく、運用・保守といった「見えにくいコスト」が継続的に積み上がると指摘しています（ITmedia エンタープライズ／ガートナー）。実際、運用フェーズで発生するランニングコストは、5年間で初期費用の50〜100%にのぼるケースが多く、初期費用と同等かそれ以上に膨らんでいきます（TCO（総保有コスト）とは？システム発注前に5〜10年の費用を試算する方法）。つまり、初期費用だけで「安い／高い」を判断するのは、氷山の水面上だけを見て船を進めるようなものです。
この記事では、受託開発を手がける立場から、見積もりの数字がどう作られているか、なぜ運用フェーズで追加費用が膨らむのか、そして外注・内製・ハイブリッドを「3年トータルのコスト（TCO）」で比較するとどこで損益が逆転するのかを、本音込みで解説します。読み終えたとき、相場の数字を暗記するのではなく、自社の数字に当てはめて総額を組み立て、稟議で説明できる考え方を持ち帰っていただくことが狙いです。
なお、「外注と内製のどちらを選ぶか」という判断軸そのものについては別記事で詳しく扱っています。本記事は、その判断の中でも特に「コストの妥当性・総額」に絞って掘り下げます。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
「外注は安い」は本当か——受託開発会社がコスト構造を正直に話す
最初にお伝えしておきたいのは、「外注は安い」という言葉が嘘というわけではない、ということです。ただし、それは「初期開発の立ち上げだけを見れば」という条件付きの話です。この条件が見積書のどこにも書かれていないために、発注側と受注側の認識がズレてしまいます。
なぜ「外注は安い」と感じてしまうのか
外注が安く見える最大の理由は、提示される初期見積もりを「総額」だと誤解してしまうことにあります。
内製でシステムを作る場合、エンジニアを採用し、育成し、開発環境を整え、その人材を継続的に雇用し続ける必要があります。これらは「人件費」としてまとまった金額が頭に浮かびやすいため、内製は高く感じられます。一方、外注の見積もりは「この機能を作るのに○○万円」と一括で提示されるため、内製で必要な採用・育成・継続雇用のコストが視界から外れ、相対的に安く見えるのです。
しかし、ここで抜け落ちているのが「作った後」のコストです。システムは納品されたら終わりではなく、そこから何年も使い続け、不具合の修正や機能の追加が発生します。初期見積もりにはこの「使い続けるコスト」が含まれていないことがほとんどです。安く見えた金額は、あくまでスタート地点の費用に過ぎません。
受託会社が見積もりで「運用フェーズのコスト」を前面に出さない理由
では、なぜ受託会社は最初から「運用まで含めると総額はこうなります」と提示しないのでしょうか。悪意があるわけではなく、構造的な理由があります。
第一に、運用フェーズのコストは発注時点では正確に見積もれないからです。リリース後にどれだけ改修が発生するか、利用者がどれだけ増えるか、不具合がどの程度出るかは、作ってみないと分かりません。受託会社としては、不確実な金額を最初に大きく提示すると失注につながるため、確定している初期開発費だけを前面に出すのが自然な力学になります。
第二に、発注側が「初期費用の相場」で各社を比較するため、見積もりを初期費用に最適化せざるを得ないからです。相見積もりで「A社は500万円、B社は450万円」と並べられれば、運用まで誠実に見積もって総額を高く見せた会社ほど不利になります。結果として、業界全体が「初期は安く、運用は別途」という見せ方に収束していきます。
ここで重要なのは、この構造を責めることではなく、発注側が「初期費用は氷山の一角であり、本当の総額は運用まで含めて自分で見積もる必要がある」と理解しておくことです。次の章から、その総額を組み立てるための具体的な見方を解説していきます。
外注費用の内訳を分解する——見積書の数字はどう作られているか
「この見積もりは妥当なのか」を判断するには、相場の総額を別の見積もりと比べるだけでは不十分です。金額がどういう要素から組み立てられているかを分解できれば、自社で妥当性をチェックできるようになります。
人月・人月単価とは——見積もりの最小単位
システム開発の見積もりは、ほぼすべて「人月（にんげつ）」という単位を基礎にしています。人月とは「エンジニア1人が1ヶ月作業する作業量」のことで、見積もりは原則として次の計算式で組み立てられます。
開発費 ＝ 人月単価 × 開発人数 × 開発期間（月）
「人月単価」は、エンジニア1人を1ヶ月稼働させるのにかかる費用です。職種や経験によって幅があり、たとえばシステムエンジニアで月65万〜110万円程度、プロジェクトマネージャーで月110万〜150万円程度がひとつの目安とされています（発注ラウンジ（hnavi））。経験年数で見ると、経験1〜3年のジュニアで月50万〜80万円、経験7年以上のシニアで月100万〜180万円程度と、スキルによって大きく変動します。
つまり「500万円の見積もり」という数字は、たとえば「月単価80万円のエンジニアが、おおよそ6人月分（3人で2ヶ月、など）働く」といった内訳に分解できます。この分解ができると、「なぜこの金額なのか」を受託会社に質問できるようになります。
見積もりの大半は人件費——どこに費用が乗っているか
システム開発費の内訳で最も大きな割合を占めるのは人件費です。一般的に、開発費全体の40〜60%を人件費が占めることが多いとされています（パソナ）。プロジェクトの性質によっては、これがさらに大きな割合になることもあります。
これは裏を返すと、システム開発は「人が手を動かす時間を買っている」ということです。サーバー費用やソフトウェアのライセンス費用も含まれますが、それらは多くの場合、人件費に比べれば小さな割合にとどまります。見積もりが高い・安いの差は、結局のところ「何人が、どれだけの期間、どのスキルレベルで関わるか」の差だと考えると見通しがよくなります。
したがって、見積もりをチェックするときは「総額」ではなく「どのスキルの人が何人月分か」を確認するのが有効です。同じ500万円でも、シニア中心の少人数構成か、ジュニア中心の大人数構成かで、品質も後々の改修コストも変わってきます。
「相場」を鵜呑みにしない——同じ機能でも金額が割れる理由
相場の数字は便利ですが、鵜呑みにするのは危険です。同じ「予約システム」でも、要件の細かさ次第で金額が数倍に割れることは珍しくありません。
金額が割れる主な要因は、要件の定義度です。「予約ができればよい」のか、「複数拠点・複数スタッフ・キャンセル待ち・外部カレンダー連携まで必要」なのかで、必要な人月はまったく変わります。相場記事に載っている金額は「ある前提のもとでの平均」であり、自社の要件がその前提と一致している保証はどこにもありません。
ですので、相場の数字は「この桁で合っているか」を確認する大まかな目安として使い、最終的な妥当性は「内訳（人月構成）」で判断するのが現実的です。相場と見積書の相場比較をより詳しくチェックしたい場合は、システム開発費用の見積書チェックリストで具体的な確認項目を整理しています。
初期費用だけで判断する危うさ——3年TCOで見る外注と内製のコスト
ここからが本記事の核心です。初期費用だけで外注・内製を比較すると、判断を大きく誤る可能性があります。判断の土台に据えるべきは、初期費用ではなく「TCO（総保有コスト）」です。
TCO（総保有コスト）とは——初期費用は氷山の一角
TCO（Total Cost of Ownership＝総保有コスト）とは、システムの導入から運用、改修、廃棄までのライフサイクル全体にかかる費用の総額を指します。米国の調査会社ガートナーが提唱した概念で、導入時に見えやすい費用だけでなく、運用フェーズで継続的に発生する「見えにくいコスト」までを含めて総額をとらえる考え方です（ITmedia エンタープライズ／ガートナー）。
TCO は大きく次の2層に分けて考えると整理しやすくなります。
- イニシャルコスト（初期費用）: 開発・導入時に一度だけ発生する費用。見積書に書かれている「初期開発費」がこれにあたります。
- ランニングコスト（運用費用）: システムを使い続ける限り、毎月・毎年発生し続ける費用。サーバー費用、保守契約費、機能改修費、社内の運用管理工数などが含まれます。
冒頭でも触れたとおり、ランニングコストは積み重なると軽視できない金額になります。たとえば運用・保守にかかるコストは、5年間で初期費用の50〜100%にのぼるケースが多く、初期費用と同等かそれ以上に膨らんでいきます（TCO（総保有コスト）とは？システム発注前に5〜10年の費用を試算する方法）。初期費用だけを見て判断するのは、氷山の水面上に出た一角だけを見ているのと同じことなのです。TCO の試算手順そのものをさらに詳しく知りたい場合は、TCO（総保有コスト）の試算方法で5〜10年スパンの考え方を解説しています。
外注・内製・ハイブリッドの3年コストはどこで逆転するか
それでは、外注・内製・ハイブリッドを3年トータルで比較すると何が見えてくるでしょうか。具体的な金額は要件によって大きく変わるため断定はできませんが、コスト構造の「形」には共通したパターンがあります。
- 外注（フル外注）: 初期費用は明確で、立ち上げは速い。ただし改修のたびに発注・見積もり・支払いが発生するため、改修が頻繁だとランニングコストが積み上がりやすい。
- 内製: 初期に採用・育成・環境整備のコストがかかり、立ち上がりは遅く高くつく。一方、エンジニアを雇用していれば改修は「すでに払っている人件費の中」で吸収でき、改修が多いほど1回あたりの限界コストは下がっていく。
- ハイブリッド: 初期開発は外注で速く立ち上げ、運用・改修は内製や準委任で内側に取り込む形。初期の立ち上げの速さと、運用フェーズのコスト抑制を両立しやすい。
この3つを時間軸で並べると、短期では外注が安く、改修が継続的に発生するほど内製やハイブリッドが追いついて逆転する、という構造が見えてきます。逆転の分岐点を決める最大の変数が「改修頻度」です。
リリース後にほとんど手を入れない（年に数回の軽微な修正で済む）システムなら、外注のままが総額で安くなりやすい。逆に、事業の成長に合わせて毎月のように機能を足し続けるシステムなら、改修のたびに外部発注コストが乗る外注より、内製・ハイブリッドのほうが3年トータルで安くなる可能性が高まります。「自社のシステムは作った後どれだけ手を入れるのか」を見積もることが、外注・内製の選択の出発点になります。
「採用・育成・離職」という内製側の見えにくいコストも勘定に入れる
ただし、内製が常に安いわけではありません。内製には外注にはない「見えにくいコスト」があり、これを勘定に入れずに「内製のほうが安い」と判断すると、こちらもまた誤りになります。
内製で見落とされがちなコストは次のとおりです。
- 採用コスト: エンジニアを採用するための求人広告費・エージェント費用・面接にかかる社内工数。即戦力人材ほど採用は難しく、コストもかかります。
- 育成コスト: 採用した人材が自社のシステムを理解し、生産性を発揮するまでの立ち上がり期間。この間も人件費は発生し続けます。
- 離職リスク: 1人のエンジニアに依存していると、その人が辞めた瞬間にシステムを誰も触れなくなり、改修が止まる（属人化リスク）。これは金額に表れにくい、しかし致命的になりうるコストです。
外注の「3年TCO」と内製の「3年TCO」を比較するときは、外注側の運用・改修コストを加えるのと同じ厳密さで、内製側のこれらのコストも加えてください。両者をフェアに並べて初めて、自社にとっての本当の損益分岐点が見えてきます。
なぜ外注は「追加費用」で膨らむのか——受託会社が正直に明かす構造
「最初の見積もりは安かったのに、気づいたら追加費用で当初の1.5倍になっていた」——外注でよく聞く話です。これも悪意ではなく、契約と見積もりの構造から生まれます。発生メカニズムを知っておけば、発注側で事前に防げる部分が増えます。
追加費用が生まれる典型3パターン
追加費用が発生する場面は、大きく次の3パターンに整理できます。
- 仕様が未確定のまま着手するパターン: 「とりあえず作り始めて、細かい仕様は走りながら決めましょう」という進め方は、立ち上げは速い反面、後から「これも必要だった」が次々と出てきます。当初の見積もりは「決まっていた範囲」に対する金額なので、追加で決まった分は当然追加費用になります。
- 仕様変更パターン: 開発の途中で「やはりこういう仕様に変えたい」となるケース。すでに作った部分を作り直すコストが発生するため、変更のタイミングが後ろになるほど追加費用は大きくなります。
- スコープ解釈の差パターン: 発注側は「当然含まれている」と思っていた機能が、受託側は「見積もりの範囲外」と認識していた、という認識のズレ。たとえば「管理画面」と一言で言っても、どこまでの操作ができるかの解釈が双方で違うと、後から差分が追加費用として表面化します。
これら3つに共通するのは、「最初に決まっていなかったことが、後から費用として顕在化する」という点です。逆に言えば、最初に仕様とスコープを明確にしておくほど、追加費用は抑えられます。
「まずは小さく」の見積もりが総額で膨らむ仕組み
「まずは小さく始めましょう」という提案は一見良心的に見えますが、総額の観点では注意が必要です。
小さく始めた初期見積もりは確かに安く済みます。しかし、本当に必要だった機能を後から追加していくと、最初からまとめて作るより総額が高くなることがあります。理由は、後から機能を足すと、すでに作った部分との整合性を取り直したり、設計を見直したりする手戻りコストが乗るためです。最初から全体を見据えて設計していれば不要だった作業が、分割したことで発生してしまいます。
これは「小さく始めるのが悪い」という話ではありません。検証目的でまず最小限を作るのは合理的な選択です。ただ、「初期見積もりが安い」ことと「総額が安い」ことは別物だと理解した上で、最初に全体像（最終的にどこまで作るのか）を受託会社と共有しておくことが、総額の膨張を防ぐ鍵になります。
費用を抑える発注の仕方——受託会社が「これをやられると値引きしにくい」と感じる打ち手
ここからは、総額を実際に抑えるための発注側の打ち手を、受託会社の本音込みで紹介します。単純な値切りは品質低下や関係悪化を招くだけで、総額の構造を変える効果はほとんどありません。効くのは、コストの構造そのものに働きかける打ち手です。
総額を下げる最大のレバーは「作る範囲を削る」こと
費用を抑える最も効果の大きいレバーは、値切りでも相見積もりでもなく、「作る範囲（スコープ）を削る」ことです。
前述のとおり、見積もりの大半は人件費であり、人件費は「何をどれだけ作るか」で決まります。したがって、作る機能を1つ減らせば、その機能にかかる人月がまるごと減り、初期費用も将来の保守費用も同時に下がります。これは値切りでは得られない、構造的なコスト削減です。
具体的には、機能に優先順位をつけ、「本当に最初から必要な機能」と「後でも、あるいはなくてもよい機能」を仕分けします。「あったら便利」レベルの機能を初期スコープから外すだけで、総額は大きく変わります。受託会社の立場から正直に言うと、丁寧に優先順位を整理してくる発注者ほど、こちらも無駄な提案を乗せにくく、結果として総額が引き締まります。
相見積もりは「金額」でなく「内訳と前提」で比較する
相見積もりは有効な手段ですが、総額の数字だけを並べて安いほうを選ぶのは逆効果になりかねません。
なぜなら、安い見積もりは「前提が小さい」ために安いだけかもしれないからです。A社が550万円、B社が420万円だったとして、B社が安いのは、A社が見積もっていたテストや運用引き継ぎを範囲外にしているからかもしれません。その場合、B社を選んでも後から追加費用でA社の金額に近づき、結局割高になることすらあります。
相見積もりで見るべきは「金額」ではなく「内訳（人月構成）」と「前提（どこまでが範囲か）」です。各社に同じ要件・同じ前提で見積もりを依頼し、内訳まで開示してもらった上で比較すれば、見かけの安さに惑わされず、本当に総額が安い相手を選べます。
引き渡し条件とハイブリッド化で長期コストを下げる
長期のランニングコストを下げるには、「引き渡し条件」と「ハイブリッド化」の2つが効きます。
引き渡し条件とは、ソースコードや設計書、開発環境を発注側が受け取れるようにしておく取り決めです。これがないと、改修のたびに必ず元の受託会社に依頼するしかなくなり、価格交渉力を失います（いわゆるロックイン）。契約時にソースコードの帰属やドキュメントの納品を明確にしておくだけで、将来「別の会社に頼む」「内製に切り替える」という選択肢が残り、長期コストの上限を抑えられます。
ハイブリッド化とは、初期開発は外注で速く立ち上げつつ、運用・改修フェーズを徐々に内製や準委任契約で内側に取り込んでいく進め方です。改修が継続的に発生するシステムでは、改修のたびに外部発注するより、内側で吸収できる体制を作ったほうが3年トータルのコストは下がりやすくなります。最初からすべてを内製しようとせず、「外注で立ち上げ、運用は内側へ」という設計が、立ち上げの速さとコスト抑制を両立させます。
自社のコストを試算する——稟議に出す数字の組み立て方
ここまでの内容を、自社のケースに当てはめて「稟議に出せる数字」へ落とし込みます。完璧な精度は不要です。経営層に「3年でいくらかかるのか」「なぜ外注（または内製・ハイブリッド）なのか」を説明できる概算が作れれば十分です。
3年TCO試算の埋めるべき項目
外注・内製・ハイブリッドそれぞれについて、次の4項目を埋めると3年TCOの概算が出ます。
項目 | 外注 | 内製 | ハイブリッド |
|---|---|---|---|
① 初期費用 | 初期開発の見積額 | 採用費＋育成期間の人件費＋環境整備費 | 初期開発の外注額（内製より小さめ） |
② 年間運用費 ×3年 | 保守契約費＋サーバー費 ×3年 | 担当者人件費（運用分）×3年 | 外注保守＋内製運用の合算 ×3年 |
③ 3年間の改修費 | 想定改修回数 × 1回あたり外注費 | 改修担当の人件費（②に含まれることが多い） | 外注改修＋内製改修の合算 |
④ 社内管理工数 | 発注・検収・調整にかかる自社人件費 ×3年 | 採用・育成・マネジメントの自社工数 ×3年 | 両方の中間 |
ポイントは、外注側にも「④社内管理工数」が必ず発生することと、内製側にも「①採用・育成」という初期コストがあることを忘れないことです。この4項目を3つの選択肢で横並びにすると、どこで逆転するかが数字として見えてきます。
試算結果の読み方——どの数字が出たら外注・内製・ハイブリッドか
埋めた数字は、次の観点で読み解きます。
- 改修頻度が低い（年数回の軽微な修正で済む）場合: 外注の3年TCOが最も小さくなりやすい。立ち上げが速く、運用負荷も低いため、無理に内製する理由は薄くなります。
- 改修頻度が高い（毎月のように機能を足す）場合: 内製・ハイブリッドの3年TCOが外注を下回りやすい。改修1回ごとに外部発注コストが乗る外注の不利が、回数とともに効いてきます。
- 改修頻度が高いが、すぐに採用できる人材がいない場合: ハイブリッドが現実解になりやすい。外注で立ち上げ、運用・改修を段階的に内側へ移すことで、内製の立ち上げの遅さと外注の改修コスト高の両方を避けられます。
なお、ここで扱ったのはあくまで「コスト」の観点です。実際の意思決定では、コストに加えて、開発スピード・社内へのノウハウ蓄積・事業のコア領域かどうかといった軸も合わせて判断する必要があります。コスト以外も含めた総合的な判断軸については、外注と内製の判断基準で受託会社の本音込みで整理しています。中立的な3軸フレームで考えたい場合は内製化と外注の判断フレームワークも参考になります。
まとめ——外注の安さは「初期費用」、損益は「3年の総額」で決まる
最後に、本記事の要点を整理します。
- 「外注は安い」は初期費用に限った話です。運用・保守の「見えないコスト」は積み重なると初期費用に匹敵する規模になるため、初期費用だけで判断すると氷山の一角しか見ていないことになります。
- 見積もりの妥当性は「総額」でなく「内訳（人月構成）」で判断します。見積もりの大半は人件費であり、「どのスキルの人が何人月か」を確認すれば、相場を暗記しなくても妥当性をチェックできます。
- 外注・内製・ハイブリッドの損益は「改修頻度」で逆転します。改修が少なければ外注、改修が多ければ内製・ハイブリッドが3年トータルで安くなりやすい。内製側の採用・育成・離職コストも忘れずに勘定に入れてください。
- 追加費用は「最初に決まっていなかったこと」から生まれます。仕様とスコープを最初に明確にし、全体像を受託会社と共有しておくことが、総額の膨張を防ぐ最大の予防策です。
- 総額を下げる最大のレバーは「作る範囲を削る」ことであり、値切りではありません。相見積もりは内訳と前提で比較し、引き渡し条件とハイブリッド化で長期コストの上限を抑えましょう。
外注の見積もりを前に稟議が止まっているなら、まずは外注・内製・ハイブリッドの3つを、初期費用・年間運用費・3年改修費・社内管理工数の4項目で横並びにしてみてください。相場の暗記ではなく、自社の数字で組み立てた3年TCOこそが、経営層を納得させる説明の根拠になります。「初期はこちらが安いが、3年で見ると逆転する（しない）」と数字で語れたとき、その発注判断は単なる相場感ではなく、根拠のある意思決定になっています。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 3年TCOを試算するとき、最初に調べるべき数字は何ですか？
まず受取済みの外注見積書から「初期開発費」を確認し、次に「年間保守契約費＋サーバー費」と「想定改修回数×1回あたり外注費」を受託会社に問い合わせて埋めます。この3項目を揃えるだけで外注側のTCO概算が出せ、内製・ハイブリッドとの比較軸が作れます。
- 自社の「改修頻度」はどう見積もればよいですか？
既存システムがある場合は過去1〜2年の改修依頼件数を数えるのが最も確実です。新規システムの場合は、事業の成長速度（機能追加の要望が月1回以上発生しそうか）を基準に「頻繁（月1回以上）」「低頻度（年数回）」で分類するだけで、外注・ハイブリッドの損益分岐点の判断に使えます。
- 見積書に保守費用が含まれているかどうかは、どこを見て確認しますか？
見積書の「対象範囲」または「備考」欄に「リリース後〇ヶ月の保守を含む」と記載があれば含まれています。記載がない場合は含まれていないと判断し、「リリース後の不具合対応・軽微な修正はどのように取り扱いますか？」と受託会社に明示的に確認してください。
- 相見積もりで人月構成を開示してくれない受託会社には、どう対応すればよいですか？
「総額の妥当性を社内で説明する必要があるため、工程別の人月数と単価レンジだけでも教えてください」と依頼するのが最初の一手です。それでも開示しない場合、見積もり根拠を説明できない会社とは追加費用交渉でも不利になりやすいため、開示に応じる会社を選ぶ判断材料として扱うのが現実的です。
- 「作る範囲を削る」際に、どの機能を削るか判断する基準はありますか？
「この機能がなければリリースを延期しなければならないか」を問い、答えが『No』なら後回しに分類します。具体的には、初期リリースで必須の機能（コア業務フロー）と、あると便利だが後から追加できる機能（通知・レポート・管理画面の拡張）に仕分けするのが現実的な出発点です。
- 内製とハイブリッドはどちらを選べばよいですか？
今すぐ採用できるエンジニアがいればフル内製、採用に時間がかかる場合はハイブリッド（外注で先行立ち上げ→運用を段階的に内側へ移す）が現実解です。採用・育成が整う前にフル内製を選ぶと、立ち上げの遅延とコスト増が重なるリスクがあります。
