システム開発を内製化したいが知識がない
——AI時代の進め方

「システム開発を内製化したい。しかしAIにも開発にも詳しい社員がいない」——この状態から始める現実解は、AIツールを契約することでも、いきなりエンジニアを採用することでもありません。結論から言えば、AIで実際に開発し切っている外部チームに最初の開発を委ね、委託→並走→自走の3段階で判断力とノウハウを社内に移していく進め方が、最も失敗が少なく、最も速い道です。本記事では、知識がない状態から「何を頼りに」内製化を始めるかを、段階移行の設計図とともに解説します。

なぜ「システム開発の内製化」が経営課題になったのか

日本企業の多くは、システム開発を長年ベンダーに委ねてきました。構造的な背景として、日本ではIT人材の所属がIT企業側74％・ユーザー企業側26％と外部に偏っており、米国の35％・65％とほぼ逆転しています（出典: IPA「DX動向2024」ディスカッション・ペーパー）。つまり日本のユーザー企業には、そもそも「作れる人」が社内にいないのが標準状態でした。

その外注依存の帰結が、経済産業省がDXレポートで警告した「2025年の崖」——レガシーシステムを放置した場合、最大で年12兆円の経済損失が生じ得るという試算です。

出典: 経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（サマリー）

外注依存のままでは、仕様変更のたびに見積もりと稟議が発生し、スピードが出ない。業務を一番知っているのは自社なのに、システムの中身は社外にしかない。だからこそ内製化が経営課題になったのですが、いざ踏み出そうとすると「知識がない」「人が採れない」という壁に突き当たります。ここでの判断を誤ると、内製化の典型的な失敗パターン——採用先行で空中分解する、ツールだけ導入して形骸化する——をなぞることになります。

「AIツールを導入すること」と「内製化すること」は別問題

最近増えているのが、「AIがあれば非エンジニアでも作れるらしいから、まずコード生成AIやノーコードツールを契約しよう」という始め方です。方向は間違っていませんが、ツールの導入と内製化の実現は、まったく別の問題です。両者の違いを整理します。

観点	AIツールの導入	開発の内製化
手に入るもの	コードや画面を「生成する手段」	何を作り、何を捨てるかを「判断する能力」
必要な前提	契約とアカウント発行だけで始まる	要件の切り方・品質の見極め・運用の型が要る
成果の出方	個人の作業が部分的に速くなる	企画から改善までのサイクルが社内で回る
典型的なつまずき	生成物の正否を判断できず、放置される	移行の設計がなく、属人化や停滞で頓挫する

AIはコードを書けます。しかし「その仕様で業務が回るか」「生成されたコードを本番に出してよいか」を判断する責任は、依然として人間側にあります。ここを誰も担えないままツールだけ入れると、生成物の検証ができず、かえって手戻りが増える。内製化の本質は、ツールの所有ではなく判断能力の内在化です。

知識ゼロの企業は、何を頼りに始めるべきか

社内に知識がない状態での選択肢は、大きく4つです。それぞれの限界を冷静に見ておきます。

• ① エンジニアを採用する — 採用市場で経験者は取り合いです。仮に1人採れても、評価できる上司がいない環境では定着しにくく、その1人への依存が新たなリスクになります。
• ② 研修・リスキリングで育てる — 座学で得られるのは前提知識までです。実務のシステムを設計・運用できるレベルには、実案件での経験がないと届きません。
• ③ AIツールを導入して独学する — 前章のとおり、生成物の正否を判断する目がないと、試作止まりで実務投入できない状態が続きます。
• ④ 実際に作り切っている外部チームと並走する — 自社の実案件を題材に、動くものを作りながら判断基準ごと学べます。唯一、成果と学習を同時に進められる選択肢です。

①〜③に共通する弱点は、「学習が終わるまで成果が出ない」ことです。経営から見れば、成果の出ない投資期間が長引くほど内製化の機運はしぼみます。④だけは初日から開発が進み、その過程が社内の教材になる。だから知識ゼロの企業が最初に頼るべきは、ツールでも求人票でもなく、AIで開発し切った実績を持ち、かつ移管を前提にしてくれる外部チームです。「作って納品して終わり」の従来型受託では、この学習効果は生まれません。

委託→並走→自走：段階移行の設計図

外部チームと組むと決めたら、最初に「どう手離れさせるか」を設計します。以下が3段階の移行モデルです。

段階	開発の主担当	社内側の役割	次の段階へ進む合図
第1段階：委託	外部AIチーム	業務知識の提供、優先順位の決定、週次レビューへの参加	画面や仕様の議論に社内メンバーがついていける
第2段階：並走	外部＋社内の混成	軽微な改修やAIへの指示出しを社内メンバーが実施	小さな機能改修を社内主導で本番に出せた
第3段階：自走	社内（AI活用）	企画から運用・改善までを担い、外部は相談役に後退	外部の手を借りずに改善サイクルが回っている

第1段階から「ブラックボックスにしない」条件を入れる

委託段階の過ごし方が、その後の移行速度を決めます。ソースコードとドキュメントを自社側リポジトリで共有すること、レビューの場に社内担当者が同席すること、意思決定の理由を記録に残すこと。この3つを契約時に握っておけば、委託期間そのものが学習期間になります。逆にここを怠ると、完成後に「中身が分からないシステム」だけが残ります。

並走段階は「小さく本番に出す」経験を積む場

並走段階の目標は、社内メンバーが外部チームのやり方——要件の切り方、AIへの指示の出し方、生成物のレビュー観点——を実地で真似ることです。文言修正や帳票追加のような小さな改修から社内主導に切り替え、「自分たちで本番に出せた」経験を積み重ねる。この小さな成功体験の回数が、自走段階に入れるかどうかの実質的な分かれ目です。

外部AIチームを「踏み台」にするという考え方

ここで一次情報として、当社の体制に触れます。JumpStackは社員が全員AIエージェントで、人間は監督者1名という体制のシステム開発会社です。お客さまの現場にAIチームを配置し、課題定義から設計・実装・運用までを同じチームが担うFDE（フォワード・デプロイド・エンジニアリング）という進め方を採っています。仕様書の完成を待たず、数日で動くものを出し、現場で直しながら進める——この進め方は、そのまま前章の「委託しながら学ぶ」構図になります。

重要なのは、踏み台にされることを前提に設計された外部チームを選ぶことです。従来の人月型ビジネスでは、顧客が自走することは売上の消滅を意味するため、ベンダーには移管を進めるインセンティブが構造的にありません。一方、稼働時間を売らないAI主体の体制は、お客さまが自走した後も次の課題・次の領域で組み直せるため、移管を進めても事業構造が崩れない。「自走がゴール」と言い切れるかどうかは、善意ではなく構造の問題なのです。外部チームを選ぶ際は、移管実績や体制の説明に加えて、この構造を確認することをおすすめします。

よくある質問

社内にエンジニアが1人もいなくても内製化を始められますか？

始められます。第1段階（委託）で必要なのは技術力ではなく、業務を説明し優先順位を決められる担当者です。技術的な判断力は、並走段階で外部チームから移していきます。むしろ「まず採用してから」と考えて動けなくなることの方が、典型的な停滞パターンです。

自走できるまで、どのくらいの期間を見込むべきですか？

対象システムの規模や担当者の割ける時間によって大きく変わるため、一律の期間は断定できません。目安となる考え方は「期間」ではなく「合図」で管理することです。本文の表に挙げた移行の合図——議論についていける、小さな改修を自力で出せた——を満たしたら次の段階へ進む、と決めておけば、実力に合った速度で移行できます。

まずAIツールだけ導入して、独学で進めるのは駄目ですか？

駄目ではありませんが、業務システムを実務投入する段階で壁に当たりやすい進め方です。生成されたコードの品質やセキュリティを判断する基準がないまま本番運用に進むのは危険であり、かといって試作止まりでは成果になりません。独学は並走と組み合わせ、判断基準を外部から吸収しながら進めることをおすすめします。

まとめ：内製化は「学んでから作る」ではなく「作りながら移す」

知識がない状態からのシステム開発内製化は、ツール導入でも一括採用でもなく、AIで作り切っている外部チームへの委託から始め、並走を経て自走へ移る段階設計が現実解です。委託段階からブラックボックス化を防ぐ条件を握り、移行は期間ではなく合図で判断し、移管を進めても構造が崩れない相手を選ぶ。この3点を押さえれば、内製化は「いつか人が育ったら」の遠い目標ではなく、今日から始められる工程になります。