社内エンジニアと外注の役割分担｜4象限で決める線引き基準

「社内のエンジニアが1人しかいないのに、基幹システムの改修も社内システムの開発も運用保守も全部その人に集中していて、もし辞められたら業務が止まってしまう」。そんな危機感を抱えながら、新しい開発案件まで降ってきて、いよいよ外注を検討し始めた——。中小企業の情シス責任者やIT統括の方から、こうした声をよく聞きます。

外注を入れるしかないと頭では分かっていても、いざ進めようとすると手が止まります。「どこまでを社内に残して、どこから外に出していいのか」を判断する基準が自分の中にないからです。過去に「丸投げしたら要件がずれて作り直しになった」「外注先に依存しすぎて社内に何のノウハウも残らなかった」という苦い経験があれば、なおさら踏み出しにくくなります。

しかし、ここで迷うべきなのは「外注すべきか、すべきでないか」というYes/Noの問いではありません。本当に決めるべきなのは「どの業務を社内に残し、どの業務を外に出すか」という配分の線引きです。社内エンジニアと外注エンジニアは対立するものではなく、組み合わせて役割を分担するのが中小企業にとっての現実的な解だからです。

本記事では、社内エンジニアと外注の役割分担を設計するための判断軸を、できるだけ実用的な形で整理します。業務を「コア度×変動性」の4象限に仕分けるフレーム、社内に残す業務と外注に出す業務の線引き基準、役割分担を機能させる契約形態、そして外注してもノウハウを社内に残す進め方まで、順を追って解説します。読み終えるころには、自社の業務を仕分ける設計図を描き、「まずどの業務から外注するか」という最初の一歩を決められる状態を目指します。

社内エンジニアと外注エンジニアの役割分担が今必要な理由

外注を検討する前に、まず「なぜ役割分担の設計がこれほど重要になっているのか」を整理しておきます。背景を共有しておくことで、この後の線引き基準が「なぜそう判断するのか」まで腹落ちしやすくなります。

ひとり情シス・社内SE偏重がもたらす属人化と退職リスク

多くの中小企業では、社内のIT業務が1〜2名のエンジニア、いわゆる「ひとり情シス」に近い体制に集中しています。基幹システムの改修、社内システムの開発、日々の運用保守、ヘルプデスク対応まで、その一人がすべてを抱えている状態です。

この体制には2つの構造的なリスクがあります。1つは属人化です。業務の進め方や設計の意図がドキュメント化されず、その担当者の頭の中にしか存在しないため、他の誰も代われません。もう1つは退職リスクです。属人化が進むほど、その担当者が退職した瞬間に業務が止まり、最悪の場合はシステムの中身が誰にも分からなくなります。

背景には、構造的なIT人材不足があります。経済産業省の試算によれば、IT人材の不足は2030年には中位シナリオで約45万人、高位シナリオで最大約79万人に拡大すると予測されています（経済産業省「IT人材需給に関する調査」）。採用市場でエンジニアの確保はますます難しくなっており、「人を増やして社内体制を厚くする」という選択肢だけに頼るのは現実的ではなくなっています。

なぜ「全部内製」も「全部外注（丸投げ）」も失敗するのか

人材不足を背景に、対応の方向は大きく2つに振れがちです。しかし、どちらの極端も中小企業にとってはうまくいきません。

「全部内製」は、社内にエンジニアを増やして自前で対応しようとする方向です。理想ではありますが、採用に時間とコストがかかるうえ、繁忙期に合わせて人を雇うと閑散期には余剰になります。専門外の技術領域まで社内人材だけでカバーしようとすると、品質もスピードも犠牲になります。

一方「全部外注（丸投げ）」は、要件の整理まで含めて外部に投げてしまう方向です。これが先ほど触れた「要件がずれた」「ノウハウが残らなかった」という失敗の典型です。自社の事業を理解した上での判断や最終的な品質責任まで外に出してしまうと、出来上がったものが意図とずれても気づけず、修正もコントロールできなくなります。

つまり、どちらか一方に振り切るのではなく、「社内が担うべき業務」と「外注に出すべき業務」を見極めて配分する——この配分設計こそが、中小企業の現実的な解になります。次の章から、その配分を設計するための判断材料を順に揃えていきます。

内製と外注の違いを役割設計の視点で整理する

業務を仕分ける前に、社内エンジニア（内製）と外注エンジニアがそれぞれ何を得意とするのかを、役割設計の視点で整理しておきます。単なるメリット・デメリットの列挙ではなく、「どんな業務をどちらが担うと噛み合うか」という観点で対比すると、後の仕分けがぶれにくくなります。

社内エンジニアが担うと強い領域

社内エンジニアの最大の強みは、自社の事業や業務を深く理解していることです。「この機能は現場のどんな業務を支えているのか」「過去にどういう経緯でこの仕様になったのか」といった文脈を持っているため、表面的な要件の裏にある本質的な意図を汲み取れます。

意思決定の速さも社内ならではです。仕様を判断する際に契約や見積もりのやり取りを挟まず、その場で関係者と相談して決められます。日々の運用保守のように継続的に蓄積していく知見も、社内に置いておくほど次の改善に活きます。

まとめると、社内エンジニアは「事業ドメインへの理解」「意思決定の速さ」「継続運用での知見蓄積」が求められる領域で強みを発揮します。

外注エンジニアが担うと強い領域

外注エンジニアの強みは、必要な専門スキルを必要なときに即座に調達できることです。社内にない技術領域や、特定のフレームワーク・インフラの専門知識を、採用や育成の時間をかけずに確保できます。

繁閑への伸縮性も外注の利点です。新規開発の山場だけ人手を増やし、落ち着いたら縮小するといった調整が、雇用に比べてはるかに柔軟にできます。スポット的な開発や、社内では頻度が低くて専任を置けない作業も、外注なら都度依頼できます。

まとめると、外注エンジニアは「専門スキルの即時調達」「コストの変動費化」「繁閑への伸縮対応」が求められる領域で強みを発揮します。

コスト構造の違い（固定費と変動費）を発注判断にどう使うか

内製と外注は、コストの性質そのものが異なります。社内エンジニアの人件費は、業務量にかかわらず毎月発生する固定費です。一方、外注費は依頼した分だけ発生する変動費です。

この違いは、発注判断の重要な材料になります。業務量が年間を通して安定していて常に一定の稼働がある業務は、固定費である内製の方が割安になりやすい傾向があります。逆に、時期によって業務量が大きく変動する業務や、一時的にしか発生しない業務は、変動費である外注の方がコスト効率が良くなります。

つまり「その業務の量は安定しているか、変動するか」というコスト構造の観点が、内製か外注かを判断する1つの軸になります。この「変動性」の軸は、次の章で紹介する仕分けフレームの柱の1つでもあります。

社内に残す業務と外注に出す業務の線引き基準

ここからが本記事の中核です。社内エンジニアと外注エンジニアの役割分担を設計するために、自社の業務をその場で仕分けられる判断フレームを紹介します。感覚で「これは外注、これは社内」と決めるのではなく、2つの軸で客観的に仕分けることがポイントです。

仕分けの2軸（コア度・変動性）と4象限フレーム

業務を仕分ける軸は2つです。

1つ目は「コア度」、つまりその業務が自社の事業競争力にどれだけ直結しているかです。コア度が高い業務とは、自社の事業ドメインへの深い理解が不可欠で、外に出すと競争力そのものを手放すことになる業務を指します。たとえば、自社サービスの根幹となる機能の企画や、事業判断に直結する要件定義などです。コア度が低い業務は、汎用的なスキルで対応でき、誰がやっても成果に大きな差が出にくい業務です。

2つ目は「変動性」、つまりその業務の量が安定しているか変動するかです。先ほどコスト構造のところで触れた観点で、年間を通して一定量がある業務は変動性が低く、時期や案件によって増減する業務は変動性が高いと整理します。

この2軸を掛け合わせると、業務は次の4象限に分かれます。

それぞれの象限の意味は次のとおりです。

• 第1象限（コア度・高／変動性・低）: 事業の中核で、かつ継続的に発生する業務。ここは社内エンジニアが担うべき領域です。属人化を防ぐ仕組みは必要ですが、外に出してはいけない部分です。
• 第2象限（コア度・高／変動性・高）: 事業の中核だが、業務量が波打つ業務。新規開発の立ち上げなどが典型で、社内が主導権と最終判断を握りつつ、実装の手を外注で補強するハイブリッド運用が向きます。
• 第3象限（コア度・低／変動性・低）: 汎用的で、かつ継続的に発生する定型業務。外注に出すか、自動化・ツール化でそもそもの工数を減らすかを検討する領域です。
• 第4象限（コア度・低／変動性・高）: 汎用的で、かつ一時的・突発的に発生する業務。スポットで外注するのが最も効率的な領域です。

社内に残すべき業務の典型

第1象限・第2象限に該当する、社内に残すべき業務の典型を挙げます。

• 事業ドメインに依存する企画・要件定義: 「何を作るべきか」を決める上流工程は、自社の事業理解がないと判断できません。ここを外に丸投げすると、要件がずれる典型的な失敗につながります。
• 仕様や優先順位に関する意思決定: どの機能を優先するか、どこまでの品質を目指すかといった判断は、事業責任を持つ社内側が握るべきものです。
• 最終的な品質責任の保持: 外注した成果物が要件を満たしているかを判断し、受け入れる責任は社内に残します。これは外注の有無にかかわらず手放せない役割です。
• 基幹システムの中核ロジックの把握: 事業の根幹を支えるシステムの仕組みは、たとえ実装を外注しても、社内が中身を理解しておく必要があります。

これらに共通するのは「自社の事業を理解していないと判断できない」「外に出すと事業のコントロールを失う」という性質です。

外注に出しやすい業務の典型

一方、第3象限・第4象限に該当する、外注に出しやすい業務の典型は次のとおりです。

• 専門特化した実装作業: 要件と設計が定まっていれば、特定技術の実装そのものは専門スキルを持つ外注エンジニアに任せやすい領域です。
• スポットの新規開発: 単発のWebサイト構築や、一時的なツール開発など、継続性が低い案件は外注が向きます。
• 定型的な運用作業: 手順が確立しているサーバー監視やバッチ運用など、汎用スキルで対応できる定型業務は外注化しやすい部分です。
• 繁忙期の開発リソース補強: 社内だけでは手が足りない時期だけ、実装の手を外から補う使い方です。

これらに共通するのは「要件さえ固まれば誰が担当しても成果の差が出にくい」「一時的・変動的に発生する」という性質です。

自社業務を仕分けるチェックリスト

実際に自社の業務を4象限に当てはめる際は、次の問いに答えると象限が見えてきます。各業務について、以下をチェックしてみてください。

• □ この業務は、自社の事業を理解していないと判断・遂行できないか？（Yesならコア度・高）
• □ この業務を外に出すと、自社の競争力や事業判断のコントロールを失うか？（Yesならコア度・高）
• □ この業務の量は、年間を通しておおむね一定か？（Yesなら変動性・低）
• □ この業務は、特定の時期や案件だけ発生する一時的なものか？（Yesなら変動性・高）
• □ この業務は、要件さえ固まれば誰が担当しても成果に大きな差が出ないか？（Yesならコア度・低、外注向き）

最初の2つでコア度を、次の2つで変動性を判定し、4象限のどこに位置づくかを決めます。すべての業務を一度に仕分ける必要はありません。まずは現在社内エンジニアに集中している業務を1つずつ当てはめ、「これは本当に社内が抱えるべきか」を点検するところから始めると、外注に出せる業務が見えてきます。

役割分担を機能させる契約形態と体制設計

4象限で業務を仕分けても、それを実際の発注で機能させる仕組みがなければ絵に描いた餅になります。「丸投げで要件がずれた」という失敗を繰り返さないために、契約形態の使い分けと体制設計を押さえておきます。

請負と準委任の違いと、どの業務にどちらを使うか

外注の契約形態には、大きく「請負契約」と「準委任契約」があります。役割分担を設計する上で、この違いの理解は欠かせません。

請負契約は、成果物の完成を約束する契約です。「このシステムを完成させる」という結果に責任を負い、納品物が要件を満たさなければ修正の責任（契約不適合責任）が発生します。仕様が明確に固まっているスポット開発のように、ゴールが定義できる業務に向きます。

準委任契約は、業務の遂行そのものを約束する契約です。完成責任は負わず、専門的な作業を継続的に提供します。要件が固まりきっていない開発や、運用保守のように「完成」という終わりが定義しにくい業務、社内と密に連携しながら進めたい業務に向きます。

仕分けた象限と対応づけると、ゴールが明確な第4象限のスポット開発は請負、社内主導で柔軟に進める第2象限のハイブリッド開発や第3象限の継続運用は準委任、というように使い分けるのが基本的な考え方です。請負と準委任の使い分けの詳細は、関連記事の「業務委託エンジニアの契約形態の選び方｜請負・準委任と発注前の合意事項」も参考になります。

偽装請負を避ける指揮命令の線引き

契約形態を選ぶ際に必ず注意したいのが「偽装請負」のリスクです。これは、契約上は請負や準委任でありながら、実態として発注者が外注先の作業者に直接指揮命令を行ってしまっている状態を指し、労働者派遣法などに抵触する違法な状態です。

ポイントは、請負・準委任では、発注者が外注先の個々の作業者に対して「いつ・どのように作業せよ」と直接指示を出すことはできない、という点です。作業の進め方や労務管理は外注先（受託側）が行い、発注者は成果物や業務の範囲を通じてやり取りします。

役割分担を設計するときは、「社内の誰が、外注先のどの窓口と、どのレベルでやり取りするか」をあらかじめ決めておくことが、偽装請負を避けつつ意思疎通を保つ鍵になります。指揮命令の線引きについては、関連記事の「業務委託エンジニアに頼める業務・出せない指示｜偽装請負の境界」「偽装請負チェックリスト：業務委託で違法にならない指揮命令の境界線【IT現場版】」もあわせてご確認ください。

社内エンジニアが「発注者」として担うべきマネジメント役割

外注を入れると、社内エンジニアの役割は「自分で手を動かす実装者」から「外注をマネジメントする発注者」へと一部シフトします。このマネジメント役割こそが、丸投げと適切な外注を分ける分岐点です。

発注者として社内が担うべき役割は主に3つです。

1. 要件の確定: 何を作るのか、どこまでの品質を求めるのかを言語化し、外注先と合意します。ここが曖昧なまま発注すると要件がずれます。
2. 受け入れ（検収）: 納品された成果物が要件を満たしているかを判断し、受け入れます。第三者として品質をチェックする最後の砦です。
3. 品質責任の保持: 最終的に事業に対して品質の責任を負うのは社内です。外注に任せた部分も含め、全体が機能するかを見届けます。

これらは先ほどの4象限で「社内に残すべき業務」として挙げた内容と重なります。実装を外に出しても、この発注者としての役割まで手放してはいけない——これが役割分担を機能させる最大の原則です。

外注してもノウハウを社内に残す進め方

「外注したら社内に何も残らない」という不安は、外注をためらわせる大きな要因です。しかし、これは進め方の設計次第で防げます。ノウハウを社内に残す具体策を見ていきます。

ブラックボックス化・ベンダーロックインが起きる仕組み

まず、なぜノウハウが残らなくなるのかを理解しておきます。

ブラックボックス化は、外注先が作ったシステムの中身（設計の意図、構成、設定）が社内の誰にも分からない状態です。ドキュメントがなく、外注先に聞かないと何も分からなくなると、システムの全体像が社内から失われます。

ベンダーロックインは、特定の外注先に依存しすぎて、その会社なしには改修も保守もできなくなる状態です。ブラックボックス化が進むほど、他社への乗り換えも内製化も困難になり、価格交渉力も失われます。

これらは「成果物（動くシステム）さえ納品されればよい」という発注の仕方をしていると、ほぼ自動的に起きます。逆に言えば、発注の時点で対策を設計に組み込めば防げます。

ノウハウを残すための納品物・体制要件

ノウハウを社内に残すために、発注時に決めておきたい具体策は次のとおりです。

• ドキュメントを納品物に含める: 動くシステムだけでなく、設計書・構成図・運用手順書・設定の根拠などを納品物として明記します。「コードと一緒にドキュメントも必須」と契約段階で合意しておくことが重要です。
• 設計資産を社内が保有する: ソースコードや設計データのリポジトリ、各種アカウントの管理権限を社内側で保有します。外注先だけが持っている状態を避けます。
• 社内エンジニアを伴走させる: 開発を完全に外に出すのではなく、社内エンジニアがレビューや定例の打ち合わせに関与し、設計の意図を把握し続けます。手は動かさなくても、中身を理解しておく関わり方です。
• 引き継ぎを前提に進める: 「いずれ社内で保守・改修できる状態にする」ことを最初の合意事項に含めます。ナレッジ移管のための説明会や引き継ぎ資料を、プロジェクトの完了条件に組み込みます。

これらは、先に整理した「請負か準委任か」「発注者としての役割」とも連動します。たとえば、ドキュメント納品や引き継ぎを完了条件に含めるなら、その範囲を契約に明記しておく必要があります。ノウハウを残せるかどうかは、運任せではなく発注設計で決まります。

役割分担の設計手順と最初の一歩

ここまでの判断軸を、実際に動かすための手順に落とし込みます。一度にすべてを完璧に設計しようとせず、ステップを踏んで進めることが、踏み出すためのコツです。

役割分担設計の5ステップ

1. 現状業務の棚卸し: まず、現在社内エンジニアが抱えている業務をすべて書き出します。基幹システムの改修、社内システム開発、運用保守、ヘルプデスクなど、できるだけ具体的に分解します。属人化している業務を可視化する作業でもあります。
2. 4象限で仕分ける: 棚卸しした各業務を、先ほどのチェックリストを使って「コア度×変動性」の4象限に当てはめます。社内に残す業務と外注に出せる業務が見えてきます。
3. 契約形態を割り当てる: 外注に出す業務それぞれに、請負か準委任かを当てはめます。ゴールが明確なものは請負、継続・連携が必要なものは準委任が基本です。
4. 外注対象の優先順位をつける: すべてを一度に外注する必要はありません。社内エンジニアの負担が最も大きい業務、属人化リスクが高い業務、外注しても事業への影響が小さい業務から優先的に着手します。
5. 小さく試す: 優先順位の高い業務から、まず1つだけ外注してみます。次のステップで詳しく触れます。

この5ステップは、そのまま経営層への説明資料にもなります。「現状こうなっていて、こう仕分けて、この業務からこの契約形態で外注する」という流れで整理すれば、外注予算の必要性を論理的に説明できます。

小さく外注を試す（スモールスタート）の考え方

いきなり大規模な開発を丸ごと外注すると、もし相性や進め方が合わなかったときのダメージが大きくなります。そこで推奨したいのが、スモールスタートです。

最初は、コア度が低く変動性が高い第4象限の業務——たとえばスポットの小さな開発や、定型運用の一部——から外注してみます。この領域は、万一うまくいかなくても事業への影響が限定的で、外注先の進め方やコミュニケーションの相性を見極める「お試し」として最適です。

小さく試す中で、要件の伝え方、ドキュメント納品の品質、レスポンスの速さといった「自社に合った外注先か」を確認します。手応えが得られたら、徐々に第2象限のハイブリッド開発など、より重要な業務へと外注の範囲を広げていきます。こうして段階的に進めれば、「丸投げして失敗する」リスクを抑えながら、社内エンジニアの負担を着実に軽くしていけます。

外部人材の活用方法をより体系的に整理したい場合は、外部エンジニア活用の戦略立案ガイド（DX推進・内製化ハイブリッド戦略）もあわせてご覧ください。発注判断の検討材料として活用いただけます。

よくある質問（FAQ）

最後に、社内エンジニアと外注の役割分担に関して、発注者の方からよく寄せられる質問にお答えします。

Q1. 社内エンジニアと外注エンジニアのどちらに任せるか、どう判断すればいいですか？

業務を「コア度（事業競争力への直結度）」と「変動性（業務量の安定/変動）」の2軸で4象限に仕分け、コア度が高い業務は社内に残し、コア度が低く変動性が高い業務は外注に出すのが基本です。具体的なフレームと仕分けチェックリストは、本記事の「社内に残す業務と外注に出す業務の線引き基準」で詳しく解説しています。

Q2. エンジニアやシステム開発を外注する費用相場はどのくらいですか？

費用は、契約形態・依頼する業務の専門性・期間によって大きく変わります。準委任で継続的に依頼する場合はエンジニアの月額単価が基準になり、スキルや経験に応じて幅があります。請負で開発を依頼する場合は、要件の規模に応じた一括見積もりになります。正確な相場は要件によって変動するため、複数社から見積もりを取り、単価だけでなくドキュメント納品や引き継ぎの範囲まで含めて比較することをおすすめします。

Q3. システム開発を外注するデメリット・リスクは何ですか？

主なリスクは3つです。1つ目は「要件のずれ」で、要件定義を丸投げすると意図と異なる成果物ができあがります。2つ目は「ブラックボックス化・ベンダーロックイン」で、ドキュメントや設計資産を社内に残さないと外注先への依存が深まります。3つ目は「コミュニケーションコスト」で、社外とのやり取りには社内より調整の手間がかかります。いずれも、要件確定を社内が握り、ドキュメントや引き継ぎを発注設計に組み込むことで軽減できます。詳しくは本記事の「外注してもノウハウを社内に残す進め方」をご覧ください。

Q4. 内製と外注はどう違いますか？

内製（社内エンジニア）は、事業ドメインへの深い理解・意思決定の速さ・継続運用での知見蓄積に強く、コストは固定費です。外注（外部エンジニア）は、専門スキルの即時調達・繁閑への伸縮対応に強く、コストは依頼分だけの変動費です。両者は対立するものではなく、業務の性質に応じて組み合わせるのが現実的です。

Q5. ひとり情シスの会社でも外注で役割分担はできますか？

できます。むしろ、業務が1人に集中して属人化・退職リスクが高い「ひとり情シス」の体制こそ、役割分担の設計効果が大きい状況です。まずは現状業務を棚卸しし、コア度が低く変動性が高い業務から小さく外注を試すことで、その1人の負担を段階的に軽くできます。社内エンジニアは要件確定・受け入れ・品質責任という発注者の役割に集中し、実装の手を外注で補う形が現実的です。

外部人材の活用を本格的に検討する際は、業務の仕分けから契約形態の選び方まで体系的に整理した外部エンジニア活用の戦略立案ガイド（DX推進・内製化ハイブリッド戦略）もご活用ください。自社の役割分担を設計する際の検討材料になります。