システム開発の内製化は「採用」から始めると失敗する｜AI時代の内製と外注

「え！ここを直すだけで、こんなにかかるの!?」

取引先から届いたシステム改修の見積もりを見て、思わずそんな叫びを上げたことはないでしょうか。ちょっとした画面の追加なのに、数十万円と数週間。経営者であれば、「この調子でシステム開発の外注費を払い続けるなら、いっそ社内に人を置いたほうが安いのでは」と考えるのは自然な流れです。

しかも今はAIの時代です。コードを書けるツールも、プログラミングなしで業務アプリを組めるサービスも増えました。「作る」ことのハードルは、確かに下がっています。

ところが、内製化でつまずく会社の多くは、いきなり求人を出すところから動き始めます。そして「何をする人なのか」が曖昧なまま1人目のエンジニアを採り、その人しか触れないシステムが積み上がっていく。これでは、社内でシステムは作れても、ノウハウは蓄積していきません。AIが下げてくれたのは「作る」ハードルだけで、「決める」「直し続ける」「引き継ぐ」ハードルは、ほとんど下がっていないからです。

さらに、大企業であれば、すべての開発を内製化するために必要なだけの人材を抱えることができるかもしれませんが、多くの中小企業では完全内製化は現実的な選択肢ではありません。そこで、一部は少人数の社内スタッフによる内製化、一部は外注を絡めるというハイブリッド型開発を進めるほうが賢い選択でしょう。

この記事では、システム開発の内製化を「採用」から始める前に決めておきたい内製と外注の線引きを整理します。さらに、1人目の技術者を採ったあとに起きがちなこと、AIを前提にした無理のない進め方を解説します。読み終える頃には、「外注はきついが、人もいない」という手詰まりから、あなたの会社なりの次の一手が見えてくるはずです。

AIで変わったこと、変わっていないこと

内製化の話を始める前に、AIがシステム開発の何を変えて、何を変えていないのかを整理しておきましょう。この認識がずれていると、「AIがあれば内製は簡単」という期待だけが先走ります。分けて考えたいのは次の3つです。

「作る」ハードルは下がった

コードを自動生成するAIや、プログラミング不要で業務アプリを組めるノーコード・ローコードのツールが広がり、これまでは専門の開発者しか手を出せなかった領域に、プログラミングなど特別なスキルがない社内の担当者でも踏み込めるようになりました。

この規模なら、外注に出すより社内でシステムを構築する方が速い場合もあります。

日立ソリューションズも、環境変化の速い今はシステムの迅速な改修が求められ、外部委託では要件定義から見積もり、契約調整までに時間がかかると指摘しています。「小さく速く直せる」ことは、内製の分かりやすい利点でしょう。

出典・参照

• 日立ソリューションズ「システムの内製化を成功させるには」

「決める」「直し続ける」ハードルは残った

一方で、AIは「何を作るべきか」を決めてはくれません。

これらは依然として、業務と技術の両方が分かる人間の判断が必要な領域です。

作った後も同じです。仕様変更のたびに影響範囲を見極め、動かなくなった箇所を直し、担当者が代わっても動かせるように記録を整える。AIはこの作業を助けてはくれますが、肩代わりはしてくれません。システムの内製化は、最初に作るところだけでなく、むしろ作った後に直し続け、円滑な運用をし続けることにこそ高いハードルがあるのです。

AIを扱う人材と、一般的な開発者は別のスキル

もう1つ見落としがちなのが、必要な人材の専門性の違いです。社内に開発経験者がいても、その人が機械学習を使ったAIの設計や精度の評価までできるとは限りません。機械学習を用いるAIの設計・精度評価と、業務アプリの開発とでは、求められるスキルセットが異なります。

「AI人材を採ればAIもシステムも内製できる」と安易に判断するべきではないでしょう。あなたの会社が内製したいのは業務アプリなのか、データ分析の基盤なのか、AIモデルそのものなのか。その整理が重要となります。

「採用すべきか」の前に決める、内製と外注の線引き

システム内製化のために必要なことは「人材の採用」だと考えると、話が「採用できるか・できないか」だけで終わってしまいます。先に決めるべきは、あなたの会社のシステムの内どこを内製し、どこを外注や外部との伴走に任せ、どこをAIとノーコードで賄うか、という線引きです。この線引きは、次の3つの軸を参考にしてください。

変更の頻度で分ける

よく変わるものほど内製に向きます。業務のやり方に合わせて毎月のように画面や項目を直したい社内ツールは、その度に外注していては時間もお金も持ちません。逆に、一度作れば数年は大きく変える可能性が少ない仕組みは、まとめて外注したほうが総額を抑えやすいでしょう。

対外性と基幹度で分ける

社外のお客様が触れるもの、売上や在庫の根幹を握るもの、個人情報や決済が絡むもの。これらは止まったときの損害が大きく、セキュリティや品質の責任も重くなります。そのため、社内の1人の担当者に背負わせる領域ではありません。ここは外注、あるいは専門家の伴走を前提に考えることをおすすめします。

一方、社内だけで使い、止まっても紙や表計算で数日はしのげる範囲であれば、内製で試す価値があります。

撤退できるかで分ける

内製したものを、あとで「やっぱり外注に戻そう」と決められるか。これも線引きの軸のひとつです。仕様が記録に残っていて、標準的なツールで作られていれば、担当者が辞めても後任、あるいは外部へと引き継ぐことができます。逆に、特定の個人しか分からない作り方で組まれていると、内製をやめたくてもやめられません。

改めて線引きの目安をまとめます。

領域の例	内製	外注・伴走	AI＋ノーコード
申請・報告など社内の小さな業務アプリ	○	△	◎
部門を跨ぐ業務フローの仕組み	△	○	△
顧客が使うWEBサービス・アプリ	×	◎	×
売上・在庫・会計などの基幹システム	×	◎	×
データ分析・AIモデルの構築	△	○	△

この線引きが先にあれば、「採用すべきか」は「内製すると決めた範囲を、誰にどう担わせるか」というもっと具体的な問いに変わるでしょう。

ジョブ型で「1人目のエンジニア」を採るときの現実

線引きをしたうえで「この範囲は内製する」と決めたなら、次は人材の話です。1人目の技術者を採用するときには、大企業の情シスとは違う難しさがあります。知っておきたい現実を3つ挙げます。

キャリアパスと孤立の現実

中小企業が1人目のエンジニアを採るときは、「情シスを担当してもらう」というように職務を決めて採用します。職務を特定して人を採る、いわゆるジョブ型の雇用で、日本の中小企業では以前から一般的な採用方法でした。ただ、採られた技術者の側から見ると、話は違ってきます。

社内に評価できる先輩も、相談できる同僚もいない「1人情シス」の状態では、自分の仕事が正しいのか判断してもらえず、成長の道筋も見えません。情シス向けの情報サイト「情シス365」を運営する株式会社BTNコンサルティングは、こうしたキャリアの見えにくさや孤立感が、IT人材が中小企業を敬遠する理由になっていると指摘しています。

給与水準のギャップと採用競争の現実

情シス365によると、IT専門職と中小企業の情シス職とでは想定年収に百万〜二百万円ほどの開きがあります。そのため、条件だけで比較すると中小企業の求人は見劣りしてしまい、応募自体が集まらないことも少なくありません。つまり、「採用すればいい」と方針を決めても、採れるとは限らないのが実情です。

属人化の現実

無事に1人採用できたとしても、その人が社内の唯一の作り手である限り、書いたコードも組んだ仕組みも、その人だけが分かる状態で増えていきます。しかし、仮にその人が辞めてしまえば、ドキュメントもテストもなくブラックボックス化してしまい、誰も管理できないという属人化の落とし穴は避けられません。つまり、うまくいった1人目の採用も、属人化という次の課題とセットなのです。

出典・参照

• 日本人材ニュースONLINE「中小企業は今も昔もジョブ型雇用！ 大企業で取り組むジョブ型雇用導入の課題とは」
• 株式会社BTNコンサルティング（情シス365）「中小企業のIT人材採用が難しい本当の理由 ― 採用できない場合の3つの選択肢」

内製の本当のコストは「持ち続けること」にある

内製化を考えるとき、多くの場合はエンジニアの年収と外注費を天秤にかけます。ところが、内製化に必要な費用は年収だけではありません。作ったシステムを持ち続けるあいだ、じわじわと積み上がるコストがあります。本章では、給与だけを見ていると見落とすものを、4つに分けて整理します。

保守・改修の継続コスト

システムは作って終わりにはなりません。まず、エンジニアの人件費以外にも、システムを動かし続けるだけでかかる費用があります。

これらは使う人数と関係なく毎月出ていきます。さらに、業務の変化に合わせた改修や、法改正への対応、使っているソフトウェアの更新への追従。こうした作業でエンジニアの時間も絶えず取られていきます。外注なら保守契約の範囲で収まる部分を、内製では自社でまとめて抱える形になります。

ドキュメントと引き継ぎ

担当者が異動や退職でいなくなっても動かせるか。この備えにもコストがかかります。

これらを文書として残し、更新し続けるには労力が必要です。しかし、ここを省くと、目先は速く進みますが、数年後に「誰も触れないシステム」という負債が残りかねません。

テストと品質の担保

1人で作っていると、プログラムを書いた本人が気づけない不具合はそのまま残ります。第三者のレビューや、変更のたびに動作を確認する仕組みがなければ、小さな修正が別の不具合を生み出す事故につながりかねません。品質を保つ活動も、内製では会社の仕事です。

撤退ラインを先に決める

これはコストというより判断の準備です。「担当者が辞めて3ヶ月以内に後任を採れなければ外注へ移す」「この機能の改修が四半期で回らなくなったら作り直す」というように、内製をやめる条件をあらかじめ決めておきます。撤退ラインがあると、うまくいかない開発体制を抱え込まずにすみます。

AI時代の内製化の進め方4ステップ

ここまでの前提を踏まえると、現実的な内製化の進め方の順番が見えてきます。いきなり求人を出すのではなく、次の4ステップで足場を固めていきましょう。

ステップ1：先に業務プロセスを標準化する

属人化した業務を、そのままAIやツールに載せてはいけません。部門ごとにやり方がばらばらのまま自動化しても、例外処理だらけの使いにくい仕組みになります。まず業務の手順を整理し、共通化できるところを共通化する。この情報整理が、内製の成否を決めます。

ステップ2：小さく内製して、記録をセットにする

最初から大きな仕組みを狙わず、影響範囲の狭い業務アプリから始めましょう。このとき、動くものを作ることと同じ重さで、設計メモと運用手順を残すことをルールにします。

「何のために、どんな仕組みで作ったか」と「困ったときの直し方・使い方」を書き残せていないものは、社内の業務では使い始めない。この一線があるだけで、担当者が代わっても直せないシステムは溜まりにくくなります。

ステップ3：外部の伴走を「教える役」として使う

内製か外注かは、ゼロか100かではありません。外部の開発会社に、作ってもらうのではなく「社内の担当者が伴走してもらう」形でプロジェクトに入ってもらう選択肢も考えられます。

丸投げでも自前主義でもない中間の使い方です。

ステップ4：採用は線引きが固まってから

ここまで進めて初めて、採用を具体的に検討する段階です。「何を内製すると決めたか」「その範囲でどんな作業が発生するか」がはっきりしていれば、求人票に書く職務も明確になります。

逆に、この整理をしないまま人を採用すると、採用された側も「自分は何をする人なのか」が分からないまま、目の前の依頼をこなすだけになってしまいます。

AI時代、内製の「1人目」に向いている人材像

内製すると決めた範囲で採用に進むなら、どんな人を探せばよいのでしょうか。AIが開発の前提になったことで、1人目に求めるものも以前とは変わりました。細かい技術要件より先に見ておきたい観点を、3つに絞って紹介します。

「書けること」より「AIの出力を見極められること」

AIでコード生成が可能になってから、人の価値は「自分で書ける」ことから「出てきたものが正しいか判断できる」ことへ移りました。

こうした確認ができる人が、AIを使った内製では力を発揮します。特定のプログラミング言語に深く習熟しているかより、全体を広く分かっていて違和感に気づけるかを見てください。

要件を言葉にできること

AIは、あいまいな指示にもすぐ「それらしい成果物」を返します。裏を返せば、要件が甘いまま渡すと、間違ったものが速く大量にできあがりかねないのです。企業側の要望を聞き取り、作るべきものを言葉と仕様に落とし、AIツールに渡せる形へ整える。この工程は人にしかできず、AIが広まった今はむしろ重要度が増しています。AI時代のエンジニアには、コミュニケーション力が強く求められているのです。

新しいツールを試し続け、AIの限界も分かっていること

AI関連のツールは数カ月単位で新しいものと入れ替わります。10年前に覚えた1つのやり方に留まる人より、出てきたものを試して自社に取り込める人のほうが、AI時代の内製には向きます。あわせて、AIの限界を分かっているかも見ておきたい点です。生成物をそのまま信じない、社外のAIサービスに会社の情報を安易に入れない、出力の扱いにルールを設ける。こうした感覚がある人だと、後々のトラブルを避けやすくなります。

なお、AIモデルの構築や大規模な基盤の設計まで1人目に求める必要はありません。そこは外部の専門家と組む前提にして、まずはAIを使いこなし、幅広く業務をこなせる人材を採用しましょう。

まとめ：内製化は「人を採ること」ではなく「持ち続けられる形を設計すること」

「エンジニアを採るべきか」から入ると、内製化はうまくいきません。何をする人かが定まらないまま人を抱え、その1人に頼りきったシステムだけが積み上がるからです。

AIで「作る」のは速くなりました。それでも、何を作るか決めること、直し続けること、人が代わっても動くようにしておくことは、これまでどおり人の仕事です。だから内製化は、採用ではなく「どこまでを自分たちで持ち続けるか」を決めるところから始まるのです。

「外注はきついが、人もいない」。この行き詰まりは、外注か内製のどちらか一方に決めようとするほど深くなります。すべてを外注するか、すべてを内製するかをを最初から決める必要はないと分かれば、着手しやすい業務から始められるのではないでしょうか。

株式会社MUは、システム開発の要件定義から開発、その後の運用・保守、そして社内で開発を続けられるようにするための伴走支援まで手がけています。どこまでを内製にして、どこを外部と組むか、その線引きの設計からご一緒できます。内製と外注のバランスでお悩みでしたら、お気軽に株式会社MUにご相談ください。