はじめに
日本企業のシステム開発は、長年にわたりSIer（システムインテグレーター）を中心とした多重下請けの外注構造によって支えられてきた。
ユーザー企業が要件を提示し、大手SIerがプロジェクトを受注する。大手SIerは開発工程を子会社や協力会社へ委託し、さらにその先へと仕事が分配される。この構造は、社会全体でIT人材が不足するなか、多数のエンジニアを必要な期間だけ集めて大規模なシステムを構築する手法として、かつては一定の合理性を持っていた。
しかし、生成AIやAIコーディングツールの爆発的な普及によって、その前提が根底から覆り始めている。
これまでシステム開発は、 「開発・運用時に大量の人員を必要とする活動」 だった。だからこそ、企業が自社で固定人員を抱えるより、必要なときに外部へ発注する方が合理的だった。では、AIによって「少人数でもシステムを構築・運用できる時代」が訪れたとき、この合理性は維持されるのだろうか。
本記事では、日本企業がなぜITを外部に依存してきたのかを整理したうえで、AI時代に内製化とSIer市場がどのように変化するのかを論じたい。
日本のIT人材は、なぜIT企業に偏っているのか
日本と米国では、IT人材が所属する企業の構造が大きく異なる。IPA（情報処理推進機構）の調査によると、IT人材のうち「IT企業（SIerやベンダーなど）」に所属する割合は、 米国が35.1％であるのに対し、日本は73.6％ に達する[1: 2020年国勢調査より]。つまり、米国ではIT人材の多くが事業会社にいるのに対し、日本ではITを提供する側に集中している。
この違いを「日本企業はITを軽視してきたから」と一言で片付けるのは不十分だ。日本の外注依存は、以下の4つの構造的要因が積み重なった結果である。
-
業務の「間接部門」としてのITの位置付け
多くの日本企業において、ITは競争力を生む中核機能ではなく、業務を支える間接部門（コストセンター）として扱われてきた。求められたのは「新しい顧客価値の創出」ではなく「既存業務を止めない安定運用」だったため、自社にノウハウを蓄積するインセンティブが働きにくかった。 -
専門職の長期処遇が難しい人事制度
年功序列やゼネラリスト型の配置転換を前提とする日本型の人事制度は、高度なエンジニアを専門職として適切に評価・処遇する仕組みと相性が悪かった。結果として、優秀な人材を社内に定着させることが困難だった。 -
システム開発需要の「波」
大規模な基幹システム刷新などのプロジェクトでは、設計・開発・テストのピーク時に大量の人員が必要となるが、リリース後の保守フェーズではそれほどの人数を必要としない。この需要の波に対し、プロジェクト単位で外部から人員を調達する方が経営的に合理的だった。 -
リスクと責任の外部移転
契約、検収、品質保証、障害対応を含め、開発・運用全体を外部委託することで、ユーザー企業は技術的な複雑性とそれに伴うリスクをSIer側へ移転（アウトソーシング）することができた。
このような経緯から、日本では「業務を知るユーザー企業」と「システムを作るSIer」の分離が進んだ。
しかし、この分離は単なる作業の外部化にとどまらない。「システムを作り、運用し、トラブルを乗り越える過程で生まれる生きた知識（ナレッジ）」までが、企業の外側に蓄積される構造を生み出してしまったのである。
AIによって「外注する合理性」が変わる
この堅固な構造を激変させる可能性を秘めているのが、生成AIを中心とするテクノロジーの進化だ。
現代のAIツールは、単なるコードの自動生成にとどまらない。 システム構造の調査、設計補助、テストコード作成、コードレビュー、ドキュメント生成、さらには本番環境の障害解析やトラブルシューティング（DevOps領域の自動化） にいたるまで、開発・運用のライフサイクル全体へと適用範囲を広げている。
重要なのは「少人数でもシステムを維持できる」という経済合理性の逆転である。
AIによる生産性向上の度合いは条件によって異なるが、「一人のエンジニアがカバーできる領域が圧倒的に広がる」というトレンドは変わらない。
従来、新規システムを立ち上げるには数十人規模の開発・運用体制が必要だったが、AIを相棒にすれば、最小限のコアイノベーターだけで一定規模のシステムを継続的に開発・改善できるようになる。大規模なピークに合わせて外部人員をかき集める必要性が薄れ、 「少数の高度人材を社内に抱え、プロダクトを高速に進化させる」 形が極めて現実的な選択肢となった。
AIは単に開発コストを下げるだけのツールではない。これまで外部調達を正当化していた「大量の人員が必要」という前提そのものを崩し、内製と外注の境界線を引き直す技術なのだ。
内製化の本質は、「開発者を雇うこと」ではない
ここで、「内製化」という言葉の定義を正しく整理しておきたい。多くの企業が「自社でエンジニアを採用し、自社社員がコードを書くこと」を内製化だと誤解しがちだ。しかし、単に社員がコードを書いているだけでは、真の内製化とは言えない。
以下のような状態に陥っている場合、コードを書いている人間が自社社員であっても、組織としてITをコントロールできているとは言いにくい。
- 特定のエンジニアしかシステムの構造（アーキテクチャ）を理解していない
- なぜその設計にしたのか、意思決定の経緯（ADRなど）が記録されていない
- 本番障害やトラブルから得られた教訓が、担当者の頭の中にしかない
- 開発や運用の品質基準が、組織のプロセスとして定義されていない
逆に、実装の一部を外部企業に委託していても、自社がプロダクトの方針を決め、アーキテクチャを統治し、運用から得た知識を自社組織に還流できているなら、それは十分に「内製化された状態」と言える。
内製化の本質は、雇用契約の違いではなく、以下の能力を自社の「組織能力（ケイパビリティ）」として蓄積・コントロールできているかにある。
- 顧客や業務（ドメイン）に対する深い理解
- システム設計の意図と意思決定の経緯の把握
- 障害や失敗から学び、システムを回復・改善させる知見
- 継続的な改善を回すためのプロセスと品質基準
- 外部の技術やサービスを正しく評価し、使いこなす能力
つまり、内製化とは「コードの生産手段」を自社に持つことではなく、「事業とITに関する意思決定能力と学習能力」を自社に囲い込むことなのである。目指すべきは「完全な自社開発」ではなく、自社が主導権（オーナーシップ）を握ったうえで、外部の専門性をレバレッジすることだ。
AX（AIトランスフォーメーション）では、本業とITを切り離せない
内製化が不可避となるもう一つの決定的な理由は、企業におけるITの位置付けの変化にある。
従来のIT化（デジタイゼーション）は、経理や人事、販売管理など、すでに確立された業務プロセスをシステムへ置き換えることが中心だった。この場合、「業務部門が要件を定義し、SIerが実装する」という分業が機能しやすかった。
しかし、AIを事業のコアに組み込む AX（AI Transformation） においては、ITと本業を分離することは不可能である。
- どの判断をAI（エージェント）に委ねるのか
- どこに人間のチェック（Human-in-the-Loop）を残すのか
- AIの出力結果を、どの業務プロセスや顧客体験に接続するのか
これらは単なる「システムの機能要件」ではなく、業務設計、組織デザイン、権限委譲、ひいては事業戦略そのものだからだ。外部のSIerは技術に詳しくても、顧客企業の現場にある暗黙知や、組織内の力学、例外処理の泥臭い運用までを理解することはできない。一方で、事業会社の社員はドメイン知識（業務知識）を持っていても、最新のAI技術で何ができるかを知らない。
したがって、AXにおいて必要なのは、従来型のウォーターフォール的な分業ではない。ドメイン知識と技術知識を同一チーム内で行き来させ、業務とシステムを同時に実験・変革していくアジャイルな体制だ。このサイクルを高速で回すためには、中核となるプロダクト責任者や主要なエンジニアを自社側に配置せざるを得ない。
外注の本質的な問題は「学習ループの分断」である
外部の専門性を活用すること自体は、決して悪ではない。外注の真の問題は、開発作業を外に出すことではなく、「事業を改善するための学習ループ（フィードバックループ）」が企業や組織の境界によって細切れに分断されてしまうことにある。
一般的な外注構造では、情報が以下のように別々の場所に孤立（サイロ化）する。
【顧客の要望】 ──> 事業部門
【要件の整理】 ──> 情報システム部門
【基本設計】 ──> 大手SIer
【実装・テスト】──> 協力会社・下請けベンダー
【運用・保守】 ──> 外部の保守運用会社（障害・問い合わせ対応）
それぞれのステークホルダーは、自分の担当範囲の情報しか持っていない。その結果、以下のような致命的な機会損失が発生する。
- 現場の障害や顧客のリアルな反応が、次の設計に反映されるまでに膨大な時間がかかる
- 現場で得られた泥臭い運用ノウハウが、契約（会社）の境界線を越えられない
- 担当者が変わるたびに、システムの「背景」を一から説明し直すコストが生じる
これは単なるコミュニケーションの非効率ではない。 「企業が市場や顧客から学習する速度（Learning Velocity）を著しく低下させる構造」 なのだ。
AIによってコードの実装速度が極限まで高まるほど、この組織間のオーバーヘッドは浮き彫りになる。 AIを使えば1日で終わる修正に対し、要件の文書化、見積もり、契約変更、承認、検収に3週間かけているようでは、開発工程をいくら高速化してもビジネス価値の提供スピードは変わらない。
内製化によって得られる最大の果実は、外注費の削減ではない。「顧客・業務・開発・運用・トラブル対応」を一つの緊密なフィードバックループとしてつなぎ、企業の学習速度を最大化することにある。
コミュニケーションと契約の「取引コスト」を削減する
外部委託には、目に見えない多大な 「取引コスト（トランザクションコスト）」 が発生している。
- 要件を他人に伝えるための文書化コスト
- 見積もり取得、価格交渉、契約締結の手続きコスト
- 複数企業間の進捗調整、変更管理、責任分界の明確化コスト
- 納品物の検収・品質チェックのコスト
社内であれば「ちょっとここ試してみよう」と、その日のうちにモックアップを作って検証できるような変更であっても、外部委託では毎回この取引コストの壁が立ちはだかる。仕様が明確で変更が少ないシステムならこれでも機能するが、仮説検証を繰り返しながら高速に市場へ適応するモダンなプロダクト開発において、この遅延は致命傷となる。
AI時代の内製化は、アイデアから実装、評価、そして改善（あるいは障害からの復旧）までの距離を最短にし、企業間取引のオーバーヘッドに殺されるのを防ぐための生存戦略なのだ。
「プロジェクト思考」から「プロダクト思考」へ
この変化は、ITに対するマインドセットの転換（プロジェクト思考からプロダクト思考へのシフト）を意味している。
| 比較軸 | プロジェクト思考（従来の外注型） | プロダクト思考（これからの内製型） |
|---|---|---|
| ゴール | 明確な開始と終了（納期・予算・要件の遵守） | 原則として終わりはない（継続的な成長・適応） |
| 成果の定義 | 定められたシステムを「納品」すること | システムが生み出す「顧客価値・事業成果」 |
| アプローチ | 最初に仕様をガチガチに固める | 仮説検証（実験と学習）を高速に繰り返す |
何を作れば成果が出るのか分からない不確実な時代において、最初に完成形を定義することを前提とした「請負契約」は本質的に馴染まない。だからこそ、プロダクト思考を採用する企業ほど、学習と意思決定の中心を自社へ戻そうとするのである。
ITのブラックボックス化は最大のリスク
ITに対するマインドセットを「プロダクト思考」へ切り替えられない企業にとって、外部委託への依存は致命的な牙をむく。
重要なIT資産の構造、設計思想、運用のノウハウ（なぜこの構成になっており、トラブル時にどう調査・復旧すべきか）を外部企業に丸投げし、自社にブラックボックスしか残らない状態は、現代において重大な経営リスクである。
委託先の撤退、キーマンの交代によるシステムの形骸化、保守料金の高騰、技術スタックの陳腐化。契約書上に「成果物の所有権は自社に帰属する」と書かれていても、 自社にそれをハンドリングする知識やトラブルを解析する能力がなければ、それは資産ではなく「負債」 だ。
ITと事業が不可分になった今、ITの主導権を失うことは、経営の舵取りそのものを社外に委ねることに等しい。
すべてを内製する必要はない：システムポートフォリオ戦略
外部に主導権を握られるブラックボックス化は防がねばならないが、だからといってすべてのシステムを自社でゼロから開発・運用するのは不合理であり、リソースの分散を招く。重要なのは、システムを企業の競争力との関係性から分類し、適切なポートフォリオを組むことだ。
システムの3分類と戦略
| 領域 | 定義・具体例 | 内製・外注のスタンス |
|---|---|---|
| コア領域 |
競争優位や独自の顧客価値に直結する領域 （例：独自の価格決定アルゴリズム、コアな顧客体験、AIによる意思決定モデル、物流の最適化など） |
完全なオーナーシップを保持。 意思決定、アーキテクチャ、コア実装は自社で行う。一部外部の専門家を入れる場合も主導権は渡さない。 |
| 支援領域 |
事業運営に不可欠だが、直接の差別化要素ではない領域 （例：社内ワークフロー、データ分析基盤、業務支援ツール、管理画面など） |
ハイブリッド型（協働）。 自社でプロダクトオーナーシップを持ちつつ、設計・実装の大部分に外部の専門性やパートナーを柔軟に活用する。 |
| 汎用領域 |
業界共通であり、自社で独自に作る意味が薄い領域 （例：会計、給与計算、メール・グループウェア、一般的なCRMなど） |
外部サービスの徹底活用。 SaaSや標準パッケージをそのまま利用し、自社の貴重な開発リソースをここには割かない。 |
問うべきは「内製か外注か」というゼロヒャクの議論ではない。「この領域は、自社の競争力や市場からの学習にどれほど影響するか」 という問いに基づき、賢明なポートフォリオを設計することこそが、AI時代の正しいIT戦略となる。
企業規模による内製化の二極化
もっとも、このポートフォリオ戦略をすべての日本企業が一斉に、同じように実行できるわけではない。そこには企業規模による現実的な格差（二極化）が存在する。
-
大企業：内製化の推進と自社プラットフォーム化
潤沢なリソースと継続的なIT需要があるため、エンジニアを一定規模で抱え、社内の多様なテーマ（開発・データ活用・AI導入・DevOps自動化）へ柔軟に配置できる。社内に強固なキャリアラダーを設けることも可能だ。 -
中小企業：標準化されたサービスのコンポーザブル（組み合わせ）利用
一社あたりのIT需要や投資規模が限られているため、高度なエンジニアを常時雇用し続けることは難しい。そのため、すべてを内製するのではなく、SaaS、業種特化型プラットフォーム、地域の信頼できるITベンダーや外部の専門家をスポットで組み合わせる需要が強固に残る。
今後は、一律の内製化ではなく、大企業は「コア機能の内製化」を研ぎ澄まし、中小企業は「標準化された外部サービスの徹底活用」にシフトするという、戦略的重要性に応じた使い分けが進むだろう。
大企業の投資に依存するSIerモデルはどうなるのか
このように大企業が「コア領域」の内製化へと本格的にシフトし、中小企業がSaaSの活用を進める世界において、これまで大規模なIT投資を主要な収益源としてきたSIerモデルは強烈な打撃を受けることになる。
AIによってエンジニア一人の生産性が向上すれば、顧客は「半分の人数・半分の期間」で同じ成果を得られるようになる。しかし、 売上を「投入人数×期間」で計算する「人月契約（タイム＆マテリアル）」のビジネスモデルに依存しているSIerにとっては、生産性を上げれば上げるほど自社の売上が減るという構造的矛盾（ジレンマ） に直面する。
今後淘汰されるのは、 「顧客との情報格差」にあぐらをかき、要件の右から左への伝達、Excelによる進捗管理、ドキュメントの再生産だけで人月を稼いできたSIerの上流工程 だ。ドメイン知識は顧客が持ち、一般的な技術情報の整理や資料作成はAIが代替する。その間を取り次ぐだけの存在に、高い単価を払う理由はどこにもない。
FDE（Forward Deployed Engineer）はSIerの救世主か
人月ビジネスからの脱却を目指すなかで注目されているのが、FDE（Forward Deployed Engineer：前方展開型エンジニア） という役割だ。
FDEは、従来の「営業」「PM」「開発者」の垣根を越え、顧客の現場（フロントライン）に深く潜り込み、業務課題をその場で発見し、自らAIやクラウドを駆使して超高速でプロトタイプを設計・実装する。
これは、SIerが「受託ベンダー」から「顧客密着型の技術パートナー」へ変貌するための優れたモデルになり得る。しかし、FDEも万能の特効薬ではない。単に顧客ごとに個別の泥臭いカスタマイズ開発を続けるだけなら、それは名前を変えただけの「高稼働な派遣・受託」にすぎない。
FDEモデルを成功させる鍵は、顧客の現場で得た汎用的な知見や課題パターンを、SIer自社の「再利用可能なアセット（共通基盤、共通AIエージェント、業界テンプレート）」へと還元・製品化できるかにある。現場の知見を資産（プロダクト）に変換できて初めて、SIerは労働集約型の人月ビジネスを超えるスケールを手にする。
これからのSIerが生き残るための4つの戦略
今後のSIerが取るべき戦略的舵取りは、大きく次の4つの方向性に集約される。
-
「内製化の阻止」から「内製化の伴走支援」への転換
顧客を自社に依存させる囲い込み戦略はもはや通用しない。むしろ、顧客のシステムアーキテクチャの標準化、DevOps環境の構築、セキュリティガバナンス、AI活用スキルの育成などを支援し、「顧客が自走できる強固な土台」を一緒に作るパートナーとしての地位を築く。 -
労働（人）ではなく、資産（アセット）の販売
AI時代の単純な実装作業はコモディティ化する。SIerは、特定の業界特化型データモデル、コンプライアンス要件を満たしたセキュリティ基盤、高度にチューニングされたAIエージェントなど、「一朝一夕では作れない再利用可能なソフトウェア資産」を保有し、それをベースに価値を提供する。 -
コモディティ化しない「超・高度専門性」の提供
すべての高度技術を事業会社が自社で抱え切ることはできない。次世代クラウドインフラの最適化、最先端のサイバーセキュリティ対応、大規模なシステム移行（マイグレーション）アーキテクチャ、AIガバナンスの策定など、変化が激しく極めて専門性の高い領域を「結果・成果コミット型」で提供する。 -
中小企業向けの「マネージド・シェアードサービス」
内製化の体力を持ち得ない中小企業群に対し、個別開発ではなく、業種特化型SaaSや共通業務プラットフォーム、AIを活用した運用代行などを低コスト・高品質なパッケージとして提供する。
求められる「SIer ⇄ 事業会社」の人材循環
企業だけでなく、そこで働く「個人」のキャリア観においても、同様の構造変化が起きている。これまでは「SIerでスキルを磨き、事業会社の内製化要員として転職する」という一方通行のキャリアが主流だった。しかしこれからは、両者の間をポジティブに行き来する 「人材の往復（循環）」 が活発化する。
SIerと事業会社では、それぞれ得られる経験の質が本質的に異なるからだ。
- SIerで得られる経験： 多様な業界のシステムに触れる機会、大規模プロジェクトのマネジメント、最先端のインフラ・セキュリティ技術の横断的なナレッジ。
- 事業会社で得られる経験： 特定のドメイン（事業・顧客）への深いコミット、システムが事業数値に与える因果関係のトラッキング、リリース後の継続的な改善やトラブルシューティングを通じたプロダクトのサステナビリティ（持続可能性）の理解。
これからの時代に最も市場価値が高まるのは、 「技術」と「ドメイン」の両方の言語を話し、異なる組織の境界を越える「越境人材」 だ。SIerで広範な技術を学んだ者が事業会社でドメイン知識を深め、そこで得た変革のノウハウを携えて再びFDEやコンサルタントとしてSIer（またはスタートアップ）に戻り、複数の企業を支援する。こうした循環が、日本のIT産業全体の底上げにつながる。
この循環を加速させるためには、企業側の人事・評価制度のアップデートが不可欠である。事業会社は彼らを単なる「社内プログラマー」ではなく「事業変革のアーキテクト」として処遇すべきであり、SIer側も事業会社帰りの人材のドメイン知識をプロダクト開発に活かせるキャリアパスを用意せねばならない。
まとめ：AI時代に本当に問われていること
今後の議論において、「すべてを内製するか、すべてを外注するか」という二者択一は本質ではない。
本当に問われているのは、 「自社の競争力の源泉となる知識と、迅速な意思決定能力を、誰が持っているのか」 という一点である。
AIによって変わるのは、コードを書くスピードだけではない。IT人材をどこに配置し、誰が主導権を握り、現場のトラブルや顧客の声から得た学びを「どこに蓄積するか」という、産業全体の分業構造そのものの再定義なのだ。
この変化の激流のなかで、自社が保持すべき「コア領域」を明確に定め、その能力を個人の経験で終わらせずに「組織の資産」として蓄積するプロセスを確立できた企業だけが、内製・外注の形態を問わず、ITを真の武器にできるのである。