業務システムの内製化はどこまで社内でやるか｜仕事4つの分け方と、外注・伴走の選び方

なぜ今、内製化が話題になるのか：日本の会社はシステムの大事な部分を外に頼ることが多い

IPA（情報処理推進機構）が2025年6月に公表した「DX動向2025」は、日本・米国・ドイツの企業に、システムをどう用意しているかを尋ねています。自社の強みに直結する領域（調査では「コア事業／競争領域」）で、日本は「外部委託による開発」が4割弱でいちばん多く、米国は「内製による自社開発」が5割弱でした^[1]。同じ調査で、「必要な部分は内製化済みなので、現在は進めていない」と答えた日本の企業は16.7％で、米国・ドイツの半分以下です^[1]。

内製化を進めるうえでの課題を尋ねた設問では、日本は「人材の確保や育成が難しい」という答えが突出していました^[1]。IPAが2025年10月に公開した資料でも、日本企業の85.1％でDXを進める人材が足りないと示されています^[2]。

背景には、IT人材がどこで働いているかの違いもあります。IPAが日米の統計をもとにまとめた比較によると、日本（2020年の国勢調査）では、IT人材のうちIT企業に属する人が73.6％、IT企業以外に属する人が26.4％でした。米国（2021年の職業別雇用統計）はIT企業が35.1％、IT企業以外が64.9％です^[3]。日本では、システムを使う会社の中にシステムが分かる人が少なく、作るのも直すのも外の会社に頼る形が長く続いてきたことがうかがえます。

Overview

内製化とは：外に任せていた仕事を、社内で受け持てるようにすること

内製化とは、これまで外部の会社に任せていた仕事を、自社の人で受け持てるようにすることです。英語ではインソーシングと呼ばれ、反対の言葉は外注（アウトソーシング）です。この記事では、業務システムやITの内製化に話を絞ります。

システムの仕事は、大きく4つに分けられます。どれを社内に持つかで、内製化の中身は変わります。

1. 決める：何を作るか、どの順番で直すかを決める仕事です。業務の困りごとを言葉にし、優先順位をつけます。
2. 作る：画面やデータの仕組みを設計し、プログラムを書く仕事です。
3. 直す・変える：使い始めてからの不具合の修正や、業務の変化に合わせた手直しです。
4. 動かす：サーバーやアカウントの管理、データの控え（バックアップ）、問い合わせへの対応など、毎日止めずに使い続けるための仕事です。

「内製化」というと「作る」を社内でやることだと思われがちですが、実際には「決める」を社内に持つだけでも、外注の進み方は大きく変わります。何を作るかを社内で決められないまま、作る人だけを社内にそろえても、外注していたころと同じ迷い方をします。

よくある誤解を3つ挙げておきます。

誤解1：内製化すれば費用が下がる。外に払うお金は減っても、人を雇う費用や育てる時間がかかります。費用の比べ方は業務システム開発の費用相場と内製・外注の判断基準の記事で詳しく扱っています。

誤解2：内製化は全部を社内でやることだ。決める所だけ、直す所だけを社内に持つ形もあります。どこまで持つかは会社ごとに決めてかまいません。

誤解3：内製化はエンジニアを採用することだ。採用は手段の一つです。業務を知る社員が「決める」役を担えるようにすることのほうが、先に必要になる場面が多くあります。

Pros and Cons

システムを内製化するメリット・デメリット

メリット

• 直したいときにすぐ動ける：外注では、小さな直しでも依頼・見積もり・契約の手順が入ります。社内に分かる人がいれば、その手順を省いて着手できます。
• 業務の知識とシステムの知識が同じ所にたまる：なぜこの画面がこの形なのか、という理由が社内に残ります。担当の会社が変わっても、説明できる人がいなくなりません。
• 外注するときの頼み方がうまくなる：中身が分かる人が社内にいると、見積もりの妥当さを判断しやすくなり、頼む範囲もはっきり書けるようになります。

デメリット

• 人がいないと始まらない：最初の節で見たとおり、日本では内製化の課題として人材の確保・育成がもっとも多く挙がっています^[1]。採用にも育成にも時間がかかります。
• 一人に頼りきりになりやすい：小さな会社では、システムを分かる人が1人だけになりがちです。その人が休んだり辞めたりすると、外注していたころより困ることがあります。
• 守りの仕事まで抱えることになる：セキュリティの更新、障害が起きたときの対応、データの控えなど、作ったあとの地味な仕事もすべて社内の責任になります。

Comparison

内製・外注・一部内製（伴走）の違い

実際の選び方は、全部内製か全部外注かの二択にはなりません。間に「一部内製」があり、その代表が、外部の会社が社内の担当者と一緒に作り、少しずつ社内に引き継いでいく形です。この記事ではこれを「伴走」と呼びます。3つを、社内に何が残るかを軸に比べると次のようになります。

表の「請負」と「準委任」は、民法の言葉です。請負は、仕事を完成させることを約束し、その結果に対して報酬を払う契約です。準委任は、決まった作業や助言をすることを約束する契約です（民法では「法律行為でない事務」を任せる契約とされています）。多くは作業そのもの（かけた時間や工数）に報酬を払う形ですが、2020年4月に施行された民法の改正で、成果に対して報酬を払う形も条文に書かれました^[4]。どちらを選ぶかで責任の範囲が変わるので、詳しくは受託開発と請負の違いを整理した記事をご覧ください。

Fit

内製に向いている業務、外に任せてよい業務

同じ会社の中でも、内製に向く業務と向かない業務があります。判断の目安は次の4つです。

• 変える回数が多いか：取引先ごとの条件や、季節で変わる手順など、直しが頻繁に入る業務は内製に向きます。
• 自社の強みに直結しているか：見積もりの出し方、受注の判断、独自の品質管理など、他社と差がつく部分は、中身を社内で理解しておく価値があります。
• 業務を知らないと作れないか：現場の言葉や例外の多い業務は、外の会社に説明するだけで時間がかかります。
• どこの会社でも同じ形か：会計、給与、勤怠のように、法令や一般的な手順で形が決まっている業務は、既製品に任せる候補です。

IPAの調査でも、日本の企業は自社の強みに直結しない領域（調査では「ノンコア事業／非競争領域」）では、パッケージソフトやSaaS（インターネット経由で使うソフト）を入れる回答が多いと報告されています^[1]。

既製品に合わせるか、一から作るかで迷う業務は、スクラッチ開発とパッケージ・SaaS・ノーコードの違いを比べた記事の「向いている場合、向かない場合」が判断の助けになります。自社の強みになっているやり方を既製品の型に合わせてよいかを、そこで確かめられます。この記事では、既製品に任せない業務について、決める・作る・直す・動かすのどこまでを社内に持つかを考えます。

Process

システム内製化の進め方（5つの段階）

1. いまの仕組みを書き出す：社内で使っているシステム、だれが作ったか、だれが直しているか、契約や資料はどこにあるかを一覧にします。中身が分かる人がいない仕組みが見つかることもあります。
2. 社内に持つ仕事を決める：前の節の4つの目安で業務を分け、仕組みごとに「決める・作る・直す・動かす」のどこまでを社内でやるかを決めます。最初から全部を持とうとしないことが大切です。
3. 担う人を決め、時間を確保する：兼務で始めるなら、週に何時間をシステムの仕事に使うかを決めておきます。本業の合間に回すだけでは、忙しい時期に止まります。
4. 社内に移す順番を決める：止まっても業務がすぐには困らない、社内向けの仕組みから手をつけます。最初は「決める」と「直す」だけを社内で受け持ち、「作る」は外部の会社と一緒に進めると、無理なく始められます。慣れてきたら「作る」や「動かす」を少しずつ社内に移していきます。
5. 引き継ぎの終わりと、手に負えないときの頼り先を決める：どこまでできたら社内だけで回すのかを決めます。あわせて、障害や大きな改修のときに頼れる外部の窓口も残しておきます。

社内にエンジニアがいない会社が、AIを使った開発の道具で内製に挑む場合の注意点は、「社内にエンジニアがいない」中小企業がClaude Codeで内製化に挑む前に知っておくべきことにまとめています。

Pitfalls

内製化で失敗しやすい所

作る人だけ社内に入れて、決める人がいない

エンジニアを1人採用しても、何を作るかを決める人がいなければ、現場の要望をそのまま形にするだけになります。要望同士がぶつかったときに決められる人を、経営側か現場の責任者から立てておく必要があります。要望が人を介するうちに形を変えてしまう問題は、システム開発の「伝言ゲーム」を扱った記事でも取り上げています。

「動かす」仕事の持ち主を決めていない

サーバーやアカウントの管理、データの控えは、だれの仕事か決めないまま始めると、作った人が自然に抱え込みます。「動かす」の担当と、その人が不在のときの代わりを、作る前に決めておきます。

外注先から引き継ぐものを確かめていない

外注で作った仕組みを社内で直したいとき、プログラムの元の文書（ソースコード）や設計の資料、サーバーの管理画面に入る権限が手元にないと、そもそも直せません。だれが権利を持つかは契約の書き方によって変わります。IPAが公開している開発委託のモデル契約でも、納入物の著作権について、開発会社にすべて残す案、汎用的に使えるプログラムは開発会社に残してそれ以外を発注側に移す案、同じく汎用的なものを除いて両社の共有にする案の3つが示されています^[5]。内製化を考え始めたら、まず今の契約書と手元にある資料を確かめておくと安心です。

作ったあとの仕事を見積もっていない

作るまでは張り切って進んでも、使い始めてからの直しや問い合わせへの対応、データの控えといった仕事は続きます。担当者の時間の何割をそこに使うかを先に決めておかないと、新しい仕組みを作る余裕がなくなっていきます。

FAQ

内製化についてよくある質問

Sources

参考にした資料

1. IPA（情報処理推進機構）「DX動向2025」2.4 システム開発等の内製化の状況（2025年6月公開）
2. IPA（情報処理推進機構）ディスカッション・ペーパー「DX動向2025 AI時代のデジタル人材育成」（2025年10月公開）
3. IPA（情報処理推進機構）「情報処理・通信に携わる人材数の日米比較を追加し、『DX白書2023』印刷書籍版PDFを公開」（2023年3月公開）
4. e-Gov法令検索「民法」第632条・第643条・第648条の2・第656条
5. IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」ひな型 第45条（納入物の著作権）A案〜C案（2020年12月公開・2026年9月ページ更新）