LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

システムを作りたいが、社内に開発の人手がない。開発会社に相談したら、受託開発・SES・準委任と言葉が並び、どれで頼めばよいのか分からない——。初めて開発を外部に頼む情報システム部門では、こうした戸惑いが起こりがちです。受託開発とは、発注する会社が求めるシステムを、開発会社が仕事として引き受けて完成させ、納品する形の開発です。

作るものが決まっていれば、完成までの責任を開発会社に任せられる点が受託開発の強みです。ただし万能ではなく、要件が固まっていない段階や、社内の担当者が技術者と一緒に開発を進めたい場面では、準委任やSESのほうが合うこともあります。本記事では、システムの発注を担当する方に向けて、受託開発の意味、SES・準委任との違い、進め方、そして外部に頼むときに確認したい点を整理します。

受託開発とは

受託開発の「受託」は、頼まれた仕事を引き受けるという意味です。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」も、「受託開発（一部企画を含む）、保守運用」を対象にした契約書のひな型を用意しています。^*2 発注する会社（ユーザー）と開発会社（ベンダー）が、工程ごとに役割と責任を分けて結ぶ形です。

• 発注側が「何を作るか」を決め、開発会社が設計・プログラムの作成・テストを受け持ちます
• 開発に加わる技術者は開発会社が選び、作業の指示も開発会社が出します^*2
• 完成したシステムを納品し、発注側の検査（検収）に合格したところで区切りがつきます
• モデル契約では、工程ごとに個別の契約を結び、請負か準委任かをそのつど決めます^*2

法律の上で受託開発の中心になるのは、民法の請負です。民法は請負を「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」契約と定めています。^*1 つまり受託開発で発注側が支払うのは、作業にかかった時間ではなく、完成した結果に対してです。

SES・準委任との違い

受託開発と並べて語られるのが、準委任とSES（システムエンジニアリングサービス）です。準委任は、民法の委任の規定を「法律行為でない事務の委託」に当てはめた契約で、^*1 仕事の完成ではなく、専門家として作業をきちんと行うことを約束します。SESは法律上の用語ではなく、技術者の作業を提供するサービスの呼び名で、準委任の形で契約を結ぶのが一般的です。

表で見落としやすいのが「作業の指示」の列です。受託開発でもSESでも、発注側が開発会社の技術者に直接作業を指示できるわけではありません。厚生労働省は、労働者派遣か請負かは「契約形式ではなく」実態に即して判断されると示しています。^*3 技術者に日々の作業を直接指示したいなら、労働者派遣のように指示を出せる形の契約を選ぶことになります。契約の条文の違いはシステム開発の準委任契約と請負契約の違いで、SESと準委任の関係はSESと準委任契約の違いで詳しく扱っています。

受託開発の進め方

受託開発は、発注側の準備から納品後の保守まで、いくつかの工程に分けて進みます。IPAのモデル契約は、工程によって請負と準委任を使い分ける形を示しています。^*2 全体を1本の請負で結ぶのではなく、決まっている部分から順に契約を結んでいく考え方です。

• ステップ1：RFP（提案依頼書）を作り、開発会社から提案書と見積書を受け取る
• ステップ2：要件定義（何を作るかを決める工程）。決めるのは発注側で、開発会社は支援する立場のため準委任で結ぶ^*2
• ステップ3：外部設計（画面や帳票など、使う人から見える部分の設計）。準委任と請負のどちらでも結べる^*2
• ステップ4：内部設計からテストまで。開発会社が完成を約束する請負で結ぶ
• ステップ5：発注側が検査して合格を出し、運用と保守の契約へ移る

つまずきやすいのはステップ2です。要件定義で決めた内容が、その後の請負で開発会社が完成を約束する範囲になります。要件があいまいなまま請負の契約を結ぶと、完成の基準もあいまいになり、納品の段階で「頼んだものと違う」という食い違いが起きやすくなります。RFPの作り方はRFP作成を支援・外注する方法でまとめています。

受託開発が向いている場面

受託開発を選ぶかどうかは、作るものがどこまで決まっているかで考えると迷いません。受託開発が向いている場面と、ほかの形のほうが合う場面を並べると次のとおりです。

• 向いている：業務システムの刷新など、作る範囲と仕様を文書にまとめられる
• 向いている：社内に開発チームが無く、設計からテストまでをまとめて任せたい
• 向いている：完成の時期と予算を、開発を始める前に固めておきたい
• ほかの形が合う：何を作るかをこれから探る段階（要件定義を準委任で頼む）
• ほかの形が合う：社内の開発チームで開発を続けながら、技術者を加えたい（SESや派遣を検討する）
• ほかの形が合う：長い目で見て、開発を自社の力にしたい（内製化を検討する）

受託開発で作ったシステムを、あとから社内で保守したい場合もあります。その場合は、ソースコードや設計書の引き渡しまでを契約に入れておくことが前提になります。受託開発から内製へ切り替える進め方は内製化支援をナレッジ移転と伴走で進める方法で扱っています。

外部に頼むときに確認しておきたい点

受託開発では、完成までの責任を開発会社が持つ分、契約で決めた範囲と基準がすべての前提になります。見積もりの金額を比べる前に、次の点を発注側で確かめておきます。

• 工程ごとの契約：要件定義・設計・開発のどこまでを請負にし、どこを準委任にするか
• 検収の基準：何を確かめれば合格とするか。モデル契約では、テスト項目やテストデータを定めた検査仕様書をもとに検査します^*2
• 仕様の変更：途中で変えたいときの手続き。モデル契約は、変更の理由・費用・スケジュールへの影響を書いた変更管理書で協議する形です^*2
• 不具合への対応：納品後に見つかった不具合を、いつまで、どこまで直してもらえるか
• 権利の扱い：作ったプログラムの著作権を、開発会社と発注側のどちらが持つか。モデル契約でも3つの案が示されています^*2

特に検収の基準は、発注側が用意するものです。基準を決めないまま納品の日を迎えると、何をもって合格とするかで話がまとまらず、支払いや保守への移行が止まってしまいます。検収の進め方はシステム開発の検収・受入テストの進め方にまとめています。

まとめ：受託開発で確かめておきたい3つの点

受託開発を発注するうえで、確かめておきたい点は3つに整理できます。第一に、作るものが文書にできるほど固まっているかを見て、受託開発・準委任・SESのどれで頼むかを決めること。第二に、全体を1本で結ばず、工程ごとに請負と準委任を分けて契約を結ぶこと。第三に、検収の基準と仕様変更の手続きを、開発が始まる前に決めておくことです。この3点を踏まえておけば、「納品されたシステムが思っていたものと違う」という事態を避けやすくなります。発注の形や契約の分け方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：e-Gov法令検索「民法（明治二十九年法律第八十九号）」（https://laws.e-gov.go.jp/law/129AC0000000089）。出典：第632条（請負）、第637条（担保責任の期間の制限）、第643条（委任）、第648条（受任者の報酬）、第656条（準委任）の条文を参照（2026年10月確認）
2. *2　参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：受託開発（一部企画を含む）、保守運用のひな型の第4条（個別契約と契約類型）、第11条（業務従事者への指揮命令）、第14条（要件定義作成支援業務）、第19条（外部設計のA案・B案）、第24条（ソフトウェア開発業務）、第27〜29条（検査仕様書・検収・契約不適合責任）、第37条（変更管理書）、第45条（著作権のA案・B案・C案）を参照（2026年10月確認）
3. *3　参考：厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」（https://www.mhlw.go.jp/bunya/koyou/gigi_outou01.html）。出典：労働者派遣と請負の区分は契約形式ではなく実態に即して判断されるとの説明を参照（2026年10月確認）

Tweet