内製化支援とは ─ システム内製化を外部の力を借りて進めるサービス
「外注に頼りすぎていないか。システムを自社で回せないか」。経営会議でそう問われ、内製化の検討を任された情報システム部門の方は少なくありません。調べ始めると、内製化のメリットを並べた記事や支援サービスの紹介は見つかります。一方で、「どこまでを内製にするのか」「何から始めるのか」「支援会社に何を頼むのか」を決める材料は、なかなか見つかりません。
最初に押さえたいのは、内製化は「すべてを自社で作れるようにすること」ではない、という点です。経済産業省の DX レポート 2 も、他社と差がつかない領域は既製品を使い、事業の強みになる領域を自社で作り変えられるようにする方向を示しています。この記事では、内製化支援とシステム内製化の定義から、公的調査で見る日本の現状、内製か外注かの判断軸、メリット・デメリット、よくある失敗、支援の選び方と期間・費用の考え方、段階的な進め方までを順に扱います。AI 駆動開発で内製化の何が変わるかは、後半の 1 節にまとめました。
FIXIT内製化って、外注を全部やめて自分たちで作るってこと？
Shioriいいえ。整理すると、どこを自社で持ち、どこを外に任せるかを決め直すことです。
FIXITじゃあ、内製化支援は何をしてくれるの？
Shiori一緒に開発しながら、進め方と判断の仕方を社内に移します。最後は支援なしで回る状態を目指します。
そもそもシステムの内製化とは
内製化とは、外部に任せていた業務を自社の人材で行う体制に切り替えることです。製造業の部品や広告運用など、さまざまな分野で使われる言葉ですが、この記事ではシステムの内製化を扱います。
システムの内製化は、外部の開発会社に任せていたシステムの企画・設計・開発・保守・運用の一部またはすべてを、自社の人材で担えるようにすることです。「一部またはすべて」という幅がある点が大切で、実際には、日々の改修だけを社内で行い、大きな刷新は外部に頼む、といった分担もあります。
内製化支援は、この切り替えを外部の会社が手伝うサービスです。支援会社が社内のメンバーと一緒に実際の開発を進めながら、設計・レビュー・運用の判断の仕方を社内に移していきます。成果物を納品して終わりではなく、支援がなくても開発が続く状態をゴールに置く点が、ほかの外部委託との違いです。
受託開発・SES・内製化支援の違い
外部の力を借りる形は、ほかにもあります。終わったあとに何が社内に残るかで比べると、違いがはっきりします。
| 形態 | 主な目的 | 開発を進める人 | 終わったあとに社内に残るもの |
|---|---|---|---|
| 受託開発 | 決めた仕様のシステムを納品する | 受託した会社 | 成果物。開発の進め方は外部に残りやすい |
| SES | 技術者の労働力で開発の人手を補う | 社内の指示を受けた外部人材 | 稼働期間中の戦力。契約が終わると元に戻る |
| 内製化支援 | 自社で開発を回せる体制をつくる | 社内のメンバーと支援会社 | 開発の進め方、判断の基準、手順書と環境 |
受託開発や SES が悪いわけではありません。立ち上げ期や、一時的に開発量が増える時期には、外部の力を借りるほうが速く確実です。受託開発と SES の契約上の違いは、受託開発と SES の違い で詳しく解説しています。
システム内製化が求められる背景 ─ 公的調査で見る日本の現状
内製化が話題になる背景には、日本企業のシステムの作り方が外部委託に寄ってきた経緯があります。公的な調査で現状を確認します。
経済産業省の DX レポート 2 (中間取りまとめ) (2020 年 12 月) は、今後のシステムの持ち方を 2 つに分けています。他社と差がつかない協調領域はパッケージソフトウェアや SaaS に置き換わり、事業の強みになる競争領域は、経営の速さを引き出すためにユーザー企業 (システムを使う側の企業) で内製化されるようになる、という見通しです。あわせて、内製に必要な開発の考え方や技術にユーザー企業の人材だけではすぐに対応できないことが多いため、ベンダー企業が伴走しながらスキルを移す支援のニーズが高まる、とも書いています。これが、いま「内製化支援」と呼ばれているサービスにあたります。
では、実際にどれだけ内製しているのか。IPA の調査から主な数字を拾います。
| 調査 | 主な結果 |
|---|---|
| DX 白書 2023 (2023 年 2 月) | 「コア事業／競争領域」で「内製による自社開発」を選んだ企業は、日本 24.8%、米国 53.1% |
| DX 動向 2024 (2024 年 6 月) | 「内製化を進めている」は従業員 1,001 人以上で 40.4%。内製化を進める企業の課題は「人材の確保や育成が難しい」87.4%、「新しい技術への対応が難しい」39.4%、「開発量の増減への対応が難しい」36.4% |
| DX 動向 2025 (2025 年 6 月) | 日本は「コア事業／競争領域」で「外部委託による開発」が 4 割弱で最も多く、米国は「内製による自社開発」が 5 割弱。「必要な部分は内製化済み」は日本 16.7% で、米国・ドイツの半分以下 |
日本企業は、事業の強みになる領域でも外部委託が多く、内製化を進めている企業は人材の確保と育成で困っている、というのが調査から読み取れる姿です。DX レポート 2 には、国内の IT 人材の 77% が IT 企業に所属し、ユーザー企業に所属するのは 29 万 4,000 人にとどまるという IPA の 2019 年度調査も引かれています。人を採って内製化しようとしても、採れる人の母数が限られているということです。
DX 推進全体の流れの中で内製化をどこに置くかは、DX 推進の進め方を 7 ステップで解説 で扱っています。
内製か外注か ─ 領域ごとに決める判断軸
内製化の検討で最初に決めるのは、「何を内製にするか」です。システム単位、あるいは機能単位で、内製・外注・既製品 (パッケージや SaaS) の 3 つから選びます。判断の軸は次の 5 つです。
| 判断軸 | 内製に向く | 外注に向く | 既製品に向く |
|---|---|---|---|
| 事業での位置づけ | 他社と差がつく競争領域 | 競争領域だが、立ち上げを急ぐもの | 他社と差がつかない協調領域 |
| 変更の頻度 | 月に何度も改修する | 年に数回の大きな改修 | 業務を製品に合わせられる |
| 業務知識の要否 | 社内の業務を深く知らないと直せない | 仕様を文書で渡せば作れる | 業界で標準的な業務 |
| 開発量の波 | 一年を通して一定の改修が続く | 刷新や新規開発など、一時的に大きく増える | ─ |
| 必要な専門性 | 社内で育てられる範囲 | セキュリティ診断や大規模移行など高い専門性 | 製品側で担保される |
たとえば、会計や勤怠のように業界で業務がほぼ決まっている領域は、既製品を使うのが合理的です。一方、受注の仕組みや顧客向けのサービスのように、事業の強みに直結し、改修が頻繁に入る領域は内製に向きます。同じ競争領域でも、最初の構築だけは外部に任せ、運用と改修を内製に移す、という段階的な分担も取れます。
要点
判断に迷ったら、「この部分の改修を外部に頼んで待つことが、事業の足を引っ張っているか」を問うと決めやすくなります。待ち時間が問題になっていない領域まで内製にする必要はありません。
外部委託を続ける領域も、将来の移管に備えておくと選択肢が残ります。ソースコードや設計書の引き渡しを契約に入れておく考え方は、ベンダーロックインを避ける発注設計 にまとめています。
システム内製化のメリット・デメリット
判断軸で対象を絞ったら、その領域を内製にしたときのメリットとデメリットを比べます。
メリット
| メリット | 内容 |
|---|---|
| 改修が速くなる | 見積もり・発注・待ちの工程がなくなり、業務の変化に合わせてその場で直せる |
| 業務とシステムの知識がつながる | 業務を知る人がシステムを直すため、要件の伝え違いによる手戻りが減る |
| ブラックボックス化を防げる | 仕組みを社内で把握できるため、外注先の撤退や担当者の交代で運用が止まりにくくなる |
| 外部と対等に話せる | 外部に任せる部分の見積もりや提案を、自社で評価できるようになる |
デメリット
| デメリット | 内容 |
|---|---|
| 人件費と育成の時間がかかる | 立ち上げ期は学ぶ時間が必要で、短期的には外注より負担が増える |
| 属人化と離職の影響が大きい | 少人数で回すと、担当者が辞めた時点で改修が止まる |
| 開発量の波を吸収しにくい | 刷新など一時的に開発量が増える時期は、社内の人数だけでは足りない |
| 新しい技術への追随が要る | クラウドや開発ツールの変化を、社内で追い続ける必要がある |
このうち育成・開発量の波・新しい技術の 3 つは、IPA の DX 動向 2024 で内製化を進める企業が挙げた課題 (人材の確保・育成、新しい技術への対応、開発量の増減への対応) と重なります。
費用については、「内製化すれば下がる」と言い切れません。外注費は減っても、人件費・育成の時間・開発ツールの費用・支援会社への支払いが増えます。比べるときは、外注を続けた場合の年間費用と、内製にした場合のこれらの総額を、同じ期間で並べてください。改修の待ち時間が減ることによる効果は金額にしにくいため、「依頼から反映までに何日かかっているか」を測っておくと、社内への説明に使えます。
システム内製化でよくある失敗パターン 6 つ
内製化が途中で止まる原因は、技術よりも進め方の設計にあることがほとんどです。よくあるパターンを、兆候と対策の組で挙げます。
| 失敗パターン | 兆候 | 対策 |
|---|---|---|
| 全部を内製にしようとする | 対象が基幹システムまで広がり、計画だけが長引く | 判断軸で対象を 1 つに絞り、既製品と外注に残す領域を先に決める |
| 採用を待って止まる | 「エンジニアが採れたら始める」のまま、着手の時期が決まらない | 今いる社員 1〜2 名と支援会社で、小さな対象を 1 本回しきる |
| 外注先から引き継げない | ソースコードや設計書が手元に無く、どこから読めばよいか分からない | 引き継ぎの範囲と資料を契約で確かめ、並行して運用する期間を設ける |
| 費用削減だけを目的にする | 立ち上げ期に負担が増えた時点で「外注のほうが安い」と結論が出る | 待ち時間の短縮など費用以外の目的も、着手前に社内で共有しておく |
| 研修だけで終わる | 研修の翌週には、元のやり方に戻っている | 研修の前に開発環境を整え、実際の改修依頼を題材にして研修中に 1 件完了させる |
| 支援が終わると元に戻る | 支援会社がいないと、判断も改修も進まない | 支援会社が手を動かす割合を段階的に減らし、手順書とレビューの基準を残す |
いずれも、始める前に決めておけば避けられるものです。とくに「採用を待って止まる」は、IPA の調査で内製化を進める企業の 87.4% が人材の確保と育成を課題に挙げていることとも重なります。人が揃うのを待つより、今いる人で回せる範囲を先に作るほうが、内製化は前に進みます。DX の取り組み全体が止まる原因は、DX 推進が失敗する 7 つの原因 で整理しています。
内製化支援の選び方 ─ 何を支援してもらうか・期間・費用の考え方
内製化支援と一口に言っても、中身は会社によって大きく違います。「何を支援してもらうか」と「支援会社がどこまで手を動かすか」の 2 つで整理すると、比べやすくなります。
支援の型
| 支援の型 | 支援の中心 | 支援会社が手を動かす割合 | 向いている状況 |
|---|---|---|---|
| 研修型 | 開発の手順や AI ツールの使い方を、実務を題材に教える | 小さい。手を動かすのは受講者 | 社内に開発の素地はあるが、手順がそろっていない |
| 伴走開発型 | 社内のメンバーと一緒に実際のシステムを開発・改修する | 最初は大きく、段階的に減らす | 社内に開発経験が少なく、実務で覚える必要がある |
| ツール定着・ルール整備型 | 開発ツールの導入、利用ルール、レビューの基準、品質の仕組みを整える | 中程度。仕組みを作り、運用は社内 | 個人で使い始めたツールを、チームの標準にしたい |
| 開発委託からの移管型 | 外部が作ったシステムを、運用と改修ごと社内に移す | 最初は大きく、移管後はゼロに近づく | 立ち上げは外部に任せ、運用は社内で持ちたい |
型を 1 つに絞る必要はなく、研修と伴走を組み合わせる、移管の途中で研修を入れる、といった組み方もできます。研修の費用や選び方は、AI 研修の費用相場と選び方 で比べています。
期間の考え方
期間は、「対象を 1 本、社内のメンバーが自分で回しきるまで」を単位に見積もると、成果を確かめながら進められます。対象の大きさで幅があり、FIXIT の例では、小さな公式サイト 1 つの保守を移した支援が約 1 ヶ月半、10〜30 名規模のチームに AI 開発ツールを定着させる支援は 3〜6 ヶ月を標準にしています。既存のコードや資料が整理されていない場合は、環境を整えるだけで 1 ヶ月を超えることもあります。最初から全社を対象に長期の契約を結ぶより、最初の 1 本で効果を確かめてから次の範囲を決めるほうが、社内の合意も取りやすくなります。
費用の考え方
内製化支援の費用は、多くの場合、対象の人数・期間・支援の範囲で決まります。比べるときは、支援費だけを見るのではなく、内製化した後の体制まで含めた総額で考えます。
- 外注を続けた場合の年間費用 (保守費と改修費の合計)
- 内製にした場合の年間費用 (担当者の人件費のうち内製に使う割合、開発ツールの費用、残す外注費)
- 内製化支援の費用 (一度きり。研修の場合は助成金の対象になることもある)
1 と 2 の差で、3 を何年で回収できるかを見ます。研修については、要件を満たせば人材開発支援助成金の対象になりえます。
契約前に確かめる 6 項目
- 支援が終わった時点で、社内に何が残るか (手順書、設計書、レビューの基準、開発環境の設定)
- 教材や題材が、自社のシステムや実際の業務か
- 支援会社が手を動かす割合を、段階的に減らす計画があるか
- 支援する人が、日々実際に開発をしている人か
- 費用が、人数・期間・範囲のどれで決まり、追加の条件は何か
- 支援が終わったあと、内製の範囲を超える相談をどこにするか
段階的な進め方 ─ 小さく始めて線引きを見直す 5 段階
内製化は一度に進めず、段階ごとに成果を確かめながら広げます。
| 段階 | やること | 次へ進む条件 |
|---|---|---|
| 1. 棚卸しと目的決め | 外注しているシステムと費用・待ち時間を一覧にし、内製化の目的を決める | 目的と、最初に内製にする対象 1 つが決まっている |
| 2. 環境と資料をそろえる | ソースコード・設計書・開発環境を手元にそろえ、安全に試せる場所を用意する | 担当者が手元で修正を試し、元に戻せる |
| 3. 伴走で 1 本回しきる | 実際の改修依頼を題材に、支援会社と一緒に設計・実装・レビュー・リリースする | 担当者が支援なしで小さな改修を完了できる |
| 4. 手順にして広げる | 判断の仕方を手順書とレビューの基準にし、対象やメンバーを増やす | 新しいメンバーが手順書を見て作業に入れる |
| 5. 支援を減らし線引きを見直す | 支援会社の関与を相談役に縮め、内製と外注の分担を実績から見直す | 内製の範囲と外部に頼む範囲が、社内で説明できる |
段階 2 は見落とされがちですが、ここを飛ばすと段階 3 で担当者の手が止まります。整っていない環境で試すと失敗が続き、担当者が「自分の理解が足りないからだ」と受け取ってしまうからです。
段階 5 の線引きは、着手前に厳密に決めようとしても判断材料が足りません。実際に運用を回してみると、「これは自分たちでやったほうが速い」「これは頼んだほうがいい」が分かってきます。線引きは運用の実績を見て決めるものだと考えておくと、計画の段階で議論が止まりません。
AI 駆動開発で内製化の何が変わるか
Claude Code・Cursor などの AI ツールを開発に組み込む AI 駆動開発は、内製化の前提をいくつか変えています。一方で、変わらない部分もあります。
| 変わること | 変わらないこと |
|---|---|
| コードの下書きやテストの作成を AI に任せられ、少人数で書ける量が増える | 何を作るか、どう直すかを決めるのは業務を知る社員 |
| 既存のコードを読む作業を AI が補助し、引き継ぎの初動が軽くなる | AI が書いたコードをレビューし、リリースの責任を持つのは人 |
| 設計書や手順書の下書きを作る負担が下がる | 機密情報を AI に渡してよい範囲は、社内で決める必要がある |
人材の確保が内製化の最大の課題であることを考えると、少人数で回せる範囲が広がる点は大きな変化です。ただし、AI の出力を評価できる人がいないまま使うと、品質のばらつきが広がり、後で手戻りになります。AI ツールを配るだけでなく、レビューの基準と利用ルールをセットで整えることが前提です。
FIXITAI があれば、エンジニアがいなくても内製化できるの？
Shiori人が書くコードは減ります。ただ、出てきたものの良し悪しを判断する人は要ります。
FIXITじゃあ、何から整えればいいの？
Shiori優先順位で言うと、AI に渡してよい情報の線引きとレビューの基準が先です。
AI 駆動開発そのものの考え方は AI 駆動開発とは、社内で AI 活用を推進するチームの作り方は 社内 AI 活用推進チーム (CoE) の作り方、Claude Code を組織に入れる手順は Claude Code 全社導入 完全ガイド で解説しています。
FIXIT の内製化支援 ─ 事例と提供しているサービス
FIXIT は、AI 駆動開発のクリエイティブスタジオとして、内製化を支援するサービスを提供しています。
公開している事例の 1 つが、学校法人 (職員 100 名規模) の公式サイトの保守を、教職員 2 名が担える状態にした支援です。支援期間は約 1 ヶ月半 (開発環境の整備 2 週間と、ハンズオンでの伴走 1 ヶ月) で、月額 30 万円かかっていた保守の外注費が不要になりました。研修の前に環境を整えたこと、実際の修正依頼を題材にしたことなど、進め方の詳細は 公式サイトの保守を内製化した AI 活用研修の事例 で紹介しています。
支援の内容に応じて、次のサービスを用意しています。
| サービス | 内容 | 費用の目安 |
|---|---|---|
| AI 活用研修 | 事業会社向け。開発チーム・ビジネス職・リーダー向けの 3 プログラムを、自社のコードや資料を教材に実施 | 90 万〜250 万円 (税抜) |
| AI 駆動開発研修 | 受託・自社開発の開発部隊向け。自社のリポジトリで、テストを先に書き AI に実装させ人がレビューする手順をそろえる | 250 万〜680 万円 (税抜) |
| AI 開発ツール定着支援 | Claude Code・Cursor などを組織の標準にする伴走。試用から組織標準化までの 5 段階で、利用ルールと品質の仕組みを整える | 10 名規模 200 万〜400 万円、25 名規模 350 万〜600 万円 (税抜) |
研修は、要件を満たせば人材開発支援助成金の対象になりえます。内製の範囲を超える開発は、引き続きご相談いただけます。
まとめ
システムの内製化は、すべてを自社で作れるようにすることではなく、どこを自社で持ち、どこを外部や既製品に任せるかを決め直すことです。公的な調査でも、日本企業は競争領域でも外部委託が多く、内製化を進める企業の多くが人材の確保と育成に悩んでいます。だからこそ、対象を 1 つに絞り、今いる人で 1 本回しきるところから始め、運用の実績を見ながら線引きを見直す進め方が現実的です。内製化支援を選ぶときは、支援が終わった時点で社内に何が残るかを最初に確かめてください。
どこから内製にするかの整理から始めたい方は、無料相談 をご利用ください。外注しているシステムの状況とゴールを伺い、最初に内製にする対象と、外部に任せ続ける範囲の切り分けからご一緒します。