受託開発とは何か ― 契約の形と、発注前に決めておくこと

「システム開発を外に頼むことになったが、契約書に『請負』と書いてある会社と『準委任』と書いてある会社があった。何が違うのか」

「開発会社に見積もりを依頼したら、金額が数倍開いた。同じものを頼んだつもりだった」

「納品されたものが、想定していたものと違った。仕様書には書いていなかったと言われた」

システム開発を外部に依頼するときのご相談は、こうした声から始まります。いずれも、契約の形と、決めておくべきことの理解がずれていたところから生まれています。

この記事では、受託開発とは何か、他の依頼の仕方と何が違うのか、契約の形で何が変わるのか、そして発注する前に決めておくべきことを、受託開発を行っている側の視点で整理します。

受託開発とは

受託開発とは、システムやソフトウェアの開発を外部の企業に依頼し、完成した成果物の納品に対して報酬を支払う形態です。依頼を受けた会社が、要件の整理から設計、開発、テスト、納品までを一貫して担当します。

自社にエンジニアを抱えずに開発を進められること、そして成果物に対して責任の所在がはっきりしていることが、この形態の特徴です。

似た言葉に「システム開発の外注」がありますが、こちらは外部に任せることの総称で、契約の形までは指しません。受託開発は、その中の一つの形です。

SES・派遣・自社開発との違い

外部に依頼する形はいくつかあり、混同されやすいので整理します。

SES（システムエンジニアリングサービス）は、エンジニアの稼働時間に対して報酬が発生します。人手を補う契約であり、成果物の完成を約束するものではありません。「外注した」と言っても、受託開発とSESでは責任の所在がまったく違います。

派遣は、発注側が直接指示を出せる点がSESと異なります。SESでは発注側が直接指示を出すことができず、これを行うと契約上の問題になります。

自社開発は、自社の製品やサービスを自社の人員で作ることです。内製化はこの形に近づけていく取り組みです。

見積もりを比べるときは、それぞれがどの形での提案なのかを先に揃えてください。時間に対する契約と成果物に対する契約は、そもそも金額の意味が違います。

請負契約と準委任契約で、何が変わるか

受託開発の契約は、多くの場合このどちらかです。実務で何が変わるのかを整理します。

4つの観点で並べると、違いがはっきりします。

請負契約は、仕事の完成に対して報酬を支払う契約です。決めた成果物が完成しなければ、報酬を請求できません。納品後に契約の内容に適合しない箇所が見つかった場合、開発会社が修正などの責任を負います。これを契約不適合責任と呼びます。

なお、2020年4月の民法改正より前は「瑕疵担保責任」と呼ばれていました。古い資料や記事ではこちらの表記が残っているため、読み替えが必要です。

準委任契約は、業務の遂行に対して報酬を支払う契約です。決められた作業を適切に行うことが求められますが、成果物の完成そのものは約束されません。

労働者派遣契約は、発注側が直接指示を出せる点が上の2つと違います。請負と準委任では指揮命令権が開発会社側にあるため、発注側が現場のエンジニアに直接指示を出すと契約上の問題になります。

実務上の違いは、次のように出ます。

• 仕様が固まっているか。 作るものが明確なら請負が向きます。要件を探りながら進める段階では、準委任のほうが実態に合います
• 変更への対応。 請負では、決めた範囲を超える変更は追加の契約になります。準委任では、優先順位を入れ替えながら進められます
• 完成の判断。 請負では受け入れの基準が要ります。何ができていれば完成とみなすかを、契約の時点で書いておく必要があります

要件定義の段階は準委任、仕様が固まってからの開発は請負、というように工程で分ける進め方もよく取られます。最初にすべてを請負で決めようとすると、決まっていないものを金額に落とすことになり、双方にとって不利になります。

不確実さを金額に落とすとき、開発会社が取れる選択肢は2つしかありません。リスク分を上乗せするか、範囲を狭く解釈するかです。前者は発注側が余計に払うことになり、後者は「それは範囲外です」というやり取りを生みます。要件が固まっていない段階で総額を決めようとすると、このどちらかが起きます。

要件定義を切り出して契約する進め方は、遠回りに見えて結果的に早く着きます。何を作るかが決まっていれば、その後の見積もりの精度も上がります。

なお、ここでの説明は一般的な整理です。個別の契約内容については、契約書の文面と、必要に応じて専門家の確認をお願いします。

受託開発のメリット

採用せずに始められる。 エンジニアの採用と育成にかかる時間と費用をかけずに、開発を始められます。

専門的な技術をその期間だけ使える。 特定の技術に詳しい人を、必要な期間だけ確保できます。常時抱える必要がありません。

成果物に責任を持ってもらえる。 請負契約であれば、完成しなかった場合の責任は開発会社が負います。

社内の負担が増えない。 既存の業務を持っている人に、開発の負荷を上乗せせずに済みます。

業務に合わせて作れる。 既製品では合わない業務でも、自社の進め方に合わせた形で作れます。

受託開発のデメリット

社内にノウハウが残りにくい。 設計の理由や運用の勘所が、開発会社側に蓄積されます。次の改修も外に頼むことになりがちです。

変更のたびに時間がかかる。 見積もり、合意、着手という往復が毎回発生します。変更が多い仕組みほど、この待ち時間が積み上がります。

社外に情報を渡すことになる。 業務の内容や顧客のデータを委託先に共有します。取り扱いの取り決めが必要です。

認識のずれが起きやすい。 事業側の意図が伝わりきらないまま作られると、動くけれど使われないものになります。冒頭の「想定していたものと違った」はこれです。

初期の費用がまとまって発生する。 内製のように人件費として分散するのではなく、プロジェクト単位で費用が発生します。

受託開発が向いている場合、向いていない場合

向いている場合

• 社内に開発できるエンジニアがいない、または採用の見込みが立っていない
• 期限が決まっていて、採用から始める時間がない
• 一度作れば当面大きく変えない仕組みである
• 既製品では業務に合わず、自社に合わせて作る必要がある
• 認証やインフラのように、専門性が高く自社で維持する意味の薄い領域である

向いていない場合

• 月に何度も仕様が変わる。往復の待ち時間が事業の速度を決めてしまいます
• その仕組みが事業の差別化そのものにあたる。ノウハウが社外にたまり続けます
• 何を作るべきかがまだ決まっていない。この段階では、作るものを決める進め方から始めたほうが早く進みます

3つ目に当てはまる場合は、いきなり本開発を発注するより、PoC・MVP開発のように小さく作って確かめる進め方が向いています。

内製化と迷っている場合は、システム開発は内製化すべきか、外注すべきかに判断の軸を整理しました。あわせてご覧ください。

受託開発の流れ

会社によって呼び方は変わりますが、おおむね次の工程で進みます。

1. 相談・ヒアリング — 何を解決したいのか、いつまでに必要かを共有します。この段階では要件が固まっていないのが普通です。

2. 要件定義 — 何を作るのかを決めます。ここが最も重要な工程です。曖昧なまま次に進むと、後の工程すべてに影響します。

3. 設計 — 画面、データの持ち方、外部システムとの連携方法を決めます。

4. 開発 — 実装を進めます。定期的に動くものを確認できる進め方だと、認識のずれが早く見つかります。

5. テスト — 開発会社側の確認に加えて、発注側でも実際の業務の流れで確認します。ここを省くと、公開後に問題が出ます。

6. 納品・運用 — 引き渡し後、問い合わせと不具合対応を誰が担当するかを決めておきます。請負契約であれば、納品後に見つかった不具合について開発会社が修正の責任を負う期間が定められているのが一般的です。その期間と範囲も確認しておいてください。

工程の進め方には大きく2つあります。ウォーターフォール型は、要件定義から順に工程を進め、前の工程に戻らない前提で計画します。仕様が固まっていて、期日が動かせない案件に向きます。アジャイル型は、短い期間で作って確認することを繰り返します。要件を探りながら進める案件に向きます。

契約の形と対応しており、ウォーターフォール型は請負、アジャイル型は準委任と組み合わせられることが多くなります。どちらが優れているという話ではなく、作るものがどれだけ決まっているかで選びます。

発注側の関与が最も必要になるのは、2の要件定義と5のテストです。ここに時間を割けるかどうかが、結果を大きく左右します。「丸投げできる」と考えて進めると、たいてい想定と違うものが出てきます。

受託開発でよくある失敗と、避け方

ご相談をいただく中で、繰り返し見かける形があります。

要件定義に発注側が参加しない。 「専門的なことは分からないので任せます」という進め方です。開発会社は業務のことを発注側ほど知りません。結果として、動くけれど現場が使わないものができあがります。避けるには、業務を知っている人を要件定義の場に出してください。技術の知識は必要ありません。

決める人が多すぎる。 関係者それぞれが要望を出し、誰も削らない状態です。範囲が膨らみ、期間も費用も伸びます。決める人を1人に定め、その人が判断する形にしてください。

テストを開発会社に任せきる。 開発会社のテストは、仕様どおりに動くことの確認です。実際の業務の流れで使えるかどうかは、発注側でしか確認できません。ここを省くと、公開直後に問題が出ます。

公開がゴールになっている。 誰が問い合わせを受け、誰が直すのかを決めずに公開すると、そこで止まります。運用の体制は、開発の計画と一緒に決めてください。

安さだけで選ぶ。 見積もりが安い理由は、効率が良いからかもしれませんし、含めている範囲が狭いからかもしれません。前提を揃えずに金額だけを比べると、後から追加費用が発生します。

将来の内製化を伝えていない。 引き継ぐ前提かどうかで、技術の選び方も設計も変わります。可能性がある段階で伝えておいてください。後から言われても、作り直しが必要になることがあります。

いずれも、発注側の力量というより進め方の設計の問題です。最初に決めておけば避けられます。

費用と期間の考え方

受託開発の費用は、公開されている情報を見ても幅があります。小規模なもので数十万円から、基幹システムの構築になると数千万円を超えるものまで、案件の内容によってまったく異なります。

人月単価という考え方

見積書を受け取ると、「人月」という単位を目にすることがあります。エンジニア1人が1か月稼働したときの費用を単価として、必要な人数と期間を掛けて総額を出す考え方です。

この方式は分かりやすい一方で、注意点があります。人月は投入量であって、成果物の量ではありません。同じ機能を作るのに、経験のある人なら1か月、慣れていない人なら3か月かかることがあります。人月で比べると、後者のほうが高く見えます。

見積もりを比べるときは、単価だけでなく何人が何か月関わる前提なのか、そしてその工数で何が完成するのかを確認してください。単価が安くても工数が多ければ総額は変わりません。

また、人月単価は担当者の役割によって変わるのが一般的です。プロジェクトマネージャー、エンジニア、デザイナーで単価が異なるため、内訳を見せてもらうと構成が分かります。

金額を決めているもの

金額そのものより、何が金額を決めているのかを把握したほうが、見積もりを比べられるようになります。主な要素は次のとおりです。

• 画面数と機能の数
• 利用する人の種類（一般利用者だけか、管理者や承認者もいるか）
• 外部システムとの連携（決済、認証、既存の基幹システムなど）
• 既存データの移行の有無
• 対応する端末（Webだけか、スマートフォンアプリも必要か）
• 求める可用性や監査ログの水準
• 公開後の運用と保守の範囲

冒頭の「金額が数倍開いた」は、多くの場合これらの前提が各社で違うところから生まれます。どちらかが不当なのではなく、含めている範囲が違うのです。比べるときは、金額を並べる前にこの前提を揃えてください。

期間は、規模と要件の固まり具合で変わります。共通しているのは、期間を延ばす主な要因が実装量ではなく、仕様が決まらない待ち時間だという点です。週に一度は動くものを確認し、その場で判断できる体制を作れるかどうかが効きます。

見落とされやすいのが、運用にかかる継続的な費用です。クラウドの利用料、データベース、外部サービスの利用料、監視の仕組み。これらは開発費とは別に、毎月発生し続けます。開発費だけで予算を組むと、公開後に足りなくなります。

保守の費用も同様です。不具合の修正だけを含むのか、小さな改修まで含むのか、対応時間はどうか。契約によって幅があるため、開発の見積もりと一緒に確認しておいてください。

発注前に決めておくこと

見積もりを取る前に決めておくと、後の進行が楽になる項目です。

何ができれば成功か。 動くものを納品することが目的ではないはずです。何が起きれば投資が回収できたと言えるのかを、先に言語化してください。

誰が決めるか。 仕様の判断をする人を1人に定めます。関係者が多いほど、判断が遅くなります。

契約の形と変更の扱い。 請負か準委任か。仕様変更が発生した場合に再見積もりになるのか、一定の範囲で吸収されるのか。口頭で合意したことは、必ず書面に残してください。「言った・言わない」は、受託開発で最も多いトラブルの形です。

見積もりに含まれる範囲。 要件整理、UI/UXデザイン、テスト、クラウドの費用、公開後の保守。どこまでが含まれるのか。

受け入れの基準。 何ができていれば受け入れるのかを、機能単位で並べます。

運用の担当。 公開後に問い合わせを受けるのは誰か、障害時に誰が判断するのか。

成果物の権利。 ソースコードの著作権がどちらに帰属するか。将来内製化する可能性があるなら、ここは特に確認してください。

将来内製化する意向があるか。 引き継ぐ前提かどうかで、技術の選び方も設計もドキュメントの粒度も変わります。後から伝えられると、作り直しが必要になることがあります。

セキュリティと情報の取り扱い。 どのデータを渡すのか、どこに保管されるのか、作業する人の範囲はどうか。個人情報や機密情報を扱う場合は、契約書とは別に取り決めが要ります。

これらは、見積もりを取る前に社内で決めておけるものです。決まっていない状態で複数社に依頼すると、各社が違う前提で見積もることになり、比べられなくなります。

WTはシステム開発として、要件定義から設計・開発・運用まで一貫して担当しています。これまでの開発事例も公開しています。

よくあるご質問

受託開発とSESは何が違いますか？

受託開発は完成した成果物の納品に対して報酬が発生し、開発会社が成果物の責任を負います。SESはエンジニアの稼働時間に対して報酬が発生し、成果物の完成は約束されません。「外注」と一言で言っても、この2つでは責任の所在が違います。

請負契約と準委任契約は、どちらを選ぶべきですか？

作るものが明確に決まっているなら請負、要件を探りながら進める段階なら準委任が実態に合います。要件定義の工程は準委任、仕様が固まってからの開発は請負というように、工程で分ける進め方もよく取られます。

丸投げでも進められますか？

進められません。要件定義とテストの工程は、発注側の関与が必要です。何のための仕組みかを知っているのは発注側だけなので、ここを委ねると想定と違うものができあがります。

見積もりが会社によって大きく違うのはなぜですか？

各社が含めている範囲が違うためです。要件整理、UI/UXデザイン、テスト、クラウド費用、公開後の保守。どこまでを含めるかで金額は大きく動きます。金額を並べる前に、この前提を揃えてから比べてください。

開発の途中で仕様を変更できますか？

契約の形によります。請負契約では、決めた範囲を超える変更は追加の契約になるのが一般的です。準委任契約では、優先順位を入れ替えながら進められます。変更が起きる前提であれば、契約の時点でその扱いを決めておいてください。

納品されたシステムのソースコードはもらえますか？

契約次第です。著作権の帰属は契約書で定めるものなので、発注の時点で確認してください。将来内製化する可能性があるなら、特に重要な項目です。

受託開発と内製化、どちらを選ぶべきですか？

事業の中核にあり変更頻度が高い部分は内製、専門性が高く変更の少ない部分は外注、という分け方が現実的です。判断の軸はシステム開発は内製化すべきか、外注すべきかに整理しました。

まだ何を作るか決まっていない段階でも相談できますか？

ご相談いただけます。その段階であれば、いきなり本開発を発注するより、小さく作って確かめる進め方が向いていることが多いです。お問い合わせから、整理したいことをお聞かせください。

ウォーターフォールとアジャイル、どちらで進めるべきですか？

作るものがどれだけ決まっているかで選びます。仕様が固まっていて期日が動かせないならウォーターフォール型、要件を探りながら進めるならアジャイル型が向きます。契約の形とも対応していて、前者は請負、後者は準委任と組み合わせられることが多くなります。

開発期間中、発注側はどのくらい時間を取られますか？

工程によって差があります。要件定義とテストの期間は関与が必要で、週に数時間から、規模によってはそれ以上かかります。設計と開発の期間は、週に一度の確認ができれば進みます。「まったく時間を取られない」進め方は、結果として想定と違うものを生みます。

公開後の保守はどこまで含まれますか？

契約によって幅があります。不具合の修正だけを含むもの、小さな改修まで含むもの、対応する時間帯を定めるもの。開発の見積もりと一緒に、範囲と費用を確認しておいてください。運用にかかるクラウド費用も、開発費とは別に毎月発生します。

複数社から見積もりを取るとき、何を揃えればよいですか？

作るものの範囲（画面数、機能、外部連携、データ移行、対応端末）、契約の形、見積もりに含む工程、公開後の保守の範囲。この4点を同じ条件で伝えてください。揃っていないと、金額の差が何から来ているのか判断できません。

まとめ

受託開発とは、完成した成果物の納品に対して報酬を支払う開発の形です。SESや派遣とは、責任の所在も指揮命令の関係も違います。

契約の形は請負と準委任があり、仕様が固まっているかどうかで適した形が変わります。工程で分ける進め方も一般的です。

そして、受託開発は丸投げできる仕組みではありません。要件定義とテストの工程では、発注側の関与が結果を左右します。ここに時間を割ける体制を作れるかどうかを、発注の前に確かめてください。