受託開発とは？依頼の流れ・契約形態・新規事業の選び方

この記事では、受託開発の基本、依頼から納品までの流れ、請負契約と準委任契約の違い、新規事業で依頼先を選ぶときの確認ポイントを整理します。受託開発の失敗は、開発会社の腕前だけでなく、「契約の形」と「プロジェクトの性質」が合っていないことから起きる場合も少なくありません。発注前に全体像を押さえ、社内で判断するための材料としてお使いください。

受託開発とは何か

受託開発とは、システムやアプリケーションの開発を、発注する会社（発注者）から依頼を受けた開発会社（受託側）が、自社の技術と体制で請け負って開発することです。発注者の要望に合わせて一から作る「オーダーメイド」の開発を指すことが多く、「システム開発の外注」とほぼ同じ意味で使われます。

他の選択肢との違い

システムを用意する方法は、受託開発だけではありません。違いを整理すると、自社に合う方法を選びやすくなります。

• 自社開発（内製）：自社でエンジニアを採用・育成して開発する方法です。仕様変更に素早く対応できる反面、採用と育成に時間がかかります。
• パッケージ・SaaSの導入：既製のソフトウェアやクラウドサービスを使う方法です。すでに形になっているため早く使い始められますが、自社独自の仕組みには合わせにくい場合があります。
• 受託開発：自社の要件に合わせて作れます。一方で、何を作るかを発注者と受託側で正しくすり合わせる必要があります。
• ラボ型開発：一定期間、開発チームを確保して継続的に開発を進める方式です。受託開発の中でも、仕様が変わり続ける案件向けの契約形態として使われます。

新規事業でシステムそのものが事業の中心になる場合、既製のサービスでは差別化しにくいことがあります。このようなときに、受託開発が有力な選択肢になります。

受託開発の依頼の流れ

会社や案件によって細部は違いますが、一般的な流れは次のとおりです。

1. 目的と範囲の整理

最初に、何のために作るのかを整理します。「誰の、どんな課題を解決するのか」「成功をどう測るのか」を言葉にしておくと、後の判断がぶれにくくなります。この段階では、仕様が細かく決まっていなくても構いません。

2. 依頼先の検討と相談

複数の開発会社に相談し、提案や見積もりを比べます。資料としてRFP（提案依頼書）を用意することもありますが、新規事業では仕様が固まっていないことが多いため、構想段階のメモや企画書を元に相談する形でも進められます。

3. 契約の締結

依頼先が決まったら契約を結みます。最初に秘密保持契約（NDA）を結び、その後に業務委託の基本契約や個別契約へ進むのが一般的です。契約の形は次の章で詳しく説明します。

4. 要件定義

システムで何を実現するかを決める工程です。必要な機能、画面、データ、利用者、運用の方法などを整理します。ここでの認識違いが、後の手戻りの大きな原因になります。

5. 設計・開発・テスト

要件をもとに設計し、実装し、動作を確認します。途中で進捗の確認や、画面・機能のレビューが入ります。

6. 受入確認と納品

発注者側が、依頼した内容どおりに動くかを確認します（受入テスト、検収）。問題がなければ検収が完了し、納品となります。

7. 運用・保守

納品後も、不具合の修正、サーバーの管理、機能追加といった運用が必要です。この部分を事前に決めていないと、公開後に困るケースが多くあります。

契約の形：請負契約と準委任契約

受託開発の契約は、大きく「請負契約」と「準委任契約」に分かれます。どちらを選ぶかで、責任の範囲や進め方が変わります。契約の法律上の細部は、最終的には弁護士など専門家に確認することをおすすめします。ここでは、判断の基本となる考え方を整理します。

請負契約

請負契約（民法632条）は、「決められた成果物を完成させること」を約束する契約です。受託側は完成させる責任を負い、発注者は完成した成果物に対して報酬を支払います。

発注者にとっては、何が納品されるのかが明確なのが利点です。一方で、最初に仕様を固める必要があります。開発途中で仕様を変えたい場合は、変更の扱い（追加の対応が必要か、どこまでが当初の範囲か）で揉めやすくなります。

請負では、納品物に契約内容との不適合があった場合の責任（契約不適合責任）も論点になります。民法では、発注者が不適合を知ってから1年以内に通知する必要があるとされています（民法637条）。実務では、契約書で期間や範囲を別に定めることが一般的なので、内容を確認してください。

準委任契約

準委任契約（民法656条）は、「業務を遂行すること」を約束する契約です。受託側は、専門家として注意を払って業務を行う義務（善管注意義務、民法644条）を負いますが、成果物の完成そのものは約束しません。

仕様が固まっていない段階でも進めやすく、状況に応じて内容を調整しやすいのが利点です。一方で、最終的に何が出来上がるかは、発注者側も関わりながら管理する必要があります。

準委任には、作業した時間や工程に対して報酬を支払う「履行割合型」と、成果の引き渡しに対して報酬を支払う「成果完成型」があります（民法648条、648条の2）。どちらなのかは、契約書で確認しておきたい点です。

違いの比較

観点	請負契約	準委任契約
約束すること	成果物の完成	業務の遂行
向いている場面	仕様が固まっている開発	仕様が変わりやすい、上流工程、調査・検証
発注者の負担	最初に要件を固める負担が大きい	進行中の判断や管理の負担が大きい
仕様変更	変更の扱いを事前に決める必要がある	柔軟に調整しやすい

「どちらが良い」ではなく「工程ごとに使い分ける」

どちらか一方が常に優れているわけではありません。経済産業省が公表している「情報システム・モデル取引・契約書」でも、要件定義や設計の段階を準委任、開発の段階を請負といったように、工程を分けて契約する「多段階契約」の考え方が示されています。仕様が見えていない段階で、全体を請負で契約すると、あとから食い違いが生じやすくなるためです。

準委任で注意したい点

準委任契約でも、発注者が開発者に直接、細かく指揮命令する形になると、労働者派遣や偽装請負との区別が問題になることがあります。誰が、誰に、どこまで指示を出すのか。この運用は事前に確認しておきましょう。

新規事業で受託開発を使うときの難しさ

通常の業務システムの開発と、新規事業の開発では、難しさが異なります。

一番の違いは、「何を作れば正解か」が最初には分からないことです。新規事業では、利用者の反応を見て仕様を変えることが前提になります。ところが、請負契約で仕様と費用を先に固めた場合、途中で分かった「これじゃない」への対応が難しくなります。

もう一つは、社内の判断の難しさです。経営陣（決裁者）と現場（立案者）は、同じ目的を見ていても、判断の材料や進める速度が違うため、話が噛み合わないことがあります。ズレているのは目的ではなく、進め方であることが多いと私たちは考えています。企画書だけで「何ができるのか」を伝えるのには限界があり、動く実物があるかどうかで、社内の議論は進みやすくなります。

新規事業のシステム開発を構想から運用まで進める全体像は、新規事業のシステム開発の進め方｜構想から運用までの全体像 で整理しています。あわせてご覧ください。

新規事業で依頼先を選ぶ7つのポイント

以上を踏まえ、新規事業で受託開発の依頼先を選ぶときに確認したいポイントを挙げます。

1. 事業の目的を理解しようとしているか

「何を作るか」だけでなく、「その事業で何を実現したいか」を聞いてくる会社かどうかを見てください。仕様を言われたとおりに作るだけの会社と、事業の形まで一緒に考える会社では、提案の中身が変わります。

2. 仕様が変わる前提の進め方になっているか

新規事業では、仕様は途中で変わります。請負なのか準委任なのか、その組み合わせはどうか、変更があった場合どう扱うのかを、最初に説明してもらいましょう。

3. 契約前に実物で確認できる機会があるか

言葉や資料だけで要件を決めると、認識違いが起きやすくなります。画面のイメージやプロトタイプ（試作品）など、動くものを見て判断できる機会があるか、あるならどの段階でどこまで見られるかを確認してください。

4. 担当者と体制が見えるか

提案時の担当者と、実際に開発する人が違うことがあります。誰が窓口になるのか、連絡の頻度や方法はどうか、進捗の見せ方はどうかを確認しましょう。

5. 成果物の権利とデータの扱いが明確か

ソースコードなどの著作権が、納品後にどちらに帰属するのかを確認します。著作権法61条2項では、著作権を譲渡する契約で、翻案権など（27条・28条の権利）が明記されていないと、それらは譲渡した側に残っていると推定されます。自社で改修や他社への引き継ぎをしたい場合は、契約書に明記してあるか確認してください。あわせて、利用者のデータの扱いやセキュリティの考え方も確認します。

6. 納品後の運用・改善まで見ているか

新規事業のシステムは、公開してからが本番です。不具合の対応、サーバーの管理、機能追加をどう進めるのか。納品後の体制を最初から決めておくと、リリース後に慌てずに済みます。

7. AI活用の考え方と、品質の担保の仕方

近年は、AIを開発に取り入れる会社が増えています。スピードの面で期待できる一方、AIが出力したものを誰がどう確認するのか、という品質の担保が重要です。AIを使うかどうかより、「何を人が判断し、どう品質を確かめるのか」を説明できるかどうかを見てください。

発注前に確認したい契約書のチェック項目

依頼先を決めたあと、契約書で確認しておきたい項目をまとめます。

• 契約の種類（請負／準委任、準委任の場合は履行割合型か成果完成型か）
• 成果物の範囲と、検収の基準・期間
• 仕様変更や追加の依頼があった場合の扱い
• 納品後の不具合への対応範囲と期間
• 知的財産権（著作権）の帰属と、利用の範囲
• 秘密保持の範囲と、再委託する場合の取り扱い
• 契約の解除や中断をする場合の条件
• 運用・保守の範囲と、契約の更新方法

社内に詳しい担当者がいない場合でも、「誰が、何を、いつまでに、どの基準で」決めるかが書かれているかを見るだけで、多くの認識違いを防げます。

まとめ

受託開発とは、発注者の要望に合わせて、開発会社がシステムを一から作る形の外注です。依頼の流れは「目的の整理、依頼先の検討、契約、要件定義、設計・開発、受入確認、運用」が基本です。

契約は、成果物の完成を約束する請負契約と、業務の遂行を約束する準委任契約に分かれます。仕様が固まっていない新規事業では、最初から全体を請負で固めるのではなく、上流の工程は準委任、仕様が見えてから請負、といった分け方を検討すると、認識違いが起きにくくなります。

依頼先を選ぶときは、①事業の目的への理解、②仕様変更を前提にした進め方、③契約前に実物で確認できる機会、④体制の見えやすさ、⑤権利とデータの扱い、⑥納品後の運用、⑦AI活用と品質の担保、の7点を確かめてください。

私たちJustFit（運営：株式会社LEGAREA）は、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく「先に作って、後から決める」進め方をとっています。システムが事業そのものになるような新規事業を、仕様が固まる前の段階から一緒に考えられます。詳しくはJustFitのサービス紹介をご覧ください。