システムの内製化と外注どっちがいい？比較表と「社員が作った業務アプリ」の線引き

システムの開発や保守を外注に任せきりにしてきた結果、「社内に仕組みを説明できる人がいない」「見積もりが妥当かも判断できない」と感じている会社は少なくありません。一方で最近は、社員が生成AIを使って業務アプリを自作する例も増え、「内製化はどこまで進めるべきか」という悩みが新しい形で出てきています。

先に結論をお伝えします。「全部内製」か「全部外注」かの二択で考える必要はありません。多くの中小〜中堅企業にとって現実的なのは、まず「何を作るかを決める力」「開発会社と対等に話す力」「自社データを理解する力」といった発注者力を社内に持ち、実際の開発は内容に応じて社内と開発会社で分ける「ハイブリッド型」です。社員が作るアプリも、影響範囲・扱うデータ・利用者数・保守体制の4つで「社内OK／レビュー必須／開発会社へ」の3段階に分けると判断しやすくなります。

この記事では、内製・外注・ハイブリッドの比較表、最初に社内に残すべき役割、社員が作ったアプリの判断マトリクス、人材の育て方、開発会社から知識を引き継ぐ進め方を、発注者の目線で解説します。

内製化と外注で迷う会社が増えている背景

DXを進める人材の不足は多くの企業に共通する課題

内製化の議論が増えている背景には、人材不足があります。IPA（情報処理推進機構）は、国内企業へのアンケートをもとにした分析で、DXを推進する人材が不足していると答えた日本企業の割合を示しています。

📰 出典：IPA「DX動向2025 – AI時代のデジタル人材育成」

この資料では、日本企業の85.1%でDXを推進する人材が不足しており、米国・ドイツと比べて著しく高いとされています。つまり「社内に分かる人がいない」のは、あなたの会社だけの問題ではありません。そして人材が足りない中で「全部を社内で作る」のは、多くの会社にとって現実的ではないことも読み取れます。

「外注に頼りきり」で困るのは、開発より「判断」の場面

外注そのものが悪いわけではありません。開発会社は技術と経験を持っており、自社で一から人を集めるより早く、安定した品質で作れることが多いからです。

困りごとが起きやすいのは、次のような判断の場面です。

• 見積もりや提案が妥当か、社内で評価できない
• 仕様変更や追加費用の話が出たとき、業務への影響を説明できない
• 担当者の異動や開発会社の交代で、システムの中身が誰にも分からなくなる

こうした問題は、開発を内製にしなくても、判断できる人を社内に置くことで多くが軽くなります。ここが「何を内製化するか」を考える出発点です。

内製・外注・ハイブリッドの比較表

3つの進め方を、発注者が気になる観点で比べます。どれが正解ということはなく、会社の規模・システムの重要度・社内の人材によって向き不向きが変わります。

観点	内製（社内で開発・保守）	外注（開発会社に依頼）	ハイブリッド（役割を分ける）
コスト構造	人件費・教育費・ツール費が毎月の固定費になる	案件ごとの開発費＋保守費。必要な時だけ払える	社内の担当者分の固定費＋開発会社への変動費
スピード	小さな改修は早い。人が少ないと大きな開発は遅れやすい	契約・見積もりの手続きが必要。大きな開発は体制を組んで進められる	小さな改善は社内、大きな開発は外部で並行できる
品質	担当者のスキル次第でばらつきやすい	開発会社の体制・実績に左右される。発注者の要件の質にも依存	社内でレビュー基準を持てば、両方の品質をそろえやすい
継続性	担当者の退職・異動で止まるリスク（属人化）	契約が続く限り保守できるが、交代時に引き継ぎが必要	社内に全体を分かる人を残し、中身は文書で共有する
採用・育成	エンジニアの採用・育成が必要で、時間がかかる	開発人材の採用は不要。ただし発注担当者の育成は必要	採用・育成するのは主に「発注者力」を持つ人材
向いている会社	IT自体が事業の中心、継続的に改善し続けるサービスがある	システムが少なく、改修の頻度も低い	多くの中小〜中堅企業。業務システムが複数あり、改善も続けたい

表のとおり、内製は「早く小回りがきく」反面、人がいないと成り立ちません。外注は「人を抱えずに済む」反面、社内の判断力が弱いと任せきりになります。ハイブリッドはその間をとる考え方で、社内に残すのは「判断」、外に出すのは「作業」と整理するのが基本です。

「内製化と聞くとプログラマーを雇う話に思えますが、最初に社内にいてほしいのは、何を作るかを決めて、開発会社と話ができる人なんです」

最初に社内に残したい3つの「発注者力」

内製化を進めるとき、いきなりプログラミングから始める必要はありません。最初に社内で持つべきなのは、次の3つです。

1. 要件を決める力：何を作るか・何をやめるかを決める

「何を作るか」を決めることは、開発会社には代われない発注者の仕事です。業務の目的、必須の機能と後回しにできる機能、成功の基準を、社内で言葉にできる人がいると、見積もりのぶれや仕様の食い違いが減ります。要望の伝え方は作りたいシステムを開発会社にどう伝える？も参考にしてください。

2. ベンダーマネジメント（＝開発会社との関係を管理する力）

開発会社を選び、見積もりや進捗を確認し、成果物を受け入れる役割です。技術の細部まで分かる必要はありませんが、次のことはできるようにしておきたいところです。

• 見積もりの前提（作る範囲・含まれない作業）を確認できる
• 定例会で課題や遅れを具体的に聞ける
• 納品物（設計書・ソースコード・手順書など）がそろっているか確認できる
• 契約の範囲と保守の範囲を把握している

3. データと業務の理解：どのデータがどこにあるか

自社の業務でどんなデータを使い、どのシステムに入っていて、誰が見てよいのか。これを把握しているのは社内の人だけです。AIを使った業務改善でも、データの整理ができているかどうかで結果が大きく変わります。後で紹介する社員アプリの判断でも、この理解が土台になります。

この3つは、外注中心の会社でも、内製を進める会社でも共通して必要です。まず「判断できる人」を1人決め、その人に情報が集まる状態をつくることが、内製化の第一歩になります。

社員が作った業務アプリはどこまでOK？判断マトリクス

生成AIやノーコードツールの普及で、エンジニアではない社員が業務アプリを作れるようになりました。現場の改善が早く進むのは大きな利点ですが、作ったアプリが知らないうちに重要な業務を支えるようになり、作った人しか直せない状態になることもあります。

そこで、次の4つの観点でアプリを3段階に分けて考える方法をおすすめします。

観点	社内で作ってOK	社内で作るならレビュー必須	開発会社への依頼を検討
影響範囲	止まっても手作業で代わりがきく	止まると部署の業務が遅れる	止まると売上・顧客対応・法定の業務が止まる
扱うデータ	公開情報や、個人を特定しない集計データ	社内の業務データ（取引先名・社員情報の一部など）	顧客の個人情報・決済情報・機密情報
利用者数・範囲	作った本人や数人のチーム	部署全体、複数の部署	全社、または取引先・顧客など社外の人
保守体制	作った人がいなくなったら使うのをやめてもよい	作った人以外にも直せる人が1人以上いる	継続的な改修・障害対応・セキュリティ更新が必要

判断のしかたはシンプルで、4つの観点のうち最も右側に当てはまる列を、そのアプリの区分にします。たとえば、利用者は3人でも顧客の個人情報を扱うなら「開発会社への依頼を検討」に入ります。

各区分で決めておくこと

• 社内で作ってOK：作った人・目的・使っているデータを社内の一覧（台帳）に1行書いておく。これだけで後の引き継ぎがかなり楽になります
• レビュー必須：公開前に、情報システム担当や社内の詳しい人がデータの扱い・アクセス権限・バックアップを確認する。社内に確認できる人がいない場合は、開発会社にスポットでレビューを頼む方法もあります
• 開発会社への依頼を検討：社員の試作品を「動く見本」として使い、要件をまとめて開発会社に相談する。試作した社員を要件定義に参加させると、現場の意図が伝わりやすくなります

区分は一度決めたら終わりではありません。最初は数人で使っていたアプリが部署全体に広がることはよくあります。半年に一度など、台帳を見直すタイミングを決めておくと、「気づいたら重要システムになっていた」を防げます。

社内人材の育て方：デジタルスキル標準を地図として使う

「どんなスキルを持つ人を育てればいいのか分からない」ときは、公的な枠組みを地図として使う方法があります。

📰 出典：IPA「デジタルスキル標準（DSS）」

経済産業省とIPAが公表している「デジタルスキル標準（DSS）」は、全てのビジネスパーソン向けの「DXリテラシー標準」と、DXを推進する人材向けの「DX推進スキル標準」の2つで構成されています。

📰 出典：IPA「DX推進スキル標準（DSS-P）概要」

DX推進スキル標準は2026年4月にver.2.0へ更新され、執筆時点（2026年9月）では「ビジネスアーキテクト」「デザイナー」「データサイエンティスト」「データマネジメント」「ソフトウェアエンジニア」「サイバーセキュリティ」の6つの人材類型が示されています。

発注者力の観点では、次のように対応づけると考えやすくなります。

社内に残したい役割	参考になる人材類型	最初の育て方の例
要件を決める・業務を変える	ビジネスアーキテクト	小さな改修案件で、目的・成功基準を書く役を任せる
データの理解・管理	データマネジメント	業務データの所在と閲覧権限の一覧を作る
社員アプリのレビュー	サイバーセキュリティ／ソフトウェアエンジニア	判断マトリクスを使った確認を担当してもらう
全社員の底上げ	DXリテラシー標準	生成AIの社内利用ルールとあわせて基礎知識を学ぶ

全ての類型をそろえる必要はありません。中小企業なら、まずビジネスアーキテクトに近い役割を1人、データの整理を担う人を1人、と小さく始めるのが現実的です。

開発会社から知識を引き継ぐ進め方

ハイブリッド型を目指すなら、今お付き合いのある開発会社の協力は欠かせません。知識の移転は、開発会社にとっても「発注者の判断が早くなる」「要件が明確になる」という利点があり、対立する話ではありません。

ステップ1：内製化の方針と範囲を開発会社に共有する

「将来はすべて社内で」なのか、「小さな改修だけ社内で」なのかで、開発会社の協力のしかたも変わります。どこまでを社内に移したいかを最初に伝えましょう。

ステップ2：納品物とドキュメントの範囲を確認する

設計書、ソースコード、環境構築の手順、運用手順書など、何が納品されるかを確認します。既存の契約で含まれていないものは、追加の作業として相談する必要がある場合もあります。契約上の権利の扱いは、契約書と専門家への確認をおすすめします。

ステップ3：定例会に社内担当者を同席させる

いちばん効果が高いのは、日々のやり取りに社内の担当者が加わることです。仕様の決め方や障害時の対応を横で見ることで、少しずつ判断できる範囲が広がります。

ステップ4：小さな改修を「一緒にやる」

文言の修正や帳票の項目追加など、影響の小さい改修から、社内担当者が作業し開発会社がレビューする形を試します。勉強会や作業の同席は、別途費用がかかるのが一般的なので、見積もりで範囲と費用を確認しておきましょう。

ステップ5：役割分担表を作り、定期的に見直す

「社内がやること」「開発会社がやること」「一緒にやること」を表にし、半年〜1年ごとに見直します。社内の力がついてきたら、少しずつ社内側の範囲を広げていきます。

内製化でやりがちな失敗

• エンジニアを1人採用して全部任せる：その1人に知識が集中し、退職すると元の状態に戻ります。複数人で分かる状態を目指しましょう
• 開発会社との契約を急に打ち切る：引き継ぎが不十分なまま切り替えると、障害時に誰も対応できなくなります。段階的に移すのが安全です
• 社員アプリを禁止するか、放任するかの両極端になる：禁止すると現場の改善が止まり、放任すると把握できないアプリが増えます。判断マトリクスのように「区分」で扱うのがおすすめです
• コスト削減だけを目的にする：内製には人件費・教育費が継続的にかかります。「判断の速さ」「ノウハウの蓄積」など、何を得たいかを先に決めましょう

発注者がやることチェックリスト

• ☐ 内製化の目的（判断力・スピード・ノウハウ蓄積・コストなど）を言葉にした
• ☐ 社内のシステムを一覧にし、それぞれ「内製・外注・ハイブリッド」のどれで運用するか決めた
• ☐ 要件決定・ベンダーマネジメント・データ理解を担う担当者を決めた
• ☐ 社員が作ったアプリの台帳（作った人・目的・データ・利用者）を作った
• ☐ 判断マトリクスで各アプリを「社内OK／レビュー必須／開発会社へ」に分けた
• ☐ 育成する役割をデジタルスキル標準の人材類型と対応づけた
• ☐ 開発会社に内製化の方針を共有し、役割分担表の案を作った
• ☐ 台帳と役割分担を見直す時期（半年〜1年ごと）を決めた

開発会社への質問例

• 「将来的に小さな改修は社内で対応したいと考えています。どのような資料や手順があれば、社内で引き継げそうですか？」
• 「現在の契約で納品されている資料と、追加で作成をお願いする必要がある資料を教えてください」
• 「社内担当者が作業し、御社にレビューしていただく形は可能ですか？その場合の費用の考え方を教えてください」
• 「社員が作った業務アプリのうち、どれを正式なシステムとして作り直すべきか、診断をお願いできますか？」
• 「社内の担当者が最初に身につけるべき知識や、見ておくべき資料はどれですか？」

まとめ：まずは「判断できる人」を社内に置くことから

• 内製化は「全部内製」か「全部外注」の二択ではなく、社内に判断、外に作業を分けるハイブリッドが現実的な選択肢
• 最初に社内に残したいのは、要件を決める力・ベンダーマネジメント・データの理解という「発注者力」
• 社員が作るアプリは、影響範囲・データ・利用者数・保守体制の4観点で「社内OK／レビュー必須／開発会社へ」に分ける
• 人材育成はデジタルスキル標準を地図にして、1〜2つの役割から小さく始める
• 開発会社とは、方針の共有・ドキュメント・同席・小さな共同作業を通じて、段階的に知識を移していく

内製化は一度に進めるものではなく、社内でできることを少しずつ増やしていく取り組みです。まずは社内のシステムと社員アプリの一覧を作り、「誰が判断するか」を決めるところから始めてみてください。

あわせて読みたい関連記事