システム開発は内製化すべきか、外注すべきか

「情報システム部門を強化して内製化する方針が出た。ただ、どこまで自社でやるべきなのかが決まらない」

「外注していたシステムの改修に、毎回1か月かかる。これなら自社で持ったほうが早いのではないか」

「内製化を進めたが、作った本人が退職してから誰も触れなくなった」

システム開発を内製化するか外注するか。このご相談は、こうした声から始まります。

先に、この記事の立場を書いておきます。

内製化は、多くの企業にとって望ましい方向です。ただし、開発まで含めた完全な内製化を、自社だけで維持し続けるのは現実的ではありません。技術の選択肢は増え続け、必要なスキルも変わり続けます。それを全部追いかけられる体制を、事業会社が単独で持ち続けるのは負担が大きすぎます。

一方で、外注し続ける形にも限界があります。事業の中核が社外にあり続けると、変えたいときに変えられません。

現実的なのは、その中間です。事業を進めながら、技術と判断の型が少しずつ社内に移っていく状態。この記事では、その形をどう作るかを整理します。

当社（wesionaryTEAM）は受託開発を行っている会社であり、同時に自社の業務ツールを自分たちで作って運用してもいます。作る側と、社内で持つ側の両方を経験している立場から書きます。

内製化・外注・受託開発が、それぞれ何を指すか

言葉の指す範囲がずれたまま議論すると、噛み合いません。先に揃えておきます。

内製化とは、外部に委託していたシステム開発や運用を、自社の人員で行うように切り替えることです。すべてを自社に取り込むという意味ではありません。

外注は、システム開発を外部の会社に任せることの総称です。契約の形はいくつかあります。

受託開発は、成果物を納品することに対して報酬が発生する契約です。要件を決め、設計・開発・テストまでを請け負う会社が一貫して担当します。

これと混同されやすいのがSES（システムエンジニアリングサービス）で、こちらはエンジニアの稼働時間に対して報酬が発生します。人手を補う契約であって、成果物を約束する契約ではありません。「外注した」と言っても、この2つでは責任の所在がまったく違います。

内製化を検討するときに比較すべき相手が、受託開発なのかSESなのかは、先に確認しておく価値があります。受託開発そのものの進め方や契約の形については、受託開発とは何か ― 契約の形と、発注前に決めておくことに整理しました。

外注のメリットとデメリット

判断の軸に入る前に、それぞれの長所と短所を並べておきます。

外注のメリット

採用せずに始められる。 エンジニアを雇わずに開発を始められます。人材の採用と育成にかかる時間を、そのまま短縮できます。

専門的なスキルをすぐ使える。 特定の技術に詳しい人を、その期間だけ確保できます。自社で常時抱える必要がありません。

必要な期間だけ費用が発生する。 プロジェクトが終われば費用も止まります。固定費になりません。

社内の負担が増えない。 既存の業務を抱えている人に、開発の負荷を上乗せせずに済みます。

外注のデメリット

社内にノウハウが残りにくい。 設計の理由や運用上の勘所が、外部にたまります。意識的に引き継がないと、次も外に頼むことになります。

変更のたびに時間がかかる。 見積もり、合意、着手という往復が毎回発生します。変更が多いほど、この待ち時間が積み上がります。

社外に情報を渡すことになる。 業務の内容、顧客のデータ、場合によっては技術的な機密が委託先に共有されます。取り扱いの取り決めが要ります。

認識のずれが起きやすい。 事業側の意図が伝わりきらないまま作られると、動くけれど使われないものになります。

内製化のメリットとデメリット

内製化のメリット

ノウハウが社内に残る。 なぜその設計にしたのかが、人と一緒に社内に蓄積されます。次の判断が速くなります。

変更に柔軟に対応できる。 思いついた翌日に直せます。事業の速度と開発の速度が近づきます。

情報漏洩のリスクを抑えられる。 顧客データや機密情報を社外に出さずに扱えます。セキュリティ要件が厳しい領域では、これが決め手になることがあります。

事業の理解が深い人が作る。 何のための機能かを分かっている人が手を動かすため、仕様の詰めが速くなります。

内製化のデメリット

固定費になる。 開発する案件が無い期間も人件費は発生します。

採用と育成にコストがかかる。 採用の費用と時間に加えて、事業と既存システムを理解してもらう期間が必要です。IT人材の確保そのものが難しい状況では、ここが最大の制約になります。

属人化しやすい。 レビューする人がいないまま進むと、その人しか触れないものが増えます。

最新の技術に追いつきにくい。 少人数の体制では、扱える技術の幅が限られます。

判断を分ける5つの軸

内製化か外注かは、どちらが優れているという話ではありません。また、全体をどちらかに決める話でもありません。仕組みごと、領域ごとに見るものです。次の5点で見ると、判断できるようになります。

1. その仕組みが事業の中核にあるか

売上や顧客体験に直接効く部分、他社との差別化そのものにあたる部分は、内製に寄せる価値があります。逆に、勤怠管理や経費精算のように、どの会社でも要件が大きく変わらないものを自社で作る理由は多くありません。

2. どのくらいの頻度で変えるか

月に何度も仕様が変わる仕組みは、内製が向きます。外注は1回ごとに見積もりと調整が発生するため、変更が多いほど待ち時間が積み上がります。逆に、一度作れば数年変えないものは、外注のほうが総額で安く収まります。

判断に迷ったら、直近1年でその仕組みを何回変えたかを数えてみてください。

3. 人を採用し、辞めない状態を作れるか

内製化の議論で最も軽く見られがちなのがここです。エンジニアを1人採用できたとしても、その人が辞めた瞬間に止まる状態であれば、内製化したことにはなりません。

必要なのは1人ではなく、レビューし合える体制です。最低でも複数人、そして人材を採用し続けられる魅力が会社側にあるかどうかが問われます。

確認しておきたいのは次の3点です。

第一に、採用できる見込みがあるか。求人を出せば来るという前提で計画を立てると、そこで止まります。給与水準、開発環境、任せる裁量が市場と釣り合っているかを先に見てください。

第二に、評価できる人がいるか。技術者を採用するには、技術者を評価できる人が要ります。ここが社内にいない場合、採用の精度が上がりません。移行期間に外部と組む理由の一つがこれです。

第三に、辞めない理由を用意できるか。事業の中核を任せるのであれば、その人にとって面白い仕事である必要があります。運用の当番だけを任せる形では、採用できても定着しません。

4. いつまでに必要か

3か月後に動いていなければ意味がない、という案件で、採用から始めるのは現実的ではありません。採用に3か月、立ち上がりに3か月かかると考えると、内製で着手できるのは早くて半年後です。

短期で必要なものは外注、時間をかけて積み上げるものは内製、という分け方になります。両方が必要な場合は、最初の版を外注で出し、並行して社内の体制を作り、次の版から内製に移すという順番が取れます。

5. コストをどう見るか

ここは短期と長期で逆転します。初期のコストだけを比べると判断を誤るため、次の章で詳しく書きます。

コストは、短期と長期で逆転する

外注の費用は、プロジェクトごとにまとまって発生します。内製の費用は、人件費として毎月発生し続けます。

短期で終わるもの、一度作れば変えないものは、外注のほうが安く収まります。人を雇わずに済むからです。

一方、何年も使い続け、変更も入り続ける仕組みは、途中で逆転します。外注は変更のたびに費用が発生しますが、内製は固定費の範囲で回せるためです。

ただし内製の費用には、見落とされやすいものが含まれます。

• 採用にかかる費用と時間（エージェント経由なら年収の3割前後、加えて選考にかかる社内の時間）
• 教育の期間（即戦力の方でも、事業と既存システムの理解には数か月かかります）
• 属人化を防ぐための、レビューやドキュメントの手間
• 開発環境、クラウド、各種ツールのライセンス費用
• 採用した人が辞めた場合の、再採用と引き継ぎ

「外注費より人件費のほうが安い」という比較は、たいてい上の5つを数えていません。比べるのであれば、3年程度の総額で並べてください。

比べ方の例

たとえば、年に2回の改修が入る仕組みを考えます。

外注で進める場合、初期開発の費用に加えて、改修のたびに費用が発生します。3年で初期1回と改修6回です。

内製で進める場合、エンジニアの人件費が3年間ずっと発生します。採用と教育の期間を含めると、実際に開発できるのは着任から数か月後です。

年2回の改修であれば、多くの場合は外注のほうが総額で収まります。これが月2回の改修になると、外注では見積もりと調整の往復だけで時間が溶けるため、逆転します。

回数を数えてから比べてください。感覚で「内製のほうが安いはずだ」と決めると、たいてい外れます。

外注側の費用は、人月単価という単位で示されることがあります。エンジニア1人が1か月稼働したときの費用に、人数と期間を掛けて総額を出す考え方です。内製の人件費と比べるときは、この単価に開発以外の時間（見積もり、調整、報告）も含まれている点に注意してください。内製でも同じ時間は発生しますが、人件費の中に埋もれて見えにくくなります。

なお、人件費を見積もる際に公開されている平均年収を使うのは避けたほうが賢明です。ITエンジニアの平均年収として公開されている数字は、調査によって450万円台から730万円台まで開きがあります。使うべきなのは平均ではなく、自社が実際に提示できる金額です。その水準で採用できるかどうかも、同時に確かめられます。

すべてを内製化しようとすると、何が起きるか

内製化そのものは正しい方向です。ただ、一度に全部を取り込もうとした場合に、よく起きることがあります。

進まなくなる。 採用が計画どおりに進まず、既存の運用を回すだけで手一杯になります。

品質が安定しない。 レビューできる人がいないまま作り続け、動いてはいるが誰も直せないものが残ります。

特定の人に依存する。 冒頭に挙げた「作った本人が退職してから誰も触れなくなった」がこれです。内製化したはずが、その人がいなくなった瞬間に外注より不自由な状態になります。

外注していたときより遅くなる。 判断できる人が社内にいないため、確認待ちが増えます。

これらは能力の問題ではなく、進め方の問題です。土台がない状態で全部を取り込もうとすると、こうなります。

裏を返すと、全部を取り込もうとしなければ避けられます。変化の速い領域まで自社で追い続ける前提を置かず、外の力を使い続ける部分を残しておけば、体制の負担はここまで大きくなりません。

順番として先に要るのは、次のようなものです。開発環境とテストの仕組み、コードレビューの習慣、何を作らないかを決める進め方。これらが無いまま人だけ増やしても、増えた分だけ属人化が広がります。

現実的なのは、分けて持つこと（ハイブリッド型）

内製と外注のどちらかを選ぶ必要はありません。領域ごとに分けて持つ形を、ハイブリッド型と呼びます。実際にはこれが最も多い着地であり、変化の速い環境では最も持続する形でもあります。

内製化の本質は、外注していた仕事を丸ごと自社に取り込むことではありません。事業の中核にあり変更頻度が高い部分を自社で持ち、専門性が高く変更の少ない部分は外部に任せる。この線引きです。

具体的には、次のような分け方になります。

この線引きは一度決めて終わりではありません。事業が変われば、中核も変わります。年に一度は見直す前提で置いてください。

判断に迷ったときは、「この仕組みが競合と同じ作りでも困らないか」を問うてみてください。困らないのであれば、外に出してよい領域です。困るのであれば、そこが中核です。

もう一つ、線引きを助ける観点があります。その仕組みについて、事業側の担当者が「こうしたい」と細かく言えるかどうかです。細かく言える領域は、事業の理解が要る領域であり、内製に寄せる価値があります。逆に「うまくやっておいてください」で済む領域は、外に出しても支障がありません。

なお、分けて持つと決めた場合、境界そのものの設計が重要になります。内製する部分と外注する部分が密に絡み合っていると、どちらも動かしにくくなります。データの受け渡しの形を先に決め、互いに影響しない形にしておいてください。ここは最初に手間をかける価値があります。

どちらが向いているかの目安

判断基準を、企業の状態から見た形にも直しておきます。

外注が向いている場合

• 開発できるエンジニアが社内にいない、または採用の見込みが立っていない
• 期限が決まっていて、半年以内に動いていなければならない
• 一度作れば当面変えない仕組みである
• 認証基盤やインフラ構築のように、専門性が高く自社で維持する意味が薄い領域である
• 開発が一時的で、常時抱える案件量がない

内製化が向いている場合

• その仕組みが売上や顧客体験に直接効く、事業の中核である
• 月に何度も仕様が変わる
• 顧客データや機密情報を扱い、社外に出したくない
• エンジニアを複数人採用し、維持できる見込みがある
• 数年にわたって使い続け、変更も入り続ける

両方に当てはまる項目がある場合が普通です。その場合はハイブリッド型を前提に、どこで線を引くかを考えてください。

外注先を選ぶとき、確認すること

外注に寄せる部分について、確認しておくとよい点を挙げます。

• 契約の形。成果物に責任を持つ受託開発なのか、稼働時間に対する契約なのか
• 見積もりの前提。要件整理、UI/UXデザイン、テスト、クラウド費用、仕様変更が発生した場合の扱い、公開後の保守。どこまでが含まれるか
• 変更への応じ方。仕様変更のたびに再見積もりになるのか、一定の範囲で吸収されるのか
• 引き継げる形で作るか。将来内製化する可能性があるなら、その前提を最初に伝えてください。設計が変わります

最後の点は特に重要です。いずれ内製化したいと伝えられている開発と、伝えられていない開発は、作り方が変わります。後から言われても、作り直しが必要になることがあります。

具体的には、引き継ぐ前提であれば次のような違いが出ます。使う技術を、市場で採用しやすいものに寄せる。独自の作り込みを減らし、一般的な構成に合わせる。設計の理由をドキュメントに残す。テストを、他の人が安心して直せる密度まで書く。

これらはいずれも、その場の開発速度だけを見れば遠回りです。引き継ぐ前提が共有されていなければ、開発会社は速いほうを選びます。それが悪いのではなく、前提が伝わっていないだけです。

当社はシステム開発として、要件定義から設計・開発・運用まで一貫して担当しています。開発事例も公開しています。

受託開発で進める場合の、実務上の注意点

外注に寄せると決めた領域について、契約と進め方で押さえておくと後が楽になる点を挙げます。

要件が固まっていない段階で総額を決めない。 決まっていないものを金額に落とすと、開発会社は不確実さの分を上乗せするか、範囲を狭く解釈するかのどちらかになります。どちらも発注側の不利になります。要件整理までを別の契約に分ける進め方があります。

変更の扱いを先に決める。 開発中に仕様が変わるのは異常なことではありません。変更が発生したときに再見積もりになるのか、一定の範囲で吸収されるのかを、契約の時点で書面にしておいてください。

受け入れの基準を先に書く。 「完成」の定義が曖昧なまま進むと、納品の段階で揉めます。何ができていれば受け入れるのかを、機能単位で並べておきます。

運用の担当を決める。 公開後に問い合わせを受けるのは誰か、障害が起きたときに誰が判断するのか。ここを決めずに公開すると、公開直後に止まります。

成果物の権利を確認する。 ソースコードの著作権がどちらに帰属するかは、将来内製化する場合に効いてきます。

これらはいずれも、揉めてから確認すると手遅れになる項目です。見積もりを比べる段階で揃えておくと、金額の差が何から来ているのかも見えてきます。

内製化を進めるとき、外部をどう使うか

「内製化するから外注はやめる」という二択にする必要はありません。移行の期間は、外部を使ったほうが早く進みます。

一緒に作りながら渡す。 外部のエンジニアと自社のエンジニアが同じチームで開発し、進めながら引き継ぐ形です。ドキュメントを渡して終わりにするより、はるかに定着します。

土台だけ先に整える。 開発環境、テストの仕組み、デプロイの手順といった基盤を先に用意しておくと、採用した人がすぐ動けます。

判断の型を渡す。 何を作らないかを決める進め方や、レビューの観点は、仕組みそのものより引き継ぎが難しい部分です。ここを一緒にやることに価値があります。

移行の進め方としては、次の順番が現実的です。

まず、対象を1つ選びます。事業の中核にあり、変更頻度が高いものです。全社の開発を一度に切り替えようとしないでください。

次に、土台を整えます。開発環境、テスト、デプロイの手順。ここが無いと、採用した人が最初の数か月を環境構築に使うことになります。

そして、一緒に作ります。外部と自社のエンジニアが同じチームで、同じコードを触ります。渡す側が書いて、受ける側が読むのではなく、両方が書きます。

最後に、手を引きます。ここを決めずに始めると、いつまでも並走が続きます。何ができるようになったら引くのかを、最初に決めておいてください。

当社はこれをDX推進・内製化支援として提供しています。構想を整理したチームがそのまま実装と運用まで担当し、並行して貴社チームへ引き継ぐ形です。

新規事業のように、そもそも作るべきものが定まっていない段階であれば、PoC・MVP開発から始めるほうが早い場合もあります。

当社の立場

当社は受託開発を行っている会社です。そのうえで、内製化を勧めることも、外注を勧めることもしません。

理由は、どちらか一方に振り切る形が、いまの環境では機能しにくくなっているからです。

技術の選択肢は数年で入れ替わります。クラウドの構成も、開発の進め方も、AIの使い方も、数年前の常識がそのまま通じません。この変化を自社の人員だけで追い続けるのは、事業会社にとって本業ではない負担です。かといって外に任せきると、事業の中核を変えたいときに自分で変えられません。

当社が取っているのは、共創という形です。発注者と受注者に分かれるのではなく、同じチームで事業を進めながら、技術と判断の型を渡していきます。

具体的には、次のような進め方になります。

一緒に作る。 外部のエンジニアと貴社のエンジニアが同じコードを触ります。渡す側が書いて受ける側が読むのではなく、両方が書きます。

事業を止めない。 教育のために開発を止める必要はありません。事業を進める中で、扱う技術と判断の理由を共有していきます。

社内の人が育つ形にする。 何を作らないかを決める進め方、レビューの観点、設計の理由。仕組みそのものより引き継ぎが難しいのはここです。

手を引く条件を決めておく。 何ができるようになったら並走を終えるのかを、最初に決めます。決めずに始めると、いつまでも並走が続きます。

内製化は到達点ではなく方向です。全部を自社に取り込むことがゴールではありません。変化の速い領域では、外の力を使い続けながら、社内で判断できる範囲を広げていく形が現実的です。

自社で作った経験があることも、この進め方を支えています。当社は業務ツール「projectAI」を自分たちで作り、社内で日常的に使っています。2026年7月に公開したとおり、約4.5か月で73画面、31のAI機能を実装しました。社内で持つと何が起きるかを、支援する側の想像ではなく経験として知っています。

最後に、最近の変化についても書いておきます。AIを使った開発で実装の速度は上がりました。実装が速くなった分、何を作るべきかを決める速度が、そのまま事業の速度になります。この判断は社内にしか持てないため、判断できる人を社内に育てる意味は以前より大きくなっています。一方で、AIを前提とした開発の型そのものは、外から持ち込んだほうが早く身につきます。ここでも、分けて持つ形が効いてきます。

よくあるご質問

内製化と外注、どちらが安いですか？

期間によって逆転します。短期で終わるもの、一度作れば変えないものは外注が安く収まります。何年も使い続け変更も入り続ける仕組みは、途中から内製が有利になります。比べる際は、採用費用、教育期間、属人化を防ぐ手間、開発環境の費用まで含めて3年程度の総額で並べてください。

受託開発とSESは何が違いますか？

受託開発は成果物の納品に対して報酬が発生する契約で、開発会社が設計から納品まで責任を持ちます。SESはエンジニアの稼働時間に対して報酬が発生する契約で、人手を補うものです。「外注」と一言で言っても、この2つでは責任の所在が違います。

内製化は何から始めればよいですか？

対象を1つ選ぶことからです。事業の中核にあり、変更頻度が高いものを選んでください。全社の開発を一度に切り替えようとすると、採用も教育も追いつかず止まります。

エンジニアを1人採用すれば内製化できますか？

1人では難しいのが実際のところです。その人が辞めた時点で止まる状態は、内製化とは呼べません。レビューし合える複数人の体制と、採用を続けられる状態が要ります。移行期間は外部と組みながら進めるほうが現実的です。

将来内製化したいのですが、いま外注しても大丈夫ですか？

問題ありません。ただし、その予定を最初にお伝えください。引き継ぐ前提かどうかで設計もドキュメントの粒度も変わります。後から伝えられると、作り直しが必要になることがあります。

内製化を進めたら、外注はゼロにすべきですか？

その必要はありません。専門性が高く変更の少ない領域は外部に任せたほうが、社内のエンジニアを事業の中核に集中させられます。分けて持つのが現実的な形です。

すでに外注している既存システムを、内製に切り替えられますか？

切り替えられます。ただし一度に全部を移すのは避けてください。まず変更頻度の高い部分から移し、安定している部分は当面そのままにするのが現実的です。移行の前に、ソースコードの権利関係と、設計の経緯がどこまで残っているかを確認しておくと、見積もりが立てやすくなります。

開発会社に内製化の相談をしても大丈夫ですか？

構いません。むしろ、いずれ内製化したい意向は最初に伝えていただくほうが、双方にとって良い結果になります。引き継ぐ前提かどうかで技術の選び方も設計も変わるため、後から伝えられると作り直しが必要になることがあります。

内製化にどのくらいの期間がかかりますか？

対象を1つに絞った場合で、採用から数えると半年から1年が一つの目安です。採用に3か月、事業と既存システムの理解に数か月、そこから開発が始まります。この期間を短く見積もった計画は、途中で止まりやすくなります。

AIで開発が速くなったことは、この判断に影響しますか？

影響します。実装の速度が上がった分、何を作るべきかを決める速度がそのまま事業の速度になりました。その判断は社内にしか持てないため、事業の中核を自社で持つ意味は以前より大きくなっています。一方で、AIを前提とした開発の型そのものは、外から持ち込んだほうが早く身につきます。

まとめ

システム開発の内製化と外注は、どちらが正しいという話ではありません。そして、開発まで含めた完全な内製化を自社だけで維持し続けるのは、いまの変化の速さでは現実的ではありません。

現実的なのは、事業の中核にあり変更が多い部分を自社側に寄せ、専門性が高く変化の速い領域は外の力を使い続ける形です。そのうえで、事業を進めながら判断できる範囲を社内に広げていきます。

判断基準は5つです。事業の中核かどうか、変更の頻度、人材を採用し維持できるか、いつまでに必要か、そして3年で見たコストの総額。

内製化は到達点ではなく方向です。線引きが決まらない段階でも構いません。お問い合わせからご相談ください。どこを社内に寄せ、どこを一緒に進めるかの整理からご一緒します。