システム内製化はどこまでやるべきか｜外注との使い分けと段階的な進め方

システム開発を外注に頼りきりにせず、社内で開発できる体制をつくりたい。こうした内製化の相談は、事業のデジタル化が進むにつれて増えています。改修のたびに見積もりと契約が必要で動きが遅い、外注費がかさむ、社内にノウハウが残らない、といった不満が背景にあることが多いようです。

ただ、内製化は「エンジニアを採用すれば実現する」ものではありません。採用した人が力を発揮できる環境、仕事の優先順位を決める人、退職したときに知識が途切れない仕組みがなければ、外注していたときより不安定になることもあります。とくに中小企業では、エンジニアが1〜2人だけという状態がそのまま属人化のリスクになります。

反対に、すべてを外注に任せ続けると、システムの中身を理解している人が社内にいなくなり、外注先の提案を判断できなくなります。大切なのは、内製か外注かの二択ではなく、どの部分を社内で持ち、どの部分を外部に任せるかを決めることです。

この記事では、内製化で得られるものと失うもの、内製に向く領域と外注に向く領域の見分け方、段階的な進め方、外部と組むときの契約形態の注意点を解説します。

内製化で得られるものと失うもの

内製化の効果としてよく挙げられるのは、改修のスピード、費用の削減、ノウハウの蓄積です。ただし、これらはいずれも条件付きで成り立つものです。

期待されること	成り立つ条件	成り立たないケース
改修が速くなる	小さな改修が頻繁に発生し、優先順位を社内で即決できる	改修の頻度が低く、エンジニアの手が空く期間が長い
費用が下がる	開発の仕事量が年間を通じて安定している	開発量に波があり、繁忙期だけ外注も併用することになる
ノウハウが残る	複数人で知識を共有し、ドキュメントを書く習慣がある	1人のエンジニアに知識が集中し、その人が退職する
事業に合った開発ができる	エンジニアが業務の現場と日常的に会話できる	エンジニアが孤立し、依頼をこなすだけになっている

費用の面では、外注費と社員の人件費を単純に比べると内製のほうが安く見えがちです。しかし社員には給与のほかに社会保険料、採用費、教育費、開発用の機材やツールの費用がかかり、仕事が少ない期間も固定費として発生します。外注は単価が高くても、必要なときに必要な分だけ使える変動費です。開発の仕事量が安定しているかどうかで、どちらが安くなるかは変わります。

失うものとしては、外部の専門性に触れる機会があります。外注先は複数の企業のシステムを手がけているため、技術の選び方や失敗の避け方について幅広い知見を持っています。社内だけで開発していると、その知見に触れる機会が減り、技術の選択が古いまま固まってしまうことがあります。

内製に向く領域と外注に向く領域

どこを内製にするかは、その領域が事業の競争力にどれだけ関わるかと、変更がどれだけ頻繁に起きるかで判断するのが分かりやすい方法です。

領域の性質	おすすめの持ち方	例
事業の差別化に直結し、変更が頻繁	内製を目指す。少なくとも仕様の判断は社内で持つ	自社サービスの画面や機能、独自の業務ロジック
事業の差別化に直結するが、変更は少ない	設計と仕様は社内、実装は外注でもよい	独自の計算処理や価格算定の仕組み
差別化には関わらないが、変更が多い	パッケージやSaaSの設定変更で対応できるか先に検討する	帳票のレイアウト、通知の文面
差別化に関わらず、変更も少ない	外注またはパッケージ・SaaSを使う	会計、勤怠、一般的なワークフロー
高度な専門性が一時的に必要	外注する。社内には判断できる人を置く	大規模なデータ移行、セキュリティ診断、AIの検証

この表で大切なのは、内製の対象を「開発作業」ではなく「判断」として捉えていることです。仕様を決める、優先順位をつける、外注先の提案が妥当かを評価する、といった判断は、プログラムを書かなくても社内で持つことができます。多くの中小企業にとって、内製化の最初の目標は開発作業ではなく、この判断を社内に取り戻すことです。

会計や勤怠のように、どの会社でも同じような業務は、自社開発する意味が薄い領域です。この種の業務まで内製の対象にすると、限られたエンジニアの時間が差別化に関わらない仕事に取られてしまいます。

どの区分にも当てはまりにくい場合は、「その機能の改修を外注先に依頼したとき、待ち時間が事業に影響しているか」を考えてみてください。依頼から反映までの数週間が売上や顧客対応の遅れにつながっているなら、その領域は社内で持つ価値があります。待っても困らないのであれば、外注のままで問題ないことがほとんどです。

もう一つの目安は、その領域の知識が社内の業務知識と切り離せるかどうかです。業務の細かいルールを知らないと正しく作れない領域は、外注先に毎回説明するコストがかかります。逆に、業務知識をほとんど必要としない技術的な領域は、外部の専門家に任せたほうが質も速さも上がりやすくなります。

段階的に進める内製化のステップ

内製化は、いきなり開発チームをつくるよりも、判断する力から順に社内へ移していくほうが失敗しにくくなります。段階ごとに必要な人材と、外部の使い方を整理すると次のようになります。

段階	社内で持つもの	外部に任せるもの
1．発注者として判断できる	要件の整理、優先順位の決定、見積もりと成果物の評価	設計、開発、運用のほぼすべて
2．仕様を社内で決める	上記に加え、画面や機能の仕様、受入テスト	設計と開発、インフラの運用
3．一部を社内で開発する	小さな改修、データの抽出や集計、簡単な画面の追加	大きな機能開発、インフラの設計、専門的な領域
4．主要な開発を社内で行う	中核となる機能の設計と開発、技術の選定	一時的に人手が足りない部分、専門性の高い部分

段階1と2は、エンジニアを採用しなくても進められます。業務を理解している社員がプロジェクトの責任者となり、外注先とのやりとりを通じて、仕様の決め方やテストのやり方を身につけていく形です。この段階を飛ばしてエンジニアを採用すると、採用した人が何を作るべきかを決める人がいないまま、外注先の代わりに依頼をこなすだけになりがちです。

段階3に進むときは、1人ではなく複数人で知識を共有できる体制を意識しましょう。最初から複数人の採用が難しい場合は、外部の開発パートナーと社内のエンジニアが同じソースコードを扱い、互いにコードを確認し合う体制にすることで、知識が1人に閉じるのを防げます。

段階3で最初のエンジニアを採用する場合は、求める役割をはっきりさせておくことが大切です。1人目のエンジニアには、プログラムを書く力に加えて、業務の担当者から話を聞いて仕様に落とし込む力や、外部の開発パートナーと技術的な会話をする力が求められます。特定の言語や技術の経験年数だけで選ぶと、入社後に「何を作るか」の部分で手が止まりやすくなります。

また、エンジニアを採用する前に、既存システムのソースコードやインフラのアカウントを自社で受け取れる状態にしておく必要があります。採用したエンジニアが最初に取り組むのは、多くの場合、既存システムの中身を理解することです。ソースコードが外注先の手元にしかない状態では、採用しても仕事を始められません。

段階4まで進む必要がある企業は、自社のシステムそのものが商品やサービスの中核になっている場合に限られます。そうでなければ、段階2か3で止めるのが費用対効果の面で合理的なことも多くあります。どこまで進むかは、最初に決めておく必要はありません。各段階で半年から1年ほど運用し、次に進むかどうかを判断すれば十分です。

外部と組むときの契約形態の注意点

内製化を進める途中では、社内のメンバーと外部の技術者が一緒に働く場面が増えます。このとき注意したいのが契約形態です。請負契約、準委任契約、労働者派遣契約では、発注側が外部の技術者に対してできることが異なります。

契約形態	発注側が約束を受けるもの	技術者への直接の指示
請負契約	完成した成果物	できない。依頼は受注側の責任者を通す
準委任契約	作業の遂行（成果物が約束されない形が基本）	できない。依頼は受注側の責任者を通す
労働者派遣契約	派遣された労働者の労務	できる。派遣元は労働者派遣事業の許可が必要

請負や準委任の契約なのに、発注側の社員が外部の技術者に作業の進め方や勤務時間を直接指示していると、実態として労働者派遣とみなされ、いわゆる偽装請負の問題になるおそれがあります。厚生労働省は、労働者派遣と請負を区分する基準（昭和61年労働省告示第37号）を示しており、受注側が自ら業務の遂行方法や労働時間の管理などを行っていることなどを、請負として扱われる条件にしています。

実務上は、次のような運用にしておくと問題が起きにくくなります。

• 外部の技術者への依頼は、受注側の責任者や窓口を通して行う
• 依頼は作業の進め方ではなく、何を実現したいかという要件として伝える
• 作業時間や勤務場所の管理は受注側に任せる
• 社内メンバーと同じチャットを使う場合も、依頼の窓口と経路を決めておく

社内のメンバーと外部の技術者を一つのチームとして日常的に指示しながら動かしたい場合は、その運用に合った契約形態を選ぶ必要があります。契約形態と実際の働き方が食い違っていないかは、内製化の途中で定期的に確認しておきましょう。

参考：労働者派遣事業と請負により行われる事業との区分に関する基準（昭和61年労働省告示第37号）／厚生労働省

参考：労働者派遣事業の適正な運営の確保及び派遣労働者の保護等に関する法律／e-Gov法令検索

内製化でつまずきやすいポイント

内製化がうまくいかないケースには、いくつか共通するパターンがあります。事前に知っておくと、計画の段階で手を打てます。

つまずき	起きる理由	対策
採用したエンジニアがすぐに辞める	相談できる相手がおらず、評価の基準もない	技術面の相談先として外部の開発パートナーを確保し、評価の観点を事前に決める
エンジニアが社内の雑務に追われる	パソコンの設定やネットワークの不具合など、ITに関わる仕事がすべて集まる	開発と社内IT対応の役割を分け、開発に使う時間を確保する
既存システムの改修が進まない	外注先が作ったシステムの中身が分からない	外注先との契約に引き継ぎ協力を含め、ドキュメントとソースコードを受け取る
何を作るかが決まらない	エンジニアはいるが、仕様と優先順位を決める人がいない	業務側にプロジェクトの責任者を置き、決める役割を明確にする

とくに注意したいのが、既存システムの引き継ぎです。外注先が開発したシステムを社内で改修するには、ソースコードの権利と、システムを理解するための資料が必要です。契約書で権利の扱いがどうなっているかを確認し、外注先から段階的に知識を移してもらう期間を設けましょう。

また、内製化の成果を測る指標を最初に決めておくことも大切です。外注費の削減額だけを見ると、人件費の増加と相殺されて成果が見えにくくなります。改修の依頼から反映までの期間、社内で判断できるようになった項目の数など、内製化で改善したいことに合わせて指標を選びましょう。

内製化を進めると、外注先との関係も変わります。すべてを任せていたときとは違い、社内のエンジニアと外部の開発パートナーが同じシステムを扱うことになるため、ソースコードの管理方法や品質の基準、リリースの手順をそろえておく必要があります。外部の開発パートナーを選ぶときは、社内のメンバーと一緒に働くことや、知識の移転に協力的かどうかも判断材料に加えるとよいでしょう。

まとめ

システムの内製化は、開発作業を社内に移すことよりも、仕様や優先順位を決める判断を社内に持つことから始めるのが現実的です。事業の差別化に関わり、変更が頻繁な領域ほど内製の価値が高く、どの会社でも同じような業務はパッケージやSaaS、外注に任せるほうが合理的です。

自社の状況によって、最初の一歩は変わります。

現在の状況	最初にやること
外注先に任せきりで、仕様を社内で説明できない	業務側にプロジェクトの責任者を置き、外注先とのやりとりに同席してもらう
仕様は社内で決めているが、小さな改修にも時間がかかる	小さな改修やデータ集計を社内でできるよう、1人目のエンジニアと外部の開発パートナーの組み合わせを検討する
社内にエンジニアがいるが、1人に知識が集中している	ドキュメントの整備とコードの相互確認の体制をつくり、知識を複数人で持つ

明日すぐにできることは、自社のシステムを一覧にして、それぞれが事業の差別化に関わるか、変更がどれくらい発生しているかを書き出してみることです。その一覧が、どこを社内で持ち、どこを外部に任せるかを考える土台になります。