LASSIC Media らしくメディア
システム開発を外注するメリット・デメリットと丸投げを防ぐ進め方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム開発の外注は専門技術をすぐにそろえられる一方、知識が委託先に残りやすい点がデメリットです。
- 丸投げの失敗は、要件の決定と検収を発注する側が持ち、変更を手続で協議することで防げます。
- 契約の前に、工程ごとの契約の形と役割分担、再委託、引き継ぎの範囲を委託先と確かめておきます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
社内に開発の担当者がいないので外注したいが、任せきりにして失敗しないか不安だ。見積もりを取ったものの、内製と比べてどちらがよいのか判断がつかない——。システムの刷新を任された情報システムの担当者には、こうした迷いがつきものです。システム開発の外注とは、システムの設計や製作を社外の開発会社に契約で委託することを指します。
人と技術をすぐにそろえられる便利なやり方です。ただし万能ではなく、発注する側の関わり方しだいで、費用や納期が膨らむこともあります。本記事では、システム開発を外注するかどうかを判断する担当者に向けて、外注のメリットとデメリット、内製との違い、丸投げで起きやすい失敗と防ぎ方、そして外部に頼むときに確認したい点を整理します。
システム開発の外注とは
システム開発の外注は、システムの設計やプログラムの製作などを、社外の開発会社に契約で委託することです。日本ではIT人材の72％がIT企業に所属し、ユーザー企業に所属するのは28％にとどまります。*4 IPA（情報処理推進機構）の講演資料は、こうした事情から、システム開発では外注すなわち契約の締結を避けられないと説明しています。*4
- 契約の形は主に2つです。請負は仕事を完成させる義務を負う契約、準委任は専門家として注意を尽くして作業する義務を負う契約で、完成の義務は負いません*3
- 企画（要件定義まで）・開発・運用と保守の段階ごとに、どちらの形で契約するかを選びます*3
- IPAは、契約書のひな型として「情報システム・モデル取引・契約書」の第二版を2020年12月に公開しています*1
外注といっても、すべてを開発会社に任せる形だけではありません。要件定義だけ、開発だけ、テストだけと、工程ごとに分けて頼むこともできます。どの工程を頼み、どこを自社に残すかで、メリットとデメリットの出方が変わります。
外注のメリットとデメリット
外注のメリットとデメリットは、自社に開発の担当者がいるかどうかで重みが変わります。まずは一般的な点を並べます。
メリット
- 社内にいない専門技術を持つ技術者に、開発に加わってもらえる
- 採用や育成を待たずに、開発を始められる
- 開発が終われば体制を縮められ、人件費を固定費として抱えずに済む
- 開発の進め方や品質の確かめ方を、経験のある会社の手順に沿って進められる
デメリット
- 何を作るかを決める作業は自社に残る。任せきりにすると要件の見落としが起きやすい
- 開発の知識が委託先に残りやすく、改修のたびに同じ会社に頼ることになりやすい
- 設計が固まった後の変更は、そのたびに費用と納期の協議が必要になる
- 社内の業務を説明する手間や、打ち合わせの時間がかかる
メリットの多くは「人と技術をすぐにそろえられる」ことから来ています。一方、デメリットの多くは「発注する側の関わり方」で小さくできます。デメリットを理由に外注をやめるより、防ぎ方を先に決めておくほうが現実的です。
内製との違い
内製は、自社の社員でシステムを開発することです。外注と内製のどちらが合うかは、開発を急ぐか、知識を社内に残したいかで決まります。主な違いを表にまとめました。
| 観点 | 外注 | 内製 |
|---|---|---|
| 開発を始めるまで | 契約を結べば始められる | 担当者の採用や育成から始まることが多い |
| 専門技術 | 委託先の技術者の知識を使える | 社内にいる人の技術の範囲に限られる |
| 費用の出方 | 案件ごとの委託料 | 社員の人件費が毎月かかる |
| 知識の蓄積 | 委託先に残りやすい | 社内に残る |
| 仕様の変更 | 契約に沿って費用と納期を協議する | 社内の判断ですぐに直せる |
| 発注する側の役割 | 要件の決定と、納品物の検収 | 開発のすべての工程 |
どちらか一方を選ぶ必要はありません。要件定義と検収は自社で持ち、設計からテストまでを外注する分け方もあります。費用の比べ方は内製化と外注のコスト比較で、外注から段階的に内製へ移る方法は内製化支援をナレッジ移転と伴走で進める方法で扱っています。
丸投げで起きやすい失敗と防ぎ方
IPAのモデル契約の解説は、請負で契約すると、発注する側に「丸投げ」の意識が強くなる場合があると指摘しています。その結果、要件定義での見落としも生じやすくなるとしています。*2 外注で起きやすい失敗と、モデル契約が示す防ぎ方を並べると次のようになります。
| 起きやすい失敗 | きっかけ | 防ぎ方 |
|---|---|---|
| できたものが業務に合わない | 要件を委託先に任せた | 要件は発注する側が主体的に決める。要件定義書の確定は発注側の責任者の権限と責任*3 |
| 費用と納期が膨らむ | 設計が固まった後に追加の要望を重ねた | 設計の承認後の変更は、変更管理の手続で委託料と納期を協議する*3 |
| 見積もりが大きくずれる | 要件があいまいなまま全体を一度に見積もった | 工程ごとに契約を結び、要件が明確になった段階で見積もり直す*2 |
| 稼働後に不具合が見つかる | 受け入れの確認を委託先に任せた | 検収は発注する側が中心になって行い、検査の仕様書も原則として発注側が作る*3 |
発注する側の協力には、委託先の作業を妨げないことも含まれます。仕様を固める合意をした後に大量の追加要望を出し、開発を遅らせたとして、発注した会社に損害賠償の責任が認められた裁判例もあります。*3 段階ごとの役割分担を図にすると、次のとおりです。
外部に頼むときに確認しておきたい点
システム開発を外注するときは、見積もりの金額を比べる前に、契約の中身と役割分担を確かめておきます。次の5つは、契約の前に委託先と話しておきたい点です。
- 契約の形：工程ごとに請負と準委任のどちらで契約するか。要件定義のような企画の段階は準委任が基本です*3
- 役割分担：要件定義書と画面などの設計書を、誰がどの時点で確定するか。双方の責任者は誰か
- 変更の手続：追加の要望をどう受け付け、費用と納期をどう協議するか
- 再委託：作業の一部を別の会社に再委託するか。モデル契約は業務の全部の再委託を認めず、一部の再委託にも発注側の承諾を求める案を示しています*2
- 引き継ぎ：設計書やソースコードなど、何を納品物とするか。社内に知識を残す方法をどうするか
最後の引き継ぎは、後から内製に切り替えたいときに効いてきます。納品物に設計書が含まれていないと、改修のたびに同じ委託先へ頼むしかなくなります。将来の運用まで見据えて、契約の段階で決めておくと進めやすくなります。
まとめ：外注で確かめておきたい3つの点
システム開発の外注で失敗を避けるうえで、確かめておきたい点は3つに整理できます。第一に、外注のメリットとデメリットを踏まえ、どの工程を頼み、どこを自社に残すかを決めること。第二に、要件の決定と検収は発注する側が持ち、設計の承認後の変更は手続に沿って協議すること。第三に、契約の形、再委託、引き継ぎの範囲を契約の前に委託先と確かめることです。この3点を踏まえておけば、「任せたはずが、できあがったものが業務に合わなかった」という事態を避けやすくなります。外注と内製の分け方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
システム開発の契約書のひな型はありますか
IPAが「情報システム・モデル取引・契約書」を公開しています。*1 Word形式の文書は自由に手直しして使えると案内されています。ただし、ひな型は対等に交渉できる会社どうしの契約を前提にしているため、自社の案件に合わせた見直しが必要です。
小さな改修だけでも外注できますか
できます。既存システムの機能追加や画面の修正だけを頼むことも珍しくありません。その場合も、どこを直すのかを文書にまとめ、直した後に自社で確かめる手順を決めておくと、追加の費用を抑えやすくなります。
外注先の候補はいくつ比べればよいですか
決まった数はありませんが、同じ要件をもとに複数の会社から見積もりを取ると、金額だけでなく作業の範囲や前提の違いが見えます。比べ方はシステム開発の相見積もりも参考にしてください。
システム開発の外注と内製の分け方のご相談
どの工程を外注し、どこを自社に残すかの整理から、要件定義の支援、開発、内製への引き継ぎまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：第二版の公開日（2020年12月22日）、Word形式の文書を自由にカスタマイズして利用できる旨の記述を参照（2026年10月確認）
- *2 参考：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」（2025年4月8日更新）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000087884.docx）。出典：請負型で「丸投げ」の意識が強くなる場合があるとの指摘、多段階契約と再見積り、再委託（全部の再委託を認めないこと、A案の事前承諾）の記述を参照（2026年10月確認）
- *3 参考：IPA「情報システム・モデル取引・契約書」の解説資料（2025年4月9日更新・PowerPoint）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/000089598.pptx）。出典：請負型と準委任型の義務の違い、フェーズと契約類型、役割分担のモデル、要件定義書の確定の権限と責任、検収と検査仕様書、協力義務と札幌高判平成29年8月31日の記述を参照（2026年10月確認）
- *4 参考：IPA 講演資料「システム開発の健全化に向けて」（2025年4月24日）（https://www.ipa.go.jp/digital/model/ug65p90000001ljh-att/20250424-kouen.pdf）。出典：8ページ「ICTシステム開発における契約の必要性」（IT人材の所属割合 IT企業72％・ユーザー企業28％、出典はIPA「IT人材白書2017」）を参照（2026年10月確認）
