システム開発の外注と内製｜中小企業の判断基準

01はじめに｜「外注か内製か」は、会社単位で決める話ではありません

要点： 「うちは外注」「うちは内製」と会社単位で決めると、どちらを選んでも無理が出ます。同じシステムでも、作る工程と直し続ける工程では向き不向きが逆になるからです。まず工程に分けて、置き場所を決めてください。

「システムを作りたいのですが、外注するべきか、社内でやるべきか」。ご相談でいちばん多い質問です。ただ、この問いの立て方には、はじめから無理があります。

システム開発の外注と内製は、二者択一のように語られがちです。でも1つのシステムの中には「一度作れば数年変わらない部分」と「毎月のように直したい部分」が同居しています。前者は外注が向き、後者は社内が向く。会社まるごとで寄せると、必ずどちらかで詰まります。

この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、中小企業の現場で使える判断のしかたを整理します。読み終えるころには、「この部分は依頼する、ここだけはうちで持つ」と、私自身の言葉で線を引けるようになります。開発そのものの進め方は、Webシステム開発のサービスページもあわせてご覧ください。

先に、この記事で扱う範囲をはっきりさせておきます。

• 扱うもの。 受注管理・在庫管理・顧客管理といった社内向け業務システムについて、外注と内製をどう振り分けるかの判断基準。
• 扱わないもの。 プログラミング言語の選び方やコードの書き方。「どこを誰に持たせるか」という体制の話だけを扱います。
• 想定する規模。 従業員10〜300名ほどの中小企業。金額は税別、2026年8月時点の目安です。

まずは、内製化という言葉が何を指しているのか。動画で全体像をつかんでから読み進めてください。

02システム開発の外注と内製、それぞれが向いている場面

要点： 外注が向いているのは、仕様が決まっていて、作り終わりがある仕事です。内製が向いているのは、正解が見えておらず、動かしながら毎月直したい仕事です。この2つは同じシステムの中に同居します。

向き不向きは、技術の高さでは決まりません。「終わりがあるか、終わりがないか」で決まります。

受注管理の画面を新しく作る。これは終わりがある仕事です。人を集めて一気に作り、終わったら解散できるので、外注が得意とします。社内で同じことをすると、その期間だけ人が足りず、あとで余ります。

一方、使いはじめてからの「並び順を変えたい」「項目を足したい」には終わりがありません。毎月続きます。こちらは社内のほうが速く回ります。依頼書を書いて、見積りを待って、発注する。この往復が要らないからです。

• 外注が向く仕事。 新規構築、大きな機能追加、他システムとの連携、リニューアル。専門性が要り、期間が区切れるもの。
• 内製が向く仕事。 画面の並び替え、項目の追加、帳票の書式変更、運用に合わせた微調整。小さくて頻度が高いもの。
• どちらでもよい仕事。 データの移行、初期設定、マスタ登録。手数はかかりますが、専門性はそれほど要りません。

費用の目安から知りたい場合は、システム開発の費用相場を100万円と1000万円で比べた記事を先に読むと、この振り分けの重さが実感しやすくなります。

03判断軸別｜外注と内製、どちらに寄せると有利か

要点： 判断軸を8つに分けて並べると、外注が有利な軸と内製が有利な軸ははっきり分かれます。速さや安さといった漠然とした比較ではなく、軸ごとに見てください。全部を一方に寄せる理由は、どの会社にもありません。

「外注は高い」「内製は遅い」は、どちらも半分だけ当たっています。Webシステム開発のご相談でうかがう論点を8つの軸に整理すると、そのねじれが見えてきます。

並べてみると、外注が有利な軸は「立ち上げ」と「守り」に、内製が有利な軸は「日々の手入れ」に集まっていると分かります。この偏りが、そのまま振り分けの答えです。

外注は立ち上げと守りに強く、内製は日々の手入れに強い。どちらかを選ぶ必要はありません。

04内製化のメリットは「速さ」ではなく「直し続けられること」

要点： 内製化のメリットとしてよく挙がる「速い・安い」は、条件つきでしか成立しません。確実に得られるのは、公開したあとに何度でも直せる状態です。ここを目的に置かない内製化は、たいてい途中で止まります。

内製化のメリットは、多くの記事が「開発が速い」「費用が安い」と答えます。でもこの2つは、前提が崩れると簡単に逆転します。作れる人が1人しかいなければ速くありませんし、その1人の人件費は外注費より高くつく場合もあります。

条件に左右されない内製化のメリットは、実は1つだけです。公開したあとに、自分たちの都合で何度でも直せること。これに尽きます。

たとえば、受注画面の入力順を現場の作業順に合わせたいとします。外注だと、要望を伝え、見積りをもらい、稟議を通す。ここまでで2〜4週間かかります。金額は数万円でも、この往復があるために「まあ今のままでいいか」と流れがちです。社内に触れる人がいれば、その日のうちに直せます。

もう1つ、要件の言語化がうまくなるという効果もあります。社内で手を動かした経験があると、外注する場面でも要望の伝え方が変わります。要件の固め方そのものは、要件定義の進め方をまとめた記事で扱っています。

逆に、内製化に期待してはいけないものも挙げておきます。

• 大規模開発の速さ。 人数がそろわない以上、大きな構築は社内のほうが遅くなります。
• セキュリティや可用性の水準。 攻撃対策や障害時の切り戻しは、経験の量が差になります。
• 短期の費用削減。 採用と教育を含めると、最初の2年は外注より高くつきます。

05内製が成立する人数と、そろわないときに起きること

要点： 内製が続くかどうかは、技術力よりも人数で決まります。1人だけの体制は、休みと退職の両方に耐えられません。3人以上そろってはじめて、外注を使わずに回せる状態になります。

内製化の話でほとんど語られないのが、人数です。ところが現場では、ここがいちばん効いてきます。相談を受けた案件を人数別に並べると、線がきれいに出ました。

いちばん危ないのは、いちばん多い形でもある「1人・兼任」です。本人のやる気や技術は関係ありません。繁忙期に本業が重くなった瞬間、開発は止まります。止まっている間に、現場は元のExcelへ戻ります。この戻りかたはExcel業務をシステム化すべきサインをまとめた記事でも触れています。

3人という線には理由があります。1人が抜けても2人残り、そのうち1人は仕様を知っている。2人と3人の差は1.5倍ではなく、止まるか止まらないかです。

06社内エンジニア不足のまま内製化すると、何が起きるか

要点： 社内エンジニア不足のまま内製化を決めると、開発が止まるだけでは済みません。動いているシステムを誰も直せない状態が残ります。採用でも解決しにくく、これが中小企業でいちばん重い失敗です。

社内エンジニア不足は、この判断の背景そのものです。IPAの「DX動向2025」では、日本企業の85.1%でDXを推進する人材が不足していると報告されています。人がいないのは自社だけの事情ではありません。採用市場で取り合いになっている以上、「採用できたら内製する」は実行日が決まらない計画になりがちです。

それでも見切り発車で内製に踏み切ると、次の順番で問題が現れます。

1. 着手が遅れる。 採用が決まらない、決まっても立ち上がりに3〜6か月かかります。その間、課題は放置されます。
2. 作りかけで止まる。 半分だけ動くシステムが残り、現場は新旧の二重運用になります。
3. 担当者に全部が集まる。 設計の意図もパスワードも本人の頭の中だけになります。
4. 退職で完全に止まる。 動いてはいるが誰も直せないシステムだけが残ります。

4番目まで進むと、立て直しは最初から作り直すより高くつくことがあります。中身を読み解く作業が先に必要になるからです。

採用できるまで待たない、というのが現実的な答えです。外注で先に動かし、社内の担当者はその横で「仕様を理解する役」に置く。手を動かす人と、業務を分かっている人は、別でも構いません。

07外注リスクの正体は「外注」ではなく「丸投げ」です

要点： 外注リスクとして語られる「高くつく」「思ったものと違う」「他社に移せない」は、外注ではなく丸投げから生まれます。決める人を社内に置き、設計書と権限を受け取る。この2つでほとんどが防げます。

外注リスクを並べた記事はたくさんあります。ただ、その項目をよく見ると、「外注したから起きたこと」ではなく「決める人を社内に置かなかったから起きたこと」がほとんどです。代表的な4つを整理します。

• 思っていたものと違うものが出てくる。 要件を相手任せにしたことが原因です。画面の下書きを1枚でも自分で書けば、ずれは着手前に見つかります。
• 追加費用が次々と発生する。 見積りの前提を読まずに契約したことが原因です。何が含まれ、何が別料金かはシステム開発の見積もりの見方で確かめてください。
• 他社に引き継げず、値上げを断れない。 設計書とソースコード、サーバーの権限を受け取っていないことが原因です。契約書に一行入れるだけで防げます。
• 小さな修正に毎回2週間かかる。 メンテナンスの範囲を決めていないことが原因です。月内で何時間まで対応するかを、契約時に数字で決めてください。

契約の形や役割分担は、IPAが情報システム・モデル取引・契約書を公開しています。一から考えなくても、ひな形として参照できます。

外注が危ないのではありません。決める人を社内に置かないまま外注することが危ないのです。

その1人は、プログラムを書ける必要はありません。業務を分かっていて、優先順位を決められる人で十分です。

085年モデル｜外注・内製・併用の累計コスト

要点： 1つの業務システムだけを内製で持つと、5年たっても外注より高いままです。内製が金額で見合うのは、同じ担当者が3つ以上の業務を継続して見られる場合に限られます。この違いは初年度からは見えません。

費用は、初期費用だけを比べても意味がありません。5年分を並べてはじめて差が出ます。中規模の業務システム1本を想定した試算です。

この表で大事なのは、いちばん下の行です。同じ内製でも、担当する業務の数で1業務あたりの負担は3分の1になります。1業務だけを抱えると5年目には外注の3倍を超え、3業務を見られるなら4年目に外注中心と肩を並べます。

金額だけなら外注中心がいちばん安いのですが、併用には「その日のうちに直せる」価値が乗ります。この差額を、その価値で説明できるかで判断してください。ホームページ制作の費用相場と並べて議論すると、投資の優先順位を決めやすくなります。

09開発を委託するかどうかを、5つの質問で判断する

要点： 開発の委託判断は、5つの質問に順番に答えるだけで決まります。上から順に答えていき、「いいえ」が出た時点で外注または併用が正解です。感覚ではなく、順番で決めてください。

迷ったときの順番を用意しました。上から答えていき、「いいえ」が出たらそこで判断は確定します。

1. 3年後もこの業務は続いていますか。 数年でやめる業務なら、人を抱えず外注で作り切ってください。人は残りますが、業務は残りません。
2. 公開後、月1回以上は直したくなりますか。 年に数回しか触らないなら、社内に持つ理由はありません。メンテナンス契約で足ります。
3. いま社内に、専任で3人以上を確保できますか。 確保できないなら、内製を主軸にはできません。併用を前提に設計してください。
4. その担当者は、他にも2つ以上の業務を見られますか。 見られないなら、金額の面で内製は見合いません。
5. 担当者が明日辞めても、他の人が直せますか。 直せないなら、内製化はまだ完了していません。設計書と手順書を残すところから始めてください。

5つすべてに「はい」と答えられる中小企業は、そう多くありません。ご相談を受ける会社の多くは3番目か4番目で止まります。それは失敗ではなく、併用という答えに着地しただけです。デジタル化をどこから始めるか迷っている段階なら、小規模から始めるDXの進め方を先に読むと答えやすくなります。

10工程別｜どこを外注し、どこを社内に残すか

要点： 工程で切り分けると、社内に残すものは意外に少なくなります。優先順位を決める役と、日々の小さな改修。この2つだけ社内に置き、残りは外注に任せて構いません。

ここまでを、工程ごとの振り分け表にまとめます。人数が2人以下の会社を想定した形です。

右端の列を縦に読んでみてください。社内に必ず残すものは、どれも手を動かす作業ではありません。決めること、説明すること、受け取ること。プログラムを書ける人がいなくても実行できます。

逆に、この列を空欄にしたまま進めた案件は、あとで困っています。とくに「設計書の受領」と「ソースコードの受領」は、契約書に書いていなければ手元に来ません。

11まとめ｜工程で切り分け、直し続ける場所だけ社内に残す

要点： システム開発の外注と内製は、会社単位ではなく工程単位で決めてください。決める人を社内に置き、設計書と権限を受け取る。この形なら、社内に開発者がいなくても外注リスクは大きく下がります。

まず、問いの単位を会社から工程に変えます。次に、5つの質問に上から答え、内製を主軸にできるかを確かめます。多くの中小企業は3番目か4番目で止まり、併用に着地します。それで構いません。

そのうえで、社内に残すのは「決める・説明する・受け取る」の3つだけ。手を動かす工程は外注に任せます。この形なら、社内エンジニア不足のままでも前に進めますし、外注リスクの大半も防げます。

ZenWeb Japanは2000年の創業以来、ホームページ制作とWebシステム開発を手がけてきました。振り分けのご相談だけでも承ります。Webシステム開発のページからお気軽にお問い合わせください。

12よくある質問

要点： 開発の委託判断でよく聞かれるのは、ノーコードで代替できるか、途中から内製に切り替えられるか、オフショアは選択肢になるか、契約で何を守るか、担当者を採用すべきかの5つです。順にお答えします。

1. ノーコードツールを使えば、社内エンジニアがいなくても内製できますか？

小さな業務であれば可能です。申請フォームや簡単な台帳管理なら、ノーコードツールで十分回ります。ただし、他システムとの連携や複雑な権限管理が必要になった時点で頭打ちになります。作り込みが増えるほど、結局は担当者しか触れない状態に戻る点にもご注意ください。

2. 最初は外注で作り、途中から内製に切り替えられますか？

切り替えられます。ただし、着手前の準備が必要です。設計書とソースコードを受け取れる契約にしておくこと、サーバーやドメインの権限を自社名義で持っておくこと。この2つがなければ、あとから切り替えようとしても実質的に不可能になります。

3. 人数が足りない場合、オフショア開発は選択肢になりますか？

なります。とくに継続的に手を入れたい開発では、国内の人材を採用するより早く体制を組めます。ただし、日本語で要件を受け止める窓口が間に入るかどうかで結果が大きく変わります。ZenWeb Japanでは日本人SEが窓口に入る形をとっています。

4. 外注するとき、契約で必ず確認すべき点は何ですか？

4つあります。ソースコードと設計書の引き渡し、著作権の帰属、メンテナンスの対応範囲と対応時間、そして追加開発の単価です。とくに1つ目と2つ目が抜けていると、あとから他社に移せなくなります。IPAが公開しているモデル契約書がひな形として参考になります。

5. 内製化のために、エンジニアを1人採用するのは有効ですか？

その方が3つ以上の業務を継続して見られるなら有効です。1つの業務だけを任せる想定なら、費用の面で見合いません。また、1人体制は退職で完全に止まるため、採用と同時に外注先を1社確保しておくことをおすすめします。